OCaml is 25
discuss.ocaml.org
discuss.ocaml.org
To be clear, I’m in favor of these changes, and I don’t denigrate any existing language for not having them, I just still marvel seeing HN headlines like “Python to get match statement”, “Record Types in Java”, “Tail Call support in Rust” and appreciate all the more the things OCaml (and before it, ML) have gotten right for so long.
As CPU and RAM increases you can make smarter compilers and generalize things like type inference, bigger compilation units and higher level constructs that rely heavily on compiler optimization for good performance.
Many people think that Rust and C++ are too slow to compile today, imagine what it would've looked like on a Pentium II CPU with 128MiB of RAM!
Rust made design choices even beyond the complexity of LLVM that make its compiles slow.
Also, people have been complaining about C++ compile time for as long as I can remember, so I don't think it necessarily invalidates my point.
Edit, should include that the experience in 2002 was on a corporate project which ultimately had many millions of lines of code, so not just some crazy guy in a basement. Lots of crazy people were in the basement with me.
On MS-DOS Borland C++ 2.0 was the first compiler to support them.
Naturally this was work in progress, try to keep up with the latest stand from WG 21.
https://docs.microsoft.com/en-us/cpp/atl/active-template-lib...
In 2000 it was version 3.0 alongside Visual C++ 6.0.
Excuse me?
25 years ago on was on the Adobe Photoshop team, happily programming in C++. We had templates, smart pointers, and the STL.
And the people at Taligent were all about C++, around the same timeframe.
Yes! Ocaml was my first programming language and I have been baffled at how languages I learned subsequently tended to miss what I considered basic utilities like proper pattern matching and tail calls (happily those ideas are now finally entering the mainstream).
lmao what. how. like what course of events....
I had several years professional experience, including functional programming, and still found it pretty rough going for a while. And even other professionals have often not even heard of it.
What there is is usually for a specific course, or is published by like Jane Street or some shit and highly domain-specific as well. I just found it hard to dig myself out when I ran into trouble.
I definitely agree about the FP concepts being no more difficult or even simpler to learn. I used to teach introductory programming to adults and at first we taught loops then map/filter etc and told students to use their preference.
Almost universally they used map, including complete synthesis of the entire concept of iteration without loops. Like when presented with a loop, I once saw a student skim the internal logic, see that it was doing an array push inside an if, and call it "a filter loop." To him the filter was the concept and the loop the tool, which is I think backwards from a lot of us.
Interestingly, it was the students with previous programming experience who had the most difficulties learning the language. I have not found the reverse to be true, the Ocaml compiler is very strict, but it makes you attentive to details and types in a way that transfers well to other languages.
The class hated it/him. Type errors were nothing short of terrifying. `function has type (a->(b->c)->(b->d)) but should have type (a->b->(c->b)->d)` or such. If you passed the class (a big if), you'd move on to C++ and OOP and never see Ocaml/functional again.
I appreciated it for providing me so much understanding wrt mathematical thinking - functional programming, recursion, induction. Later on I took some classes/researching using SML.
Fast-forward ~12 years and I get into web dev and what I see functional programming trending!? Kinda funny... I want to get into it somehow, probably Clojure this time. It just resonates with my thinking - maybe a product of being primed for it all those years ago.
https://devblogs.microsoft.com/cppblog/finding-bugs-with-add...
https://devblogs.microsoft.com/cppblog/static-analysis-fixes...
https://devblogs.microsoft.com/cppblog/address-sanitizer-for...
https://docs.microsoft.com/en-us/cpp/c-runtime-library/sal-a...
https://developers.redhat.com/blog/2021/01/28/static-analysi...
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....
There are exceptions like Python and Ruby, but I think the "default" is that a given language is not popular, and there have been almost no platforms written in functional languages. (anticipating the objection: Lisp isn't functional :) )
There are very large first-mover advantages and network effects to programming languages. Programmers want to learn languages existing code is written in; companies want to use languages that lots of programmers already know. Languages that get big for historical reasons tend to stay that way.
Mainstream adoption wasn't the main goal for a lot of functional languages when they were created: the aim was to develop ideas of how programming could be better. The surprising thing, really, is that people write real production in some of these languages, despite how different they are from what most programmers already know. We shouldn't be treating not getting as big as Java as some sort of failure.
Overall, though, functional languages see progression today, they may not have an exponential growth, but neither did Python, and look where it is now.
[1] https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...
It’s an interesting example of the Blub paradox [0] as well (Paul Graham’s answer to a similar question, “why doesn’t everyone use Lisp”)
Do you have others in mind? I'm sure we can find fairly similar circumstances for most of them.
Then POSIX still left too room for each UNIX flavour to decide how to actually implement certain features, e.g. signal.
So Java, despite being initially interpreted felt like how portable code should be, coupled with a rich library.
Isn't this what people refer as marketing? Other languages were garbage collected before Java. Common Lisp and SML both existed a decade before Java. There was also Smalltalk and Eiffel, but for them I've heard that Java being free really helped (which may be called marketing or not, but is still related to Sun money in a way).
- crowd maturity (zero dev cared about safety in the web 2 era, cue wordpress cheese, people flocked to php or ruby because it was fun and easy, only later people started to make solid specs for their languages)
- business-less ethos (I'd bet $10 FP dudes have zero desire nor skills to promote and sell their work)
- culture shock (fp is somehow very rooted in math culture, how many times in the last 20 years did someone at a meeting or an OO class said "explictVerboseVariableNamePlease" ? compare that to
fold f z [] = z
fold f z [h:t] = fold f (f z h) t
add various degrees of second degree effects like the fact that complex and hard to sell things don't attract funding, unlike wordpress you get less exposure. Maybe for the best because mainstream business interest would surely distort the original paradigm quest to fit whatever money-heavy requirement lands on someone's desk that day
A long variable name only makes sense when the variable is specific. In fold, you have “a function”; nothing else can be said about it. And since working with “a function” is very common, Haskell programmers have converged on a shorthand for it: f. Sure, it’s harder for an entirely new programmer to understand, but every language has practices like this that need to be learned: take “i” in a for-loop in C.
If the French government had realised what they had in OCaml and made it the standard programming language in all of France they would be a software powerhouse by now.
Happy birthday !
They are, or were, capable of serious technical advances, such as Le Minitel being way ahead of its time.
With imperative code, you can just spell out a for loop which makes intuitive sense. With functional code, you need to do so recursively, so you need at least some understanding of recursion, and perhaps even category theory for more complex examples or languages like Haskell.
Just that kind of complexity over an imperative language alone is why I surmise that functional languages haven't reached as much popularity.
Which is simpler:
for (int i = 0; i < n; i++) array[i]++;
map (+ 1) list
The functional approach allows you to only care about the what ("add 1 to each element of the list") instead of the how ("create a number that goes from 0 to the size of the list minus one (because our language is 0-indexed, because arrays are in fact directly related to how memory is laid out), then for each value of this number, take the value that's at this index in the array and increment it").
I'd argue that the functional approach is easier to learn, especially if you haven't had prior experience with programming. You also said earlier than functional is harder to learn because you have to use recursion to make for loop. That's not really true, you can just use functions like map which are already here. And when you start tackling recursive data structures like trees, recursion is easier to understand.
It's not exactly a struggle to get Base or Core working, but it's way less streamlined than it really ought to be. I see things like F# picking up some popularity and it strikes me as a bit of a tragedy on Ocaml's part. .NET is pretty bad to work with, imo. I know C# people will hate that, and indeed if I was meaning C# then they'd be right to feel that way. The fact is, there are few FP languages with a deep platform (like JVM, .NET, js/browser) already, and even fewer pleasant enough to work with on a daily basis.
I've been blessed to use Ocaml for some of my statistics work, and I'm watching very close the OWL project (ocaml.xyz), and hopefully it will come together nicely.
Still, I see the quickstart process of F#, Scala, Clojure, Elixir, even Haskell, and it's just much less headache than Ocaml for the first 10-15 minutes.
Ultimately, I don't know. I use Python a LOT, and I REALLY enjoy it. A lot of what people don't like about Python just doesn't get in my way that much. Really the only thing that I could see myself yearning for in the language is pattern-matching (which we're getting soon) and some form of piping with better lambda support. I really miss |>, <| in the way I build my tools, but in the end I get along just fine.
I'm glad that SO many languages have taken inspiration from Ocaml, and I'm sure that as time goes on, many more still will draw water from the plentiful well of its beautiful type inference, compiler architecture, domain modeling capabilities without annotations, et al.
Finally, I think it remiss to sorta colloquialize projects by a sum of their most recent decisions. It's not difficult to look around and go "Man, ReScript is sort of a shit-show, ReasonML doesn't really offer anything except different syntax at this point, and there's typescript anyhow, which has a vastly superior dev experience in just about every modern code editor." But that doesn't do justice to how incredibly epic it is that a project is still alive and competitive at a deep, academic level, across continents, for 25 years. I could munge around my emails and find projects starting near me that are using things like Coq (now called something else, I think), it's very much still alive for important technical work even throughout the Numpy-pocalypse.
Anyhow, this comment is a mess. Congratulations Ocaml team. Keep on truckin'. <3
Coincidentally I’ve been writing up an OCamlbyexample page that hopefully I can post here at some point to motivate people to learn the language:)
I guess it depends on exactly what you're trying to do, but we've developed a large amount of complex software in OCaml this way.
Rarely are people arguing that a situation like this makes writing software impossible. The question is whether it adds friction, and in adding friction impedes adoption. I think it clearly does, and that tooling is one of the highest-impact features a language can prioritize to improve adoption. If the story for building and packaging OCaml software is "go make yourself proficient in the C build tooling ecosystem first," of course that makes it harder to adopt (and you're not the first person in the community to give this answer, either). This hostility to beginners is one of the major things that irks me about the OCaml community, and OCaml is probably my favorite language.
When i was a beginner, trying a new language was actually easier: you just installed a compiler. Now you need a "platform", for some even a special dedicated machine.
I wonder who is benefiting this sillo-ing, but I doubt that's the beginners.
>I wonder who is benefiting this sillo-ing, but I doubt that's the beginners.
Everyone benefits from the better tooling we have now. The siloing is a problem that still has not seen a satisfactory solution. Regression in user experience is not acceptable.
Being part of a "language community" is not the only way to be a programmer. Not knowing your way outside of the opinionated built tool black box is indeed quite frankly the hallmark of being a beginner, if not a tech illiterate, in my book.
When I originally asked what was the point of Dune, the answer I received from the people pushing that project at that time was that I shouldn't worry, it was just a tool to speed up getting a workable workflow when teaching 1st grade students. It made sense then, I though at some point beginners would naturally outgrow that walking aid. But look at what happened instead!
Mind you, today's experience with ocamlc/ocamlopt for the seasoned programmer is not unchanged either. Because of that new "community first" principle, all the tools tend to work only withing the ecosystem at the expense of cooperating with the larger distribution. Again, younger devs or devs used to "lesser operating systems" never experienced life under a proper system-wide software distribution so they have no idea what they are missing. Of course opam looks great once Debian is broken (and until, let's hope, guix or nix takes over). An exemple of such a regression: querying the type of an ocaml expression from any editor used to be trivial from the easily parsable annotation file producer by the compiler. It's now been replaced by a memory dump that's easier for merlin. And merlin will not even be able to answer that simple query unless you provide it with a full blown configuration. Good luck setting that up without the assistance of the dune built tool. Good luck setting that up if your project involves anything else than plain and simple ocaml.
Ach, I probably start to sound unfair. Indeed this tendency toward infantilism is in no way specific to ocaml, probably ocaml has been resisting it for longer even. And it's not specific to programming languages either, nor even to technology. Pardon my rant, grumpy old man can still feel passionate about computers at times; rest assured he is being transferred to another trade :)
I will say that adapting to change is part of the human experience and especially part of the programmer experience. I’m 22, but I’m almost entirely self taught as a developer and have only a year of college. I’ve been reading older programmers (and older people) lamenting the new way of things for at least ten years already, it seems to be a constant. What you now call infantilism will be the old way 30 years from now, and the kids writing software then will be doing stuff that confuses me, I’m sure. But this is how progress happens, and change is okay.
That's because I took that opportunity to rant more largely about the whole industry.
I frequently ask myself what's the likelihood that this perception that the computing industry is regressing, and that is shared by many of the older devs who were passionate about it, would be just caused by normal grumpiness and confirmation bias. Eventually, I believe tech evolution is more dynamic than progress/regress.
I've witnessed the creation and then the demise of personal computing, unrestricted computer networks, free and open software distributions, unbiased search engines; I hope I will not be around when the Linux kernel momentum is lost and personal general purpose computers become once again inaccessible. There were of course already a lot of deficiencies when I started my career ; the big "Software Crisis" was already well documented, some big corporations were slowing down innovation as hard as they could, and surely many established programmers routinely wrote miles of buggy software on inefficient hardware. But there was a growing, vivid shiny trend, easy to spot, in all this gloominess: a Unix revival on micro computers led by young engineers who just wanted to do the right things. Ok, that momentum is gone now and I'm looking for the next big wave that would push us forward. Meanwhile: business, politics, conventions, ignorance and laziness are eroding that culture.
This is how I picture things, at least; in this picture progress is not automatic, nor is regress. Please do not believe progress is automatic, or you won't fight for it. At worse, if that is wrong and progress is indeed automatic, what's the loss?
Anybody today can, in seconds, download dozens of production-ready language runtimes and get started writing programs with a great IDE experience, for free! No cost at all. And this is now a fundamental assumption of software development.
I don't take it for granted because I have some idea of how far we've come, but I read people like you complaining about not being able to work with new build tools and I'll be honest, I assume that you've been left behind technologically and haven't kept up. I'm sure that's unfair, but you don't give these tools credit for their upsides (using new languages is much easier than it used to be, and development with them also scales much better), and you still haven't really explained the downsides fully. Even the C and C++ community is slowly moving in the direction of package managers and integrated tooling.
Do I stick to my tools longer than necessary before acknowledging true progress? Possibly, but not always. I've been pushing ruby over perl/php/python, ngnx over apache, I adopted systemd quite early for some of its practical merits, I pushed for containerd over docker, for nix then guix over Debian, and PL wise I've enthusiastically explored mercury, ATS, and rust way before it was a thing (then decided against it). So although it's true that I would not feel confident in a conversation with young JS programmers I could still name a long list of interesting new techs they have never heard about! :)
One of the hardest thing in a software dev's job used to be to learn to say "no" to product-designers and management. Nowadays it's to say "no" to shiny new techs. Many times this pays off, since most of tech novelties shine only for a brief moment before being superseded by another. The price to pay is to arrive a bit late to the party from time to time. One have to be very passionate and picky to not end up stranded in an isolated ecosystem.
You mentioned IDEs many time. Beware that they are often times such isolated ecosystems. You would not believe how strongly java devs thought no one would ever need to venture outside of Netbean... No I mean Eclipse. No, VScode. Meanwhile, I'm still wondering what problem those are trying to solve; do I have a problem I haven't diagnosed? Must not be the speed of writing or navigating code though, given I'm usually amongst the fastest around. In programming as well as in real life, things own you as much as you own them.
Look, "keeping up in detail" is the domain for youth because youth has the luxury of the spare time to do it.
Besides, being left behind is actually the destination for all of us simply as the result of our own mortality. I'm suspicious that you might think that the fact some folks "haven't kept up" indicates an error on their part rather than a very valid choice.
heh and in my case I'm just not that good a programmer so theres that.
https://github.com/libguestfs/libguestfs/blob/d01ce082180c41...
Now if you're saying that the autotools/make/cmake/meson tooling is hard, I sort of agree, but many people are familiar with C build tools already. I don't see how it's easier or harder than learning language-specific tools.
That's not really the main problem to me but it is a problem.
>many people are familiar with C build tools already
Maybe if they're C++ programmers. I don't know anyone outside of the C++ community who has ever used anything aside from Makefiles and language-specific tooling.
>I don't see how it's easier or harder than learning language-specific tools.
The language-specific tools are typically very well integrated with the default testing, packaging, and editor tools ecosystem. The C build tools are not going to be, at least not for OCaml. Language-specific tools show users the best experience a language can offer. More advanced users can always choose to use something else, but the advantages of the whole community using the same tool are hard to beat as well.
I'm omnivorous but I get paid for web development and that's what most people I know are most interested in. And like I said, they understand Makefiles and make, but autotools and Meson are not "basic C build tools," they're both extremely complex and relatively niche. I'm not saying you shouldn't use the tools you use, but you should understand that they are not popular or well-understood outside of your niche of Linux programming with C. I'm sure these programmers could learn how to use them, but most are going to choose not to if it's the easiest way to use the language. They will pick something else.
Companies are mostly building web and mobile applications, along with the corresponding web servers on the backend. JavaScript, Swift, Go, Java, Python - these are the kinds of languages developers are working with, and none of those languages normally are used with C build tools.
It's common now in some language ecosystems for the default tooling to just generate all this stuff for you, and you move on to writing code. So if you're e.g. a JavaScript developer who is interested in functional programming, and you're used to npm or whatever, it's a difficult start.
Yes, it does.
- Dependency management: opam
- Builds: dune
- Project structure: dictated by dune
- and so on: more details at https://ocaml.org/platform/
Do some of the doc pages need to be updated? Yes. Do some universities take a long time to update their course materials? Yes. Does this mean there's no conensus? No.
Good to hear this is changing, though.
For developers, maybe. But as a user, I love compiling and installing Autoconf software (compared to the alternatives).
Dune enforces fairly strong conventions in project layout.
Agree with a lot of your comment though.
- A dune file in a specific directory makes that directory a component
- An .ml file in the directory with the same name as the component (in the dune file) becomes the main module of the component
- Any submodules aliased inside the main module are properly wrapped and namespaced.
An effort in this direction is a transpiler I'm working on. So far it sticks to a strict subset of python3. But I'm open to incorporating ML like features in an incompatible way if there is a compelling argument.
By sticking to a statically typed subset we've already given up some compatibility.
I don't see Python growing very much more functionally. There's two decades of resisting FP with much vigor, and I expect another two decades of fighting about what little FP has grown into Python thus far.
I'd love to see your transpiler work! It sounds pretty cool.
I keep an eye on mys-lang (@github/mys-lang/mys) and mypyc, to see what's going on in that realm of Python.
Compatibility is a double-edged sword, as I'm sure you realize.
The project I'm working on is called py2many
The Haxe compiler is actually written in OCaml and its type system is influenced by it.
It looks like Haxe was designed from day 1 to be transpiler friendly, whereas I'm trying to leverage python's popularity and language ecosystem to achieve similar goals.
Sticking to a strict subset of python has the advantage that all the scripts are directly executable by the python interpreter. If we add some features (say implemented pattern matching similar to OCaml), we lose that.
Perhaps some macros/library features can bridge that gap. Or over time, python evolves to be more like OCaml.
For an example of what happens when language implementations try to shoehorn in Unicode into their strings, look at JavaScript's UTF-16 strings or this Python example: https://www.reddit.com/r/programming/comments/asi2qo/go_is_a...
The material I’ve found has been quite dense where I’m just looking to learn enough to be dangerous
After that, I would recommend the new (beta) version of Real World OCaml — it gets a lot more in depth about more advanced language features: https://dev.realworldocaml.org/toc.html
There is also https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/. Yours is 2019 Spring, this is 2019 Fall. This version covers many more topics. Might be useful for some. :)
Just to add more:
- https://caml.inria.fr/pub/docs/u3-ocaml/ocaml.pdf (Using, Understanding, and Unraveling The OCaml Language by Didier Rémy)
- https://ocaml.github.io/ocamlunix/ocamlunix.pdf (Unix System Programming in OCaml by Xavier Leroy and Didier Rémy)
- https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12-refm...
- https://ocaml.org/learn/tutorials
You might also find interesting stuff here: https://blog.janestreet.com/. There are videos, too: https://blog.janestreet.com/why-ocaml/
Note that ;; is only required in the REPL (i.e. the 'toplevel'), not in source code.
The documentation of libraries is awful, there's the Async/Lwt split, small ecosystem, the IDE support is flaky (breaks every now and then when you upgrade, doesn't work properly in VS Code).
My diagnosis (specially after talking to people in the Rust community) is that there's a weak sense of community and weak leadership. The response to conflict is "screw this, I'll do it my own way", instead of making decisions as a community. It's kind of the wild west, people going in different directions doing what they want. There's no alignment in focus or effort to really drive things forward.
We are moving away from OCaml. If you are considering it for medium or large production systems, I urge to stay away from it </rant>
I remember trying it out 22 years ago and in retrospect I did not appreciate what a young language it must have been :)