Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Come to FooBar University; learn any language in 3 days!

By terran in Op-Ed
Fri Oct 06, 2000 at 02:13:43 PM EST
Tags: Software (all tags)

I can't count the number of times I've heard someone say: "If you learn Computer Science, you'll be able to learn any programming language in a few days." Every time I hear it, it pisses me off. It pisses me off because it is total, unadulterated, ego-stroking bullshit that bears no more resemblance to reality than a deranged mountain lion bears to a cucumber.

I went to a prestigious university. I've seen a lot of CS grads up close. I've seen that a lot of them spend weeks getting to the "hello world" level when they get a job and have to write actual code. Never mind that, however. I'm not saying merely that many CS graduates happen to be incompetent; I'm saying that the very idea that a theoretical background lets you learn programming languages quickly is fundamentally broken.

If you want to write a program, there are three things you have to understand. You need to understand the algorithms you're going to use, the language(s) in which you're programming, and the platform(s) you are targetting. These are all learned separately. Let's suppose I'm going to write a Unix daemon in C. Algorithm knowledge lets me do things like store my data in a hash table instead of an array that I bubble-sort every time I insert something. Language knowledge lets me make intelligent decisions between functions like sscanf or atoi, and prevents me from writing 'printf ("user supplied string");'. Platform knowledge is what tells me how to use things like socket() and bind(). If any of these three are lacking, my program will suck.

Now, let's consider what you learn in a theoretical CS program. You learn lots about algorithms, so that part is covered just fine. You don't learn a damn thing about real-world platforms, but that's not the subject here, so we'll assume that you learn all about those on your own. This brings us to languages. They don't teach real-world languages in theoretical CS, so all you can learn is general information applicable to multiple languages. You learn the fundamental concepts of procedural and functional languages (and possibly other types as well).

Now, this is important, especially the part about functional languages. We understand functional programming! We're much better than all those self-taught procedural-language code-monkeys. All they can learn is the syntax, but we can appreciate the beauty and elegance of the underlying principles. Let's sit around and feel special. Go ahead, feel special. Please. Get it out of your system.

Now that you're done feeling special, I'd like to point out that this isn't the hard part of learning a programming language. The devil, as they say, is in the details, and this is very true here. The hard (or at least time-consuming) part of learning a programming language is not in the basic theory. It's in learning about the functions (or standard library) that the language provides. You may think that there isn't a whole lot to learn here, because you can always look things up when you need them. This is both true and false. I'll take the example of C. If I know the name of a function, I can figure out its syntax quite easily, using 'man'. However, if I know what I want to do, it's nontrivial to find a function which does it. That's what you have to learn. I don't need to remember the syntax for, say, memset (does the value come before or after the size?). I need to know that when I want to set memory to a particular value, memset is the function I should look up. This comes from experience, and knowledge of the particular language in question. This takes time. What takes even more time is the ability to make intelligent decisions - do I use scanf, or write my own parser? How do I divide the code into files? Which functions would be better as a preprocessor macro?

What about other languages, like, say, Common Lisp. You can learn common lisp in three days? You can't read the Common Lisp spec in three days! I won't even talk about C++.

Yes, Mr. Computer Scientist, you can be more skilled than the person who taught himself a language without any background. However, you don't get there for free. You get there by putting in just as much effort to learn the language as he did, in addition to your theoretical background. If you understand the theory and not the language, you're no better than the person who understands the language and not the theory - you're just differently incompetent.

I don't doubt that you can learn just the syntax of a language in three days. In fact, you can probably learn the syntax in three hours. Trying to program knowing only the syntax and algorithms is like trying to drive to the other side of the world with perfect directions and maps, but without understanding what the wheel and pedals do. Saying that you can learn a language in a few days is like saying that because you understand the theory behind transportation, you can trivially learn to drive any type of vehicle. Go drive a stick shift with no experience then come back and tell me that with a straight face.

If you think you can learn a language well enough to write reasonably good programs in three days, you're simply wrong. The CS professor who told you that you could was wrong too, probably because he's never done any actual programming in his life. It takes time to learn a language properly, regardless of how many other languages and abstract theory you know.

I don't doubt that there are people who genuinely believe that they can learn programming languages in three days. I also don't doubt that they have never properly learned any languages at all and write very, very bad code.

I'm not saying that there aren't legitimate, valuable contributions that one can make in the realm of computer science without writing any real-world code at all. There are. If that's what you want to do, I have only the greatest of respect for you - as an applied mathematician. Just don't pretend that you can actually program a real-world computer when you can't. Every time someone claims to be able to learn a new programming language in a ridiculously short amount of time, it not only makes the speaker look dumb, it's an insult to everyone who has actually put in the time to learn to program properly.

It's the same in other disciplines. A great number of engineers look down on machinists. They think that they understand the principles of the machines, and the machinist is just an operator. Then, one day, they have to do the machinist's job, and they can't. The then learn the lesson that the application of theory is a skill in and of itself, and does not trivially follow from the theory. It's a lesson that theoretically-minded people of all sorts must learn sooner or later in order to be worth anything, and many never do.

A century from now, there will probably still be people who understand the theory of something and think they can trivially learn to apply it whenever they want. A century from now, they will still be wrong.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


How quickly can one go from having no knowledge of a language (take C as an example) to being a competent programmer?
o 3 days 4%
o 2 weeks 7%
o 1 month 9%
o 3 months 13%
o 9 months 11%
o 2 years 8%
o 5 years 1%
o A Minute to Learn, a Lifetime to Master 42%

Votes: 264
Results | Other Polls

Related Links
o prestigiou s university
o Also by terran

Display: Sort:
Come to FooBar University; learn any language in 3 days! | 106 comments (104 topical, 2 editorial, 0 hidden)
You are lost in space (3.78 / 23) (#3)
by maketo on Fri Oct 06, 2000 at 01:30:13 PM EST

Formal education is about giving you the capabilities to delve into the details with an organized approach. It is not about sitting down and cranking out a PERL script that uses some quirk of the underlying platform. This any idiot can learn and they can be perfectly fine all their life doing just that. Try to get them to do anything more complicated and you will see how stuck and frustrated they will get. Now, there is a lot of CS grads outhere that dont know what the hell they are doing but that is not due to the error of the system, it is a personality issue.Some people do just enough to pass a course and some really love what they do. Some are in school to "get the degree and the job" and some are in there for the love of hacking. And CS is as much about hacking as is your rant. If you follow the field(s) you will see that many scientists usually come from Europe (eastern) and they have VERY strong theoretical basis with emphasis on mathematics and physics. Back home my computer science program had 31 courses all in all and of those 15 were various calculuses and mathematics. After that formal training you can sink your teeth into anything and you can actually be a scientist as well as an engineer. Compare this to a person that "knows his platform and his language". The devil is in the details, I agree, but the SCOPE is as important and SCOPE you get from how broad your mind is.
agents, bugs, nanites....see the connection?
Re: You are lost in space (3.20 / 5) (#6)
by terran on Fri Oct 06, 2000 at 01:42:46 PM EST

You claim that I am "lost in space", but I can't find any substance in your comment which actually disagrees with what I'm saying. You're saying it's good to "be a scientist as well as an engineer". I said the same thing:
Yes, Mr. Computer Scientist, you can be more skilled than the person who taught himself a language without any background.
Obviously, I said it in an emotionally charged way. It's a rant; that's the point. You will notice that I also listed a knowledge of algorithms as one of the things required to write a good program.

I was never disputing the importance of theory. I was disputing the claim that having theoretical background makes it substantially easier to learn the practical side of things. Your comment does not seem to actually express an opinion on this point, let alone disagree with me, and thus it's not clear to me why you conclude I am so wrong.

I wouldn't have posted a rant if I didn't want argument, but please, disagree with what I'm actually saying and not a straw man. :)

[ Parent ]

Re: You are lost in space (4.00 / 1) (#83)
by peteg on Sun Oct 08, 2000 at 03:41:07 AM EST

OK, my first post on kuro5hin. be gentle. ;-)

Some things you just need theory to do; try implementing some machine learning algorithms in your spare time and see how far you get. Then, try getting them to work on real world examples. Not "practical" enough for you? I assure you there's a fortune to be made applying these techniques to the stock market.

As regards programming languages: just what are we using them for, and what do we expect them to do for us?

An example: it's difficult to see the merit in something like Haskell or Mercury without having an appreciation of the theory underlying them (try writing something that depends on global state a lot - such as a compiler - in a "purely declarative" language and you'll see what I mean. Now try and understand their solution to the state-problem - monads - and ask yourself whether this ends up being anything significantly different to an imperative language - and if not, why do it this way?). Their advantage is that they make reasoning about programs a lot simpler; this in turn means that more ambitious programs can be written. It also means automatic program transformation is possible in a way that puts C to shame.

Theory's also good for telling you how much you can rely on your tools; I for one would prefer to use more recursion (OO seems to encourage it) but then you pay the performance penalty. There's no reason (in theory ;-) why most of the recursion couldn't be turned into iteration, and it'd be nice to have a compiler do that for me, and tell me when it can't.


[ Parent ]
Finally, (4.26 / 19) (#4)
by trhurler on Fri Oct 06, 2000 at 01:37:47 PM EST

a decent rant. Of course, I don't agree with all of it, but it is certainly a decent rant. Personally, I think what you get from CS depends on who you are and where you go to school, and even which particular professors you have. Also, and this is crucial, on what you spend your free time doing.

I got out of school with a solid understanding of C, a passing familiarity with C++, and a healthy smattering of algorithms, data structures, analysis of said, a whole lot of operating system theory, more Unix knowledge than I ever thought possible, and minimal experience in assembler. Guess what? Not only did I have no learning curve except our product when I joined my employer, but I find that I actually have to deliberately go and learn something new if I want to know it; quite frankly, I have skills I'm not using at my current(C development) job.

Now, I'd agree that I'm the uncommon case, but I didn't go to a big name school, and I didn't get great grades, and I claim that anyone who really likes computers and programming can do what I did to get here - the problem is that they -don't- do it.

Step one: learn C, assembly, computer architecture, and operating systems. I know this is bass ackwards from what profs want. They're wrong, which is why they're teaching instead of making the big bucks. Ignore them for now and keep moving. If you don't understand this stuff, then everything else you learn is a floating abstraction that you don't REALLY comprehend. While you're at it, your classes will be teaching algorithms, data structures, and analysis. Learn these things too; you'll be spending a lot of your off hours tinkering around on Unix systems learning the stuff that I mentioned first, but it isn't as though I'm trying to say the material taught in classes isn't important - it certainly is.

Step two: program for awhile. While you're at it, you'll probably take OS theory courses(these should be easy for you by now,) program design courses(these will come in handy when you're programming; apply the techniques you learn at every opportunity, and know upfront that you'll make mistakes of the "I have a hammer, therefore that's a nail" variety,) advanced analysis courses, compiler theory, and so on. All of this is good stuff, but don't get so caught up in math that you don't have time to keep learning practical skills. If you have spare time, learn a scripting language(Python, perl, whatever,) and regular expressions. If you fancy OO stuff, then do that too; hopefully one of your design courses covered this topic somewhat.

At this point, you -should- be able to learn programming languages pretty easily. C is a nasty one because of all the hoary details of safely using its libraries, but once you know that stuff, learning something like python should be nigh on trivial, which is where I disagree with this rant; some languages ARE easy to learn, and C is the real hard one. Well, C++ isn't easy either, but that's a different rant. Exactly what you learn is up to you, and depends on what you want to do after school. The important thing to note about this plan, which can be varied for different purposes(ie, you already know you want to be an OO deity,) is that you do most of the learning on your own time. School can only teach you things professors are good at; if they were good at what I do, they'd be doing it instead of teaching math to halfwits who were told "you must go to college!"

'God dammit, your posts make me hard.' --LilDebbie

Re: Finally, (3.50 / 2) (#60)
by mikpos on Fri Oct 06, 2000 at 08:03:54 PM EST

I agree. I think the only reason people think he has much of an argument at all is because he used C as an example. It took me about six months to become decent in C, another four months to become decent in C++, another three or four hours to become decent in Objective C, and then another twenty minutes to half an hour to become conversational in Smalltalk (mind you I wasn't concerned with silly things like file I/O and other trivialities which actually let you do useful things). So after learning C, I was able to walk the C-Smalltalk continuum very quickly.

However, then I got interested in functional programming languages. I skimmed through Common Lisp and Haskell and a few others. I spent a few days (or maybe weeks) at, albeit in a pretty half-assed fashion, and I still can't code my way out of a functional wet paper bag.

Anyway, for concepts you're already familiar to, you can pick up a language very quickly I think. Learning Pascal if you already know C can probably be done in a matter of days. Learning Haskell if you only know Bourne shell could be a different matter entirely, though.

[ Parent ]

I'm a PhD student in computer science... (4.00 / 17) (#5)
by fluffy grue on Fri Oct 06, 2000 at 01:39:04 PM EST

...and I agree 100%.

Actually, a big misconception about CS which psises me off is that it's not even about programming. It's about computation. Algorithms and the like. CS isn't about learning how to program or write software, it's learning the mechanics of computation, the ideas behind programming and solving problems, and the semantics of what programming languages are. Granted, there's some level of programmin for research, but that's NOT what CS is about.

I can't stand how a lot of students here come here to learn to program so they can make big bucks as software developers, and then when they don't immediately become a master programmer they bittle it as though they've been cheated. And a lot of them don't even want to learn, and they don't understand that programming is a creative process - many people graduate from here (and there's even some graduate students like this) thinking that they can program by just copying and pasting existing code. One of my friends teaches a section of C programming, and a lot of the students are unable to complete the assignments because they can't understand that programming is more than just "typing stuff in."

But that's a whole other rant. :)

"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

CS and computers (3.40 / 5) (#7)
by Kaa on Fri Oct 06, 2000 at 01:45:23 PM EST

Actually, a big misconception about CS which psises me off is that it's not even about programming. It's about computation.

This is entirely correct. Some very smart person (was it Dijkstra?) said:

Computer science is about computers in the way that astronomy is about telescopes.

And that about sums it up.

Kaa's Law: In any sufficiently large group of people most are idiots.

[ Parent ]
Re: I'm a PhD student in computer science... (3.33 / 6) (#11)
by trhurler on Fri Oct 06, 2000 at 02:17:54 PM EST

I agree with most of what you just said, but you show signs of ivory tower syndrome. Believe it or not, there are those of us who got BS degrees(and a good many who never got that far,) who are quite good at this whole "computation" thing, as well as merely being good programmers. It simply is not true that the only way to learn is to do it in a school. I personally wish I had time to take a few more courses in a few subjects, but not enough to get a masters, and I can learn those things on my own, given time and a bit of tenacity.

Frankly, I hated school. Why should I pay money to be made to jump through hoops? That's supposed to work the other way around. And don't pretend college is about learning; if it was, professors wouldn't drop students with 97% averages just because they were late to class too many times, or fail students they know understand the material on the ground that they slipped up somewhere along the way and it was the wrong place to slip up(say, bombed a test, whatever.) College is about proving you can handle poverty, suffering, and irrational stupidity on the part of people with nigh-on-absolute control over your success long enough to get a piece of paper that everyone knows doesn't mean anything, but everyone wants you to have anyway. Fortunately, I got good at what I do on my own time, and used college to supplement that where possible, but don't even try to tell me I ought to have enjoyed it.

And don't tell me it was my school, or my profs. I have friends who have gone to Duke, Purdue, MIT, UC-Berkeley, UIUC, and so on. It is the same everywhere; the only difference is a given student's ability/willingness to put up with it. To some, it doesn't seem as bad, or they just don't care as much. To others, it does, or they do.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Re: I'm a PhD student in computer science... (3.50 / 2) (#49)
by fluffy grue on Fri Oct 06, 2000 at 05:33:00 PM EST

Um, you're putting the proverbial cart before the horse. Just because CS is about computation and not programming doesn't mean that ONLY CS majors can learn about computation and not programming. I never said that only in college can you learn about computation - just that in college CS that's what you learn about, computation, not programming.
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: I'm a PhD student in computer science... (3.50 / 2) (#72)
by Vetinari8 on Sat Oct 07, 2000 at 02:54:35 AM EST

I keep getting the impression that some people think the perfect hiring procedure is:
Does the person have a degree? If they don't, hire them. They are sensible and worthy people.

If so, does the person have a BS? Flip a coin four times. At least one head? Hire them. They're fools with a little bit of sense.

Does the person have an MS? Flip a coin four times. At least three heads? Hire them. They're retards we can throw away later.

Does the person have a PhD? THROW AWAY THE RESUME! They don't know jack and are worthless idiots.

It's strangely malignful to me, mostly because my research group is composed of people who can definitely handle programming, system admin., etc.... pretty much everything similar people without degrees can do, with a deeper understanding of what's going on (the theory). We're also the programming languages research group here so this all strikes a strange chord in me. :)

People always say that programming languages is a dead area in the real world; but then again who's going to handle the compilers, interpreters, and virtual machines of the world with the most knowledge and background?

Anyways, the point of seemingly pointless languages (e.g. Scheme, SML) is that they're more expressive than your typical C-like language. I don't mean in terms of Turing power (because all of these are Turing complete, I mean even TeX is Turing complete); I think I mean in terms of abstractions. Computer-sciencey stuff as opposed to coding-engineering stuff. Of course C/C++ or Java can do these things, but it tends to be a lot harder to implement in either (one because it's too low-level, the other because it leaps too high in weird ways -- ever tried explaining to freshmen with 0 experience what an object is? Don't. Just don't).

(And Scheme and other variants of LISP do get used in the "real world". Ever heard of Emacs? Or GNOME? Or Sawfish? And SML is often lauded by compiler-people as being one of the most natural languages to write a compiler in. SML's got cool stuff in it. So does Scheme. If you don't see this, then all I have to say is, where did your engineering curiosity go?)

I suppose if you're not very interested in seeing the how of everything, then school is useless to you. This will limit you in the future in ways you won't know aught of until you're older.

Anyways, I wouldn't call my colleagues useless idiots. One of them is one of the most active programmers on Dia and got a summer internship at Xerox park.

But that's just me. And I'm just a useless idiot to be, so why listen? :)
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick

[ Parent ]

Re: I'm a PhD student in computer science... (3.75 / 4) (#22)
by intol on Fri Oct 06, 2000 at 03:36:13 PM EST

One thing that I found a bit shocking when I took my first programming class in college was that 95% of the students had absolutely no programming experience at all. The majority of them were CS majors. I was expecting to find a class with more "geeks", or at least some people who were interested in CS for something else besides "making the big buck$". It was a bit discouraging, to say the least.

One day before class started, when I feeling particularly bored, I decided to ask as many of the CS majors as I could why had they chosen CS as their major. The most popular response was that programmers make lots of money.

At my school more than 50% of the CS majors drop out of the program before the end of their second year. The most popular reason given is that "CS is too hard".

All of this had such an effect on me that I've decided to transfer. (I have not decided where yet, but I'm leaning towards CMU because I have friends there)

Anyone care to comment on similar experiences?


[ Parent ]

Re: I'm a PhD student in computer science... (2.50 / 2) (#33)
by mezzo on Fri Oct 06, 2000 at 04:23:23 PM EST

Well, what do you expect? People go to where the money is, whether its parents or society pressuring them to be successful.

My first semester here, I took classes in Music, Psych, CS, because I couldn't figure out what it was that excited me. The more I did CS though, the more I liked it. And I found myself in the field. It was only after I chose CS did I discover how great the job market was. But there are people in it just for the money, and sometimes its discouraging. But if you take hard classes like compilers, or honours versions of classes, you'll find more people there who do it because they love it.

In any field you'll find people who are in it because they love it, or because of money or just because they need to major in something. And I don't think going to a better school like CMU would change it.

"The avalanche has started, it is too late for the pebbles to vote."-- Kosh
[ Parent ]

For the love of the game (4.00 / 3) (#45)
by Denor on Fri Oct 06, 2000 at 05:09:23 PM EST

I started wondering recently, too. I was talking to a person in my Statistics class who, it turned out, was also a computer science major. And as I enjoy being able to talk shop with people, I started to. One of my favorite topics of conversation is personal projects: what are you doing in your spare time on the computer, just for fun?

Nothing, it turns out. She doesn't play with the computer outside of class.

That was a little strange, I thought. So I bugged some other people who I was familiar with and knew were in the CS program. What were their personal projects?

They weren't up to anything, either.

I'm wondering if it's just me - if I (and the people who I used to talk to about their projects) are a small minority who really get into the computers, and that everyone else is in it for the money, or whatever reason.

I plan on bothering my other friends, too, and warning off those who are in it for anything other than enjoyment. Because if you're not in this for the love of the game, you're very quickly going to find the work intolerable. Hell, I do, and I love it :)


[ Parent ]
Re: I'm a PhD student in computer science... (2.00 / 1) (#81)
by yuri82 on Sat Oct 07, 2000 at 08:57:52 PM EST

I first learned programming when I was 12. Loved it. Everything I did was in xBASIC and it kept me going forever. That is, until i got to college. I wanted to program 24/7. They gave me a c++ class that taught me how to print out 'hello world' on a console program. My grades are shitty now. I hate college and all my CS classes. I pass them, but barely, because I understand them but I hate doing the work. College made me lose all of my curiosity in computers. My point is, I am not learning what I want to, and i want to learn it all, not just console programs that use great algorithms. I want to make stupid programs that have awesome graphics. So now I'm digging into programming books that I would never read in school and learning everything that school isnt teaching me. Has the school work helped any? Not a single bit. I'm starting from scracth everytime I read on a new language.

[ Parent ]
The hard stuff (3.75 / 12) (#8)
by sbeitzel on Fri Oct 06, 2000 at 01:48:42 PM EST

Actually, how hard it is to learn a given language varies. C, for instance, requires one to learn a set of functions, sure, but the hardest part of programming in C is really learning to think algebraically. While this is cake for somebody who's done well in math, I can think of a few people I know in the business who dropped out of high school or who never took a math class that they understood. I never, ever want to try to maintain their code.

On the other hand, take Java. Please. It's a freakin' zoo of objects and each one has tens of methods dripping off it. So I want to display a value to the user; which object do I instantiate and how do I assign the appropriate value to it so that it'll display properly? With a more procedural language you can probably look in the index of a language reference book (you know, with paper) and find the function you're looking for fairly quickly since it'll probably be named something like "print" or "display" (shell programming newbies would be SOL, of course, since an "echo" is something you listen to, not read). With Java, you have to know a lot more of the object zoo before you can do something useful.

Okay, but suppose you already know one language pretty well. Say you learned Pascal or FORTRAN at GoshWhattaUniversity and you get hired by some company that does all its coding in C++. You'll be able to pick up the language (if not the principles of OOP) pretty quickly because C++ is (with some weird and nasty exceptions) a superset of C, which acts a lot like Pascal without the verbosity.

So the main point still stands, that theory may be useful but it sure doesn't give you some magic shortcut to programming with ease. But you only hit a language from a standing start once in a paradigm.

Excellent rant! (3.23 / 13) (#9)
by vorx on Fri Oct 06, 2000 at 02:02:05 PM EST

I agree wholeheartedly with you! I'm a completely self-taught programmer, with around 17 years of good, solid experience, and I agree, you have to know more than just theory. Theory is a VERY useful thing to have, it will save your butt on more than one occasion, but with the way colleges are skimping on practical applications of the theory, a degree can actually be a hindrance.

Case in point: I'm interviewing for some new positions here in my company, and I'd say at least 80% of them are CS grads, who come in with a "I have a degree now, so I am completely qualified to rule the world now, thank you" attitude... Listing experience with dozens of popular languages on their resumes... Start asking them to do anything beyond the 10 line apps they've done for their homework assignments however, and watch the fun begin! It's getting to the point where if I see a resume with a degree and all these supposed qualifications, I'm just immediately trashing them. It's a waste of my time to keep interviewing college grad know-it-all's that really don't.

Anyway, I was about to launch into a full mini-rant myself, so I better stop :)

Re: Excellent rant! (3.00 / 5) (#10)
by terran on Fri Oct 06, 2000 at 02:14:27 PM EST

who come in with a "I have a degree now, so I am completely qualified to rule the world now, thank you"
Yes, it's exactly people like that who piss me off. It's good to see there's other people out there who sympathize. :)
but with the way colleges are skimping on practical applications of the theory, a degree can actually be a hindrance.
I actually think it's OK for universities to teach only theory, as long as they're honest with their students about what they're doing. They need to say: "We teach you theory and algorithms here. This is an important part of what you need to learn in order to program, but it's not everything. If you want to actually program, instead of dealing only with the abstract, you'll also need to learn programming languages and platforms. We don't teach you either of those, but they're important and nontrivial." The problem is when the universities say "We teach you theory, and there's nothing else that you need to learn. You can now go out and lord your degree over the world."

[ Parent ]
Re: Excellent rant! (3.00 / 4) (#15)
by vorx on Fri Oct 06, 2000 at 02:47:14 PM EST

Now there's an idea... drop the pure theory crap, and start offering degrees that REQUIRE a portion of real life, practical, work to be done. Almost like the requirements for PhD's, etc... Not a thesis per se, but how about something along the lines of: "Ok, you know most of the theories used in programming, now to graduate you must write a single-entry accounting system similar to Quicken or Money, with features X, Y and Z, with a full gui. Your choice of language and platform. Come back when it's done."

THAT would separate the wheat from the chaff in a most effective manner... No hiding a lack of knowledge there.. it's one thing to bungle your way through a 20 line homework assignment, it's a whole different story to try and write a 30k-line accounting system... You actually have to know what you are doing then! :)

[ Parent ]
Re: Excellent rant! (2.33 / 3) (#25)
by AndyL on Fri Oct 06, 2000 at 03:50:33 PM EST

Don't most university CS programs require a senior project of some sort? I havn't gotten that far, but I always assumed that it ment some sort of real-world application was required.

[ Parent ]
Re: Excellent rant! (2.50 / 2) (#30)
by overcode on Fri Oct 06, 2000 at 04:14:29 PM EST

Some universities do require real-life projects. For instance, all Georgia Tech CS students have to do a senior design project before they graduate, which involves designing and implementing something non-trivial. GT also has a very strong co-op program so that students can graduate with real-world experience.

I'll agree that a CS degree isn't an instant ticket to world domination. However, I do think it's a start on the right path for someone who's willing to keep an open mind with respect to learning. It provides - or should provide - a solid understanding of what makes computer systems tick and how they can be improved. A CS degree is not a coding degree.


[ Parent ]
Re: Excellent rant! (1.00 / 1) (#40)
by vorx on Fri Oct 06, 2000 at 04:57:19 PM EST

Ok, I'll agree than that if GT has those kind of requirements and incentives, then it's a Good Thing. I also agree that CS, by definition, isn't a coding degree. It should be about how the theory of computers and programming work... but don't give students the idea that getting a CS == being a programmer... I've unfortunately seen that happen too many times, and I personally think that it is a major factor contributing to the lack of quality in our industry.

[ Parent ]
Re: Excellent rant! (2.66 / 3) (#34)
by mezzo on Fri Oct 06, 2000 at 04:29:14 PM EST

Well, that's why you have technical schools, and things that certify you in whatnot. As others have pointed out, Computer Science is the study of computation, of algorithms, not of the instrument itself.

That said, however, I assume most good schools do make you take a praticum.

"The avalanche has started, it is too late for the pebbles to vote."-- Kosh
[ Parent ]
Re: Excellent rant! (2.66 / 3) (#39)
by vorx on Fri Oct 06, 2000 at 04:53:23 PM EST

Well, my opinion on technical schools (based upon my rather limited experience dealing with them and their students) is that they are the classroom-based equivilant of "Learn C in 21 Days" books... They teach students how to write in a language or two, but the end result is no better than a pure-theory CS grad... They may know the langauge good, but their theory is lacking, and you still don't know if they have what it takes to work on real projects in the Real World. Now granted, I'm sure there are good schools out there that teach a good balance of theory AND practical experience, but I've not personally come across them.

[ Parent ]
Re: Excellent rant! (2.50 / 2) (#53)
by mezzo on Fri Oct 06, 2000 at 06:09:10 PM EST

Balance can be good.. though in my case, I do prefer theory. But what do you mean by Real projects, or Real World? I mean, if I want to work in IT for say, an investment bank. All I really need to know is SQL, scripts, Excel, a bit of db stuff. If I work for an 'e-commerce site' I end up doing lots of JSP, ASP, servlets and whatnot. Either of them really isn't that technically challenging (well some are, but most isn't), nor need much theory about np-completeness, automatons, discrete math. I do think that theory and 'practical skills' are two different things. And given a candidate with one or the other, I would prefer one with a good theory background.

Languages change, theory doesn't.

"The avalanche has started, it is too late for the pebbles to vote."-- Kosh
[ Parent ]
Re: Excellent rant! (none / 0) (#75)
by vorx on Sat Oct 07, 2000 at 12:40:31 PM EST

Well, I'm not referring to the different skill sets that different applications need, as you said, I need different skills to code a financial app than an e-commerce app. But some things stay common to both, and are the skills to which I was reffering. Things like the ability to organize your code, both in terms of how you organize your storage of source code, and in terms of how you architect your application. Both are vastly important, and neither is very much needed on small apps. I know I learned that lesson the hard way the first time I had to write a large program :) It's not a matter of taking a small program and scaling it up, eventually you get to a point where things simply get too complex, and the app should be redesigned properly (like it should have been done in the first place) These are the skills I think that need to be at least partially addressed by the schools cranking out the CS grads.

[ Parent ]
Re: Excellent rant! (none / 0) (#76)
by vorx on Sat Oct 07, 2000 at 12:40:44 PM EST

Well, I'm not referring to the different skill sets that different applications need, as you said, I need different skills to code a financial app than an e-commerce app. But some things stay common to both, and are the skills to which I was reffering. Things like the ability to organize your code, both in terms of how you organize your storage of source code, and in terms of how you architect your application. Both are vastly important, and neither is very much needed on small apps. I know I learned that lesson the hard way the first time I had to write a large program :)

It's not a matter of taking a small program and scaling it up, eventually you get to a point where things simply get too complex, and the app should be redesigned properly (like it should have been done in the first place)

These are the skills I think that need to be at least partially addressed by the schools cranking out the CS grads.

[ Parent ]
Re: Excellent rant! (none / 0) (#84)
by newht on Sun Oct 08, 2000 at 03:46:45 AM EST

I'm a CS major myself, and I couldn't agree with you more for the lower end of the classes offered at my school. Classes like Intro to C, Intro to Java, Datastructures, and what not are designed specifically with a 30-50 lines of code, because they are there to teach the basics, ie. linked lists, classes, etc... But once I progressed to the 3-400 level classes, I started getting assignmets exactly like you've described, lenghty projects with fairly generalized goals. As an example, last semester I took Distributed Systems (400 level) and our final project was simply: write a distributed mail server, fully ACID, and it has to have this enumerated list of funtions implemented. These kinds of projects are all I've been seeing this last year, which is as it should be. Nearly every CS course, above the introductory level, has this type of sink or swim project. As for the theory vs. wrote memorization/copy-and-paste coding, nearly every school whose CS program I looked at required most of the following; Computational Models, data structures, a year of Algorithms, Systems Fundamentals (writing in MIPS 2000 I was more than happy to "bungle my way through a 20 line homework assignment"), network fundamentals, and 26 math credits (about 3 courses every two years). This sort of schedule seemed pretty typical to me, be it at a state school or Ivy League school. Now, of course there were two types of people in the CS department: those who wanted to know it all, and those who just wanted to know exactly enough to get the work done. THis can't be avoided, it happens in every discipline. ---- THis is where I degenerated into giving lofty advice about principles, the value of hard work, etc... so I'll just cut it off here. NEWHT

[ Parent ]
Re: Excellent rant! (3.00 / 2) (#67)
by 0xdeadbeef on Sat Oct 07, 2000 at 12:05:14 AM EST

Bah, it's the same chip on their shoulder as of the author if the editorial. You know why? Because so many schools can't teach worth shit. They have classes in specific lagnuages, but don't really teach theory at all.

They don't stress their students' programming abilities. In a real school you learn theory, and you pick up programming as you go along. Oh sure, there's some hand-holding in the beginning, but by the end of your sophmore year you should be fairly competent in learning new languages. For me at Ga Tech it was Pascal (intro), Lisp (functional programming), C (concurrency, intro to OSes), Smalltalk (OOP), and MIPS assembly (with a little compiler theory). From thereon there is no language teaching (except for a class on the theory of programming languages, with assignments in Prolog, ML, and Java). Most classes assume you know the chosen language, or will learn it in the first weeks of the class, or, like most of the higher level classes, can choose anything with a compiler on the school systems.

Learning languages is trivial compared to learning theory. Ok, I'll admit, I didn't feel like a C++ guru until after using it for three years. And I'm currently learning the ins and outs of the Java class library. I had to whip out the Camel book a lot when I used perl. But when I have a question about a language, I already know the answer: it is going to be yes or no. Because my questions are always either "does this language support this?" or "does this language have an equivalent to library routine such-and-such?"

Ask somebody just out of school who was trained only on specific languages to implement a hash table. Or linked list routines, binary trees, or evaluate the efficiency of an algorithm. This stuff is old hat by the sophmore year in a real school. People who spent their college years learning Visual Basic, or only the syntax and libraries of Java or C++ cannot do this without looking it up, if they can at all.

The fact is you learn good programming techniques by implement hard programs. You implement hard programs when you're learning theory. You do not learn programming by writing the toys in a "learn X in 21 days" book.

[ Parent ]

well then (4.44 / 25) (#12)
by blaine on Fri Oct 06, 2000 at 02:23:50 PM EST

Seeing as this rant is directed squarely at me, I feel the need to comment.

I think the problem here is that you're making the assumption that all three steps you've outlined are of equal difficulty. They are not.

Learning the theory behind computation on your own is a hell of a lot harder than learning the nuances of a language or a specific platform. By studying Computer Science, you learn what is arguably the hardest part of programming: how to create efficient and well-written code.

Let's assume I know OO theory, but I don't know C++. [false, but we'll assume this for now]. Now let's assume you know C++.

What do you think is going to be easier: me learning C++, or you learning how to write efficient algorithms in C++ ? If you answered the latter, you're kidding yourself.

It is possible to learn theory through practical experience. However, it is much easier to learn the theory first, and put it into practical use once you understand the concepts.

Also, I find it amusing that you assume I don't do any real-world programming. I actually don't do theoretical work in any way. I'm a "code-monkey", just like the people who you are defending. The difference is that I took the time to learn the hows and whys of CS. And this is why time and time again, I find people who are self-taught from "Learn [LANGUAGE] in 21 days!" books who know jack shit about real programming.

Does this mean that self-taught people can't be good? No. I know a few self-taught programmers who are goddamn brilliant. In fact, most of the people I know who are good at theory are also self-taught. The difference, once again, is that they took the initiative to go one step furthur, and learn the theory that they were missing. Most self-taught programmers never do this.

As a final note, you seem to be under the impression that all people who study CS graduate and don't know how to do any practical programming. This is far from true. Those who graduate and can't program worth shit are those who did the bare minimum work. The people who are truly good at CS and programming are those who actually spend time outside of classwork to learn the non-theory parts of it. In fact, this is why so many CS graduates feel that they didn't learn anything practical. They simply don't understand that they are supposed to be doing the practical learning on their own, and that the classes are for theory to complement the practical side.


- blaine

Re: well then (3.55 / 9) (#21)
by terran on Fri Oct 06, 2000 at 03:34:58 PM EST

Unfortunately, it doesn't seem to me that you've actually addressed the claim I was trying to make. My claim is: it takes much more than a few days to learn a programming language, and having theoretical background does not make it substantially faster.

You are claiming that it is more difficult to learn the theory than the programming language. I am not entirely convinced of this, but it's not really related to the point here anyway. I was claiming that it takes at least several months to learn a programming language, and that it does not take substantially less time if you have the world's most wonderful background in theory and algorithms. It is obviously better to understand the theory and the language than to understand the only language. I was not attempting to claim otherwise. My claims were about the time required to learn the language, a point which you do not seem to have addressed.

You also claim that I am "defending" people who do not understand theory, but I don't think that on the basis of what I wrote there's justification for thinking that that is my position. I listed a knowledge of algorithms as being necessary for programming, and I explicitly described people without knowledge of theory is "incompetent". There is no need to justify the importance of knowing more than syntax, because I am not disputing it.

I'm basically saying that someone with a computer science background needs to put as much time into learning a language as someone without a computer science background. If he does, he'll then do better than the person who learned the language but doesn't know any theory, but if he doesn't, he'll be equally or even more useless.

I'm sorry that you felt personally attacked by the rant, and I assure you that my sentiments were directed not at any one person but at dozens who have espoused similar views. If you think that you can learn (to the point of being good, not to the "hello world" level) any language you want in a few days, I do think you are very much mistaken (or some sort of superman), but I don't hate you for it (either way ;).

[ Parent ]

Re: well then (3.71 / 7) (#27)
by blaine on Fri Oct 06, 2000 at 03:58:19 PM EST

I can't give you much more than anecdotal evidence, but here we go:

I learned Java in 1 week. And I am hardly a superman. I simply didn't find it difficult. I've taken classes in OO theory. I already knew C++ . And quite frankly, within that 1 week, I was writing fairly complex programs. I was able to do this because I already knew the basic ideas behind what I was doing. All I had to do was learn syntax.

I don't believe that a person who hasn't studied theory could do this. However, I don't think that I'm special. I know more than one person who has done very similar things. Other, less impressive examples: learning Perl for me took almost no time. Of course, learning some of the more powerful parts of it [like its regexp engine] took more time, but still, I was writing useful programs in almost no time.

Anyways, one other thing I want to point out: going to college forces you to learn things you would never learn otherwise. The main reason for this is that if all you ever do is practical programming, you're never going to think to do a lot of these things. And quite frankly, the experience you get from this type of thing is important. It enhances your knowledge, and it will make you better at what you're doing.

[ Parent ]
It Depends On The Language:More Anecdotal Evidence (3.50 / 4) (#63)
by Carnage4Life on Fri Oct 06, 2000 at 09:35:33 PM EST

Unfortunately, it doesn't seem to me that you've actually addressed the claim I was trying to make. My claim is: it takes much more than a few days to learn a programming language, and having theoretical background does not make it substantially faster.

In my opinion it depends on the complexity and difficulty of the language. In my personal experience I have learned Javascript, Perl and VBScript each in 3 days or less when the occasion has presented itself that I need to use these languages in production code at one internship or the other. I am hardly a master at these languages in that I do not know all the ins and outs of them but all the code I wrote in them is being used as production code either in shipping products or in tools used by developers to build shipping products.

I have learned the elements of Lisp in less than a week for a class where we had to write a parser that converted Lisp code to the equivalent in C. I do not know the ins and outs of the language yet, but I can now edit my emacs source files with confidence from the knowledge I gained during that time.

On the other hand, I have known how to program in C++ for over two years but there are still aspects of the language I am either unfamiliar with or have never used. The same can be said for Perl. Basically, I agree with blaine where he states that anyone with a CS degree and a good book can learn the basic tennets of a language in a few days (tops a week) even though it may take a much longer period to actually become a master in the language. Also some languages, especially scripting languages, do not contain much that cannot be learned in over a few days, e.g. Javascript.

[ Parent ]
Re: It Depends On The Language:More Anecdotal Evid (2.00 / 1) (#104)
by skinhead on Mon Oct 09, 2000 at 08:55:08 PM EST

Also some languages, especially scripting languages, do not contain much that cannot be learned in over a few days, e.g. Javascript.

I feel that I just have to comment on this. Yes, Javascript is very simple and easy language. It is also damn hard to learn. The basic commands are easy, but with different browser it becomes hell. One has to remember what works with what and how to work around the limitations in some browsers. When you smile, the world laughs at you.

[ Parent ]
Re: well then (3.40 / 5) (#42)
by Pinball Wizard on Fri Oct 06, 2000 at 05:03:26 PM EST

>>Does this mean that self-taught people can't be good? No.

I definitely respect your attitude. I think one of the big reasons this subject is repeated ad nauseum is that people with CS degrees seem to jealously think their CS degree makes them superior to those without. Those of us who don't have a degree, yet have read Knuth and understand algorithms resent being relegated to 2nd class citizens because we don't happen to have that piece of paper. So if we are better than the kid with the CS degree but he makes $40,000 more because of it its bound to cause some resentment.

I've said it before, and I'll say it again: Its possible to be a good programmer without the degree. Its also possible to suck even if you have a degree from a good school.

[ Parent ]

Re: well then (2.25 / 4) (#55)
by Matrix on Fri Oct 06, 2000 at 06:13:33 PM EST

Excellent! This is basically why I'm going to University instead of trying to find a job straight out of high school. I'm also considering doing co-op work, to gain some practical experience. But there's one main reason I'm going to University. Math. Computers are based on mathematics, and understanding the math lets you program just a bit better.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

I'm one of those completely self-taught lads ... (3.12 / 8) (#13)
by Arkady on Fri Oct 06, 2000 at 02:35:28 PM EST

... and I also agree 100%.

It most certainly takes days to get through the Common Lisp spec, and I also don't want to get into discussion how long it'd take to get through C++. Though it usually takes me the three days to a week to get to basic grips with a new language, it takes months (even on a system I know well) to become reasonably proficient. Sure, I can write usable programs in the first week, but anything non-trivial definitely gets up over a month and anything sophisticated takes much longer.

Right on!

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.

don't forget the lack of solid history (3.12 / 8) (#14)
by mx on Fri Oct 06, 2000 at 02:39:05 PM EST

one of my peeves with current training is that developers come out of the institutions knowing almost nothing of what has been done and/or how. plethoras of people i've interviewed have not had a grounding in unix, the land of many sensibilities (and a few ass-backwardisms) ... not to mention learning about the people and how they thought (pike, richie, kernagin, bjarn, stallman, and *many* more). in fact, often developer types know nothing of history or even stuff outside of their *SINGLE* speciality - which can be as weak as VB only. not knowing how things are done, how the greats thought, and how many problems have been solved make for a weak developer ... unless they actually happen to be highly intelligent and are able to discover all of these things themselves (and even those would benifit from learning from others).
- mx
More CIS Woes (3.75 / 12) (#16)
by baberg on Fri Oct 06, 2000 at 02:47:50 PM EST

Allow me to share my experiences with the CIS department at another prestigious university (ok, maybe we're better known for football, but there is a school here...)

One instructor in the CIS department saw problems with so-called "standard" languages like, for instance, C++, and sought to change them to his liking. He fought for code reusability, clarity, and simplicity (all noble goals). However, in the course of doing so, completely destroyed a beautiful programming language and corrupted entire graduating classes of CIS majors.

His bastardization is called RESOLVE/C++. Perhaps there's meaning to the acronym, perhaps not. I never bothered to find out. RESOLVE consists of hiding all details from the end-programmer. You never hear about pointers, linked lists, etc. They are all jumbled together into a pre-made class called a "Partial Map". That's fine; it simplifies the course for beginners, because they don't have to worry about memory allocation, etc.

But here's the rub: RESOLVE/C++ is never used outside of my school's CIS department (have you ever heard of it?) And they never allow a student to write a program; they only write methods inside larger programs. Thus, as a result of this, programmers learn to only look as their own small picture, never realizing there are details (like #include lines, main (), and pointers) that they do not know about. I have met many students who can write beautiful code, taking full advantage of recursion and tight algorithms. But they cannot write a "Hello World" program.

The devil's in the details, indeed.

Re: More CIS Woes (3.66 / 3) (#64)
by Bradley on Fri Oct 06, 2000 at 10:16:22 PM EST

I'm going to (sort of) disagree with this. At my uni, the first language has been something called blue. Its strictly OO, and has a combination of things - pre/post conditions (sytax like eifell), integrated IDE/debugger, standard typesafe library classes (like c++, although the course only covers using them - 1st years don't write templates). It also has restrictions, like a class without a comment won't compile, no overloading, etc. (2nd year does java/C++/MIPS asm)

Its not used outside Usyd (although the people who created it moved to Monaash uni, and they use a derivative of it), but it gives a good intro to the basics, without worrying about the "hard stuff".

I already knew how to program (*BASIC), and so it wasn't as useful to me. They're moving to java from this semester, and people are having lots of problems with it. Why:

  • Theres a lot to get through before you can start coding. public static void main(String args[]) is not the first thing you want someone to see.
  • Lack of typesafety in the container classes.
  • Java isn't as "clean". Blue wasn't deisnged to be powerful, which makes it a much weaker language, but a much better teaching language.

    Students were doing some quite complicated stuff (for 1st year) with Blue. Inheritance is introduced at the beginning of 2nd semester, and the 2nd of 2 projects for that semester involve building recursive descent parsers for things like a spreadsheet, or parsing (a subset of) SQL SELECT statements for a databse. (data persistancy was intoroduced earlier). Other groups are writing interpreters for a (non-OO) subset of blue. The assignemnts are openended, so people can add what they want.

    Blue was ugly, slow and buggy. But it was used to teach to concepts, not the specifics. Someone else posted that they were first taught OO stuff instead of the fact that a ; is at the end of a line. So? Some introduction to a language is needed. But if you teach people the ideas, then whether you implement it in C, C++, java, or Intercal won't make a difference.

    Understanding all the syntax is useful to master a language. But if you know how to use a linked list, then there shouldn't be a problem doing it in c or java.

    Also, remember that in every group there will be a range of abilities. Especially with CS, where uni courses don't assume prior knowledge (unlike physics, chem, or maths), because a lot of hight schools (At least in .AU) don't offer it, or teach it well. Its hard to structure a course to cover all these groups.

    I picked up the concepts of java in a day or so. With that, a reference manual, and some example code, it wasn't really that hard. You never really learn a language until you code something in it. The first programming language is definately the hardest to learn.

    [ Parent ]

  • Re: More CIS Woes (none / 0) (#101)
    by baberg on Mon Oct 09, 2000 at 11:34:49 AM EST

    if you know how to use a linked list, then there shouldn't be a problem doing it in c or java

    I agree with this. If you understand the concept behind a linked list (which I feel is more valuable than concrete examples) then you can implement it in whatever language you choose. The problem here at OSU is that they never teach you that. They only vaguely touch on the fact that they have a linked list, which is a struct of the data represented and a pointer to the next argument.

    They mentioned that as kind of an "FYI" type of deal, without telling us how to implement it, giving any code examples, etc. Also, at the same time, they harp on the fact that (and I quote, because I recall this day very well) "On your resumes, put down that you know C++. The main code we have been doing is C++, we have just organized and simplified what you are doing." I'm sorry, but if you "know" C++, then you can write a Hello World program. Nobody in that class could write a simple program without external knowledge. THAT is the problem with teaching overly simplified languages.

    Overall, though, good counterpoints. I realize why they teach RESOLVE/C++ instead of ordinary C++. I just disagree with their methods.

    [ Parent ]

    Excellent! (4.06 / 16) (#17)
    by h0tr0d on Fri Oct 06, 2000 at 02:53:07 PM EST

    I wish my boss could have read this before making a big mistake. We do most of our embedded development in assembly for a multitude of reasons. Well, over that past few years the HR department has learned that it's getting harder and harder to hire competent assembly programmers. So the big boss comes up with the idea that even though our hardware won't be very efficient we will move to C. Besides, this makes the code portable so hopefully some time in the future we can port to a new platform. Well, sure enough the HR people now think that they have a mass of qualified C programmers.

    There are many things that have gone wrong with this plan but two are prominent and appropirately realted to this. The first is that we have discovered that it is just as hard to hire a competent C programmer as it is to hire an assembly one. You see, the boss and HR fail to realize that we program embedded systems with completely different constraints than a pc has(there's actually a lot more to it than this but this sums it up rather well). The second problem is that in creating our application in C for our embedded platform we weren't able to use any of the standard libraries. So we have written our own to accomplish the task at hand. So now the new programmer not only has to learn how to program in a very restrictive embedded environment but they must also forget everything they already new about the standard library and learn ours. So much for the theory that moving to C would make everything easier. I think the average learning curve for a new assembly programmer is about 6 months(plus or minus depending on previous experience) and that same curve for the new C programmer is about a year. So much for efficiency. I figure the big boss must have gotten this idea form one of those "Learn to Program C in 21 Days" books. He probably bought it, read it, and after 21 days he was able to make "hello world" on his own pc at home. So he must have figured that if he could do that much with his own pc imagine what we could do with our platform. Oh well.

    I'm also tired of conversing with other "programmers" who "know" a certain language and then when it really comes down to it the only programming experience they have is the "hello world" they did in school. I absolutely hate it when I have to maintain some of our legacy applications that were written or previously maintained by these types. It amazes me to find bugs that are blatantly obvious and have been there for years. Or worse, when I go through the change logs and discover that one bad bug was replaced by another.

    Sorry for ranting for so long, but it's been building up. If I wasn't so hungry I could keep going on this one all day long.

    -- It appears that my spleeing chucker isn't working again.

    C stdlib on embedded platforms (3.33 / 3) (#43)
    by jfpoole on Fri Oct 06, 2000 at 05:03:53 PM EST

    The second problem is that in creating our application in C for our embedded platform we weren't able to use any of the standard libraries. So we have written our own to accomplish the task at hand. So now the new programmer not only has to learn how to program in a very restrictive embedded environment but they must also forget everything they already new about the standard library and learn ours.

    I've had to write C code on platforms in the past where C stdlib support ranged from weak to non-existent. The best thing to do when faced with the prospect of writing your own library is to emulate the C stdlib as much as possible. Sure, you don't implement the whole thing, but when you need functionality found in the C stdlib you implement it using the interface to said functionality from the C stdlib. Thus, when other developers examine your code its a lot easier to understand since they needn't run off and figure out what your new stdlib functions do. Plus the ramp-up time for new developers is a lot lower. I must admit I'm curious why your team didn't follow the same approach, as it's a fairly obvious win.

    [ Parent ]

    Re: C stdlib on embedded platforms (2.75 / 4) (#48)
    by h0tr0d on Fri Oct 06, 2000 at 05:26:46 PM EST

    Unfortunately, the team that developed the library for us was located out of state(not that this is an excuse) and they were fairly out of touch with this particular product. They also didn't think to allow the application development team to have any input. I think about 30% of the routines followed the C stdlib implementation and the rest were just sort of made up as they went along. In fact, there were a bunch of them that were the opposite of the stdlib. I was irate and managed to open my mouth on more than one occasion regarding this to no avail. In fact, after spending three months on development of a new application based on our new C implementation the project leader and I decided to scrap the entire project and start over in assembly. The entire attempt at C had been flawed form the beginning. Hopefully the company has learned from this mistake, although I highly doubt it.

    I was pleased to learn from one of the lead developers in another office that he is now leading the path to C in a more structured way and that a new C library is in the works that will be compatible with our proprietary os macros(something the other library lacked). I look forward to the day when we can get it all together in C. Until then I am more than happy to be programming in assembly. While it is not nearly as friendly as C I sure do like having such close control of the hardware. Thanks for your input.

    -- It appears that my spleeing chucker isn't working again.
    [ Parent ]

    Hmm. (3.14 / 7) (#18)
    by pb on Fri Oct 06, 2000 at 03:09:06 PM EST

    Programming languages often build on each other. Of course, a strictly theoretical background is useless if you want to actually do anything!

    After having known a few related tools and languages, (C, shell scripting, Unix utils...) and having stared at the examples in the past, I actually spent a day sitting down and learning Perl--reading through the book for 8 hours, and playing around with some example code. By the second day, I was more comfortable with it, but definitely needed work on my regexps. By the third day, I could start writing useful code, and rewriting bad code. I still kept learning and doing new things after this, but I'd say I learned Perl in three days, more or less.

    However, this would have been impossible without the familiar syntax, library calls, and functions. I'm sure that if I was coming from, say, a background in just Scheme, or Common Lisp, I would have been hosed. Or maybe writing obfuscated Perl with anonymous subroutines and recursion while jumping up and down saying "This is easy!" and "Where are my parentheses?".

    I'm glad I took those classes too, because I understand the value that interpreted languages can add. However, I'm glad I learned C first, because that's much more useful for the day-to-day system tasks, and generally faster, too.

    Also, your 'memset' example is excellent. It took me forever to find out what that was called in C; I was used to using 'fillchar' in Pascal. Reimplementing standard library functions just because you don't know about them is almost criminal, and certainly very sad. And in most programming classes, this sorry state of affairs is called "Homework". :)
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    The poll hit it right on the head... (3.50 / 10) (#19)
    by Luke Scharf on Fri Oct 06, 2000 at 03:11:13 PM EST

    I think the poll hit it right on the head -- "A minute to learn, a lifetime to master".

    In a weekend I learned enough Java to be able to read and write some basic Java code. It would take me months to become a good Java programmer.

    Bah. (2.75 / 16) (#20)
    by porkchop_d_clown on Fri Oct 06, 2000 at 03:30:22 PM EST

    A long time ago I stopped counting the number of computer languages I "knew". I remember that if you counted the dialects, it was approaching on 30, and I was still 23.

    How did I know so many freaking languages? Easy. They all fall into a few neat camps and, with minor differences, if you know one language in that camp, you know them all. The difference between C and Pascal is can be summed up in the phrase "pointers and strings". Modula 2? Pascal with some fixes, and an additional layer of code organization. C++? A bastard attempt to make a good low-level language into a CASE tool. Java? Java is the same concepts as C++, just done better. Performance sucks, but the coding is great.

    So, what else is there? Assembler? I've done the z80, the 65xx series, the 68000 series. I've even dabbled in IBM 370 assembler. no problem.

    What else? SQL, SAS, or Lisp? Done it, done it, done it. Rexx, Perl, C shell, Bourne shell. Forth, PostScript, APL. COBOL. ForTran IV, ForTran 77. BASIC? Let's see, TRS-80 Level I, II and III, Exidy, Facit, Apple, IBM, Commodore PET/VIC/C64 BASIC, Commodore Amiga BASIC.

    Show me a working program, a development environment (anything from a card punch to an IDE) and a manual, and I will be up and coding in a day.

    Do I remember the details of all these languages? No. Why should I waste valuable core on things I can look up when I need them? That's what documentation is for.

    People who think "clown" is an insult have never met any.
    Learning lanugages lets you learn languages (3.86 / 15) (#23)
    by zakalwe on Fri Oct 06, 2000 at 03:46:13 PM EST

    Bollocks - I'll say it. I can pick up a language, and reach a reasonable degree of competency in 3 days.

    Perhaps you're right in that it's not from computing theory that I gained this ability (In fact, I would have said this before even starting university) - its simply from actually using lots of different languages, from assembler to C to Python. After you learn a half dozen or so languages, it all just becomes a difference in syntax.

    OK I should probably backtrack here and say that I can learn a language of a similar style to one I know in 3 days. Learning a functional language when I only know imperative languages (or even if I only know one other functional language) would take a lot longer, but once you're used to the fundamental idioms, it's easy.

    Becoming an expert in a language is a bit different - knowing the constructs prone to error, common pitfalls and tricks and so on takes a few months ( and months of really using the language.) - but still, learning a language is trivial beside the other things you need to know to be a good programmer.

    Re: Learning lanugages lets you learn languages (3.33 / 6) (#28)
    by simmons75 on Fri Oct 06, 2000 at 03:58:35 PM EST

    To which I say the American equivalent--bullshit! =) You'll learn to program in another language in 3 days, but you'll still be coding for the other language. You won't be producing code that demonstrates competency; you'll be producing code that proves that you can dance around the syntax of a different language.
    So there.

    [ Parent ]
    Re: Learning lanugages lets you learn languages (3.00 / 2) (#44)
    by porkchop_d_clown on Fri Oct 06, 2000 at 05:08:18 PM EST

    You'll learn to program in another language in 3 days, but you'll still be coding for the other language.

    If you do that, then I know you're a lousy programmer. There are certainly people who do this; I've had to clean up after any number of them; but I would assert that they simply aren't very bright.

    There are certainly languages that, because of conceptual differences, are harder to grasp than others. I will admit that I stared at SAS for a week before I started being able to think the way SAS works. I suffered a similar pause when I first had to design (as opposed to code) in an OO manner. But there's certainly no "paradigm shift" between Java and C++ or between C and Pascal.

    People who think "clown" is an insult have never met any.
    [ Parent ]
    Re: Learning lanugages lets you learn languages (2.50 / 2) (#51)
    by zakalwe on Fri Oct 06, 2000 at 05:58:20 PM EST

    You won't be producing code that demonstrates competency; you'll be producing code that proves that you can dance around the syntax of a different language.
    No, I don't. Obviously this is just me saying that I don't - but then your claim is just as much an ad-hominim.

    For those 3 days - yes I will probably produce awful code - I usually learn a language by trying to implement something smallish ( about 100-200 lines). The first attempt will inevitably produce a mess of crappy code. But after 2 or 3 rewrites, I'll usually have a good feel for the language.

    [ Parent ]

    Think about the context (4.00 / 8) (#24)
    by SIGFPE on Fri Oct 06, 2000 at 03:48:44 PM EST

    People often make this claim in the context of a job interview and I think that it is often justified even if not strictly true. There is a certain mind set that a good software engineer can have that makes them able to pick up languages very fast - though not all of the details in 3 days. Frequently this is the kind of person that I'd rather hire even if they don't know a specific language that I need. I know that they'll be able to learn the language on the job and will probably be productive within a few days. I think that being able to learn many languages fast but superficially is a good indicator of the talents that I really require.

    Often computer languages have a 'point' that you have to 'get'. For example Prolog has one almost trivial idea that makes it work - backtracking. Once you 'get it' it's as if a new part of your mind has opened up. Even without learning the details you now have a new way of thinking about problems that you can apply even when programming in, say, C. Often this point is the reason why the author of the language created it in the first place. The same goes for Smalltalk, LISP, FORTH and many other languages. Often when someone says they can learn a language in 3 days it often means they have got this point and that they are able to adapt to the different ways to solve problems that different languages offer. Such a person can be a good hire.
    Book Recommendations? (2.12 / 8) (#26)
    by AndyL on Fri Oct 06, 2000 at 03:58:17 PM EST

    On a related topic,

    There are plenty of books about various programing languages, and various systems. Both "Teach Yourself X in Y days" and more serious in depth stuff.

    But could anyone recommend a good book on CS theory? I'm sort of hoping for some sort of reference book rather then a beginner's guide. Text books are a good start but it'd be nice if I had somewhere I could learn more information in areas I'm interested in. Rather then the little about everything I learn in school.


    Re: Book Recommendations? (3.50 / 2) (#32)
    by overcode on Fri Oct 06, 2000 at 04:22:08 PM EST

    "Structure and Interpretation of Computer Programs" is an excellent book. Knuth's stuff is also good, but it's less easy to read.


    [ Parent ]
    Re: Book Recommendations? (3.00 / 2) (#47)
    by frenetik on Fri Oct 06, 2000 at 05:18:06 PM EST

    I'd second that. It was our reference book in first year cs and I really appreciated the unpretentious style.

    If it's algorithms you're more specifically interested in, I'd recommend "Introduction to Algorithms", by Cormen, Leiserson and Rivest. Warning: It's quite a brick!

    Friends are like plants. They need attention and they need to drink. -- SPYvSPY
    [ Parent ]

    Re: Book Recommendations? (4.00 / 1) (#77)
    by sabi on Sat Oct 07, 2000 at 01:03:41 PM EST

    I learned a great deal about programming languages from Essentials of Programming Languages, by Friedman, Wand, and Haynes. Most of the rest of the class I was in hated it, but I really enjoyed the ability to play with a bunch of language paradigms, using functioning interpreters. It certainly didn't make learning new languages a great deal easier - right now I'm learning Smalltalk, and it has pretty minimal syntax compared to its capabiliities, but previous knowledge of practical languages (Scheme, Python, Objective-C, etc.) sure isn't hurting.

    Now I also am a CS PhD student, and am having a great deal of trouble reconciling the "CS is only about theory" and the "computers are tools to help people" views. So I'll probably end up doing operating systems or database research because I've had such dismal experiences with human-computer interaction and programming language theory (waaay too much politics and nothing getting done). Or maybe I'll get proven wrong, which would really make me very happy.

    [ Parent ]

    [Off Topic] Re: Book Recommendations? (3.33 / 3) (#35)
    by intol on Fri Oct 06, 2000 at 04:37:55 PM EST

    I don't know if this is what you are looking for but you may be interested in checking out "The Art of Computer Programming" by Donald E. Knuth. "Volume 1: Fundamental Algorithms" is probably my all time favorite CS theory book.

    The author assumes that you are reasonably good at mathematics. As I said it may not be what you are looking for, as it is a very intensive book, so it is a good idea to check it out before you buy it.

    Taken from the Jargon File:

    Knuth /ka-nooth'/ n.

    [Donald E. Knuth's "The Art of Computer Programming"] Mythically, the reference that answers all questions about data structures or algorithms. A safe answer when you do not know: "I think you can find that in Knuth."

    Take it from me, 'this aint' no beginners guide!' :o)


    [ Parent ]

    Re: [Off Topic] Re: Book Recommendations? (3.50 / 2) (#41)
    by jxqvg on Fri Oct 06, 2000 at 05:02:46 PM EST

    Just don't buy all three existing volumes right away, like I did. It'll cost you extra money, and you won't get to volume 2 for at least a decade, anyway.

    [ Parent ]
    Re: Book Recommendations? (3.33 / 3) (#38)
    by Pinball Wizard on Fri Oct 06, 2000 at 04:47:44 PM EST

    Try these -

    Knuth - Art of Computer Programming
    Erich Gamma, et. al - Design Patterns
    Steven S. Skiena - The Algorithm Design Manual

    [ Parent ]

    Abstractions: Knowledge vs. Metaknowledge (4.51 / 33) (#29)
    by rwc_2001 on Fri Oct 06, 2000 at 04:09:20 PM EST

    I have been making a decent living the past nine years as an indepedent contractor. There is no predicting what language, platform or problem domain my next client will throw at me.

    As a result, I can honestly say I am expert in no languages, but am competent in just about all of them, including odd ones I've never seen.

    How can this be? Simple: I forget the details (domain-specific information and knowledge) and cling tightly to the abstractions (metaknowledge, theory, experience). I try not to get caught up in the details of a specific language or tool set, but try to know how to evaluate and use the salient features of each one I encounter.

    How does one gain this capability? Read. Read everything you can get your hands on. Forget the details, remember the concepts. I subscribe to five trade publications, six journals, and I purchase the proceedings from several conferences each year (though I seldom attend). I read all the time.

    When an unfamiliar concept presents itself, I will often detour and "play" with it for a while, but only to get an overview, and not to master it.

    It is like remembering the table of contents and index of a book, and throwing away everything in between. If you have those two things, you can always go to the book and look up what you need, when you need it. There is no need to keep it permanently stored inside your head.

    I do, however, have one general purpose tool I cling to quite tightly: MathCad. Within MathCad I can explore a problem deeply, model whatever I need, develop useful proofs, algorithms and heuristics. Once I know HOW to solve a problem, then I can construct a high-level design and start to formulate a plan of attack.

    I'm still tool-independent at this point, and largely platform-independent. Once I know what needs to be done, then I can find and evaluate the tools needed to implement that design. I consult tool experts to ensure I use the features I need, and seldom spend my time mastering any particular tool. I solve problems and implement solutions.

    This approach even works when maintaining legacy systems, since it clearly separates the problem from the domain. Sometimes I need to reverse engineer the present system so that I may build a MathCad model. That process allows me to advise the client of the REAL costs involved, well before the implementation work begins. It also allows me to use radical, non-obvious implementation strategies.

    It all depends on the design process. Waiting until implementation, or relying on implementation expertise, seldom does anything to guarantee success!

    As proof, I once hired high school students and college freshmen to implement one of my designs. They were far from experts in any way. Yet they did the implementation quickly and effectively, with only occasional mentoring from me. I implemented only that code where the design has too many platform dependencies (where, for example, the quality of a math library was critical).

    Too many "professional" software engineers do their design work in a code editor. Those who are domain experts can sometimes get away with it. But that does not make it the "right" way to implement a project. To many designs are nearly useless, simply because too much emphasis has been placed on implementation tools and platforms, and not enough empahsis has been placed on developing useful abstractions and a quality design.

    I view nearly all programming tools as the "tools of Satan". They are necessary evils. The have the downside of deluding the programmer that learning the tool is equivalent to learning programming. Nothing could be further from the truth. Programming is the LAST step in the process! If all the prior steps are properly executed, then the programming itself will be trivial, and any newbie should be able to implement a quality design.

    I have used many languages on many projects over the years: Assembler (for at least 11 different processors, including CISC, RISC and DSP), Ada, C, C++, EC++, PL/M, Prolog, Forth, Mumps, Fortran, Postscript, Lisp, Smalltalk, Jovial, Pascal, and several others I can't recall (not to forget about a dozen or so scripting languages). I have used just about every development tool set available on the market or via Open Source (including editors, IDEs, compilers, debuggers, repositories, etc.) on just about every development host workstation imagineable (WinXX, SGI, SUN, HP, IBM, etc.) and for a vast range of targets (from 4-bit CPUs to 1K CPU arithemetic vector arrays and full-custom processors implemented in FPGAs and ASICs).

    Clearly, it is absoltely hopeless to even think this much domain-specifc knowledge could ever be retained in a single skull (especially one as small as mine). If I were unable to rely on my knowledge of theory, my ability to abstract both the problem and solution domains, and my ability to craft a decent design, I would never be able to make a living doing what I do.

    The only other alternative would be to specialize to the point that I can retain everything I need within my own skull. And that, to me, is a very limited and boring state of being. Yet that is exactly what most programmers pursue with total dedication (and tunnel vision, IMHO).

    Yes, it is scary walking up to a language I've never before seen, much less even heard of. But it is just another tool: There are books and documentaiton available, and domain experts (with blinders intact) I can call upon when needed. The same applies to platforms and other tools.

    But it does not apply to problem abstraction and solving, nor does it apply to the crafting of a usable and workable design (independent of the design tools used). These areas MUST be mastered. All others can be looked up as needed.

    There is one additional skill that is useful for climbing the tool learning curve faster: Properly using online documentation and search tools (any regexp engine). My first task when encountering a new tool is to learn the "description language" used to document that tool. Every manufacturer seems to invent their own words and meanings to describe what their tool does. Learn that language, and you have truly learned much of the tool. So, of course, I read the Table of Contents and the Index first, just to collect words. If there is a glossary (a very rare thing), I read that first of all. Once I know all the terms for all the major features and concepts, and I can craft expedient searches to get access to the details I need.

    Just look at the terms used to describe vi compared to the terms used to describe emacs: Very different! And they are both basic tools on the same platforms. Toss in additional tools and different platforms, and the "description language" problem grows as well.

    This "description language" is just metaknowledge. Knowing that different ones exist and how to master them is "meta-metaknowledge".

    In all areas of Computer Science, it is the theory, the metaknowledge, and the meta-metaknowledge that matters. Toss in some basic experience, and new tools become repetitive exercises.

    It is more important to know where the domain-specific expertise is, and how to use it, than to acquire it for yourself. For example, I never let a domain expert actually implement any part of my systems: I use them only for their knowledge, properly abstracted, and never for direct implementation. That is, I use them as advisors, teachers and mentors, not as implementers.

    Tool expertise is vastly over-rated! Only a few tool "gurus" are needed: The rest of us should be able to abstract nearly all of our work away from the tools.

    Yes, I am certain we all should be tool- and platform-independent, to the greatest extent possible.

    At least, it sure works for me.

    Metaknowledge is the key! (4.16 / 6) (#73)
    by flieghund on Sat Oct 07, 2000 at 03:55:33 AM EST

    An excellent term! I have a perfect tract record of learning new programs in a day or less. Why? Because, as rwc_2001 points out, I don't bother learning a specific program to an "expert" level (though there are some that I have chosen to specialize in). Instead, I like to think that I have a general, "higher-level" understanding of how most programs work, so it is only a matter of familiarizing myself with "which button to click" or "what command to type" in order to use an unfamiliar program. Example: though I know Photoshop very well, I can easily transition to other graphic editing programs (raster or vector) because I don't rely on looking for a paint bucket icon to execute a fill -- I know I need a fill command, so I find what icon represents that and use it. It can be very subtle, but it really helps when you are thrust into an unfamiliar setting. Same thing can be said for operating systems -- learning basic concepts of how/why OSes work is much more valuable (IMHO) than learning the complete command set for DOS.

    (OT sub-rant here: this is probably what kills linux adoption for the average home user. For example, they don't know how to use a word processor program -- they know how to use Microsoft Word. They lack any kind of metaknowledge, so they are completely incapable of switching to a new program without massive retraining. Multiply that by three or four core programs -- Word, Outlook, IE [don't laugh, I know people who can't use Netscape because the buttons are in a different order; I know these people shouldn't even look at a computer], Excel -- and no one is willing to switch. It appalls everyone I know who knows anything about computers, but it is also frighteningly true. Another example: couple-eight years ago, my mother took a DOS class. She knew more about DOS than most CS majors I know, but most of that knowledge is completely wasted because now she uses Windows 98. She has no metaknowledge about operating systems, only specific knowledge about DOS...)

    I think metaknowledge is what a CS education is really good for -- teaching, or at least trying to teach, students how to think more abstractly about programming so that picking up new languages in the future is easier. (This coming from an architecture graduate; the closest I have come to a CS course is a not-for-degree-credit introductory C++ class, but I know a lot of (former) CS majors, so this is only a semi-informed opinion.)

    Everyone seems to be clamoring for more "practical" training -- but have you ever asked any old-school programmer types who were trained in a relatively archaic langauage (I dunno, maybe COBOL?), usually at the expense of theory, how practical that training is today? Sure, you could be taught C++, or Java, or some other such language, but ten years from now you could be SOL because some other language has become the "standard."

    "Give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for life." A CS education (or any quality secondary education for that matter) strives to teach you how to fish, so you can fend for yourself in the future rather than relying on a base of specific and static knowledge. It attempts to impart a level of metaknowledge to students such that they can go forth and learn whatever langauge suits their situation best.

    Again, this is coming from a non-CS person, so maybe I'm just grossly misinformed. But I would think it sucks more to be forced to learn a specific language that you will never use at the expense of learning how/why that general type of language (OO, OB, lisp, etc.) works the way it does. The latter type of knowledge -- metaknowledge -- seems to be much more valuable information and something that would be difficult to learn without the guidance of someone who already knows what they're doing (read: professors, older students, whatever).

    Q: Why can't you use the same debugging techniques for Java that you use for C++? A: Because sacrificing a goat isn't platform independent.

    Using a Macintosh is like picking your nose: everyone likes to do it, but no one will admit to it.
    [ Parent ]
    Re: Abstractions: Knowledge vs. Metaknowledge (1.25 / 8) (#80)
    by delmoi on Sat Oct 07, 2000 at 08:50:52 PM EST

    Wow, that was really long
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    Uhh No! (3.60 / 5) (#31)
    by logicnazi on Fri Oct 06, 2000 at 04:21:53 PM EST

    Okay first it certainly is possible to learn a language in three days. I know this because I learned common lisp in about three days. Did I know every function in common lisp...or even correct macro definition? No but I was at a level where I could produce workable, and not exceptionally ugly code. Once past this initial barrier my understanding grew as was necessery..if I needed a function I checked my reference book (yes sometimes it was a little difficult to find the appropriate function name but even in common lisp with thousands of functions it wasn't that bad). Furthermore this is the appropriate (and possibly the only) way to properly learn a language.

    I have had classes in pure programming before (not theory) they are boring and excedingly useless. Presenting elements of the language when you don't need to use them is about as efficent as reading the dictionary. None of these concepts sink in until you actually program with them, This makes the class superflous as a book can present you with the syntax just as well and you are doing your learning on your own at your computer anyway.

    But if it is a waste of time to teach programming in a CS class what are the colleges doing? Well in many cases you are correct...many programmers (especially the less skilled ones writing simple code) would be much better served going to a *technical* school which assigned them various coding projects. The lack of this is NOT the professors or the colleges fault it is the CS majors who don't want the ego blow it would be to attend a technical school. In this country attending a technical school is in many ways considered inferior.

    However, I do not believe this is the case for all programmers. Those programmers who are going to be writing complicated hard code need the algorithmic end. Moreover the intellectual excercise involved in the computational side which you lambast makes them smarter people. The training in proper thinking will spill over into their coding ability. In addition these students will be able to learn the language on their own.

    Furthermore CS university provides a selection critera for potential workers. If all everyone did is produce code it might be very hard to tell prospective employees apart (sure he created everything they told him to but is he a whiz able to do it in five minutes or did he slave away all night every night). However the computational program in its greater abstraction provides a much better litmus test of applied intelligence.

    Re: Uhh No! (2.66 / 3) (#37)
    by B'Trey on Fri Oct 06, 2000 at 04:46:01 PM EST

    I think we're getting hung up on the definition of "learn a language."

    If you're a competent programmer, you can pick up a new language rather quickly. Once you understand the structure of a basic statement, loop constructs, how to create and call functions and procedures, and get a feel for the underlying philosophy of that particular language, you can start to write usable code in that language. You can usually do this in a few days with a bit of effort. The question is, does this level of proficiency qualify as "learning the language?" I tend to agree with terran - learning a language involves more than just being familiar with basic syntax. I think if I were an employer, I'd certainly feel this way.

    [ Parent ]

    Think about the context (3.62 / 8) (#36)
    by SIGFPE on Fri Oct 06, 2000 at 04:39:44 PM EST

    People often make this claim in the context of a job interview and I think that it is often justified even if not strictly true. There is a certain mind set that a good software engineer can have that makes them able to pick up languages very fast - though not all of the details in 3 days. Frequently this is the kind of person that I'd rather hire even if they don't know a specific language that I need. I know that they'll be able to learn the language on the job and will probably be productive within a few days. I think that being able to learn many languages fast but superficially is a good indicator of the talents that I really require.

    Often computer languages have a 'point' that you have to 'get'. For example Prolog has one almost trivial idea that makes it work - backtracking. Once you 'get it' it's as if a new part of your mind has opened up. Even without learning the details you now have a new way of thinking about problems that you can apply even when programming in, say, C. Often this point is the reason why the author of the language created it in the first place. The same goes for Smalltalk, LISP, FORTH and many other languages. Often when someone says they can learn a language in 3 days it often means they have got this point and that they are able to adapt to the different ways to solve problems that different languages offer. Such a person can be a good hire.
    Halelujia! (3.66 / 12) (#46)
    by BOredAtWork on Fri Oct 06, 2000 at 05:17:33 PM EST

    Someone else with some sense speaks up! You just made my day.

    I'm in my 6th semester (out of 8) of work on my Computer Engineering degree at Virginia Tech. To graduate with a CpE degree here, there are five required "programming" classes. Those who chose to focus on hardware development don't take more, those who opt for a software focus do.

    < begin rant >

    The first class (generic disclaimer: this class has been revamped 3 times in the past six years. I had the "2nd edition" of it. It may be better now...) was an unmitigated disaster. It was called "Introduction to C++ for Engineers," and was taught by a CpE faculty member who had no interest in being there. This was THE first exposure most CpE's had to programming (luckily I taught myself in high school). The first two weeks of discussion centered on the "object oriented philosophy". We "learned" lots of vocabulary words like inheritance, polymorphism and recursion, and drew lots of pretty pictures called class diagrams. All this, before learning that a ; must be the last character on a line. Before seeing our first pair of {}'s. When it came time to learn syntax, we were shown a few overhead slides, and told to read the textbook. About 1/2 of the students in that class either dropped the major, or failed. The other half passed with flying colors, having no idea how to implement a linked list or protect against multiply included headers.

    The second class was Introduction to Data Structures and UNIX. This one was also taught by the CpE department, and I thought it was great. Most people hated it; it required telneting to an SGI to do homework. The course had previously required an installtion of Slackware, but the professor was pressured into removing that requirement by the department higher ups, after too many students complained. The class assumed a working knowledge of C++, so most were students were SOL. The only students who got something from this class were the ones who had taught themselves C++ previously. The rest were lost.

    The third and fourth classes were taught by VT's CS department. Object Oriented Programming, and Data Structures. Both assumed that working knowledge of C++, and both professors outright refused to answer syntax questions in class, because "I'm here to teach concepts, not symantics." The professors of both classes just used projects and homeworks assigned by others in the department, and the second didn't even bother to read the specification for the projects; he just assigned them, and told us which teaching assistant to submit them to.

    The fifth class, and one I'm enrolled in now, is killing people. It's Operating Systems, also taught by the CS department. It requires an install of 2.2.x Linux system. When people whined about this, the professor (Dr. S, congrats on being the first decent CS professor I've seen, even if you are incredibly anal about grading the project documentation) basically said that he'd help as much as possible, but there's no way in hell you deserve to pass an operating systems class without being able to install an operating system. The class assumes a GOOD knowledge of C and C++. There are people in this class, people with GPA's of > 3.0, who have NEVER used a printf statement. They're fading fast, and it's only the 2nd month of school. It's scary. I give tons of credit to the professor for forcing these folks to learn the material or retake the class; and for answering hundreds of easy syntax questions with patience over and over again. It's a shame that he should have to by a student's third or fourth year, however.

    The CS department here emphasizes theory and principles over practicality, and the CpE department hasn't been much better (although I've seen the syllabus for those two CpE classes I mentioned, and it looks like they've been MUCH improved). One can graduate with a 3.5 here, and not ever have seen K & R's "C Programming Language". Theory is wonderful and all well and good, but if one isn't taught how to do anything practical with that theory, it's all useless. Personally, I think the most effective way to teach programming is to start with basic sequential hello-world stuff, and progress to functions, loops, ifs, and eventually object oriented features. You've gotta start with the small stuff to be able to understand the big stuff, and in my opinion, way too many schools just don't think that way.

    < /rant >

    Re: Halelujia! (2.75 / 4) (#54)
    by pb on Fri Oct 06, 2000 at 06:10:39 PM EST

    Wow; I'm in an operating systems class at NCSU (CSC451), and K&R (well, ANSI--it's the second edition :) is our Bible. Also, we have "The Design of the UNIX Operating System", by Bach, for other system implementation details.

    In fact, I should be working on a little Minix-like filesystem right now. Oops! :)

    But yes, the quality of individual courses is often spotty and inconsistent. The other great course I've had here was CSC201, (x86 Assembler) which is entirely because of the teacher; CSC202 (threads and stuff...) was horrible, again just because of the teacher; that makes a huge difference.

    Most of the other courses I can take or leave, and about half of them are at least somewhat theoretical, if not entirely so. I think it's a good mix, but I'd like it if all the actual math courses were in the math department; some of them seem to sneak over into CSC...
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]
    Re: Halelujia! (3.00 / 1) (#86)
    by luethke on Sun Oct 08, 2000 at 05:08:02 AM EST

    The CS teacher who said he is teaching theory in class I think is more correct. At a 3000 or 4000 level course systax should be assumed during lectures. syntax should be taught in the lower classes, after all what theory are you going to be able to handle in "intro to computer science". Catering to the lowest skills in that environment (upper level courses) is bad. He should be willing to spend office hourse going over syntax, at that point it should be individual attention. Lets face it, when you go get a job they are going to give you a project and it is YOUR responisbility to learn the syntax of the language (at least in most cases I know). You will be givin those nice little pictures that are theory and you better damn well be able to change that to code. Also part of a teachers job is also to tell a person if they should go do something else. They do this both by giving difficult assignments (espically in high level courses) and possibly by flat out telling you this. I think oo programming and atastructures is theory. they should teach the algortihm for a stack, queue, or what ploy-morphism and encapsulation are, not c++, c, or any other specific languages idea of one, in this case it is best to learn the base, then get specific for an implementation of a language. That being said a teacher can still be unfair, I have done bad in classes where it's a bad teacher and where I just should not have been ion the course. The thing to look at is how are the other students doing (not comlaining, most people, including me, will complain if they are making 98 in the class). If the majority of the class is failing (ie one of my calc II classes I droped the average grade after two tests was in the 40's out of a 100) or is the average acceptable (should be no less than 75, anything higher and the class is easy). if you are doing bad in the first instance, drop the course, never take a class with the teacher again if possible. If the second, then rethink staying where you are. And yes I know this is not 100% accurate but it has been a fairly good indicator in my experiance.

    [ Parent ]
    learning ADA in 3 hours (1.16 / 6) (#50)
    by toddmilburn on Fri Oct 06, 2000 at 05:34:37 PM EST

    I had to do a simple testing program to test a fraction package in ADA and I didn't get my ADA compiler (GNAT for linux) installed until 11 at night before the program was do... It took longer than 3 hours to just figure out syntax for everything, and a little bit more to figure out how to work with the types let alone learn anything truly useful and differentiating about ADA...

    programmers and hackers (2.25 / 4) (#52)
    by cynessis on Fri Oct 06, 2000 at 05:59:31 PM EST

    I think that first the distinction must be drawn seperating 'programmers' and 'hackers'. In most CS classes that I have been in it is clear who is in the class to earn a fat paycheck and who is in the class because of love of the code. In addition I think most of the material taught in university CS classes is significantly over rated. I don't have the greatest programing skills in the world but when I walk into the local university bookstore to pick up a book for some class I find it funny to look over at the CS section and see books for 300 level CS classes that I used to read in highschool. I personnally believe that a competent person with enough O'Reilly books and Coffee can aquire the same amount of knowledge than any 'non-hacker' programmer with a BS in CS.


    Re: programmers and hackers (4.00 / 3) (#70)
    by 0xdeadbeef on Sat Oct 07, 2000 at 01:03:21 AM EST

    I think you've really nailed what this debate is about. The "school is a waste of time" crowd hold up the image of the cocky wanna-be who's in it for the money as their proof (when in fact, these people generally don't last beyond their first semester at the better schools). The "no amount of talent will ever make up for a lack of proper education" crowd (of which I'm a part) present the image of the cocky wanna-be who skipped college and thinks he's a 1337 hacker because he's making 50k writing ASP scripts (when in fact there are lot of people with real skill who never finished college).

    A person with natural talent and a strong motivation to learn will do well with or without a degree. I simply believe that those without a degree have severly limited their options, not by nature of missing a piece of paper, but by not experiencing the mind-expanding joy of spending several years with the free time to learn what is interesting rather than what is marketable. It also gives you plenty of time to hone your skills before you enter the real world.

    300 level? You mean stuff like this and this? Wow. I was reading "Mastering Turbo Pascal" in high school and I thought I was kewl shit. :-)

    [ Parent ]

    Re: programmers and hackers (3.33 / 3) (#79)
    by hardburn on Sat Oct 07, 2000 at 07:18:49 PM EST

    I'm of the "school is a waste" line of thought. I will be attending a two-year technical school, however, for purly pragmatic reasons (way too many employeers actualy care if you went to college).

    My Grandpa (who's been doing computer work since the 1950s) also thinks this way. When he is given chance to hire some new employees for the IT department, he'll often interview CS major after CS major. Full of cockeyness, knowing nothing. I had one person explain to me that these people were newbies and should be expected to need more training. THEY JUST CAME OUT OF COLLEGE. THEY'RE NOT NEWBIES, OR AT LEAST SHOULDN'T BE.

    So the CS majors were largely overlooked by him and went for the self-taught hackers. However, most employers haven't taken my Grandpa's advice and require a degree. Despite my feelings that there is good reason for two acronyms being spelled "BS", I really do need a job, and it might as well be in computers.

    Another story from my High School CS class last year: The teacher was looking at a catalog that had special prices on software just for schools. He was no fan of Microsoft, but he noticed that Microsoft sold MSVC++ really cheep. He also knew quite well that the reason for this was that MS wanted to get new CS students used to the VC++ IDE, thus getting more sales later. However, he still got that compiler because there was nothing in the budget for anything more expensive.

    I told him he could use DJGPP on the Windows 95 machines that were in the computer lab for free. The response from another CS student (another hacker) said that it wouldn't happen because nobody wants to use a command line. Now, if you can figure out C pointers, OO programing, arrays, data structures, etc., what is so hard about adding "command line usage" to that list?

    Nothing, except that nobody uses CLIs in corperations, which is the whole point of being in in a CS class, right?

    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

    [ Parent ]
    Re: programmers and hackers (5.00 / 3) (#82)
    by mpeever on Sat Oct 07, 2000 at 10:45:15 PM EST

    That is really cutting to the crux, but there is another unstated assumption in these arguments: that education's purpose is to prepare one for a career. Education may help in a career setting, but that was not why we created the educational world.

    My degree is completely unrelated to my job, but that does not make it irrelevant. Solving n permutations of Schroedinger's Equation may not be related to running a Unix network, but it has done wonders for my ability to see through a problem to the root cause.

    So my education helps me a lot at work, but that's not a very good reason to have gone to school. The four years of experience that I missed when I was in school would have helped too.

    University ought not to be about career preparation, but about intellectual growth and expansion. It's pathetic how many "College is a waste" people really can't seem to reason in any form of a straight line. That's what University is about. This may or may not affect their job competence (although in my short time I've observed quite a few problems that would have been circumvented if people would only think).

    So many posts here and at the other place reveal a good deal of [presumably] talented programmers/sysadmins/etc. who have no ability to form an abstract thought... and abstraction is what algorithm development is all about. (BTW, my code always sucks... even when it works: ) )

    The political/philosphical rants put out by many talented people are absolute trash. Not because they're wrong, but because the arguments are invalid.

    So a class in symbolic logic won't make you a good programmer, neither [probably] will a class in programming. That requires effort, talent, and experience. It's a skill, and skills are learned through practice. They may well steepen your learning curve, deepen your perspective on the problem you're trying to solve, or give you a more clear understanding of the solution. But even that (as good as it is) is not the reason to take them. The real reason is to expand your mind by disciplining it to work properly. That's what education is all about.

    Who knows, some formal education might actually make some on-line rants a little more enjoyable too.

    "Assertion is not proof" -Erasmus
    [ Parent ]
    I've thought about this. (3.60 / 5) (#56)
    by mindstrm on Fri Oct 06, 2000 at 06:18:11 PM EST

    There are quite a few general misconceptions about CS and how it relates to modern computer 'technical' work.

    CS, in many cases, stands for 'Computing Science' and not 'Computer Science'. The Science of computing. Mainly, Algorithms. How do you automate, well, anything? That's what it's really about. How do we use computers to help us advance in science?

    Now, the design of a computer.. that's not computing science at all, that's EE! (electrical enegineering).

    Also, there are many types or levels of programming. Certainly, to test out certain theoretical algorithms, an appropriate computing language helps to test it. But the computer scientists is not the one who designs, usually, the final high-speed product; he's the one who figures out the algorithm and demonstrates that it works.

    Lots of programming is also more like mechanics. Many programmers are similar to the guy who fixes your car. They know their tools and the environment they use them in, and know them well. Also, they are good at learning new tools.

    There is certainly overlap between EE, CS, programming, and general computer skills, but they are also all separate beasts.

    Learning Programming Languages? (1.16 / 12) (#57)
    by DJBongHit on Fri Oct 06, 2000 at 06:28:04 PM EST

    Never mind 3 days - the only programming language that took me more than 1 day to learn was C, and that is because it was my first language and I was 9 years old. When I was 15 I taught myself Java in 2 hours and by the end of the day had a fully-functional GUI email client, complete with PGP-signing and attachments. From scratch, using nothing but standard language features like sockets. Last year I taught myself PHP and MySQL and within 2 days had a complete Slashdot-workalike web log. A few days later, I taught myself Perl in a day and the next day had another version of the web log written entirely in Perl. I have similar stories for Pascal, Lisp, and Tcl.

    And here I am dropping out of college.


    GNU GPL: Free as in herpes.

    Less than a day? Big deal. (3.00 / 8) (#61)
    by lazerus on Fri Oct 06, 2000 at 09:09:54 PM EST

    Ah, in a lot of ways you remind me of a less advanced version of myself. I started younger than you, however, learning my first language at the age of 3 - Assembly on an old Apple II.

    I taught myself FORTRAN, BASIC, C, Perl, PHP, Python, C++, Modula, INTERCAL, COBOL, Visual Basic, Java, Ada, Pascal, Assembly for 15 different architectures, Ruby, Shell scripting, Novell scripting, Smalltalk, Squeak, most variants of SQL databases, javascript, coldfusion, Effeil, Basicplus, NetBasic, Rebol, Lisp, Scheme, Logo, Haskell, C#, PL1, TCL, AMOS, DataBasic, Delphi, Prolog, Eclipse, Clipper, REXX, AREXX, Objective C, Dylan, Algol, SNOBOL, RPG/400, Clarion, Adabas, ABAP, AppleScript, VBScript, VBA, Amiga-E, Pike, Verilog, Occam, FORTH, Oberon, AML, APL, ADL, Blue, Bigwig, Pliant, Spanner, Brain, Component Pascal, DOS Batch, Elf, Emerald, Slim, Self, Leda, JJ, IDL, FoxPro, Yorick, Charity, Omega and ABC --- In under 2 hours each.

    It's not that hard if, like me, you read 2 pages in 5 seconds and have a photographic memory, as well as a mathematical mind capable of taking on a modern computer in terms of floating point calculations.

    [ Parent ]
    Re: Less than a day? Big deal. (1.25 / 8) (#66)
    by maketo on Fri Oct 06, 2000 at 11:39:00 PM EST

    But I bet you dont know how to write Word macros.
    agents, bugs, nanites....see the connection?
    [ Parent ]
    Re: Less than a day? Big deal. (1.00 / 11) (#68)
    by plastik55 on Sat Oct 07, 2000 at 12:14:58 AM EST

    Your petty boats will be meaningless when you discover that I am GOD.
    [ Parent ]
    Re: Learning Programming Languages? (3.33 / 3) (#69)
    by aphrael on Sat Oct 07, 2000 at 01:00:02 AM EST

    One of the things that i've found to be true is that, while the general syntax and semantics of a language can be picked up in a couple of days, there are niggling details which, a year later, i'm still getting. When I got forced by my job to start programming in pascal roughly 16 months ago, the switch from c++ was trivially easy; yet there are still corners of the language that i am confused by, and there are frequent times when i look at code i wrote a year ago and am struck by how ... wrong it is, not just in the sense that i'm a better programmer now than I was then, but in the sense that the dialectal nuances of the language that I understand now were just totally lost on me then, and my code did something which was technically legitimate but stylistically wrong.

    In this, learning computer languages is like learning human languages: even if you get the syntax and semantics *down*, there are still idiomatic differences between the languages which can take years to get correct. Which leads to an interesting question: at what point can you really say you know a language? I claim to be fluent in German, aber gibt es viele Buecher die ich gar nicht verstehen kann; kann ich dann das Deutsch sprechen, oder nicht? In the computer realm, I can write functional perl programs, but not good ones; do I know perl?

    I submit that the process of learning a language is, in some sense, never finished.

    [ Parent ]
    Re: Learning Programming Languages? (1.10 / 10) (#71)
    by Linus Torvalds on Sat Oct 07, 2000 at 01:13:10 AM EST

    Oh yea? I am Linus Torvalds. Top that, you cocky bastard! ;-)

    [ Parent ]
    Re: Learning Programming Languages? (1.20 / 5) (#93)
    by Ken Thompson on Sun Oct 08, 2000 at 02:09:05 PM EST

    Yeah? I'm Ken Thompson. So shove it. ;^)

    [ Parent ]
    Re: Learning Programming Languages? (3.00 / 1) (#85)
    by luethke on Sun Oct 08, 2000 at 04:45:56 AM EST

    Wow, you read and understood the entier java doc in 2 hours, man you must read at something like a 1000 words a second or more and have phenominal memory. I suspect it is more like when I "learned" perl after know c and c++ for several years. I wrote junk like

    open( FILEHANDEL, "file.tx" );
    if( !FILEHANDLE )
    print( "could not open file.tx\n" );
    return 0;

    unfortunatly while that is sytactically perl it is not they way that would normally be wrote in perl, whic would be:

    open( FILEHANDLE, "FILE.tx" ) || die "can not open file.txt"

    ( of course the above is assuming no syntax errors, as I am dyslexic it is very difficult for me to keep a lot of them out and depend on the interpreter to catch them, makes me hate PERL with a passion but it is too usefull to not use ) In the end I don't consider my self "knowing" perl for several moths even though my first perl program was a fairly large program (a multi-user online ordering system). the code I wrote at the first of the project was noticly different from the last. I'm still not sure I would count myself as knowing PERL or not.

    [ Parent ]
    10 days. (2.00 / 7) (#58)
    by your_desired_username on Fri Oct 06, 2000 at 07:05:55 PM EST

    I can learn a typical staticly typed language in less than 10 days. (I might take longer with a lisp variant - but elisp took me only 2 days.)

    Did I learn that skill from studying language theory? Yes.
    Do most CS grads learn that skill in university? No.
    The average student understands less than 10% of the material he is exposed to.

    How soon we forget (3.57 / 7) (#59)
    by DesiredUsername on Fri Oct 06, 2000 at 07:51:35 PM EST

    "The hard (or at least time-consuming) part of learning a programming language is not in the basic theory. It's in learning about the functions (or standard library) that the language provides."

    Only someone who learned how to program VERY early in life or has a VERY poor memory of when they didn't know how to program would think this is true.

    Designing algorithms is hard. Heck, most people can't even accurately and succinctly describe the problem, let alone come up with a solution. Don't you remember when you first learned to program. The cry goes up "what do I do first??", "how did you know to divide there??"

    Furthermore, the accessibility of the contents of the standard library is not a function of the language. It's a function of the development environment. Imagine you had two books: One listing all functions by name, one listing all functions by "general purpose" (network, filesystem, etc). With just these two volumes you can look up anything you need to know. Now take away the books, but keep using the same language. Developing is now harder, but the language hasn't changed--the docs are the obviously the controlling factor.

    I mean, think about it for a second. The "backstage" area of a sports arena is often hard to navigate. Does that make the hardest part of football "figuring out where the lockerroom is"?

    Play 囲碁
    Re: How soon we forget (3.25 / 4) (#65)
    by bgalehouse on Fri Oct 06, 2000 at 11:36:41 PM EST

    There are different types and styles of 'programming' even within a language. cgi scripts in C are one thing, secure cgi scripts in C are another :-), garbage collection systems are yet another, kernels are different yet. Sometimes syntax is the most important part, sometimes it is the last thing you need worry about. No one line of the linux kernal is hard to read if you know C.

    Some people really can adapt to a new language in a few days, sometimes the standard libraries are sufficiently well documented and indexed that they can code normal stuff in that time. Some people will never be able to do that, but will still make perfectly good coders. The penalty is that the faster you learn a language, (and associated tricks) the faster you might get bored with it, but I digress.

    I went to CMU, and minored in CS. When I started, they were listed at the top in the nation for CS by whatever magazine it is that does such things. They required a certain amount of theory and math, but they also had no-nonsense project courses. The killer was Operating Systems. They changed the units that it counted as from 4 to 6 while I was there. Didn't change the workload though; they just decided to be a little more honest.

    Thing was, even at that level, there were differences in the people. OS allways had two projects, first half semester: write a unix-like kernel (processes, etc), second half: write a filesystem for the kernel.

    I met a friend in the computer center one Sunday evening. He looked like he had been there a while. Said that he had put 40 hours into his kernel that weekend. He was splitting the work with a partner (this was allowed).

    Later in the semester, I met a second friend coming back from campus one day. He looked pretty drained. Explained that he had just spent the entire day writing his filesystem. Said it was mostly working, or something like that. He didn't work with a partner.

    Practice makes a difference. But it can't allways compete with talent. So figure out where you most need to practice, and quit worrying about where other people do :-)

    [ Parent ]

    Alternatives to 4 year degree. (3.20 / 5) (#62)
    by delver on Fri Oct 06, 2000 at 09:25:45 PM EST

    At my University of choice, there is a program that I'm currently participating in. Its called elements of computing. It offers a education in programming (starting with Java, and later moving to C++). Although its under the CS department, it doesn't have the same requirements and is intended for non-cs majors. You learn programming and algorithims along with a decent amount of meta-programming skills. For someone who just wants to code, its a good alternative to a 4 or 5 year degree. It takes like 2 years. All you get is a certificate, but its something to add to your resume.

    Best of both worlds (4.50 / 10) (#74)
    by Boojum on Sat Oct 07, 2000 at 05:40:37 AM EST

    There's been a lot of debate between those who are self-taught and those who study C.S. in school. From my own experience, I think that it's possible to have the best of both worlds.

    I was a self taught programmer who learned quite a number of programmers over the years before I entered college and started for a C.S. degree. I could write some fairly complex programs and had no problem churning out code.

    Since I've been here though, I've learned a lot of theoretical computer science before. Some of it was new to be. Other stuff was things I had seen before, but might not have really grasped. But since I've been here, I've had to learn a lot of the theory behind.

    As a result, my programs have gained a certain sophistication and polish. They run faster and take fewer lines of code. They are simply more elegant. For example, for a networks class, I once had to write a robust unframer for a simulation of a network datalink layer. I applied the Knuth-Morris-Pratt algorithm that I had learned in my algorithms class to generate the basic part of a deterministic finite automata. (Which, incidently, I learned more than I ever wanted to know in the automata and computing theory class.) I was then able to incorporate that in a larger DFA that I was hand crafting. The result? The main loop of my unframer was about five lines long, ran like a bat out of hell, never needed to back track and required only a small buffer to hold the decoded packets.

    What's my point? Self teaching and college courses are not mutually exclusive. A good college C.S. program will refine and polish the skills of an already competent self-taught coder by teaching the theory that drives the code. Both are important.

    Re: Best of both worlds (3.80 / 5) (#91)
    by blaine on Sun Oct 08, 2000 at 12:42:30 PM EST

    I have to agree with you here. As I've said before, being self-taught doesn't mean you can't be good. However, I believe that college helps push you to take a few more steps forward, and polishes off all the rough edges in your knowledge and skills.

    I started messing with computers when I was 8 years old. I started really programming at about 11. So by the time I got to college, I was a fairly accomplished programmer... or so I thought.

    After my first year at college, I couldn't believe that I'd actually considered myself a good programmer beforehand. It was made painfully obvious to me that I had been missing out on a lot of important knowledge, and although I had had some talent, raw talent can only take you so far. Formal instruction can take that raw talent and hone it into real skill.

    This is why I encourage people to go to college. Sure, it isn't the most practical thing at times. Sure, you'll do some things that you'll never need to know how to do ever again. But if you go to a good college, you will learn an incredible amount of useful information that you will be hard-pressed to gain on your own.

    But that's just my perspective on it.

    [ Parent ]
    Does this only apply to CS majors? (3.33 / 3) (#78)
    by FeersumAsura on Sat Oct 07, 2000 at 03:05:47 PM EST

    I'm a self taught (mostly) programmer. Well I lie, actually I'm not a programmer. I'm a systems engineer, this means that some days I design circuit, other days I write code for embedded system (Assembly ONLY) and the rest of the time I write high level apps in Delphi. In July I started a new job, I'd never written in Assembly (PIC) before but they neded me to. I found that it only took about a day to master the basics and after a week I was writing hefty comms orientated bit banging code. OK I will agree PIC Assembly only has 35 real commands (the rest are macros) but when the stack is only 8 layers deep, you have one working register and 255 (usually) one byte registers it can be quite difficult to carry out some tasks. The transistion from Visual Basic to Delphi took about a week. So a langauge can be picked up in a short time. However, I would aggree that most languages take months and even years to truely master.

    I'm so pre-emptive I'd nuke America to save time.
    Software Engineering and Programming vs. CompSci (4.66 / 6) (#87)
    by Zanshin on Sun Oct 08, 2000 at 05:45:52 AM EST

    This is a very complicated area and the educational system only makes it more complicated. I have found that a bachelor's degree in Computer Science is actually of very little worth (real worth, not percieved worth, and not job potential worth). People who haven't gone through the CompSci regimen would be surprised at the number of students who couldn't program their way out of a paper bag. In fact, I would go so far as to say that most of the reason anybody who gets a CS degree has any substantial programming ability is largely due to what they bring to the table before hand and not anything that they are tought.

    Unfortunately, "Computer Science" is mis-advertised and slightly mis-labeled. Of all the undergraduate science programs, it is one of the least scientific. "Computer Engineering" suffers from similar though lesser problems. What most of these programs are taken to be, are not programs to create computer science researchers, but to create Software Engineers and just plain old Code Hacks. They fail at that task very badly.

    Your plain old "Code Hacker / Monkey" degree could easily be a 2 year degree offered by community colleges and technical colleges as well as the more prestigious educational institutions. The level of sophistication and capabilities of most of the programmers on the software assembly lines ("in the trenches", so to speak) is really more at the 2 year community college degree level than the 4 year bachelor of science degree level. However, I don't see much possibility for a move toward this kind of degree, partly because it would imply a loss of sophistication on the part of the employer and the employee and partly because it would likely result in much lower salaries for the lower echelon of programmers.

    On the other hand though is the need to produce true computer scientists and true software engineers. Really, a computer science bachelors degree should be nearer the level of what goes for a masters degree in compsci these days. Someone with a bachelor's degree in biology, or chemistry, or physics has much more experience with the cutting edge in their field, with real world application of the principles they learn, and with actual legitimate hands on research. Unfortunately, few CS majors people stick around to get their masters, which results in a paltry number of true computer scientists. This, I believe, is a key reason why innovation and computer science research is in such a pitiable state these days.

    There aren't many true Software Engineering degree programs out there and we desperately need more true software engineers. Software doesn't make and organize itself when you throw a bunch of programmers together. It needs innovation (legitimate scientific research), it needs leadership and organization (software engineering), and it needs qualified skilled labor (programmers).

    CS students spend most of their time grappling with theory (all too often not very useful theory as well) and with trying to kluge together replications of work so obsolete it has mold on it. Do they learn how to use modern equipment, do they learn about the cutting edge of technology, do they gain practice on how to be part of a team creating software? All too often the answer is no. If you are a chemistry major in almost any university in the US you will learn how to use some of the most sophisticated and modern equipment currently in use, as well as all the old standby's, plus, you will probably have a good chance of actively participating in real cutting edge research. What students need is practice. They need to learn several languages, they need to learn several operating systems, they need to be part of several software development projects. Not just the general theory, but specific examples, and specific usages. The way to be able to learn new programming languages is not just to study theory (that's actually only mildly important), but to learn several programming languages. Programming languages are often very similar and take their designs from pre-existing languages. Thus, if you know C++, and Perl, it's not too hard to learn Javascript, or PHP for that matter.

    Who knows how long it'll take before legitimately good programs of study for simple programming, computer science, and software engineering will be the norm rather than the exception. But until then, we can expect "the software problem" to remain as difficult as it is today with even uninspired, technologically undemanding software designs going over budget and over schedule and resulting in bug riddled bloated low-quality production code.

    Tools of the trade (2.66 / 3) (#88)
    by Majix on Sun Oct 08, 2000 at 07:49:47 AM EST

    I have recently started studying CS at a University, so far the experience has been very positive. Some people start CS thinking it will turn them into master C++/Java/C etc. programmers, often they are disappointed. I think that it would be very stupid to concentrate on learning C++ or something in the university, because languages come and go.

    I want to learn computer science, algorithm design and problem solving because I can then implement this knowledge in any current or future language, this is knowledge I will use all my life. I claim that almost anyone can learn the syntax of some language or other without really understanding what they're actually doing. Sadly universities also produce copy and paste programmers but I still think people who go to universities have better chances of acquiring understanding of the more complicated programming principles than you do if you learn it from a book. The university provides me with a way of thinking about problems, not language syntax.

    Come on now (2.00 / 2) (#89)
    by hoss10 on Sun Oct 08, 2000 at 10:58:56 AM EST

    > The university provides me with a way of thinking about problems, not language syntax

    yeah right. i'm doing final year CS in an UK university and all we've been taught is recursion (which i taught myself as a teenager and didn't even know it had a name, for god's sake)

    90% of the class wouldn't be able to do "hello world" in a language of their choice without having to find a book!

    University is shit for learning real stuff but it's good fun I suppose :-)

    [ Parent ]
    Re: Come on now (2.50 / 2) (#94)
    by Majix on Sun Oct 08, 2000 at 03:01:06 PM EST

    yeah right. i'm doing final year CS in an UK university and all we've been taught is recursion (which i taught myself as a teenager and didn't even know it had a name, for god's sake)

    Sounds like a pretty lame university if you ask me. My CS education is far from easy, a helluva lot of math and several computer languages are taught (no visual whatever either, it's an all unix environment). Recursion is such a basic requirement of algorithm design that it's covered during the very first algorithm class, we also study a lot data structures during the first year. The last years are spent focusing on some area like compiler technology, distributed system, programming embedded systems or high performance computing, etc... I study in Finland BTW.

    [ Parent ]
    Re: Come on now (2.00 / 2) (#95)
    by Fetch on Sun Oct 08, 2000 at 04:22:18 PM EST

    Heck, we have a better CompSci department than that even at Texas A&M University... certainly not the forefront of CS schools. Not that I have all that much respect for the _average_ CS Bachelors grad, but at least I know they've been taught the theory. Including language theory, which does make picking up syntax and structures in other languages easier. And they know OS design, which makes picking up how/why OS-specific implementation details are done just a little bit easier for them. Most of them are still morons, tho :)

    [ Parent ]
    Python, all the way! (1.50 / 4) (#90)
    by psicE on Sun Oct 08, 2000 at 11:46:01 AM EST

    I learned C in thirteen seconds ... (3.80 / 5) (#92)
    by forrest on Sun Oct 08, 2000 at 01:20:43 PM EST

    I'm reading a lot of comments lke that, and I wonder what the posters really mean. In my experience, you don't learn a language like that.

    I'm not saying that you can't, I'm saying that you don't.

    When I first started learning perl, it was because I had to search through some files and extract output. Before very long, I understood perl-style regular expressions and perl file i/o quite well.

    It some time (months?) later that I began to put my code in modules. Oh, sure, I had read about modules, and used modules from CPAN, but I didn't write my own until I felt I had some routines worth moularizing. Then, I learned how one goes about creating a perl module, and the tricks involved. Did it "take me months to learn"? No, I had been writing useful perl code all that time, i just knew it was time to get the scoop about modules then.

    Then there was mastering references, still later. And then extending perl with XS. Embedding perl came after that. These with gaps of weeks to months -- of writing useful perl code -- in between.

    Only recently have I written my first object-oriented perl module, after probably half a year or so of successfully, happily using perl.

    I took on each new step as I had a need for it. I guess I could have piled on the concepts faster, but I didn't set out to "be the ultimate perl guru as quickly as possible", I set out to "use perl in the context of my job where it made sense to do so".

    As a consequence of this style of learning, by the time I took each new step, I knew the foundation underneath it very well. I don't think it's fair to say "it took me half a year to learn perl", because that wasn't my focus.

    I could tell similar stories about all the languages I've mastered. From the tone of the "I learned -- in one day" posts here, I wonder whether my case is the rule or the exception.

    Re: I learned C in thirteen seconds ... (3.00 / 1) (#98)
    by Zanshin on Sun Oct 08, 2000 at 11:14:24 PM EST

    Agreed. The braggarts talking about "I learned language X in Y time, ain't I special?" are blowing smoke. There's a difference between "learning" a language, being fluent in a language, being productive in a language, being an expert in a language, and being a guru in a language. Sure, if you're fast you can pick up a book on latin and learn the basics and maybe be able to talk and understand fairly well pretty rapidly if you're smart. But if you try to claim that you are fluent in latin from that short amount of study, or that you require no more education in that language, people will just laugh at you.

    It takes even the smartest people a long time to become serious experts in any language, it takes a lot of hands on programming experience, it takes a lot of learning the little nuances and the tricks of the trade from the existing pros, it takes a lot of exploration of the language before you can remotely claim to being an expert, or even someone of intermediate skill. None of these can be gotten in a day, or even a week.

    [ Parent ]

    Learning languages is a matter of experience (4.00 / 1) (#96)
    by madams on Sun Oct 08, 2000 at 06:46:10 PM EST

    The ability to learn new programming languages quickly is a matter of experience. Programmers who know more languages/programming methodologies will have an easier time picking up new ones. CS majors tend to see a larger variety of languages than self-taught programmers, who will only run into the "popular" languages: C, C++, Java, Perl. CS students, OTOH, take courses that involve Lisp, Scheme, ML, and a variety of assembly languages (MIPS and 68k are the most common), in addition to the standard languages.

    Mark Adams
    "But pay no attention to anonymous charges, for they are a bad precedent and are not worthy of our age." - Trajan's reply to Pliny the Younger, 112 A.D.

    An MIT grad that disagrees with the first one. (4.50 / 8) (#97)
    by jmvidal on Sun Oct 08, 2000 at 07:25:42 PM EST

    The amazing thing is that, 12 years after taking 6.170 (Software Engineering) I went back to the Liskov and Guttag's textbook and realized that it still contains everything you need to be a good software engineering. Even more amazing is that 14 years ago I learned everything about object-oriented programming, streams, inheritance, and design from the "Structure and Interpretation of Computer Programs" 6.001.

    Those classes teach you all the important concepts. And, yes, the languages are secondary. In fact, I remember that I took:

    • 6.001, which use Scheme
    • 6.170, which used Clu (anyone? ;-)
    • 6.??? (compilers) which used C
    • 6.004, which used assembly
    • 6.002, Spice (hmm...not really a programming lang)
    • 6.003, something fun that had these cool fast-fourier transform functions (fortran?)
    • 6.045 (AI) Lisp.
    • 6.033 (advanced AI) Actors
    and thats just the ones I remember. In none of those classes did the profs made a big deal about "we are using a new language". It was more like "this is the language we are using, learn it over the weekend before turning in PS1". And, it was fine. No one had a problem with it.

    I do not mean to imply that I ever became a "wizard" at any of these languages but I could quickly grab it and get it to do what I wanted.

    Languages are only tools. We grab them and use them to get the job done. We do not need to become wizards in any language (the language will probably be obsolote by then). However, each project is different so each one will require you to learn something about that domain.

    My suggestion:

    1. Learn your data structures and algorithms.
    2. Know, and use, big-O notation.
    3. Learn UML and good object-oriented techniques.
    4. "Abstraction and Specification" are a way of life.
    5. Know that, even thought Liskov and Guttag have been saying the same thing for the last 15 years, it is still true.

    Agreement with original post, even with a BS in CS (3.00 / 2) (#99)
    by lwiggins on Mon Oct 09, 2000 at 10:39:13 AM EST

    I have gone to the university, worked through a degree, and have now spent time working in the industry as a sysadmin. One thing that i have noticed is that a lot of people who have graduated come to work thinking they are hot shit.(My self included once upon a time :) They are, at least in the generous environment of academia, where there are no memory/cpu constraints, and since the code is rarely doing more than a bubble sort or something else, you don't have to worry about time and space. Once you get into the real world though, you have to worry about such things, for bigger reasons than a bad grade on a paper. If it is actual work you are interested in, then CS is probably not the right course. If you want to do research in computers, it probably is. Is CS a useless degree for a job?? I doubt it, especially when most people (open-source/Linux arena excluded) are looking for that piece of paper, because regardless of actual working knowledge, it does present you as someone who is teachable. And if you want to make money, rather than be the local guru, you will probably possess not only a degree, but also sign up for about six different certifications. With all that said, CS students are no different from the rest of the community. They can't learn a language any faster, and that CS degree doesn't give them any special powers. If they have good skills, its for the same reasons that non CS students have them: they stayed up late reading everything they could get their hands on, hacking on their and other's existing code, and just generally trying to be the best at their subject. They were just lucky/smart enough to get handed a degree for their troubles.

    Teach Yourself Programming in Ten Years! (3.00 / 2) (#100)
    by washort on Mon Oct 09, 2000 at 10:59:49 AM EST


    Peter Norvig explains why programming is hard to master.

    Doing it for the (gulp) MONEY... (3.00 / 4) (#102)
    by floorpie on Mon Oct 09, 2000 at 02:07:58 PM EST

    Whenever this topic comes up, someone always makes the offhand comment about those greedy bastards who are only in CS for the money instead of the love for the code. Then they make some other comment about how all those idiots fail miserably and then move on to some disreputable major like business.

    Hello? Who actually goes to college nowadays for the love of academia? Sure, a few special smartie-pants, but I would surmise that most people go to school so that they can make more MONEY later on. Yeah, I did it too.

    I'm almost a year out of college (non CS major, though I did take a few boring CS courses -- wanna learn SCHEME?!?), and I make more money programming than most people's parents who have worked all their lives.

    Sure, money is the root of all kinds of evil... but money also supplies food, shelter, music, palm pilots, plane tickets, gigahertz clocked cpus, and whatever else that adds meaning to your pathetic empty lives. Computers are just a job -- a means, not the ends, by which you enjoy a balanced life.

    What's my point? Get off your pedestals about the purity of computer science being tarnished by those greedy rapscallions. Yes, there are some people who are in it purely for the money, but most people have a more balanced set of priorities... and Computer SCIENCE isn't (and shouldn't) be on the top.

    Whoa, whoa, whoa. (4.00 / 2) (#103)
    by 11223 on Mon Oct 09, 2000 at 08:51:19 PM EST

    Since when is systems programming all there is? I like systems programming. I love systems programming. But there is something to be said for application programming which shouldn't require systems programming knowledge.

    And besides, I consider myself as knowing C++ without ever having touched the spec. It's acquired knowledge, and it's faster and better than reading a spec. You can't be a language lawyer in 3 days. You can get a working knowledge of most any infix language in 3 days (same with prefix or postfix if you've programmed them before...)

    The dead hand of Asimov's mass psychology wins every time.

    (1.66 / 3) (#105)
    by BlyndFreddy on Wed Oct 11, 2000 at 12:59:53 AM EST

    ...but has anyone really tried to provoke a Cucumber. My Mother told me anything is possible.

    You can but you can't.... (3.00 / 1) (#106)
    by jimmythegeek on Wed Oct 11, 2000 at 11:59:54 AM EST

    As the original poster said "...you can learn just the syntax of a language in three days". Been there, done that. In fact I have on at least one occasion figured out how to code in a language, debugged someone elses code, wrote some quick subroutines to fix errors by the original programmer, and then went for lunch. On the other hand...after gaining a more thorough knowledge of the language...went back and recoded those subroutines about three weeks later. It's pretty much like spoken language...you may be able to make yourself understood at the basic level after only a few lessons (especially if you already have experience with more than one language). For more complex ideas to be understood, you need to have a thorough understanding of syntax, sentence structure and pronunciation.

    Come to FooBar University; learn any language in 3 days! | 106 comments (104 topical, 2 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!