Re: [Caml-list] objective caml and industry

[John Max Skaller <skaller@ozemail.com.au>]

james woodyatt wrote:

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



> + Hysteresis. 


Heh. Also known as 'inertia'. In my opinion, this is
THE MAJOR problem. It isn't a technical problem.
The coming English translation of the new O'Reilly Ocaml
book is the most significant step forward here since
Bagley's Shootout showed Ocaml is the top performing
language after C.

> + Type inference is scary.


Yes it is. Felix deliberately refuses to do it.
But it does do type deduction (bottom up).

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


Yes you have, you just haven't recognized that INDUSTRY
itself has already made the case!

Most scripting languages, such as Python, support
polymorphism, and do not have type declarations.
QED. Case proven. People hate writing useless
type declarations.

Ocaml is even better, because it ALSO supports static
type checking.

No, it is NOT inference that is scary. It is the horrid
error messages.

That is a deep technical problem, which the Ocaml
team is successfully addressing. The most obviously
unhelpful messages have been improved
just going from 3.04 to 3.05/6. Much more work
is needed here, for example, to locate the places
where the engine gets its data, so that it can say

"here, x is infered to be type T, but here, it is
used as type T'"

whereas at present, the first location isn't known
to the engine, and so it often reports an
error in the "wrong" location.

But don't be too depressed: if you've seen a few

C++ template error messages, we'll, they aren't
so easy to figure out either :-)

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


There are many other reasons for shared libraries.
Even now, I really NEED them in my Felix compiler.
My prior Ocaml project, Vyper, required them too.

In both cases these are technical demands, not a matter

of commercial requirements.

The context is different (Vyper had to emulate
Python's dynamic loading, Felix needs to be able
to compile and then execute code within the
compiler). Many other systems are continuously
running and require the ability to be upgraded
in pieces without stopping the process.

Dynamic loading simply isn't negotiable these days.
A translator that can't do it is useless in a very
large class of commercial applications.


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


Of course they are (ducks for cover :-)

> This is why industry continues to be populated with 
> idiots 


now who is being prejudiced?

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


It is, believe me, it is. So is C++ syntax :-)
---
My data: I used Ocaml in a heavy commerical environment,
(the job was to produce a programming language).

The major concern was #1: lack of programmers.
The other concern was the licence.
The job was killed, not because of Ocaml,
but because in an engineering shop few had any idea
of the requirements for a research project,
or the issues involved in designing a programming language.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


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