Re: [Caml-list] ocaml complexity

Re: [Caml-list] ocaml complexity

[John R Harrison]

| > The intro in the HOL-Light manual is quite good.  Also quite good is:
|
| [....]
|
| Do you have a link to the HOL-Light manual?

See the following URL (there's a link to the manual near the bottom):

  http://www.cl.cam.ac.uk/users/jrh/hol-light/index.html

Most of the CAML tutorial material here was compressed from an earlier
lecture course I gave based on CAML. You might also find the notes for
this course interesting:

  http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html

This starts with basic lambda calculus theory before getting into real
CAML programming, so it might not appeal to many programmers. (Indeed, it
didn't appeal to most of the students, as I recall.) But this approach
does help to emphasize the fundamental theoretical simplicity of core ML.
And there are some quite nice programming examples near the end.

John.
-------------------
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 Gurr]

> From owner-caml-list@pauillac.inria.fr Wed Jun 13 13:36:15 2001
> From: leary@nwlink.com
> To: Brian Rogoff <bpr@best.com>, caml <caml-list@inria.fr>
> X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
> Date: Wed, 13 Jun 2001 13:32:35 -0700
> Subject: Re: [Caml-list] ocaml complexity
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> 
> 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 

I assume you mean Caml rather than SML

> that
> might be borrowed from with permission?
> 
> 
The intro in the HOL-Light manual is quite good.  Also quite good is:

http://cristal.inria.fr/~remy/isia/

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

[leary]

On Wed, Jun 13, 2001 at 02:04:06PM -0700, David Gurr wrote:
> > Are there any better tutorials on ML 
> 
> I assume you mean Caml rather than SML

Actually, I did mean SML, as I think there are probably a few more intro
tutorials there, that could be borrowed from, and translated to OCaml.  Of
course, doing so is a bit over my head, as I'm fluent in neither.  Just a
thought.

> The intro in the HOL-Light manual is quite good.  Also quite good is:
> 
> http://cristal.inria.fr/~remy/isia/

Hm, I don't know French, but the OCaml manual is surely one of the targets
I have in mind when I gripe about inaccessible documentation. :)

Do you have a link to the HOL-Light manual?

-------------------
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, David Gurr wrote:
> > From owner-caml-list@pauillac.inria.fr Wed Jun 13 13:36:15 2001
> > From: leary@nwlink.com
> > To: Brian Rogoff <bpr@best.com>, caml <caml-list@inria.fr>
> > 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 

It depends on the group that you're targeting for the tutorial, of course. 
I think writing from scratch is a fine idea. I think a tutorial should be 
aimed at getting (C++/Java/Perl) programmers up to speed quickly so it 
would probably be a bit boring for the type theory heavy crowd. 

> I assume you mean Caml rather than SML

Borrow from good SML tutorials like Robert Harper's too I say. 

> > that
> > might be borrowed from with permission?
> > 
> > 
> The intro in the HOL-Light manual is quite good.  Also quite good is:
> 
> http://cristal.inria.fr/~remy/isia/

This is in French, which would be a problem for a lot of programmers that
I know. Interestingly, I seem to have picked up enough written French from
reading this list (with a dictionary and some phrasebooks of course) that 
I could read almost all of this. If Didier would like to make the TeX
available, I could take a stab at translating this. He has also written 

http://cristal.inria.fr/~remy/cours/appsem/

which I think is just wonderful, but I don't think its for the beginning
OCaml'er. It's for a more sophisticated programmer, and delves into type 
theory issues. 

John Max Skaller <skaller@ozemail.com.au> then writes
> Brian Rogoff wrote:
> > 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 .." :-)

I believe with perfect faith in the coming of OCaml. 

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

That's true, but there were certainly some pretty major cleanups in 
Python with respect to its scoping that I think make it a much better
language. Of course, it's not OCaml, but it's clearly popular enough that 
lots of people want it on their resumes. OCaml is not there yet. 

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

There are a few places where I think improvements can be made. From what
I've read, INRIA is working on all of them. 

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

I was thinking more of writing free, web available tutorials to increase
the user base. That needs to happen to bring more people on board. Only
then will there be a big market for OCaml books in Anglophone nations. 
In other words, 

	Ask not what the OCaml community can do for you, ask what you 
	can do for the OCaml community. 

> I blame Ocaml for that. Catch-22.

I feel your pain. It's tough to go back to C++ or Java, isn't it?

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

[Tore Lund]

Brian Rogoff wrote:
> 
> >       OTOH, Ocaml doesn't really _need_ fixing :-)
> 
> There are a few places where I think improvements can be made. From what
> I've read, INRIA is working on all of them.

The one thing that definitely needs fixing if OCaml is ever to catch on
is the *name*.  For my own part it took some time before my brain even
registered that there was such a language, and I am sure this was due to
the unwieldy abbreviation "OCaml" - it looks like a typo or line noise
the first time you see it.

Audially, few people would realize that "oh camel" refers to a computer
language.  In fact, in most European languages it is probably heard as a
chivalrous way to address a camel ...

One might choose a new name like "Milner", "Weis", "Leroy", etc.  But if
rocking the boat that much is not acceptable, just "Caml" would be much
better than "OCaml", and "Camel" would be even better.
-- 
    Tore

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

[Nils Goesche]

Tore Lund <tl001@online.no> writes:

> The one thing that definitely needs fixing if OCaml is ever to catch on
> is the *name*.  For my own part it took some time before my brain even
> registered that there was such a language, and I am sure this was due to
> the unwieldy abbreviation "OCaml" - it looks like a typo or line noise
> the first time you see it.
> 
> Audially, few people would realize that "oh camel" refers to a computer
> language.  In fact, in most European languages it is probably heard as a
> chivalrous way to address a camel ...
> 
> One might choose a new name like "Milner", "Weis", "Leroy", etc.  But if
> rocking the boat that much is not acceptable, just "Caml" would be much
> better than "OCaml", and "Camel" would be even better.

Earlier, when asked `which language do you use for it?' I used to
answer `Objective See Ay Em Ell', but people often thought I meant
`Objective C', then :-) Now I say `Objective Camel'.  It means a bit
more to them than just `Oh-Camel'.  Unfortunately, they get the
impression that it's some obscure object oriented language like
Smalltalk now, so I add `a functional language'.  When I typed the URL
caml.inria.fr into the browser of a British coworker of mine, he
pointed at the `fr' part and shouted `NO, NO!  UNACCEPTABLE!!' :-)

Regards,
-- 
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

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

[Xavier Leroy]

Tore Lund <tl001@online.no> writes:
 
> The one thing that definitely needs fixing if OCaml is ever to catch on
> is the *name*.  For my own part it took some time before my brain even
> registered that there was such a language, and I am sure this was due to
> the unwieldy abbreviation "OCaml" - it looks like a typo or line noise
> the first time you see it.

I think all the published documents (manuals, the Web site, the
O'Reilly book) use the official name, which is "Objective Caml"
(pronounced: "Objective Camel").  I often use "Caml" for short when
talking about the core language.

The "OCaml" name that you dislike so much just spread among users by
itself, in particular on this mailing list, but there is not much that
we can do about it...  (Granted, the compiler commands are called
"ocaml<something>", but that was needed to distinguish them from the
"caml<something>" commands of Caml Light...)

> > One might choose a new name like "Milner", "Weis", "Leroy", etc.  But if
> > rocking the boat that much is not acceptable, just "Caml" would be much
> > better than "OCaml", and "Camel" would be even better.

I'll pass on "Leroy" -- flattery will get you nowhere :-)  Of course,
"Caml" is fine.  "Camel" is the pronounciation, but we're quite fond
of the "ml" spelling.

> Earlier, when asked `which language do you use for it?' I used to
> answer `Objective See Ay Em Ell', but people often thought I meant
> `Objective C', then :-) Now I say `Objective Camel'.  It means a bit
> more to them than just `Oh-Camel'.  Unfortunately, they get the
> impression that it's some obscure object oriented language like
> Smalltalk now, so I add `a functional language'.

And then it gives them the impression that it's some obscure
functional language like Haskell? :-) :-)

> When I typed the URL
> caml.inria.fr into the browser of a British coworker of mine, he
> pointed at the `fr' part and shouted `NO, NO!  UNACCEPTABLE!!' :-)

Meanwhile, Blair is manoeuvering the British to switch to the Euro, so
I'm not too concerned here...  Still, you can use www.ocaml.org instead;
your coworker will like it more, but Tore will like it less.
Not www.caml.org to my great regret, since the caml.org domain is
registered already by the "Cruel Angel Mailing List" (no kidding)...

- Xavier Leroy
-------------------
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]

> Tore Lund <tl001@online.no> writes:
>
> > The one thing that definitely needs fixing if OCaml is ever to catch on
> > is the *name*.  For my own part it took some time before my brain even
> > registered that there was such a language, and I am sure this was due to
> > the unwieldy abbreviation "OCaml" - it looks like a typo or line noise
> > the first time you see it.

> > Earlier, when asked `which language do you use for it?' I used to
> > answer `Objective See Ay Em Ell', but people often thought I meant
> > `Objective C', then :-) Now I say `Objective Camel'.  It means a bit
> > more to them than just `Oh-Camel'.  Unfortunately, they get the
> > impression that it's some obscure object oriented language like
> > Smalltalk now, so I add `a functional language'.
>

The biggest source of confusion I've noticed is with Occam - a pascaloid (?)
language for parallel processing.

- 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

[Nils Goesche]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

(I wrote)

> > Earlier, when asked `which language do you use for it?' I used to
> > answer `Objective See Ay Em Ell', but people often thought I meant
> > `Objective C', then :-) Now I say `Objective Camel'.  It means a bit
> > more to them than just `Oh-Camel'.  Unfortunately, they get the
> > impression that it's some obscure object oriented language like
> > Smalltalk now, so I add `a functional language'.
> 
> And then it gives them the impression that it's some obscure
> functional language like Haskell? :-) :-)

Hehe, I am aware of that danger, but I hope that the mental imprint of
the popular buzzword `Objective' hasn't completely vanished yet when I
say `functional'... Sometimes I said `An ML dialect', but nobody knows
what ML is, either (we are all C drones programming embedded systems
like PBXes and routers and stuff :-).

> > When I typed the URL
> > caml.inria.fr into the browser of a British coworker of mine, he
> > pointed at the `fr' part and shouted `NO, NO!  UNACCEPTABLE!!' :-)
> 
> Meanwhile, Blair is manoeuvering the British to switch to the Euro,
> so I'm not too concerned here...  Still, you can use www.ocaml.org
> instead;

Ah, thanks for the hint...

> your coworker will like it more, but Tore will like it less.
> Not www.caml.org to my great regret, since the caml.org domain is
> registered already by the "Cruel Angel Mailing List" (no kidding)...

LOL what a shame :-)
-- 
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

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

[Sven LUTHER]

On Fri, Jun 15, 2001 at 04:54:31PM +0200, Xavier Leroy wrote:
> Meanwhile, Blair is manoeuvering the British to switch to the Euro, so
> I'm not too concerned here...  Still, you can use www.ocaml.org instead;
> your coworker will like it more, but Tore will like it less.
> Not www.caml.org to my great regret, since the caml.org domain is
> registered already by the "Cruel Angel Mailing List" (no kidding)...

What about caml.com, or ocaml.com, it could be registered by the consortium
stuff or someting such, but i guess here again, caml.com is already owned, not
that there is something informative on the page you get though.

Friendly,

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

[Remi VANICAT]

Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:

> On Fri, Jun 15, 2001 at 04:54:31PM +0200, Xavier Leroy wrote:
> > Meanwhile, Blair is manoeuvering the British to switch to the Euro, so
> > I'm not too concerned here...  Still, you can use www.ocaml.org instead;
> > your coworker will like it more, but Tore will like it less.
> > Not www.caml.org to my great regret, since the caml.org domain is
> > registered already by the "Cruel Angel Mailing List" (no kidding)...
> 
> What about caml.com, or ocaml.com, it could be registered by the consortium
> stuff or someting such, but i guess here again, caml.com is already
> owned.

moi@debian:~$ host -a caml.com
caml.com                NS      NS1.ARW.com
caml.com                NS      NS2.ARW.com

yes it is... by Arrow electric inc but i don't know why... i haven't
seen anything about caml on their site

ocaml.com is free.
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
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

[Doug Bagley]

Tore Lund wrote:
> The one thing that definitely needs fixing if OCaml is ever to catch on
> is the *name*.  For my own part it took some time before my brain even
> registered that there was such a language, and I am sure this was due to
> the unwieldy abbreviation "OCaml" - it looks like a typo or line noise
> the first time you see it.

I respectfully disagree!  OCaml is a wonderful name.  Consider how much
easier it is to find OCaml resources via a search engine, compared to
C#, or C--, for example :-)

> Audially, few people would realize that "oh camel" refers to a computer
> language.  In fact, in most European languages it is probably heard as a
> chivalrous way to address a camel ...
> 
> One might choose a new name like "Milner", "Weis", "Leroy", etc.  But if
> rocking the boat that much is not acceptable, just "Caml" would be much
> better than "OCaml", and "Camel" would be even better.

It is strange but this same idea just popped up on comp.lang.tcl ... "Tcl
isn't popular ... it must be because the name isn't sexy!"  (See thread:
http://groups.google.com/groups?ic=1&th=62d53dbb9f3ebba1,32)

I think it is far more important to have good marketing, good
introductory materials, some killer apps/libraries, and a vigorous
and helpful user community.

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

[Didier Remy]

> http://cristal.inria.fr/~remy/cours/appsem/
> 
> which I think is just wonderful, but I don't think its for the beginning
> OCaml'er. It's for a more sophisticated programmer, and delves into type 
> theory issues. 

Indeed, these notes were aimed at an advanced audience (master level or
more). 

Actually, I have just finished a first revision of these notes (thanks,
Brian for your support). Mainly, I fixed some typos, improved the
presentation and added exercises. The size also increased by 40%.

I might do a second revision in the fall. 

> > http://cristal.inria.fr/~remy/isia/
> 
> This is in French, which would be a problem for a lot of programmers that
> I know. Interestingly, I seem to have picked up enough written French from
> reading this list (with a dictionary and some phrasebooks of course) that 
> I could read almost all of this. 

Conversely, the ISIA notes were written for Ocaml beginners without much
theoretical background.  I included some of this material into the APPSEM
notes and I may add more in the future.

> If Didier would like to make the TeX
> available, I could take a stab at translating this. 

This would not be a problem for me, but there could be redundancy with my
APPSEM notes. 

        Didier

-------------------
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 Thu, 28 Jun 2001, Didier Remy wrote:
> > http://cristal.inria.fr/~remy/cours/appsem/
> > 
> > which I think is just wonderful, but I don't think its for the beginning
> > OCaml'er. It's for a more sophisticated programmer, and delves into type 
> > theory issues. 
> 
> Indeed, these notes were aimed at an advanced audience (master level or
> more). 

I think a good "Theoretical OCaml" course could be constructed from John
Harrison's notes (updated for OCaml) followed by your APPSEM notes. There's
some overlap, but that seems right to me. 

> Actually, I have just finished a first revision of these notes (thanks,
> Brian for your support). Mainly, I fixed some typos, improved the
> presentation and added exercises. The size also increased by 40%.
> 
> I might do a second revision in the fall. 

Great, please announce the updates to the list, since I think it is of
general interest. 

> > > http://cristal.inria.fr/~remy/isia/
> > 
> > This is in French, which would be a problem for a lot of programmers that
> > I know. Interestingly, I seem to have picked up enough written French from
> > reading this list (with a dictionary and some phrasebooks of course) that 
> > I could read almost all of this. 
> 
> Conversely, the ISIA notes were written for Ocaml beginners without much
> theoretical background.  I included some of this material into the APPSEM
> notes and I may add more in the future.

The beginners without much theoretical background is a very large group. 
Now that Jason Hickey's compiler course notes are available, the pressure 
for more extensive beginner docs, like the O'Reilly translation, are
reduced, but I think that such a doc should be available on the web in a 
format where it can be modified by volunteers. OCaml continues to evolve, 
but a static document will fall behind. Both the O'Reilly book and the 
CalTech notes are already missing discussion of some of the latest
features. 

> > If Didier would like to make the TeX
> > available, I could take a stab at translating this. 
> 
> This would not be a problem for me, but there could be redundancy with my
> APPSEM notes. 

That's OK, the APPSEM notes are too scary for the raw beginner audience. 
Once they ride the camel, their curiosity surpasses their fear and they 
realize that they want to understand this beast in order to ride better,
and that's when theory steps in. 

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

[Arturo Borquez]

On Mon, 11 June 2001, Pierre Weis wrote:

>
> 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!).
> 
I must add to this that after three month evaluating and testing some server apps at my company, we have decided as part of a major improvement (that includes a new DB model) to port ALL our propietary server apps (mainly C/C++) to OCaml. The survey we did show that OCaml productivity is 5 to 10 times C/C++, runtime and memory perfomance good enough to put it in production. Also we have found that the core language / libraries supplied fullfill almost our needs. We envise OCaml as a part of the key to provide customers satisfaction (quality services and requirement responsiveness). The lack of 'market programmers' in OCaml certainly is an issue, so we started doing capacitation investments (3 month 45 min/day/programmer) that are marginal in the long term and payed in excess with the benefits of the language. As OCaml isn't already a 'popular' language we are confident that these guys will stay with us as they earn more money with less effort and enjoy programming in OCaml, !
they don't want back to boring C/C++.

My experience 'teaching' Ocaml to C/C++ programmers are:

1) Remark the difference between imperative vs FP. The analogy of a spreadsheet or a calculator (without parens -> imperative) (with parens -> FP) is very usefull, the programm is an expression to be evaluated not a sequence of instructions. It seems me that this is the main obstacle at the begining to switch from the 'sequence thinking' to the 'expression thinking'.

2) Use a blackboard and show a piece of code known by the audience at the left side in C/C++ and at the right side in OCaml. Take all the time to disscuss the differences. Even more is better if you show a gentle trasition from imperative to FP style for the example regarding not to obfuscate with too much abstraction. Do it trivialy and simple as possible.

3) Do not introduce explicit typing annotations or partial function application at the begining. Let beginers to practice and be confident with type inference. 

4) Stay in the core language and libraries for a while (don't hurry). Even some functions exercised were polymorphic by nature don't distract attention.

5) Introduce the typing system, modules and labels at a second stage. Explain polymorphism partial function applications currying, recursions. Put the accent in FP style.

6) Develop a full fledged known application step by step. Show how you can improve starting with the design and the befefits of coding OCaml. It is very important sychological issue to transmit confidence to programmers, be patient.

7) Continuity. Give some real apps to code to do in pairs programmers and give them continuos time to do it (do not disturb them with other stuffs and support them as they need).

8) As programmers get skilled revise old code, show the enhancements that could be made. Let them to discover and exercise the advanced features of the language. I am not a fun of OOP and I try to avoid OOP code in our apps, but it isn't a religion, certainly I have used LablGtk. 

OCaml is so good that even if it would freezed by INRIA we plan to use it as much we can. I am not allowed by my company to reveal some commercial details but I can inform that we serve about 1000 customers client workstations along the country, at a rate of 80000 transaction/day. I have no doubt upon the success of this proyect and surely it will open the door to other projects with OCaml.

Best Regards
Arturo Borquez (Chile).


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.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

Re: [Caml-list] ocaml complexity

[Miles Egan]

On Mon, Jun 11, 2001 at 01:33:49PM -0700, Arturo Borquez wrote:
> My experience 'teaching' Ocaml to C/C++ programmers are:

Thanks for your comments.  I think this kind of pedagogy is the right approach.
It will be interesting to what impact the English version of the O'Reilly book
has. 
 
-- 
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

[wester]

> On Mon, Jun 11, 2001 at 01:33:49PM -0700, Arturo Borquez wrote:
> > My experience 'teaching' Ocaml to C/C++ programmers are:
> 
> Thanks for your comments.  I think this kind of pedagogy is the right
> approach. It will be interesting to what impact the English version of the
> O'Reilly book has. 
> 
Does anybody know when the O'Reilly book will be available?

Rolf Wester


-------------------------------------
Rolf Wester
wester@ilt.fhg.de
-------------------
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]

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

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

[Caml-list] ocaml complexity

[Miles Egan]

I'm not sure how easy it will be to bring this up constructively, but I'm
curious to hear what others have to say so I hope I can make it clear that this
isn't a criticism of ocaml but an honest curiousity.

I've been studying Ocaml on and off for about three years now and although I'm
still very impressed with its power I still don't really feel like I understand
it very well.  I've also learned lisp, scheme, and python in the last few years
and, although Ocaml seems to me to be a more powerful language in many respects,
I feel that these other languages were much easier to learn.  This is partly due
to my inexperience with functional languages, I'm sure, but I don't think that
alone accounts for it.  

It feels to me to be more of an issue of the number of language features and
abstraction techniques each language offers.  The other languages seem to "fit
in my brain" better.  I have to admit that I find the conjunction of modules,
classes, variants, polymorphic variants, labels, references, streams etc. a bit
bewildering.  I find myself at a bit of a loss when starting a new program
because I have so many avenues of decomposition open to me.  I think I've
finally grasped the essentials well enough to write real programs in Ocaml, but
I can't say it's been easy.

I'm often tempted to push Ocaml as a solution for projects at work, but I
hesitate to advocate it too strongly because I honestly think Ocaml is beyond
the abilities of most of my colleagues.  I suspect only the brightest of the
programmers I've worked with will come to grips with both functional programming
and the large array of features Ocaml offers fast enough to justify the time
taken to retrain.

Of all the functional languages, Ocaml seems to me the most pragmatic and most
useful for everyday programming, but I wonder if it's within the grasp of the
everyday user.  I know a lot of fairly amateur C++ programmers who get by with a
small subset of the language, but it seems more difficult to limit oneself to a
small subset of Ocaml.

Have others had similar experiences?  I suspect most of the readers of this list
are better-than-average programmers.  How difficult have you found it to be to
teach Ocaml to your colleagues?  Any suggestions on a simple pedagogy for
bringing more junior people abreast of subjects as esoteric as polymorphic
recursive types?

-- 
miles
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Chris Hecker]

>Have others had similar experiences?  I suspect most of the readers of this list
>are better-than-average programmers.  How difficult have you found it to be to
>teach Ocaml to your colleagues?  Any suggestions on a simple pedagogy for
>bringing more junior people abreast of subjects as esoteric as polymorphic
>recursive types?

I agree that Ocaml is big and powerful, and I even think it's kind of ugly.  ;)  However, I've been learning it in stages so I don't agree with your statement about not being able to use subsets.

Features I'm using:  

closures, local and anonymous functions, libraries, imperative stuff, experimenting with higher order functions (but usually just 1st order (2nd?), where a function takes a function), tiny bit of currying, genlex parsers, nested data structures

Features I'm not using right now:

objects, heavy modules, functors, streams (besides simple genlex things), heavy duty polymorphism, threads, lazy

I haven't taught anyone to use Ocaml completely, but I've walked non-functional (!) programmers through my code and they seem like they could get it.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Charles Martin]

>I feel that these other languages were much easier to learn.

There is a well established pedagogy for Lisp, Scheme, and ML which does not exist for OCaml.  The resources that are available are a bit more difficult for the novice to find and to use; for example, the tutorial for Caml (not OCaml), which the novice might pass by thinking it's not relevant, or books that are in French (only) or only available on order from Amazon for over $100.

I think a slight reorganization of the manual could help.  Right now, new users first see a tidy introduction to the "core language," and are then immediately thrown into a discussion of labels, "commuting labels mode", and polymorphic variants.  The novice wonders: Is this important?  Can I ignore it?  Who knows?  Let's skip ahead: the next section of the manual covers objects, parameterized classes, coercions, etc.  More confusion.

Once up to speed on OCaml and a regular reader of caml-list, the novice will realize that objects, labels, and polymorphic variants are not in wide use.  Indeed, they weren't included in the "core language" discussion.  But modules appear to be more central to how OCaml is actually used.

Perhaps the manual could be restructured to make this clear:

        PART I - Introduction to OCaml

                The core language
                The module system

        PART II - Advanced Topics

                Objects in Caml
                Advanced examples with classes and modules
                Labels and variants


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[Michael Hicks]

> Perhaps the manual could be restructured to make this clear:
> 
>         PART I - Introduction to OCaml
> 
>                 The core language
>                 The module system
> 
>         PART II - Advanced Topics
> 
>                 Objects in Caml
>                 Advanced examples with classes and modules
>                 Labels and variants

I think this is an excellent idea.  At Penn, our research active
internetwork has two publicly available implementations: one in Java, and
the other in Ocaml.  Despite the fact that the Ocaml implementation is more
flexible, better documented, faster, and still maintained, most users go for
the clumsy, slow, poorly documented, unmaintained Java implementation (even
after trying the Ocaml one) because they balk at learning Ocaml.  Making the
language easier to learn (and your suggestion above seems like a good start)
would be a boon to the community I think.

Mike

-- 
Michael Hicks
Ph.D. Candidate, the University of Pennsylvania
http://www.cis.upenn.edu/~mwh            mailto://mwh@dsl.cis.upenn.edu
"In essential things, unity; in doubtful things, liberty; in all things,
 charity." --Pope John XXIII, Ad Petri Cathedram, and popularly 
 attributed to St. Augustine

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[David Fox]

Charles Martin <charles@chasm.org> writes:

> I think a slight reorganization of the manual could help.  Right
> now, new users first see a tidy introduction to the "core language,"
> and are then immediately thrown into a discussion of labels,
> "commuting labels mode", and polymorphic variants.  The novice
> wonders: Is this important?  Can I ignore it?  Who knows?  Let's
> skip ahead: the next section of the manual covers objects,
> parameterized classes, coercions, etc.  More confusion.

Is the manual available in source form?  I haven't been able to find it.
-------------------
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

[FabienFleutot]

> Perhaps the manual could be restructured to make this clear:

Another simpler and faster solution, which could be done without taking time
to the ocaml development team, would be to write some sort of
"Ocaml user manual's user manual": a small document indicating what parts of
the manual are important relative a given purpose, what are the more common
beginner mistakes to avoid, and a guide about the order in which the
different concepts should be studied.

Here is a list of the most common "autonomous Ocaml learner" mistakes I've
been faced to, as a former beginner and as an Ocaml evangelist with my
friends. We should discuss about that, then write it down in a user manual's
manual. Please note that these features are already dicussed in the manual:
my purpose is just to concentrate them in a place where they are focused on.

This would be my ---unsorted--- hot points list;
addition/modifications/removal are obviously welcomed:

- The compiler relies on upper|lowercaseness of the words
- Use currying for multiple-parameters functions instead of tuples
- Use of the fun keyword (it semmes to me the relevant part of the manual
has been rewritten between Ocaml 2.04 and 3.00, and the newer version is
much clearer).
- Don't reinvent hot water, and study at least the List library
- When two features have some common points, explain what's common and what
are their respective advantages (structures vs. cartesian products,
parentheses and begin..end, etc.). Beginners often can't imagine that two
different features have a lot of common parts, if it is not clearly set.
- Show how many different things can/should be done by pattern matching.
- usefulness of .mli files
- many other points I've forgotten.

I guess that those who have teached ocaml programming in an academic frame
will stress some very different points: this would be interesting to compare
with.
-------------------
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 Wed, Jun 06, 2001 at 11:25:43AM -0700, Charles Martin wrote:
> Perhaps the manual could be restructured to make this clear:
> 
>         PART I - Introduction to OCaml
> 
>                 The core language
>                 The module system
> 
>         PART II - Advanced Topics
> 
>                 Objects in Caml
>                 Advanced examples with classes and modules
>                 Labels and variants

I like this idea.

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

[Caml-list] ocaml complexity

[William Chesters]

Miles Egan writes:
 > Of all the functional languages, Ocaml seems to me the most pragmatic and most
 > useful for everyday programming, but I wonder if it's within the grasp of the
 > everyday user.  I know a lot of fairly amateur C++ programmers who get by with a
 > small subset of the language, but it seems more difficult to limit oneself to a
 > small subset of Ocaml.

 > Have others had similar experiences?  I suspect most of the readers of this list
 > are better-than-average programmers.  How difficult have you found it to be to
 > teach Ocaml to your colleagues?  Any suggestions on a simple pedagogy for
 > bringing more junior people abreast of subjects as esoteric as polymorphic
 > recursive types?

Objectively, C++ is much harder to learn than ocaml and you have to be
_brilliant_ to make the most of it without getting into trouble.  The
point surely is that people are more familiar, or at least feel
embarrassed about being unfamiliar, with the _jargon_ of C++ as
against that of ocaml.

Try this table:

ocaml closures \approx anonymous classes with one "virtual operator ()" method

ocaml sum types \approx C union with attached variant code

ocaml polymorphic types \approx generic types via templates

   -- but no worries about template instantiation, or bloat, or
      having to learn about the STL!

                     or \approx void * pointers in C
   -- but with typechecking of course

ocaml recursive types = C++ recursive types
   -- but less confusing---try explaining to a junior programmer
      what does and does not provoke "incomplete type not allowed"
      in templatey C++ code

ocaml functors, or paramaterised modules, \approx C++ templates
   -- but in ocaml you get to give signatures, hooray (typename anyone???)

ocaml classes \approx C++ classes in which all methods are virtual


The really big cultural shift is to think in recursive not iterative
terms.  I really don't know how to teach that or even explain why it's
sometimes a nice way to look at things.  But of course in a
multiparadigm language (like ocaml or, well, C++) that's more a matter
what you do with the language rather than the language per se.

Another thing that throws people, strangely, is the sheer
conciseness of functional languages---even ocaml (let alone Clean).

Finally I think there is a hard core of people who cannot understand a
language until they know how it is implemented.  In fact ocaml is
implemented in a very machine-friendly way (which is why it's so fast
and practical).  Maybe it's a useful exercise to write out equivalent
C---just as it's a great way of explaining C++ to people.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

William Chesters wrote:

> The really big cultural shift is to think in recursive not iterative
> terms.  

	I don't agree. It does take time to learn to use
recursion and inductive data types effectively, but they
exist in C++ too.

	The really BIG culture shift, in my opinion,
is something much simpler: syntax. I think humans,
particularly experts, can read programs by high speed
unconscious pattern matching that is _highly_ sensitive
to syntactic form, and even lexicology. 

	Just try reading C++ or Ocaml which is not sensibly 
indented to see what I mean, or switch the colours around
in your favourite colourizing editor to get immediate
vertigo and loss of comprehension.

	Or have a look at the arguments about which
operator to use for some feature. Syntax is more
important than most of us think.

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

Re: [Caml-list] ocaml complexity

[William Chesters]

John Max Skaller writes:
 > 	The really BIG culture shift, in my opinion,
 > is something much simpler: syntax.

I agree that's very significant.  C++-style syntax with camlp4,
anyone? :)
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

William Chesters wrote:
> 
> John Max Skaller writes:
>  >      The really BIG culture shift, in my opinion,
>  > is something much simpler: syntax.
> 
> I agree that's very significant.  C++-style syntax with camlp4,
> anyone? :)

I know there's a sort of smiley there, but this is more or
less what I'm working on: I'm developing a new programming
language, Felix, for C++ users, which has the main features
of functional programming, including closures, higher
order functions, variants, pattern matching,
modules, and garbage collection.

Felix provides overloading, uses {} to denote blocks
in which all definitions are recursive,
has type inference for variables but not functions,
uses SML/Ocaml type grammar, and binds cleanly
with C++ (partly because it's a C++ code generator).

Here's a complete working example, I hope it is
readable to both C++ and Ocaml programmers.
[I also hope 6! = 720, because that's the answer
that gets printed :=]

--------------------------------------------
header '#include <stdio.h>';

type bool = "bool";
type int = "int";
proc print: int = 'printf("%d\n",$1);';
fun sub: int * int -> int = "$1 - $2";
fun mul: int * int -> int = "$1 * $2";
fun gt: int * int -> bool = "$1 > $2";

fun fact(a:int): int
{
  fun f (a:int, p:int) : int {
    if(a>1) return f(a-1, p*a);
    else return p;
  }
  return f(a,1);
}

print (fact 6);

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

[Miles Egan]

On Wed, Jun 06, 2001 at 09:36:16PM +0200, William Chesters wrote:
> Miles Egan writes:
> Objectively, C++ is much harder to learn than ocaml and you have to be
> _brilliant_ to make the most of it without getting into trouble.  The
> point surely is that people are more familiar, or at least feel
> embarrassed about being unfamiliar, with the _jargon_ of C++ as
> against that of ocaml.

C++ is certainly a pathological worst case, and I can't really think of another
language as baroque and confusing (certainly not Ocaml).  I suppose the biggest
hurdles for programmers new to Ocaml are type theory and functional thinking.

Software development is an essentially complicated task these days, so good
tools will probably necessarily be somewhat complex too.  I certainly intend to
keep using and advocating Ocaml.  I'm mainly interested in finding out what
other working programmers are doing to sell it to their colleagues.

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

[David Fox]

Miles Egan <miles@caddr.com> writes:

> On Wed, Jun 06, 2001 at 09:36:16PM +0200, William Chesters wrote:
> > Miles Egan writes:
> > Objectively, C++ is much harder to learn than ocaml and you have to be
> > _brilliant_ to make the most of it without getting into trouble.  The
> > point surely is that people are more familiar, or at least feel
> > embarrassed about being unfamiliar, with the _jargon_ of C++ as
> > against that of ocaml.
> 
> C++ is certainly a pathological worst case, and I can't really think
> of another language as baroque and confusing (certainly not Ocaml).

Not to belabor the obvious, but C++ has the huge advantage of being
(for all practical purposes) a superset of C.  Its like the mother of
all tutorials.
-------------------
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

[wester]

> I've been studying Ocaml on and off for about three years now and although
> I'm still very impressed with its power I still don't really feel like I
> understand it very well.  I've also learned lisp, scheme, and python in
> the last few years and, although Ocaml seems to me to be a more powerful
> language in many respects, I feel that these other languages were much
> easier to learn.  This is partly due to my inexperience with functional
> languages, I'm sure, but I don't think that alone accounts for it.  
> 
Lisp and Scheme are functional languages too. Concerning Common Lisp 
I think it's a much bigger language and also a very powerful one (may be
in some other respects than OCaml).   
>
> It feels to me to be more of an issue of the number of language features
> and abstraction techniques each language offers.  The other languages seem
> to "fit in my brain" better.  I have to admit that I find the conjunction
> of modules, classes, variants, polymorphic variants, labels, references,
> streams etc. a bit bewildering.  I find myself at a bit of a loss when
> starting a new program because I have so many avenues of decomposition
> open to me.  I think I've finally grasped the essentials well enough to
> write real programs in Ocaml, but I can't say it's been easy.
> 
I don't know of course how difficult it had been for me to learn OCaml
as a first language but my personal experience with OCaml is, that
it is not very hard to learn. I think C++ is more complex and seems 
not to be so clearly structured as OCaml is. I'm much more experienced 
in C++ programming but I enjoy doing things in OCaml. One of the 
main advantage for me is the toplevel of OCaml. You can easily try
out things and so learn much faster as oposed to compile/link/run 
in C++.

> I'm often tempted to push Ocaml as a solution for projects at work, but I
> hesitate to advocate it too strongly because I honestly think Ocaml is
> beyond the abilities of most of my colleagues.  I suspect only the
> brightest of the programmers I've worked with will come to grips with both
> functional programming and the large array of features Ocaml offers fast
> enough to justify the time taken to retrain.
> 
> Of all the functional languages, Ocaml seems to me the most pragmatic and
> most useful for everyday programming, but I wonder if it's within the
> grasp of the everyday user.  I know a lot of fairly amateur C++
> programmers who get by with a small subset of the language, 

Those who are content with getting by with a small subset of a language 
probably don't like programming and so will not be willing to learn a new
language. 

>but it seems
> more difficult to limit oneself to a small subset of Ocaml.
> 
Why?

> Have others had similar experiences?  I suspect most of the readers of
> this list are better-than-average programmers.  How difficult have you
> found it to be to teach Ocaml to your colleagues?  Any suggestions on a
> simple pedagogy for bringing more junior people abreast of subjects as
> esoteric as polymorphic recursive types?
> 

> -- 
> miles
> -------------------


-------------------------------------
Rolf Wester
wester@ilt.fhg.de
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml complexity

[John Max Skaller]

wester@ilt.fhg.de wrote:

> Those who are content with getting by with a small subset of a language
> probably don't like programming and so will not be willing to learn a new
> language.

	I find that a strange comment. I know C++ pretty well,
but I only use a subset of it. Indeed, I claim that this is
_because_ I know it so well. Preferably, the empty subset :-)

	I use a subset of Ocaml for a different reason:
the subset seems adequate for what I need, and I don't
understand some of the higher level constructions well enough
to rely on them. In this case, I'd love to learn more ..
which is why I read this list :-)

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