Popular conceit about learning programming languages

[Pascal Costanza]

Donn Cave wrote:
> Quoth Pascal Costanza <costanza at web.de>:
> | Donn Cave wrote:

> |> 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.

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.

> 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.

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.

(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.)


Pascal

-- 
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there 
are always circumstances when it is advisable not only to ignore the 
rule, but to adopt its opposite. - Paul Feyerabend