[NTLUG:Discuss] Direction Recomendations

[Richard Cobbe]

Lo, on Thursday, 20 July, 2000, Steve Baker did write:

> 
> Language wars tend to get very heated and passionate...tread with care!

Truly.

> C++ is a 100% super-set of C.  If you have learned all of C++ then you

Erm, almost.  I don't have my copy of Harbison & Steele here, so I can't
give you a specific example, but I believe there ARE constructions that are
valid C which will cause a C++ compiler to barf.

> already know C...providing you can remember all the things C can't do
> that C++ can!
> 
> Conversely, if you know C, you can write programs that will compile as
> C++ - although you won't be using the full expressive power of C++...
> which is very important.
> 
> I advise you to learn C first - then progress on to C++ later.

Well, if you already know C, then the 'surface structure' of C++ should be
quite easy to pick up: syntax, data model, and so forth.  And, if you just
want to write in `C+' (no, that's not a typo) then you can do that.

(By C+, I mean the dialect halfway between C and C++ that we used to teach
right at the end of the intro CS class at Rice -- after a semester of
Scheme.  Basically, it was straight C, but use new instead of malloc() and
iostreams instead of printf()/scanf(), and don't sweat delete.  Full C++,
in all its glory/evil (depending on how you look at it), came later.)

However, it generally takes a great deal of time to learn the new
programming styles that are possible (or, at least, well-supported) in C++:
generic programming through templates, OOP, and so forth.  Learning C will
not really help you here.  However, it won't hinder you, either---unless
(like far too many professionals, IMNSHO) you've only got room in your head
for one design paradigm.

> > Perl:
> >  Great for text processing and system administration type things.  Very
> >  useful and powerful tool.  It's interpretted instead of compiled, so
> >  it's slower than C/C++.  But development time is a lot shorter largely
> >  because you don't have to do all the memory management that C/C++
> >  warrants.

> Python, Java and Perl are interpreted languages.  That means that they
> are S-L-O-W compared to equivelent code written in C or C++.  We are
> talking 5 to 50 times slower here.

True, Perl, Python, and Java are slower than C/C++.  The question you have
to ask yourself, though, is "So what?"  More specifically:

* Is the added speed of C/C++ actually required or even highly desirable
  for this application?  Put another way: would an implementation in (say)
  Python be fast enough?  I believe that the answer to that second question
  is 'yes' far more than most people probably assume.

* Do the benefits provided by Perl/Python/Java's other features outweigh
  the speed penalty?

If you fall into the trap of beliving that speed is everything, you will
end up ignoring a great many HLLs as worthless, and thus missing out on
some of the neatest stuff to come out of the language community in the last
20--30 years.  (True, C++ was designed in the early 80's, but in many ways,
it's really a much older language than that.)

(Incidentally, it's an oversimplification to state that Java is
interpreted, but I'm not going to get into that here.)

> Perl is a nasty mess IMHO - learn it only if you absolutely need
> it - certainly not as your first language.  Other people are
> passionate about it - so I expect to be contradicted on this one.

Amen.  Linguists should never be allowed to design programming languages
without adult supervision. [1] [2]

This is not to say that Perl is not useful.  In particular, it's
string-handling facilities are wonderful.  There are, however, better
languages available for almost everything.

                                   * * *

In the end, it all boils down to what you want.  If you've got a specific
application in mind, then Steve's list is a pretty good place to start.
If, on the other hand, you're just interested in finding out what this
`programming' thing is all about, then my recommendations would be
different.

Start with a high-level language.  My personal favorite is Scheme (see
http://www.rice.edu/CS/PLT/ for an LGPLed implementation that runs on
Linux), but there are any number of other choices: ML, perhaps Python,
perhaps Smalltalk, plenty of others.

(Note that neither Perl nor Java are in that list.  Java is, at best, a
mid-level language.  True, it's higher-level than C++, but that's rather
damning with faint praise.  Perl, as Steve said above, is just a mess.
Avoid it wherever possible.)

Also, I don't really know Smalltalk or Python well enough to be able to say
anything intelligent about them.

I also have a bunch of additional Scheme resources; if anyone's interested,
send me private mail, and we can talk.

The primary advantage of starting with an HLL is that it lets you
concentrate on what I consider to be the core of programming, instructing
the computer to solve the problem at hand, without bogging you down in bits
and bytes and memory management bookkeeping and complex I/O routines and
such.  You can learn that stuff as it becomes necessary.

Plus, my experience with the intro CS class at Rice suggests that people
with no programming experience have a much easier time learning HLLs and
moving to low-level languages than going the other direction.

Richard

====

[1] Attribution: This was based on something a friend of mine, Daniel
Whiteson, said to me at school.  He was a Physics/CS double-major and did
some programming work for the Physics department on the side.  At one
point, he said to me, "Physicists should not be allowed to program without
adult supervision."

[2] Disclaimer: I've had enough linguistics to understand where Larry Wall
was coming from.  However, I've also had enough computer science, and in
particular, language theory, to understand that the idea of designing
programming languages to act like natural languages doesn't work very
well.  In particular, natural languages are highly ambiguous.  Since humans
are, by and large, intelligent enough to resolve those ambiguities, that's
ok.  Computers, however, aren't, so that ambiguity KILLS you when you're
programming.