

What can OCaml do that you can't do in other programming languages? - baha_man
http://camltastic.blogspot.com/2008/09/what-can-ocaml-do-that-you-cant-do-in.html

======
tptacek
(1) Almost every high level language has a bit-struct-style binary parsing
library. Python, Perl, and Ruby all have libpcap file parsing libraries. And
yet the overwhelming majority of raw packet processing code is still written
in C, because it's just not that hard.

(2) Ok, type checking is kind of the point of OCaml. If you're into that sort
of thing, go for it.

(3) High level languages are slow and getting much, much faster. Javascript,
Python, and (soon) Ruby are getting JIT'd to native code and threaded C calls.
And all of them have foreign function interfaces that let you call into C/C++
code when you actually care about speed.

(4) I doubt anyone's choosing OCaml over Python for the library support.

~~~
jlouis
(1) Erlang, Ocaml, Common Lisp, Scheme, and Haskell can all, with relatively
mundane code, parse a TCP/IP packet in 4 lines, nicely formatted, and some of
them gets it type-correct at the same time. The problem isn't that you cannot
do it in C, the problem is that you are wasting your time doing it. When it is
reasonably fast as well, there is no excuse.

(2) Indeed.

(3) JIT and tricks from Self will not make the code faster than a well-
implemented Ocaml. Also, the complexity of said implementations leaves much to
be desired. If you know how little optimization the Ocaml compiler does when
compiling to native code you are pretty amazed that it is so damn fast.

The point here is: will $LANG scale along the speed axis? _Currently_ (it may
change) Python doesn't. It scales up to a point at which you go write your
code in C/C++. JSON decoders/encoders that are fast happens to be a nice
example. Contrast that with Haskell, Ocaml, Common Lisp where you can improve
your program and scale it far more on the speed axis before you have to
succumb to Fortran77 for your libatlas ;)

For most problems, this scalability is not that important. But then again,
there are some where it is crucial you can get that extra speed.

Personally, I program in both Ocaml and Python at work. We have most web-stuff
written in Python whereas some backend parts, where correctness and speed
matters, are written in Ocaml. We could have used C/C++ at the backend, but
our development time is much lower in ML with a fraction of the effort
required.

On the other hand, the Pylons framework does wonders for the web-frontend. We
don't need the type-correctness as much there, the speed doesn't matter that
much either as long as we can serve pages up quickly enough. I would be sorry
using Ocaml there as it would hamper the development speed and take more time.

Bottom line: I dual-wield!

~~~
tptacek
I'm not seeing what you can do with Common Lisp or Scheme in 4 lines of code
that you can't do with Python and Ruby.

~~~
PieSquared
(format nil "I have~{ ~(~A~)~#[~;, and~:;,~]~}." '(red green blue black white
yellow))

~~~
gruseom
That's sort of cheating, since you dropped out of CL into the format mini-
language.

~~~
PieSquared
You're right of course. I was also considering showing off the loop macro.
That one actually wouldn't have been cheating, since it shows off macros (A
pretty nifty and central feature of Lisp)

    
    
      (loop for x from 1 to 10
            as x-sqr = (* x x)
            collect x-sqr)
    

Or something like that.

------
time_management
OCaml's type-checker is pretty awesome. You get the benefits of static typing,
although you almost never have to declare types.

This also makes interfaces easier to understand. You can often understand what
a function does without looking at the documentation or code. For example,
let's say you've never heard of a map before, and you peek in the .mli file
for the List module and see:

List.map : ('a -> 'b) -> 'a list -> 'b list.

This means that it takes a function (whose type signature is 'a -> 'b) and a
list of 'a, and returns a list of 'b. Your first guess is that it produces the
item-for-item image of a list under a function, e.g. f [a0; a1; ... an] -> [(f
a0); (f a1); ... ; (f an)]... and you'd be right.

Pattern-matching is also a huge plus of the language, because it saves you
from having to do a lot of ugly if/then kung fu and makes the code more
readable.

