Re: [Caml-list] ocaml complexity

Re: [Caml-list] ocaml complexity

[leary]

I'd wager that 90% of the reason Perl is so huge is due to _Learning Perl_.
Neophytes can start writing interactive programs on page 7.  I went from
near zero programming ability to writing an IDL parser/EDI data tranlator
in about a month or so using that and Programming Perl -- for which the OCaml
manual is a semi-reasonable, if terse and dry, match.  Is there hope for
the coming O'Reilly translation, or does it too think that I/O (i.e. doing
something useful and interesting) is something best left for the later
chapters (or the reference section)?  It's hard for me to believe that
OCaml can be both so good, and so unpopular (read: badly documented (read:
no friendly tutorials)).  From whence _Learning OCaml_?
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Jonathan Coupe]

> I'd wager that 90% of the reason Perl is so huge is due to _Learning
Perl_.
> Neophytes can start writing interactive programs on page 7.  I went from
> near zero programming ability to writing an IDL parser/EDI data tranlator
> in about a month or so using that and Programming Perl -- for which the
OCaml
> manual is a semi-reasonable, if terse and dry, match.  Is there hope for
> the coming O'Reilly translation, or does it too think that I/O (i.e. doing
> something useful and interesting) is something best left for the later
> chapters (or the reference section)?  It's hard for me to believe that
> OCaml can be both so good, and so unpopular (read: badly documented (read:
> no friendly tutorials)).  From whence _Learning OCaml_?

Books are important. Perl's are superb at getting a new user started. A
Learning OCaml would be a good thing. But Perl's spread is also dues to at
least four other factors:

1. Perl was perceived by the adopters who gave it critical mass as being
fundamentally like the languages they already knew (bash, C, Awk) It was a
low risk, low effort, low fear choice.

2. Perl is aimed most of all at small projects. The risk of trying new tools
in this space is low - throwing away a 200 lines of code is annoying, but
not job threatening. And benefits are quickly perceiveable. Ocaml's best use
is probably larger projects beyond the scope of scripting languages.
Throwing a way an even quarter completed project is likely to mean the loss
of several thousand lines of coding effort, and you're unlikely to have
proveable benefits until the end of the first project, which is more likely
to be months, not days or hours, after starting work.

3. Perl's regexp gave it a decisive edge in several rapidly expanding
niches.

4. Its easy to perceive Perl's strengths from an initial examination, and
perhaps harder to pick up on its weaknesses.


Jonathan Coupe

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[leary]

On Thu, Jun 07, 2001 at 07:29:27PM +0100, Jonathan Coupe wrote:
> 1. Perl was perceived by the adopters who gave it critical mass as being
> fundamentally like the languages they already knew (bash, C, Awk) It was a
> low risk, low effort, low fear choice.

A Hitchhiker's Guide to type theory (and all the other alien things my eyes
glaze over at on this list) aimed at the unwashed masses would go a long
way to making OCaml (and functional programming in general) more
accessible.  Did I pass over one somewhere?

> 2. Perl is aimed most of all at small projects. The risk of trying new tools
> in this space is low - throwing away a 200 lines of code is annoying, but
> not job threatening. And benefits are quickly perceiveable. Ocaml's best use
> is probably larger projects beyond the scope of scripting languages.
> Throwing a way an even quarter completed project is likely to mean the loss
> of several thousand lines of coding effort, and you're unlikely to have
> proveable benefits until the end of the first project, which is more likely
> to be months, not days or hours, after starting work.

How much time and money do development teams spend creating and tracking
down memory management errors in C and C++ starting on day one?  At least
some of the benefits are immediate and ongoing.

> 
> 3. Perl's regexp gave it a decisive edge in several rapidly expanding
> niches.

And OCaml has features which give it a decisive edge in markets too big to
be called mere niches.

> 4. Its easy to perceive Perl's strengths from an initial examination, and
> perhaps harder to pick up on its weaknesses.

I can say exactly the same of OCaml.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Mattias Waldau]

> How much time and money do development teams spend creating and tracking
> down memory management errors in C and C++ starting on day one?  At least
> some of the benefits are immediate and ongoing.

Why this obsession comparing Ocaml with C/C++? C/C++ isn't used out there
except for Linux-development, low-level programming and embedded
development.

No one writes applications using C/C++, they use Java, Visual Basic. Some
open source developers use Python, PHP and similar. Some use Fortran and
Delphi.

Talking about memory management with a programmer using anything else than
C/C++ is a waste of time.

The real questions is how to convince a Java-programmer to start using
Ocaml.

The arguments I can list is:
- speed
- polymorphism, no casting needed (will be solved in next generation of
Java, so this
argument will disappear)
- closures (however can always be programmed using local class with
()-method)
- better typechecking makes higher order functions simple to use (however, I
  think that a local class in Java will be as good)
- compact programs (Java programs are very long)
- easy integration with C (easy in VB, I haven't tried it in Java)

Plz help me with more arguments
/mattias

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Pierre Weis]

> The real questions is how to convince a Java-programmer to start using
> Ocaml.
> 
> The arguments I can list is:
> - speed
> - polymorphism, no casting needed (will be solved in next generation of
> Java, so this
> argument will disappear)
> - closures (however can always be programmed using local class with
> ()-method)
> - better typechecking makes higher order functions simple to use (however, I
>   think that a local class in Java will be as good)
> - compact programs (Java programs are very long)
> - easy integration with C (easy in VB, I haven't tried it in Java)
> 
> Plz help me with more arguments
> /mattias
> 
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:http://caml.inria.fr/FAQ/ 
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

The more interesting features Caml offers to the programmer are

- concrete data types (sum types) along with pattern matching
- abstraction facilities thanks to modules (providing abstract data types)

The salient feeling you have when using the compiler is its
strictness: it ``seems'' to be clever enough to track down your bugs
via typechecking and pattern matching analysis.

Best regards,

Pierre Weis

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


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[William Chesters]

Pierre Weis writes:
 > The more interesting features Caml offers to the programmer are
 > 
 > - concrete data types (sum types) along with pattern matching
 > - abstraction facilities thanks to modules (providing abstract data types)

Yes, Java has only one mechanism for abstraction, viz dynamic dispatch
(virtual methods).*  They're quite handy sometimes, hence ocaml's
classes---but increasingly they are no longer seen as the be-all and
end-all of programming.  With C++ moving more and more towards
templates, i.e. modules in the ML sense, "selling" other paradigms can
only get easier.


* unless you count data hiding as such to be a mechanism which I
hardly do :)
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Brian Rogoff]

On Fri, 8 Jun 2001, Mattias Waldau wrote:
> The real questions is how to convince a Java-programmer to start using
> Ocaml.
> 
> The arguments I can list is:
...
> - closures (however can always be programmed using local class with
> ()-method)
> - better typechecking makes higher order functions simple to use (however, I
>   think that a local class in Java will be as good)
...

- block structure with lexical scope

C derived languages are relatively flat; yeah you can have nested scopes
but you can't nest function definitions. I hate that. Pascal derived
languages are much nicer in this respect, but they always have
restrictions on what you can do with functions. So ML style closures will 
be a lot nicer than Java style closures faked with objects since you don't 
have to explicitly make the local variables into arguments. 

I'll post an example if you wish, but I sent one to compl.lang.ml a few
months ago when some Python programmer was asking for examples of what
you could do in ML that you couldn't easily do in Python. I think Python 
is fixed now, but Java is still broken. So is C++ (sorry Chris, couldn't 
resist ;-).

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Chris Hecker]

>C derived languages are relatively flat; yeah you can have nested scopes
>but you can't nest function definitions. I hate that. Pascal derived
>languages are much nicer in this respect, but they always have
>restrictions on what you can do with functions. So ML style closures will 
>be a lot nicer than Java style closures faked with objects since you don't 
>have to explicitly make the local variables into arguments. 

Unless you want local types (or local exceptions for parameterized Breaks, like we discussed previously) to go with your local functions, in which case you have to wrap them in a local module, but you can't local open, so it's a lot like a nested class syntax-nastiness-wise, and you can't have record fields with the same name anyway, etc.  :)

In some sense, you trade heavyweight functions in C++ for heavyweight types in OCaml.  I won't defend that statement particularly strongly though, so don't bother attacking it with vigor.  :)

> So is C++ (sorry Chris, couldn't resist ;-).

I certainly think C++ is a pile, myself.  My point with that other comment was that I think "alternative language people" (whatever that means) like to bash C++ to the point where it becomes a habit, rather than it staying an engineering analysis of a different solution's strengths and weaknesses.

Chris


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Jonathan Coupe]

----- Original Message -----
From: <leary@nwlink.com>
To: "Jonathan Coupe" <jonathan@meanwhile.freeserve.co.uk>
Cc: <caml-list@inria.fr>
Sent: Friday, June 08, 2001 10:41 AM
Subject: Re: [Caml-list] ocaml complexity


> On Thu, Jun 07, 2001 at 07:29:27PM +0100, Jonathan Coupe wrote:
> > 1. Perl was perceived by the adopters who gave it critical mass as being
> > fundamentally like the languages they already knew (bash, C, Awk) It was
a
> > low risk, low effort, low fear choice.
>
> A Hitchhiker's Guide to type theory (and all the other alien things my
eyes
> glaze over at on this list) aimed at the unwashed masses would go a long
> way to making OCaml (and functional programming in general) more
> accessible.  Did I pass over one somewhere?
>
> > 2. Perl is aimed most of all at small projects. The risk of trying new
tools
> > in this space is low - throwing away a 200 lines of code is annoying,
but
> > not job threatening. And benefits are quickly perceiveable. Ocaml's best
use
> > is probably larger projects beyond the scope of scripting languages.
> > Throwing a way an even quarter completed project is likely to mean the
loss
> > of several thousand lines of coding effort, and you're unlikely to have
> > proveable benefits until the end of the first project, which is more
likely
> > to be months, not days or hours, after starting work.
>
> How much time and money do development teams spend creating and tracking
> down memory management errors in C and C++ starting on day one?  At least
> some of the benefits are immediate and ongoing.
>

If this was the decisive issue, people would just use C++ with GC. It's as
simple as doing a search for Boehm or Great Circle. I think the memory leak
issue for C++ is overstated (except possibly for very large projects.) For
competent teams, memory management is rarely an issue. C++'s real problems
are elsewhere: compiler breaking language complexity, poor generics, lack of
interpretive systems, no widely supported block\closure equivalent, nasty
type system, appalling phyical dependency issues, and bottom of the line
syntax for function calls.

Finally, you don't really know the cost/benefit ratio for a technology until
the day you manage to ship. You certainly won't be able to convince any
sceptical colleagues or managers of it, and that's what governs the adoption
rate for new technologies.


> > 4. Its easy to perceive Perl's strengths from an initial examination,
and
> > perhaps harder to pick up on its weaknesses.
>
> I can say exactly the same of OCaml.

Then you should say what these easy to percieve strengths are. The major
strengths of OCaml I'm aware are definite and considerable, but take time to
appreciate.

For Perl it's easy - great regexp, decent ability to wrap C, lots of
libraries, fast coding (as evidenced by the number of lines of code to write
a demonstration program - the easiest to perceive test for potential
adopters), improved file handling and loops compared to the languages it
took over from, an error tolerant runtime machine.

The point here isn't that Perl is a better or even good language. I don't
*like* Perl. The point is that it's benefits are easily communicated to
potential users:  communicating the potential benefits of Perl takes no more
than showing a 200 line C-program that's been re-written as a 17 line Perl
program.

This is not the case for OCaml. It's much hard to convey the benefits of its
support for functional programming. Many programmers don't know what fp is;
more are positively allergic to it because of bad academic intoductions.
It's not easy conveying the benefits of the OCaml type system to an
industrial C programmer either. Claiming benefit here is easy. Persuading
someone else that it exists requires real intellectual effort on your part
and theirs. I don't think anyone could this better than Mark Dominus did
with his article, which is probably a good hour's read. If the benefits
Ocaml provides here were obvious, I don't think you'd have written that
trying to understand the type system makes your eyes "glaze over."

Perl is widely used. Ocaml, Scheme, CLOS and Smalltalk aren't, despite being
better languages. The reason why is partly that Perl is a more marketable
language - it fits into niches where new tools can spread more easily, and
because its benefits are easily communicated, potential users can easily be
persuaded to try it out.

Jonathan Coupe


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Chris Hecker]

Do people actually see the current "market penetration" of ocaml as a problem?  One big problem would be if INRIA didn't think it was popular enough to continue funding it, but anything short of that is not disasterous.  We might get more libraries and whatnot with more people, but there would be downsides to more popularity as well.

I guess I'm kind of enjoying learning an unhyped language with a high signal/noise mailing list of smart people (who do bash C++ a little too much, but oh well :).

I much prefer the slower word-of-mouth adoption rate that ocaml seems to have over the MOP (Marketing Oriented Programming) and "get users at any cost" that has taken over language design these days.

People seem to discover ocaml in two ways that are both healthy for the language, in my opinion:  1) word-of-mouth, and 2) being dissatisfied by one's current language and doing research into alternative languages and seeing that it's one of the best designed and engineered out there (I came upon it in the latter way, via the ICFP contest, but people also probably see ocaml's placement on the Great Computer Language Shootout, and other places...I plan on writing a couple articles about it in Game Developer Magazine when I've got more of a clue).  

Three other ways to come into contact with a new language are of more questionable value (again, in my opinion, of course): 3) being forced to learn it at school before you're ready, 4) being told by an employer you have to learn it, and 5) looking on monster.com and deciding you need to learn whatever ranks highest in help wanted ads.

I don't consider myself an elitist at all, but I'm kind of liking the small community.  Contrast this list with comp.lang.c++, even in the old old days (Skaller will confirm), and you'll see what I mean.

Chris

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Miles Egan]

On Fri, Jun 08, 2001 at 01:22:44PM -0700, Chris Hecker wrote:
> 
> Do people actually see the current "market penetration" of ocaml as a problem?
> One big problem would be if INRIA didn't think it was popular enough to
> continue funding it, but anything short of that is not disasterous.  We might
> get more libraries and whatnot with more people, but there would be downsides
> to more popularity as well.

I certainly don't think Ocaml's popularity or lack thereof is a problem and I
agree there advantages in letting it grow at its own pace.  I'm mainly
interested in increasing its market penetration where I work so I can stop
writing Python code.

-- 
miles
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Jonathan Coupe]

> On Fri, Jun 08, 2001 at 01:22:44PM -0700, Chris Hecker wrote:
> >
> > Do people actually see the current "market penetration" of ocaml as a
problem?
> > One big problem would be if INRIA didn't think it was popular enough to
> > continue funding it, but anything short of that is not disasterous.  We
might
> > get more libraries and whatnot with more people, but there would be
downsides
> > to more popularity as well.
>
> I certainly don't think Ocaml's popularity or lack thereof is a problem
and I
> agree there advantages in letting it grow at its own pace.  I'm mainly
> interested in increasing its market penetration where I work so I can stop
> writing Python code.
>
> --
> miles
>

Is Ocaml's acceptability at Pixar independent of its use in the larger
marketplace? If so, I'm surprised. (I believed that the opposite was the
case for Lisp, from your comments on cll.) The more people who use a
language, the more useful it is through the availability of tools, libraries
and trained programmers. And yes, the more politically acceptable it is to
decision makers. Which is fair enough - what if INRIA does stop supporting
Caml?

There's also the larger question of our professional responsibility to
society. Software quality is a key (though usual buried) problem for the
modern world. Tools that can improve it are good. Ocaml has significant
potential to do that. I'd hate to see it under used to the extent that CLOS
and Smalltalk are.

Jonathan

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Miles Egan]

On Fri, Jun 08, 2001 at 11:17:26PM +0100, Jonathan Coupe wrote:
> Is Ocaml's acceptability at Pixar independent of its use in the larger
> marketplace? If so, I'm surprised. (I believed that the opposite was the
> case for Lisp, from your comments on cll.) The more people who use a
> language, the more useful it is through the availability of tools, libraries
> and trained programmers.

I'm not denying any of that.  It would be easier to push Ocaml around here if it
had the kind of visibility that Python or Perl enjoys.  I don't feel like
there's much I can personally do to advance Ocaml globally at the moment,
though, so I'm more immediately interested in what I can do locally.

I've been wondering if I was the only one that reads cll and caml-list. ;)

> There's also the larger question of our professional responsibility to
> society. Software quality is a key (though usual buried) problem for the
> modern world. Tools that can improve it are good. Ocaml has significant
> potential to do that. I'd hate to see it under used to the extent that CLOS
> and Smalltalk are.

So would I.  I'm focusing on making my own little dent at the moment.

A little buzzword compliance doesn't hurt, of course, which is why I was
wondering if anyone is working on SOAP libs.

-- 
miles
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Pierre Weis]

[...]
> Is Ocaml's acceptability at Pixar independent of its use in the larger
> marketplace? If so, I'm surprised. (I believed that the opposite was the
> case for Lisp, from your comments on cll.) The more people who use a
> language, the more useful it is through the availability of tools, libraries
> and trained programmers. And yes, the more politically acceptable it is to
> decision makers. Which is fair enough - what if INRIA does stop supporting
> Caml?

INRIA is supporting Caml since early 1984 (following its support to
the development of an ML compiler from... the beginning!).

Objective Caml is one of a very few sucessful software provided by
INRIA. Hence it is politically important for INRIA (read it as ``it is
an important argument for INRIA to get funding), hence INRIA is not
likely to abandon its support for Caml (also remember that more and
more INRIA's software is written in Caml!).

Another argument quoted from industry:

``Caml is free software, the source of the compiler is available,
well written, and it has almost no bugs: it would not be a big deal to
maintain the Caml compiler by ourselves, if INRIA were to fail at
maintaining it''.

> There's also the larger question of our professional responsibility to
> society. Software quality is a key (though usual buried) problem for the
> modern world. Tools that can improve it are good. Ocaml has significant
> potential to do that. I'd hate to see it under used to the extent that CLOS
> and Smalltalk are.
> 
> Jonathan

On this last point, I agree with you 100%, since it was (and still is)
one of our main goals when designing Caml: try to improve the quality
of software developments that can be done using Caml.

Best regards,

Pierre Weis

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


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

Miles Egan wrote:

> I certainly don't think Ocaml's popularity or lack thereof is a problem and I
> agree there advantages in letting it grow at its own pace.  I'm mainly
> interested in increasing its market penetration where I work so I can stop
> writing Python code.

	I have a different problem: I don't have a job at all.
I find it really hard to bring myself to write any C++ or Python
these days, and it shows in job interviews I guess. :-(

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[David Fox]

Chris Hecker <checker@d6.com> writes:

> not disasterous.  We might get more libraries and whatnot with more
> people, but there would be downsides to more popularity as well.

I am going to strongly disagree with this statement.  I think that
more libraries are extremely important, and I also think that the fact
that many good things are unpopular doesn't imply that all popular
things are bad, or that something becomes worse when it becomes
popular.

> Three other ways to come into contact with a new language are of
> more questionable value (again, in my opinion, of course): 3) being
> forced to learn it at school before you're ready, 4) being told by
> an employer you have to learn it, and 5) looking on monster.com and
> deciding you need to learn whatever ranks highest in help wanted
> ads.

I also believe that the "right thing for the wrong reason" beats the
heck out of the wrong thing in most cases.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[leary]

Excellent points, and I'm inclined to agree, but I'd like to actually be
able to someday get a job using OCaml, ML, et al. :)

Search on DICE.com... out of 70000+ jobs nationwide (USA):

caml 0
sml 19 (apparently none mean Standard Meta Language, so really: 0 )
haskell 6
lisp 16
python 146
PHP 155
smalltalk 231
perl 426*
java 10339
C++ 18638

* probably safe to add in most of the 743 unix system admin jobs, plus some
other portion of the 926 unix quality assurance jobs.

I may as well try to get a programming job using Latin.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Mark Wotton]

On Fri, 8 Jun 2001 leary@nwlink.com wrote:

> Excellent points, and I'm inclined to agree, but I'd like to actually be
> able to someday get a job using OCaml, ML, et al. :)
> 
> Search on DICE.com... out of 70000+ jobs nationwide (USA):
> 
> caml 0
> sml 19 (apparently none mean Standard Meta Language, so really: 0 )
> haskell 6
> lisp 16
> python 146
> PHP 155
> smalltalk 231
> perl 426*
> java 10339
> C++ 18638
> 
> * probably safe to add in most of the 743 unix system admin jobs, plus some
> other portion of the 926 unix quality assurance jobs.
> 
> I may as well try to get a programming job using Latin.

I suspect many of the jobs done with Ocaml occur when the customer doesn't
really care how the system is implemented as long as it works. I guess the
reason this doesn't happen more often is a self-reinforcing one: if the
system ever needs maintenance, the customer's unlikely to be happy about
it being in a "marginal" language.

Mark


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Markus Mottl]

On Fri, 08 Jun 2001, leary@nwlink.com wrote:
> Search on DICE.com... out of 70000+ jobs nationwide (USA):
> 
> caml 0
> sml 19 (apparently none mean Standard Meta Language, so really: 0 )
> haskell 6

I'd have been surprised to find companies that try to recruit
Haskell-programmers (I only know Galois Connections Inc.). The reason
why there are six Haskell entries here is simply text parts like the
following:

  9848 Haskell Ave.

Or:

  Contact for more information:
  Julie Haskell

The "qualities" that are usually demanded in these "hits" are of the sort:

  ..., experience of 5+ years, cobol and banking ...

Sounds very inspiring! ;)

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

leary@nwlink.com wrote:
 
> Excellent points, and I'm inclined to agree, but I'd like to actually be
> able to someday get a job using OCaml, ML, et al. :)
[]
> I may as well try to get a programming job using Latin.

Well, I have had two: the first was at a university,
where I learned Ocaml 'on the job', and the second was
building a compiler for a telco in a C++ shop.
(Both in Australia, where the market is small)
I'm looking for a third. Willing to travel. Any offers? :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[leary]

On Fri, Jun 08, 2001 at 01:27:33PM +0100, Jonathan Coupe wrote:
> If this was the decisive issue, people would just use C++ with GC.
<snip>
> Finally, you don't really know the cost/benefit ratio for a technology until
> the day you manage to ship. You certainly won't be able to convince any
> sceptical colleagues or managers of it, and that's what governs the adoption
> rate for new technologies.

No one factor is decisive, of course, else people would be using OCaml
(more) already.  But it looks like you're saying that adoption is governed
by people who can't be convinced to adopt unless they've shipped something
using the untried technology.  Let's just give up now, ok? ;)  Seriously,
IMHO, there ought to be a compelling case for OCaml that can be made on
paper, and supplemented with some relatively small projects (examples?
exercises for the reader?) which demonstrate the value.

> Many programmers don't know what fp is;
> more are positively allergic to it because of bad academic intoductions.

One of my main points: there is a lack of good tutorials aimed at people
who don't give a rip about the theory and lingo of language design, beyond
knowing the basics: http://caml.inria.fr/FAQ/general-eng.html .

> It's not easy conveying the benefits of the OCaml type system to an
> industrial C programmer either.

Really?  I'm a pretty lightweight programmer (Perl and a bit of C) by
comparison, and I didn't have trouble grasping the benefits.

> Claiming benefit here is easy. Persuading
> someone else that it exists requires real intellectual effort on your part
> and theirs. I don't think anyone could this better than Mark Dominus did
> with his article, which is probably a good hour's read.

I guess you mean this?: http://perl.plover.com/yak/typing/typing.html

> If the benefits
> Ocaml provides here were obvious, I don't think you'd have written that
> trying to understand the type system makes your eyes "glaze over."

My apologies for being unclear; it's just that I'm... unclear.  Hmmm, let
me put it this way: I've read dozens of chapters in books on ML and OCaml,
yet I can't even figure out half the *questions* that are asked on this
list.  Some of that is surely that I haven't read far enough to have
covered some of the particulars, but a good part of that is the language
(of programming languages) that is quite new to me.  I guess what I'm after
is: Where is the HHGT deciphering FP discussions?  (see my reply to the
HHGT Typing)

> Perl is widely used. Ocaml, Scheme, CLOS and Smalltalk aren't, despite being
> better languages. The reason why is partly that Perl is a more marketable
> language - it fits into niches where new tools can spread more easily, and
> because its benefits are easily communicated, potential users can easily be
> persuaded to try it out.

Scheme and CLOS aren't more widely used because people don't like the
parentheses.  And a good number of the most visible people who advocate
them are rabid emacs zealots -- talk about losing half your audience at the
start.

I went to the GNU Smalltalk site -- where a lot of people are going to go
first, if they're curious.  No good tutorials that I could see, the manual
looked pretty unfriendly -- what I got a chance to see of it.  The html
manual is on an ftp server that allows 10 users, so people might not be
able to read up on it enough to want to download.  I wasn't.  There's also
no evidence of *why* I should want to learn and use Smalltalk.  And anyway,
I'm not a big fan of using OOP (and certainly not for everything), as many
people aren't.  OCaml doesn't seem to force it on the user.  That's a
selling point.

Anyway, you don't think the great numbers of Free Software and Open Source
hackers can get excited about FP and OCaml?  I think they can.  I think the
benefits are easily communicated ( see again:
http://caml.inria.fr/FAQ/general-eng.html )  Remember, these are the people
who enjoy the Unix command line; who have made PHP and Python into viable
solutions in the face of Perl, C++, and Java; who actually do use Scheme
and CLOS and Guile and Emacs Lisp.  Look at the language shootout page.
OCaml is #2 and #4.  Yeah, yeah, speed isn't everything, but it *is* a
selling point for geeks, esp. when OCaml is so far ahead of languages like
Perl, Python, Ruby, Emacs Lisp, TCL and PHP; all of which are far "cooler"
right now.  And now there is PCRE-OCaml; a gold-plated opportunity to
interest some Perl folks in looking more closely at OCaml.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[David Fox]

To follow up on my previous post, which hasn't shown up here yet, the
advantage of a really popular language is that the libraries have been
thoroughly hammered by users.  In contrast, there are quite a few
libraries for Ocaml, but typically I pick one up and start using it
and quickly run into bugs.  Any feature the author isn't using is
likely to need work.  This is somewhat annoying to me, and quite
disconcerting to a less experienced programmer.

I'm just saying that popularity is a good thing for a programming
language.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

David Fox wrote:
 
> I'm just saying that popularity is a good thing for a programming
> language.

	Recent comment on the C++ committee refector indicates this
is not always the case. Even obvious faults, especially
in libraries, can't be fixed if there are too many users.

	For a growing language, _moderate_ growth would
seem a reasonable compromise.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Brian Rogoff]

On Wed, 13 Jun 2001, John Max Skaller wrote:
> David Fox wrote:
>  > I'm just saying that popularity is a good thing for a programming >
> language.
> 
> 	Recent comment on the C++ committee refector indicates this
> is not always the case. Even obvious faults, especially
> in libraries, can't be fixed if there are too many users.

Interesting that you should say that, since I've seen a few posts from the
implementors which suggested that there was a concern for backward
compatibility which sometimes kept little things from being fixed; the
latest was in the exchange between Pierre Weis and Jacques Garrigue with
respect to lvalues and mutable fields in objects. 

IMO, as someone with old code to maintain, I say fix things and make the 
language as close to perfect as you can. I knew when I came aboard that 
OCaml wasn't like Ada or Common Lisp (an ANSI or ISO standard) or even
like SML. When OCaml becomes so popular that it one of these standards
organizations is involved, there will be significantly less ability to 
make incompatible changes. 

Anyways, more growth is good. If OCaml reaches Python's popularity, that
would be great. 

This thread, while rambling, has been quite interesting. A few ideas for 
writing an OCaml tutorial were discussed, and some contributed problems
that they had while learning OCaml. Perhaps we users should start writing
tutorials, rather than asking INRIAns, as I'd rather that they work on 
growing the language.

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[leary]

On Wed, Jun 13, 2001 at 08:21:27AM -0700, Brian Rogoff wrote:
> Perhaps we users should start writing
> tutorials, rather than asking INRIAns, as I'd rather that they work on 
> growing the language.

Aye.  Would Michel Mauny be agreeable to having his "Functional
Programming Using Caml Light" be the starting point for a "Learning OCaml"
project, say on sourceforge?  Are there any better tutorials on ML that
might be borrowed from with permission?



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Johann Höchtl]

leary@nwlink.com wrote:

>On Wed, Jun 13, 2001 at 08:21:27AM -0700, Brian Rogoff wrote:
>
>>Perhaps we users should start writing
>>tutorials, rather than asking INRIAns, as I'd rather that they work on 
>>growing the language.
>>
>
>Aye.  Would Michel Mauny be agreeable to having his "Functional
>Programming Using Caml Light" be the starting point for a "Learning OCaml"
>project, say on sourceforge?  Are there any better tutorials on ML that
>might be borrowed from with permission?
>
I found the introduction of Caltechs Compiler Design Laboratory

http://www.cs.caltech.edu/cs134/cs134b/
direct link:
http://www.cs.caltech.edu/cs134/cs134b/book.pdf

for a beginner (what i am) the most valuable one.

I agree, that the mathematical foundations are sooner or later a great 
aid for a deeper insight in what FP is all about.
However, a beginner can easily get scared of to much formalism.

lG,
  Johann

>
>
>-------------------
>Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
>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/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

Brian Rogoff wrote:

> IMO, as someone with old code to maintain, I say fix things and make the
> language as close to perfect as you can. 

	For Ocaml, I agree, but then I don't have that much
old code I care about.

> When OCaml becomes so popular that it one of these standards
> organizations is involved, there will be significantly less ability to
> make incompatible changes.

	I like your positive approach  

	"When Ocaml becomes so popular .." :-)

> Anyways, more growth is good. If OCaml reaches Python's popularity, that
> would be great.

	But Python too is severely constrained by backwards 
compatibility requirements. It is the main reason I gave up on it
as a serious language: it is beyond fixing.

	OTOH, Ocaml doesn't really _need_ fixing :-)

> Perhaps we users should start writing
> tutorials, rather than asking INRIAns, as I'd rather that they work on
> growing the language.

	I'd love to, but the language isn't popular enough for me
to make enough money selling books on it: I'd make a respectable income
from C++ books, but I have lost enthusiasm for promoting it.
Blame Ocaml for that. Catch-22.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Jonathan Coupe]

----- Original Message -----
> No one factor is decisive, of course, else people would be using OCaml
> (more) already.  But it looks like you're saying that adoption is governed
> by people who can't be convinced to adopt unless they've shipped something
> using the untried technology.

No. What I said was that you won't convice sceptical colleagues that you're
right in choosing ocaml until you ship. Until then, you're burning up
political capital and your job/VC/Project is at risk - much more so than if
you're using a mainstream technology like C or C++. You certainly won't
convince anyone that ocaml was the right choice by saying that you're
developing faster "from day one" as you claimed. People make claims that all
the time. They're usually wrong. In fact, making claims like will reduce
crdibility - unless you've got unusually tight metrics to back you're claim
up. From your comments, I'm pretty sure you've never been a lead on a
commercial project.

The point here isn't to give up on promoting Ocaml. It's to do it in a smart
way - by understanding the barriers to adoption of the language

> I went to the GNU Smalltalk site -- where a lot of people are going to go
> first, if they're curious.  No good tutorials that I could see, the manual
> looked pretty unfriendly -- what I got a chance to see of it.  The html
> manual is on an ftp server that allows 10 users, so people might not be
> able to read up on it enough to want to download.  I wasn't.  There's also
> no evidence of *why* I should want to learn and use Smalltalk.  And
anyway,
> I'm not a big fan of using OOP (and certainly not for everything), as many
> people aren't.  OCaml doesn't seem to force it on the user.  That's a
> selling point.

Hmm. No one I've ever met uses GnuSmalltalk. My understanding from people
who have tried is that its only marginall usable. The standard open source
smalltalk is Squeak. Ruby, a Smalltalk cousin, is probably alos worth
looking at  - and is spreading like wildfire. You can find more Smalltalk
stuff at www.stic.org

Jonathan

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[leary]

On Sat, Jun 09, 2001 at 11:32:20PM +0100, Jonathan Coupe wrote:
> No. What I said was that you won't convice sceptical colleagues that you're
> right in choosing ocaml until you ship.

Didn't you see the winky smiley and the "But seriously..."?

But I disagree anyway; there's no way to know exactly when people will be
convinced of something.  For example, a milestone or two on a large project
might be enough; and shipping two products might not be.

> You certainly won't
> convince anyone that ocaml was the right choice by saying that you're
> developing faster "from day one" as you claimed. People make claims that all
> the time. They're usually wrong. In fact, making claims like will reduce
> crdibility - unless you've got unusually tight metrics to back you're claim
> up. From your comments, I'm pretty sure you've never been a lead on a
> commercial project.

Actually, what I *asked* was, "How much time and money do development teams
spend creating and tracking down memory management errors in C and C++
starting on day one?".  'Not much' was your answer.  I didn't argue with
that.  But since you bring it up again... Having to address memory
management is a cost in time and/or money associated with development in C
and C++ -- you must address the issue *somehow*.  Not having to deal with
memory management is an immediate and ongoing benefit, *however small*,
from using OCaml rather than C or C++.

And before you say it, yes, this is probably going to be outweighed by the
availability of off the shelf components and libraries, and the fact that
it's easier and maybe cheaper to find replacement programmers for a popular
language, among a number of other factors which would likely tend to make
development faster in those languages.

> Hmm. No one I've ever met uses GnuSmalltalk. My understanding from people
> who have tried is that its only marginall usable. The standard open source
> smalltalk is Squeak. Ruby, a Smalltalk cousin, is probably alos worth
> looking at  - and is spreading like wildfire. You can find more Smalltalk
> stuff at www.stic.org

Mea culpa, I just searched on Google for "smalltalk free" and went to the
first link, 'cause I got warm fuzzies when I saw "GNU".  I still don't like
all OOP, all the time, tho'.

Didn't know that about Ruby; interesting.  I read it's all the rage in
Japan.  Go figure.


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

RE: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Dave Berry]

I've spent the last six months actively recruiting C++ programmers.
There are many C++ programmers out there, and they are very much in
demand.  The notion that "nobody writes applications using C/C++" is
simply wrong.  Also, the "open source" community can't be so easily
dismissed, as OCaml is more likely to make headway with these users than
commercial users (at present).

That said, there are other major languages used for writing
applications, such as VB, Delphi and Java.  Comparisons between these
and OCaml would be a good idea.  

Dave.


-----Original Message-----
From: Mattias Waldau [mailto:mattias.waldau@abc.se]
Sent: 08 June 2001 11:06
To: caml-list@inria.fr
Cc: leary@nwlink.com; Jonathan Coupe
Subject: Why is Ocaml better than Java (WAS: [Caml-list] ocaml
complexity)


> How much time and money do development teams spend creating and
tracking
> down memory management errors in C and C++ starting on day one?  At
least
> some of the benefits are immediate and ongoing.

Why this obsession comparing Ocaml with C/C++? C/C++ isn't used out
there
except for Linux-development, low-level programming and embedded
development.

No one writes applications using C/C++, they use Java, Visual Basic.
Some
open source developers use Python, PHP and similar. Some use Fortran and
Delphi.

Talking about memory management with a programmer using anything else
than
C/C++ is a waste of time.

The real questions is how to convince a Java-programmer to start using
Ocaml.

The arguments I can list is:
- speed
- polymorphism, no casting needed (will be solved in next generation of
Java, so this
argument will disappear)
- closures (however can always be programmed using local class with
()-method)
- better typechecking makes higher order functions simple to use
(however, I
  think that a local class in Java will be as good)
- compact programs (Java programs are very long)
- easy integration with C (easy in VB, I haven't tried it in Java)

Plz help me with more arguments
/mattias

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:
http://caml.inria.fr/FAQ/
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/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: Why is Ocaml better than Java (WAS: [Caml-list] ocaml complexity)

[Jean-Marc Eber]

There is another argument in favour of FP (more precisely in favour
of polymorphism + type synthesis) that is, I think, often not enough
emphasised even if, unfortunately, it also only works "in the large".

It's the easiness with which
you can *modify* a big piece of code. More precisely, I'm speaking here
about code that is maintained over many years (say 10 or 15 years) and
constantly
"updated" to work under new circumstances.  Most of the time, this means in
fact a
"generalisation" of the software. A typical example is for instance a
"program" that manipulates, say, floats and is generalised for manipulating
sets of
floats (typically represented as lists). The old case being just the
particular
case of a singleton list.

When you are doing this kind of "software upgrade" with, say, OCaml, it
appears often that you just have to change and adapt the two ends of your
treatment
chain, the intermediary steps "adapting" automatically thanks to the type
unifier.
It's the possibility to do minimal explicit type annotation of your source
code (with
type security albeit of course) that gives incredible flexibility.

Even after a few years of FP programming, I'm still fascinated by the
easiness of patching for instance the OCaml compiler itself (not a small
piece of
code indeed!) by chirurgical minimal source code modifications (replace a
simple value by a tuple etc…).

I miss a FP textbook (but perhaps I'm wrong and someone on this list knows
one) that not only explains that it is easy, sure etc… to write programs in
FP,
but that shows how easy one can *transform* a FP program, by keeping the
"illusion" (thanks to the type unifier) of doing only a minimal change.


Jean-Marc Eber
LexiFi Technologies
17, square Edouard VII
F-75009 Paris - France
tél : 33 1 53 43 92 48
fax: 33 1 53 43 94 94
email: jeanmarc.eber@lexifi.com


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr