Popular conceit about learning programming languages

[Donn Cave]

Quoth Pascal Costanza <costanza at web.de>:
| Donn Cave wrote:
|
|> The procedural aspect of Python is also natural but not necessarily
|> benign.  This is basically the linear descendent of assembly language,
|> with variables for registers and other superficial differences;  the
|> alternative (or one of them, anyway) is the equational reasoning you
|> find in functional and logic programming languages.  It's arguably
|> true that the normal programmer can more easily conceive a procedural
|> solution to a problem, but it is not true that this solution will
|> naturally be robust and maintainable.
| [...]
|
| That's even true for code that superficially looks like OOP. An 
| extremely well-presented example and discussion of this can be found at 
| http://csis.pace.edu/~bergin/patterns/ppoop.html

That's an interesting read, all right, but ``procedural'' is used
there in a different sense, I believe, than I intended it - in fact,
almost the opposite.  In the sense I'm using it, OOP _is_ procedural,
or nearly always.  By some accounts, that may not have been the original
idea, but the alternative (OO that is not procedural) seems to be
difficult to find or describe.

Probably the best counter example, of a language that emphasizes
what I'm calling ``equational'' rather than procedural, is Haskell.
It's the most prominent example of a ``non-strict, purely functional''
programming language (``non-strict'' is a queer term that probably
doesn't mean what you think.)  Haskell has a type class system that
supports polymorphism, but it's no OOPL.  There's an O'Haskell offshoot
that I find really interesting (though evidently I'm alone on that,
because it seems to be a dead project), and it really illustrates the
point by adding OO to Haskell and not making it a bit like any ordinary
OOPL.

Any real program will fall somewhere in between - nothing stops me
from writing C code that is purely functional in places, and no
Haskell program can do anything without resorting to some fundamentally
procedural code to put it in motion.  But you can expect to see a
strongly procedural approach in OOPLs, because the object is all
about encapsulating program state - and that program state is the
stuff of procedural programming.

	Donn Cave, donn at u.washington.edu