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.
Dealing with the messy real world with exceptions to rules and evolving shape of data vs writing compilers and other internally consistent closed systems.
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).
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.
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.
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.
I am sorry that you somehow think this has become a Haskell vs Clojure fight. Me, I actually use Haskell a lot more than I use Clojure, and generally think it's a great language with a lot to offer.
But I also believe another very important thing: There is no silver bullet.
Because I believe that, I am able to recognize that even the things I love have some limitations. And I don't believe that this should be a fight, and that is why I think I should be able to articulate what I have found to be the limitations of a tool, and acknowledge that some other tool that other people like might have something to offer in this area. Without being perceived as a hater for doing so.
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.
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.
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.
