Haskell’s great. It isn’t hype. If anything, there’s “an embarrassment of riches” when it comes to the library ecosystem. I’m still figuring out the web frameworks (Yesod, Snap, Scotty) and which to invest in.
I know of about 20 companies that have gone the Haskell route and none have regretted it. Of them, only one ended up moving away from Haskell and it was toward F# because they wanted to be on the .NET platform (it was a financial firm whose traders used Excel pretty heavily). It wasn’t about regret, just specific convenience.
I’m investigating Haskell for a mid-size Chicago company and I’m finding the language to be a joy to work with. It has all the things I liked about Clojure, but a type system that gives me confidence in ramping up to a larger team, which I wouldn’t have as much of with a dynamic language.
Though, the types do pay off long before an add'l human is entered into the equation.
I don’t like salesmanship for PL. I’d rather languages be able to stand on their own merits. If your ROI curve is beyond the horizon, then it’s hard to know. I’ve chosen to focus on making Haskell sufficiently straightforward to learn that they can kick the tires and see what people mean. That’s likely going to be more convincing than burning peoples' credulity up before they’ve fired GHCi up with what, they can only assume, are outlandish claims.
I’ll probably get downvoted for this, but – it’s not because Haskell is that good. It’s because everything else is that backwards. The road doesn’t end with Haskell. PL researchers haven’t been asleep at the wheel even if industry has. More stuff in the pipe to keep us busy for the next few decades.
But as a 9-5 programmer? It’s great. I use Haskell at work. I’m extremely happy that I do. And you know what? There are still messes. They aren’t Haskell’s fault, but Haskell means that for my small team they’re still tractable and it eliminates a lot of additional risk & pain. I’ve flipped multiple companies over to Haskell (contracting and amateur) and they’re all happy customers too. I didn’t flip those companies by pitching the fuck out of Haskell, I did it by having acquired enough credibility with them that they were prepared to investigate and evaluate Haskell themselves. Only in one case did I teach them anything and that poor CTO got the worst Haskell tutorials I’ve ever given. The tutorials were bad because I hadn’t taught many people Haskell to any real depth. Two years later, that has since changed. Despite my terrible tutorials, the CTO kept with it because Haskell was doing the sales, not me.
I propose we skip the sales pitches that turn reasonable-minded people off (isn’t that who we want in our community?) and instead consider this way of putting it:
“It’s not perfect, but we think if you check this cool thing out and plumb its depths properly, you’ll have discovered something really cool that you’ll want to use in your work or personal projects. I’m here if you want to ask questions or get details.”
I think that’s going to get things off on the right foot more often than over-eager marketing pitches.
An anecdote: I work in a coworking space. I heard a marketing dude make an outlandish claim about AI. Something to the effect of, “My company is the only provider of True AI™ in the market today”.
Now, given what I’d just heard, I can arrive at one of three conclusions:
He’s incompetent and doesn’t know anything about AI. His claim is overreaching but the engineering might be sound.
The engineering isn’t sound and he’s lying to cover for this.
The engineering is sound but not spectacular and he’s lying because he’s a marketer/salesperson. This isn’t really better than the other possibilities because the main thing I need to know about a product or tool is its limitations. Limitations requires more depth of experience than benefits so it’s best if you can trust your vendor. Cf. databases
They’ve actually invented AI but their team is so utterly disconnected from the research community that they haven’t published and so incompetent at business that they’re pitching their thing at a coworking space in Austin, TX.
Maybe there are more gracious conclusions I could’ve arrived at, but the real take-away?
I didn’t bother to ask him to elaborate. I got tea and left.
How many people are getting their tea and leaving because a tool that had a lot of value to offer was oversold?
Apologies for the wall of text. Back to writing about Monoids.
Yes, very much, to all of this. Especially to the analogy.
I wrote something here a while ago, complaining about this from the other direction: Why does everyone complain about monads being difficult to understand, despite the general consensus among experienced Haskellers that monads aren’t especially important for newcomers to learn anytime soon?
Because the hype that got people interested in Haskell in the first place mentioned monads prominently.
I would appreciate if people would stop doing that. :)
Yes! This stuff agonizes me. Getting people to stop fetishizing monads (as if they could be learnt without knowing the language) is a regular chore of mine.
Yes, you’ll learn them later. No, it doesn’t matter right now. You can cargo-cult the do-syntax and figure it out later. Monad analogies do more damage than temporarily ignoring what do syntax does under the hood. Trying to dive straight into Monad when you don’t know anything about Haskell has burnt so many people out unnecessarily. It’s a terrible unforced error to make in teaching people something.
The mere idea of a single article monad tutorial with no prerequisites isn’t well-founded and should be avoided if at all possible.
Funny story, I know a mathematician that uses Haskell and she’s never once used Monads (unless you count GHCi’s implicit IO + do loop) because it’s never been relevant for her work :)
In my tutorials I always explicitly tell people to not care about Monads, it’s just a mathematical concept and set of rules that aren’t really relevant to your day-to-day programming. I think because Haskell people tend to be the type of people who wants to understand things and learn things deeply, we tend to teach that way as well.
However, a Node.js programmer doesn’t care about how the Event Loop works even if they use it every day. A JS developer wanting to learn promises doesn’t go and learn how they work and what their computer science fundamentals are, they just look at the tutorial on how to use them.
So when I teach Haskell I teach people how to use Maybe, how to manage state in their application and how to do IO. You never need to know the underlying principles, and when people are comfortable with using things, they typically 1) learn the underlying principles much easier and 2) do so from their own interest instead of being told that this is something they should learn.
You never need to know the underlying principles, and when people are comfortable with using things, they typically 1) learn the underlying principles much easier and 2) do so from their own interest instead of being told that this is something they should learn.
Yeah, this is something I’ve noticed with some of the more mathematically minded folk that haven’t taught much. They think learners can work backwards from formal definitions to application…which is bonkers. If you have a means of kicking around Haskell (with help), then you can probably ignore Monad, but we focus on simply trying to do a good job of teaching the concepts in our book.
Rather just slay the dragon, ya know?
I completely agree with all of what you are saying, and this post was actually my attempt to highlight how, despite our built up technical debt and focus on things not-haskell, Haskell worked out for us. I was hoping it would be more of an anecdotal story than a pitch, perhaps I failed in my mission and it sounds like a pitch? Would love feedback on how to improve the story-telling so it isn’t a pitch.
That said, this:
is unfortunately sometimes not enough because the people you are trying to convince (sometimes) are not programmers. They care about things like what monetary benefits it brings, how easy is it to hire, will it scare off any potential acquirers? How does one convey that without making it sound like an outlandish pitch? I can provide examples for all of those things but the response is always the same “so why isn’t everyone using this if what you’re saying is true?”
I was hoping it would be more of an anecdotal story than a pitch, perhaps I failed in my mission and it sounds like a pitch?
No no, you’re fine! My comment is not a reply to your post.
is unfortunately sometimes not enough because the people you are trying to convince (sometimes) are not programmers.
Yeah, I was talking about technical people that have a tendency to be a bit skeptical. Management, IME, been either very receptive or very unreceptive to Haskell. This often depends on whether they have a growth mindset.
How does one convey that without making it sound like an outlandish pitch? I can provide examples for all of those things but the response is always the same “so why isn’t everyone using this if what you’re saying is true?”
There’s a (game theoretic?) answer to this – if it were easy/cost-free, everybody would be using it. Pretty much by definition, if there’s an advantage/benefit to something and it costs nothing then it would be wide spread. You could talk about it terms of a technical “moat” similar to the PG essay. Or in terms of Moneyball, but that sort of pitch will make programmers grumpy if they hear you make it. I took a (temporary) salary cut to be able to use and teach Haskell in my work, so I’m sanguine about it :)
My comment was more of a “simma-down-nah” to over-eager programmers who don’t have that much depth in Haskell sprinting around news aggregators to tell everybody they should be using Haskell. Again, not a reply to your post.
I’m very glad you shared your experiences, please keep doing so! Cheers :)
Ditto what bitemyapp said - your post was good! I was more bemoaning the state of things in general. :)