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.
