Hacker News Reader

Comment by pcwalton | Hacker News Reader

Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.)

I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.

View on HN

"Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming"

Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages.

Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done.

So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)

> I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.

Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant.

Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption.

Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.

In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)

Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it.

Scala "implicits" mean two different things:

1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from.

implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class")

2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance

def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append)

is equivalent to the Haskell

monoidSum :: (Monoid a) => [a] -> a

monoidSum as = foldl' mappend mempty

Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts.

Modular implicits are similar to (and inspired by?) Scala implicit parameters.

If you don't mind reading a paper, there's a paper on it that actually is readable instead of just all whitepapery and overly-theoretical: http://arxiv.org/pdf/1512.01895.pdf

Actually, for me the biggest obstacle is the lack of a good build/dependency tool along the lines of cargo.

The closest I've been able to get is Oasis+OPAM, but it's just not the same.

I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...

Been sampling a bunch of languages in the past 3+ months and I have to say, [| |] is really, really off-putting.

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.

I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible.

I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.

Reply on news.ycombinator.com