[NCLUG] Looking at programming languages...

[Chad Perrin]

Warning: This email contains strong opinions, some of which may be stated
as fact.


On Wed, Jan 16, 2008 at 12:16:54PM -0700, Bob Proulx wrote:
> 
> One thing to keep in mind is that you will spend time teaching and
> people will spend time to learning something and that is an
> investment.  It has more return if they can learn something that they
> can apply and use.
> 
> If the goal is only to teach them principles now and then they would
> need to learn a Real(TM) programming language later then you could
> teach them MIX now and then they could pick up any language later.
> That has been done.  But I don't think that is the best way to go.  (I
> learned Pascal initially to learn the principles and then later
> learned C for creating real world programing.)
> 
> There are a lot of languages that would make the short list of useful
> programming languages to know.  Before you commit to a language you
> should consider how useful knowing that language would be to them
> later.  Would Gambas/BASIC really be that language?

BASIC is a piss-poor language to teach new programmers regardless of
whether it's useful as a "real" programming language later.  Learning
BASIC first is a good way to get brain-damaged in terms of programming
concepts, and it takes years to recover from that.  Thank goodness I got
a little bit of a buffer against that from early exposure to Logo.


> 
> In my not so humble opinion the short list for compiled programs:
> 
>   C, C++
> 
> C++ is really the new Pascal.  C++ makes easy things easier and hard
> things harder.  Unfortunately it was the hard things that I needed to
> be easier.  This is heresy to say but true IMNSHO.  The recent history
> is long filled with portability issues between compiler versions.
> Memory management is complicated.  A great language to teach and many
> people love it but it contains subtle nuances that fills volumes with
> traps for the unwary.  I stick with C these days.

Avoid C++.  Seriously.  There are far better compiled languages for
learning OOP techniques.  C is good for a number of reasons, though.


> 
> In my not so humble opinion the short list for interpreted programs:
> 
>   Perl, Python, Ruby

Python and Ruby are far better choices for OOP than C++, in terms of
teaching concepts.  C++ actively gets in the way of conveying core OOP
concepts, in my experience, because it's not really an OOP language at
heart (in that its syntactic and semantic design doesn't really
facilitate an OOP mindset).  Objective C would be better, and OCaml may
be better still.  Ruby and Python both blow C++ out of the water in terms
of good tools for learning OOP techniques, and of course Smalltalk is the
canonical example of good OOP technique made manifest in a language.

C++ is something that, in my honest opinion, should only be learned if
you have a specific need for it.  Stick with C for non-OOP learning, if
you want something from the C family, and almost anything other than C++
if you want OOP learning.  Even Java would be better as a first-timer's
OOP learning tool.


> 
> I have loved and hated Perl for the reasons you mentioned but mostly
> today would avoid it because it is harder to teach and program object
> oriented programming principles with it.  The variable scoping rules
> were not created with OOP in mind.  It is possible but not fun.

If one of the requirements for a given language is that it's good for OOP
instruction, I agree: avoid Perl.  Perl's object model is less awful than
C++'s, but that's not saying much.


> 
> The difference between Python and Ruby is less than between either and
> Perl.  I personally find Ruby to be my favorite of the two.  Others on
> the list would choose Python.  Both are very good.

In terms of OOP characteristics, this is true.  In terms of some other
characteristics, however, either Python or Ruby might be more like Perl
than either Ruby or Python, depending on the specific characteristic.
The three languages have a lot in common.

Perl's object model is more like Python's than Ruby's, but Python's is
more like Ruby's than Perl's.  Ruby's, meanwhile, has a fair bit in
common with Smalltalk's.  I guess the relationship looks something like
this (greatly simplified):

    C++ <---> Perl <---> Python <--> Ruby <--> Smalltalk


> 
> I know that I did not put Java in that list.

It's probably better that way.  I'd recommend it over C++, but not by
much, in terms of the language itself.  In terms of deployability,
however, I'd be almost inclined to choose C++ over Java.


> 
> I have not found use of Ruby to be problem as compared to Perl or
> Python from a system resource point of view.  They are within the same
> order of magnitude of performance.  If an application is in critical
> need of performance then a compiled language is the best choice.  But
> here are some quotes about optimizing too soon.
> 
>   "We should forget about small efficiencies, say about 97% of the time:
>   premature optimization is the root of all evil.", Donald Knuth.
> 
>   "The First Rule of Program Optimization: Don't do it. The Second Rule
>   of Program Optimization (for experts only!): Don't do it yet.",
>   Michael A. Jackson.

In my opinion, anything slower than Perl is too slow to worry about
performance.  If performance is any kind of concern, don't use anything
slower than Perl (which includes Python and Ruby).  Perl is better for
very short-run stuff, generally speaking, than Java -- but Java is better
for very long-running persistent processes than Perl, generally speaking.

If you need *real* performance, I don't think there's a partially
interpreted language out there that should even be on your radar.  That
means both Java and Perl should be excluded.  At this point, we're
talking about the faster implementations of Common Lisp compilers,
Haskell, Objective C, and up.  My understanding is that for compiled OOP,
C++ and OCaml are pretty much top of the heap (with OCaml edging out C++
on execution speed) -- and if you don't need OOP, C blows them both away.
Any faster than that, and your only real choice is Assembly.

Pascal can outperform C for limited purposes, but in general tends to
languish around the range of C++, from what I've seen.

. . . but as Bob Proulx notes in his quotes of Knuth and Jackson,
execution performance optimization is something that should only be
undertaken with a complete understanding of the cost to benefit ratio in
such optimizations.  Most of the time, a better algorithm beats the crap
out of a faster language implementation for purposes of improving
execution performance.  Even a "better algorithm" needs to be weighed
against the clear presentation of your program logic, however, in terms
of the relative benefits to be gained.  Does it really matter if your
to-do list is generated a few milliseconds faster?


> 
> As far as teaching users OO right at the beginning I think that would
> have been much easier than the way I learned programming.  I have
> heard many people advocate teaching OO right from the start.  I think
> OO is only considered advanced because most of use learned without it
> and only later came to know it.  If I were teaching I would teach OO
> concepts as simply a normal part of the course.

I think that, based on my experience of object oriented languages, Ruby
is among the best (of not *the* best) language I've seen for teaching OOP
from the very beginning.  The only things in the language that are not
either objects or methods are a handful of operators and keywords
(notably, certain assignment operators and keywords like do and end).
Smalltalk might be similarly appropriate.

Another possibility, if you happen to know the language well enough,
might be OCaml -- which provides unique opportunities for teaching OOP,
FP, and imperative/structured programming techniques all at the same
time, as well as introducing the user to compiled, VM bytecode-compiled,
and interpreted programming, interactive interpreter use for rapid
development, and modern type inference systems.  It suffers, however,
from a dearth of good instructional material coverage and ubiquitous
deployment.  It's easily acquired for most computing platforms, though.

If, for some reason, you decide to go with OCaml, I have a piece of
advice:

Whatever you do, *do not* waste any money on the Apress book "Practical
OCaml" by Joshua B. Smith.  It's crap.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Marvin Minsky: "It's just incredible that a trillion-synapse computer could
actually spend Saturday afternoon watching a football game."