Popular conceit about learning programming languages

[Donn Cave]

Quoth Pascal Costanza <costanza at web.de>:
...
| Just recently I have encountered some useful terminological distinctions 
| in c.l.l that made sense to me. There you have the imperative and 
| message-passing paradigms on the one hand, and the procedural and 
| object-oriented style on the other hand. The interesting bit is that 
| these things are independent. So procedural style is well-suited for the 
| imperative paradigm and object-oriented is well-suited for the 
| message-passing paradigm. However, you can also do message-passing in a 
| purely procedural languages as well as use the imperative style in most 
| object-oriented languages. I guess that you are thinking along these 
| lines as well.

Perhaps I could be, if message passing were clearer to me!

| > 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.
|
| Yes, this kind of pure languages is very interesting. However, I have 
| doubts that they are of practical importance. Purely functional or 
| purely declarative programs can be very intriguing when they are in a 
| "finished" state, but this hides the fact that it's harder in these 
| languages to get to such a "finished" state IMHO. It's more important 
| what kind of support a programming language gives you as long as a 
| program does _not_ work (because that's what they do most of time during 
| development). From my experience, you need an easily accessible 
| operational model of what goes on behind the scenes in order to 
| understand why a program does not work. Languages like Haskell and, for 
| example, Prolog make it hard to have an understanding of the operational 
| model. Both the imperative and the message-passing paradigm have 
| comparably simple operational models.

It can be much harder to get something done in pure FP, at least
that's true for me.  Now, this is obviously because I ``think in
Python'', or rather I think in procedural terms, and someone who
``thinks in Haskell'' will have less trouble.  But I think you're
right, it is essentially more demanding in some ways.  My point was
that when it seems like it's easier to think in Python, we have to
remember that it's still hard to write good software, and the thinking
still has to be done somewhere.  Intensive use of Python features is
often not a good substitute.

| I prefer a language that allows me to use side effects and message 
| passing as default modes but let me switch to purely 
| functional/declarative features for subtasks that are simple enough to 
| be modeled that way.

Well, of course that's how Haskell is - it's just that they have higher
than average estimation of what can be modelled that way.

| (BTW, for the same reason I don't like static type systems. It's nice to 
| be able to prove some static properties of a program when it is 
| finished, but during development static type systems usually just stand 
| in the way.)

If there's one thing that makes Python a bad choice for me, that's it.
During development, static type systems save me a lot of trouble.

	Donn Cave, donn at u.washington.edu