Each year I think wether should I learn OCaml or not. What is the current state of multi-thread OCaml? Is that a game changer or just a cool feature? I can't understand why OCaml doesn't have mass adoption.
Multicore development has sped up pace, there are many changes in the latest two compiler internals that were made in order to accommodate the new GC, and you can read updates on those works in this year's' POPL and ICFP talks.
Multicore benchmarks are on github and are used to drive the changes. When used properly you can see large speedups without affecting much the speed of single core OCaml (which is quite fast).
If you want more details there are monthly updates now on the discuss.ocaml.org forum (just search for multicore). We usually post them also on HN when there is some meat.
Even though rust (or Julia if we talk about numerics) can clearly be many times faster, it is an imperative language with a functional feeling (don't take it in the wrong way, I think both are great languages for different reasons).
For less performance critical applications I think OCaml is still worth, it is reasonably fast for a GCed language, has a great type system and the compiler is egregiously fast.
Multicore makes quite a difference in performances for certain numerical code, however it will be hard (if even possible at all) to reach the speed of fine-tuned Julia, C/C++, Fortran or Rust (which does not yet have a proper numerical framework though, afaik).
The approach of owl has been to introduce an engine (wol-symbolic) that compiles computation graphs to ONNX format, so that they can be executed on GPU, FPGA, different engines, releasing from it the burden of supporting those various backends.
Personally I find the ease of maintenance and refactoring with reasonable speed a good compromise, I think its sweet spot is for exploratory code that does not require bare metal speed and yet should be fast enough.
Just to add to this good summary, OCaml already has some support for parallelism that would be useful for scientific computation.
Essentially you can already have multi-threaded OCaml programs as long as only one thread is using the OCaml runtime at any point in time. For numerical code where you might be spending the vast majority of your time in external libraries this ends up not being a major problem. It's not a dissimilar story for where Python is.
What Multicore OCaml adds is the ability to run multiple threads of OCaml code at the same time (we call them Domains, to avoid confusing them with existing Threads - which can coexist).
> I can't understand why OCaml doesn't have mass adoption.
Probably for the exact same reason each year you think about learning OCaml you decide not to (I mean this sincerely, not trying to be snide).
I think the main reasons it doesn't see mass adoption in industry:
* There are only two major companies that do a substantial amount of OCaml that I can think of off the top of my head, Jane Street and Ahrefs. Facebook does some OCaml too but I don't think it's a core part of their stack.
* The tooling is lacking.
* People have an easier time learning Python or Java so you'll have a larger pool of candidates if you use one of those languages.
Haskell is like the nerdy cousin of the ML family. Everyone knows he's smart, but no one would think to ask him to fix the kitchen sink or install the new dishwasher.
Seriously, Haskell is massively impressive, both as a research language and as an implementation. But it does not shed that certain research attitude. Every known problem seems to be boring. "Oh you want a proxying http server? No problem, this is just the inversion of the endofoo over the category of abstract Monobars!". Sometimes I get the feeling that no one focuses on shipping actual software with Haskell.
Care to elaborate on this point? Maybe it's just because I'm coming from Haskell (lol), but my experience with OCaml's tooling has been pretty darn good.
While I don't think there's a heavyweight IDE for OCaml à la IntelliJ, in Emacs I get my error messages inline, on-the-fly checking (including type inference and checking, which is huge), and pretty good completion. All of this seems to "just work".
The build system also seems to "just work" and utop is pretty nice.
I just cannot understand how people find Python easy to learn but languages like F# or OCaml hard to learn. I personally find Python to be a much more confusing language than F#.
I agree with most of your points. Though for the Python and Java thing, I think it's less that they're easier to learn and more that they are taught in school and/or already have a lot of popularity/momentum.
As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is:
* More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang)
* Better for learning - there are more advanced topics you can go into with Haskell, especially around the type system. There is nothing I can think of that you can learn in ocaml that you can’t learn in Haskell
* More fun - if you want to, there are lots of entertaining/aesthetically pleasing things you can do with writing concise/elegant programs or proving properties using the type system
Also, a lot of the putative advantages of OCaml over Haskell (e.g. “Monads seem complicated”) disappear when you use OCaml in practice.
This isn’t to shit on OCaml - it’s better than 95% of languages out there. But if you’re starting from scratch with no prior investment, I would not prefer it in any scenario I can think of.
I see the Haskell community offensive on OCaml is still going strong.
Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast.
Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users tend to be a lot more oriented towards practical matters like, you know, building softwares rather than lenses library.
I'm not part of "the Haskell community", just a random hobbyist. You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist.
> Being lazy by default makes it very difficult to reason about Haskell performance really fast.
I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.
> practical matters like, you know, building softwares rather than lenses library.
This is the classic completely idiotic "haskell isn't practical" argument. Let me tell you what's not practical: not having multithreading. Not having a well-functioning asynchronous programming system (Async sucks).
Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
> You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist.
It's not persecution. It's just that recently you can't have a discussion about OCaml without having an Haskell devotee dropping by and implying you should use Haskell instead generally for somewhat spurious reasons (same with Rust but the languages are so different, it's easier to ignore). It gets a bit tiring.
> think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.
We might have to agree to disagree on this one.
> Not having a well-functioning asynchronous programming system (Async sucks).
It's a chance everyone uses Lwt then. Pretty much no one uses Async apart from Jane Street.
> Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
OCaml has multiple lenses libraries including one written by Jane Street which are not used a lot because mutations are fine. This is not being far behind. It is being practical.
I would encourage people to learn both Haskell and OCaml. Between functors, GADTs, recursive types one can already have a lot of fun with the advanced corners of OCaml type system. One point where OCaml and Haskell differs a lot is on the question of abstraction and modularity: Haskell requires a transparent world where type definitions are always visible, and abstract interfaces have always one implementation by type whereas OCaml promotes a world where implementation details might be abstracted away and behavior are not bound to types.
I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala.
I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong.
I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml.
The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits.
All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing.
All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior.
For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes.
You gotta admit there's something just really awesome about that.
> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes.
But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag.
Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.
Not sure how it came to be that everyone totally ignores it.
But why would you be doing a bunch of category theory stuff while writing softwares ?
Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction.
OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic.
> Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.
I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway.
I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.
> Of course I guess I could use unsafePerformIO everywhere
I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue.
You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time.
> modular implicits would be a game changer for OCaml.
Of course it's not necessary. I have a lot of experience with Haskell, but I still believe the Haskell way of tracking effects puts an undue burden on the developer. I'm simply not interested in keeping track of effects and mutation.
In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary.
This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.
As others said, I think the language is great. Things get uglier when you want to go from OCaml to real world OCaml. The standard library is lacking, which means you have to use Jane Street libraries or other third-party library which may not be very robust, stable, documented. Jane Street libraries are fine but they significantly increase the complexity of the langage. They also encourage you into doing things a certain way (using sexp, ppx). Also, I find monad-based asynchronous programming to be quite tedious. I feel like a lot of the simplicity and elegance of OCaml is being lost. In terms of fun, I'd rather write a server in Go than in OCaml.
There is another widely used standard library: containers. Which is much less opinionated and aims to extend the standard library instead of replacing it. In many use it in production, so it quite well tested and polished.
It is also true that the standard library is growing faster recently, so maybe this will become less of a problem I. The future.
I think Rust kind of stole OCaml’s thunder. It has most of the same benefits, with a mostly familiar syntax and a lot of industry buy-in. And with recent versions, I never find myself fighting the borrow checker like I used to.
I don't know. I think Scala and F# have stolen OCaml's thunder more than Rust. While Rust has been inspired by ML, OCaml and Rust have much different usecases.
Other than interop with .NET does F# bring anything more ? Perhaps a little cleaner syntax. One thing F# does not bring is Ocaml's powerful module system
> I can't understand why OCaml doesn't have mass adoption.
The biggest problem with OCaml is the tooling (and Windows support is pretty rough). It is getting better, but it's certainly not as easy as using something like Cargo.
> Each year I think wether should I learn OCaml or not
Ask yourself if you want to learn OCaml for practical reasons, or because you want to satisfy an internal itch. Both are perfectly good reasons to learn a language.
When I went to evaluate OCaml, I realized I wouldn't get much practical use out of it despite my curiosity, and focused on learning skills that I would get practical use out of. I'm happy with my choice, and plan to revisit the language to satisfy my curiosity at some other point.
I took a brief look at OCaml and from what I've read the tooling and ecosystem has been a bit of a pain in the past. And while it may be minor, from what I understand OCaml on Windows isnt a thing without cygwin or WSL.
The most serious scientific computation gets done on distributed memory systems, not shared. That likely just means bindings to MPI and other appropriate libraries. That will often do pretty well on shared memory too.
Love OCaml. One of my favorite languages. But I'm using Julia for this kind of thing, it just seems much better suited. Likewise, I wouldn't use Julia to write a programming language implementation, OCaml is much better suited for that.
It's the same for me, Julia is perfect for scientific programming - it has basically replaced Python, it's even starting to be used at my work. I don't think Ocaml has its place in this domain.
Pretty interesting. Reading it, seems closer to a tutorial in using Owl, an OCaml-written package for technical computing (what e.g. Matlab is; though architecture differs according to post).
I am not sure why you are getting downvoted. If you had not posted the direct link already, I would have done so. Perhaps the downvotes are about the second part of your comment.
Skimming through this book, one thing i was constantly wondering, is how well does this ocaml framework use the hardware.
Leaving ocaml aside, the connection between scientific computing and hardware is the one thing I miss the most in "scientific computing" books and courses, because it sooner or later limits the science that any researcher doing scientific computing can do.
To give an example, earlier this week, one of our scientists was waiting 10 minutes between each interactive iteration of their data-set, so I was called to help, and the only feedback they gave was that "its slow", to which I replied "slow with respect to what? how fast are you expecting this to be and _why_?".
The answer to these questions is the difference between "maybe they just need a faster computer", "maybe they need a different algorithm", or even "maybe this problem cannot be solved today because computers this fast do not exist".
From their facial expression, it looked to me that they actually had never thought about any of this, probably because whatever they did before was always fast enough, but now this issue was limiting their science and they were lacking the bare minimum set of tools to even get proper help.
If you are doing scientific computing, chances are that the problems you are going to be dealing with are going to be getting bigger and harder as you advance in your career. For many scientists, the first problems will actually be big enough for the hardware to matter.
I wish scientific computing courses and books will at least provide the most basic tools to these scientist for them to at least be able to get meaningful help. Having someone on call for when this matters is quite expensive.
This has a chapter on low level optimisation in Owl: https://ocaml.xyz/book/core-opt.html, which includes how core functions are implemented in C, and how OpenMP is utilised etc. Besides, Owl relies on certain libraries such as OpenBLAS and FFTPack for the performance of key operations in e.g. linear algebra.
It gives scientists a lot of information about how to perform low level optimization on code, e.g., if your code is "slow", use SIMD, OpenMP, BLAS, or do this or that trick.
But it does not provide the scientist with even the most basic tools to answer the question: "Is my code fast or slow?" (i.e. should I optimize it at all?), much less "_Why_ is it slow, and what's the best way to address that?" (e.g. if it is slow because its using 100% of the peak FLOPs of the CPU, but your hardware has a GPU, so you end up with 1% total FLOP utilization, then none of the "tricks" there will help).
It also completely avoids the issue that, in practice, a O(N) algorithm beats a OpenMP+SIMD-optimized O(N^2/p) algorithm pretty much all the time.
The chapter kind of assumes that scientists OCaml code will be slow, and gives them a "bag of tricks" that they can try to make it faster.
So we end up with the irony of a book on scientific computing that completely ignores the scientific method.
It is a continuing source of wonder how many scientists seem unable to apply scientific method/research to computing. However, yes, things like debugging, measurement, and hardware features should be taught and rarely are apart from courses on performance engineering which seem to pass most by.
Let’s face it, is this researcher ever going to read a book on scientific computing in OCaml? Most researchers won’t even read a book on scientific computing.
In my opinion, static languages don't bring a whole lot to the table with numerical math. There's not many types for one. You basically just use matrices and vectors of floats most of the time.
What would really be a bigger deal is some limited dependent typing to avoid errors from mismatched array sizes. Until then though, Julia is a bit more practical choice for me.
Slap (https://github.com/akabe/slap) is a more serious attempt. Tensority is still a prototype library that ventures very far into statistical safety, probably at a quite steep cost in usability.
> Indexing, slicing, and broadcasting are three fundamental functions to manipulate
multidimensional arrays.
...
> Indexing and slicing is arguably the most important function in any numerical
library.
These statements are undoubtedly true. The first question any practitioner familiar with other systems will ask is: what does basic arithmetic, array manipulation, and linear algebra look like?
But from what I can tell on a very quick skim, that question isn't really answered until the section starting with these sentences, on page 123. I've noticed this situation every time I look at the Owl docs webpage too, FWIW (have not looked recently though).
I understand the need to be perceived as fully-capable for modern tasks -- and that's fine for a 2-4 page set of teaser examples up front -- but I think this book would become much more approachable if the basic mechanics of doing math were presented first.
Interesting idea to use an ML for scientific programming, but I don't see any practical reasons not to use Julia or Python. I'd rather take advantage of everything Julia already offers (+ Python with PyCall.jl) than wait for the same support in a language not widely used in the first place.
You can use PyML to call python from OCaml in the same way, and it works fine to pass an owl ndarray to numpy.
As a user of both, I think they have different treadoffs.
I tend to use OCaml when I am playing around with the code because I find it infinitely easier to refactor (and to figure out what I was doing if I leave the code rotten for too long)
Data science and interactive programming are actually the main focus of the next release of f#. Not saying it’s bad now, but Microsoft wants it to be a strong option in data workflows.
I had originally been learning ocaml but switched to f# because it has much better tooling and more uses (e.g. better web server support since I use .net libs)
From just preliminary research, F# seems both loved by its devs, but also found to be a bit of an unloved child on a sidetrack - that was probably another reason I hesitated in getting started. Do you think that is justified?
I wouldn't say its unloved or on a side track, it's baked into .net as a first class citizen and has dedicated engineers at Microsoft working on it.
When I started I was pleasantly surprised how easy it was to download .net core on a mac and not do anything else to use F#.
Its less popular than C# so its there's not as much documentation from 3rd party sources, youtube videos, etc, but you can use any C# modules in F# so you'll get used to reading C# docs.
I'm aware that .net is cross platform, however there is the issue that C# apps that use WinForms or WPF aren't cross platform, or at least that was the case the last time I checked.
I am curious as to whether the F# ecosystem is similarly fragmented by Windows-only libraries.
.NET Core isn't as feature rich as Java the GUI side, or supported platforms thought.
Almost anything with a CPU has some OEM shipping JVM implementations for them, while Microsoft focus only on the major desktop and mobile OSes (one of them with its own coffee brand).
That is Xamarin rebranded, and there is yet to be a clear roadmap where it stands versus Uno, Blazor (also being pushed for Electron like deployments), WinUI.
Plus it doesn't help that some teams are adopting React Native, even alongside .NET.
Too much chaos going on sorting out WinRT, while most of us aren't willing to say how high when Microsoft says jump.
I went from Ocaml to F# because I wanted better tooling and a much larger pool of available library (any .net library can be used from F#), I did not look back.
Both languages are close cousin but F#'s syntax feels a bit more streamlined at the cost of less powerful type inference (the type inference in Ocaml is a thing of beauty that I have not found elsewhere).
F# for the tooling. Jetbrains Rider is particuarly good. Unfortunately Visual Studio on Windows is a bit lacking.
If you get a feel for F# I'm sure it will be an easy leap to OCaml if you decide to do it later.
Incidentally I've just been running through the Advent of Code in F# over the last few days - I do think the toolset for F# is very kind for a new learner.
I have spent a couple of years doing .NET for life sciences, as many labs are mostly focused on Windows due to their laboratory robots and data readers.
So many researchers end up using a mix of Excel, VBA and MFC (old tech) and Forms/WPF (new tech) based tooling.
If that is your data science domain, I would definitely advise F#.
The experience with VSCode, VS for Mac and Rider are also quite good, as far as I can tell.
Also you can use .NET Core.
Note that VS for Mac is no longer Xamarin Studio rebranded, nowadays it shares several common code with VS, which is one of the reasons why the plugins have moved away from COM to being .NET based.
Scala might be something worth looking at. There's a lot of libraries on the JVM, but sparse linear algebra is still kind of a wasteland compared to Python or Numpy. I wish someone would just make some good bindings to Eigen or something for the JVM.
I've never encountered a real OCaml project or anyone who uses it in my career (same is true for Haskell). I have assumed these languages are a hobby for CS academics and get used for pet projects by their devotees. Not that that's bad - they're interesting and the ideas are cool. I would just be afraid of locking myself into an isolated ecosystem that it's hard to hire experienced people for. Is anyone on HN actually using these languages for scientific computing, or other large production projects? Curious to know what the pros / cons are in practice and how common that is.
I use OCaml at work. We work with the Binary Analysis Platform https://github.com/BinaryAnalysisPlatform/bap which is a pretty essential part of what we do. In general, OCaml seems somewhat popular in the area of compilers and program analysis. Facebook Infer is written in OCaml for example https://fbinfer.com/. This may be as you said because of these areas sometimes more academic flavor. There are companies out there using OCaml for all sorts of things, although of course it is a small fraction of those using python or C++.
Haskell and OCaml are definitely not just hobbies. I've used Haskell full-time for the last five years of my career.
The company I work for uses Haskell for a network packet parsing engine, web api servers, CLI executables, build infrastructure (alongside Nix and NixOS), an interpreter for a custom programming language, a gateway/proxy service for AWS services, etc.
I've talked to at least one persons who works on production Haskell applications, and Jane Street, a company that was discussed on HN just yesterday makes heavy use of OCaml, but yeah they're pretty rare and I suppose the people working with them are just lucky. I've heard particularly about the Haskell market that if you want a chance of competing for the few jobs available you have to be among the top-haskellers, but I'm not sure.
Jane Street being the only company that anyone ever mentions when discussing OCaml is even worse in my opinion. It means the ecosystem is going to be heavily driven by their needs, not to mention that banks tend to have idiosyncratic development cultures.
It is not the only one though. There are Ahrefs, Tarides, Tezos, Citrix (XenServer and a part of Xen are in OCaml), Inria, Facebook (for compilers, typecheckers and ReasonML), Bloomberg (was Bucklescript/ReScript, now at facebook though I believe).
There are also some academic projects with industrial uses. Directly to mind come Coq, Frama-C, Mirage and the Zélus compiler.
Both INRIA and the CEA uses OCaml heavily (Coq, CompCert, Frama-C). Cambridge uses it for MirageOS, Facebook to write software analysers and now web applications (the web version of Facebook Messenger), Citrix in XenServer. Bloomberg developed a compiler from OCaml to Javascript.
Jane Street only gets mentioned so often because it is one of the highest paying and selective companies in the world. They are not in control of the ecosystem. And they have nothing to do with banks.
I'm not very familiar with the scientific landscape of Haskell or OCaml, but if you would allow an educated guess...
Languages like R, Python, Matlab, and Mathematica have a LOT of built-in capability in this area to do symbolic and numerical methods and data analysis kind of stuff (large sparse matrices... etc). You can do a ton in the high level language without ever dropping down to C or Fortran. So a scientist can just do their job without having to worry about how the plumbing works as others (open source community for Python and R) or vendors (Matlab and Mathematica) take care of that, which is a huge win.
Back when I thought about doing scientific work in Ada, Rust, OCaml, and Haskell, I was dissapointed to see that either there were many libraries missing that I would need, or the existing ones were incomplete. The solution is usually just to FFI to Python or C, but at that point, I think you lose a lot of the magic of sticking to 1 high level language. Just my 2 cents. If you're comfortable in doing all the scientific bits in C and just calling from OCaml, then you should be fine. On the data analysis side though, R or Python + Pandas just have sooo much inertia.
I'll add that this book's table of contents seems to have some really neat topics, but a lot are just a single page long and I still think a lot of areas (Ex: linear algebra) are going to be a lot less complete than what Python has to offer. With that being said, the scientific scene I'm seeing in this book is much farther along than I would've guessed, so that is a good sign.
You are right that the ecosystem is small, and will likely be always behind Python, R and Julia. But considering how small the community around numerical methods in OCaml is, I think the work that went into owl and this book is incredible and may help raising awareness and growing the userbase.
I think one of our current limitations is the lack of a high quality, full-featured plotting library. There are some which are used for publication level plots, but they are nowhere near the experience of plotly, matplotlib, ggplot2 or julia's plots.
In any case, the community seems to be slowly growing already, so there is some hope.
I think the best would be if we can start integrating it with SciML and similar projects.
lets you call R from any language with a C FFI. A very simple solution (even if not quite as convenient as a full OCaml solution) that lets someone write OCaml if that's their preferred language. I helped add that functionality to RInside and I've been doing that for years so I can use D for my research.
Indeed! There are already OCaml bindings for many R and python packages in the opam repository (opam is the package manager for ocaml), as well as C and fortran libraries. Similarly there are now a few packages to interact with rust. I think, right now, only a library to interact with julia is missing.
I said it earlier, but if I have to call R from another language, in most cases I'd rather just use R by itself.
Of course there are reasons why you might integrate the two. Perhaps you have an R expert doing the statistics work and the back end developer gluing everything together. That's fine, but at some point the system becomes pretty confusing and is a giant leaky abstraction.
Thanks for the hard work! I always appreciate any contributors even if I have only used OCaml a few times.
I think y'all are definitely raising some awareness and I agree the lack of a plotting library is a major hurdle. You can always call out to GNUPlot from the terminal, but most folks probably don't want to do that.
Similarly, I use https://github.com/mseri/ocaml-gr but it is a safe lowlevel binding. I hope one day to have the time to wrap it into an interface similar to Julia's one.
Not a problem at all. Thanks for chatting and sending the links. I wish you the best on this project. Maybe it will help get OCaml some additional/well-deserved attention and love. I'll keep my eye on the project too. Is anyone working on data frames?
OCaml is the strongly-typed functional language that sees most serious use.
It's harder to do generic polymorphism in OCaml since the language has nothing like C++'s parametric templates or Haskell's type classes. It does have a very nice module system that has the required flexibility, but compared to these languages, I think it is clunky for the kind of genericity seen in scientific computing.
I think Julia has shown us that strong typing is not really needed for scientific computing.
> It's harder to do generic polymorphism in OCaml since the language has nothing like C++'s parametric templates or Haskell's type classes. It does have a very nice module system that has the required flexibility, but compared to these languages, I think it is clunky for the kind of genericity seen in scientific computing.
Are parametrized modules really clunkier than parametric templates ?
At least for beginners, they absolutely are. I have found undergrads generally get the idea behind something like HashMap<Integer, String> but getting them to reason about OCaml modules takes quite a bit of effort.
(int, string) Map.t doesn't seem to be too many steps away from your example. When I was learning OCaml, I found that much of the module and module type system can just be seen as a more beefed up version of interfaces in OOP languages, so it didn't take long to see its benefits.
The grandparent meant that OCaml is static while Julia is dynamic, and both are strongly typed.
>You can specify types, but they don't really do anything except help with performance.
For Julia it's the exact opposite though, types don't help with performance since the compiler infers them anyway regardless of declaring them or not (you only really should to specify in very particular cases where inference is not possible to avoid the compiler being too conservative, and if you overspecify types you might even end up with a slower program). You declare them for their main purpose of controlling dispatch.
Julia's type system is a core aspect of it's paradigm (multiple dispatch [1]), which is the key element in both it's performance and polymorphism. It's different from a gradual typed language in which the language can exist without the types at compilation time, but those can be optionally added to enhance safety or performance, Julia cannot be compiled without knowing the types, which will happen regardless of declaration.
That said, types in Julia are not used for compile time static checking, which is a compromise that for many tasks it's not worth it. Ocaml ML and Julia ML can coexist well exactly because they have vastly different compromises, with Julia focused on interactivity/fast prototyping and Ocaml in safety (like Lisp x Haskell, but with somewhat more pragmatic languages).
An example of OCaml use in scientific computing is to derive the framework for the FFTW library, which is rather important. (No, the library isn't written in OCaml, as I've seen claimed.)
Owl, the array/scientific computing library that this book introduces, has been discussed on HN before. Dropping those links here, in case people are curious about the comments.
As someone that likes and uses OCaml a lot but uses Julia for scientific computing, it's not worth it, just use Julia.
The Julia code is going to be shorter, faster, and more elegant. The libraries will be sooo much better. The static typing of OCaml doesn't really help in this area and sometimes actually hurts (statically typed DataFrames don't work so well).
What makes Julia code shorter and more elegant generally? I strongly disagree with static typing not being useful in scientific computing. Most of that I see isn't dealing with data frames, though I've seen confusion with types in those with R users.
I would say the biggest difference is broadcasting. So let's say I have an array of returns, r:
r = [0.0001; -0.00002...]
I might be interested to find the cumulative returns:
cumprod(1 .+ r) .- 1
Or just apply a function f to it:
f.(r)
In Ocaml I can't vectorize any notation:
List.map ~f:(fun x -> x - 1)) @@ List.cumprod(List.map r ~f:((+) 1))
List.map r ~f:f
Julia allows you to write code in a very vectorized, array language style. OCaml does not. This is big big issue, imo. Also with multi-dimensional arrays and slice notation, Julia is just very convenient for working with higher dimensional data. OCaml, to put it mildly, is not very good at this.
Scientific computing and array languages go hand in hand. Also the lack of polymorphic functions is a big problem in OCaml. For example it would be impossible to define an addition function in OCaml that transparently worked with arrays:
Julia makes this easy. A real array language like kdb+/q or J is even better.
This is great for linear algebra (matrices and tensors). You can write very math-like equations using very high level functions. With OCaml you will always be burdened with the nitty gritty of mapping and folding over the lists/arrays.
That's what the kind of book it came to my mind when I read the title. No, they differ though there is slight overlap and yes, someone should read them both. OfS first, OSC next.
Specifically. OfS is an introductory OCaml book (first half) which has example usage of interest to scientists (second half). OSC though it has some introductory text per section is mostly concerned in showing Owl, which is what you'll end up using.
