Re: [Caml-list] objective caml and industry

Re: [Caml-list] objective caml and industry

[Jonathan Coupe]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


[-- Attachment #2: Type: text/html, Size: 704 bytes --]

Re: [Caml-list] objective caml and industry

[Chris Hecker]

> www.jetcafe.org/~npc/doc/euc00-sendmail.html

I was interested to read this, but was sad to see that they didn't
actually ship the app, or even beta test it, according to this quote:

"After performing code cleanup based on Lennart's suggestions, we
prepared for an initial test release of the system during the summer
of 2000. That release has been put on hold while we perform
integration work with another complex legacy application and improve
our monitoring system."

Chris


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

Re: [Caml-list] mixin modules paper and future?

[M E Leypold @ labnet]

Chris Hecker writes:
 > 
 > >You're right, it is not at all planned for any future release. There
 > >are too many open questions yet even to make any guess whether it will ever
 > >find its way.  But thanks for your interest!
 > 
 > Hopefully you guys are actively working on solving the open 
 > problems.  :)  I think that this is an incredibly important feature for 
 > caml to make headway into large systems development.


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.

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

[Caml-list] objective caml and industry

[james woodyatt]

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

Re: [Caml-list] objective caml and industry

[Michael Vanier]

> Date: Thu, 29 Aug 2002 11:47:55 -0700
> From: james woodyatt <jhw@wetware.com>
> 
> 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.
> 

[good reasons omitted]

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

Now you're getting close to the real reason.  You could cast this in a less
negative light by noting that ocaml has a long learning curve, even for
programmers who know lots of other languages.  There are simply a lot of
unfamiliar features in ocaml for the vast majority of programmers.

However, I don't think you're being negative enough ;-)  In my experience,
most programmers react to anything resembling functional programming as if
it were made out of kryptonite.  The reason for this is that it forces them
to think in a different way than they're used to, and the resistance this
generates, even among otherwise very proficient coders, is nothing short of
astounding.  Consider that object-oriented programming has been around
since around 1967 (simula) and yet it took more than twenty years to become
mainstream.  And OO is a *much* less radical departure from ordinary
imperative programming than functional programming is.  FP has been around
since 1960 (lisp) and is *still* considered to be radical!  You can't
overestimate how conservative the community of programmers is.  We teach
scheme as an introductory programming language at Caltech, and we get a
*lot* of resistance even from supposedly open-minded freshmen (most of whom
know C and thus think they know the "right" way to program).  Also, the
average programmer, if he's even heard of functional programming (>99% of
them haven't) is convinced that it's incredibly inefficient and therefore
not worth learning.

Change takes time.  I think chasing after industry acceptance of ocaml is
the wrong strategy.  The right strategy is a grass-roots effort (building
up the language libraries, trying to attract the best hackers and using
ocaml in university courses).  This approach has worked well for python,
and I think it will work well for ocaml as well.

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

Re: [Caml-list] objective caml and industry

[james woodyatt]

On Thursday, Aug 29, 2002, at 15:57 US/Pacific, Michael Vanier wrote:
>
> [...] We teach scheme as an introductory programming language at 
> Caltech, and we get a *lot* of resistance even from supposedly 
> open-minded freshmen [...]

Tell them that computer *scientists* need to learn functional 
programming, and that if they really want to take courses in the 
software equivalent of automotive repair, then perhaps they should have 
considered studying at DeVry.

How's *that* for negative?


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

Re: [Caml-list] objective caml and industry

[Vitaly Lugovsky]

On Thu, 29 Aug 2002, Michael Vanier wrote:

> Change takes time.  I think chasing after industry acceptance of ocaml is
> the wrong strategy.

 It already accepted functional programming. Look at what Microsoft 
Research have done - isn't them represent the industry?

> This approach has worked well for python,
> and I think it will work well for ocaml as well.

 Python is treated by industry as a "new, better Smalltalk".
There is no such a way for functional programming - Lisp always was
a marginal approach.



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

Re: [Caml-list] objective caml and industry

[Michael Vanier]

> Date: Fri, 30 Aug 2002 17:13:43 +0400 (MSD)
> From: Vitaly Lugovsky <vsl@ontil.ihep.su>
> 
> On Thu, 29 Aug 2002, Michael Vanier wrote:
> 
> > Change takes time.  I think chasing after industry acceptance of ocaml is
> > the wrong strategy.
> 
>  It already accepted functional programming. Look at what Microsoft 
> Research have done - isn't them represent the industry?

Microsoft has a research interest in functional programming.  Though that's
perhaps encouraging, it's a far cry from trying to promote FP as something
programmers should learn.  C# (which they do promote as something
programmers should learn) is a long, long way from FP.  Still, every little
bit helps.

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

Re: [Caml-list] objective caml and industry

[Chris Hecker]

>+ Hysteresis.
>+ Type inference is scary.
>+ Deployment issues.
>+ Stupidity.

None of these are things the dev team needs to be working on...not that 
they're not important, but the community, if it got its act together, could 
solve all of these problems, or rather they could make as much headway on 
them as the dev team.  By contrast, the community cannot add massively 
subtle and complicated features to the compiler; only the dev team can do that.

Chris


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

Re: [Caml-list] objective caml and industry

[Jonathan Coupe]

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


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

Re: [Caml-list] objective caml and industry

[Jonathan Coupe]

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


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

Re: [Caml-list] objective caml and industry

[John Max Skaller]

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

Re: [Caml-list] objective caml and industry

[Oleg]

On Friday 30 August 2002 10:26 pm, John Max Skaller wrote:
> 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.

While Bagley's Shootout was good PR because of its Slashdot exposure, as I 
mentioned recently [1], Bagley confuses doubly-linked lists and deques, and 
then goes on to benchmark C++ doubly-linked list against O'Caml pre-allocated 
array. I don't want to say anything about scientific integrity, since I think 
INRIA simply overlooked the poor quality and extreme lopsidedness of the 
Shootout (They reference it on O'Caml's front page)

Regards,
Oleg

[1] http://caml.inria.fr/archives/200208/msg00332.html
The Shootout page I referenced changed a bit since Aug 19, 2002, but, still, 
it was the misleading results that were publicized.
-------------------
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