kinda sorta, the reason why people still thing of ocaml is because janestreet use them, and janestreet makes a lot of money .. and we all want to make money, so somewhere vaguely some people can/may link ocaml with money
i love ocaml, i love ml languages, and i think ocaml is a very good ml
but, i think its kinda too late for it,
i think people who want to program with types today most likely will go to rust, scala or f#
Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.)
I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.
I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible.
I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...
> I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant.
Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption.
Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)
Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it.
Scala "implicits" mean two different things:
1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from.
implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class")
2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance
def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append)
is equivalent to the Haskell
monoidSum :: (Monoid a) => [a] -> a
monoidSum as = foldl' mappend mempty
Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts.
Modular implicits are similar to (and inspired by?) Scala implicit parameters.
If you don't mind reading a paper, there's a paper on it that actually is readable instead of just all whitepapery and overly-theoretical: http://arxiv.org/pdf/1512.01895.pdf
"Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming"
Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages.
Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done.
So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
I don't see why someone would evaluate F# but not OCaml, they're very similar languages. The breadth of libraries available for F# may be greater, but OCaml has some strengths that F# currently doesn't, such as native compilation. I'm teaching myself F# at the moment but I'd not rule out using OCaml in the future.
From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link.
Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start.
EDIT: The project I was referring to before is Nymote: http://nymote.org/
F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.
Why Rust though? It doesn't provide much in terms of an expressive type system when compared to Haskell, SML, OCaml, Idris. I like Rust for many reasons and it's a huge boon for more correct software produced by more people (aka those who don't use an Ada profile :D) but Rust's type system isn't something to weight heavier than OCaml's. There is at least one SML implementation with region types from what I understand. Need to look it up, but it was the implementation from that Dane whose name was something like Elsberg or something and which also had tracing and stuff. For SML I use the MoscowML REPL and MLton for executables. But I don't do much SML, unfortunately. In some ways it's nicer than OCaml.
What features does SML or OCaml's type system have that Rust's doesn't?
Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds.
Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
OCaml's module system is a nice tool for many cases that is only slowly getting into Haskell via Backpack but not there yet. So that's one.
GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful.
I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC.
I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
The post is called "Rust for functional programmers" and contains side-by-side comparisons with both OCaml and Haskell. http://science.raphael.poss.name/rust-for-functional-program...
you might be confusing it with the other post "Haskell for OCaml programmers"?
It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
OCaml has higher-kinded types in the guise of modules, and so does SML with common extensions. I'm not completely sure what you're implying, but type classes aren't required for higher kinds.
OCaml has a powerful module system, labeled and optional function parameters, row polymorphism, equirecursive types, and GADTs. Most of these features would be fairly difficult to add to Rust.
OCaml also has a better track record with soundness issues than Rust, and more interesting fragments of the language have been formalized.
In MLs, you can often replace what would be a typeclass in haskell with idiomatic uses of functors (parameterized modules). It gets kind of hairy if you do it a lot, though.
Compare rust head to head with Haskell and and it will come out of that fight sporting some serious bruises. But Rust's lifetimes are a genuinely interesting idea that you see nowhere else when people start discussing sophisticated type systems
I've heard bad things about Harper, but then he's an accomplished fellow, which doesn't mean he has to be nice. I only expect him to be truthful, is all. Maybe he's just ML's LISP zealot like the now deceased Dane whose name I forgot.
Harper is nowhere near as bad, fortunately. No F-bombs, for one thing. Harper is opinionated, curmudgeonly and sometimes arguably unfair, but he always backs up his opinions with reasoned arguments. Even when you don't like the way he expresses himself, he always has something insightful to say.
Yeah, when reading Harper it's best to skip over the opinion parts and just read the technical content (which is fortunately plentiful). I always feel as if he's jealous of Haskell's success.
As suspected by hisham_hm, I'm paid to code in Scala.
At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help.
Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala.
IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark.
I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
I don't agree with your Jane Street / money reasoning. I had never heard of Jane Street until I started looking at OCaml. That Jane Street makes money and is "all in" on OCaml does support the idea that one can use OCaml for serious projects. But does anyone really think (even subconsciously) that using OCaml will make them rich, just because?
I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.
Okay I (having done a little Haskell and enough F# to know a higher abstraction was needed) thought that modules were already OCaml's counter to Haskell typeclasses, and they were already better. Some weird set-theory-looking T-shirt (obviously) proved it. So what are modular implicits, and how are they better than modules and typeclasses, why are modules not actually enough anymore as an answer for typeclasses, and are they (please no) related to Scala implicits?
Under the current module system, there is no single polymorphic `to_string` function. You end up with a separate function per type, typically residing in different modules.
In haskell you can just say `show a` as long as `a` is of a type that implements the `Show` typeclass, but OCaml currently has no good answer to this. You end up with `Int.to_string a` or what-have-you. It isn't less powerful, technically, just more verbose.
Modular implicits allow you to define a function `show : (S : sig type t show : t -> string end) -> S.t -> string` and then mark the first argument implicit, so you can call `show a` and the compiler fills in the first argument with the appropriate module for the type of `a`.
There are proofs that this particular feature of typeclasses is impossible to put into OCaml's module system (something to do with functors and type aliasing and not being able to ensure that there is a unique `Show` instance per type), but modular implicits come close.
Modules are strictly more powerful than Haskell type classes (at least, more powerful than naive type classes; there are so many extensions that I'm not sure that is still the case). Modular implicits are described here: http://arxiv.org/pdf/1512.01895.pdf. The main problem with modules as typeclasses is that it's pretty painful to use in practice, and modular implicits fix that, giving a solution quite reminiscent of Haskell type classes. I don't know Scala implicits well enough to comment, but the authors feel their version avoids most of the problems in Scala's implicits (they jokingly refer to it as "a more explicit kind of implicit").
AFAIUI modular implicits don't give you global uniqueness. While this can be "worked around" in some cases[0], it's not really possible in the general case, and global uniqueness is pretty essential for sanity when writing higher-level code[1].
[0] The paper gives set-union as an example.
[1] https://www.youtube.com/watch?v=hIZxTQP1ifo . (Sorry for throwing video at you -- there's probably a write-up somewhere, but I'm in a bit of a rush, and this was the thing that came to mind.)
Now we just need a Haskell compiler which actually bothers to provide the "pretty essential for sanity" for global uniqueness. Currently, I count zero compilers in common use which do.
(EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
Because they never bothered to actually implement the checks to guarantee global uniqueness in GHC?
> (EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
No weird and dangerous extensions in use. Vanilla Haskell.
Orphan warnings tell you that you defined an instance in the wrong place.
Things you don't receive warnings for:
- Defining the same instance twice.
- Having code which uses both instances.
Those two should be hard compiler errors, because they break data structures at runtime and make code behave incorrectly.
Sorry, orphan warnings are multiple magnitudes of escalation levels away from what should happen and are focused on something different (code hygiene vs. THIS-CODE-IS-WRONG-AND-BROKEN-AND-WILL-CORRUPT-SHIT-AT-RUNTIME-I-WILL-FAIL-TO-COMPILE-THIS).
No, forbidding orphan instances is exactly what you need so that both 1) duplicate instances are never defined, and 2) instances written by separate parties never conflict. If you think that should be an error rather than a warning then fine, but in either case code without orphan instances never has breakage due to instance clashes. It's the correct way to solve the problem.
I believe I've understood the issue, but if I've misunderstood then I feel extra need to comment, that my misunderstanding might be clarified.
From my first reading of what you'd written, tome seemed spot on.
On careful re-examination (after reading this comment), I think when you said "Things you don't receive warnings for:" you did not mean to say that you can write that code and receive no warnings (a reasonable interpretation), but that the warnings would not read as directed at the points you raise (also a reasonable interpretation) - which (you note) are substantially more important than "this is generally a good idea."
Firstly, one tends to believe that one understands before one comments even if one actually doesn't, so admonishment to understand before commenting will typically be redundant. Secondly, if one doesn't understand, blame can often lie on both sides of the conversation.
I claim that if you never have orphan instance warnings then your code has "the guarantees Kmett keeps boasting about".
In particular you can never "define the same instance twice", and this of course implies that you cannot "have code which uses both instances".
What exactly is your complaint and why does my claim not address it?
One advantage ML has over Haskell is that it's not opinionated on how one manages effects. How effects are managed in ML is a design decision by a library author, whether that be monadic or eff-style or sprinkling a printf here and there.
I know Standard ML, and yes, it has eager evaluation and modifiable references. I've learned to appreciate lazy evaluation and purity, so those have little value to me. I miss parameterized modules, as Haskell's modules are strictly for namespaces. But I'm pretty clueless on the delta from SML to modern OCaml, so maybe I've missed out on valuable developments.
Interestingly, that's also a disadvantage since you cannot control effects (in the user-supplied code) if you're e.g. writing a library API with callbacks. On the advantage side you have what you mentioned, namely "benign" effects -- but I've found that the "sprinkle a few debug printfs" use case is adequately handled with Debug.Trace... unless you're trying to debug a terminal application! :)
Logging is another popular example of a "benign" effect, but I personally don't think is: I mean, your logging library could be doing all kinds of weird things like shipping logs over TCP to a remote syslog daemon... and I don't want that to be hidden under the rug (using unsafePerformIO or similar) only to blow up later when the network happens to be down.
Anyway, having programmed in O'Caml for 3-4 years, I was won over to Haskell by the compiler-supported (side) effect tracking. I think it's also important to note the distinction between side effects and plain (desired) effects. Not enough people do this in these sorts of discussions.
I'm also a Haskeller, and have been writing OCaml for a few months. Some things I liked include (1) really straightforward imperative programming (2) really straightforward mutable data structures like hash tables (3) module system (sort of like typeclasses but much more expressive) (4) named parameters (5) easy-to-understand/straightforward assembly (6) eager by default
Agree with everything you said, and I'd also add polymorphic variants. I too am a Haskeller now writing mostly Ocaml. I view the two languages as cousins. Both have great features the other doesn't. Both are worth learning and using.
I'm wary of the term "ORM" and in particular the idea that you'd get your SQL defined at compile, which is exactly what something like PGOcaml does, and which is a bad idea if it's the only game in town. As someone who gets to write SQL fairly regularly, I'm a lot more interested in composability than anything else (I'll even trade type safety for composability if I have to pick one).
I'd rather have a system to generate composable queries (hopefully in a typesafe manner) and able to use modern SQL syntax (eg, window functions), without the stuff you typically find in an ORM (identity map, magic setters, etc)
This has always been a big challenge for me with SQL - programmatically composing queries, filters, etc. has been 1. very difficult across the board and 2. very function-oriented rather than data-oriented.
I still hold out hope for a datalog-to-sql layer, someday.
This is something that really bugs me about OCaml in general. There's really no good option to do database access that doesn't involve writing raw, non-composable SQL queries. I don't need a full blown ORM, but something that makes writing type-safe (and injection-resistant) SQL queries like JOOQ would be absolutely amazing. For now I'm just sticking with Python and SQLAlchemy, as much as I love OCaml and F#.
IFF you are using Microsoft SQL Server, sure. Any other RDBMS is a crapshoot, I've been using FsSql which works but I have to devolve into manually manipulating SQL Query strings to do anything sufficiently advanced.
Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).
I'm using PostgreSQL with Entity Framework and running my code on Mono. It all works in production on an AWS Ubuntu instance with DB in RDS. Very happy.
Edit: Forgot to mention that no Visual Studio or Windows is used in the process.
Entity Framework is extremely heavy and not really what I am looking for. I really just want a lightweight layer over SQL that makes query generation safe, not a full blown ORM (think JOOQ, SQLAlchemy).
I use Dapper with F# both on Mono/Linux (test/prod) and on Windows (dev/build/test) and it works great and I've never had an OS porting issue in three years. There are extensions that make it more composable, but haven't needed them yet.
Type safe solutions, in terms of using code expressions that get translated into SQL, exist too. However everywhere I look people complain about how horribly inefficient and frequently buggy the generated SQL is. This is true in LINQ, EF, Scala's SQL generator, etc. Stackoverflow obviously created Dapper for a reason. So I've thus far avoided these "too clever by half" solutions; Dapper is perfectly fine.
I actually also thought that this was a problem so I started trying to build an ORM-ish thing in F#. I havent had that much time to spend on it lately, but its in a pretty OK state as is. If you have any comments or opinions then Im open for all suggestions :) https://github.com/wastaz/hyperboliq
Indeed, it certainly needn't be #1. The recent migration to "micro-orm" such as Dapper (.Net) and Yesql (Clojure), just thin wrappers over ODBC/JDBC shows that ORMs aren't the end-all.
Yes they lack composability and type safety. You could easily add composibility in the guise of something line various existing JsonQL libraries. Type safety, at some point (crossing process/network boundaries) you just have to be pragmatic and let go.
I'm not a big OCaml user, have used it on occasion for a few small projects and I liked it, but from what I remember, I think a few things are missing from this list if OCaml wants to obtain widespread adoption.
1. Really good unicode support
2. A dead simple high quality package manager i.e. bundler, mix, cargo.
I'd also add built-in concurrency primitives i.e. (Channels in Go, Processes in Erlang), though this probably isn't a must have currently, but will surely only become more important as time progresses into the multicore future.
It can be worthwhile to bless a set of libraries. Even if it seems like it can be done unofficially, it helps to have it done "officially", at least, from the point of view of a newcomer to the language. Haskell's getting some mileage out of that sort of thing, lately, starting with the "Haskell Platform" and lately moving into Stack, a blessed set of packages that are maintained in certain snapshot sets and guaranteed to compile together.
Shouldn't #1 be out of the box these days? You'd hope it'd be included in the standard library. Do any of the standard library sets available for OCaml (e.g. Core, Batteries, etc...) have Unicode support?
Yes, but I just think unicode support is so pervasive its not something you should really leave up to a library in 2016. Still this is just my biased opinion as a developer who needs it on virtually every project.
Finally, the title contains "widespread adoption". There is no modern language on the Tiobe Index top 20 without those two characteristics except for possibly MATLAB and C# which both don't have good package managers as far as I know, but I could be wrong since I've never used either one of them.
Anyway, I'd like to see ML get more adoption. I think fixing these things are more fundamentally important than some others such as web frameworks, etc...
I agree with you completely on #1. Without built in support, people screw up Unicode. They either won't use it at all, or they won't use it in all the places it's needed, and by the time it becomes a problem, it's a big problem.
On #2, I disagree. The effort required to make the pull request is a small fraction of the effort required to make a library worth adding to Opam. At the same time, it's enough effort that it should prevent the NPM problem of a million stupid "libraries" for 2 line functions.
I'm in the same boat as a lot of people here, in that I think OCaml looks great except for a few big shortcomings that they've ignored for a long time (unicode, multi-threading, etc.) that end up being deal killers for me. As I put it in another thread a while back, it's not even that I need the missing functionality all the time, it's that they refuse to add any of it for as long as possible.
OCaml 4.03 will have a minimal UChar type and module, that
will allow various Unicode libraries to agree on a common type: https://github.com/ocaml/ocaml/pull/80
According to the author of one of the Unicode libraries that is the only thing the compiler should distribute by default, and I agree with that, otherwise you need everything that comes with Unicode too to make it useful: normalization, segmentation, etc.
If an application needs that it can link with the unicode library, having it separate from the compiler means features and updates can be implemented faster.
A few weeks ago I started learning OCaml via Real World OCaml. However, I became concerned when I discovered that there are multiple competing "standard libraries" and that there are also two different competing async frameworks. It looks like work is being done to ensure that the async frameworks are interoperable, but the existence of various standard libraries is worrisome to me.
In particular, while the one used in RWO (Core) seems very nice, it looks like its use of named parameters is via some kind of syntax extension (edit: not the case; see LeonidasXIV's reply). This seems to be a pretty large difference in approach, and while I can appreciate the reasons behind using named parameters in Core, it makes me worried about writing code that might have to interact across different stdlibs.
As such, I've decided to hold off on learning OCaml for now until resolutions to these community issues can be made more clear. But perhaps I just prefer the Python approach, and that may not be the same objective as those in OCaml.
Edit: Actually, the nail in the coffin was probably when I found a web framework that I wanted to use, but then the author explained why he was removing support for both of the async frameworks and going with only one of them (the one that RWO doesn't use). And then the other main web framework I found also used non-RWO async... :(
I started learning OCaml about a year ago (started with "OCaml from the very beginning" and moved onto "Real World OCaml"). The different extended standard libraries (Batteries and Core) gave me pause too. I'm by no means an active part of the community, but I feel like everything is moving toward Core (and I prefer it to Batteries anyway).
The multiple standard libraries thing also really cooled my enthusiasm last time I investigated the language. They really need to resolve that, or at least explain on their website why a newbie should not be concerned.
> it looks like its use of named parameters is via some kind of syntax extension
No worries, OCaml natively supports named (and optional) parameters. What Core does, though, is reshuffle many function signatures to be more useful when using those parameters.
I suppose you're talking about this[0] blog post, his reasons are pretty clear: hardly anybody uses Async apart from Jane Street, whereas Lwt is much more popular, used by standalone projects, many bindings, as well as Mirage.
The reason RWO used Async is that it is basically a companion to Core and one of the authors of the book is also the author of both Core and Async.
I'm sorry for misunderstanding OCaml's built in support for named/optional params.
The problem with Async is that what seems to be the best resource for learning OCaml in 2016 teaches Async, not Lwt. I was excited to use it until I discovered that many things I was interested in use Lwt instead. It's not hard to learn Lwt, but this discovery made me think about the problems I've had as a professional Perl programmer in dealing with Perl 5's multiple competing event loops.
I can completely understand your worries and I agree that it is rather inconvenient, esp. since Lwt does not have a great introduction to start with.
The upside is that with the hopefully soon upcoming algebraic effects that are supposed to appear in OCaml sooner or later, Lwt and Async might end up being obsoleted or subsumed into a compatible set of Async primitives.
FWIW, the current preferred web server at JS seems to be https://github.com/mirage/ocaml-cohttp (which supports both Async and Lwt). I wouldn't go so far as to call it a framework, though.
I've been using OCaml for system's programming for 6+ years,
and it's better than most other things we've tried. I guess any (mostly) functional language with a static type system based on Hindley-Milner would give the same advantage. This advantage is basically: the compiler acts like a neo nazi and slaps you mercilessly on the head whenever you do something stupid. So in the end, you can often get to the "if it compiles, it works" promised land.
The situation improved drastically over the last years with opam which allows easy installation of most packages.
What's still missing, however is
- decent multi core
- resource management for things other than memory. For example, bigarrays don't cause enough gc pressure, and can therefore leak space. Thus people tend to manage that manually (acquire, release) which is even worse than what a C++ dev can use (unique_ptr)
- decent profiling (yes I can leverage strace and callgrind, but they don't understand lwt)
- decent runtime inspection. (what are all theses values in my heap?)
Maybe not, but a comment like this helps no one. If you know enough to make such a claim then you know enough to show what the problems are, and that would make a much better comment. We'd all learn something.
It might be considered poor form not to spell the problem out, however I honestly think it is crystal clear
But what's interesting is that I was being upvoted until I've rephrased the comment. It used to be "That's an unfortunate comparison you've made". In the same time it sounded more moderate and more personal. I've edited it because moderation came at the cost of authenticity/honesty, and I thought addressing the comment risked automatic rejection of the underlying message on the OC's part. I did think that the actual sentiment could sound worse to others, but it would be hypocritical of me not to have gone with it. The underlying message is precisely "don't conform on account of genuineness".
You should checkout the work that KC has done over in OCaml Labs. Start with his blog [1] — there are things around Multicore, Effects and Profiling in there.
Great write-up. If I could nitpick a bit I would say...
I am on the fence with ORMs. Yes, they make 80% of cases possible, remaining 19% difficult and last 1% sometime impossible.
Having Slick (Scala) and JOOQ (Java) makes code much more transparent, explicit and easy to maintain. Debugging nasty stateful session bugs (oh JPA) can be nightmare.
112 comments
[ 3.1 ms ] story [ 59.0 ms ] threadi love ocaml, i love ml languages, and i think ocaml is a very good ml
but, i think its kinda too late for it, i think people who want to program with types today most likely will go to rust, scala or f#
ocaml is very niche
I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant.
Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption.
Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
Scala "implicits" mean two different things:
1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from.
implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class")
2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance
def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append)
is equivalent to the Haskell
monoidSum :: (Monoid a) => [a] -> a
monoidSum as = foldl' mappend mempty
Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts.
Modular implicits are similar to (and inspired by?) Scala implicit parameters.
The closest I've been able to get is Oasis+OPAM, but it's just not the same.
Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages.
Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done.
So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link.
Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start.
EDIT: The project I was referring to before is Nymote: http://nymote.org/
Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds.
Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful.
I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC.
I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
There is a fun library[0] with a pretty good paper[1] on how to do that in OCaml :-)
[0]: https://github.com/ocamllabs/higher
[1]: https://ocamllabs.github.io/higher/lightweight-higher-kinded...
OCaml has a powerful module system, labeled and optional function parameters, row polymorphism, equirecursive types, and GADTs. Most of these features would be fairly difficult to add to Rust.
OCaml also has a better track record with soundness issues than Rust, and more interesting fragments of the language have been formalized.
... is this what you mean?
I revere Harper, but his anti-Haskell rants just seem unhinged to me.
I've heard bad things about Harper, but then he's an accomplished fellow, which doesn't mean he has to be nice. I only expect him to be truthful, is all. Maybe he's just ML's LISP zealot like the now deceased Dane whose name I forgot.
I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.
At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help.
Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala.
IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark.
I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
In haskell you can just say `show a` as long as `a` is of a type that implements the `Show` typeclass, but OCaml currently has no good answer to this. You end up with `Int.to_string a` or what-have-you. It isn't less powerful, technically, just more verbose.
Modular implicits allow you to define a function `show : (S : sig type t show : t -> string end) -> S.t -> string` and then mark the first argument implicit, so you can call `show a` and the compiler fills in the first argument with the appropriate module for the type of `a`.
There are proofs that this particular feature of typeclasses is impossible to put into OCaml's module system (something to do with functors and type aliasing and not being able to ensure that there is a unique `Show` instance per type), but modular implicits come close.
[0] The paper gives set-union as an example.
[1] https://www.youtube.com/watch?v=hIZxTQP1ifo . (Sorry for throwing video at you -- there's probably a write-up somewhere, but I'm in a bit of a rush, and this was the thing that came to mind.)
Now we just need a Haskell compiler which actually bothers to provide the "pretty essential for sanity" for global uniqueness. Currently, I count zero compilers in common use which do.
(EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
Because they never bothered to actually implement the checks to guarantee global uniqueness in GHC?
> (EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
No weird and dangerous extensions in use. Vanilla Haskell.
Sure they did. Orphan instances are detected by the compiler.
Orphan warnings tell you that you defined an instance in the wrong place.
Things you don't receive warnings for:
Those two should be hard compiler errors, because they break data structures at runtime and make code behave incorrectly.Sorry, orphan warnings are multiple magnitudes of escalation levels away from what should happen and are focused on something different (code hygiene vs. THIS-CODE-IS-WRONG-AND-BROKEN-AND-WILL-CORRUPT-SHIT-AT-RUNTIME-I-WILL-FAIL-TO-COMPILE-THIS).
I believe I've understood the issue, but if I've misunderstood then I feel extra need to comment, that my misunderstanding might be clarified.
From my first reading of what you'd written, tome seemed spot on.
On careful re-examination (after reading this comment), I think when you said "Things you don't receive warnings for:" you did not mean to say that you can write that code and receive no warnings (a reasonable interpretation), but that the warnings would not read as directed at the points you raise (also a reasonable interpretation) - which (you note) are substantially more important than "this is generally a good idea."
I claim that if you never have orphan instance warnings then your code has "the guarantees Kmett keeps boasting about". In particular you can never "define the same instance twice", and this of course implies that you cannot "have code which uses both instances".
What exactly is your complaint and why does my claim not address it?
Overall I'd say that OCaml is more pragmatic.
Logging is another popular example of a "benign" effect, but I personally don't think is: I mean, your logging library could be doing all kinds of weird things like shipping logs over TCP to a remote syslog daemon... and I don't want that to be hidden under the rug (using unsafePerformIO or similar) only to blow up later when the network happens to be down.
Anyway, having programmed in O'Caml for 3-4 years, I was won over to Haskell by the compiler-supported (side) effect tracking. I think it's also important to note the distinction between side effects and plain (desired) effects. Not enough people do this in these sorts of discussions.
I'd rather have a system to generate composable queries (hopefully in a typesafe manner) and able to use modern SQL syntax (eg, window functions), without the stuff you typically find in an ORM (identity map, magic setters, etc)
I still hold out hope for a datalog-to-sql layer, someday.
Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).
Edit: Forgot to mention that no Visual Studio or Windows is used in the process.
Type safe solutions, in terms of using code expressions that get translated into SQL, exist too. However everywhere I look people complain about how horribly inefficient and frequently buggy the generated SQL is. This is true in LINQ, EF, Scala's SQL generator, etc. Stackoverflow obviously created Dapper for a reason. So I've thus far avoided these "too clever by half" solutions; Dapper is perfectly fine.
Yes they lack composability and type safety. You could easily add composibility in the guise of something line various existing JsonQL libraries. Type safety, at some point (crossing process/network boundaries) you just have to be pragmatic and let go.
1. Really good unicode support
2. A dead simple high quality package manager i.e. bundler, mix, cargo.
I'd also add built-in concurrency primitives i.e. (Channels in Go, Processes in Erlang), though this probably isn't a must have currently, but will surely only become more important as time progresses into the multicore future.
It got a lot of attention on Tim Bray's widefinder benchmark:
https://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Result...
Yes, but I just think unicode support is so pervasive its not something you should really leave up to a library in 2016. Still this is just my biased opinion as a developer who needs it on virtually every project.
"2. opam."
see: https://opam.ocaml.org/doc/Packaging.html#Publishing, - basically, I think requiring a PR on github to get a package published is not "dead simple".
Finally, the title contains "widespread adoption". There is no modern language on the Tiobe Index top 20 without those two characteristics except for possibly MATLAB and C# which both don't have good package managers as far as I know, but I could be wrong since I've never used either one of them.
The List: (http://www.tiobe.com/tiobe_index)
Anyway, I'd like to see ML get more adoption. I think fixing these things are more fundamentally important than some others such as web frameworks, etc...
On #2, I disagree. The effort required to make the pull request is a small fraction of the effort required to make a library worth adding to Opam. At the same time, it's enough effort that it should prevent the NPM problem of a million stupid "libraries" for 2 line functions.
I'm in the same boat as a lot of people here, in that I think OCaml looks great except for a few big shortcomings that they've ignored for a long time (unicode, multi-threading, etc.) that end up being deal killers for me. As I put it in another thread a while back, it's not even that I need the missing functionality all the time, it's that they refuse to add any of it for as long as possible.
According to the author of one of the Unicode libraries that is the only thing the compiler should distribute by default, and I agree with that, otherwise you need everything that comes with Unicode too to make it useful: normalization, segmentation, etc. If an application needs that it can link with the unicode library, having it separate from the compiler means features and updates can be implemented faster.
Also see here on how other languages (Python in this example) got it wrong: https://sympa.inria.fr/sympa/arc/caml-list/2014-07/msg00050.... https://sympa.inria.fr/sympa/arc/caml-list/2014-07/msg00054....
The linked introduction to Unicode (for OCaml but not only) is also very informative: http://erratique.ch/software/uucp/doc/Uucp.html#uminimal
In particular, while the one used in RWO (Core) seems very nice, it looks like its use of named parameters is via some kind of syntax extension (edit: not the case; see LeonidasXIV's reply). This seems to be a pretty large difference in approach, and while I can appreciate the reasons behind using named parameters in Core, it makes me worried about writing code that might have to interact across different stdlibs.
As such, I've decided to hold off on learning OCaml for now until resolutions to these community issues can be made more clear. But perhaps I just prefer the Python approach, and that may not be the same objective as those in OCaml.
Edit: Actually, the nail in the coffin was probably when I found a web framework that I wanted to use, but then the author explained why he was removing support for both of the async frameworks and going with only one of them (the one that RWO doesn't use). And then the other main web framework I found also used non-RWO async... :(
No worries, OCaml natively supports named (and optional) parameters. What Core does, though, is reshuffle many function signatures to be more useful when using those parameters.
I suppose you're talking about this[0] blog post, his reasons are pretty clear: hardly anybody uses Async apart from Jane Street, whereas Lwt is much more popular, used by standalone projects, many bindings, as well as Mirage.
The reason RWO used Async is that it is basically a companion to Core and one of the authors of the book is also the author of both Core and Async.
[0]: http://rgrinberg.com/blog/2014/12/11/abandoning-async/
The problem with Async is that what seems to be the best resource for learning OCaml in 2016 teaches Async, not Lwt. I was excited to use it until I discovered that many things I was interested in use Lwt instead. It's not hard to learn Lwt, but this discovery made me think about the problems I've had as a professional Perl programmer in dealing with Perl 5's multiple competing event loops.
The upside is that with the hopefully soon upcoming algebraic effects that are supposed to appear in OCaml sooner or later, Lwt and Async might end up being obsoleted or subsumed into a compatible set of Async primitives.
I, certainly, do not remember one for JS or Node.
The situation improved drastically over the last years with opam which allows easy installation of most packages.
What's still missing, however is
- decent multi core
- resource management for things other than memory. For example, bigarrays don't cause enough gc pressure, and can therefore leak space. Thus people tend to manage that manually (acquire, release) which is even worse than what a C++ dev can use (unique_ptr)
- decent profiling (yes I can leverage strace and callgrind, but they don't understand lwt)
- decent runtime inspection. (what are all theses values in my heap?)
But what's interesting is that I was being upvoted until I've rephrased the comment. It used to be "That's an unfortunate comparison you've made". In the same time it sounded more moderate and more personal. I've edited it because moderation came at the cost of authenticity/honesty, and I thought addressing the comment risked automatic rejection of the underlying message on the OC's part. I did think that the actual sentiment could sound worse to others, but it would be hypocritical of me not to have gone with it. The underlying message is precisely "don't conform on account of genuineness".
Hope this cleared something up after all
https://github.com/openvstorage/alba https://github.com/openvstorage/arakoon/
[1] http://kcsrk.info/blog/
[0]: http://www.meetup.com/sv-ocaml/
I am on the fence with ORMs. Yes, they make 80% of cases possible, remaining 19% difficult and last 1% sometime impossible.
Having Slick (Scala) and JOOQ (Java) makes code much more transparent, explicit and easy to maintain. Debugging nasty stateful session bugs (oh JPA) can be nightmare.