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