On Tuesday 01 April 2008 09:26:30 salog wrote:
> I have encountered to this article about some OCaml experience:
>
> http://schani.wordpress.com/2007/07/23/why-ocaml-is-not-my-favorite-program
>ming-language/
>
> The author gives an example of arithmetic calculations in OCAML and
> scares with weakness of the type-safe programming exceeding it's
> benefits.
>
> I doubt that the language developers planed using OCAML in this
> programming style.
> Probaly there is a problem in C- like author's thinking style but not
> in the language.
> At least I hope this.
>
> What's wrong in the article?
There are many such articles out there for any given language but your first
port of call as a beginner should always be articles written by people who
love the language.
As Sylvain said, this guy has basically just completely missed the plot.
His first example regards different kinds of integers. Languages provide
different kinds of integers for three main reasons:
. Performance.
. Memory consumption.
. Compatibility.
Yet this author fails to discuss any of these aspects. In practice, Lisp
allows you to manually annotate integers on an individual basis in an attempt
to obtain adequate performance and memory consumption using "fixnum" but the
author fails to mention this too.
Functions are very important in functional programming, of course, yet the
author fails to make use of OCaml's extensive built-in support for currying
in his function to add 3, which should be:
(+) 3
A faithful Lisp equivalent is:
(lambda (x)
(declare (fixnum x))
(+ x 3))
Suddenly the Lisp is not quite as alluring for the vastly more practically-
relevant task of adding machine-precision ints.
Moving on to his second example, in Lisp:
(defun chop-rev (seq)
(reverse (subseq seq 0 (1- (length seq)))))
This is the classic mistake of trying to factor out commonality from functions
when there is none. Consequently, his implementation is uniformly inefficient
on all data structures.
The ability to write such functions that can be applied to lists and arrays is
almost entirely useless in practice because these data structures have
virtually nothing in common. This is why OCaml's ability to statically check
that you have not accidentially passed a list instead of an array is useful.
The author touches upon this subject but fails to mention that Lisp is
completely incapable of enforcing any guarantees at compile time.
His assumption that Buffer is "really just a string" is completely wrong.
Buffers are string builders, not strings.
His assertion that OCaml is limited to 16Mb arrays is correct for legacy
systems but I think it is only fair to mention some equivalent problems with
Lisp. For example, you can apply a function to a list in Lisp using "apply"
but this can fail on lists as short as only 50 elements!
http://www.lisp.org/HyperSpec/Body/convar_call-a_uments-limit.html
http://groups.google.com/group/comp.lang.lisp/msg/ee2fa821c8ab7a2d
A 50-element limit will be slightly more of a hindrance than a
16,000,000-element limit...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"ocaml-developer" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/ocaml-developer?hl=en
For other OCaml forums, see http://caml.inria.fr/resources/forums.en.html
-~----------~----~----~----~------~----~------~--~---
