7 ms·

To paraphrase what's said about fusion energy: Haskell is the language of the future and always will be. I love Haskell, but there's really not a single shred

To paraphrase what's said about fusion energy: Haskell is the language of the future and always will be. I love Haskell, but there's really not a single shred of evidence that programming's moving towards high-level abstractions like category theory. The reality is that 99% of working developers are not implementing complex algorithms or pushing the frontier of computational possibility. The vast majority are delivering wet. messy business logic under tight constraints, ambiguously defined criteria, and rapidly changing organizational requirements. By far more important than writing the purest or most elegant code, are "soft skills" or the ability to efficiently and effectively work within the broader organization. Can you effectively communicate to non-technical people, do you write good documentation, can you work with a team, can you accurately estimate and deliver on schedules, do you prioritize effectively, are you rigorously focused on delivering business value, do you understand the broader corporate strategy. At the end of the day, senior management doesn't care whether the codebase is written in the purest, most abstracted Haskell or EnterpriseAbstractFactoryJava. They care about meeting the organizational objectives on time, on budget and with minimal risk. The way to achieve that is to hire pragmatic, goal-oriented people. (Or at the very least put them in charge.) And that group rarely intersects with the type of people fascinated by the mathematical properties of the type system.

deleted 7y ago
[deleted]
whateveracct 7y ago
> The way to achieve that is to hire pragmatic, goal-oriented people. (Or at the very least put them in charge.) And that group rarely intersects with the type of people fascinated by the mathematical properties of the type system. I wouldn't say it rarely intersects - I'm one and I've worked with plenty. And I've seen plenty with strength in one join a production Haskell shop and pick up the other (in both directions!) Haskell definitely gives you a lot to help manage the messiness you mention. You have to have know-how and awareness to do it, but it can help like none other. But overall, stuff like this is why I wish to eventually become as independent as I can manage in my career. The intersection of Haskell and management thinking is frequently a bad faith shitshow in my experience, so the sooner I can start creating on my own terms, the better. The best part about Haskell is how little effort I exert solving problems compared to my comparable experience in Go, Python, Java. A perfect match for personal creation.
mumblemumble 7y ago
> The vast majority are delivering wet. messy business logic under tight constraints, ambiguously defined criteria, and rapidly changing organizational requirements. And herein lies the fundamental reason why most large aggregations of business software that I've seen in the wild are only strongly typed at about the same scale as the one on which the universe actually agrees with Deepak Chopra. Beyond that, it's all text. It doesn't have to be full-blown Unix style the-howling-madness-of-Zalgo-is-held-back-by-sed-but-only-barely; it can be CSV or JSON or XML or whatever. And a lot of it's really just random magic strings. But it's still all stringly typed at human scales.
- Diederich 7y ago
  I agree with both yours and the parent comments. But this is just glorious: > full-blown Unix style the-howling-madness-of-Zalgo-is-held-back-by-sed-but-only-barely I'm a very long-time UNIX guy, so the I think I get the zen of what you're saying here, but I don't really get the Zalgo reference. Is this it? https://knowyourmeme.com/memes/zalgo https://knowyourmeme.com/memes/zalgo Thanks!
  - sigstoat 7y ago
    first answer on https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open...
    - schoen 7y ago
      And in context, the idea is that when we use classic Unix text manipulation tools, we make implicit and sometimes explicit assumptions about the nature and structure of the data. Those assumptions can be wrong and then our pipelines are also wrong. By contrast, a strongly statically typed environment might force us to prove our assumptions in the context of the interactions among the different parts of our code, and so there will be fewer corner cases where we have unexpected or unspecified behavior. The only barely held back part is presumably that when we notice a corner case, we might add a little more logic to handle that specific case, but we never really approach the goal of handling all possible inputs with valid or useful behavior. (We might even declare that a non-goal.)
darzu 7y ago
I would argue that Haskell lets you respond to nebulous requirements better than almost any other language, because refactoring is so much easier and safer. I self identify much more with being pragmatic and goal-oriented than math-y and perfectionist, and I think for almost every programming domain we'd achieve our goals faster by moving more towards having strong static guarantees in an ergonomic, expressive language. Finally, I would also put forth that debugging state corruption or randomly failing assertions is much harder than learning to avoid side-effects and leaning into immutability.
- KurtMueller 7y ago
  Alexis King, a professional Haskell coder, recently wrote an article on exactly that: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
  - mumblemumble 7y ago
    It's a very insightful article. It's clear and precise and lucidly written, and I'd recommend anyone who cares about these things read it. That said, I found the article unconvincing. The author's writing is perhaps too precise, to the point where the forest has been lost amidst the trees. I can draw the main reasons why I'm losing my religion w/r/t to static typing from out of the appendix portion of the article itself: > not only can statically-typed languages support structural typing, many dynamically-typed languages also support nominal typing. These axes have historically loosely correlated, but they are theoretically orthogonal The fact that they're theoretically orthogonal is small consolation. They are loosely correlated, but the looseness doesn't happen in a way that's particularly useful to me. The fact of the matter is, the only languages I'm aware of that have decent ergonomics for structural typing are either dynamically typed, or constrained to some fairly specific niches. If I want structural typing in a general-purpose language, I'm kind of stuck with Clojure or Python. The list of suggested languages that comes a paragraph later fails to disabuse me of that notion. As does this observation: > all mainstream, statically-typed OOP languages are even more nominal than Haskell!
FabHK 7y ago
Agreed. One sentence in the article embodies this problem: > As long as the dumb AI is unable to guess our wishes, there will be a need to specify them using a precise language. We already have such language, it’s called math. Math is wonderful and elegant, but it is useless (in itself) to specify things in the real world. You need tons of conceptualisation and operationalisation and common sense etc. for the foreseeable future. Heck, logic is useless for the real world - everyone knows the example that “a bachelor is a man that is not married”, but even if you can implement it as a conjunction of two logical predicates, then try to define, with logic a computer can understand, what “man” is, or “married”, or “game”, or “taxable income” or “murder” or “fake news”. Go on, use math and category theory. Good luck. EDIT to add: For a wonderful overview of the problems with the naive Aristotelian view of definition (easily captured by predicate logic) in the real world, see George Lakoff’s book “Women, Fire and Dangerous Things: What Categories Reveal About the Mind”.
- mreome 7y ago
  To be pedantic a bachelor is a man that is not, and has never been, married. A man that is not married may be a bachelor, a divorcé, or a widower. But bachelor is still used colloquially (in the US) for all three (but not as often for a widower). Now if the age of the person is under a certain age, most people would not seriously call them a bachelor yet, but the cut-off age varies culturally. Now married is a bit complicated too.. married in the eyes of the law, formally or common-law, in a particular country, in the eyes of a particular church? Also, my aunt is a Bachelor of Arts, and her martial statues doesn't effect that. Language, life, and business logic is messy, confusing, and conditional/contextual to the point of absurdity. You will never realistically reduce it to pure mathematics in a way that makes it easier to deal with.
  - bzbarsky 7y ago
    I _really_ like the "martial statues" image there, along with the implication that the statues don't convey information about educational attainment... :)
- codeslubber 7y ago
bjornsing 7y ago
This is definitely an accurate description of the past, but is it the future? I’m really interested in what happens when we start to see (more) companies organized around software...
- mrkeen 7y ago
  In the future we'll say "We don't need Haskell because we already have values, higher-kinded types, pure functions, and do-notation in Java". (Although if I could speculate based on past performance: values won't work with collections, pure functions won't allow recursion, do-notation will be incompatible with checked exceptions, and the higher-kinded types won't have inference. And all of them will be jam-packed with unnecessary syntax.)
marcosdumay 7y ago
> The reality is that 99% of working developers are not implementing complex algorithms > The vast majority are delivering wet. messy business logic Ok, notice something wrong here?
- jandrese 7y ago
  That people are using computers to solve real world problems instead of pursuing the higher planes of pure math? 90% of the work ends up being input validation and normalization. Humans suck at consistency, especially if your data comes from multiple sources, and potentially multiple languages. None of those complex algorithms are going to work until you make the data sane.
  - marcosdumay 7y ago
    Those two lines contradict each other.
    - wisnesky 7y ago
      Your point is well-taken, and being overlooked, so here it is explicitly: to implement "wet. messy business logic" is, by definition, to implement "a complex algorithm".
      - asdfasgasdgasdg 7y ago
        I don't think it's being overlooked. It's being seen as pedantry, correctly I think. It's obvious what the parent poster meant, right? Sure the messy business logic is an algorithm in the technical sense. But everyone knows that when people mean when they say that most developers aren't writing fancy algorithms. You know it's kind of funny how this very conversation mirrors the criticisms of Haskell leveled in the top post! Someone is trying to insist that language fit in a neat mathematical box where words are stripped of their colloquial meanings and force us to only use dictionary definitions. But language and the real world just refuse to be so clean! Ha!
ska 7y ago
cf history of lisp.
dhjhfujvfyu 7y ago
Whether you're right or not depends on whether one believes that algebraic datatypes could only have come out of a fascination with the "mathematical properties of the type system". Because ADTs are a serious win in terms of robustness and efficiency of development. They are now found in Rust (for example) but were invented in the 70s in the functional language community. An innovation like that, which was not stumbled on by mainstream imperative language designers, arguably comes from a focus on abstract mathematical structure. You might be right if you believe that profunctor optics are going nowhere, or that dependent types and type–level programming are just too complicated, but as a research project, strongly typed functional programming has many strengths, and I don't just mean strengths that are not essentially related to the type system like purity or laziness. '“The ability of the [strong] type system to catch [mundane] errors allows us to spend more time thinking about other, deeper issues in our code and drives down our error rate, making it possible to move faster while still maintaining safe and reliable systems,” says Yaron Minsky, co-head of the technology group at liquidity provider Jane Street. The firm, as it puts it, writes “everything that we can in OCaml”, a functional language, and employs 300 OCaml developers.'
CuriousSkeptic 7y ago
But people need simple tools by witch to do that. So while not everyone needs to care about abstractions and their properties. We really need the people who put together frameworks and libraries to.
pyrale 7y ago
It is harmful to people to suggest that, because they might have novel or different ideas, they are not "pragmatic", or "goal-oriented". This kind of ad-hominem attacks on their character has no place in evaluating the value of a tool or a concept. Please consider evaluating ideas based on their merit with regards to context, rather than delivering blanket considerations about people based on your prejudice.

deleted 7y ago

[deleted]

whateveracct 7y ago

> The way to achieve that is to hire pragmatic, goal-oriented people. (Or at the very least put them in charge.) And that group rarely intersects with the type of people fascinated by the mathematical properties of the type system. I wouldn't say it rarely intersects - I'm one and I've worked with plenty. And I've seen plenty with strength in one join a production Haskell shop and pick up the other (in both directions!) Haskell definitely gives you a lot to help manage the messiness you mention. You have to have know-how and awareness to do it, but it can help like none other. But overall, stuff like this is why I wish to eventually become as independent as I can manage in my career. The intersection of Haskell and management thinking is frequently a bad faith shitshow in my experience, so the sooner I can start creating on my own terms, the better. The best part about Haskell is how little effort I exert solving problems compared to my comparable experience in Go, Python, Java. A perfect match for personal creation.

mumblemumble 7y ago

> The vast majority are delivering wet. messy business logic under tight constraints, ambiguously defined criteria, and rapidly changing organizational requirements. And herein lies the fundamental reason why most large aggregations of business software that I've seen in the wild are only strongly typed at about the same scale as the one on which the universe actually agrees with Deepak Chopra. Beyond that, it's all text. It doesn't have to be full-blown Unix style the-howling-madness-of-Zalgo-is-held-back-by-sed-but-only-barely; it can be CSV or JSON or XML or whatever. And a lot of it's really just random magic strings. But it's still all stringly typed at human scales.

Diederich 7y ago
I agree with both yours and the parent comments. But this is just glorious: > full-blown Unix style the-howling-madness-of-Zalgo-is-held-back-by-sed-but-only-barely I'm a very long-time UNIX guy, so the I think I get the zen of what you're saying here, but I don't really get the Zalgo reference. Is this it? https://knowyourmeme.com/memes/zalgo https://knowyourmeme.com/memes/zalgo Thanks!
- sigstoat 7y ago
  first answer on https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open...
  - schoen 7y ago
    And in context, the idea is that when we use classic Unix text manipulation tools, we make implicit and sometimes explicit assumptions about the nature and structure of the data. Those assumptions can be wrong and then our pipelines are also wrong. By contrast, a strongly statically typed environment might force us to prove our assumptions in the context of the interactions among the different parts of our code, and so there will be fewer corner cases where we have unexpected or unspecified behavior. The only barely held back part is presumably that when we notice a corner case, we might add a little more logic to handle that specific case, but we never really approach the goal of handling all possible inputs with valid or useful behavior. (We might even declare that a non-goal.)

darzu 7y ago

I would argue that Haskell lets you respond to nebulous requirements better than almost any other language, because refactoring is so much easier and safer. I self identify much more with being pragmatic and goal-oriented than math-y and perfectionist, and I think for almost every programming domain we'd achieve our goals faster by moving more towards having strong static guarantees in an ergonomic, expressive language. Finally, I would also put forth that debugging state corruption or randomly failing assertions is much harder than learning to avoid side-effects and leaning into immutability.

KurtMueller 7y ago
Alexis King, a professional Haskell coder, recently wrote an article on exactly that: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
- mumblemumble 7y ago
  It's a very insightful article. It's clear and precise and lucidly written, and I'd recommend anyone who cares about these things read it. That said, I found the article unconvincing. The author's writing is perhaps too precise, to the point where the forest has been lost amidst the trees. I can draw the main reasons why I'm losing my religion w/r/t to static typing from out of the appendix portion of the article itself: > not only can statically-typed languages support structural typing, many dynamically-typed languages also support nominal typing. These axes have historically loosely correlated, but they are theoretically orthogonal The fact that they're theoretically orthogonal is small consolation. They are loosely correlated, but the looseness doesn't happen in a way that's particularly useful to me. The fact of the matter is, the only languages I'm aware of that have decent ergonomics for structural typing are either dynamically typed, or constrained to some fairly specific niches. If I want structural typing in a general-purpose language, I'm kind of stuck with Clojure or Python. The list of suggested languages that comes a paragraph later fails to disabuse me of that notion. As does this observation: > all mainstream, statically-typed OOP languages are even more nominal than Haskell!

FabHK 7y ago

Agreed. One sentence in the article embodies this problem: > As long as the dumb AI is unable to guess our wishes, there will be a need to specify them using a precise language. We already have such language, it’s called math. Math is wonderful and elegant, but it is useless (in itself) to specify things in the real world. You need tons of conceptualisation and operationalisation and common sense etc. for the foreseeable future. Heck, logic is useless for the real world - everyone knows the example that “a bachelor is a man that is not married”, but even if you can implement it as a conjunction of two logical predicates, then try to define, with logic a computer can understand, what “man” is, or “married”, or “game”, or “taxable income” or “murder” or “fake news”. Go on, use math and category theory. Good luck. EDIT to add: For a wonderful overview of the problems with the naive Aristotelian view of definition (easily captured by predicate logic) in the real world, see George Lakoff’s book “Women, Fire and Dangerous Things: What Categories Reveal About the Mind”.

mreome 7y ago
To be pedantic a bachelor is a man that is not, and has never been, married. A man that is not married may be a bachelor, a divorcé, or a widower. But bachelor is still used colloquially (in the US) for all three (but not as often for a widower). Now if the age of the person is under a certain age, most people would not seriously call them a bachelor yet, but the cut-off age varies culturally. Now married is a bit complicated too.. married in the eyes of the law, formally or common-law, in a particular country, in the eyes of a particular church? Also, my aunt is a Bachelor of Arts, and her martial statues doesn't effect that. Language, life, and business logic is messy, confusing, and conditional/contextual to the point of absurdity. You will never realistically reduce it to pure mathematics in a way that makes it easier to deal with.
- bzbarsky 7y ago
  I _really_ like the "martial statues" image there, along with the implication that the statues don't convey information about educational attainment... :)
codeslubber 7y ago

bjornsing 7y ago

This is definitely an accurate description of the past, but is it the future? I’m really interested in what happens when we start to see (more) companies organized around software...

mrkeen 7y ago
In the future we'll say "We don't need Haskell because we already have values, higher-kinded types, pure functions, and do-notation in Java". (Although if I could speculate based on past performance: values won't work with collections, pure functions won't allow recursion, do-notation will be incompatible with checked exceptions, and the higher-kinded types won't have inference. And all of them will be jam-packed with unnecessary syntax.)

marcosdumay 7y ago

> The reality is that 99% of working developers are not implementing complex algorithms > The vast majority are delivering wet. messy business logic Ok, notice something wrong here?

jandrese 7y ago
That people are using computers to solve real world problems instead of pursuing the higher planes of pure math? 90% of the work ends up being input validation and normalization. Humans suck at consistency, especially if your data comes from multiple sources, and potentially multiple languages. None of those complex algorithms are going to work until you make the data sane.
- marcosdumay 7y ago
  Those two lines contradict each other.
  - wisnesky 7y ago
    Your point is well-taken, and being overlooked, so here it is explicitly: to implement "wet. messy business logic" is, by definition, to implement "a complex algorithm".
    - asdfasgasdgasdg 7y ago
      I don't think it's being overlooked. It's being seen as pedantry, correctly I think. It's obvious what the parent poster meant, right? Sure the messy business logic is an algorithm in the technical sense. But everyone knows that when people mean when they say that most developers aren't writing fancy algorithms. You know it's kind of funny how this very conversation mirrors the criticisms of Haskell leveled in the top post! Someone is trying to insist that language fit in a neat mathematical box where words are stripped of their colloquial meanings and force us to only use dictionary definitions. But language and the real world just refuse to be so clean! Ha!

ska 7y ago

cf history of lisp.

dhjhfujvfyu 7y ago

Whether you're right or not depends on whether one believes that algebraic datatypes could only have come out of a fascination with the "mathematical properties of the type system". Because ADTs are a serious win in terms of robustness and efficiency of development. They are now found in Rust (for example) but were invented in the 70s in the functional language community. An innovation like that, which was not stumbled on by mainstream imperative language designers, arguably comes from a focus on abstract mathematical structure. You might be right if you believe that profunctor optics are going nowhere, or that dependent types and type–level programming are just too complicated, but as a research project, strongly typed functional programming has many strengths, and I don't just mean strengths that are not essentially related to the type system like purity or laziness. '“The ability of the [strong] type system to catch [mundane] errors allows us to spend more time thinking about other, deeper issues in our code and drives down our error rate, making it possible to move faster while still maintaining safe and reliable systems,” says Yaron Minsky, co-head of the technology group at liquidity provider Jane Street. The firm, as it puts it, writes “everything that we can in OCaml”, a functional language, and employs 300 OCaml developers.'

CuriousSkeptic 7y ago

But people need simple tools by witch to do that. So while not everyone needs to care about abstractions and their properties. We really need the people who put together frameworks and libraries to.

pyrale 7y ago

It is harmful to people to suggest that, because they might have novel or different ideas, they are not "pragmatic", or "goal-oriented". This kind of ad-hominem attacks on their character has no place in evaluating the value of a tool or a concept. Please consider evaluating ideas based on their merit with regards to context, rather than delivering blanket considerations about people based on your prejudice.