Learn Programming with OCaml | Hacker News Reader

Learn Programming with OCaml

usr.lmf.cnrs.fr

318 pointselvis70139 comments

I believe that an ML should be the First Language for Computer Scientists. It's much less clear which language we should teach people for whom it will likely be their Only Language, today Python is common, and for fields which care about stats often R is used, I've also seen Java used in this role. But for a First Language specifically I am in no doubt that an ML should be chosen, and this is despite the fact that the University where I work has taught Java for decades and Python most recently as First Language.

I'm an old man, I learned the Standard ML of New Jersey when I was an undergraduate many years ago, but I'm pretty sure that experience though it isn't irrelevant, did not overly colour my belief in what we [speaking broadly of humanity] ought to teach.

An ML is great for the theory or abstraction side of programming, but C is also hands down the best language to get a sense of how the computer is running your program.

It’s still an abstraction, but at least being aware of memory management, copying vs referencing, etc are hugely important concepts that ML languages can hide.

> It’s still an abstraction

C is still heavily abstracted. Modern OS evolved in conjunction with C s.t. it behaves like a C runtime simulating a PDP11 (I remember reading a nice article on that). To learn system, what you need is an OS course, not C. I'd say the current C-based stack is in a quite embarrassing state.

Probably thinking of this article: "C Is Not a Low-level Language: Your computer is not a fast PDP-11."

https://queue.acm.org/doi/10.1145/3212477.3212479

Sure, you need an OS course, but that's when students should learn C as well.

I think this PDP-11 meme is quite misleading. There is nothing really in the C programming model specific to the PDP-11 and C was used on systems much weirder than a PDP-11. C is also very successfully the basis of many parallel programs running on multi-processor systems with a memory model in the standard that was created much later than the PDP-11.

Also somehow the implied argument that computing hardware and operating systems simulate a PDP-11 for the sake of C is completely backwards. Historically, there were other approaches, e.g. processors designed for object-oriented programming or actors etc.. All those were not very successful.

It's clear that the authors were either inspired by the PDP-11 ISA and/or designed the language to make porting UNIX from PDP-11 Assm to it easier.

UNIX for PDP-7 in Assm -> UNIX for PDP-11 in Assm -> UNIX for PDP-11 in C

https://news.ycombinator.com/item?id=42644851

and

https://news.ycombinator.com/item?id=43245166

I do not think that pre- and postincrement operator being inspired by PDP-11 has anything to with fundamental system design questions.

> Q. How do you port an OS from one language to a new one, pre-LLM?

A. you reduce impedance mismatch, but making the new language using similar concepts and mechanisms

You're right, this table is just a coincidence, probably derived from the standard math notation, and used in many PLs like FORTRAN and Python ;)

  PDP-11        C
  
  INC R         ++i
  DEC R         --i
  ADD src, dst  dst += src
  SUB src, dst  dst -= src

  (R)+          *p++
  -(R)          *--p
  X(R)          p[x]
  @(R)+         **pp++
  @X(R)         *p[x]

  BR label      goto label  ; near jump
  JMP label     goto label  ; far jump

I do not disagree with the point that some superficial aspects are inspired by the PDP-11, I disagree with that this has anything to do with the fundamentals of computing architecture.

It would also completely contradict the whole idea that everything today simulates the PDP-11 design because of C, as few architectures have this auto-in/decrement addressing modes despite C having native syntax.

You are being somewhat disingenuous with your comment ;-)

PDP-11 was hugely influential in the later designs of various Hardware, Software, OS, Languages etc. See for example; Dave Cheney's What Have We Learned from the PDP-11? - https://dave.cheney.net/2017/12/04/what-have-we-learned-from... The conclusion from the article;

While its development was sometimes chaotic, and not without its flaws, the PDP-11 is at the intersection of many threads of history.

Hardware, software, programming languages, operating systems, have all been influenced by the PDP-11. I wager there is not a single person in this room who cannot trace the lineage of the language they work with, the computer they use, or the operating system it runs, back to the PDP-11.

And that is worth celebrating.

While the PDP-11 instruction set was certainly influential in the design of the "C Abstract Machine" the latter was generalized to accommodate other architectures extent at that time (eg. Honeywell 6000, IBM System/370) with enough flexibility that you can implement a C compiler for almost any architecture you can think of. That is its strength.

David Chisnall's criticisms in his C Is Not a Low-level Language: Your computer is not a fast PDP-11 (https://queue.acm.org/doi/10.1145/3212477.3212479) has to do mainly with the fact that the abstract machine was serial execution with no concept of memory protection/models. But this very flexibility is what makes C easily portable to dinky little MCUs which do not have those features while allowing the programmer to explicitly program those using libraries on more complex processors with lots of parallel cores, mmus etc.

Thus a single thread runs on a "C abstract machine" on a core (i.e. the bare minimum) and it is up to the programmer to manage interactions between the threads on various cores. We have lost nothing but perhaps burdening the programmer with more knowledge of hardware complexity which was an acceptable tradeoff then. Note also that there already exists various extensions to C to handle parallel programming directly eg. "Concurrent C" by Narain Gehani et al. The industry however chose to settle on external libraries and optional thread support in C11 again keeping with its minimality and flexibility mantras.

Note that IMHO there are quite a few things incorrect or misleading in this article.

Do you mean in Cheney's article or Chisnall's article or in my comment?

Chisnall's article. A lot of the general criticism would still apply if you replace "PDP-11" with "von Neumann architecture" which makes the whole thing a bit weird. But also many specific comments about C are bit off (the cost of copying padding, the sequencing, provenance, etc.)

Right. Its catchy title gained it notoriety and then got amplified by human parrots.

However, it is a good article to read and understand low-level multiprocessing issues.

You might find Beyond the PDP-11: Architectural support for a memory-safe C abstract machine by David Chisnall et al. also interesting - https://dl.acm.org/doi/10.1145/2786763.2694367

Yes, I have much less complaints about the content of this paper, except for the PDP-11 meme aspect.

For someone just starting to learn CS, it should not matter whether they're on PDP-11 or x64 or ARM. You can't start teaching with pipelining and speculative branch execution. So C is good choice because there is a simple CPU architecture that it maps to well.

Fully agree. C sits in an almost perfect level of abstraction for students to get a vague sense of how the computer runs code.

Those that don’t need low level details can spend their professional career in languages like python and JavaScript while still have a sense of what lies beneath the abstraction.

For those that do want or need to go deeper, C is an excellent jumping off point into ASM and arch specifics.

C hasn't presented an accurate model of how computers actually work for decades. It's a high level language LARPing as a low level language.

Computers haven't presented an accurate model of how computers actually work for decades. Compare the surface ISA of anything mainstream since the mid 90s versus all of the superscalar and out-of-order execution happening under the hood.

Deliberate efforts to surface this deeper layer back to the programmer-facing ISA (VLIW, notably Itanium) failed spectacularly outside of niche applications. C and its contenders can't simply hop over the CPU abstraction presented to them without having to map backward from some lower-level model to the surface ISA it's forced to target then having the rug pulled every few years due to microarchitectural changes. It has managed to evolve surprisingly gracefully over decades from tiny 16 and 18-bit machines, sometimes segmented, to 32 and 64 bit machines, and even accommodating SIMD reasonably gracefully via intrinsics (which is about the best we can do at present, as CPUs continue to diverge wildly in this area, though I'm begrudgingly impressed by what modern compilers can do via autovectorization to optimize simple loops).

> but C is also hands down the best language to get a sense of how the computer is running your program.

C is in an odd position right now to argue it is how the machine is really working. Computers are more complicated since bigger caches entered the picture. Hell I do not think even ASM is a good approximation on how machine really work given the data dependencies will make stuff being processed in parallel instead of sequentially.

What you could argue is that C is the archetype for an imperative language procedural language with a clean mapping to ASM. That is different than how the machine works. Simpler architecture have less distance between their ASM and what is really hapenning.

> an imperative language procedural language with a clean mapping to ASM

C really isn't as great for this as is often suggested either, not for decades at least

K&R's original compiler on an actual Digital machine from that era makes the case best, but remember this is the era when if you hot loop over modifying a variable your compiler is going to emit memory stores for each iteration - because that's what you wrote, isn't it? No modern C compiler would do this because it's awfully slow.

Likewise that iteration of C doesn't have what you'd recognise as function prototypes, it doesn't care whether your function takes six arguments, here are six arguments the first two are integers, good luck with that. In assembler that makes sense, but you don't do that in modern C either.

C is still a close-to-the-metal language, but it is programming an abstract machine and it is important that the programmer knows that's not really how the machine works, if you want to learn about the machine you will need to write at least assembler and possibly just go learn electronics. Good luck.

> C really isn't as great for this as is often suggested either, not for decades at least

It's good enough for undergraduate teaching. In C, you can easily explain the relation between a struct definition and its layout in memory. It's much more difficult in Caml (what's the relation between an algebraic datatype and its layout in memory?) or Java (which introduces pointers that you never asked for).

We (University of Paris-Cité) are teaching Java in first year, then C and Caml in second year, with seemingly good results.

If the compiler optimizer doesn't reorder the struct fields depending on which flags or pragmas are used, and you could teach that as well in other compiled languages, ignoring the market size of each language.

The C optimizer is not allowed to re-order, so, unless you've specifically used some implementation override you know exactly how C will lay out basic types.

Likewise packing isn't allowed by the standard, so you'd again only need to talk about packing if you want to.

This seems like a reasonable place to start. Like the way driving school teaches you a U-turn but not a J-turn. Is a J turn actually a thing you might need? Maybe, but it's definitely not where we should start.

Well, we cannot talk about ISO C for some things, and Compiler Specific C for others, depending on the convinience of what is being discussed.

The layout rules for C struct are definitely a blessing for teaching I can see that.

> C is in an odd position right now to argue it is how the machine is really working

This is exactly what makes it great for teaching. Students don’t need to know actual arch or hardware details. They just need to grasp the core concepts of what is happening on the hardware.

For that purpose the ideal teaching language is lower level than python, javascript, Ocaml, etc without diving into nitty gritty arch specifics.

C is the undisputed champion in that domain.

> C

Well some procedural language would do the trick.

The main issue is see is people jumping straight into OO or functional programming and developing a habit of over-abstracting everything.

I think something like Odin which is purely procedural but has less historical cruft and offers modern affordances would be a great choice.

C is absolutely worth learning but students will spent a lot of time learning to cope with its sharp corners and subpar standard library. Some might give up before they discover the joys for programming.

Maybe learn Rust as a middle ground between ML and C, then? It has sum types like ML and teaches you memory management like C.

The allure of Rust is that you don’t have to manually manage memory.

Lifetimes are a compiler safety abstraction and mostly unrelated with how the computer runs your program.

Learning a language like C helps to understand why lifetime annotations are needed and how the compiler uses them.

C doesn't provide anything that C++, D, Object Pascal, Ada, Modula-2, Zig, Swift and many others won't do as well.

All great options as well, with the caveat that it’s possible to “ignore” the parts that make C useful as a teaching tool.

Most modern languages have ways to automate parts of memory management, and rightfully so. But you should at least be somewhat aware of what is going on under the hood.

Some of the suggested languages are as old as C, with better ergonomics if you mean ignorig is doing string concatenation instead of manually handling char buffers with pointer arithmetic, or proper reference parameters instead of being forced to pass the address of output variables manually, which is nonetheless possible in the suggested languages.

What low level thing do you think C can do, but Modula-2, Ada or Object Pascal are unable to provide the comparable feature?

Also taking into account possible C extensions not covered by ISO.

C lacks just enough “modern language features”, by design, that students are forced to be vaguely aware of memory layout, memory management, ref vs copy, shallow copy vs deep copy, maybe even calling convention, etc.

It’s also popular enough that there is an abundance of high quality learning resources for beginners.

No other language threads that needle as well as C.

Provided examples from 1978 and 1983 languages do that just as well, unless you mean by 1978, C design was too primitive, or even when compared with languages like PL/I and NEWP from 1966 and 1961 respectively, which then I fully agree with.

Maybe we were led into a false dichotomy by the title. If someone wants to learn programming for other reasons than as a mean to a goal - which will become more and more rare because LLMs do that already - this person must not learn just one language but one per major paradigm : C (imperative/procedural), Smalltalk (OOP), Prolog (logic), SQL (declarative, although maybe there are better representatives), OCaml (functional, although one can go for Haskell or Lisp/Scheme), and Forth (concatenative, but also to take a look under the hood of interpreters/compilers/VMs).

To get a sense of how the computer runs your program you need to learn some modern assembly language, i.e. either Intel/AMD x86-64 or Arm Aarch64, or for something simpler one could start with IBM POWER.

The hardware machine model used by the C programming language is completely obsolete and very different from how modern CPUs work. Even for abstracting PDP-11 it had defects and omissions.

The fact that C is indeed more transparent than many other more abstract programming languages does not make it good enough for understanding how the CPU runs your program. Believing that the CPU works within the straitjacket of the C language is dangerous, because much more than half of the instructions of a modern CPU cannot be directly expressed in C (though a good optimizing compiler can sometimes infer when such instructions can be used), and the C language does not even have the data types that are used by many hardware instructions.

The relationship between the C language and how a computer runs a program is exactly the opposite of what the previous comment says.

For someone who knows how a CPU runs a program, it will be easier to understand how a C program is run than how a program in another language is run, because for the latter there may be very different runtime library implementations, whose behavior cannot be guessed by looking at a source program, without having supplementary documentation about the compiler or interpreter that is used.

On the other hand if someone knows only the C programming language, their mental image about how the program is executed is likely to be very wrong for any non-trivial program.

For learning an assembly language, the prior knowledge of C is more a handicap than something helpful, by creating bad habits, like using incorrect implicit conversions, inappropriate integer data types, not caring about interactions with the cache memory or memory access ordering, choosing between alternative expressions those that are more inefficient in hardware (e.g. in many modern CPUs accessing data through indices is more efficient than through pointers, but a lot of legacy C programs use pointers to access arrays, under the wrong assumption that this is more efficient), etc.

I agree with the top poster that languages from the ML family are a very good choice for a first-learned programming language.

For a programming language to be known before any assembly language, I believe that even Fortran is much more appropriate than C, because it is much less misleading about how a modern CPU works, and I say this despite the fact that for decades I have been writing programs in the C language, for embedded computers (but before learning the first assembly languages I had experience mostly in Fortran, and to a lesser extent in LISP and COBOL).

For a few years starting with 1990, I liked C very much, because with the Microsoft and Borland C compilers for IBM PC it was a great improvement over the Pascal, Fortran or Basic to which I had access previously, but today, 36 years later, I do not think that there exists any application for which learning or using C makes sense, despite the fact that we will remain stuck with it in many places for many more decades in the future.

Even the ancient Fortran remains more useful than C today, because for many computational applications most modern programming languages are crippled in comparison with it, by poor support for array operations, while C does not have any intrinsic advantage over alternative programming languages. A "C" done in the right way is "D", so it would be better for learning, though it still inherits from C some questionable features, which would not exist in a clean design.

You really need to grok C and understand Lisp. Learning just these two well, will give you most of the foundation you're ever gonna need. Nearly every other PL is a bunch of accretions on top of one of these; sometimes those accretions are great improvements, and more often than you'd think - they are downgrades.

Lisp can teach you everything about what logically a program is, how computation itself can be expressed - code as data, recursion, and abstraction built from almost nothing, and C can teach you what a program physically is - memory, pointers, and how the machine actually runs it.

I have gone through over a dozen of different PLs, each time thinking that my skillset was improving but I still sucked at it, and just needed to learn yet another language to truly get better at programming. Turns out, I just needed to grok Lisp.

Don't be like me, don't waste your lives wandering around, following a map everyone's holding. Majority not only can be wrong, but as history teaches us - it is wrong most of the time. Instead, follow those few that are looking for shortcuts. They may not have most popular opinions, but they might be on the right path after all.

> I believe that an ML should be the First Language for Computer Scientists.

I'm not sure how much influence a First Language has - the biggest impact might be whether someone decides to continue learning to program. I'd also worry that we might lose something if all computer scientists are too similar. There are lisp believers, and there are those who swear by C; and I think the field of CS would be less rich if either were missing. Given that, it's a good thing that there are a variety of languages taught as first languages, and I'd like to see the variety widen (I don't know of any CS degree which begins by teaching Forth).

The best programming course I had in college was one on comparative programming languages (and not just 'cause I was the only student who was able to do all of the Lisp exercises solo) --- it was quite striking getting an overview of the history of computer science and to see the myriad approaches which had been used.

Tangentially, a great interview with the creator of OCaml, Xavier Leroy [1].

[1] https://www.youtube.com/watch?v=9Cswiqrq6So

The entire series of interviews with various language designers by Ryan Peterman is really great and a highly recommended watch.

It gives an insight into how they thought/think and what we can learn from them.

While watching the series i was stuck by the fact that they often only focused/reiterated the conceptual basics and building on top of them in a step-by-step manner. Whereas if you watch interviews with programmers (even famous ones) you will often see a lot of fancy talk about the complicated features of the language etc.

I believe "Experts" have a way of modeling domain knowledge in their mind in such a way that they intuitively know what is the "wheat" and what is the "chaff". This is what we need to learn. Scheme can do a lot with a minimal language and so can C++ on the other end of the spectrum. So then what constitutes "Programming"? It is simply an expression of Intent via syntax supporting abstraction of state/behaviour.

This is the best OCaml resource I know, and I have gone through it in full, and highly recommend:

CS3110: OCaml Programming: Correct + Efficient + Beautiful [0]

It is one of the best programming resources that I know of.

[0]: https://cs3110.github.io/textbook/cover.html

This book is a great.

A common misunderstanding around OCaml is to classify it as a functional programming language, it is actually a multi-paradigm language. In short, in OCaml, you can write in any paradigm you want, imperative, object, or functional.

Typically, I write in a mix of OCaml and stubs in C (for bindings to Linux libraries), for everything, to replace shell scripts, Python scripts, Javascript/Typescript, but also for big applications (I wrote a clone of Emacs in OCaml, a long time ago, before writing MLdonkey).

Once you have started using it, it does not replace your main programming languages, it replaces all the languages you needed...

A good comment to motivate myself to learn the language; particularly the last line ;-)

I personally detest the babel of languages involved in "modern ways of programming" and have settled on C/C++ for everything since they are available everywhere. The only other languages i am willing to seriously consider adding to my repertoire are Erlang (functional/concurrent/distributed/fault-tolerant/hot-reload) and Prolog (knowledge representation and derivation using predicate logic) along with a formal verification language like Lean4/TLA+ etc. due to LLMs usage.

I do really wonder what it would be like to learn to program for the first time with OCaml.

I remember learning to use OCaml in a properly functional way after so long writing code in C and it was really miserably painful trying to change how I thought about algorithms. I eventually got over the hill and it changed how I write code in C (for the better?), but I do wonder if it would have been easier to have learned OCaml as a first language instead.

I did so! (quirks of the path I took in the French educational system)

I went through a book similar to the one above, with no internet connection. The first few weeks were rough: I did not quite know what a type was and the compiler error messages were unforgiving and hard to understand without that context. But, once I grokked the core ideas (a proper idea of what could be done with recursion took much longer), things went surprisingly smooth. I definitely credit it with making me a better programmer.

How old were you?

I started programming at 18 right after highschool (which, I guess, is late by HN standards: a number of my peers had played with Python first and hated Ocaml).

When I first learned to program at university we were taught Haskell. That was 15 years ago and I've not really programmed anything in Haskell since, instead I've racked up years coding professionally in pretty much all the major imperative languages.

I'm aware of why Haskell is not practical as a production language for most companies, but I have to say I've never really coded in anything else that feels as "neat" and it's a shame. Every other language feels like it has some idiosyncratic scaffolding one has to learn, reminding you that you're constrained by how computer hardware works, rather than just expressing an algorithm in terms of inputs and outputs.

I would say it has made me a better coder, I've still kept a preference for keeping data immutable, copyable and abstracting complexity into easily testable functions over classes with unobservable mutable state.

It's a good language to learn programming. Very simple semantics. But ultimately, you need to learn different paradigms, I think the order doesn't matter, they'll still be an element of surprise.

Also OCaml lets you write imperative code if you wish so. So you can learn the different paradigms within the same language.

Being a functional programmer in a group of imperative programmers is miserable

Ooooh, the memories...

Caml was how I was taught computer science in prépa and first few years of engineering school, a mere 25 years ago.

(Ok, I had done bits of BASIC before, but I had time to recover.)

To be honest, the learning path was

1. Lots of maths. Then add some more.

2. Algos in pseudo code. (In "French", pseudo code, of course, because, why not ?)

3. Caml as "executable pseudo code". With all the warnings and a hints of disgust as the use of mutation and side effect. (And of course ":=" his completely different from "=", what are we, beasts ?)

4. Lots of exams where you have to write properly indented programs on paper on the first try to submit all sorts of recursive trees to all sorts of horrendous manipulations - and you can imagine the grader doing the mother of all code reviews

5. Re do that again in engineering school, because a third of the class had done zero computer science, and the other third had learn in Pascal

6. Then learn C and assembler, and get your mind blown in the exact opposite direction

7. See your teachers reluctantly say that "you should just learn java", because "that's what used in the industry", and "no one will ever get a job writing caml anyway"

...

25 years later : yup, some people managed to get jobs writing a dialect of caml for this small startup in a garage serving cat pictures and racist memes to billions of people

26 years later: "you should just learn to prompt LLMs anyway", because "that's what the industry needs, and no one will get a job programming any more"

Drawing cardioids in maple V while I had darkbasic pro at home and could write my own games and delve into quaternions since 3eme. :x

No wonder I failed this sht, kind of.

Yup, I did not mention the classmates who were already fluent in c++ at 15 and were not that kind of pretending "loops" were mathematical wonder :D

This book, while excellent otherwise, is much too harder for beginners, IMO. The pace is too brisk, and it's far from pedagogically useful if you don't already know how to program.

Yeah, I don’t think it assumes zero knowledge, which is what I’d expect from a “first programming language” book.

But it does say it’s targeted more for an “algorithms” course in the introduction.

As a side note, I think a REPL is the best environment for learning to program for absolute beginners. You get instant feedback and can focus entirely on just short snippets of real code, without having to worry about compilers, build systems, and “the OS” as a whole. Especially if it comes with a GUI wrapper, you can skip the terminal entirely.

Indeed--so the title is somewhat misleading.

Agree with you wrt to REPL, though sooner or later the programmer-wanna-be has to embrace technical sophistication. :)

OCaml programmers, what learning resource would you recommend starting out with? I know there's https://cs3110.github.io/textbook/chapters/basics/intro.html. How does this book compare? Anything else you would recommend?

What is the recommended GUI framework for OCaml? (Please don't say HTML)

Camlkit-gui for macOS

Anything for Linux? Or cross-platform?

I looked for Qt bindings but they appeared to be abandoned last time I checked.

I see that unison (file sync tool) seems to use: https://garrigue.github.io/lablgtk/

For Linux UI.

But that uses Gtk 3. Gtk 4 is already more than 5 years old ...

5 years is no age for an UI kit! ;-)

GTK4 bindings https://github.com/chris-armstrong/ocgtk

What language and framework do you use for GUI programming?

https://github.com/sanette/bogue

> Learn Programming with OCaml

Lately, I keep asking myself, do I need to learn this new thing, should I force myself to learn this thing, LLMs know it anyways and so on.

So (asking genuinely), should we learn these things?

Should you learn history if it is already written in a book? Should you live if others are already living?

For most people, history is trivia.

If you ignore history everything is perfect, or at least a controlled slight deviation.

You can also learn for your own amusement, and solely for the fun of comprehension; a lot of mathematician were driven by this. It's a shame current social value places so much utilitariaism on learning.

This ^

This. The question can be seen like “should I learn to solve sodoku, if a computer can do it better?”

As always, it is good to be aware that many people are too anxious about more existential issues to comfortably an consistently expend effort on intellectually-taxing tasks that aren't perceived as directly related to their survival. If it's an issue with social values, it's less of one related to learning as it is to perpetuating artificial scarcity.

>to comfortably an consistently expend effort on intellectually-taxing tasks that aren't perceived as directly related to their survival.

the average person spends 6(!) hours a day on their smartphone, the average TikTok user spends 100 minutes on the app alone. This isn't about artificial scarcity, it's about the average person looking like the Wall-E people

Escapism and making a concentrated effort on something are two different things. Yes it would probably be good if you could flip a switch and use the small windows of time we look at our phone per day to study OCaml, but it's not really realistic..

People who are asking these questions are saying "will me spending my time learning OCaml help me land that job that pays six figures and has health insurance so I can not rot away living on the margin". They aren't saying "I only do things that will make me money".

>use the small windows of time we look at our phone

again, it's not a small window. It's six hours. That's almost half your waking day. People spend virtually their entire leisure time rotting away on low quality entertainment.

>will me spending my time learning OCaml help me land that job

that's a pointless question for one you never know if something will land you a job, new opportunities don't open up before you do something, secondly the relevant question is, should I stop doing X and start learning Ocaml, or Chinese, or take a welding class because all of that even if it doesn't work out beats scrolling through Instagram.

I don't even take offense with the idea that you engage in activity that makes you money, because pure selfishness on that front would be an improvement to what most people are doing now.

“Low quality entertainment” is a very elitist thing to say. Most don’t have time or luxury of even being introduced ( via an east coast liberal arts college ) to read Tolstoy or appreciate the finer motions of Tchaikovsky. Instead the Druski memes will do just fine, mixed in with the AI slop. Or maybe they’re physically or physiologically incapable of enjoying the outdoors or sport. Point is, my gen played strategy games and first person shooters and listened to Eminem, this one marls TikToks until their thumbs have RSI.

As for OCAML vs not, I think the vast majority of even intellectual and studious people would be better served trying to AI max and build some kind of agent serving businesses than trying to get a job at, uhh, Jane Street. 1% of the best engineers in the world get to work in that language, so yeah the parent makes a valid point

Many of the classics were very popular and got their label later. Classics and pop culture are not necessarily at odds.

Even if those statistics are correct, I do think you're ignoring that smartphone apps are specifically engineered to be low-friction and highly-addictive, and pushed specifically to the people who are anxious about spending money on other pursuits (free time often being necessary but insufficient), as they contend with the artificial scarcity (which this is absolutely about) of affordable housing, affordable food, affordable transportation, affordable guided education, etc.

I like baking. There are machines that can bake bread at an industrial scale that I cannot compete with. There are home kneaders that do much of the work very well. I use one of those more often than not.

I still think it worth my time kneading dough by hand. It teaches me the various properties of flour, how external factors like humidity or temperature impact the overall process, and I believe that it makes me a better baker, even when I use a machine, because I am better at controlling what the machine does. When I get a new brand of flour I will make sure to bake everything by hand first to "get a feel".

Kneading by hand is also very relaxing to me. This is probably the main reason I bake in the first place.

Programming, and other activities are not very different. We now have machines that can do it faster, at a fraction of the quality many people deem good enough. If you hate coding, that is probably all you need to use, and learning a new language might just be a frustrating experience not worth subjecting yourself to. But if you enjoy coding then it should make you better at it, even when you use the machines.

My experience with OCaml has transformed how I think about programming and complex system design. This may also be true if you learn any other functional programming language, but OCaml is easy and flexible which makes it good imo as a door towards the more formal part of comp sci. Even for steering an LLM I think this might help.

My experience with lisp was exactly that: it completely changed how I think about programming, but much more, how I think about systems and engineering. (I learned it through SICP)

Why learn an instrument when you can just press play?

Cultural inertia: until recently, you couldn't just press play and get even a wide selection of music: for most of history, if you wanted music, you had to make it or hire someone to do it for you.

More recently, you had to go to the store and buy it, which meant you didn't have much variety.

Today, learning an instrument is for social status, inheriting the shine of the past, where music was rare and costly. The reason to learn an instrument today is because the former situation was romanticized.

It'll probably take a generation before people ease into guilt-free enjoying infinite, fully generated music.

your body needs exercise or you end up an obese couch potato. Your mind is similar: it needs exercise or you end up a dunce.

These theories sound vaguely plausible.

I would rate them as about 5% true and 95% false, as explanation of the past and prediction of the future.

The satisfaction of learning to do something difficult isn't going away, and the social status associated with it won't either.

Sure, I guess. But today, something like 30% of people play music or sing regularly enough to say they do it (ie, not very much at all). Even a couple of generations ago, it was much higher. It's not going to die out, but I think a lot of people are asking themselves if they want to bother.

> The reason to learn an instrument today is because the former situation was romanticized.

Lol. The reason to learn an instrument is because it is directly pleasurable to play an instrument. You've got consumer/spectator brain.

I mean, why post a comment when you could have just read a comment?

Why does anyone have any hobbies?

What the hell else do you have to do?!

You could have asked this question 10 years ago, long before llms. It's not like you'd realistically would get an ocaml job back then when there's so few of them, so why bother?

The answer is still the same as well, people learn ocaml either because they enjoy it, or because learning a functional language makes them a better programmer overall and teaches your brain to approach a problem in a different way.

Seeing that you already know programming, I'd say it'd be less risky for you. But the only reason you're able to pilot an LLM to do programming for you, is because you understand programming and architecture.

But what about the future generations skipping the step of learning the OCaml's, the C's, the Python's...? It's quite concerning.

Oh by the way, yes. Learn OCaml!

Outsourcing all the thinking to machines may have consequences you might not like.

An oblique explanation: https://croissanthology.com/earring

I mean if you want to let llms do everything for you go ahead. Wall-e implications aside, it seems like a great self centric life.

Michael Clarkson teaches OCaml at Cornell. I highly recommend his free course materials [1]. He’s an excellent educator. Learning functional programming paradigms had a major influence on how I design programs. Clarkson also taught snippets from the Pragmatic Programmer, which was equally influential (as it has been for many many others) [2].

[1] https://www.cs.cornell.edu/courses/cs3110/2025sp/

[2] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...

I would sharpen my software engineering skills rather than coding / programming skills.

LLMs know it anyways?

Hhhmmmmm

LLM + static types is a winning combo. And if you want to be serious with what you do with your LLM, you need to understand the output to some extent.

That being said, you may as well use Rust. The extra complexity of manual memory management and Rust idiosyncracies are easily dealt with by the LLM.

Posting 'why should we learn' a programming language on Hacker News is top-quality ragebait :-D

you are eventually going to have a very bad time if you do not have a solid mental model of the code the LLM is writing, and indeed if you cannot steer the LLM so that its code conforms to your mental models. learning ocaml is a great way to add some valuable tools to your toolkit when it comes to thinking about code and how it fits together.

LLMs are better at OCaml than any other language, and being able to read and think in OCaml is very helpful to understanding LLM generated OCaml code.

Also, it may very well be the decade of formal verification - if so, OCaml is a good place to be.

I would not make that dependent on LLMs. If OCaml covers a use case you have, why not.

Personally I try to stick within my own niche though - ruby, java and also python (ruby is unfortunately losing grounds really hard now, the writing was on the well in the last some years though, and people such as DHH are now indeed a liability rather than an asset to be had, but that's a side topic).

I think what LLMs will force in the long run is to make programming languages used by real humans in a traditional way, more effective. That is, writing code by humans will have to become a lot more efficient, both time-wise and speed-wise. And for that there is always a use case IMO since LLMs are, despite the promo, incredibly stupid.

I think it's helpful to have a deep understanding of one c-type language, one lisp, and one ML-type language. There are so many things influenced by these three language families that being comfortable with them makes it so much easier to understand a wide variety of languages and libraries.

Yes. LLMs do not know anything, and they will make mistakes as a result. You have to be able to check their work if you wish to do a good job.

This isn’t really true for many programming tasks anymore. And as the saying goes, “this is the worse they will ever be”.

> “this is the worse they will ever be”

This is assuming that the current state of LLMs is sustainable, which it definitely isn’t.

Keep using your brain or you will forget stuff. Doing puzzles is great, programming in new languages is also great.

> So (asking genuinely), should we learn these things?

I wanted to learn a functional programming language with powerful type capabilities and I chose the Lean Language for that and not OCamel or Haskell. Reason being: Better type system (dependent types!), applicable in formal domains and can use it to learn math too.

For your bread and butter programming, there is already JS/Go anyways.

So don't see much point in learning OCamel.

This mindset (i.e. LLMs are available so why do i need to learn anything?) is highly insidious and will destroy your brain/mind/future if you let it.

Humans are the ones who Understand, while LLMs only Know.

So inter-disciplinary/cross-disciplinary insights, new modes of thinking/reasoning, flashes of insight etc. are still in the purview of Humans only. AI/LLMs can help focus and short-circuit the study of various subjects but their understanding can only happen within a human "Mind". If you do not even have basic domain knowledge (i.e. unknown unknowns) how can you even prompt/query an LLM for answers?

A few illustrative examples; a) Newton came up with limits/calculus out of a need to measure continuous motion with varying speeds b) Kekule came up with the benzene ring from a dream where he saw a snake grab its own tail c) Descartes came up with the cartesian coordinates in an attempt to solve geometry via algebra etc. Each of these was a novel leap of insight bringing together various concepts to create entirely new knowledge domains.

So one should learn/study the core concepts/ideas in various domains and then push the tedious mechanical labour onto the machines. In this regard see also the concept of "Active Learning" - https://en.wikipedia.org/wiki/Active_learning

Should I continue to walk, when technology can move me from place to place?

https://tenor.com/view/tf2-wall-e-team-fortress-2-autobalanc...

I know a few programs written in OCaml such as weidu.

OCaml is a very strange programming language. I don't think it will be able to sustain e. g. success stories of other languages, such as python.

Ocaml is ancient at this point. It's never going to be python, but I doubt it's going to disappear.

The French original version of the book appears to be 12 years old (2014). Is the English translation linked here a somehow more up to date book?

Why is the PDF smaller than the Epub file?

Probably vector-drawn diagrams are rendered into bitmap images for the EPUB version.

The ePub contains both SVGs and PNGs, the latter of which doesn't compress all that well for "plain zip", which an ePub is.

The PDF on the other hand gets to use zlib for streaming all the objects. It gets half decent compression.

OCaml is the LLM secret weapon right now. They are better at writing it than they are any other language.* That’s all I have to say about it.

* Other “pure” hindley-milner languages are tied but among them ocaml has some particular strengths that I’m sure others will discuss.

Two genuine questions. (1) Why not Rust? (2) Why not Haskell?

(I have my own answers, but I'd love to hear yours, too.)

(1) complexity

(2) performance

Both force the model to reason about types too much. The more constrained type system plus global inference merely holds them to what they already wrote, with very fast feedback.

Rust is fine if you need it but most things don’t and ocaml has more convenient abstractions for “regular” work. If you need rust you need rust but ocaml isn’t that far off in perf.

Haskell type system is too expressive, it itself becomes a place for the agent to make mistakes and get bogged down.

1. Compile times. OCaml compiles very quickly (think Go) and this gives you a fast feedback loop. It lets the LLM rip through the implementation.

2. OCaml has an idiomatic approach of using interface files for all modules that can be accessed outside their libraries, and interface files give LLMs a great précis of exactly what is wanted. They then just have to follow the types and fill in the blanks to get the implementation. It's nearly the perfect use case.

Flamebait aside, has this been studied for real ? Curious how you would rate that...

Yes I contributed code to a paper on it this spring. It’s hard to measure and “studying” it just means feeding money into frontier models. If anyone has a few billion tokens for a couple masters students hmu so they can get it published.

I'd be very interested to read this paper when it comes out.

I will add you to the list, I’ll definitely post it on HN also.

They had originally planned on june and my part is in so…. Me too.

I'm interested too - besides the paper, is it your personal experience that working with llms on ocaml is superior to other languages? I thought with the sheer amount of training data languages like python and java would be "ideal"

No it’s more about speed and quality of the feedback loop. So you want the compiler that catches the most stuff when given the least information.

Can it not be studied with open weight models? This is a genuinely curious question, not an attempt at scoring a point.

I don’t know it’s not my paper. I don’t want to talk shit but I’m also a little confused at this apparent limitation.

Did you also compare F#?

Couldn't agree more. Even when the models could barely write it, the compiler was so good

For web frontend, it's derivative programming language, rescript, is also a secret weapon because of types, fast compilation times and first class support of React. Using React in rescript is much nicer than TypeScript.

The standard library could be better, though.

Don't learn programming with OCaml, it's horrible.

Reply on news.ycombinator.com