Why did you learn OCaml?

Community
101

Let me try to tie this thread from two different sub-threads. A lot of people come to OCaml and miss things they have in Haskell or whatever else. But one of the reasons OCaml is so cool and interesting to me is how finely tuned it is. Everything is balanced so carefully that it feels like carelessly jamming on some feature or the other would ‘ruin’ it.

  • OCaml doesn’t have type classes but it does have functors, blazing-fast compilation speed, and much better type errors than Haskell’s ‘No instance of … found for …’
  • OCaml doesn’t have operator overloading but it does have strict static types with no willy-nilly casting of some types to others, everything is explicit and you know exactly what you’re paying for when you’re dealing with numbers
  • OCaml doesn’t have a clean syntax (arguably) like Python or F# but in exchange you do get a whitespace-insensitive syntax so that you can layout your programs in exactly the right way for the program, and of course copy and paste code without regard to indentation level. And also no need to learn weird offside layout rules.
  • And so on, I think you get the picture.
4 Likes
102

Sure, but whether you consider it awful or not, that’s C++ operator overloading.

In Haskell, you could say, sure, the operator is one of a number of possible functions, but my point is that you do know, implicitly but exactly, which one. Or to be more precise, you know that as well as you know which type the objects are that it’s operating on; you may very well not know that, but then that’s the whole point of polymorphism. You couldn’t ban it from a Haskell shop, without banning arithmetic, and there’d be no point anyway.

103

Do you write much C++? Disciplined C++ is not that different from Ocaml in comprehensibility and maintainability. It’s just a lot harder to maintain the discipline, and there’s no compiler to help with some of the rough bits. Of course, it’s typically crazy faster. So there’s that.

I think you’re imputing your experience and love of Haskell, to the experience of C++. And I don’t think it carries over. In addition to operator overloading, the style guide also forbids the “clever” uses of “template metaprogramming” (e.g. using template matching as a bit of a logic-programming language), so it’s not merely operator overloading. It’s all the ways in which C++ code can be written so that an experienced engineer, who doesn’t know your code, will be stymied from understanding it for a good long while.

104

No! I did write a couple things back in the '80s and '90s that were used for a long time, but that’s almost a different language. When I go back, I find that practically every programming language in existence has spoiled me, not just Haskell. And really if I were such a huge Haskell devotee I wouldn’t be here.

My point is not that Haskell is better than C++, but that whatever you think about C++'s operator overloading, that applies only to C++'s operator overloading, and not to Haskell’s typeclass implementation of what might appear to be the same thing, because its relation to Haskell programming is categorically different.

1 Like
105

I don’t want to turn this thread into a C++ thread, and I left it overnight before deciding whether to comment on this, but this morning felt sufficiently moved to do so. I am saying that I think C++ has serious problems, most notably with the attitude of the C++ standard committee who seem to be quite happy to have had the C++17 standard break previously valid C++11/14 code, particularly in its changes to object lifetime rules. Did you know that you cannot now construct even trivial objects (ints and so forth) in raw malloc’ed memory by assignment or memcpy() as in C - you have to use placement new. This will break shed-loads of previous code. And array placement new is totally defective and unusable. Furthermore it is no longer enough to comply with strict aliasing rules when considering pointer dereferencing - you now also have std::launder to consider. And they didn’t notice that std::uninitialized_copy() and cognate functions now, by their own rules, have undefined behaviour!

If you want to see something which makes you consider the competence of the committee, read this committee document pointing out defects in C++17: P0593R6: Implicit creation of objects for low-level object manipulation

You simply don’t get this kind of stuff in Ocaml, nor in Haskell or Rust for that matter. There is no way the C standard committee would do this kind of thing and I now try to avoid C++ in new projects. Something like Ocaml with C for the hairy or maximum-speed bits works well I think.

4 Likes
106

Or OCaml and Rust! Should make an amazing combo.

107

It fits right into this thread, I think, in terms of the relative attractions of OCaml vs. different languages. I’m here partly because I perceived OCaml’s development as more conservative, less likely to break older code for any reason but particularly for the sake of just rearranging the furniture. So … it’s true, I hope?

1 Like
108

I think it’s true that OCaml’s changes are more conservative than many. But many languages have had to flex with the times, perhaps because of being more adventurous in the past. Haskell was an experiment which managed to escape the lab, thanks largely to application of monads making it practical… which turned out fuel a lot of (probably) good ideas across many languages!

And I think one of OCaml’s practical friction points is the lack of a typeclass/trait-like feature to simplify some common programming idioms (like abstracting the idea of adding and allowing the same glyph to implicitly work for things which can be added). So you clearly have a point when bringing up a longing for typeclasses – it’s not like we’re all completely satisfied with the state of things. This is why a lot of OCaml programmers have been eager for modular implicits. Most languages take a very ad-hoc and unprincipled solution to this which simplifies (in one way) the specific cases of arithmetic operators only. I really like the idea of modular implicits allowing for resolving unambiguous cases (to the compiler), though it can add a bit more ambiguity for a programmer reading the code (quickly resolved by editor tools), just as with inference itself.

For myself, at first I cringed at explicitly different float ops, then I’ve found over time that I quite like the clear assurances of explicit functions and operators… mostly simplified in practice by the lightweight M.( ... ) style of local module opening so I can work with a particular set of functions more fluidly yet retain the clarity as written. However, this doesn’t work well when functions from many modules are interleaved such as with a flow of transformations with operations. This is where I’d value a bit of modular implicit help. :slight_smile:

7 Likes
109

Since I guess it was more or less I who brought up Haskell typeclass in this thread, as a thing I miss in OCaml, … I’ll add, that I don’t miss them so much that I’d ask for OCaml to break a lot of old code to add any such thing. Or to potentially detract from ability to understand code.

2 Likes
110

35 posts were split to a new topic: On interoperability between Rust and OCaml

145

Initially learned it at my university. Luckily the new prof decided to teach OCaml instead of Lisp, which was being taught there up until then. Haven’t touched it in years, until I spent a year or two dabbling with Haskell, realizing that it was too academic for myself and rediscovered OCaml.
Part of the reason of course is also disenchantment with the industry-accepted languages C++/ Java/python.

4 Likes
146

the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.

I know that feel. It’s almost like a law that the nicest languages cannot become the most popular.

5 Likes
147

Oh, this is quite close of how I came back to OCaml: I initially learned OCaml (or more precisely Caml light) in the first years of university . Then I went on to study physics and dabbled in all classical programming languages for physicists and few other (C, Java, Fortran, matlab, C++, Igor, Haskell, …).

And it was after writing some toy simulation in Haskell with terrible performance for a master’s project that I decided to rewrite it from scratch in OCaml.

At that point, I was sold on OCaml and spent my PhD thesis wrtting code in either matlab (for my advisor), OCaml (for me) or C++ (for performance).

Sometimes later, I started to write camlp4 extensions for doing linear algebra, soon followed by a PR for custom index operators… And few years later, I am now working on the OCaml compiler at Inria.

11 Likes
148

Part of it is has to do with the fact thatOCaml was too entrenched in academia. And a bigger part is the inertia. They’ll keep debugging the NULL pointers and memory corruption issues before they switch to a nicer language. The barrier of entry is pretty high for OCaml too, which would lead to scarcity of developers and higher wages. Who wants that? :smiley:

2 Likes
149

I started with c++ at uni wheras it didn’t spur the slightest excitation in me. My mind ain’t imperative :/. Retrospectively the world partitions in three. (Conservative) industry, (Research) school, (voluntary/spontaneous) entrepreneurship. Engineering led to the industry, ergo c++. Soon I upgraded to D (dlang) impressed with the cpp lab tidying up. Casting off evangelists and conformity I found hundreds of languages. All had bigots, all claimed holiness, programming grail. A big sea. I felt lost. I looked up this page[randomly] https://rosettacode.org/wiki/Y_combinator and browsed for one single criteria : smallest code ever. I repeated this on various entries, not understanding any of it, just the sloc count. Why ? Because math is my girlfriend and it has semantic compression. That trait is easily spotted at first sight as everything(geometry, topology, algebra…) is piles of abstraction, encapsulations, DSL made upon more DSLs, thanks to a low level grammar found in the fabric itself. I filtered out OCaml, Haskell, Lisps as contenders. All smelled like math. Oddly enough, I just used my vision skills(pattern recognition engine) to subconsciously identify transliterated math scripture in foreign gibberish ! I then found out it was indeed descendants of a common root, lambda calculus. How funny I could spot a “visual invariant”. I was surprised that maths had another syntax for Turing machines. It’s no coincidence I had immediately recognised the familiar structure and adopted functional programming with a crush :blush: ever since. I was quite relieved that ended my quest.

In the thread I read a lot of confrontation on typeclasses. Personally I think Haskell and OCaml are not comparable. They simply derive different axioms. I do understand evolutionary behaviours such as mimicking, copying, mating ! But rather I see two isolated pools of researchers evolving endemic species. Orange-breasted sunbird and glacier bear. (OCaml is featherweight, Haskell is heavyweight). So for instance, you prefer geometry over number theory but you can’t say one is better than the other.
In the end, this is really just biology which is just an optimisation strategy.

I don’t know how multicore came before modular implicit. Perhaps pragmatic OCaml is fast and now guaranteed to run exponentially faster, for free, for years to come.

To my eye, modular implicit/typeclasses provide abstraction mechanism. That’s all I care about to write compact code or more easily. Hence I find it seriously missing in the eloquence quiver. That’s why I am beginning Haskell. I have a gut feeling it can help with math content. To be clarified.

F# has nice computation expressions. See Tomas Petricek’s academic paper.

I spent hours in and out reading GitHub threads on OCaml internals I don’t understand any of. However I observe how the core community works/members collaborate. It’s always disciplined, rigourous, formal, research grade. I just feel in the right hands. I trust the people who made this with boundless confidence. Incidentally I am amazed by the imperative translation which is magics to me and I fail to understand where all the patches come from.

I concur with a previous remark. Haskell is too broad. Pragmas are daunting DSL warnings. OCaml programs are instead accessible :slight_smile:

To conclude, I came to OCaml naturally while it let me gain missing computing power !

8 Likes
150

Small note, OCaml has the equivalent now: OCaml has some new shiny syntax | Notes on Computing

4 Likes
151

I heard that computational expressions are not technically the same as do notation, because they integrate both comprehension syntax and do notation. I don’t know is that enough to say that CE are more powerful than do notation.

But all of that is offtopic, of course.

[1] https://github.com/dsyme/fsharp-presentations/blob/master/design-notes/ces-compared.md

P.S. Maybe ocaml vs haskell posts should be rebased to the new orphan thread too…

3 Likes
152

There are many things in your very poetic post that I do not fully understand, but I get a lot of what you mean. Personally, I have no formal background in maths (I’ve never even taken calculus), but I also find that modelling computation in terms expressions makes it so much easier to think about programs. Imperative programming sort of feels like throwing s*** at a wall to see what sticks, and statically typed functional programming feels like… some kind of mechanism where things “click” into place once they are correct. I like the click.

1 Like
153

I’m not sure about that. I think the question “why did you learn language x?” implies “instead of learning/sticking with language y”.

When OCaml is x, I think the most frequent cases of y are going to be Haskell, Lisp or F#. Of the three—in my not-particulary-humble opinion—Haskell is the only “serious competition” to OCaml. I think it makes a lot of sense to go into details about their differences in a discussion about why someone uses OCaml.

(and this is not to say that one should not use both Haskell and OCaml. They are both great programming languages)

154

[1] The paper I referred to was «The F# Computation Expression Zoo» http://tomasp.net/academic/papers/computation-zoo/computation-zoo.pdf

Thanks for the link to Don Syme’s discussion.

1 Like