[Caml-list] objective caml and industry

[james woodyatt <jhw@wetware.com>]

On Thursday, Aug 29, 2002, at 03:11 US/Pacific, M E Leypold @ labnet 
wrote:
>
> Do you think so? I think 1 thing we can learn from Java, C, C++,
> FORTRAN and COBOL is, that the only thing a language doesn't need to
> "make headway into large systems development" is any smart mechanisms
> for composing systems. That is to say: Success doesn't depend on
> merit.

I promise not to be broken record about this, but there are some things 
holding Objective Caml back from being an optimal language choice for 
large industrial applications development.  I don't think any of the 
open problems in the research of mixin modules are on the list.

Here are the main issues holding back industrial developers from 
adopting Objective Caml, I think:

+ Hysteresis.  An awful lot of dollars have gone into the engineering 
of cubicle farms full of programmers who know Java, C++ and other iron 
age relics.  These are dollars invested in training, development tools, 
documentation, the works.  Using Objective Caml in university computer 
science courses can be inductive, but it's a long-term problem going 
forward.

+ Type inference is scary.  All the languages popular in industry today 
that have syntactical support for polymorphism are either not strongly 
typed or they require types to be explicitly defined prior to their 
use.  Industrial programmers will want to see the case made that type 
inference is a language feature worth the pain associated with learning 
how to work with it.  I think a good case can be made; I just haven't 
seen it.  And I'm in industry, so if it's kicking around in academia 
somewhere, it needs a wider audience.

+ Deployment issues.  Industry likes to be able to treat every line of 
source code it writes as if it were a trade secret, even when there's 
no good reason to do so.  It's like we're all queer for secrecy, or 
something.  The languages most popular with industry today permit 
relatively easy distribution of dynamically loadable modules either in 
native machine code or in an already widely adopted virtual machine 
code.  Objective Caml doesn't meet this criteria.

+ Stupidity.  Objective Caml's popularity in academia is a curse as 
well as a blessing.  For every coder like me who wonders if he should 
rather have gone into academia, industry has a hundred coders who think 
career academics are a fat lot of pencil-necked geeks who can't get 
"real" programming jobs.  This is why industry continues to be 
populated with idiots who think the reason Java programs so often 
perform badly is the garbage collector.  These are also the same people 
who will tell you that the syntax of Objective Caml is intolerably 
bizarre, while simultaneously raving about the elegance of C#.  (I'm 
not bitter.  I'm not bitter.)

I started writing these in descending order of importance, but by the 
time I got to the last one I began to think maybe I got it exactly 
backward.  All of these views are my own alone.

Maybe the two in the middle are the ones I would recommend the Caml 
team think about in their copious spare time.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

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