Sorry to be blunt, but it's probably because of how crypto is a Rube Goldberg machine that attracts similar tinkerers as those attracted by Haskell's Rube Goldberg machine aspects. Both technologies seem to be doing a lot of complicated stuff, and so they attract a kind of technologist that enjoys technology for technology's sake.

Maybe. I thought it had more to do with smart contracts, where the the mathematical and research oriented nature of Haskell helps somehow? I figured it had something to do with the "if it compiles, it works" aspect of Haskell (granted, Haskell has bugs like any language, but it's closer to the compiles = perfect standard.)

I know the one and only Haskell job I personally looked into was about smart contracts.

And using the latest webframework garbage react iteration is not tech for tech sake? Or worse tech for resume sake. At least with the former I get to enjoy myself.

Plus, at least using Haskell exercises the mind: most web frameworks seem designed to keep one's thoughts sedentary.

I like Scala and Haskell. The selling points of high assurances by their compilers appealed to me.

Opinion: Something I did not anticipate is these languages allow a high degree of individual choice in coding style by a programmer, and companies tend to dislike this. I have read this sentiment about Clojure shops; the original authors are very capable in the codebase but it can be hard to bring in new team members later. It seems to me most companies prefer less expressive languages with opinionated style guidelines. I have never worked with Python professionally, but apparently there is a high emphasis on style consistency in the community.

This concern about ease-of-onboarding may not even be related to the qualities of the programming language. I'm sure there are Python projects where it is difficult to onboard new team members.

I still believe the type system of Haskell can provide great benefits to codebase maintenance over the long term. If the coding style were restricted and opinionated, it might assist with company adoption.

If your products biggest concern is fungibility of developers and controlling what developers can do then you likely wouldn't be getting any value from any of the group of expressive languages anyway.

>Obviously there exist projects in less expressive languages that are hard to maintain

This is the flip side of more conservative language choices. The moment you're off the beaten path you're doing way more custom stuff to work around the language. My favourite one I point at is Instagram's use of Python is commonly held up as "Python can do everything" but when you read their tech blogs you're basically reading "here's how we got some extremely skilled specialist language Devs to Jerry rig custom functionality onto python to create a flavour that could be doing absolutely anything. All to avoid hiring a few devs with a copy of a standard manual for some other language.

> I still believe the type system of Haskell can provide great benefits to codebase maintenance over the long term. If the coding style were restricted and opinionated, it might assist with company adoption.

Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack.

All good points. Very interesting point about Instagram. The solution to that IMO is building upon a language-agnostic messaging system. I believe the Bezos API mandate addressed this. This would allow a small team to use a better-suited language and still interface with the rest of the company.

> Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack.

Interesting point; that there is no general-purpose language that perfectly encodes every business domain.

I disagree with giving the developers the tools and getting out of the way. The management is still responsible for the outcome of the project and needs more control than this. Yes, fungibility of developers is a concern. If the developers hold equity in the project, they are incentivized to support fungibility as well, to allow the company to grow.

IMO start-ups should reduce the proprietary code opinions as much as possible, and rely on well-publicized code patterns as much as possible. This both grows the hireable talent pool, and makes it easier for new hires to understand the system once inside. Since start-ups tend to pay less than large companies and the equity is high risk, it is unfair IMO to require new employees to learn a highly-opinionated proprietary start-up tech stack. The requirement to learn a proprietary stack is more justifiable in large companies where the financial compensation is more reliable and often higher.

Haskell is a well designed language. Designed by some of worlds best experts on programming language theory. I don't think it has any "Rube Goldberg machine aspects", Solidity on the other hand...

I agree completely. Haskell is a more difficult language to learn in my opinion than Python or Java, but there are real benefits in the runtime errors it can prevent.

Not sure why you are getting downvoted, but I agree. There is a learning curve to Haskell, which should not be surprising. Haskell is to Python what Python is to x86 assembly. x86 assembly has less of a learning curve than Python. There's less to learn and it's much more flexible.

Once the learning curve has been overcome, most would agree that higher-level languages are more productive. I am significantly more productive in Haskell than Python, especially for any non-trivial problem.

> Haskell's Rube Goldberg machine aspects

Eh, it's the other way around. As you keep adding functionality to a program in an imperative language, at some point it will turn into a mess that you can describe as a Rube Goldberg machine.

Functional programming allows one to keep one's head cool, and thus you will reach tipping point complexity at a much later stage.

FP allows one to build taller buildings. This is what attracts smart people to Haskell.

Agreed, I was surprised too. Haskell is the only language I've used in which the codebase doesn't turn into a Rube Goldberg machine in the short amount of time (granted most of that was Python -- maybe it's Python in particular that has a problem).

The Rube Goldberg machine builders will do the same in any language. Give them Java and they will build monstrosities beyond your comprehension.

The functional paradigm has its strengths and weaknesses, just like any other paradigm. One of its strengths is facilitating elegant, easily understood, and highly correct code -- but that depends on the developer.

Smart contracts are foot guns and so they are an interesting case for formal verification and advanced static typing people. They usually like Haskell. I like formal verification but not blockchain, however , the jobs are there. Saving actual lives with formal methods is not worth the money, so we prove Ponzi schemes to be correct. A little over the top, sorry, but it is hurting just a tad that chemo delivery devices have less rigid software than something that is marketed as an everyone wins lottery type of thing.

Yes, to add to this, it was an opportune time at the beginning of a new sector with no legacy code. I've read that iOS Apps benefited in a similar way in security over Mac OS; there was an opportunity to start fresh without backward compatibility requirements.

I wouldn't be surprised if a huge factor is just marketing. Most crypto products are only built to be sold to some investor. And saying it's all built on Haskell probably sells better than saying it's a bog standard typescript program.

Insert something about "our coin is secure because we code in a language that prevents programmers from making mistakes".

would you rather handling money in php or haskell ?

I've seen a company doing that in Visual Basic. It was successful enough to have a nice office etc.

I would rather handle money in what I know best.