I'm sooo sick of the tools analogy when it comes to programming languages. A programming language is not simply a tool like a hammer. A hammer does one thing well, a programming language is a means of expression. It's more akin to a natural language like Spanish than a "tool" as we generally think of the word.

Yes, in the broadest sense of the word, Spanish is a tool. So is a programming language, but the analogy is stretched and stale. The image it puts in people's minds is not super helpful. And if we must use such a broad word as tool - let's acknowledge that it's really a collection of tools (every API, bit of syntax, and language feature is a tool).

> It's more akin to a natural language like Spanish than a "tool" as we generally think of the word.

I still say it is a tool, just a tool with many buttons and settings. English is a natural language that I learnt (it was my 3rd natural language) primary to read and understand computer related materials (books, keywords, instructions). It was absolutely a tool just like a hammer is a tool to drive a nail in. It turns out to be a very beneficial tool but a tool nevertheless. I would never bother spending time learning the etymology of words or finding all the tenses or declensions (but some do and derive great pleasure from that).

I don't think you read what I said - I said it is a tool in the broad sense of the word (one as you put it with many buttons and settings - I pointed out those APIs, syntax, etc) - it's just a shitty analogy because the broad sense of the word means something different than the common use of the term "tool".

It’s an optimisation problem. Both classes of people, at a fundamental level, want shit to get done. It’s a question of whether you want it done right (for some definition of “right”) or whether you want it done now.

Most of the time, there’s a balance to be struck in the tool you choose—if we did it in Haskell or OCaml or Scala, it’d probably be more correct and easier to maintain in the long run; but we are a startup that is likely going to run out of funding in a month or two, and if we hack it together in Ruby or Python or Node then no one will fault us and we can rewrite it in a good language later if we have the budget of time and money.

So while Haskell might be my primary language at work and play—and I see the tremendous value it holds for experienced developers—when beginners ask me what language they should learn, I invariably say: “Java”. At this point, it’s the essence of mediocrity, the dead middle of the bell curve; you can go better or worse from there.

Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving. For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'. Not that I've ever seen any real numbers which is a big problem when making statements like that.

> Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving.

While I don't have actual proof of anything (and I doubt parent has either), removing classes of issues is a big win. Not to say that any of the three languages you list is a silver bullet, they all come with a long list of drawbacks. You just have to pick which drawbacks you dislike the least.

> For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'.

What do you mean by this? If your types are fine-grained enough (which you can absolutely do in Java, at the cost of a lot more code), and you change your specification, you will need to change your types. But if you did not have fine-grained types (in any language), you're going to be fixing errors at runtime instead. If you're not going to leverage the type system, you may as well work with Python, you'll get the same effect with a lot less code.

If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly. If it was something like javascript, you'd just add the new information somewhere and it would be passed through without changes to where you'd need it. Making a statement like 'Haskell is easier to maintain' doesn't seem to ring true in this case. If you have unit tests for both your Haskell and javascript code then they should both be equally correct after the change.

Now maybe Haskell really would be easier to maintain - but it's something that needs proof and hard evidence. To use a car analogy for the GP's post, "I could buy a Ford because it is safer and easier to repair, but sometimes I'd just buy a Chrysler because it's cheaper and easier to purchase". There's nothing wrong with this statement if you have real numbers on the two different cars - but making the statement based on some kind of assumptions on what you think the two languages will or won't do is pure folly.

If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.

> If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly.

It depends on what you do. If you (say) add a new field to an existing type, this will screw up pattern matching. It's a bit inconvenient, but typically not a big deal. On the other hand, if your previously non-nullable String field becomes a Maybe String, you're going to have to update every location where you access it... and that's exactly what a reasonable programmer wants to do. Unfortunately, you can't encode this in Javascript, so you're going to resort to 'grep' (good luck if you have the same field name for several objects), or forget about it and get runtime errors. Sure, in theory you can rely on your Javascript unit tests to detect the error, and you may be right in practice, or you may be out of luck.

Generally speaking, Haskell has its fair share of problems, but it's not one of them.

> If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct.

It definitely matches my own experience (it obviously depends on your proficiency in both languages, and Haskell will have only marginal advantages if you use String everywhere because types are hard).

> He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.

It's the kind of thing for which it is extremely hard to get any evidence for (and not only in Haskell vs Javascript debates), for obvious reasons. The best you can say is that the stronger guarantees of correctness offered by a strongly-typed program ensure that it makes it much easier to detect regressions. On the other hand, if, say, there are no third-party libraries for the problem domain at hand, strong typing will not magically fix that.

You are absolutely right about the technology fetish, I think most of us here have been guilty of it. On the other hand, you do have languages which help with writing more correct programs, and others which hinder you (I'm looking at you, PHP and Javascript).