I’ll add that OCaml’s guiding light has never been ergonomics and you can feel it when you use it.
Tons of the features that make Haskell compilation slower (solved by using ghcid, by the way, for anyone who hasn’t used Haskell ever / in a long time) are there to make your development better. Even the simple things like free ordering of definitions, partial application of type constructors without extra libs, top-level pattern matching, etc.. It’s death by a thousand cuts even before you get to inevitably missing typeclasses and other big features.
As a general comment on a lot of things in threads like these that toss around “practical” and “pragmatic”:
It’s an interesting sort of accepted way to argue in favor of less rigorous methods and languages. Some would argue that having more static verification is more practical and pragmatic, but these words are almost always used as “Well, those are not the bugs that happen in my code [read: that I remember]”. My reality looks a lot different. There’s very little that’s practical about not having more static guarantees and I miss it everywhere I don’t have it.
It’s a matter of degree too. When I saw what people could do with dependent types I wanted them immediately. So I tried Idris and just didn’t get how to use them. I later tried again and got just a little bit closer to getting it. I’m not “with it” enough to sit down and think in dependent types, but I definitely want to be and I definitely will be. Because it just adds more static guarantees, even on the value level (by proxy of being able to have the value level in the type level).
Let’s face it: Humans are the best at programming but still extremely bad at it. This puts us in the position that we pretty much have to do it, because even while we’re terrible at it we still don’t have good stand-ins that can take our place. Having the machines help us along the way seems the most sensible way forward to me.
@gon782 I recently came across the following talk:
which was very interesting, since it brings up some important points about the Haskell development environment that could be improved;
some quick examples being:
The learning cliff.
There are too many libraries, so it is difficult to find good/maintained libraries that do what you want between the cruft.
The Haskell community is divided about a couple of core issues, such as if it is better to manage your dependencies (and even ‘how to install Haskell’) using Cabal or Stack.
Some libraries make odd choices of when to use partial functions, and when this inevitably does bring down your application, the error messages are extremely cryptic and there usually isn’t a stacktrace at all.
Besides this, the talk also talks about web-development-specific things, where their team had issues changing their Rails-mindset to a Haskell one. (And even though it has been a year, in my personal opinion, some of that Rails mindset still shines through in what they attempt to do in Haskell, but most of their points are very valid and definitely interesting to hear).
I really like what you’ve written in your latest post, by the way. I couldn’t have said it better .
I like the talk and I can’t claim to have gone through the same thing as they have in terms of scale at all. DB stuff in particular I think is something I feel spoiled with in terms of Ecto.
While there are things I dislike about Haskell the language (records, etc.) they’re fairly few, because I think as a language there really isn’t a general purpose one that can rival it. The real issue is that I’ve always felt that I needed a Haskell mentor that could answer all of these peripheral questions (many of which are brought up in the talk). There’s only one other language I can think of where a mentor is essentially required because you have to really be one with the zeitgeist/community/current best choice and it’s C++.
I’ve found posts like this one really good:
To some extent it’s about someone making a choice for you and letting you move forward and you trusting that that choice is good enough. In certain areas we might only have bad choices and that’s another issue, but often there will be a best choice somewhere and without someone to tell you you’re just fumbling in the dark.
One of the reasons I want a Haskell job is because I want a Haskell senior to tell me all of these things so that I, as a “Haskell for fun” user can unlock all of these secrets I imagine are out there. In contrast, I learned Elixir pretty much on my own and have managed to find my way into a very productive situation both in terms of output and financials (granted, this is really a function of the contact network I established from working with Erlang).
So yeah, I agree that there are issues, but they’re not usually about the language. That makes it almost infinitely more frustrating, because you know that they’re avoidable and solvable, yet they remain. The divide between cabal (+ nix…) and stack is perhaps the most obvious one because it hits you the moment you decide to start (and also come back if you’ve been away for a while). It has much bigger consequences than you’d imagine at first as well because there are things that plain just won’t work for one or the other.
Edit: A special note about the editor integration, etc.:
A while ago I stopped using HIE and went back to basics: I started using onlyghcid (+ a separate ghci process) and Hole Driven Development (this video shows basically zero initial knowledge with holes driving the implementation entirely, which you’d rarely actually do, though it shows the power of it as a guide and the experience of doing it, as mentioned in the video, is actually better now). The compiler can answer a lot of questions for you and the dev cycle you get with ghcid telling you stuff like this on save gets you extremely far.
If you feel like it, you can use ghcid together with editors to have them display the same information in-editor, but I’ve found that I just really never run GhcidStart in neovim anymore.
This becomes even better with valid function suggestions for holes, with which you’ll get actual suggestions for functions to use based on the type of the hole. This’ll increase the discoverability of library functions a lot and it’s something GHC provides on its own, so it’s usable from the most basic tooling.
A type being able to fullfill interfaces is not part of typeclasses but rather part of witness collapsing (remember that typeclasses are just less powerful witnesses), which conceptually it’s like passing the same thing into multiple arguments of the different types, thus that can still be emulated in Elm.
You ‘can’ still do witnesses in Elm, not as succinct as in other languages, but it is still entirely doable, so you can still get typeclass functionality, just with more writing.
Yep, that vtable ‘is’ an incarnation of the global witness table, though optimally in a full witness system (the way OCaml does it) the global witness table would not exist and all calls would be statically known with no virtual lookups needed. You can still ‘bake’ a global witness table in OCaml if absolutely necessary, both the module system or the object system can be used for that (or GADT’s if you know all types ahead of time).
+1 I don’t get Elm’s reluctance to add exceedingly useful QoL things, it reminds me of Go, trying to be as low level as possible, which just makes both easy to use, but very very boring and hard to read and brittle (in logic).
Indeed! OCaml tries to be as pure as erlang, which is to say purity where it matters and dropping it (but safely) to let you get ‘real work done efficiently’.
It’s designed to be unambiguous and easy to parse, of which it is, there are never any questions of what a construct is at any point, unlike haskell and elixir and so forth.
OCaml supports this with interfaces fine, it’s just not default because OCaml rely’s on ordering of commands allowing for overriding the visibility of prior ones, thus allowing you to something like having a module extend another module and change and/or add functionality to it (or remove it), which is not something you can in Haskell, and this has fantastic boons for keeping code short and reuseable.
That’s because haskell generates functions for the heads, which pollutes the function namespace. I prefer OCaml’s style of opt-in function generation by far, especially as I don’t use it most of the time (which means I can make head names be far more generic and readable).
Uh, doesn’t OCaml have quite a lot of pattern matching? A common test would be something like this (at the top level):
let 4 = 2 + 2 (* Test that addition works as expect *)
You can even destructure, match, even include guards and all via the match or function calls:
let blah = function
| 1 -> "One"
| 2 -> "Nope"
| x when x<0 -> "ACK! Too low! But I have a guard!"
| _ -> "Higher positive"
(* match is identical syntax except you pass in the initial value like `match value with ...` *)
So I’m not seeing these, at all… I find that I’m as productive in OCaml as I am in Python in terms of languages (and indeed even many libraries, except all type safe), and I definitely would not be able to say that about haskell. I am curious where you got the above thoughts though as they seem to lack the reasoning on the other side as to ‘why’ those decisions where made (for example, OCaml doesn’t include typeclasses just because they don’t, but rather because it has a significantly more powerful capability that is slightly more verbose, but even the verbosity will vanish once a PR is finished up), or just outright wrong (like matching, a big thing about OCaml is destructuring matching with guards, ala Erlang/Elixir).
No, I think I’m fairly certain why most of the QoL things that aren’t in ocaml are missing and I even gave one of those in the post.
You mean the thing that never ever ships, just like multicore? It’s the Duke Nuke’em of language features at this point.
I like ocaml and I understand what it’s doing, I’ve even praised the singular dedication they’ve shown in never implementing anything that doesn’t fit into those ideas, but it just isn’t as concerned with QoL as I’d like it to be.
About top-level pattern matching, it’s a nitpick but I’d just prefer split clauses with pattern matching right on the parameters. I didn’t use to but I just think it’s unnecessary to not have it at this point.
I’ll reiterate what I’ve said elsewhere: I think OCaml is about as much power as you can get with the least amount of tools, because when stuff is added it fits extremely well. I’d just rather they lowered the power-to-feature ratio in favor of comfort a bit. But it’s not in their philosophy to do that and that’s fine. We still use OCaml for some of our projects and I’m very happy about it because it beats Javascript by heaps.
Except they aren’t missing. OCaml has overriding in lieu of free ordering, or just use and instead of let at all top level definitions except the first, then you get free ordering, Haskell’s definitions are like they are in an implicit and chain without any way to break out. OCaml doesn’t like to pollute the function namespace as it then makes ‘return’ type deduction not what one would expect, unlike what Haskell does (I.E. it is opt-in). And OCaml very much has pattern matching that is near the power of erlang, I’m not actually sure that haskell even has the capability of guards on pattern matching?
Not in mainline but they are in branches. Unlike Haskell that likes to break things on every-singly-version, OCaml actually takes backwards compatibility seriously, thus they don’t just immediately toss in everything that is handed them but rather test it extensively, including with existing code-bases to make sure no prior issues, and that it will properly cover all issues that it is intended to cover into the unbounded future, which is very much unlike Haskell that has 40 ways of doing things, 3 string types just in core alone, and kludge upon kludge upon kludge just to get it’s type system working.
They are very concerned with QoL, not just with immediate usage but also with maintainability and for people to not worry that their code will just outright break on later versions, unlike Haskell.
A PPX can change that, but that seems like a lot of needless verbosity when just a simple | indicates a new head on the same function, nicely readable and perfectly consistent with match expressions, unlike haskell that uses entirely different syntax between it’s function heads and case.
I’m curious how it is considered ‘least amount of tools’. Everything you can do with Functors and modules you can do via flat record packing/unpacking (and a whole TON more verbosity), you get the completely fluff row-typing via objects (which are just row-typed records), you have polymorphic variants (also entirely fluff on a normal more-verbose tag system), among a great deal more. OCaml is designed for ease of use and ease of reading (where haskell often looks like line noise and runs slower to boot…). No surprise slow lazy calls (instead it’s opt-in via lazy, thus only where you need it, instead Haskell is opt-out), it compiles significantly faster, has a single package manager system, doesn’t have an ambiguous syntax that relies on whitespace to try to disambiguate (and haskell still fails at times) that makes copying code actually sensible, has the ability to extend modules, etc… etc…
However yes, OCaml’s parallel work sucks, the python model is not acceptable, but then again OCaml usually replaces my Python work, it doesn’t replace my erlang/elixir or C++/Rust work. Use the right language in the right place and all. Haskell does have some cool concurrency models, but then again it is a move fast and break things language. And it’s not like OCaml is standing still, the current work is focusing on getting windows to be a first-class citizen, which is no small undertaking.
It’s just that I also prefer, if ever so slightly, to be able to do this:
update model (ServerMsg msg) = handleServerMessage model msg
update model (ClientMsg msg) = handleClientMessage model msg
instead of this
let update model = function
| Server_msg msg -> handle_server_message model msg
| Client_msg msg -> handle_client_message model msg
Much like the picture you’re painting is an exaggeration I’ll say at least Haskell got new features since the millenium. For real, though, I don’t really see where you’re going with this as breaking changes haven’t been something I’ve taken note of in Haskell. If you mean new language features changing things they’re exclusively in language extensions (which OCaml should probably adopt, by the way, so new features can actually enter the language instead of languishing in repositories for 4+ years).
Modular implicits have been coming Soon™ for like 2-3 years. If ergonomics/QoL was a serious priority they’d have been out long ago, but I guess the safest way to ensure no breakage is to literally never actually release the feature.
Text & ByteString aren’t in core, they’re just packages. That’s either worse or better depending on who you ask, I suppose. If you were to say it’s confusing for newbies, yeah, it’s currently what half of this thread is about at the moment, but luckily these have “best practices” now. If it’s text, just use Text, if it’s binary data that’s not meant to be treated as text, just use ByteString.
… once the compiler has gotten its pound of flesh and something has absolutely no performance hit whatsoever?
Jokes aside I’m not even saying OCaml is somehow much worse than every other language. All things considered it’s probably in my top 5 languages, maybe even top 3. It’s just that you inevitably feel like you’ve gone back in time for a bit, in my opinion.
All in all I just can’t really agree with you that it seems they’ve ever really considered ergonomics and putting the programmer first in almost any choice. I love the features they have put in, but at some point it must’ve been like obviously useful things like ad-hoc polymorphism just weren’t prioritized highly enough. At this rate Haskell will likely implement dependent types before modular implicits are released for OCaml. That’s all work done by, as far as I know, one person and that’s to take the language into the future, not just catch up.
I actually prefer the latter, even putting a case inside a def in elixir at times, it makes it obvious they all belong together, heads of the same function, unlike the above and normal elixir/erlang styles where you can’t always tell they are the same head without mentally parsing the name and arguments of the function itself. I.E. it makes it contextually obvious without needing to do mental work, which is a huge boon when scanning through code quickly.
OCaml core is pretty easy about taking in new features as long as there is sufficient tests done, pretty stringent on that. In Haskell I’m speaking more of old code breaking, not new features.
Modular implicits are a fairly small thing overall, they save you from typing a single word each on a witness patterned function call, not a huge boon, though a nice QoL mostly on witness based operators (I tend to go for piping though).
Most of my Haskell work ended ~5 years ago, so I havn’t kept up much after that except the occasional compiling and updating/fixing of something that broke from new versions of ghc. Still though it’s massive amount of type extensions hasn’t gotten any better by far, nor its compiling speed (still rivals that of C++, especially templatees when HKT’s are used in Haskell).
Ooo? They have an actual setup for dependent types coming out? I’d actually like to read on that a bit. I’ve tried implementing dependent typing a few times in languages I’ve made but all the corner cases start driving me crazy and idris is not quite mentally parseable… ^.^;
Overall though, I still prefer languages that are slow on taking in features when the features are well designed. Take C++, I waited 12 years for C++11 to come out just to give me something as trivial as auto, even though I could 90% of the way there with template magic and certain design patterns, auto was just so trivial for the compiler as it already had that information, but it still took 12 years to get it. OCaml seems like it moves very fast to me compared to what I’m used to. ^.^;
There’s been a lot of progress and from the latest status update I think Richard Eisenberg said that he’s hopeful for actual dependent types in GHC in 2019, but there’s no telling if I’m up to date on that at all.
In the case of Elixir the language itself and the tooling is dead simple, but the runtime and ecosystem of BEAM is very complex, and there’s a lot of compile time complexity.
Ocaml has a very small runtime and is dead easy to parse, In terms of code reusability if you abuse the sh*t out of functors even though it’s not all that great appearance wise and adds a lot of complexity compared to say type classes to the application developer, MLI files make code reviews and documentation easy.
As for it’s concurrency story, honestly its story there shouldn’t be compared to Python, like Lwt + libevent or uwt is actually more performant than NodeJS, and nobody talks about Node’s GIL.
I’m going to use the aformentioned excuses that the the Python people do but honestly I just find it hypocritical because nobody says this about Node.
Honestly the main case where Ocaml is actually as bad as people think in a multicore world, is like when you have a shared state bottleneck where you’re using a mutex and there are a lot of writes that actually take a long time to do, and Node is in the same boat.
If we’re talking C10K it’s on par with node and when it comes to data parallel stuff, using fork it’s comparable to Go.
Don’t even get me started on how great Mirage is in a parallel world, since like you’re just spawning a bajillion tiny unikernels that only use the resources it needs.
is just a PITA because you are constantly reinventing the wheel and like there isn’t a lot of documentation in the cooler projects, like you’re expected to just mess around with it and read the MLI files and maybe send a message on the forum or email the maintainer.
Multicore is usab
TL;DR: Elixir is simpler le now for the most part apart from a handful of backwards compatability bugs, that have improved rapidly, like the only thing that holds back widespread use is lack of documentation, the fact that it’s targeted towards people who know how to and really want to implement schedulers.
Modular Implicits can be used it just hasn’t been integrated as part of the main version of the language, mostly because the community is like screw that I’ll just use ppx rewriters for the time saving parts, or I’ll use the record system, or first class modules to imitate x aspect of typeclasses I want, and honestly prefer the modularity over the conveniences of type classes.
Ocaml’s problem isn’t a lack of performance or language features, the community is dominated by less than a 100 systems hackers or compiler nerds, who don’t mind reinventing the wheel, its weakness is the lack of empathy to normal application programmers who don’t want to read a lot of code they aren’t writing, contribute to a handful of open source projects, and have their GitHub full of tiny libraries that maybe 10 people use, and implement a truckload of common algorithms .
Erlang has a similar story but like it makes things so very easy to build cool ****.
.