Re: [Caml-list] Some Clarifications

[Ville-Pertti Keinonen <will@exomi.com>]

Robert Morelli wrote:

> In the interests of saving time,  and keeping my post to a palatable

I'll only comment on a couple of points for the same reason...

> just the tip of the iceberg.  I find that the facilities of a language
> like OCaml are so inadequate to represent this domain,  that using
> OCaml can be a distinct impediment.  Sometimes Java is a better fit.

Which do you have more experience in, OCaml or Java?  Or FP vs. OO 
languages in general?

Unless you are highly experienced in both, your view of OCaml as an 
impediment might merely be an indication that you don't know the 
language and the associated styles of abstraction sufficiently well. 
Remember, OCaml is a multi-paradigm language, and the paradigms include OO.

The reason I'm pointing this out is that there are very few things that 
Java, as a language, is capable of that don't translate easily to OCaml 
(type-narrowing casts, explicit - extremely clunky - introspection, 
neither of which are usually considered good OO practice).  OCaml 
provides a huge amount of things that don't easily translate to Java, 
even in the OO area (separation of subtyping and inheritance, multiple 
inheritance, binary methods etc.), and learning to make use of them 
effectively requires experience.

Even for an OO language, Java is horribly clunky and limited.  The 
reasons for its popularity are almost certainly familiarity, library 
functionality and commercial backing, it can't possibly be the merits of 
the language itself.

> 4. Over the decades,  both hardware and software technologies have
> inexorably evolved toward networked,  decentralized,  componentized
> systems.  Even CPU's are now trending toward multicore designs.  This
> makes the sequential computational model that FP is based on seem less
> and less central.

Really?  Avoiding mutable state is a good way of making concurrent 
programming convenient and reliable.

See e.g. Erlang for a very much real-world example.

Also consider a couple of multi-paradigm (with good FP features) 
languages with very good support for concurrent and distributed 
programming - Oz, Alice ML.

All of these are capable of running several orders of magnitude more 
threads than Java efficiently.  As is CML, which is the lightest-weight 
of them all, but also the least practical.

Unlike multithreading in mainstream languages, where it's just a 
bolted-on feature, resulting in extremely heavyweight threads and a 
default concurrency model of shared-state concurrency (which is the most 
error-prone) these systems treat concurrency as a programming paradigm.


Most of your arguments seem to be centered around either your personal 
"feeling" of what OO is and what it's capable of (which is why I'm 
interested in how much experience you have in different kinds of 
languages) or rationalizations based on a belief in correlation between 
popularity and merit (obviously popularity will go hand in hand with the 
availability of literature and tools, but none of those are defining 
factors in terms of the technical or scientific merit of a paradigm, 
technology, language or anything else).

Note that I'm not arguing against OO, I consider it a very useful 
programming paradigm, but it is not sufficient and it is vastly over- 
and misused by the mainstream because they don't know anything else.  I 
consider multi-paradigm languages such as OCaml the most powerful and 
practical programming tools.