5 ms·

So, I love me some ML-style languages, including Haskell, but I've also come to think that Rich Hickey is right about the real problems of business programming

So, I love me some ML-style languages, including Haskell, but I've also come to think that Rich Hickey is right about the real problems of business programming not being well solved by digging in on things like static typing. For example, pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler. One makes the code a bit more concise and readable, but not necessarily a whole lot more maintainable. The other takes one of the more annoying and error-prone portions of my (say) Java code and renders it far more manageable. There's a recent LispCast that talks about this a bit: https://lispcast.com/what-is-data-orientation/ https://lispcast.com/what-is-data-orientation/

chrisseaton 7y ago
What's the difference between 'business programming' and other types of programming? I don't really know what distinction people are trying to make here.
- deleted 7y ago
  [deleted]
- fulafel 7y ago
  Dealing with the messy real world with exceptions to rules and evolving shape of data vs writing compilers and other internally consistent closed systems.
  - platz 7y ago
    If you have messy/dirty data then you just use an associative data structure like a Map in Haskell, just like any other language.
    - fulafel 7y ago
      Sure, but idea is that the idiomatic way of working in the language accomodates passing around data that is not necessarily closed in shape. Ie intermediate functions will by default pass along also attributes that they don't have knowledge of, for example. And checking data shape conformance is customizable (by the "spec" system).
      - platz 7y ago
        Ok, let's not do the runtime vs compile checks thing here. I was just pointing out there are options that solve similar problems. There are other ways to deal with sub-functions not needing access to the whole structure as well. But let's not expect Haskell and clojure to have exactly the same features. If you want to use clojure, then go for it. Use what you want to use.
        mumblemumble 7y ago
        I think that, at least insofar as I understand the problem I was trying to speak to, it's so deeply entangled with the runtime vs compile checks thing that it's impossible to have a coherent discussion without dealing with the subject head-on. Here's where I come down on it: There are some kinds of projects where you can cut off most potential problems at the pass with compile time checks. In those cases, yes, you absolutely want to statically render as many errors as possible impossible. Compilers come to mind as a shining example here. There are others where the nastiest bits invariably happen at run time, though. And, for a significant number of those, the grottiest bits fall under the general category of "type checking" - not checking types in the structure of the code itself, per se, but checking types in the actual data you're being fed. And, since you don't get fed data until run time, that means all that type checking has to be done at run time. There's no sooner time at which it's possible. There's some tipping point where that becomes such a large portion of your data integrity concerns that it's just easier to delay all your type checking until run time, so that you are dealing with these things in a single, clear, consistent way. If you try to handle it in two places, there's always going to be a crack between them for things to slip through.
        platz 7y ago
        I am sorry that Haskell and clojure people have to fight. You don't see me telling Clojure folks when and where to use the tools they enjoy working with. I think Haskell is an excellent language for servers and API's. It really excels as a backend language. So, I'm sorry you think Haskell is only good for compilers, but I think the range of use cases it's good at is much broader than "Compilers". Haskell is best thought of as a better Java. I wouldn't select it for every problem, but server API's and backend work is a really good fit. Also I think Clojure is great. We can both co-exist in this world though. It is possible. It's unfortunate the OP picked on python - it's not the style of post that I would write.
- base698 7y ago
  Accidental vs essential complexity is a similar concept: > Brooks distinguishes between two different types of complexity: accidental complexity and essential complexity. Accidental complexity relates to problems which engineers create and can fix; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things. https://en.m.wikipedia.org/wiki/No_Silver_Bullet https://en.m.wikipedia.org/wiki/No_Silver_Bullet
- tsmarsh 7y ago
  The difference between solving a problem, and solving a problem for someone else for money. If I'm solving a problem for myself, if it breaks in 'prod' then "Ooops", I try and avoid that, if I'm expecting other people to use it I will document public interfaces and write unit tests, but my focus is on scratching my own itch, not getting paid. If I'm writing code that 1000s of peoples lively hoods, or millions of users buying decisions are being made on the stakes are higher. I might decide to use a more rigid language like Java, because the chances that I'm going to be given the freedom to replace rather than repair classes is slim. Similarly, if I persuade a client that microservices are the way forward, I'm going to spend significant time making sure we have a monorepo so each service has the same time line, an automatic deployment pipeline and I'm going to want to be able to defend my technical choices with economically sound data... and thats where Hickey kicks in. Many of the economically sound data sets are actually vapour.
- pytester 7y ago
  Others may see it differently but I see it as the kind of programming where: * Bugs are typically caused by misunderstandings of requirements or something odd about the interactions between different systems, and rarely about internal logic. * Where quick is often better than proven correct. * Where requirements are in constant flux and where a lot of code is tossed out because it was the result of a failed experiment or an unwanted feature.
leshow 7y ago
I don't know how you can claim that static typing & pattern matching don't help with maintainability. In languages with exhaustiveness checking and good pattern matching you can often make a change in one spot and literally just follow the compiler errors to implement a new feature. They help massively in refactoring, and that's important for maintanability.
- mumblemumble 7y ago
  I find they don't help with maintainability in most my business applications because they're solving the wrong problem. It's sort of like when someone spends a lot of time carefully optimizing a piece of code that doesn't have anything to do with the application's actual performance bottlenecks, just because that's the part that's more fun to optimize. The part of the business applications I work on that's a problem is dealing with the outside world. The data is messy. It's inconsistent. The protocols I'm using to communicate are invariably something horrendously loosey-goosey like JSON or XML. Stuff like that. And so, an inordinate amount of time I spend doing business applications in static languages ends up being spent on taking the messy, messy outside world and trying to create a clean, well-typed, rigorous façade for it so that I can operate on it inside my blissfully statically typed fantasy world. And all that static typing never seems to save me in practice, because the software quality problems I run into almost never crop up in the bits that I can operate on in a Haskell-friendly way. It's invariably in some mismatch between the outside world and my domain model that I failed to deal with accurately, which means that it's in my mapping code. Worse, oftentimes it's because of my mapping code, because my statically typed domain model ends up accidentally placing requirements on the input that aren't strictly needed by the business logic; I just unwittingly introduced them in the course of my efforts to get the types to line up.
  - yakshaving_jgt 7y ago
    In practice, this means you would rather nils permeate throughout your system rather than being caught at a system boundary, i.e., where you parse and validate that loosey-goosey outside world data.
agentultra 7y ago
Rich is a smart person but I think he's missing some gaps in his knowledge of type theory and experience working with Haskell. In one of his recent talks he made the claim that `Either a b` is not associative which.. well it is since it's provably isomorphic to logical disjunction which _is_ associative. I thought what he might be looking for are _variant_ types which are possible to implement in Haskell but are a bit complicated for reasons. There are libraries for it or you can try languages like Purescript or dependently typed languages like Idris, Agda, or Lean. Regardless I don't find his particular brand of vitriol appealing. If he doesn't really have a lot of experience working with Haskell like type systems, why does he feel the need to have an opinion about them? To be fair I used to have a lot of the opinions pointed out in the article and reflected in many of the comments here. An old blog post of mine [0] muses on the utility of static types. I was seriously into Common Lisp at the time. The problem with past me then was that I hadn't taken the time to learn and understand Haskell to form an opinion. I had learned Common Lisp out of frustration to win an argument that it as an old, crusty language that nobody used or needed anymore... and lost. I hadn't done the same yet for Haskell and would join the chorus of people repeating things like, "Haskell is an academic language but is not pragmatic for real-world use." It's embarrassing looking back on it. I've learned enough Haskell in recent years to ship a feature into a production environment and teach a small group of people to hack on it. It's pretty great and I much prefer working with it than I do with weakly-typed or dynamically typed languages. The amount of work I can do with the amount of effort I have to put in has a great ratio in Haskell. The initial learning curve to get there is hard but it's worth it in the end. [0] https://agentultra.com/blog/strict-types/ https://agentultra.com/blog/strict-types/
zelly 7y ago
> pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler Maybe it's cool, but I think static types can be "cool" too. When you take the fashion statement out of the question, what are you left with? One is polymorphism at runtime and the other is at compile time. I'll take the compile time one.
_bxg1 7y ago
As someone who takes sublime pleasure in writing types around a domain, Rich Hickey's rightness on this issue makes me profoundly sad. Here's an article I read a while back (from the same author it turns out!) which nearly converted me to the dynamic-types camp: https://lispcast.com/clojure-and-types/ https://lispcast.com/clojure-and-types/
- mumblemumble 7y ago
  For me, that article and the lecture it talks about planted the seed, and then a year or two of doing data engineering type work watered and fertilized it. That observation on `Maybe` really hit home in a big way. Not at first. Eventually. I used to think that banning null and using `Maybe` instead was the best idea ever. I still love the basic idea, and wish I could always work that way. . . but nowadays I'm so frequently working in the limit case, where everying is either optional, or used to be optional, or will be optional in the future, or is officially required but somebody didn't get the memo. And it's like in some Zen parable where the student keeps getting hit with a stick until they're enlightened. Bruised, bloodied, and enlightened. You either have it or you don't. む.
  - _bxg1 7y ago
    For me it was the part about typing JSON. I work at a company with a Common Lisp back-end and Let Me Tell You. Trying to enforce the JSON structure it generates using any kind of front-end JS types, so that nil-punning doesn't crash the UI every other day, is an exercise in attrition. Unfortunately JS is not Clojure and so can't as elegantly digest inconsistent data, but I certainly have learned to appreciate the appeal of that philosophy.
    - flavio81 7y ago
      Hi _bxg1, Cycorp? Do you need more Lisp developers? I'm trying to switch jobs.
AzzieElbab 7y ago
why not both when applicable?

chrisseaton 7y ago

What's the difference between 'business programming' and other types of programming? I don't really know what distinction people are trying to make here.

deleted 7y ago
[deleted]
fulafel 7y ago
Dealing with the messy real world with exceptions to rules and evolving shape of data vs writing compilers and other internally consistent closed systems.
- platz 7y ago
  If you have messy/dirty data then you just use an associative data structure like a Map in Haskell, just like any other language.
  - fulafel 7y ago
    Sure, but idea is that the idiomatic way of working in the language accomodates passing around data that is not necessarily closed in shape. Ie intermediate functions will by default pass along also attributes that they don't have knowledge of, for example. And checking data shape conformance is customizable (by the "spec" system).
    - platz 7y ago
      Ok, let's not do the runtime vs compile checks thing here. I was just pointing out there are options that solve similar problems. There are other ways to deal with sub-functions not needing access to the whole structure as well. But let's not expect Haskell and clojure to have exactly the same features. If you want to use clojure, then go for it. Use what you want to use.
      - mumblemumble 7y ago
        I think that, at least insofar as I understand the problem I was trying to speak to, it's so deeply entangled with the runtime vs compile checks thing that it's impossible to have a coherent discussion without dealing with the subject head-on. Here's where I come down on it: There are some kinds of projects where you can cut off most potential problems at the pass with compile time checks. In those cases, yes, you absolutely want to statically render as many errors as possible impossible. Compilers come to mind as a shining example here. There are others where the nastiest bits invariably happen at run time, though. And, for a significant number of those, the grottiest bits fall under the general category of "type checking" - not checking types in the structure of the code itself, per se, but checking types in the actual data you're being fed. And, since you don't get fed data until run time, that means all that type checking has to be done at run time. There's no sooner time at which it's possible. There's some tipping point where that becomes such a large portion of your data integrity concerns that it's just easier to delay all your type checking until run time, so that you are dealing with these things in a single, clear, consistent way. If you try to handle it in two places, there's always going to be a crack between them for things to slip through.
        platz 7y ago
        I am sorry that Haskell and clojure people have to fight. You don't see me telling Clojure folks when and where to use the tools they enjoy working with. I think Haskell is an excellent language for servers and API's. It really excels as a backend language. So, I'm sorry you think Haskell is only good for compilers, but I think the range of use cases it's good at is much broader than "Compilers". Haskell is best thought of as a better Java. I wouldn't select it for every problem, but server API's and backend work is a really good fit. Also I think Clojure is great. We can both co-exist in this world though. It is possible. It's unfortunate the OP picked on python - it's not the style of post that I would write.
base698 7y ago
Accidental vs essential complexity is a similar concept: > Brooks distinguishes between two different types of complexity: accidental complexity and essential complexity. Accidental complexity relates to problems which engineers create and can fix; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things. https://en.m.wikipedia.org/wiki/No_Silver_Bullet https://en.m.wikipedia.org/wiki/No_Silver_Bullet
tsmarsh 7y ago
The difference between solving a problem, and solving a problem for someone else for money. If I'm solving a problem for myself, if it breaks in 'prod' then "Ooops", I try and avoid that, if I'm expecting other people to use it I will document public interfaces and write unit tests, but my focus is on scratching my own itch, not getting paid. If I'm writing code that 1000s of peoples lively hoods, or millions of users buying decisions are being made on the stakes are higher. I might decide to use a more rigid language like Java, because the chances that I'm going to be given the freedom to replace rather than repair classes is slim. Similarly, if I persuade a client that microservices are the way forward, I'm going to spend significant time making sure we have a monorepo so each service has the same time line, an automatic deployment pipeline and I'm going to want to be able to defend my technical choices with economically sound data... and thats where Hickey kicks in. Many of the economically sound data sets are actually vapour.
pytester 7y ago
Others may see it differently but I see it as the kind of programming where: * Bugs are typically caused by misunderstandings of requirements or something odd about the interactions between different systems, and rarely about internal logic. * Where quick is often better than proven correct. * Where requirements are in constant flux and where a lot of code is tossed out because it was the result of a failed experiment or an unwanted feature.

leshow 7y ago

I don't know how you can claim that static typing & pattern matching don't help with maintainability. In languages with exhaustiveness checking and good pattern matching you can often make a change in one spot and literally just follow the compiler errors to implement a new feature. They help massively in refactoring, and that's important for maintanability.

mumblemumble 7y ago
I find they don't help with maintainability in most my business applications because they're solving the wrong problem. It's sort of like when someone spends a lot of time carefully optimizing a piece of code that doesn't have anything to do with the application's actual performance bottlenecks, just because that's the part that's more fun to optimize. The part of the business applications I work on that's a problem is dealing with the outside world. The data is messy. It's inconsistent. The protocols I'm using to communicate are invariably something horrendously loosey-goosey like JSON or XML. Stuff like that. And so, an inordinate amount of time I spend doing business applications in static languages ends up being spent on taking the messy, messy outside world and trying to create a clean, well-typed, rigorous façade for it so that I can operate on it inside my blissfully statically typed fantasy world. And all that static typing never seems to save me in practice, because the software quality problems I run into almost never crop up in the bits that I can operate on in a Haskell-friendly way. It's invariably in some mismatch between the outside world and my domain model that I failed to deal with accurately, which means that it's in my mapping code. Worse, oftentimes it's because of my mapping code, because my statically typed domain model ends up accidentally placing requirements on the input that aren't strictly needed by the business logic; I just unwittingly introduced them in the course of my efforts to get the types to line up.
- yakshaving_jgt 7y ago
  In practice, this means you would rather nils permeate throughout your system rather than being caught at a system boundary, i.e., where you parse and validate that loosey-goosey outside world data.

agentultra 7y ago

Rich is a smart person but I think he's missing some gaps in his knowledge of type theory and experience working with Haskell. In one of his recent talks he made the claim that `Either a b` is not associative which.. well it is since it's provably isomorphic to logical disjunction which _is_ associative. I thought what he might be looking for are _variant_ types which are possible to implement in Haskell but are a bit complicated for reasons. There are libraries for it or you can try languages like Purescript or dependently typed languages like Idris, Agda, or Lean. Regardless I don't find his particular brand of vitriol appealing. If he doesn't really have a lot of experience working with Haskell like type systems, why does he feel the need to have an opinion about them? To be fair I used to have a lot of the opinions pointed out in the article and reflected in many of the comments here. An old blog post of mine [0] muses on the utility of static types. I was seriously into Common Lisp at the time. The problem with past me then was that I hadn't taken the time to learn and understand Haskell to form an opinion. I had learned Common Lisp out of frustration to win an argument that it as an old, crusty language that nobody used or needed anymore... and lost. I hadn't done the same yet for Haskell and would join the chorus of people repeating things like, "Haskell is an academic language but is not pragmatic for real-world use." It's embarrassing looking back on it. I've learned enough Haskell in recent years to ship a feature into a production environment and teach a small group of people to hack on it. It's pretty great and I much prefer working with it than I do with weakly-typed or dynamically typed languages. The amount of work I can do with the amount of effort I have to put in has a great ratio in Haskell. The initial learning curve to get there is hard but it's worth it in the end. [0] https://agentultra.com/blog/strict-types/ https://agentultra.com/blog/strict-types/

zelly 7y ago

> pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler Maybe it's cool, but I think static types can be "cool" too. When you take the fashion statement out of the question, what are you left with? One is polymorphism at runtime and the other is at compile time. I'll take the compile time one.

_bxg1 7y ago

As someone who takes sublime pleasure in writing types around a domain, Rich Hickey's rightness on this issue makes me profoundly sad. Here's an article I read a while back (from the same author it turns out!) which nearly converted me to the dynamic-types camp: https://lispcast.com/clojure-and-types/ https://lispcast.com/clojure-and-types/

mumblemumble 7y ago
For me, that article and the lecture it talks about planted the seed, and then a year or two of doing data engineering type work watered and fertilized it. That observation on `Maybe` really hit home in a big way. Not at first. Eventually. I used to think that banning null and using `Maybe` instead was the best idea ever. I still love the basic idea, and wish I could always work that way. . . but nowadays I'm so frequently working in the limit case, where everying is either optional, or used to be optional, or will be optional in the future, or is officially required but somebody didn't get the memo. And it's like in some Zen parable where the student keeps getting hit with a stick until they're enlightened. Bruised, bloodied, and enlightened. You either have it or you don't. む.
- _bxg1 7y ago
  For me it was the part about typing JSON. I work at a company with a Common Lisp back-end and Let Me Tell You. Trying to enforce the JSON structure it generates using any kind of front-end JS types, so that nil-punning doesn't crash the UI every other day, is an exercise in attrition. Unfortunately JS is not Clojure and so can't as elegantly digest inconsistent data, but I certainly have learned to appreciate the appeal of that philosophy.
  - flavio81 7y ago
    Hi _bxg1, Cycorp? Do you need more Lisp developers? I'm trying to switch jobs.

AzzieElbab 7y ago

why not both when applicable?