Probably because real-world applications mostly aren't that interesting -- they're assuming you're doing that stuff well on your own. You could write "real world applications" in any language you want, some faster (to develop) and others more efficient (at runtime) than haskell, but that's not what haskell brings to the table.
Haskellers (well me) view Haskell as introducing reasoned and disciplined immutability, purity, type safety, etc to the mundane world of real-world applications, which is why Haskellers get excited when these benefits can be applied. Writing a database query? boring. Writing a database query that is guaranteed at compile time to contain the right columns to build the right domain object such that you can never write an incorrect one? that's interesting.
I hear you. Other languages have those properties. Including TypeScript.
In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want.
And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications.
I'd love to be proven wrong as I'm into type safety and FP, in general.
I absolutely love TypeScript -- right now Node + TypeScript is my pick for the interpreted language wars (Node/Python/Ruby/Perl/etc).
> In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want.
This is actually one of haskell's greatest strengths IMO -- it enforces the kind of discipline that sidesteps this problem completely. The kind of functions you write with haskell don't allow bullshit -- non-nullable types are the biggest example of this I can think of, there's also the pervasive use of `Maybe Value` and `Either SomeError Value` types.
In other places it's usually referred to as Domain Driven Design or the onion architecture -- but best practices for software development usually dictate that you get rid of bullshit as early as possible on the borders of your application. Put simply, don't let invalid/incorrect input make it into your system.
> And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications.
Totally true, we do get stuck in the mud, but it's such nice mud -- the things you worry about are just different (and I think this is what you're seeing). Roughly zero haskellers are worrying about NPEs -- there's no urge to get something to "just work" because "better" is right there, and haskell encourages you to strive for it.
That said, it's absolutely the case that a ton of energy in haskell land is spent on academic pursuits, but that's actually good imo, languages that don't do this get stale.
> I'd love to be proven wrong as I'm into type safety and FP, in general.
Well I don't know that this is something someone else can prove to you, outside of people just writing more middling/regular software in haskell and getting it out there, which is a bit of a community thing. I do my best to write practical haskell software and write about it, but a bunch of my projects aren't open source (just yet -- I'm heavily considering making one of them open source right now). Rust is also proving to be a huge (welcome) distraction because it gives much of the haskell creature comforts with within-C++/C range efficiency.
Maybe take haskell for a spin? The learning curve is high but it will bend your mind in a good way. Or if you're of the web persuasion, try Elm/Purescript, they're thoroughly practical.
The refreshing part about Haskell to me is that it is declarative. It feels more natural to describe what you want to happen than to try to think like a machine and compose sequential machine instructions for it each of which can fail at any execution.
Haskell's compiler is incredibly strict. It'll guide you until the code is near bullet proof. The outcome is that the surface area where things can go wrong is relatively a lot smaller than in just about any other language our there.
Haskell is not declarative. It is a specific form of lazy + graph-reductive. Thinking of it as declarative leads to polynomial exponential runtime cost in CPU/memory and not understanding why or how to fix it.
I'm not talking about the compiler or the evaluation. From programmer's perspective the language does seem fairly declarative to me, mostly consisting of expressions instead of statements.
I don't know what's wrong about thinking about expressions as declarative which in my opinion they are. How would thinking about expressions imperatively help me avoid those exponential runtime costs?
For example consider the list comprehension:
[toUpper c | c <- s]
If you compare this with your typical imperative for loop to construct the same data structure I find this declarative.
> I hear you. Other languages have those properties. Including TypeScript.
Limited nominal typing, limited support for record-like functionality (ability to handle datastructures generically-but-safely), no HKT (so difficult to handle secondary concerns in the type system - e.g. writing a function whose type enforces that it's called within a database transaction, but you can still compose it with other such functions and run them all together in a single transaction). I wanted to like TypeScript, I really did, but after a month or so I was fed up enough to actually put nonzero effort into building with Scala.js (which turned out to be really easy) and within an hour I had the safety properties I was used to and was more productive as a result. (Scala isn't Haskell but the advantages are similar).
??? Could you drop some links/justification? I know I learned a lot from the set of slides about Flow vs Typescript[0].
Also, not having the sophistication of Haskell doesn't make something bad -- Rust's type system doesn't have the sophistication of Haskell and I think it's a fantastic language (I struggle not to pick it over haskell most of the time).
Typescript, sound type system or not, has brought many of the benefits of the Haskell ecosystem to JS. Python, Ruby (and Perl?) are following in the footsteps right now with their gradual typing schemes. AFAIK JS was the first to get something like this so right -- going from syntax sugar to actually highly beneficial type checking. The stuff people would put on top of C to make it safer stands out but I can't remember such transpiling ever being so embraced and beneficial to a language.
Haskellers (well me) view Haskell as introducing reasoned and disciplined immutability, purity, type safety, etc to the mundane world of real-world applications, which is why Haskellers get excited when these benefits can be applied. Writing a database query? boring. Writing a database query that is guaranteed at compile time to contain the right columns to build the right domain object such that you can never write an incorrect one? that's interesting.