Hacker News Reader

I don't agree with your conclusions, but that didn't stop me from upvoting your comment. You touch on all sorts of important issues management should consider while deciding whether to adopt an oddball programming language or technology as the basis of its business. I write this as a CTO that chose Clojure as the basis for our now-acquired and fully-metabolized-by-the-buyer startup.

You better make sure the person who is advocating for the oddball technology…

* Is going to stick around; even cofounders sometimes bail or get caught.

* Understands the opportunity costs i.e. what is being given up by not using boring tech.

* Has used the tech on the ground and not just in a comp sci lab or to implement a to-do app.

* Will be able to grow i.e. recruit additional members to the team as the needs of the business grow.

* Really is a 10X programmer -- assuming they exist.

* Can sell the decision (in a way that doesn't consume undue positive karma) to VCs, customers, acquirers, etc.

In my situation, Clojure worked for us because I'd already spent years writing Clojure (and Scheme and Lisp) code and I understood the problem domain (I was the head of product at the time) and I had made a personal commitment to the CEO to stick around for at least two years and I managed to not get arrested or do anything awkwardly disgraceful. We also got lucky in that Clojure had a bit of a moment as a smart person's programming language in the mid two thousand teens.

If I weren't hands-on, I probably wouldn't have advocated for Clojure and instead would have opted for something mainstream for backend infrastructure at the time e.g. Java, Node.js, Python.

> Integrations with emerging technologies like new database systems or new statistical packages always lags way behind other languages and usually exists in some half-finished form that depends on labor of love from some isolated hobbyist.

This really sets Clojure apart from Haskell, in that you can use any Java library with almost zero friction.

I don’t have experience in Clojure but I do have experience in Scala where this claim is also made often.

In Scala anyway, it’s totally false. Firstly there’s just a huge impedence mismatch between code relying on Scala features and code serving as a Java wrapper into Scala. But even just the basic usage of the libraries doesn’t always work.

I very nearly quit a job once just from the incredible frustration of trying to use JFreeChart in Scala.

For a while, a few years ago, I wrote a lot of scripts and personal tooling in Clojure, calling Java APIs. I don't remember really having any difficulties calling Java code from Clojure.

It's a very different world in Clojure. Data structures mutually satisfy the relevant interfaces, and there's no real pain about how a java.util.Map isn't immutable and so on.

> The type checking doesn’t actually help you to create functionally correct systems at all (let alone the false claims that it makes this process faster).

This is a red flag to me. Of course the tool doesn't guarantee the result, but your story smells of incompetence. I've introduced FP and a focus on types-as-a-tool at the places I've worked and hired accordingly. Quality and speed of development have gone up after minimal time investment. A battle of n=1 I guess?

Not really. People make all kinds of crazy claims about the benefits of static type checking or compiler enforcements. These are perfectly fine tools, but you can achieve the exact same thing with a low effort set of unit tests most of the time.

The teams I’ve worked on with functional programming always had super senior engineers, people who had previously spent serious time on core GHC development and people who had worked as compiler engineers at e.g. Lightbend. They displayed all the same sources of slowness, defects, deadline and/or feature creep, bad designs leading to required refactors or rework, etc., as any teams I’ve been a part of that do everything in Python.

Static type enforcement is just a tool like anything else. It locates a certain class of code problems at compile or type checking time, that’s all. In most large projects, speeding up the detection of this class of errors is just not very important, and can be extremely well approximated with low effort test cases and other techniques.

This kinds of harsh yet legitimate criticism puts me off from spending more time on the notoriously steep Haskell learning curve.

I wouldn't let it put you off. mlthoughts2018 is pretty much the only commenter on HN who has seriously used Haskell yet also complains about it.

But on the other hand, it's been hard to put my finger on the tangible benefits of all that time spent on Haskell. I'm worried that I end up going deep into that rabbit hole without really benefiting from it.

I think that's fine, as long as it's your own decision from your own experience. On the other hand if you're struggling with anything in particular then we tend to be friendly and helpful over at https://www.reddit.com/r/haskell/. The monthly Hask Anything threads might be useful for you.

I've posted questions there before but unfortunately got no replies. However, some friendly folks at Slack helped me a lot.

Do you have any thoughts on Elixir? I've been playing around with it and Haskell at the same time. Compared to Haskell, Elixir's dynamic type system and impurity make it a lot more practical to get stuff done, in my experience.

I'm just like you. I use Elixir for anything serious and Haskell for personal or small scale projects.

The way I see it is that Haskell abstracts away the runtime considerations. You spend the majority of your time modeling your business domain in Haskell. Or rather, retrofitting your business model into Haskell's type system.

In Elixir, in contrast, you spend the majority of your time building systems, in other words on runtime problems. All the tooling and even the whole OTP revolves around this. For anything that runs on the web, this is a major benefit compared to Haskell.