Hacker News Reader

Comment by epolanski | Hacker News Reader

I think John Carmack made a good point on this topic which I did not think of before.

He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything.

He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand.

He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.

View on HN

I agree with Carmack's analysis of Lisp but don't think it really applies to OCaml, which I've used professionally.

IMO, OCaml is significantly easier to ramp up on than Haskell. The object model and the fact that the language allows you to ramp up on imperative code let you write working code and the language is feature rich enough you're not generally writing a DSL. Granted, I think it is still harder to ramp up programmers than in JS, Python, Java, or Go.

I think OCaml's biggest problem has been one of timing and value proposition. The language matured to some level of production readiness in the mid 2000s at which point multicore started to become important.

If you wanted extreme performance, OCaml increasingly couldn't compete with C++ or Java. Most shops don't the robustness the superior type system could provide and the other downsides of an unpopular language always loomed large when adoption was being considered.

I still think OCaml or something OCaml-like might become popular with time, but it will require the kind of improvements the multicore project is hinting at providing and more.

I'm certainly no expert, but isn't (linux) kernel C full of pre-processor macros that muddy reading the code?

Those don't apply as heavily to F# and OCaml as heavily though. F# and OCaml are much more practical than Haskell and much more strict than Lisp/Scheme/Racket, and so they sit in a very nice sweet spot of programming language design. The MLs, despite their influence on other languages, are the most overlooked and underused languages.

In F#, even for some DSLs, there's not much funny business at all. You have types and functions. I'm not as familiar with OCaml, but in F#, the only really confusing thing along the lines of DSLs or macros are computation expressions. But for the most part, you don't need them aside from the built-in `async` one.

> F# and OCaml are much more practical than Haskell

For industrial applications in most deployment environments Haskell is a much more practical language than OCaml, due to having many more modern runtime features (green threads, STM, etc., that for many years have made the lack of multicore support in OCaml seem embarrassing). It's not really that that gap has been caught up to now either, OCaml is still many years behind Haskell in basic runtime features.

F# obviously has a practically useful and featureful runtime, but has a scheduler that makes it easy to get thread exhaustion, whereas Haskell has a preemptive one that will make that a non-issue.

I find that the "practical language" argument is usually used by people who have never used either OCaml or Haskell for solving real world problems. In practice OCaml is a did-not-finish versus the comparatively (to most other languages, notably losing to the BEAM languages) excellent finishing time of Haskell.

I was mainly addressing Carmack's points on the "culture" of these languages, but F# is definitely more practical overall than Haskell, in my opinion. Eager by default with optional lazy evaluation, mutability, OOP, functional, pragmatic and huge standard library, easy FFI, CLI tooling, easy to use async and concurrency, and a strong VM that basically runs anywhere and is easy to install all go a long way. I am less familiar with the particulars of OCaml because I have never needed to reach for it over F#, and yes, the longstanding multicore support deficiency was not great.

Also, to elaborate on my reply to Carmack, I think he is grossly underestimating the prevalence of esoteric implementations and DSLs in C, C++, and their ilk.

And yes, Elixir and Erlang, especially Elixir, are very practical languages. I'm hard pressed these days to look any further than F# or Elixir for projects because they effectively cover all bases from soft real-time embedded and up.

I have used both. Ocaml is a joy. I would rather swallow shards of glass than work with Haskell again.

The language is a mess. The compiler is slow. Performance is poor. The community is insufferable.

I think that what is meant by practical.

The community burned me in the end - fortunately a little committee took over my libraries when I left in a rage at some of its truly insufferable vindictive self appointed leaders. I think this comes and goes and the main body of users is tirelessly helpful.

But the rest of this is nonsense. The compiler is a flat out miracle, a monument to human understanding, and produces unbelievably fast programs given the weird and wonderful abstract material one hands to it.

I think golang is designed intentionally to make it easy to read unfamiliar code.

To paraphrase: The idea being that a well designed library api gets you 90% of the benefits of a richer language’s features, but without exactly that penalty that Carmac calls out.

Doesn't that kinda presume that everyone should just "write a well-designed library"? If it's that much easier to just use a richer language shouldn't we just do that?

I don't know what JC said exactly but I would guess that some of the issues of scaling Lisps (dynamic typing, DSL hell) don't really apply to OCaml

There's even a paradox. Lisp like languages aims at not scaling, since you have control over parsing (to an extent) and interpretation (macros). If something requires a lot of hands.. people will compress that into a DSL, and keep the team small.

It does create dialects and potential silo effect. I never worked in real CL projects but books and articles mention to not abuse macros and DSLs because of that, old lispers are also often very educated .. and they rarely do things for trivial reasons. I'm regularly surprised by how well thought out things are.

> He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand.

I don't get it. In C you're programming with structures, data types and functions. In ML and Lisp, you're programming with structures, data types and functions. Lisp lets you muck with syntactic forms so maybe that has some obscuring effect, but I expect most programs are written in fairly direct style. Where people do add abstractions, it's to reuse code so there's ostensibly less code to understand overall.

Reply on news.ycombinator.com