Re: [Caml-list] Roadplan for world domination

[Warren Harris <wh232@pacbell.net>]

[-- Attachment #1: Type: text/plain, Size: 10488 bytes --]

Chris Clearwater - chris@sharkzone.com wrote:

> I have come across the Ocaml language several months ago and after much
> investigation and trial coding I have come to several conclusions. Most
> importantly I think Ocaml is a wonderful language to program in. It 
> has all
> the features I would expect from a modern language and on top of that it's
> compiled native code appears to rival that of C in many areas. It truly is
> the language of the future. Now that I have expressed how much I am 
> growing
> to love Ocaml I would like to share with you my initial experiences as 
> a new
> user. First I would like to single out some issues that I believe threaten
> Ocaml from being taken seriously and then i would like to offer some
> solutions that would improve the usability of ocaml greatly.

I agree that ocaml is a beautiful language and first-class 
implementation, and I sincerely hope that it sees its way to world 
domination. I too am a relative newcomer to ocaml, so I've been 
reluctant to throw in my comments and criticism of the language/system 
until I had a little more experience with it, but your message has 
prompted me to resurrect this message that I began composing some time 
ago in response to the thread "OCaml popularity (long)". Please take it 
as a constructive criticism.

Warren


[Caml-list] OCaml popularity (long)

I know this is an old thread, but I can't help but throw in my 2 cents 
on ocaml's popularity. I'm relatively new to ocaml, but I have 
experience with many other languages, and think that I have a good sense 
for the new-comer's perspective. Here's my take:

1. I agree that the major factor is lack of industry backing. Java is 
successful because of Sun's marketing muscle. Same goes for C#/Microsoft.

2. Lack of university backing. Although there is a lot more support for 
ocaml at universities, there's still a large degree of fragmentation in 
terms of languages used for teaching: java, scheme, haskell, etc. Lack 
of knowledgeable students leads to a lack of demand for ocaml by 
industry people.

3. Difficulty to learn. I don't really think ocaml is that difficult to 
learn, but there are two main factors:

    (a) it's "different enough" from most languages that people are 
familiar with and many people are too lazy or impatient to wade through 
the differences to make it to the rewards, and

    (b) often the introductory treatments have an academic slant rather 
than a get-things-done approach (already mentioned in this thread -- 
need for "cookbook"). Ocaml is really much better than other "academic" 
languages in this regard (I find the O'Reilly book very pragmatic and 
not sure why so many people seem to love to hate it). I mean at least 
you don't need to understand monads to get useful work done in ocaml.

4. Tools. Lack of proper tools is the downfall of many languages. 
Although ocaml is really quite good in this dept, the major flaws are 
lack of a debugger on win32, and lack of an IDE (yes, there's emacs, and 
some integration with VC6, but it's far from what your typical Visual 
Studio guy is looking for).

About the debugger:

First I'll say that the debugger isn't nearly as necessary in ocaml for 
several reasons:

    (a) There's a read-eval-print loop (REPL) that can be used for 
interactive testing and development. This allows programs to be built 
from the bottom-up, verifying the smallest pieces first before building 
things that depend on them. This is the same as 
lisp/scheme/python/perl/js, and in stark contrast to C++/Java/C# where 
you often need to write a large part of the program (and lots of 
boilerplate) to get to the point where you can test anything.

    (b) The fact that in the REPL you don't need to specify types 
further lends itself to interactive development (again, in contrast to 
Java).

    (c) All data types can be used as literals, and printed to the 
console further aids interactive development.

    (d) Pretty-printing and the formatter are great tools, make things 
easier to read, and are very easy to use.

The reason for the lack of the debugger on Windows is the lack of 
fork/exec primitives, and these are used to implement checkpoints 
(ability to roll back to a previous debugger state). Although this is a 
nice feature, I for one don't find it that useful -- primarily because 
with every other debugger I've used I get used to putting breakpoints in 
places where I need to begin paying attention, or at least, I can 
restart the computationfrom the beginning to get back to an earlier 
point. I think most programmers would agree with this.

    (I'm not sure if there isn't a slight anti-Windows bias in the ocaml 
community, but I think there are two potentially conflicting goals for 
ocaml: (1) promoting an alternative to the dominant platform by offering 
ocaml as a better tool/language for Linux and open source development, 
or (2) promoting wide-scale adoption of ocaml language in general, which 
means making it work well on the dominant platform.)

5. Learning the language. Here's where I'll list what I think is 
"different enough" about the language that keeps people from using it:

    (a) Syntax of types -- in particular use of * and ->. I know where 
they come from, why they're good, etc, but I know they put some people 
off. This is compounded by type variables prepended with apostrophes and 
postfix type functions. Also currying is foreign to most people -- the 
fact that functions return functions that take more arguments. On the 
surface this must seem useless, and inefficient (although once you 
understand the power you'll wonder how you lived without them).

At the very least, I think ocaml type expressions would benefit from the 
ability to label arguments with symbolic names. This would aid in 
understanding. E.g.

    val assoc : 'a -> ('a * 'b) list -> 'b

might be expressed as:

    val assoc(key:'a) : fun(l: list(key:'a, value:'b)) : (value:'b)

(Just a suggestion -- I know this is more verbose, but if it makes the 
language easier to learn it might be a good thing.)

    (b) Constructors, patterns and values. This is no doubt one of the 
great things about ocaml -- the fact that these three things are 
expressed uniformly, i.e. that I can construct one by saying Foo(x), 
match and destructure by saying Foo(x), or return a value and see it 
print out as Foo(x). But to the beginner these three distinct things 
might be confused. People are very used to seeing "new" in front of 
constructors, and pulling apart nested structures one dereference at a 
time. So I believe this is one reason why ocaml is different/hard to learn.

    (c) Union types. (Or do you call them sums?) It's probably also lost 
on many newcomers how great unions are in ocaml -- the fact that the 
compiler will tell you all the functions that need to handle a new 
constructor of the union when it's introduced (as long as you don't add 
catch-all patterns), and how the pattern-matching cases are checked 
exhaustively. Unions seem to suffice for 99% of the things that people 
use OOP for (representing cases as disjunctive function clauses rather 
than methods on classes) -- but without all the boilerplate. Unions are 
great, but foreign to newcomers, and unwelcome to those that think they 
only want OOP.

    (Perhaps some sort of document is in order that shows exactly the 
class of problems that requires overloaded methods, distinguishing this 
from the cases where choosing ocaml's object system over union types is 
simply a matter of taste to the programmer. Or better yet, a document 
that describes how numerous problems expressed in Java or C++ can be 
better (more concisely and efficiently) expressed with unions.)

    (d) Heavy reliance on recursion. Although ocaml provides some 
iterative constructs, for many things you still need to write recursive 
functions. Fortunately, due to tail recursion elimination and a very 
good compiler, recursion is very efficient in ocaml, but nonetheless it 
requires programmers to contort their normal way of thinking about 
common program idioms. Higher-order functional library routines also 
fill the gap when iterative constructs are often used, but for whatever 
reason, most people don't think in terms of List.map or Array.iter. I 
think ocaml would benefit from a little more syntactic sugar in this dept:

    for x in l do e       == List.iter (fun x -> e) l
    for x in l collect e  == List.map (fun x -> e) l

    (e) Assignment and mutability. The first hurdle is that people often 
think ocaml is a "functional language," doesn't have assignment, and 
consequently isn't practical. If they get past this, they may find that 
refs require some change in the way you think about assignment. 
Programmers are used to dealing with references and dereferencing when 
pointers are involved, but for ordinary data types like int, bool and 
char they think of variables being mutable or "const". Although ocaml's 
treatment of references is more consistent, it presents a slight 
rethinking. Also, ocaml's mutable record fields further confounds the 
problem because unlike ordinary lexical variables, they can be modified. 
Perhaps ocaml should consider adding mutable local variables:

    let sum_until n =
      let mutable sum = 0 in
        for i = 0 to n-1 do
          sum <- sum + i
        done;
        sum

    (f) Type-checker error messages. When something fails to type check 
in ocaml, the error messages can be uninformative or confusing. Often 
times the source of a type constraint is far removed from the location 
where the problem is reported. Showing the source of the constraint 
would be very helpful. Also, often times the type conflict that's 
reported fails to narrow down the conflict sufficiently. It would be 
very helpful if the expected and actual type expressions were unified in 
some way to pinpoint the exact discrepancy.

    (g) Module system. Once you become proficient in the base language, 
you move on to the module system, with it's own learning curve. For 
instance, the beginner may wonder why they need to redefine all the 
types in the mli file again in the corresponding ml file (not something 
you have to do with import/include file in Java/C++). They may also be 
confused by the difference between a a functor that takes a type as a 
parameter, and a module struct specialized by a 'with' type constraint 
(ok, maybe I'm the only one confused by the difference here).



[-- Attachment #2: Type: text/html, Size: 11919 bytes --]