pauldirac137

Marshall was a panelist on the ArrayCast podcast (https://www.arraycast.com/) which discusses all things relating to array languages. He's sadly missed :(

The author says: "If you have a reason to think that OCaml is the best choice for a new project please let me know your use case, I’m genuinely curious." I think it's overwhelmingly the best language for writing an interpreter or a compiler. I'm sure Haskell is also a good language for writing compilers, but whenever I tried writing interpreters in Haskell, I found myself fighting the laziness. Most of the criticisms listed strike me as things that bother people starting out in the language (syntax etc.) but which quickly become non-issues with more experience. And my experience with opam/dune has been _much_ more pleasant than with Cabal in Haskell (though ghcup has certainly improved matters). I think the infrastructure in OCaml, which admittedly used to be quite poor, is now on par with any other language, if not better. However, if your application domain is one in which few OCaml libraries exist (e.g. web programming) you probably should look elsewhere.

Nano is OK, I guess, but it's a bit bloated. Now ed(1) -- that's an editor!

J is not closed source and hasn't been for a while. https://github.com/jsoftware/jsource

Can you be more specific? Show us the code that isn't working.

I would hesitate to call polymorphic variants "part of the OO infrastructure". They are really orthogonal to OO, but they do make OO less necessary. Ironically, OCaml has a really nice OO system but it's rarely used because with modules and functors there is little need for it. Put differently, a lot of the conventional use for OO is as a poor man's module system, and when you have a really good module system, you only use OO when you absolutely need the OO kind of polymorphism, and those cases are surprisingly rare (like existential types in Haskell).

You're right, but ST is also implemented using unsafePerformIO. The larger point is that you don't need to dress up a type signature with ST or IO just to use imperative code internally which can't leak out to the user level. Whether this is good or bad is a matter for debate, but used judiciously I think it's good.

Well, maybe "writing a compiler"? or "building a multimillion-dollar Wall Street financial services firm"? :-)

In fact, I love and use both Haskell and Ocaml, and I view the two languages as cousins. Both are functional. Both have features the other doesn't. Ocaml has the best module system in the business, with functors for module abstraction (unbelievably useful). This is much better than the current Haskell module system, though Backpack may narrow the gap. Ocaml also has polymorphic variants, which are surprisingly useful. Ocaml has some convenience features like named/optional arguments that Haskell doesn't. And oddly enough, the lack of purity in Ocaml (if used judiciously) can be a real win. You can do imperative programming without jumping through a lot of hoops. You can have code which is purely functional from the outside but which uses imperative idioms internally for efficiency (yes, I know about unsafePerformIO in Haskell, but it's much easier to do this sort of thing in Ocaml). And Ocaml is usually faster both in compilation time and run time.

My overall take on it is that I prefer Haskell for small-scale programming but I prefer Ocaml for large-scale programming. YMMV.

This is exactly the problem that modular implicits will solve. See http://arxiv.org/pdf/1512.01895.pdf

Correct. Multicore _may_ come in 4.04 if we're lucky. No ETA for modular implicits AFAICT, but I really want them ASAP; they will be a game-changer.

If you've been away from Ocaml for a while, this would be a great time to check out what's changed. A package manager, a new optimizer, and we'll soon have modular implicits (think Haskell-style type classes, but better) and multicore. Ocaml is really a first-rate programming language and I wish more people knew about it.

Harper is nowhere near as bad, fortunately. No F-bombs, for one thing. Harper is opinionated, curmudgeonly and sometimes arguably unfair, but he always backs up his opinions with reasoned arguments. Even when you don't like the way he expresses himself, he always has something insightful to say.

Yeah, when reading Harper it's best to skip over the opinion parts and just read the technical content (which is fortunately plentiful). I always feel as if he's jealous of Haskell's success.

Modules are strictly more powerful than Haskell type classes (at least, more powerful than naive type classes; there are so many extensions that I'm not sure that is still the case). Modular implicits are described here: http://arxiv.org/pdf/1512.01895.pdf. The main problem with modules as typeclasses is that it's pretty painful to use in practice, and modular implicits fix that, giving a solution quite reminiscent of Haskell type classes. I don't know Scala implicits well enough to comment, but the authors feel their version avoids most of the problems in Scala's implicits (they jokingly refer to it as "a more explicit kind of implicit").

Agree with everything you said, and I'd also add polymorphic variants. I too am a Haskeller now writing mostly Ocaml. I view the two languages as cousins. Both have great features the other doesn't. Both are worth learning and using.

F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.

I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.

All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.

Named parameters in Ocaml are not a syntax extension. http://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html...

You thought right. Ocaml is an impure functional language.

Abelson and Sussman's _Structure and Interpretation of Computer Programs_. http://mitpress.mit.edu/sicp

Bester is one of my favorite SF writers, and it's almost criminal how few people know about his work. In addition to The Demolished Man and The Stars My Destination (the latter my all-time favorite SF novel), he also wrote probably the best science fiction short story ever written, "Fondly Fahrenheit". Bester was a master of plot, of wordplay, of action, of emotion, and his stories were so exciting you were left out of breath when you got to the end.

Cannot upvote enough.

I would have told them that I had no idea what that was, but then told them what the "Liskov Substitution Principle" (named after Barbara Liskov of MIT) was. I mean seriously, if a company can't spell, do you want to work there? :-)

Better not tell this to Mitt Romney.

Excellent stuff! Thanks, Eli! OP: It's Barzilay, not Barzila.

Note also that this is "Hacker News", so a computer science orientation shouldn't be surprising.

This post is talking about monads in the context of programming languages (specifically the Haskell programming language), NOT in the context of philosophy. The programming-monad concept in turn is derived from the concept of monad in category theory. For more information, google "monad Haskell" or "monad category theory".

Maybe Gilad Bracha's opinions on monads might not matter.

This post/rant would be more persuasive if one got the impression that the author knows more about what he's talking about. One crucial aspect of monads Bracha ignores is that monads have statically-checked types (at least in languages like Haskell) which label what side effects can or (more importantly) cannot happen when a function (and/or monadic action) executes. This prevents impurity (in e.g. the IO monad sense) from breaking out into pure code; pure code that used impure code would have to change its type or wouldn't compile. This is a huge, huge, huge, huge win. It means that you can't "break" purity; pure functions stay pure. In contrast, a function in Erlang (a dynamically-typed functional language which is actor-based) which sends a message cannot be assumed to be a pure function, even in the event that a particular sent message always evokes the exact same reply. This is not to diss Erlang, which is a terrific language in many other ways (nor is it an attempt to diss Newspeak either).

Note also that Scala (a statically-typed language) has an actors library but also AFAIK has some support for monads (Scala experts can elaborate here). If only one concept was necessary in Scala, why have two?

Another point is that monads are used for a great deal more than modeling imperative features in pure languages (though that is a major part of what monads are used for). What about modeling functions-that-can-fail via the Maybe monad, or nondeterministic computations via the list monad, or computations that can raise error conditions via error-handling monads, or...? the list goes on and on. Monads can make any of these kinds of functions much easier to write and to compose. When one programming concept finds so many disparate uses, it's just possible that it's worth looking at closely.

I realize that Bracha is not a fan of static typing (his views on typing i.e. pluggable types have never seemed especially workable to me, but whatever, it's his itch so he can go scratch it), and conversely he is a fan of introspection in ways that are difficult to put into a statically-typed functional language. So I understand why he isn't a Haskell fan, and I have no problem with him pursuing another research direction. But this post smacks of (a) sour grapes that Haskell gets more attention than Newspeak, and (b) lack of understanding as to what monads are all about. Perhaps if he would read some of the tutorials he refers to a little more closely than he has, he would get it.

This is an interesting read. I've gotten a lot of mileage out of learning new and unfamiliar languages (note that "new" rarely means "unfamiliar" since most languages just rehash old concepts). When you have a completely different toolkit to express problems, it forces you to think more, and this makes you into a more flexible programmer. To pursue the game analogy, it's as if learning Go would make you a better chess player. That may be too much of a stretch, but I know of many chess players who have learned Shogi (Japanese chess) to improve their mental flexibility (and also because it's fun; Shogi is an awesome game, better than chess IMO). Back to programming: if you can think about a problem in several different ways (imperative, OO, functional, logic programming) you will have absorbed a lot of "tactics" without realizing it, since every paradigm has its own design patterns. The stuff about good naming conventions etc. is easy. Larger-scale design notions like loose coupling are harder, but when you work in a language like e.g. Haskell where there is no mutable state (except in specially-wrapped subworlds like the IO and ST monads) you get loose coupling forced on you.

I think this is one reason why a book like SICP (http://mitpress.mit.edu/sicp) is so helpful; you have to learn a new language (Scheme) and then learn unfamiliar design patterns applied to larger and larger-scale problems, and along the way you pick up a lot of generally-applicable software engineering knowledge that transcends Scheme.

Another really useful trick is to have to maintain/fix someone else's badly-written code. Nothing teaches good design better than having to fix bad design.

Note, though, that some of what the author calls "tactics" (like loose coupling) actually span the range between tactics and "strategy". Writing pure (referentially-transparent) functions that can't do anything other than transform their inputs deterministically into their outputs is loose coupling on a small scale (tactics). Writing classes which are not highly dependent on specific other classes for their functionality is loose coupling on a large scale (strategy).