-
The argument I see recently is that while “fruit” is a biological definition, “vegetable” is a culinary one (with no biologically-founded definition of “vegetable”).
In OO terms, you might consider Tomato a subclass of Fruit, implementing the Vegetable interface.
-
And it turns out that “vegetable” is also a legal definition, at least in the US.
-
-
I wonder how applicable this is for Haskell. A nice quote I found in the “Yesod tutorial for newbies:”
Weaknesses of Haskell certainly won’t be technical:
- Hard to grasp Haskell
- Hard to find a Haskell programmer
- The Haskell community is smaller than the community for
/.*/
I would further say that another weakness is that way too many people outside the Haskell community don’t take it seriously. At some point in their career someone tried to explain what Haskell was all about and they interpreted that to mean that Haskell is esoteric and only for academic purposes, or at least it’s a language like Latin, where it improves you as a programmer, but you won’t find yourself writing any real Haskell code.
So this rant ended up way longer than I wanted it to be… But now I have an idea for yet-another-blog-post-that-I-will-never-finish.
TL;DR The point I wanted to make is that this article seems to try to point out that immutability and functional thinking is easier than mutable and procedural thinking. I’m curious as to how well you can point this out for Haskell, but I think too many people see the type system and everything else to do with it as scary and complex.
-
Actually finding developers for Haskell teams isn’t super difficult, based on personal experience. In fact it might be easier than for most other ecosystems, and could be considered an advantage rather than a weakness. We’ve been hiring folks to work in our mix of Clojure + Haskell stack for the past half year and it’s been pretty reasonable.
There are considerably fewer Haskell gigs out there than there are developers either familiar with Haskell or very willing to learn it asap. Many people would love to upgrade to working in the language, but cannot because their current full-time gigs will never move off of Java / Ruby / Python or whatever else they’re using. Most folks that apply for Haskell jobs are amateurs who haven’t used it in production before but would really want to, it’s again a reflection of the dearth of Haskell teams out there. Veeeeery rarely you get people with professional experience in it, but I’m confident this will slowly go up in the coming years.
It’s clearly hard to find amazing Haskell developers, but that’s true for ecosystems out there.
On an unrelated note: “Think less” is hardly applicable to Clojure. You can’t develop anything sizeable without having to use your brain as a 3rd party compiler to continuously keep track of what kind of types you’re passing around since they’re never explicitly called out in the code. Writing Clojure code at scale is actually quite high-effort compared to a few alternatives out there. Yes yes you can use schema / clojure.typed.
-
Haskell is a language I’d really like to work more with, but I always find myself struggling to get started with any project beyond fizzbuzz. I think that’s one of the things that pulled me to Clojure; I’d heard of and tried Haskell first, but jumping out of the gate with algebraic types and monads to make IO and state possible while enforcing purity, plus the symbol-heavy syntax, all while I was just learning to embrace immutable data structures and pure-functional programming for the first time, was just too much for me.
Clojure – as soon as I figured out to just use leiningen, that is – has the latter two, but the syntax and related concepts are markedly simpler. I built my first app without major problems, and here I am a few years later.
This doesn’t make Clojure better, by the way; in terms of writing stable, fast, “provably” correct software, I don’t think anything has Haskell and its ML brothers beat. Perhaps the difference can be illustrated by my first Clojure app: it was janky and did a lot of stateful and un-idiomatic things, but it still worked, dammit! Of course, my Clojure code is much better now, but if I hadn’t been able to write bad Clojure code and still make it go, Clojure probably would have ended up in the “someday” pile next to Haskell and I’d be writing Go or Rust or something (god forbid!).
-
It’s true, for a lot of us Clojure was actually a gateway drug towards Haskell. I started there, @bitemyapp was also big in the community before moving on. My guys typically start on Clojure (in big part because we have a lot of legacy code written in it) and then eventually transition to Haskell, being able to reuse a huge subset of concepts, layering a lot of new ones on top. I haven’t tried putting someone straight in front of Haskell just yet, not for any particular reason, but that’d be an interesting experience. I’m getting closer to the point where I can decently teach someone how it works, whereas a few months ago I would have had a lot more trouble with it.
And yes, I think it’s reasonable to say that both Haskell the language and its current type system are more complex upfront than Clojure’s. You have to think much beyond maps, sets, lists and vecs, you have to deal with uncompromising purity and having to grok weaving monads before you can do anything really interesting. You save time and complexity over the long term, but it’s more to absorb when just starting out.
Btw Adam, we still heavily use your err->> monad macro at Front Row <3
-
-
Hi! I came to Haskell from Clojure. I had trouble too!
This is my guide for learning Haskell. It can get you where to need to be in order to write real stuff in Haskell, but you have to do the exercises.
Ping me if you need help, there’s also an IRC channel devoted to people learning to become productive in Haskell on Freenode at #haskell-beginners.
Btw thanks for your posts and tutorials for Clojure, they helped me a lot back in the day. :)
-
-
http://howistart.org/posts/haskell/1 (quick taste of a haskell project)
http://www.seas.upenn.edu/%7Ecis194/spring13/index.html (comprehensive in theory and application)
https://github.com/bitemyapp/learnhaskell (source of the above and where to go after)
http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter/ (great intro to testing and nice tool to use)
http://www.amazon.com/Beginning-Haskell-Alejandro-Serrano-Mena/dp/1430262508/ (In depth about lazy evaluation, basics, exposure to popular libraries, and more… everything you could want)
After getting past those, hopefully you’ve written substantial code. My first big project was 1000 lines of Haskell code in continuation passing style. Despite that, it was very nice to work with because of Haskell’s other pluses.
I saw this video a short time ago: http://vimeo.com/73648150
After watching the above (and consulting the Haskell wikibook) replaced it with a 224 line State Monad Transformer and then the actual application was about 150 lines.
Have fun, and please provide feedback!
-
-
-
And in Clojure: http://adambard.com/blog/a-clojure-url-shortener-service/
I tried OCaml for a bit but the weirdness got to me after awhile. There was a ton of magic around project setup and compilation that I didn’t understand and couldn’t find properly explained, and the fact there is more than one “standard” library bugged the heck out of me. I’m hoping that once the Linux story solidifies a bit more around .NET I’ll be able to reasonably give F# a shot.
I’ve been using F# on Linux for a few years now using Mono. It’s a bit more manual than .NET Core, but it’s stable.
If you’re interested in trying again, I created a build system (yes, yet another one) specifically designed for getting going fast in most cases. I have a blog post here:
http://blog.appliedcompscilab.com/2016-Q4/index.html
Short version: all you need is a
pds.confwhich is in TOML so fairly straight forward, a specific directory structure (src/<project>) and GNU Make. Then you runpds && make -f pds.mkand you’re done. Supports tests as well as debug builds.I’m not sure it is worth pushing yet another build system that seemingly nobody uses (at least I haven’t yet run across a package which uses it) when jbuilder seems to be gaining so much momentum in the OCaml world lately.
Maybe, but pds is pretty easy to port away from for most builds and it’s so trivial to get started and much less confusing than jbuilder’s config, IMO. My personal view is that jbuilder is a mistake but I’ll wait to switch over to it once it’s gained enough momentum. At that point, I can just switch pds over to producing jbuilder configs instead. But I’m a symptom of the problem rather than the solution unfortunately. I also use @c-cube’s containers, so yet another stdlib replacement/extension :)
Could you elaborate on why? IMO jbuilder is not perfect either but if we get a modern, documented build system which is hopefully easy to setup, it would be a massive win over all the other solutions we currently use.
I agree, the different choices in tooling is sort of disorienting and it can lead to analysis-paralysis. For a toy compiler project I started working on, I tried to find the most basic tooling that would work: whatever ocaml compiler came with my distro, ocamlbuild, make, and then eventually, extlib, ocpindent, and then after some more time, opam, ocamlfind, utop. It may make sense to use the tooling outlined in this article if future maintainability is a big concern, but to get started and to learn ocaml, I don’t find it necessary (and definitely not appealing). Having done this, I don’t pine so much for standardization (;
There’s more than one standard library in a lot of languages, though. Why does that bother you?
It bothers me because it makes the language more difficult to learn. It also wasn’t always clear to me that an alternative was in use because, IIRC, they’re not (always) clearly namespaced. I have run into this in Haskell as well, FWIW.
Typically it’s visible when you use an alternative stdlib because you start your files with
open Batteriesoropen Coreoropen Containers. I agree it’s annoying that the stdlib is not richer, and it’s a bit slow to accept contributions, but in a way the existence of alternative stdlibs/extensions shows how easy it is to roll your own :-)You can’t have two standards, that’s a double standard!
Which languages?
Haskell, C, and D come to mind. You could also argue that Python has multiple standard libraries because it has different implementations that effectively can’t use some aspects of the normal stdlib (PyPy). Then there’s Java: SE, EE, and ME are the same language with different sets of functionality in the standard libraries.
Out of curiosity, have you tried OP’s project setup?
Also, there is only one OCaml standard library–the one that comes bundled with OCaml. The other ‘standard libraries’, Batteries Jane Street’s Core, are optional add-ons made for specific purposes.
I haven’t tried OP’s setup, but honestly it seems even worse than what I had. I pretty much followed this: https://ocaml.org/learn/tutorials/get_up_and_running.html. I ended up using Oasis, which was just awful, every time I added a file or dependency I had to fiddle with the config until everything would build again, but at least there wasn’t an entirely separate language.
From OP:
Note the comment, “as far as I can tell”. To me, that’s a terrible sign. A person who has gone to a reasonable amount of effort to explain how to set up a project can’t even figure out the tooling completely.
Jbuilder is quite nicely documented (see http://jbuilder.readthedocs.io/en/latest/). The public_name defines the name of the produced executable in the install context. It does not take much effort to read it from there
Of course you still have to find out that Jbuilder exists, which the official site doesn’t seem to mention… I am lazy, I don’t like choices, I just want one, blessed tool that works more or less out-of-the-box if you follow a set of relatively simple rules (I’m even OK with wrapping the tool in a simple, handwritten Makefile, which is what I do in Go). I’m not arrogant enough to think that the way I prefer is the “right” way, in fact in some cases it would be dead wrong (like for extremely complex, multi-language software projects), but that explains why I dropped OCaml for hobby stuff.
OK, but your criticism is that you have to find out that JBuilder exists, commenting on a post that tells you about JBuilder.
To be fair, jbuilder is very young (not even 1.0 yet actually) but it might become the “standard” build tool the OCaml community has been waiting for for years (decades?). Then clearly there will be more doc and pointers towards it.
Well obviously I know about it now, but it still isn’t terribly discoverable for someone new to the language. My actual point, and I probably didn’t make this as clear as I should have, sorry, is that in my experience OCaml isn’t very friendly to beginners, in part because its tooling story is kind of weak and fragmented.
Yeah. This is true. Especially on Windows. People are working on it but it’s slow and it’s taking time to consolidate all the disparate efforts. I myself am not getting terribly excited about OCaml native but funnily enough I am about BuckleScript (OCaml->JS compiler) because of its easy setup (
npm i -g bs-platform) and incredible interop story.Others are getting equally into ReasonML ( https://reasonml.github.io/ )because it’s coming from a single source (Facebook) is starting to build a compelling tooling/documentation story.
I didn’t know about either of these, thanks!
OP here: I didn’t really make any effort to pursue documentation re: the public_name field, and I have really almost no production experience with OCaml whatsoever. I certainly have complaints about OCaml’s tooling, but I can assure you that any argument against it appealing to my authority is certainly flawed.
I wasn’t really appealing to your authority, in fact kind of the opposite. I don’t like using systems that converge to copy-paste magic, and that seems to be what you did, and is likely what I would do. I don’t want to use a weird programming language to configure my project, I want something simple, with happy defaults, that can be understood easily.
I guess I generally prefer convention over configuration in this case, and that doesn’t seem to be what the OCaml community values, which is why I gave up on it. I’m not saying anyone is right or wrong, it’s just not a good fit for me, particularly for hobby projects.