English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-02-04 (19:36)
From: Ernesto Posse <eposse@c...>
Subject: Re: [Caml-list] Estimating the size of the ocaml community

I'd like to put my 2 cents on this thread. The original subject was the
size of the O'Caml community. By comparison with some major languages,
namely C/C++, Java, Python, the community is still smaller. The question
is why is that? So far the answer in this thread has been focused on
language features. More specifically about the pros and cons of the type

  The type system is at the core of all languages in the ML family, as
well as many others. Personally I am a types-guy. While I do recognize
that untyped languages have a high "elasticity," useful in certain
contexts, I found that most applications do not benefit from that kind
of power, and that the structure imposed by a (strong) type system, as
well as its usefulness in developing correct code, outweight by far the
limitations and constraints imposed. Types are not just for
error-correction. They are a tool for designing a correct
conceptualization of a system.

  Then again, all this depends on the application. I am a firm believer of
using the right tool for the job.

  But language features such as the type system, are by no means the only
determinant of a language's popularity. There are a few key other
issues, such as:

1) Availability of development tools (IDE's) specially in different
2) Size and usability of libraries, particularly those for GUI development
3) Existing codebase
4) Learning curve for
  a) Experienced programmers comming from other languages
  b) New programmers

  I think that unfortunately O'Caml is lagging in these issues, at least
from my personal experience. I have been a long-time user of O'Caml
(back from the Caml Light days,) and I try to use it when I can, but
sometimes it just takes too much time to get a project started. Spending
too much time on the preliminaries is a big deterrent for managers, and
without their support, projects won't be done in the language.

  Recently I started a small project, and I wanted to develop it in
O'Caml, but after a while I gave up, and did it in Java. My first
concern was choosing an IDE. Normally under Linux I use Emacs+Tuareg.
Fine, but my project had to be done on Windows.  I find Emacs under
Windows a bit annoying, and I wanted to have something similar to the
popular Java IDE's for O'Caml. So I had two options: Eclipse or
Cameleon. The Eclipse mode for O'Caml is still an alpha version, and not
very usable or customizable. Writing your own Eclipse mode is a dawnting
task on its own. So I tried compiling Cameleon on MinGW. After a week of
trying to figure out how to do it I gave up. I didn't find any concise
installation instructions, other than the typical "configure-make-make
install" routine, which should be enough, if there was no need to
install LablTK. I was never able to do that. This brings me to 4.a)
above. You cannot ask a student learning to program for the first time
to do any of these things, whether it is Emacs or installing one of
these IDEs, might be fine for a seasoned programmer, but not for a
rookie (I can testify that after teaching programming to non-programmers
for several years now.)

  The second point was the library. For most purposes I find the library
satisfying enough, except when it comes to GUIs. I have to admit that
using Swing on Java got me far in no time, and it looks very good. And
best of all, there are great tutorials for it. I wasn't able to find
good tutorials for GUIs in O'Caml.

  The third point, well, the hump is growing, but unfortunately languages
such as Python which are "younger," have sadly outpaced O'Caml. Then
again, we cannot really change that.

  The fourth point is fundamental. For seasoned programmers, learning a
new language in some cases is easier, but you always have some baggage.
You always come with some preconceptions about how things work or should
work, and this is an impediment. The older the programmer, the less
likely he is to learn a new language.

  Teaching it to new programmers is better, and I hope more people teach
O'Caml. Here at McGill (in Montreal) we teach Java. I am pushing for
O'Caml, but it is an uphill battle. Changing the base language has a big
logistics problem: you have to adapt the rest of the courses somehow,
either by changing them, or creating some additional language courses on
the side. Either way it is difficult to implement. But this is
fundamental. Teaching O'Caml only at the level of compilers courses, or
theory of programming languages, or other advanced courses, will keep
the user-base small. To really increase the O'Caml community we have to
push for introductory courses in O'Caml, and this will also require more
texts (beyond O'Reilly's) translated to different languages.

  Now, the point of increasing the community, and teaching O'Caml, should
not be simply that we like the language, and we think it is cool. No,
the point is that we believe it is a very good tool for a very diverse
number of applications and audience, and that it promotes a better
approach to programming.

  So, if you are a teacher or student, try promote it in your school. If
you work in industry, talk about it with your boss and colleagues. If
you are part of the O'Caml development team: please, more tools!
specially good IDE's, and CASE tools! Maybe some of the industries that
have used it could fork some money to help build better development
support tools.

Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse