I think Haskell is an excellent choice for "high-level" situations. It
takes some doing to learn it
And maybe too "high level" because you basically have to learn category
theory before you can do some things.
How much Haskell have you written? My guess is "not much", or maybe "none".
I've written a LOT of it and what you say above is absolutely not true. You
simply learn the 'do' construct and why and when you need it, which is not
Not to disparage Haskell because I agree it is really great for its target
use cases and demographics. That is if you want to learn what a Monad is
just to do I/O and any imperative style programming.
Which takes a short period of time with Paul Hudak's "Gentle" introduction,
or "Learn You a Haskell". It's comparable to learning any programming
language. The only thing that makes learning Haskell more of a challenge
than, say, Python, is that Haskell is different in some important ways
(functional language, lazy evaluation) from more mainstream languages, and
so requires a somewhat different mindset. Not unlike ownership, borrows,
and lifetimes, but far easier, in my experience (though I will concede that
the difficulty I encountered with Rust, and I am far from alone, was, at
least in part, due to the state of the documentation at the time I
attempted to use the language; hopefully, that is a temporary situation).
And no parenthesis grouping functional call arguments, so you need to
memorize the definition site of the functions in order to group the
function arguments in order to read the code.
Again, untrue. It is always clear from the code what function-call
arguments are, otherwise it wouldn't compile!
Haskell seems to be for a mathematical mind and it inverts the type system
to coinduction thus populating every type with Bottom, i.e. the
conjunction of all types
Whereas many programmers want to think more inductively (where Any is the
Top disjunction of all types) and imperatively as they accustomed to
You are again demonstrating what I am guessing is a lack of real experience
with Haskell, and therefore you don't know the difference between theory
and practice. I have written a lot of code in all the languages you mention
(and many you haven't -- I've been doing this for a very long time) and
none of the theory you spout above was remotely a consideration. It's for
academicians to debate and write papers about, but it doesn't come up in
the real world.
The fact is that today's Haskell is a highly developed programming
environment with a large library of useful tools and an amazing compiler
(GHC). The language is very expressive -- used correctly, Haskell programs
are very concise. And much debugging is moved to compile-time (avoiding
some less efficient run-time debugging), because of the strong typing and
excellent compiler diagnostics. It's a great way to quickly develop correct
code that performs well.
My interest in Rust was the possibility that it could serve in places where
I presently use C and that it shares some of the characteristics that I
value in Haskell. I hope to come back to it at some point when the
documentation is improved and find that it is useful to me. But I do not
think that Rust and Haskell are comparable languages, any more than C and
Python are comparable. Their areas of appropriate applicability are quite
disjoint. This is because there is an inevitable trade-off between
ease-of-use and performance. Because of the power of today's hardware, we
can do a lot of useful things even with interpreted languages, and with
compiled languages that deliver less-than-maximal performance, like Haskell
and Scheme. But when maximum performance really is a top priority (as
opposed to something in the imagination of a programmer doing premature
optimization), then languages like C and Rust have a role. But you pay a
coding-time price for their use and I don't think that will ever go away.