19 ms·
OCaml for the Masses (2011)
- rkangel 8y agoIf people want to move towards functional programming, I would recommend Elixir as the first step. There is a fantastic web framework called Phoenix built in Elixir. This provides a way that you can immediately build something useful, and it teaches you how to use Elixir well: the documentation is good, the generated code that you start working with is a great example of how to use the language properly, and when you start understanding the design of the framework it's a great example of functional systems design (e.g. the Plug.Conn structure that gets passed around). Not having to deal with a full ML (or Haskell) like type system takes away a large barrier to entry, but you still have to change your mindset about how you implement things. And then the dialyzer is there, when you later want to start using gradual typing.
- proaralyst 8y agoElixir is not statically typed. Thus you lose a lot of what makes OCaml great; a whole class of errors caught by the compiler before you run your program. I'd say the type system isn't that much of a barrier to entry. You're likely used to one from any existing statically typed language; the only new things are sum types, polymorphic types & type inference. These aren't _that_ hard to get your head round but really improve the safety of your program.
- rkangel 8y agoMy point was about barrier to entry. My experience is admittedly with Haskell rather than OCaml, but while I did get my head round these things to some degree, I was still a long way from being productive. And this is despite having come from a background of C++. The debate on static vs dynamic is a far from settled one, but I think you would be hard pressed make the case that Python has no place. In this case, I'm suggesting that Elixir is a great way of getting people into functional programming and learning the value, while being immensely useful in its own right. Learning that value is a good first step. I now find it immensely depressing every time I go from my Phoenix web-app back to the Android app. Kotlin is better than Java, but it's still a mess of objects and interfaces, and having to construct 5 things when it could just be passing a map to a function. The result is that I will now more aggressively pursue FP options when I'm looking at technology decisions (e.g. bucklescript is on my 'to investigate' list).
- proaralyst 8y agoHaskell has a famously high barrier to entry that has little to do with its type system or functional nature. As a pure lazy language you have to learn a lot of concepts (What does pure mean? What does lazy mean? What is a monad?) before you can be productive. Extending this into intermediate usage is difficult too; how do I begin to combine these monads I now understand? I see your argument. If your aim is to get into functional programming then Elixir/Erlang, even Lisp/Scheme is fine. I don't think it's the functional nature of OCaml and Haskell that make them powerful; I think those parts of the language are great, yes, but the type system (static, algebraic, inferred) is the real secret sauce.
- progman 8y agoIf you want to teach FP you should use the very first and most simple FP languages --- Lisp and Scheme. Despite their extreme simplicity, they provide an extremely expressive power (through their macros) which is still unmatched in most other languages.
- drb91 8y agoI wouldn’t characterize either as FP, though—both of them still actively encourage maintenace of mutable state and use of macros. They may be “simple” in that they are very analyzable but you’re teaching a whole bag of skills, and the most FP part of lisp/scheme is just the closure.
- baby 8y agoThese languages are horrible, filled with parenthesis and not fun. I had to learn these in school, like many other people, and I stayed away from FP languages for a long time because of that (like most people). Try to learn Erlang or Ocaml, it's fun.
- remify 8y agoGreat writing. By the way, How is it that HN readers always heavily promote OCaml related threads ?
- DougBTX 8y agoI upvoted the article as OCaml is one of those “aspirational” languages that I’ve always had an interest in, but never found the time to explore. I’d like to hear more about it, might prompt me to pick it up one day.
- DanielBMarkham 8y agoThe nice thing about OCaml (and its MS cousin F#) is that it's a hybrid language. Know FP? Fine, you can code that way. Know OO? Fine, you can code that way. It meets you where you are.
- int_19h 8y agoI would even argue that for OO, OCaml is a better object-oriented language than most dedicated OO languages. It nicely decouples classes from types, for example, so that the subclass diagram needs not correspond to the subtyping diagram (i.e. you can reuse code via inheritance without following LSP subtyping rules, but the type system will still prevent any unsafe use of such hierarchies).
- reacweb 8y agoThis article is very good and OCaml is an excellent language that is underappreciated (IMHO). I have used Caml-Light when I was student and I loved it.
- phkahler 8y ago>> How is it that HN readers always heavily promote OCaml related threads ? Because functional is still the flavor of the decade.
- tybit 8y agoThe masses won’t be coming to ocaml unless it comes to them. ReasonML seems like a much more likely approach to succeed to me.
- lmm 8y agoWhat seems to be working is Rust.
- leppr 8y agoRust is a very different beast when it comes to development speed. When compromises must be made, its design decisions always favor runtime speed over developer friendliness. That results in rather unwieldy APIs compared to the alternatives in dynamic languages. As a replacement for C/C++ this makes perfect sense, as a replacement of JS/Ruby/OCaml, not so much.
- fnord123 8y agoOCaml belongs with C++ and Rust for compile times...
- LeonidasXIV 8y agoHow so? OCaml complies way faster and you don't actually need to compile it. You can sort of use it as scripting language without any compile step to begin with.
- pjmlp 8y agoHow so? OCaml has bytecode + native code compiler, both much faster than heavy C++ templated code, or plain Rust code.
- aldanor 8y agoAny particular examples of “development unfriendliness” in Rust? I would also say safety/correctness usually win over runtime speed concerns if no other factors are involved as far as Rust design decisions go, at least that’s how it has typically been.
- jasim 8y agoI for one can't wait for Typed FP to become mainstream as soon as possible. I think the prevalence of scripting languages in large systems today is a quirk of history. In early 2000s, as the web was growing to be an application delivery platform, the only practical statically typed language was Java. It didn't have generics or lambdas at the time, and was infested with the sprawl of J2EE. Choosing Ruby/Python over Java was at the time an act of rebellion and a show of technical superiority. To quote pg: "if they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers." The static type system in Java is object-oriented: the only way to create a type is to create a class. I believe it was limited in abstraction power and everyone attributed it to the rigidity of static types. Java has come a long way since, but the sense that dynamic typing is superior to static types lingers. But OCaml's static types are a completely different kind of type. There is a kind of "procedural" static typing in Go, C, and to some extent C++ where primitives are typed and you can construct structs and unions without much ceremony. Then there is object-oriented static typing in Java and C#, which traces its origin back to Simula through C++ where types and classes are the same. Then you have functional static types where types are just and only about data. Almost all Typed FP languages use a form of Hindley-Milner inference, support algebraic data types and pattern matching, have generics (they were invented by Milner for ML in 1973), and allows for code organization and encapsulation through modules and opaque types. Algebraic data types alone is a tool for thought like no other. You'll start reifying concepts that would've otherwise gone implicit in your codebase thanks to ADT. The languages are solid, ecosystems are vibrant but small and that can only be fixed with more people. Come on in, the water is fine!
- MaxBarraclough 8y ago> I think the prevalence of scripting languages in large systems today is a quirk of history. Disagree. This is happening because software development has become an enormous industry, and is now subject to Sturgeon's Law. If the bulk of software development really was about correctness and quality rather than rapid development and low skill barriers, we'd be seeing a lot more Ada and OCaml, and a lot less JavaScript. But here we are, and it's not going to change just because someone makes a technical breakthrough in the design of functional programming languages.
- devit 8y agoIt seems like Rust would have been an even better choice, had it been available at the time they chose OCaml.
- progman 8y agoRust may be a very good choice for systems programming. However, safety criticial software can also be written in other languages which don't need a borrow checker -- Ada and SPARK for instance, or even in C with verificatino tools (FramaC etc.). Most developers also don't need Rust's "feature" of not having a garbage collector since they are not involved in systems programming. As for me, what makes OCaml attractive is its functional nature combined with a very practical imperative syntax. There is no steep learning curve like in Rust, and OCaml's compilation speed is staggering.
- raphinou 8y agoI'm currently looking for the language and framework to use for a project, and I'd like to go with a functional language. I really, really want to do my next project in Ocaml, but... I find the ecosystem seriously lacking. You find Ocaml libs for a lot of needs, but a lot of those a unmaintained and have their last commit a couple of years ago. I'm afraid that choosing Ocaml would mean spending quite some time on libraries I need, and less on the app I want to develop. There's F# and the SAFE stack, but I don't feel home there. A lot of docs/libs still are (or have quirks due to having been) Windows specific, and joining the most popular f# community communication channels requires you to join the F# Software Foundation.... Then there's Scala, with functional programming and access to Java's ecosystem. But I prefer the ML style of Ocaml and F#.
- gabipurcaru 8y ago> You find Ocaml libs for a lot of needs, but a lot of those a unmaintained and have their last commit a couple of years ago. Not sure what issues you ran into, but this isn't necessarily a bad thing. I had a similar experience with Elixir, where some libraries had been last touched two years ago, but did the job with no issues whatsoever.
- raphinou 8y agoWell, one example is oauth in ocaml. I find this https://github.com/jaked/ooauth https://github.com/jaked/ooauth but it has an open issue from 2013 titled "Fix compilation on recent ocamlnet, gcc". I have the feeling I encounter a lot of these situations when I look at libraries I would need for a project. It's rather uncommon I see a very active project in Ocaml (even if there are some indeed).
- donatj 8y agoThis is something I see and feel often. If something is untouched, that doesn’t mean it’s broken or for that matter unmaintained. It can simply mean it was simply done correctly from the get go. Think of code as a formula, how many formulas are there that haven’t been touched in hundreds of years, due to the fact that they are correct. The desire for libraries that are constantly in flux stems from the “move fast and break things” mentality, mixed with the continuous flow of breakage in mutable languages. If you move slow and do things well, you can often build some reliable with a fraction of the effort.
- zengid 8y agoI'm personally having a lot of fun learning Rust, which seems to have been largely inspired by OCaml. Algebraic data types and pattern matching are a revelation!
- aldanor 8y agoFun fact: Rust compiler was initially written in OCaml.
- ynniv 8y agoI want to spend more time in OCaml, but without threads it's a tough sell. Modern performance requires parallelism with shared memory, and the current mainline solutions don't offer that. Where threads aren't part of the equation, OCaml has become suddenly popular. That's telling.
- jasim 8y agohttps://pl-rants.net/posts/go-and-ocaml-scalability/ https://pl-rants.net/posts/go-and-ocaml-scalability/ has an interesting take where they found multi-process OCaml performing better than goroutines. I don't know how to interpret those measurements correctly, so any help there would be appreciated.
- ynniv 8y agoThis experiment has "embarrassingly parallel" data, ie there is little to no benefit to sharing data between computations. It's not surprising that multiprocess does well on this, but this is not common in most real world applications. Imagine a simple chat server, where every request needs to read and write shared state. Even when the application doesn't seem to have shared state, any in-memory caching requires it.
- jasim 8y agoThat makes sense. Thanks.
- anentropic 8y ago"most real world applications" is a meaningless phrase, I doubt anyone can quantify "real world applications" one way or the other also the result is still interesting, why wouldn't goroutines scale just as well, but apparently didn't?
- ynniv 8y agoThat's fair, but perhaps I can rephrase it to say that embarrassingly parallel applications are a well known edge case and not the norm.
- christophilus 8y agoI would love to see something more like SML, with OCaml compile times, and a Go-like standard library. If that could be accomplished, I think we would see statically typed functional programming go mainstream.
- prossercj 8y ago> Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function. - John Carmack This mirrors a discussion I've had with my boss a number of times. Most of our products are written in C++, and we complain about how often developers (usually coming from Java) think that everything needs to be inside a class hierarchy. The procedural parts are still there for a reason: the CPU is procedural. A procedure or function is a closer mapping to what the CPU is actually going to do when the code runs. On the other hand, I've never done serious work with a pure functional language like OCaml. I would welcome the chance, though I wonder if one finds the same kind of dogmatism as in the OOP world...("it must be a pure function!")
- naasking 8y ago> I would welcome the chance, though I wonder if one finds the same kind of dogmatism as in the OOP world...("it must be a pure function!") Nah, OCaml is a very practical functional language, that's why it features mutable state. You just have to opt-in, so it just encourages [im]mutability as a default, as it should. Edit: fixed typo!
- badpenny 8y agoDo you mean "encourages immutability as a default"?
- p4bl0 8y agoYes, that's what he meant ;). In OCaml references are always explicit (different syntax) and mutable field in records must be declared explicitly as mutable. However, OCaml does not bother you too much (as compared to Haskell for instance) when using side effects like printing.
- hajile 8y agoHaskell is dogmatic. Everything must be lazy. Everything must be immutable. Everything must be pure. Ocaml (and SML) aren't particularly dogmatic. They are both eager, so reasoning about performance is much easier. Most things are immutable by default, but you can make mutable data structures in both. Rather than insisting on pure functions, SML and Ocaml allow side effects in functions and have the `unit` type for functions without a return. The type system is actually strong (eg, no implicit casts) and null exceptions simply do not exist. Multi-threading is the big weakness. Ocaml has been promising support for at least a decade without mainline support. Likewise, most SML variants don't have support (though PolyML does along with a couple others).
- adultSwim 8y agoPython makes it easy to start a program. OCaml is easy to finish one.
- thibran 8y agoThese kind of blog posts are one of the reasons why I love the internet, and why Hacker News is such a great place.
- lovebes 8y agoReasonML is going to bring Ocaml to the masses. Massively popular React apps can be created from ReasonML. Ocaml + syntactic sugar = ReasonML.
- twoquestions 8y agoIs F# still being used/developed, or has MS started to leave it out to dry?
- G4BB3R 8y agoI am still waiting a friendly backend language similar to Elm. OCaml is hard and lost timing.
- eterps 8y agoYou might find this interesting: https://wende.github.io/elchemy/ https://wende.github.io/elchemy/ IMO OCaml is not any harder than Elm.
- deleted 8y ago[deleted]
- donpdonp 8y agoElm is the langauge that showed me a functional language can be amazing. It clicked in my head like no other language. I did a substantial web app in it, and came to appreciate it more and more. I only wish it were available as a general purpose language. I used to call elm a gateway-drug to ocaml but I have a hard time swallowing a lot of ocaml syntax. Reason seems to be a good way around that. I'm also keeping an eye on the Grain language.
- justaaron 8y agois there any NON-garbage-collected functional programming language? Something suitable for real-time or deterministic timing usage?
- yminsky 8y agoHey, author of the linked post here. A few thoughts, since some things have changed since that post was written: First, the tooling limitations that I mentioned in the article have gotten a lot better. In particular: Merlin now provides IDE-like functionality for your editor of choice (including code, vim, and emacs). Also, Dune is an excellent build system for OCaml that does an enormous amount to simplify the build process, and tie a bunch of different tools in the ecosystem together. One great thing about Dune is it does a lot to unify the experience we've long had inside of Jane Street with the open-source OCaml experience. It's really a big upgrade. We've also made some progress on debugging tools, like the spacetime allocation profiler. There's also active work on making GDB/LLDB debugging in OCaml really first class. Also, OCaml has had some major industrial uptake. Notably, Facebook has several major projects built in OCaml (Hack, Flow, Infer) as well as their own syntactic-skin-plus-tooling on top of OCaml, in the form of Reason. Reason has gotten a lot of traction in the webdev world, which is awesome. Bloomberg, and Docker are some other big names that have real dependencies on OCaml, along with some more names you probably don't know like Ahrefs, LexiFi, and SimCorp. People sometimes feel like Jane Street is the only real user of OCaml, so they imagine that Jane Street's needs are the ones that drive the language priorities. So, the thinking goes, if you're not a trading firm, you should look elsewhere. But this is the wrong picture. First, there are other serious users, as discussed above. Besides, the community doesn't just roll over and do what we say. If you don't believe it, go and see how often our PRs to OCaml get rejected. And even our interests in the language have grown beyond what you might imagine a trading firm would care about. We use OCaml for building traditional UNIX system software, like MTAs, for designing hardware (via HardCaml), and for building dynamic browser-based applications (via Incr_dom). For sure, there are still challenges of being a minority language (and there's still no multicore GC, despite some exciting progress). But I believe OCaml is a yet better choice than it was in 2011 when I wrote the article.
- revskill 8y agoThe problem with Reason is non-automatic understanding 3rd party Javascript codebase. It's the pain to implement correct type to use in Reason program with existing JS codebase.
- fileoffset 8y agoOCaml is not for the masses, it never has been