From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 123b8d,79cbfdf4caf8a870 X-Google-Attributes: gid123b8d,public From: patrick@broadvision.com (Patrick Horgan) Subject: Re: Should I learn C or Pascal? Date: 1996/08/02 Message-ID: <4ttmpi$l3k@ns.broadvision.com> X-Deja-AN: 171762701 references: organization: The quite unorganized Patrick reply-to: patrick@broadvision.com newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.os.dos.programmer,comp.lang.ada Date: 1996-08-02T00:00:00+00:00 List-Id: In article , djohnson@tartarus.ucsd.edu (Darin Johnson) writes: > That's why the thread has drifted. The original poster wanted to know > where to get a fish. If he learns the language that gets him a job > now, what happens next year? The language will change - and more > often the way the language is used will change. When you know how to > program, the choice of language is just a matter of syntax and > idiosyncracies. If all you know is one language/methodology, then > everything else is viewed as "a silly way of doing things". If you > learn abstraction, you can use it in any language. If you learn C and > have never seen abstraction, you're not going to use abstraction until > years of experience cause you to use it. These aren't things you > learn on the job unless you work with people that also know these > things and they make an effort to teach you (and this is becoming less > and less likely). You're making a few unspoken assumptions here. First that the previous thread had anything to do with learning abstractions, (and I'll expand that to mean "all the good things that make the difference between someone that I would respect as an elegant developer"), second that everyone can and will learn these things if exposed to them, and most chilling, that no one will make an effort to continue their education on their own unless someone else takes the bull by the horns and leads them. Nevertheless what you've said is valid and good and I agree with it. To show that I do, let me say what you've said only in my usual blathering way with large amounts of voluminous text;) Most of the previous discussion has been along the lines of, "well, learn it in this order and somehow that will teach you the higher level abstractions you need to know. I think that's silly. Programming languages might lead you along the path a bit, (yes even assembler even though you ~seem~ to feel that all assembler programmers are archaic spaghetti code hacks;), but courses in data structures, algorithms, object oriented programming, and other abstractions do a better job. The better intro programming courses cover a bit of all of this along with some language, and the people might come out of the course assuming that learning the language taught them these things, but it's not true. I can write spaghetti, structured, procedural, object-oriented, or anything you desire in ada, scheme, assembler, C++, pascal, boern shell, or logo. Languages don't teach you programming, they're just the medium in which you do it. I can learn them in any order I want, and as long as all I'm learning is the language constructs I'll still suck;) Nevertheless it's obvious that these things can be learned (by some;). Often times the genesis is a set of rules to follow. I remember when structured programming was all the rage. Its intent was to do away with spaghetti code in assembler and fortran and basic, and lead programmers to a better, in that it was more understandable and more maintainable, way of programming. Most people's exposure to this was as a set of rules such as: o modularise o a module should have no more than N lines/should fit on M screens o a module should have only one entrance and exit (well, in a non-procedural language you had to tell people these things!) o frequently reused code segments should be abstracted into their own module etc...some people blindly adhered to these rules in a completely anal way that demonstrated that they didn't get it...they thought that following the rules was the thing, but the original intent was to show better tools to get things done. Like in all other things, the better people got the idea, the abstraction behind the rules, and applied it without having to think about the rules, or worry about if it was ever appropriate to do something outside the rules. Later more and more design methodologies came along. Some people blindly adhered to them, some people took the good ideas behind them that they where trying to express and added them to their repertoire. (Many projects that insisted on blindly following a particular design methodology failed, see the literature for many many details;) It became clearer and clearer that people fell into a few categories, there were those that just liked it, and learned more and more on their own all the time, and considered it a moving, changing, growing body of knowledge. There were those that wanted to know "what worked", studied it, decided they knew and wrote up whatever particular abstractions and methodologies they'd come up with as if it was on tablets from heaven (although I know with the best intentions). There were those who just believed what they were told and blindly followed it. There were more of the latter category. I believe the first guys that want to learn and grow and add more and more tools and concepts and paradigms to their toolkits all the time are the best. They are flexible. They use what works. They understand why it works. They know where the ideas for structured programming came from, they know where the ideas for object oriented programming came from. They've internalised these things to the point that they are common sense, and they're still spending more time learning about their field (and usually lots of other things in life) than most people spent in college. They like to think. They like elegant abstractions. We should be teaching free thinking and flexibility in college. Instead, since MANY college professors and their TAs fall into the second category (excluding well known examples like Pohl and Knuth and others that are the good guys,) we get rules to follow. We get punishment for free thinking and flexibility. It's sad, but not actually that bad, because only a small percentage of the folks in college have the ability to be in the first group. I don't know what it is that separates the top guys from the rest...it's not intelligence. I've known a lot of really bright but rigid folks in the field. The folks that belong in the top group will most likely get there in spite of any obstacles placed in front of them by the educational system. So, if the question is what language should you learn to get a job, I'll still say C++. Most work these days in Unix or Windows is done in C++, and that's most of the work. Is it enought to just learn a language? No. Will learning several languages in some particular order teach you what you need? No. Learn everything, learn constantly, seek to always grow. Learn what you need for school, learn what you need for work, but don't stop there. Learn the basic underpinnings of algorithms and data structures...if it's hard for you read it again. If it's still hard get a different book and read it. Learn until it's common sense to you and then go on to something else. Learn always. If you show up on a job interview I should be able to say, "write me a quick binary sort algorithm" and you have no problem doing it because you know how it works...you don't have to memorise it, you create if from well understood basic principles as needed. Then you'll end up being the developer that's sought out. You'll make more money! And if you're lucky, you'll end up in a startup that hired a lot of people like you and your peers will push you to new heights, and appreciate what makes you different from the vast bulk of your peers:) (Can you tell I'm happy where I work?:) If you find yourself in a place that's stifling, a place where you're a big fish in a pool of minnows, move on. And always, always, always keep learning, be one of the people that learns new stuff first. Be a leader. But always learn in depth. It doesn't really get added to your repertoire until it becomes common sense. -- Patrick J. Horgan patrick@broadvision.com Have horse will ride. Opinions mine, not my employer's except by most bizarre coincidence.