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

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

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