Why ocaml

Pattern Matching. OCaml allows you to use pattern matching in your function definitions. As a result, the structure of the function models the structure of the data it's processing, making it easy to see base cases and harder to miss a case, as you might using conditionals. In fact, OCaml's type checker can often warn you that you've left out a case. For example, this definition:. Pattern matching works both with the built-in data types and with user-defined data types.

Simultaneously, pattern matching eliminates the need for multiple-value returns, and serves as a general-purpose destructuring bind. Finally, many functional languages restrict pattern matching syntactically to function definitions; OCaml's pattern matching is an expression that can be used anywhere.

OCaml gives you namespaces, information hiding and abstract types via its module system. The module system is strongly and staticly typed, even across file boundaries, which allows separate compilation. Syntax Extension. OCaml allows you to arbitrarily extend the syntax of the language, achieving effects as with Lisp macros. This is done through the camlp4 Pretty-Printing Pre-Processor.

When you use it, it completely replaces the parser component of the compiler and feeds a parse tree directly to the compiler for type checking and code generation. Amazingly for a conventional compiled language , you can also use your revised syntax interactively in the top-level. Syntax extensions are separately-compiled into loadable modules; as a result many third-party extensions are available, ranging from syntactic-sugarings of regular expressions, interpolation of variables and expressions into strings e.

OCaml is very portable. The most impressive thing is the wide variety of systems that OCaml's native-code compiler runs on and generates code for. OCaml in particular can be used anywhere that C is traditionally used, such as for embedded devices, graphics drivers, operating systems, etc. By all rights, OCaml should have taken over the world by now, but hardly anyone heard of the language yet alone used it. This is a subjective question, but why have OCaml and ML other languages remained so obscure, while C and other languages became popular?

The first answer is that nobody really knows why languages become popular, and anybody who says otherwise is deluded or has an agenda. It's often easy to identify why a language fails to become popular, but that's another question. The first mature C compiler appeared in ; the first mature OCaml compiler appeared in the late s. C has a year head start. C shipped with Unix, which was the biggest "killer app" of all time. For a long time, every CS department in the world had to have Unix, which meant that every instructor and everyone taking a CS course had an opportunity to be exposed to C.

OCaml and ML are still waiting for their first killer app. MLdonkey is cool, but it's not Unix. C fills its niche so well that I doubt there will never be another low-level language devoted only to systems programming. One of C's great strengths is that its cost model is very predictable: it is easy to look at any small fragment of C code can instantly get an accurate idea of what machine operations will have to be performed to execute that code. OCaml's cost model is much less clear, especially because memory allocation is much less explicit, and the overall cost of memory allocation equals cost of allocation plus costs incurred during garbage collection depends on emergent properties like how long objects live and which objects refer to other objects.

The net result is that performance is hard to predict, and even hard to analyze after the fact. OCaml's memory-profiling tools are not what they should be. As a result, OCaml is not good for applications where performance must be very predictablelike embedded systems.

C is a language with a standard and many compilers. OCaml is a software artifact: the only compiler is from a single source, and the compiler is the standard. And that standard changes with every release. For people who value stability and backward compatibility, a single-source language may represent an unacceptable risk. Anybody with a halfway-decent undergraduate compiler course and a lot of persistence can write a C compiler that more or less works, and with adequate performance.

To get an implementation of OCaml or ML off the ground requires a lot more education, and to get comparable performance to a naive C compiler requires a lot more work. This means there are a lot fewer hobbyists to mess around with languages like OCaml, so it's harder tor the community to develop a deep understanding about how to exploit it.

I think the problem with OCaml is that it isn't too useful "out of the box". The eventual reason why people use a language is because it has libraries they need.

With nothing "out of the box", though, nobody gets far enough into a project to realize that they need to write a library. The result is a language with no libraries, which makes it hard to write "real apps". I think this is what OCaml suffers from -- nobody bothers to start "real projects" in it because all there is is a programming language. Yay, I can add two and two and print the result.

The result is a collection of libraries that are mostly academic abandonware the author got his PhD and moved on , which isn't too helpful for practicing programmers.

I know there is work under way to change this, with projects like "Batteries Included". Come back here in 5 years, and perhaps OCaml will be more popular. There are some exceptions to this rule. Java started off with no libraries, but Sun paid people to write them all in house, and then they marketed the hell out of it. Java certification, Java-specific hardware, Java books, Java classes, etc.

Then even convinced most universities to teach it exclusively, even though it isn't a very good language to use for learning programming.

Over in the functional language arena, we can see that Haskell is becoming quite popular. I think most of the popularity is due to people like dons that write useful libraries, and never stop marketing the langauge. Every day you see a few Haskell articles on Programming Reddit. This keeps it stuck in peoples' minds until they finally decide, "I am going to try Haskell. This means that they can actually do something useful "Right Now".

So between the potential to be productive and hearing about it a lot, Haskell has gained a lot of popularity. CL has many of the same libraries as Haskell and is almost as fast, but nobody talks about it, so it "feels dead". Indeed lisp is much quieter than haskell, but Lisp is still a very productive language with a lot of libraries. But marketing is very important, and Haskell does it better than Lisp or OCaml and competes for the same userbase.

Finally, some people will never "get" programming, so breaking their mental model variables are boxes with values, code executes top-to-bottom will ensure that they don't use your language. This type of programmer is a large percentage of the programming population, so this further limits the possible userbase of abstract languages like Lisp, Haskell, and OCaml. The tools support just isn't there. The debugger only works OK but does not work on windows last I checked and there just aren't that many development tools available for it.

Its type system is, at times, a bit too strong. For someone who does not understand how type inference works or the ML type system in general, the fact that he can't add an integer to a float is a major turn-off right away. The object model seems somewhat tacked-on and the standard library barely uses it, opting instead for module-based libraries. There are lots of other things that basically amount to the language not feeling "polished" and that drives people away during the very critical period when they're picking up a language and trying to decide whether or not they like it.

I think its most important legacy will be that it, along with other ML dialects, has had a very strong influence on other functional languages. Most of the current generation functional languages take the best elements from ML dialects and refine some of the annoyances. Embedded systems often require two things: speed and determinism.

OCaml can provide speed, but the fact that it has a garbage collector makes it inherently nondeterministic, and for a real-time system that simple won't do.

This is a bit of an apples-to-oranges comparison. OCaml is a fairly young language [1] and there has never been a serious, sustained effort to push it into the mainstream excepting Microsoft's current work with F. Unlike C, it isn't the lingua franca of the most widely supported and imitated enterprise operating system i. Unlike Java, it hasn't had a major corporation pushing it as a next-generation computing platform. Unlike Perl, Python, and Ruby, it hasn't taken hold in an high-profile, influential niche i.

Hence, it is not super-popular. The OCaml community failed to develop a large and reliable standard library beyond what comes with OCaml today that makes application development easy. There are several attempts to solve the problem but just take a look at Python or Ruby to see what is missing.

OCaml is a great language if you want to solve an algorithmic problem that does not depend too much on having to interact with advanced standard modules like XML, networking, data calculation and so on, which you would rather not implement yourself.

This makes is hard for a community to evolve a library. If the compiler would map directory hierarchies into module hierarchies I would see a better chance that a standard library would evolve. This would, however, require considerable effort by the core compiler developers. I am aware of packing modules but I think this is a kludge.

Another library problem is binary compatibility between compiler releases. It's pretty safe to say that all library code must be re-compiled after a compiler upgrade.

This makes it difficult to provide binary releases of modules or libraries. Probably because too many people were taught ML as part of an introduction to weird and confusing theoretical stuff about types.

That's what happened to me. I was shown ML and Smalltalk around the same time. Smalltalk just looked damned cool, and it was immediately understandable what OO was for and how you could make pretty, interactive stuff in this environment. ML was about abstract mathematical things that didn't seem relevant to what I wanted to do. And unlike C, didn't promise to let me write fast games on bit micros. This is, of course, deeply unfair and subjective.

But that's likely to be the true story for most people. These days I guess the question would be : now I do feel I need to know this weird and confusing theoretical stuff about types, why would I choose ML over Haskell or Erlang?

A common source of frustration for those learning OCaml is that the standard library that ships with the compiler is limited, covering only a subset of the functionality you would expect from a general-purpose standard library. Happily, in the world of open source software, nothing stops alternative libraries from being written to supplement the compiler-supplied standard library.

Jane Street, a company that has been using OCaml for more than 20 years, developed the code in Base for its own internal use, but from the start designed it with an eye toward being a general-purpose standard library. Like the OCaml language itself, Base is engineered with correctness, reliability, and performance in mind. Base is distributed with a set of syntax extensions that provide useful new functionality to OCaml, and there are additional libraries that are designed to work well with it, including Core , an extension to Base that includes support for UNIX-specific APIs and a wealth of new data structures and tools; and Async , a library for concurrent programming of the kind that often comes up when building user interfaces or networked applications.

All of these libraries are distributed under a liberal Apache 2 license to permit free use in hobby, academic, and commercial settings. A large community of programmers has been using OCaml since its first release in , and has generated many useful libraries and tools. The installation and management of these third-party libraries is made much easier via a package management tool known as opam.

Constituent tools of the OCaml Platform include the dune build system and a language server to integrate with popular editors such as Visual Studio Code or Emacs or Vim. This is a modern interactive tool that supports command history, macro expansion, module completion, and other niceties that make it much more pleasant to work with the language.

Real World OCaml is aimed at programmers who have some experience with conventional programming languages, but not specifically with statically typed functional programming. If you already know OCaml, this book may surprise you. Core redefines most of the standard namespace to make better use of the OCaml module system and expose a number of powerful, reusable data structures by default.

Older OCaml code will still interoperate with Core, but you may need to adapt it for maximal benefit. Code that uses only the traditional compiler standard library will always exist, but there are other online resources for learning how that works. Real World OCaml focuses on the techniques the authors have used in their personal experience to construct scalable, robust software systems.

Part I covers the language itself, opening with a guided tour designed to provide a quick sketch of the language. After covering the core language, Part I then moves onto more advanced features like modules, functors, and objects, which may take some time to digest. Understanding these concepts is important, though. These ideas will put you in good stead even beyond OCaml when switching to other modern languages, many of which have drawn inspiration from ML. Part II builds on the basics by working through useful tools and techniques for addressing common practical applications, from command-line parsing to asynchronous network programming.

Reading this part will enable you to build very-high-performance systems, or to interface with C libraries. This is also where we talk about profiling and debugging techniques using tools such as GNU gdb.