OCaml’s standard library is poor and has a lot of design flaws. Which alternative do you recommend to use? JaneStreet’s core looks very nice, but as I’ve heard it is too big and not so popular.
You should take a look at Base.
The stdlib is not that bad (except a few modules that really show their age, e.g.
Str). The community provides several options:
- core (or core_kernel, or base), owned by JaneStreet (Apache)
- batteries, a community effort (LGPL)
- containers, my extension (BSD)
- several other extensions, that I think are smaller
I’m sorry, but how can you be an OCaml “newbie” and make such a statement ?
He probably saw other people saying it.
@egoholic: I think @c-cube summarised it the best. I have not tried core (and just heard of base). I’ve only tried Batteries and it seems they are not getting enough attention. I’ve been meaning to try containers but so far I have found discrete libraries to provide what I have needed so far and I’m backing out of Batteries.
I suspect the bigger the whole library, the harder to maintain and get enough expertise to make a good one.
It’s very easy:
I’m newbie in OCaml, not in software development
I’ve read a lot about OCaml and it’s ecosystem and I’ve also read about poor standard library in the RWO book (haven’t you heard about it?)
I’ve reimplemented most of RWO examples using OCaml’s standard library instead of JaneStreet’s Core. So I can compare at least OCaml’s standard library and 2 versions of Core (the old one, covered in the book and one of the last releases).
By using a simple logic I can suppose that if OCaml has so much standard library pretenders, then the real/current standard library is poor and has design flaws. For example, it looks like authors put functions into modules randomly, so that I need to use at least 3 different modules for simple file manipulation. The compare function which returns -1, 0 or 1, is also poorly designed cause it’s signature says that it returns int (any int!).
P.S. Your comment has a flaw in it’s logic called Аrgumentum ad hominem. And I guess you are not much sorry.
Thank you for recommendation. I’ve read across JaneStreet’s Base library documentation and it looks as a good replacement.
Thank you for your response, Yaron. Base looks exactly as that what I want to have, except I don’t invest my time in writing it so that I got it for free. Thank you and all of the contributors to Base/Core/Async/Increment/etc. for working on really cool tools and their sharing.
There are alternatives and extensions to the standard library not because it has any flaws or is poorly designed. The main problem with it is that it is very small and lacks lots of features that are common in modern languages, cf., Python, Ruby. This mainly comes from two reasons: First, OCaml is a rather old language (most of the stdlib was written for CamlLight nearly 30 years ago), and at that time it was more than enough. The second reason is the support burden. It takes a lot of time to support a big library. My personal opinion, the OCaml development team consists of excellent scientists, very bright people, and it would be counterproductive to use even a minute of their time on implementing boring stuff like file processing, XML parsing, or any other stuff like that. I would better remove the burden of having the standard library at all, and let them focus on much more interesting tasks.
Next, about the alternatives. There are two general approaches - the standard library extension, and the standard library substitution. The Janestreet took the latter path, all other solutions took the former.
At Carnegie Mellon University we use the Janestreet Core (kernel) library for several years (and will keep doing this). There are good things about this library and there are bad. The good thing is that it is tremendous - it’s millions of code written by really good programmers and tested by the real life. The main problem, that we face, is the lack of documentation. Though in the past few years the situation has improved, the documentation and its availability are still average. Another problem is that given the size of the library it is very hard to learn it (and to teach it). It is also using lots of indirections, and unlike the standard library, its code is hardly readable and non-transparent. That all makes the Janestreet library a rather poor choice for education, but an excellent choice for the industrial software development. That’s my personal opinion, and I see a movement in the direction, where the Janestreet stuff becomes more accessible to newbies. To summarize, it’s an excellent library, but sometimes a little bit overwhelming
Another approach is not to fix the standard library (does it really need fixing?) but to extend it. The main rival of the Core library in this field is the Batteries library. I used it a lot, and can’t say anything really bad about it. But I’ve moved to Core, and never regret it.
Speaking of the future of OCaml, since now we have OPAM, it makes integration of different libraries much easier, and we do not really need such gargantuan libraries as Core and Batteries. We can now ship small libraries each doing one thing. (This may lead to a library explosion (cf., npm) but I hope that we will never go that far). I really like the Containers library, and I believe (and hope) that this is how the future of OCaml will look like.
But for today, my personal recommendation for you is to use the Janestreet Core library (not the Base). Read the RWO book, I would even suggest you read the second version (that is currently under development). Since the time when the first edition of RWO was written, OCaml infrastructure evolved a lot. Concerning the Base library, I personally believe that right now (Nov 2017) it is not ready to be used alone. It has a few glitches and, most importantly, the books assume that you’re using Core (maybe Core_kernel), and since the Base library often reuses the same names as the Core library, you could be easily confused.
Looks like that this comment has the same, Аrgumentum ad hominem, flaw
Thanks for the kind words about Core. And the unkind words (about the documentation having issues and the indirection making things hard to read), well, those seem on target too.
We’re starting to use Base more in earnest inside our walls, and I hope to get to reworking RWO to use Base instead of Core_kernel (which is the portable, but still large, subset of Core), which is what the dev version currently uses.
We have a full-time technical writer on staff now, which I’m hoping will help us improve the docs, and improvements to the doc toolchain itself should make it possible to generate simple documentation even for APIs that were built on top of fairly advanced uses of the module system.
So, I’m hopeful that Base is moving in the right direction for a wider set of people to be able to adopt it comfortably.
Btw, I really like the new Base library and the idea of splitting the Janestreet universe into more manageable small libraries, at least as observable from the outside. It’s just today, speaking of the version v0.9, it has some rough edges and some surprises for those people who were reading RWO (in both editions), that’s why I’m discouraging newbies from using it. So as a disclaimer: this is my very temporary opinion, and it will be revoked very soon, probably when the next release happens.
For those of us who are fairly new to OCaml and is mostly familiar with Core (because of RWO), could someone explain Base a bit?
Personally, I am currently unwilling to use Base, or Core_kernel, or any part of Core at present unless I have an adequate understanding of the use of a module based on what’s in RWO, or there is something I just can’t get any other way. The documentation and the relationships between modules is just too confusing, and Base doesn’t do enough for me. The build system for Core through opam seems like it’s very complex, and there can be problems that aren’t documented and that I’ve had to work through on my own.
Someone who has long experience with one or more of the Jane Street packages will obviously feel differently, which is fine, and some newbies may also feel comfortable using the J.S. libraries. Really, I may be lazy or lack insight.
So nothing here should be interpreted as a criticism of the J.S. libraries. Maybe a just warning to newbies (I’m not far from that state) that if Base or Core isn’t working for you at present because of documentation, etc., there’s a good chance that either Batteries or Containers will be a better alternative. Or might be the best place to start. It’s not like Core or Base is the usual default, afaics, except for RWO study. Even so, I learned OCaml from RWO1–excellent book–but rarely used Core even then. In the chapters that I studied the most, it was usually easy to run the examples, maybe with obvious adjustments, using Batteries or the standard library. (There are other chapters that are quite Core-specific.)
I can say a few words about Base. Really, there are three libraries to explain:
- Core: A full-fledged stdlib, with tons of useful libraries, including operating-system level functionality. There’s a lot of code, and it depends on lots of syntax extensions, so it takes a while to build and has many dependencies.
- Base: Portable, like Core_kernel, but considerably smaller, consisting of just the bare necessities. It has almost no build-time dependencies, so it builds in a flash, and is easy to use without the kind of package management support that opam provides.
Base is also aiming for more stability than Core and Core_kernel, and we’ve made an attempt to clean up some old API mistakes in Core, in particular with respect to how maps, sets and hashtables are integrated into the library. Also, Base tries to clean up some old awkward bits in OCaml proper, most notably by hiding polymorphic compare by default, though it’s still there to be pulled out when you need it.
I don’t quite understand @mars0i’s concerns about modules, but if you have concrete questions, that will help us fill out the documentation. We are specifically doing some work now on trying to improve documentation for Core, Core_kernel and Base, so hints as to what bits are complicated would help.
It’s worth mentioning that, except for maps, sets and hashtables, the APIs documented in RWO are essentially the same as those in Base. And even those differences are in the process of being resolved, by moving Core and Core_kernel’s APIs to match those in Base.
Was that “almost no build-time dependencies”?
Yes. I fixed the original post as well.
BTW, @Yaron_Minsky, a brief aside:
I’m an OCaml newcomer, and recently learned the language from RWO. I found that when I wanted to try to look at the Core documentation on the Jane Street site, I often couldn’t make heads or tails of it.
Part of that was functions that have only type signatures present and no real documentation associated with them.
An unexpected part of it is I just plain find the documentation web site confusing.
First, if you do something like googling for
ocaml core hashtbl you’ll get pointers to random version numbers of the docs. If there’s no way to fix that, maybe they could have links to let you click through at the top to the docs for the latest version?
Also, if you start from https://ocaml.janestreet.com/ocaml-core/latest/doc/ and start clicking through to
core thinking you can find
Hashtbl there since RWO explains
Hashtbl is part of
Core, you’ll rapidly get confused, as you first hit what seems like a dummy page, then click through to something mysteriously referencing
Core__.Std0, and then to a page that doesn’t reference
I’m sure a lot of the problem here is that I’m a rank beginner and don’t understand what I’m looking for, but on the other hand, as a rank beginner that doesn’t know what I’m looking for, it would be nice if the documentation was more helpful.
Also BTW, let me say that RWO is a great book, and made it very easy for me to get started with the language. I just find trying to learn what’s in
Core somewhat frustrating given what the documentation is like. (On the other hand, the documentation of the standard library on ocaml.org is also pretty frustrating. On the other other hand, it is also a shame that documentation is frustrating to use…)