What percentage of Haskell jobs are crypto jobs? I bet it’s high
From a 30 seconds look, it seems there are around 5 cryptocurrency jobs in the list for year 2022.
You will find that currently the list of Haskell companies is quite diverse across industries, which is a big change vs. 10 years ago.
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.
Obviously there exist projects in less expressive languages that are hard to maintain, so maybe ease-of-onboarding and ease-of-maintenance depend on something else.
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.
>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.
> 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.
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.
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 highly non-trivial problem.
I know the one and only Haskell job I personally looked into was about smart contracts.
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.
Clash for FPGA work, and several tools from Galois for embedded real time uses.