Re: [Caml-list] Re: productivity improvement

Re: [Caml-list] Re: productivity improvement

[Ohad Rodeh]

The numbers for the Ensemble group communication
(www.cs.cornell.edu/Info/Projects/Ensemble),
where more like 7:1, instead of 2:1.

The previous incarnations of the system were written in C. Comparing
line-counts for similar modules
we got a 7:1 reduction when using OCaml. The resulting system was also a
lot more stable and easier
to maintain.

This would counteract the notion of Caml being good only for producing
compilers.

      Ohad.

-----------------------------------------------------------------------------------

Ohad Rodeh
tel: +972-3-6401641
IBM Haifa, storage research


                                                                                                                                  
                      Dave Berry                                                                                                  
                      <daveb@tardis.ed.ac.uk        To:       Markus Mottl <markus@oefai.at>, Oleg <oleg_inconnu@myrealbox.com>   
                      >                             cc:                                                                           
                      Sent by:                      Subject:  Re: [Caml-list] Re: productivity improvement                        
                      owner-caml-list@pauill                                                                                      
                      ac.inria.fr                                                                                                 
                                                                                                                                  
                                                                                                                                  
                      14/07/2002 23:44                                                                                            
                      Please respond to Dave                                                                                      
                      Berry                                                                                                       
                                                                                                                                  
                                                                                                                                  



At 13:43 12/07/2002, Markus Mottl wrote:
>I'd say that depending on the kind of the problem 1:3
>to 1:10 is reasonable and fits well to the experience of others. E.g.,
>the Erlang developers also report productivity gains in this range on
>large-scale commercial projects. OCaml will most likely have similar
>ratios.

I find it unlikely that OCaml would increase productivity as much as
Erlang. Erlang is designed primarily for concurrent programming (I
believe).  When people attempt concurrent programming in C, C++ or Java,
they typically use primitive notions such as threads and locks.  This is
noticeably harder and more error-prone than sequential programming.
Therefore any language that concentrates on this problem has more to gain
than a primarily sequential language.  AFAIK, OCaml uses threads and locks
for concurrent programming, and so is no better in this respect than
conventional languages (it could even be worse, depending on how its GC
interacts with threads and distributed code).

As a commercial manager, I've seen a productivity improvement of about 50%
using Java over C++ -- mainly arising from automatic memory management, and
a slightly cleaner language.  I would expect OCaml to have that 50%, and
perhaps another for a more expressive type system, making 2:1.  For some
problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
comparison, this is also the productivity improvement I'd expect to see
using Visual Basic over C/C++ for small GUI/Database problems.

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




-------------------
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] Re: productivity improvement

[Dave Berry]

At 09:00 15/07/2002, Ohad Rodeh wrote:
>The previous incarnations of the system were written in C. Comparing
>line-counts for similar modules we got a 7:1 reduction when using OCaml.

I'm rather sceptical of line-counts as a measurement of overall
productivity, but that's still an impressive improvement.  For constrast,
Andrew Appel wrote the sample compiler for his textbook in C, SML and Java,
and found that SML was the most concise, but not by anything like 7:1.

>The resulting system was also a lot more stable and easier
>to maintain.

Now that I can believe!

Dave.
-------------------
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] productivity improvement

[Oleg]

Hi

As part of learning O'Caml I was rewriting small personal utility programs 
from C++ to O'Caml and I have not seen any productivity improvement so far. 
Possibly, this is because I essentially use the same imperative style or 
because my knowledge of O'Caml is rudimental or because there is no 
productivity enhancement, at least for the programs I was translating or for 
small programs in general.

What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
vs C++ productivity improvement (in terms of program size) and where can I 
find them?

Thanks
Oleg

P.S. Just trying to stay motivated.
-------------------
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] Universal Serializer (was: productivity improvement)

[Nicolas Cannasse]

> > This is no an ocaml specific productivity improvement but the ability
> > to marshal a data structure without having to write any data structure
> > specific code is very productive.

BTW OCaml functional programming and memory management are two ways of
increasing productivity. Pattern matching on structures is also wonderful.
For most of the programs, I will say that the productivity rate against C is
around 1:3.

Nicolas Cannasse

-------------------
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] Universal Serializer (was: productivity improvement)

[John Max Skaller]

>
>
>
>BTW OCaml functional programming and memory management are two ways of
>increasing productivity. Pattern matching on structures is also wonderful.
>For most of the programs, I will say that the productivity rate against C is
>around 1:3.
>
>Nicolas Cannasse
>
You must be an academic.:-) Try between 10:1 and 100:1,
*assuming* that any libraries you need are available,
and a reasonably complex piece of software.

You just can't underestimate how difficult it is to find
bugs in C codes of reasonable size. Such bugs almost never
happen in Ocaml. The biggest problem in Ocaml is type inference,
and the resulting loss of localisation of error diagnostics, but
such compile time errors can be resolved *definitely*;
that is, you know for sure when you've fixed them
(because the compiler stops hassling you).

Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
were written in Ocaml .. it might actually work!

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

[Caml-list] Re: productivity improvement

[Oleg]

On Wednesday 10 July 2002 12:06 pm, John Max Skaller wrote:
> >BTW OCaml functional programming and memory management are two ways of
> >increasing productivity. Pattern matching on structures is also wonderful.
> >For most of the programs, I will say that the productivity rate against C
> > is around 1:3.
> >
> >Nicolas Cannasse
>
> You must be an academic.:-) Try between 10:1 and 100:1,
> *assuming* that any libraries you need are available,
> and a reasonably complex piece of software.

Looking at Halo [1] credits, one can see that it was developed by about 10 
programmers (there were also testers and artists involved). A single O'Caml 
programmer capable of developing such a game alone should certainly stand to 
make tons of money. Then why don't we see much software written in O'Caml?

I'm not buying the argument that "O'Caml isn't used in the industry because 
investors and project managers are stupid". You don't need a project manager 
if you can replace a team of 100 C/C++ programmers alone (or just 10 of 
them if you work in your spare time < 1 hour a day) [2]

Regards,
Oleg

[1] By far the best first-person-shooter game I've ever played in terms of 
AI, graphics, playability and relative freedom from bugs.

[2] The number is supposed to be even higher if you take into account that an 
n-fold increase in individual productivity is equivalent to more than an 
n-fold increase in team size.
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Oleg wrote:
> Looking at Halo [1] credits, one can see that it was developed by about 10 
> programmers (there were also testers and artists involved). A single O'Caml 
> programmer capable of developing such a game alone should certainly stand to 
> make tons of money. Then why don't we see much software written in O'Caml?

Easy: almost all commercial and most academic programmers have never
heard of OCaml. That's a fact.

> I'm not buying the argument that "O'Caml isn't used in the industry
> because investors and project managers are stupid".

Nobody has ever said so. They are at least uninformed what concerns
this language. And even if they are informed, there are many commercial
reasons why OCaml might be a sub-optimal choice: lack of programmers,
lack of libraries for commercial purposes, etc. This is not just a matter
of language features.

> You don't need a project manager if you can replace a team of 100 C/C++
> programmers alone (or just 10 of them if you work in your spare time <
> 1 hour a day) [2]

Another reason why project managers don't want OCaml :-)

Now seriously, I don't quite get your argument. Do you have any
imagination, how difficult it is to find OCaml-programmers? I can tell
you of maybe three somewhat competent OCaml-programmers in my country.
Other programmers here are not incompetent in the sense that they don't
know how to program in general but in the sense that they have never used
(most often not even heard) of this language. If I founded a company
here using this technology, I'd get into very serious troubles when my
main programmer gets a brick on his head. Just too risky!

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

Re: [Caml-list] Re: productivity improvement

[Oleg]

On Friday 12 July 2002 07:23 am, Markus Mottl wrote:
>  If I founded a company
> here using this technology, I'd get into very serious troubles when my
> main programmer gets a brick on his head. Just too risky!

That's what insurance companies are for. IAE why would you want to hire more 
programmers if you were worth a hundred of them (by John's estimate)? 

Regards,
Oleg
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Oleg wrote:
> On Friday 12 July 2002 07:23 am, Markus Mottl wrote:
> >  If I founded a company
> > here using this technology, I'd get into very serious troubles when my
> > main programmer gets a brick on his head. Just too risky!
> 
> That's what insurance companies are for. IAE why would you want to hire more 
> programmers if you were worth a hundred of them (by John's estimate)? 

Insurance = costs. Furthermore, 1:100 sounds quite a bit too
astronomical. I'd say that depending on the kind of the problem 1:3
to 1:10 is reasonable and fits well to the experience of others. E.g.,
the Erlang developers also report productivity gains in this range on
large-scale commercial projects. OCaml will most likely have similar
ratios.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

Re: [Caml-list] Re: productivity improvement

[Pierre Weis]

Hi Markus,
[...]
> Insurance = costs. Furthermore, 1:100 sounds quite a bit too
> astronomical. I'd say that depending on the kind of the problem 1:3
> to 1:10 is reasonable and fits well to the experience of others. E.g.,
> the Erlang developers also report productivity gains in this range on
> large-scale commercial projects. OCaml will most likely have similar
> ratios.

I completely agree with you on those, somewhat impossible to obtain and
prove, productivity ratio gains. 1:3 to 1:10 is reasonable.

However, an interesting ratio seems to be forgotten in the discussion:
infinity :)

I mean, I know a lot of problems that could simply not have been
solved in any other language, and in this casess we observe this
extreme limit ratio.

No flame, please: I know that SML or Haskell could do roughly speaking
the same as Caml could do for the programmer, I also know that once
the program has been written and is fairly stable you can rewrite it
in any other language you want, even C++ or Java, provided you have
enough time and money. I also do know that there are a lot of
situations where you do not have enough time and/or money...

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Pierre Weis wrote:
> I completely agree with you on those, somewhat impossible to obtain and
> prove, productivity ratio gains. 1:3 to 1:10 is reasonable.
> 
> However, an interesting ratio seems to be forgotten in the discussion:
> infinity :)
> 
> I mean, I know a lot of problems that could simply not have been
> solved in any other language, and in this casess we observe this
> extreme limit ratio.

Well, this is a simple consequence of us humans having finite brains
(though some hack\b\b\b\bprogrammers don't believe that ;)

Even if FPLs reduce complexity only slightly, this implies that there
must be previously insoluble problems that become solvable by their
application.

> No flame, please: I know that SML or Haskell could do roughly speaking
> the same as Caml could do for the programmer, I also know that once
> the program has been written and is fairly stable you can rewrite it
> in any other language you want, even C++ or Java, provided you have
> enough time and money. I also do know that there are a lot of
> situations where you do not have enough time and/or money...

Right, as soon as there are constraints (scarce resources), economical
thinking demands more efficient tools (languages).

Regards,
Markus

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

Re: [Caml-list] Re: productivity improvement

[Dave Berry]

At 13:43 12/07/2002, Markus Mottl wrote:
>I'd say that depending on the kind of the problem 1:3
>to 1:10 is reasonable and fits well to the experience of others. E.g.,
>the Erlang developers also report productivity gains in this range on
>large-scale commercial projects. OCaml will most likely have similar
>ratios.

I find it unlikely that OCaml would increase productivity as much as
Erlang. Erlang is designed primarily for concurrent programming (I
believe).  When people attempt concurrent programming in C, C++ or Java,
they typically use primitive notions such as threads and locks.  This is
noticeably harder and more error-prone than sequential programming.
Therefore any language that concentrates on this problem has more to gain
than a primarily sequential language.  AFAIK, OCaml uses threads and locks
for concurrent programming, and so is no better in this respect than
conventional languages (it could even be worse, depending on how its GC
interacts with threads and distributed code).

As a commercial manager, I've seen a productivity improvement of about 50%
using Java over C++ -- mainly arising from automatic memory management, and
a slightly cleaner language.  I would expect OCaml to have that 50%, and
perhaps another for a more expressive type system, making 2:1.  For some
problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
comparison, this is also the productivity improvement I'd expect to see
using Visual Basic over C/C++ for small GUI/Database problems.

Dave.
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Sun, 14 Jul 2002, Dave Berry wrote:
> At 13:43 12/07/2002, Markus Mottl wrote:
> >I'd say that depending on the kind of the problem 1:3
> >to 1:10 is reasonable and fits well to the experience of others. E.g.,
> >the Erlang developers also report productivity gains in this range on
> >large-scale commercial projects. OCaml will most likely have similar
> >ratios.
> 
> I find it unlikely that OCaml would increase productivity as much as
> Erlang. Erlang is designed primarily for concurrent programming (I
> believe).  When people attempt concurrent programming in C, C++ or Java,
> they typically use primitive notions such as threads and locks.  This is
> noticeably harder and more error-prone than sequential programming.
> Therefore any language that concentrates on this problem has more to gain
> than a primarily sequential language.

Erlang is very niche-specific (though, fault-tolerant distributed
computation is surely a worthy niche). I think that Erlang would find
it tough to compete against OCaml in most other niches, be it symbolic
or numeric computation, be it in terms of safety or performance-wise.

I am pretty convinced that a ratio of 1:10 in comparison to mainstream
imperative languages for tricky symbolic computation as found in theorem
provers, compilers or also in my field (symbolic machine learning
systems) is not absurd. Note that 1:10 was the upper bound for estimated
productivity gains on my projects over C, 1:3 the lower bound. Other
projects may have other bounds.

> AFAIK, OCaml uses threads and locks for concurrent programming,
> and so is no better in this respect than conventional languages (it
> could even be worse, depending on how its GC interacts with threads
> and distributed code).

I really don't think that OCaml has much to fear here. It's support for
threads is excellent.

> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

Visual Basic lives from a wealth of tailor-made libraries and development
tools for such applications. This is "application development" rather
than "programming". It's difficult to estimate productivity gains by
language features as long as libraries/tools do most of the job. You'd
have to be specific about what you actually want to measure.

Anyway, I'd be really surprised if my average productivity gain using
OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
it would be higher than this. Doubling the factor seems quite realistic
to me.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

Re: [Caml-list] Re: productivity improvement

[Alwyn Goodloe]

  I'm not so sure it's that easy to compare productivity for most apps, no
theorem proving isn't a common app. For most apps written in Java, the
extensive class library accounts for much of the productivity gains over
C/C++.  Think of the difference in writing a simple web server in Java
over C/C++.  All you need to do is pick up the O'Riley Books on network
programming and you are off in a day or two. For most common network
programming you can get away without the details required for Unix
socket/thread programming. This is where O'Caml's library falls short of
Java's. While O'Caml has a good library it's nowhere near as extensive as
Java's.  Let's face it there are alot more people contributing to it and
from my experience the quality is very good.  In O'Caml, the productivity
gains come from the programming style.  If you have to build everything
from scratch or when the libraries are comprable I would bet that O'Caml
usually beats Java.


Alwyn Goodloe
agoodloe@gradient.cis.upenn.edu

On Mon, 15 Jul 2002, Markus Mottl wrote:

> On Sun, 14 Jul 2002, Dave Berry wrote:
> > At 13:43 12/07/2002, Markus Mottl wrote:
> > >I'd say that depending on the kind of the problem 1:3
> > >to 1:10 is reasonable and fits well to the experience of others. E.g.,
> > >the Erlang developers also report productivity gains in this range on
> > >large-scale commercial projects. OCaml will most likely have similar
> > >ratios.
> >
> > I find it unlikely that OCaml would increase productivity as much as
> > Erlang. Erlang is designed primarily for concurrent programming (I
> > believe).  When people attempt concurrent programming in C, C++ or Java,
> > they typically use primitive notions such as threads and locks.  This is
> > noticeably harder and more error-prone than sequential programming.
> > Therefore any language that concentrates on this problem has more to gain
> > than a primarily sequential language.
>
> Erlang is very niche-specific (though, fault-tolerant distributed
> computation is surely a worthy niche). I think that Erlang would find
> it tough to compete against OCaml in most other niches, be it symbolic
> or numeric computation, be it in terms of safety or performance-wise.
>
> I am pretty convinced that a ratio of 1:10 in comparison to mainstream
> imperative languages for tricky symbolic computation as found in theorem
> provers, compilers or also in my field (symbolic machine learning
> systems) is not absurd. Note that 1:10 was the upper bound for estimated
> productivity gains on my projects over C, 1:3 the lower bound. Other
> projects may have other bounds.
>
> > AFAIK, OCaml uses threads and locks for concurrent programming,
> > and so is no better in this respect than conventional languages (it
> > could even be worse, depending on how its GC interacts with threads
> > and distributed code).
>
> I really don't think that OCaml has much to fear here. It's support for
> threads is excellent.
>
> > As a commercial manager, I've seen a productivity improvement of about 50%
> > using Java over C++ -- mainly arising from automatic memory management, and
> > a slightly cleaner language.  I would expect OCaml to have that 50%, and
> > perhaps another for a more expressive type system, making 2:1.  For some
> > problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> > comparison, this is also the productivity improvement I'd expect to see
> > using Visual Basic over C/C++ for small GUI/Database problems.
>
> Visual Basic lives from a wealth of tailor-made libraries and development
> tools for such applications. This is "application development" rather
> than "programming". It's difficult to estimate productivity gains by
> language features as long as libraries/tools do most of the job. You'd
> have to be specific about what you actually want to measure.
>
> Anyway, I'd be really surprised if my average productivity gain using
> OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
> it would be higher than this. Doubling the factor seems quite realistic
> to me.
>
> Regards,
> Markus Mottl
>
> --
> Markus Mottl                                             markus@oefai.at
> Austrian Research Institute
> for Artificial Intelligence                  http://www.oefai.at/~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
>


-------------------
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] Re: productivity improvement

[Dave Berry]

At 00:13 15/07/2002, Markus Mottl wrote:
>Erlang is very niche-specific (though, fault-tolerant distributed
>computation is surely a worthy niche). I think that Erlang would find
>it tough to compete against OCaml in most other niches

That Erlang is niche-specific is exactly my point -- it's a niche that is
ripe for major productivity improvements, and I can believe a factor of
10:1 for Erlang over traditional languages within that niche.

Other niches are less likely to show such gains, IMO -- even theorem
provers and compilers.  A gain of 10:1 means that you could write in 5
weeks using OCaml what it would take you a year to write in C.  I've used
SML and C/C++ to write compilers, and I didn't see anything like that sort
of improvement.  Even if OCaml is more productive than SML, it still seems
unlikely to me to reach a 10:1 improvement, at least for most people.

I really think you should be careful when trumpeting productivity
improvements. People have seen a lot of hype for various technologies, and
are understandably sceptical.  It's best if you can produce actual figures
(this is hard, of course).

>Visual Basic lives from a wealth of tailor-made libraries and development
>tools for such applications. This is "application development" rather
>than "programming". It's difficult to estimate productivity gains by
>language features as long as libraries/tools do most of the job. You'd
>have to be specific about what you actually want to measure.

I don't think it's worthwhile to distinguish between "languages",
"libraries" and "tools", when considering productivity. 

>Anyway, I'd be really surprised if my average productivity gain using
>OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
>it would be higher than this. Doubling the factor seems quite realistic
>to me.

OK, I'll take that on board.

Dave.
-------------------
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] Re: productivity improvement

[Eric Merritt]

--- Dave Berry <daveb@tardis.ed.ac.uk> wrote:
> At 00:13 15/07/2002, Markus Mottl wrote:
> >Erlang is very niche-specific (though,
> fault-tolerant distributed
> >computation is surely a worthy niche). I think that
> Erlang would find
> >it tough to compete against OCaml in most other
> niches
> 
> That Erlang is niche-specific is exactly my point --
> it's a niche that is
> ripe for major productivity improvements, and I can
> believe a factor of
> 10:1 for Erlang over traditional languages within
> that niche.
> 

I would have to disagree with this guys. Erlang is no
more niche specific the Ocaml, C, C++, or any other
general purpose language. Simply becuase it was
created at Ericsson (a telecom company) and its used
primarily in telecom apps at the moment does not make
it a niche language. Now this niche mentioned is
filled very well by Erlang, but Erlang is by no means
limited to that niche. Many people that have never
seen or used Erlang by into this myth but it is simply
not the case. Granted it uses a somewhat diffrent
paradigm then the standard mainstream langauges be
they imperative or functional, but that doesn't make
it a niche langauge by defualt. Using that argument
all functional languages would be niche langauges, for
that matter so would OO languages. 

In any case, Erlang is not a niche langauge.

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------
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] Re: productivity improvement

[Alessandro Baretta]

Dave Berry wrote:
> At 13:43 12/07/2002, Markus Mottl wrote:
> 
>>I'd say that depending on the kind of the problem 1:3
>>to 1:10 is reasonable and fits well to the experience of others. E.g.,
>>the Erlang developers also report productivity gains in this range on
>>large-scale commercial projects. OCaml will most likely have similar
>>ratios.
> 
> 
> [comments on the use of Erlang for concurrent programming]

 From this standpoint, Erlang would probably yield a higher 
productivity in intrinsically concurrent problems. But a 
good deal of programming is intrinsically "sequential", from 
the point of view of traditional Von Neumann languages, 
"applicative", from the point of functional languages. 
Further, purely functional code (no refs or mutables) has no 
need for mutexes.

> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

I respect your opinion, but I do believe that you are not 
considering issues arising from the debugging and 
maintainance of code. In my opinion, developing an 
application from the ground up is a task that might show 
only a marginal improvement of productivity, but in the 
subsequent phase of debugging and maintainance, I expect the 
difference should be much more significant. An overall 3:1 
productivity improvement is not unreasonable.

Alex

-------------------
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] Re: productivity improvement

[Eray Ozkural]

On Sunday 14 July 2002 23:44, Dave Berry wrote:
> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

I'd expect a much higher ratio for compilers or any form of symbolic 
computation. Having went through a few C++ compilers recently I would say 
more than 1:10. The problem is that I don't have a C++ compiler written in 
ocaml in front of me, so that's just a guess ;) However, compilers for 
languages with more complex semantics (like Haskell) seems to be achievable 
in the magnitude of a few ten thousands of lines while your casual Mono 
compiler took some 10^6 lines in C if you will remember. That ratio would be 
something like 1:30, 1:40 against C, and I suspect it would still be 1:10 to 
1:20 for C++.

For a C++ compiler, the ratio would be about the same since C++ has simpler 
semantics but a more involved syntax than well designed languages. Hence more 
code for syntax, less code for semantics in the case of C++ probably making 
the compiler as complex as Haskell.

That ratio would wildly change with respect to design of the compiler of 
course. There are lots of choices even in the simplest matters. Not to 
mention the need for a good programmer. A bad programmer can eventually
manage to blow up the code size worse than a good C++ implementation ;)

Just a rough comparison,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Re: productivity improvement

[Dave Berry]

At 11:38 15/10/2002, Eray Ozkural wrote:
>your casual Mono 
>compiler took some 10^6 lines in C if you will remember. That ratio would be 
>something like 1:30, 1:40 against C, and I suspect it would still be 1:10 to 
>1:20 for C++.

Microsoft's SSCLI distribution, which is freely downloadable, includes a
fast industrial-strength C# to .NET compiler. This is written in less than
100,000 lines of C++.  By your reckoning, you should be able to write an
equivalent compiler in 5,000 lines of O'Caml.  Are you willing to produce
an example compiler to substantiate your claim?

>For a C++ compiler, the ratio would be about the same since C++ has simpler 
>semantics but a more involved syntax than well designed languages.

I'm staggered at your suggestion that C++ has a simple semantics.  To me, a
major advantage of the ML family is that their semantics is relatively simple.

Dave.
-------------------
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] Re: productivity improvement

[Eray Ozkural]

On Friday 18 October 2002 00:27, Dave Berry wrote:
> >For a C++ compiler, the ratio would be about the same since C++ has
> > simpler semantics but a more involved syntax than well designed
> > languages.
>
> I'm staggered at your suggestion that C++ has a simple semantics.  To me, a
> major advantage of the ML family is that their semantics is relatively
> simple.
>

C++ has a less sophisticated and mathematically lacking semantics devoid of 
generality compared to ML family, especially modern incarnations such as 
ocaml.

The hard part of writing a C++ compiler is coping with several syntactic 
ambiguities and incoherent semantics (such as in templates and type system) 
rather than realizing a well defined and expressive semantics.

Where in C++ is orthogonality, reliability, parametrized/recursive  types, 
parametrized modules, etc.? I'm staggered at you claiming more than C++ 
deserves. Where C++ ought to be strongest, OOP, ocaml is much more general 
and complete. In other design objectives ocaml beats C++ by a good measure. 
No derivative of C can be a really good programming language design and C++ 
is not an exception.

It isn't just a coincidence that programming language research focuses on 
functional languages a la ML.

And that the industry uses largely C++ has nothing to do with semantics. I 
think it is clear why the industry prefers one language over another; it is 
collective stupidity.

As a side note, once you get past the parsing stage it should be relatively 
easy to implement an optimizing C++ or C# compiler. I've been working on a 
C++ parser, but the syntax is so hard it's almost impossible to implement 
everything and verify that it really works. (Another indication that the 
design sucks) The syntactic analyzer itself could take a couple of thousands 
of lines. All in all it would still take 10000 or more lines. I would 
estimate somewhere about 10000-20000 lines for a C++ compiler. A C# compiler 
could be made smaller.

If we had a good C++ parser written in ocaml or haskell we could proceed to a 
full compiler very fast. It just hasn't been done before.

I can put forward a challenge in front of you and I think you would be much 
more helpless than I am about writing a C++ compiler from scratch -- which is 
no easy undertaking whatever the implementation language is. What about 
writing a full-fledged ocaml or haskell compiler in C++? I am pretty sure 
that would be an overwhelming task, something which would require more than 
100.000 lines of C++ code.

I intend to release a version of my parser when it is able to parse KDE 
headers. Maybe then people experienced in C++ parsers can work on a 
full-fledged compiler. I'm writing a top-down parser like in the recent 
versions of g++ using haskell Parsec library.

Thanks,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Re: productivity improvement

[Dave Berry]

Eray, I think you misunderstand where I'm coming from.  I would love to see
more people using ML instead of C++.  I was part of a team that produced
one of the commercial SML compilers. All three commercial SML compilers
have failed, partly because it's very difficult to persuade people to
switch.  People aren't stupid, and they won't switch to a new language
without some compelling evidence that it gives an advantage.  I believe
that a 2:1 or 3:1 gain in a meaningful measure -- the best measure being
overall cost -- would be sufficient to persuade a reasonable number of
people to switch.  But, we need concrete evidence.  This is hard to obtain,
because few people have the time to write a project twice, using different
languages.  What's more, when studies of this sort have been done,
comparing more conventional languages, the results have shown that the
choice of language makes little difference to the overall cost of the
project.  So there's a widespread suspicion of claims that language X or Y
increases productivity by significant amounts.

In this context, figures plucked from the air are, at best, not helpful; I
think they're actually counter-productive.  To an extent, the bigger the
claims, the more counter-productive they are, because they're easier to
challenge.  I would rather have one verifiable claim of a 3:1 productivity
improvement -- which is a pretty big win -- than a hundred unverifiable
claims of 10:1, 20:1 or even 40:1 gains.  (Given earlier postings on this
thread, it's worth reiterating that the type of program is also vital --
e.g. figures for a one-week project may not scale to a ten-year project).

This thread gave one very useful example: the rewrite of Ensemble.  IIRC,
this gave a 7:1 gain in LoC over the original C version.  Even if one
allows for the benefit of writing the program a second time, and for the
fact that LoC doesn't necessarily correlate directly to development time,
this is still an impressive figure.

Way back when this thread started, I quoted another example: Andrew Appel's
Tiger compiler.  This has three versions, one in C, one in Java, and one in
SML.  The SML is shorter, but not to such a great extent.  (I need to
recheck the actual figures).

Dave.



-------------------
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] Re: productivity improvement

[Michael Vanier]

Dave,

I agree with your comments.  I think it's very important that we (ocaml
fans) avoid becoming dogmatic.  I think most of us would agree that we
would rather code in ocaml than in just about any other language.  That
said, the choice of problem is going to make a world of difference in
whether ocaml is really the language of choice.  Some problems are just
going to be more easily solved (or produce better results) in other
languages, and we just have to accept this.  No one tool is perfect for all
tasks.  For instance, trying to use ocaml in domains where C or Fortran
rule (heavy numerical computing on simple data structures) is interesting
but probably doomed to produce inferior results in many cases (unless you
use ocaml as a fancy compiler or partial evaluator that spits out C code,
that is ;-)).  As the ocaml developers have pointed out, when the data
structures become very intricate, then ocaml starts to win in a big way.

As for popularity, I feel that the grassroots approach is best.  Pass the
word about ocaml on to the ten best hackers you know, try to get them
hooked on the language, use it to tackle problems that would be absurdly
hard in other languages (not ones that can be done well in any language),
and publicize your results.  This will work, although it won't work
overnight.  I've already noticed that more and more courses in CS
departments are using ocaml because of its flexibility; this by itself is
going to introduce ocaml to a large number of new students, many of whom
will spread the word to others.

Mike

> Date: Sun, 20 Oct 2002 13:46:47 +0100
> From: Dave Berry <daveb@tardis.ed.ac.uk>
> 
> Eray, I think you misunderstand where I'm coming from.  I would love to see
> more people using ML instead of C++.  I was part of a team that produced
> one of the commercial SML compilers. All three commercial SML compilers
> have failed, partly because it's very difficult to persuade people to
> switch.  People aren't stupid, and they won't switch to a new language
> without some compelling evidence that it gives an advantage.  I believe
> that a 2:1 or 3:1 gain in a meaningful measure -- the best measure being
> overall cost -- would be sufficient to persuade a reasonable number of
> people to switch.  But, we need concrete evidence.  This is hard to obtain,
> because few people have the time to write a project twice, using different
> languages.  What's more, when studies of this sort have been done,
> comparing more conventional languages, the results have shown that the
> choice of language makes little difference to the overall cost of the
> project.  So there's a widespread suspicion of claims that language X or Y
> increases productivity by significant amounts.
> 
> In this context, figures plucked from the air are, at best, not helpful; I
> think they're actually counter-productive.  To an extent, the bigger the
> claims, the more counter-productive they are, because they're easier to
> challenge.  I would rather have one verifiable claim of a 3:1 productivity
> improvement -- which is a pretty big win -- than a hundred unverifiable
> claims of 10:1, 20:1 or even 40:1 gains.  (Given earlier postings on this
> thread, it's worth reiterating that the type of program is also vital --
> e.g. figures for a one-week project may not scale to a ten-year project).
> 
> This thread gave one very useful example: the rewrite of Ensemble.  IIRC,
> this gave a 7:1 gain in LoC over the original C version.  Even if one
> allows for the benefit of writing the program a second time, and for the
> fact that LoC doesn't necessarily correlate directly to development time,
> this is still an impressive figure.
> 
> Way back when this thread started, I quoted another example: Andrew Appel's
> Tiger compiler.  This has three versions, one in C, one in Java, and one in
> SML.  The SML is shorter, but not to such a great extent.  (I need to
> recheck the actual figures).
> 
> Dave.
> 
> 
> 
> -------------------
> 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
> 
-------------------
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] Re: productivity improvement

[Eray Ozkural]

Oleg is probably going to get mad at such delays in a follow-up but 
nonetheless I have had very little time to write anything intelligible 
because of my unfortunate phd studies.  I am trying to catch up with some 
mails that I've neglected at the time.

For recall, Dave said that a measurable 2 or 3-fold improvement in code size 
could convince people to switch to ML.

On Sunday 20 October 2002 15:46, Dave Berry wrote:
> Way back when this thread started, I quoted another example: Andrew Appel's
> Tiger compiler.  This has three versions, one in C, one in Java, and one in
> SML.  The SML is shorter, but not to such a great extent.  (I need to
> recheck the actual figures).

What I would guess is that a C++ compiler implemented in Ocaml would improve 
code size considerably over one written in C. Even over those in C++, which 
seems to be the language of choice for efficient code nowadays. I have looked 
at some of the open source C++ compilers to see how the code organization was 
and I think that a C++ compiler does have the right amount of complexity to 
demonstrate our point about productivity.

I myself tried to go at some length previous summer by writing a combinatorial 
C++ parser with Parsec in Haskell. As you will guess, I quickly ran into a 
few hard resolution problems and then although I realized there was a nice 
LL(1) grammar that I could use, I didn't have enough time for the project (as 
you could also guess)

If somebody gets interested, I will try to clean up the parser and have it 
actually parse a subset of C++ so that we can begin some development on it. 
Then, if somebody pleases, it shouldn't be impossible to translate the code 
to ocaml or other functional languages. 

The reason I used Haskell was that I thought it would be interesting to see 
the pipeline effect of lazy monadic code in something like (pseudocode!)

do
    t <- parseProgram prog1;
    s <- semanticAnalyzer t;
    pr <- generatePR s;
    opr <- optimizePR pr;
    generateCode opr

I haven't really looked at any real compilers written in Haskell but I would 
think they use a fair amount of monadic functions.

But first I must program more data structures!!

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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] Re: productivity improvement

[Noel Welsh]

--- Markus Mottl <markus@oefai.at> wrote:
> I'd get into very serious troubles when my
> main programmer gets a brick on his head. 

Markus, you write as a brick to the head is a foregone
conclusion.  Is this how functional programmers are
treated in Austria?  ;-)

Seriously, Markus is right: many business decisions
are based on fear.  This is sad and leads to the kind
of lossage that Paul Graham has been writing about in
his recent essays.  It's up to small companies to gain
the advantages of innovative technology.

Noel

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Noel Welsh wrote:
> --- Markus Mottl <markus@oefai.at> wrote:
> > I'd get into very serious troubles when my
> > main programmer gets a brick on his head. 
> 
> Markus, you write as a brick to the head is a foregone
> conclusion.  Is this how functional programmers are
> treated in Austria?  ;-)

Well, you never know how laid off project managers retaliate here ;-)

> Seriously, Markus is right: many business decisions
> are based on fear.  This is sad and leads to the kind
> of lossage that Paul Graham has been writing about in
> his recent essays.  It's up to small companies to gain
> the advantages of innovative technology.

It is possible to disperse risk when you happen to live in a country with
a well-developed market for venture capital. This, however, is not the
case here. At least in this respect you can be lucky to live in the UK.
OTOH, food and weather is so much better over here :-)

Regards,
Markus

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

Re: [Caml-list] Re: productivity improvement

[John Max Skaller]

Oleg wrote:

>Looking at Halo [1] credits, one can see that it was developed by about 10 
>programmers (there were also testers and artists involved). A single O'Caml 
>programmer capable of developing such a game alone should certainly stand to 
>make tons of money. Then why don't we see much software written in O'Caml?
>
>I'm not buying the argument that "O'Caml isn't used in the industry because 
>investors and project managers are stupid". 
>
Two major reasons.

    (1) licence uncertainty
    (2) lack of programmers

Issue (2) will go away with time as use snowballs,
it would help if Universities started teaching Ocaml instead
of stupid OO languages like Java, or at least as well as.

Lack of bindings to C libraries is also an obstacle, but I'd roll that
up into issue (2).

It would be really useful if all the run time parts of Ocaml were given
a simple no bull licence such as 'free for any use' so it was quite clear
that generated code was OWNED by the entity that owned
the inputs.

-- 
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] Re: productivity improvement

[Alan Schmitt]

* John Max Skaller (skaller@ozemail.com.au) wrote:
> It would be really useful if all the run time parts of Ocaml were given
> a simple no bull licence such as 'free for any use' so it was quite clear
> that generated code was OWNED by the entity that owned
> the inputs.

I just took a look at the license, and it says you can distribute
executables of your programs as you wish, even if they contain part of
the libraries of caml by linking. So I'm not sure I follow what you mean
here ...

Alan

-- 
The hacker: someone who figured things out and made something cool happen.
-------------------
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] Re: productivity improvement

[John Carr]

> >Looking at Halo [1] credits, one can see that it was developed by about 10 
> >programmers (there were also testers and artists involved). A single O'Caml 
> >programmer capable of developing such a game alone should certainly stand to
> >make tons of money. Then why don't we see much software written in O'Caml?
> >
> >I'm not buying the argument that "O'Caml isn't used in the industry because 
> >investors and project managers are stupid". 
> >
> Two major reasons.
> 
>     (1) licence uncertainty
>     (2) lack of programmers
> 


As a new OCaml programmer let me describe the other barriers to entry:
    (3) programming style
    (4) development environment
    (5) grammar, semicolons, and other quirks

(3) programming style

This is related to (2).

Leaving out classroom use, the majority of the target audience for a
general purpose language consists of C/C++ programmers.  (Some are
recent CS graduates -- see below -- and maybe Microsoft Visual-whatever
drones should be counted as a separate category.)

At my last job we switched from C++ to Java.  We had a few experienced
Java programmers and an MIT professer with her new Java textbook.  Two
weeks were sufficient to learn the new language sufficiently well to
start writing real code.  Java is designed to look like C with classes
and garbage collection.  As a result, it is easy to find or create
Java programmers.

OCaml is not related to C.  It doesn't look like C (see below) and it
doesn't work like C.  The object oriented features are harder to learn
than those in C++.  Moving from C to a functional language is not
natural.  Retraining software engineers will take longer and some will
not be able to make the transition.

Recent CS graduates may do better than established C programmers.
They should have had recent experience with functional languages.
(I hear many students have trouble with "lambda" in introductory
CS courses.  I assume those who graduate understand.)  However,
few students will come out of school knowing OCaml.

This is a fundamental barrier and managers are right to be wary.


I did use a non-mainstream language once in a commercial software
product.  I wrote the test suite for my program in Scheme.  This
was feasible because the group was very small and my boss liked
Scheme.  For the particular application it was a good choice.


(4) development environment

I wanted to compile the HTTP client tool from one of the ocaml web
sites.  Doing this required finding, compiling, and installing three
or four other ocaml libraries plus a C library which I had to search
elsewhere for.

The core language -- the tarball from the OCaml web site -- is well
packaged and seems reliable, but the surrounding chaos feels more like
a hacker project than a solid development platform.  A developer using
C on a Unix system has more software in a standard installation.

(Is it possible to do Java-style hierarchical naming or C++ namespaces
in OCaml?  One of these is probably essential in the long run.)


(5) quirks

If OCaml is to be taken seriously it needs a compiler with better
error messages.  I remember switching 15 years ago from pcc (the
"Portable C Compiler" that came with BSD 4.2) to Metaware High C and
gcc.  pcc emitted a single unhelpful error message followed by a
cascade of secondary messages.  The newer compilers generated helpful
error messages and had error recovery so any later messages were
likely to be related to further code errors.  My productivity
substantially increased as I was able to understand what errors meant
and fix more than one error per edit-compile cycle.

ocamlc is like pcc, but without the cascading errors.

A tool like "lint", that parses a file and looks for problems, might
be adequate for this purpose.  The ideal solution would be two
independent language implementations.

The use of semicolon as an optional statement separator rather than a
mandatory statement terminator causes a lot of extra work for me.  I
understand the C rules about where a statement begins and ends.  The
OCaml rules are confusing and I often must resort to trial and error
to resolve compilation errors.  I want to know WHY the compiler thinks
my exception handler expression should have type unit.  It should tell
me "the inferred type for the value expression of the try clause at
line 120 (unit) does not match the inferred type for the value
expression of the with clause at line 130 (string)".

The lack of operator overloading makes the transition from C to OCaml
harder.  (I understand why type inference and overloading are
difficult to reconcile, but the omission is still annoying.)



Having said all that, my personal goal for this summer is to learn
a new language and write a useful program in it.  I chose OCaml and
I will reserve judgement until I have completed that task, or failed.


    --John Carr (jfc@mit.edu)
-------------------
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] Re: productivity improvement

[Brian Smith]

John Max Skaller wrote:
> Lack of bindings to C libraries is also an obstacle, but I'd roll that
> up into issue (2).

I hope I can offer some insight into this. I am a student at the 
University of Iowa in the U.S. I will say that I think that O'Caml is 
very interesting and I enjoy learning it. But, everything seems to be 
Java or VB over here, both at school and in the job market. So, that 
means I will seemingly forever be using O'Caml only in my free time.

Also, Java has the focus of so many open-source developers and 
open-source users. If I write my software in O'Caml, I worry that nobody 
will be interested in it because it isn't Java. And, contributions to 
other projects won't be accepted because they are not Java. And, it is 
an odd feeling to write code that seemingly nobody will ever use.

Finally, there is the user interface issue. I haven't seen any TCL/TK 
applications that have "good" user interfaces running on Windows or Mac 
OS. I want my applications to look like Windows applications on Windows 
and Mac applications on Mac. And, I don't want to learn a Windows GUI 
API and a Macintosh GUI API. TCL/TK does not provide this. But, Java 
_does_ do this, in a "mostly good enough" way that is always improving.

So, I think that, if people are interested in seeing O'Caml have more 
widespread use, at least in the short term there needs to be better 
interoperability between Java and O'Caml. In particular, it should be 
easy for me to write a user interface in Java and write my "business 
logic" in O'Caml. In general, it should not require a lot of work to 
reuse an existing Java library (there are so many). Currently, these 
things are not easy. Xavier's JNI bindings seem like they might help, 
but there needs to be something "above" those bindings. And, there needs 
to be some example application that makes use of these bindings. If 
these things are provided then O'Caml won't seem so much like its own 
far-off world to Java programmers.

Here is an example of what I would like to do with O'Caml: I would like 
to take a software model (described using UML or some other modeling 
languages) and transform that model into various other languages. For 
example, convert a UML package of classes into an O'Caml module of 
classes. Or, perhaps take a set of Java interfaces and make a set of 
O'Caml bindings for those interfaces. And, I want to integrate this tool 
with the NetBeans IDE which is written in Java.

Regarding syntax: It seems perhaps the O'Caml syntax is designed to be 
easy for the O'Caml parser to parse, instead of being easy for me to 
figure out. But, it would be nice if at least the object-oriented syntax 
could reduce the amount of punctuation needed, and also be a little more 
consistent within itself and the rest of the language. Also, it would be 
nice to have better support for recursive types/classes/exceptions so 
that introducing spurious type variables isn't needed. I would rather 
reserve type variables for use only when I want polymorphism.

Just my US$.02 (worth a whole US$.02 but look at our prescription drug 
prices!)

- 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

Re: [Caml-list] Re: productivity improvement

[Eray Ozkural]

On Friday 12 July 2002 16:44, John Max Skaller wrote:
> Two major reasons.
>
>     (1) licence uncertainty
>     (2) lack of programmers
>
> Issue (2) will go away with time as use snowballs,
> it would help if Universities started teaching Ocaml instead
> of stupid OO languages like Java, or at least as well as.

Indeed. The industry wants OO, the industry thinks Java is the
ultimate OO language, they persuade clueless academics (who might as well 
think that choice of PL is irrelevant to understanding the theory), and
then they start teaching Java (and now C#) at the university.

The problem is that OO is *not* the best approach to programming.
OO is a kind of program conceptualization that might be of some
use in certain domains while failing miserably in majority of domains. That's 
why most of the "OO" code is iteration constructs and imperative nonsense, 
over and over again. I once told a colleague that 90% percent of the code we 
are writing in C++ is iterators. Nothing in the world could be more stupid 
than that.

Besides, C does not hold the crown of imperative languages, especially when it 
comes to demonstrating the basics of programming. Pascal does a much better 
job at that in my opinion, and Algol might even do better but nobody 
comprehends its prominence among imperative languages.

It is so amusing when "Software Engineers" find out that the overblown UML 
can't be used to model every kind of program.

Happy hacking,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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