Re: [Caml-list] OCaml popularity (long!)

[mgushee@havenrock.com]

On 11 Mar 2003 at 10:26, Fred Yankowski wrote:

> Richard Gabriel, author of the famous "Worse is Better" paper about
> C/Unix vs Lisp, makes some interesting points in his recent book while
> discussing his theory of what it takes for a programming language to
> be accepted and evolve:
> 
>     The second mandatory feature is that the language cannot require
>     mathematical sophistication from its users. Programmers are not
>     mathematicians, no matter how much we wish and wish for it. And I
>     don't mean sophisticated mathematicians, but just people who can
>     think precisely and rigorously in the way that mathematicians can.

That's probably true as far as it goes, but I think statements about 
what a language can or cannot *require* miss the mark a bit. I would 
argue that there are very few languages that intrinsically require 
sophisticated thinking for basic programming (I would place Prolog 
among those few, but not Ocaml--more below), but that you do need 
that precision and rigor to write great programs in any language.

But how the language is presented to the world, through 
documentation, teaching, advocacy, and the activities and attitude of 
the user community, can make a big difference.

If I may illustrate from personal experience: some time early last 
year I decided that I wanted to learn a new language, and that it was 
going to be functional. My background as a programmer is mainly in 
Python and Java, with bits of Tcl, Perl, Ruby, and Visual Basic here 
and there. Oh, and I studied Asian history in college.

Why functional? I guess it's because I had been working with XSLT
for a couple of years. There were aspects of the language that had
been very puzzling. But someone pointed out to me that XSLT was a 
functional language, and as I began learning what functional 
programming was, it all started to make sense, and I wanted more. 
However, this was not an academic exercise; I was and am convinced 
that functional programming is a powerful tool for real-world tasks. 
But having practical goals obviously places some constraints on your 
choices: you need a good selection of libraries for real-world 
programming tasks (database interface, GUI, text processing, 
graphics, system interface, and so on), and you need a language that 
can be learned in a reasonable time period. So Prolog was clearly out 
;-)

My first stop was Erlang, partly because it was developed by and for 
industry. But that didn't last too long. Ericsson's OTP interpreter 
(or VM? I can't remember) was horribly slow, the selection of 
libraries was poor, there doesn't seem to be a serious effort to 
integrate Unicode into the core platform, and the documentation was 
abysmal (mostly disorganized rather than incomplete, I suppose, but 
incoherent information isn't much better than none).

Then I found Haskell. It was a good learning experience, but after a 
few weeks of intensive study and experimentation, my feeling was: 
"Yes, Haskell, you are the One True Language. Now go away and let me 
get some work done." Though I really appreciated Haskell on a 
conceptual level, there were two major reasons I gave up on it. One 
was that, although there is a reasonable selection of libraries, when 
you look closely you find that many of them are suffering from bit-
rot; in fact, the Haskell community seems to be dominated by 
academics who feel no need to develop generally useful tools. That's 
fine, but not what I was looking for.

My other big problem with Haskell was ... you guessed it: monads! I 
must have read every introduction to monads that's available on line 
(and there are at least half a dozen), but I still don't really 
understand them. Without monads, you can't do any real work in 
Haskell, and monads are universally acknowledged to be a difficult 
concept. Yet every introductory text I have seen on Haskell insists 
that you learn the theory of monads before you can learn how to do 
things like I/O.

Since I don't understand monads, maybe I'm missing something, but 
this insistence on theory before practice seems like pure dogma to 
me. I've even seen two or three Haskell tutorials that open with 
statements to the effect that "I could teach you how to write a 
Hello, World program, but I won't, because then you wouldn't 
understand why Haskell is so great."

I don't buy that argument--at least I don't accept that it's 
universally true. People have different learning styles, but many 
learn best by doing. I don't know how typical I am, but I find that a 
good experience working with a new language naturally leads to a 
desire for deeper understanding.

Which brings me around, finally, to OCaml. The main reasons I like 
OCaml and will probably stick with it are:

  OCaml and its community are focused on promoting good design and  
  good programming practices, but not on enforcing theoretical  
  orthodoxy. Knowledge about OCaml is freely available to those who 
  want to learn; they don't have to think in any certain way;

  There is a good selection of libraries available. Certainly there 
  are some gaps, but OCaml has up-to-date tools for a wide variety of 
  common programming tasks; and, on a related note:

  OCaml seems to have momentum. Though the language isn't wildly 
  popular, useful applications and libraries are being developed all 
  the time; there is something new almost every week.
  
>     Furthermore, types that try to do more than that are a hindrance
>     to understanding. For example, abstract data types allow one to
>     write programs in which the interface is completely separate from
>     the implementation. Perhaps some large programming teams care a
>     lot about that, but a lot of programming goes on in ones and twos,
>     maybe threes. Types of this variety, with complicated syntax and
>     baffling semantics, is a hindrance to programming for many of
>     these folks.

I wonder. It seems to me that the need for sophisticated program 
design stems mainly from the complexity of the problem. He also seems 
to be saying that larger teams are smarter ... because they have more 
bodies? My experience is just the opposite: the small teams I've 
known are smarter because every member is highly skilled and internal 
communications are easier. 

Let me propose an alternate (and perhaps somewhat cynical) view. 
Companies that employ large programming teams tend to favor Java. 
They may or may not be aware that there are other languages that 
foster much higher productivity. But Java is good for large teams, 
partly because its rigid OO paradigm means there are relatively few 
ways to structure a program, so managers can assign tasks with 
relative ease. Also, Java keeps everyone busy.

Now, suppose someone were to propose that a large team adopt a 
"smarter" language, such as OCaml. Well, either all team members can 
handle it, or they can't. If some people can't handle it, then you 
have to either lay them off or find other work for them to do. Big 
problem for management. But what if all team members *can* handle it? 
What if they all love their new language? That may sound good, but 
now suddenly you have a large team full of highly motivated 
developers finishing their assigned tasks in half the time it used to 
take them. Then what? Probably some will just get bored, but others 
will start wanting to get more involved with the "big picture." Also 
a big problem for management.

However much the business press may talk about people being 
empowered, the reality is that most large corporations assume--even 
depend on the fact--that the large majority of their employees are 
mediocre. Too many people working too effectively would upset the 
status quo, and is therefore a scary thought.

So I say that Java is a corporate-friendly language, and OCaml, for 
better or worse, is not.

--
Matt Gushee
Englewood, CO USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners