Re: Should I learn C or Pascal?

[patrick@broadvision.com (Patrick Horgan)]

In article <qqspaho8h3.fsf@tartarus.ucsd.edu>, 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.