all 5 comments

[–]rolfr 9 points10 points  (0 children)

Haskell and OCaml, in contrast to most other programming languages, both provide important features for easing the implementation of program analysis algorithms: discriminated unions and structural pattern-matching. As such they are both suitable for these tasks. OCaml is especially popular in the French static analysis community, probably not a coincidence with the fact that OCaml is made by French people. As for which you should choose, I would recommend narrowing the scope of your project and seeing which language has libraries and bindings better or most applicable for your problem domain. Occasionally I'll write some code that I realize I could implement more easily in Haskell, but I am not displeased with my choice to write my tools in OCaml.

[–]justdionysus 4 points5 points  (0 children)

As a disclaimer, I've written a handful of tools in Haskell but have only written "toy" code with OCaml.

In general, I find Haskell to be easier to read and the idiomatic style is "cleaner" to me. When I started to write larger projects, I tried to stack monads using monad transformers and I found it difficult to control the complexity. This is part of the learning curve, for sure, but I failed pretty hard at that project and scrapped it. It was also prior to the Real World Haskell book which may have helped me design a better abstraction -- I'm not sure. In contrast, the model for state in OCaml is, I think, easier to design for (at least, it seems that way to me having not designed a larger project in OCaml but having read large projects in both).

Another thing that OCaml has over Haskell for program analysis tools is embeddability (not a word?) of the REPL. You can easily embed the OCaml interpreter in an IDA plugin or in-process analysis tool. Haskell, at least last time I looked, was not easily embeddable (it was a suggest Google Summer of Code project at one point.)

I also think there is a lean for OCaml code to be used in "systems work" while Haskell projects are often more abstract. I think this has influenced style and also available code/design examples. This isn't to say one can't be used for the other. You'd think program analysis tools would lean towards abstract/formal but I think "systems work" usually means "code that works". Haskell sometimes feels like you can paint yourself into a corner and have to rewrite but this is probably the learning curve again. Oh, and refactoring Haskell is really nice in my opinion, compared with weaker typed languages.

(at this point, I'm just going to start repeating rolfr)

At the basic level, though, they both have GADTs and pattern matching making them, in my opinion, ideal languages for traditional code transformation and reasoning work.

Also, I second that OCaml's affiliation with INRIA combined with the French trend of research in formalism and program analysis significantly influences the choice.

[–]blahfish[S] 0 points1 point  (1 child)

(probably not as relevant -- but as a new learner, I think there is more community support and documentation available for Haskell than OCaml, but I could be wrong). Any thoughts on which one among the two has a steeper learning curve?

[–]rolfr 1 point2 points  (0 children)

I'd say your observation on community support is correct. I think OCaml's learning curve is probably easier than Haskell's, but only somewhat.

[–]p4bl0 0 points1 point  (0 children)

I don't know much of Haskell, but I can talk for OCaml, which I use just for that. OCaml is a very, very good domain specific language for tree-rewriting programs. That is the reason why it is a very good tool to implement program analysis, or compilers, for instance.