What can OCaml do that you can't do in other programming languages? | Hacker News Reader

What can OCaml do that you can't do in other programming languages?

camltastic.blogspot.com

9 pointsbaha_man8 comments

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

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

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.

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

    a = ["red", "green", "blue", "black", "white", "yellow"]; "I have %s and %s" % (", ".join(a[:-1]), a[-1])

Well almost...

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

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.

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.

Reply on news.ycombinator.com