RE: [Caml-list] ANN: ChartPak - a data visualization library for the web

[Brian Hurt <brian.hurt@qlogic.com>]

On Mon, 20 Jan 2003, Mattias Waldau wrote:

> We all want Ocaml to be a success. We want people to develop commercial
> applications using Ocaml, because otherwise it will never be a success.

Agreed.

> 
> Having a lot of libraries that can be used without restrictions is a
> competitive advantage for a programming language. Ocaml has few
> libraries compared to alternatives, making it more difficult to develop
> applications.

I don't think libraries are the biggest problem Ocaml faces for commercial 
acceptance.  Both C and C++ gained widespread acceptance with libraries 
not much better than Ocaml's (and in C's case much worse).

I'm unusual in that programming is my hobby as well as my job.  Most of 
the professional programmers I know of don't program outside of work.  The 
more aggressive ones may occassionally take a class to put some new 
buzzword on the resume- but even then, the reasoning is (next-)job 
related, so the courses they take are for hot buzzword technologies.  But 
the average run of the mill programmer doesn't learn anything unless the 
Boss requires it- and the Boss only requires what he reads about in 
Infoweak or whatever magazine is dictating his management philosophy this 
week.

Look at the last 20 years.  In 1980, assembly language was still the "real 
programmers" language of choice, especially on the PC/DOS.  Assembler got 
phased out in favor of C, which a) had good interfacing with assembler, 
and b) let you still do most of your old assembler tricks.  C is a high 
level, portable assembler.  Then along came Object Oriented- remember back 
when OO was a buzzword?  There were many good OO languages, and even some 
C + OO attempt (objective C), but what was the language that won out?  
C++.  Primarily, IMHO, because C++ contains C as a (more or less) proper 
subset.  Which allows you to go on coding in (old familiar) C while 
telling your boss and marketing "Of course we're object oriented!  We're 
coding in C++!"

Over the next eight years, programmers slowly learned OO, on the job.  
And a lot of really bad pseudo-OO code was written, as inclination and
schedules allowed.  Then, along came Java- which is primarily a cleaned up
C++.  The only new ideas Java introduced to C++ programmers was garbage 
collection and virtual machines.  Neither of which were all that new 
really :-).  I've seen examples of virtual machines from the seventies, 
and garbage collection goes back to the early sixties if not farther.  But 
they were radical to the mainstream- radical and scary, judging from the 
amount of resistance I've seen Java face.

The trend here is that the mainstream only takes baby steps.  They can 
learn new things- using a high level language, or OO, or garbage 
collection- but only if they can do so on the job, still meeting 
(unreasonable) deadlines.  And I don't see how you can switch from Java to 
Ocaml, or any truely functional programming language, in such a way.  The 
only way I can see to make the transition is to just make the transition.  
Accept that you will be at a signifigantly reduced productivity while 
learning the new way of thinking.  I think Ocaml is *worth* making the 
transition, but I don't see people doing it.  Sorry.

> I think that many programmers just select the (L)GPL-license without
> thinking about the consequences, but I might be wrong. 

You can link to the LGPL just fine, which makes it much more usable in a 
commercial environment.  Which is why it was invented- it would be 
impossible to do commercial work on Linux at all without it (libc is 
LGPL'd).  Which is also why Stallman doesn't like it.  I personally think 
the LGPL works great for a library- anyone and everyone can *use* the 
library, but improvements to the library have to be shared.

But if I don't write the code, it's not my choice.

Brian


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