5 ms·

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 Goldb

by hudon 3y ago

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.

Buttons840 3y ago
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.
anonzzzies 3y ago
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.
- intelVISA 3y ago
  Plus, at least using Haskell exercises the mind: most web frameworks seem designed to keep one's thoughts sedentary.
peterbecich 3y ago
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. 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.
- Tanjreeve 3y ago
  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.
  - peterbecich 3y ago
    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.
grumpyprole 3y ago
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...
- peterbecich 3y ago
  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.
  - grumpyprole 3y ago
    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 ARM assembly. ARM assembly has less of a learning curve than Python. There's simply much less to learn and it's much more flexible. But of course it's not at all productive and even harder to build correct software with. 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.
amelius 3y ago
> 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.
- tome 3y ago
  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).
xcv123 3y ago
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.

by hudon 3y ago

Buttons840 3y ago

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.

anonzzzies 3y ago

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.

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

peterbecich 3y ago

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. 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.

Tanjreeve 3y ago
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.
- peterbecich 3y ago
  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.

grumpyprole 3y ago

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...

peterbecich 3y ago
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.
- grumpyprole 3y ago
  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 ARM assembly. ARM assembly has less of a learning curve than Python. There's simply much less to learn and it's much more flexible. But of course it's not at all productive and even harder to build correct software with. 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.

amelius 3y ago

> 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.

tome 3y ago
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).

xcv123 3y ago

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.