Backwards compatibility: This is not really Haskell-the-language but the Prelude and while yes it's incredibly bad and should be changed, you can at least use a different prelude that e.g. uses Text everywhere. What I mean is that it's not a flaw deeply rooted in the language but the library eco system. Haskell-the-language actually has some breaking changes from time to time, for example in I think four releases * won't be the name of the kind of types, it's Type (so 5 :: Int :: Type, not 5 :: Int :: *)
I don't get the second point. You always write executables at the end, just because you use a bunch of AWS APIs this does not change
Laziness: Maybe. It makes a lot of algorithms easier to express and allows you to treat your algorithm as data structure you traverse (which is pretty cool imo). Also without laziness, some normally trivial identities do not hold.
the bottom that every type inhabits is sadly a direct result of the halting problem, getting rid of it would require haskell to become a theorem proover like Agda or Coq
too many features: yes, there are a lot of extensions and they might be overwelming for a newcomer, but for beginners they don't matter, the features are tucked behind extensions and you should know what you are doing before enabling them. A beginner won't need them, but seasoned programmers can use the type level features to make their software even more resiliant and safe.
As a big note: I am not trying to change your mind or want to proclaim my opinion as better or above yours, it's just that: my opinion. I came to Haskell after I got fixed by FRP doing frontend work and quickly fell in love. Nowadays I write all my backend code in Haskell.
As do I! :-)
On the whole though, I'm not saying Haskell is bad compared to other existing languages. Instead, I believe FP can be a whole lot more than Haskell, and that this is currently not properly being explored, partially because of Haskell's dominance.
you can at least use a different prelude
I will have to look into that.
You always write executables at the end
This is not true. You will very likely need some kind of executable at some point to run your program. What you write is a solution to a problem. With FP, you don't need to know what the underlying architecture is, only how the functions are composed from smaller functions.
E.g. in big data applications, you might map a pure function f over a data source and split the computations over many nodes. This can be expressed simply as fmap f stream. Done. Let the compiler figure out how to turn that into executables, config files and deployment actions.
allows you to treat your algorithm as data structure you traverse (which is pretty cool imo)
True, and agreed. There are certainly upsides to non-strictness, which is why it became popular in the 80's in the first place. For the flagship of FP, I think it's a bad quality.
OTOH, maybe it's possible to turn non-strict code into strict code at compile time.
without laziness, some normally trivial identities do not hold
Interesting, do you have more info about this?
the bottom
I'm not really concerned with the bottom. While I'm in favor of fully functional programming, I don't think it's necessary. I'm not really sure what you're commenting on though.
for beginners they don't matter
Sort-of. If you're programming as a learning exercise it's fine. If you want to make something "real", you will likely need libraries, which are often made by more experienced devs. So for real-world development it has a bit of a wall in its learning curve.
When you come across a function with a polymorphic type with 7 instance requirements... I can understand optimization aspect of it but damn...
Just put NoImplicitPrelude into your .cabal file or put {-# LANGUAGE NoImplicitPrelude #-} at the top of ever file. I use Protolude for example: stephendiehl.com/posts/protolude.html
Interesting, do you have more info about this?
For example this: head . fmap f = f . head. If f bottoms on the second element in the list, the left will bottom and the right not. In a lazy language both won't.
I don't think it's necessary
Bottom is just the name for crashes (which is different than errors), ie non-recoverable, like panic!() in Rust. Strict languages don't need to bother, because a crash will just instantly crash the program. In a lazy language this is not the case, so you need a name to talk about this behavior.
Just to leave my two cents here 😅
Backwards compatibility: This is not really Haskell-the-language but the Prelude and while yes it's incredibly bad and should be changed, you can at least use a different prelude that e.g. uses
Texteverywhere. What I mean is that it's not a flaw deeply rooted in the language but the library eco system. Haskell-the-language actually has some breaking changes from time to time, for example in I think four releases*won't be the name of the kind of types, it'sType(so5 :: Int :: Type, not5 :: Int :: *)I don't get the second point. You always write executables at the end, just because you use a bunch of AWS APIs this does not change
Laziness: Maybe. It makes a lot of algorithms easier to express and allows you to treat your algorithm as data structure you traverse (which is pretty cool imo). Also without laziness, some normally trivial identities do not hold.
the bottom that every type inhabits is sadly a direct result of the halting problem, getting rid of it would require haskell to become a theorem proover like Agda or Coq
too many features: yes, there are a lot of extensions and they might be overwelming for a newcomer, but for beginners they don't matter, the features are tucked behind extensions and you should know what you are doing before enabling them. A beginner won't need them, but seasoned programmers can use the type level features to make their software even more resiliant and safe.
As a big note: I am not trying to change your mind or want to proclaim my opinion as better or above yours, it's just that: my opinion. I came to Haskell after I got fixed by FRP doing frontend work and quickly fell in love. Nowadays I write all my backend code in Haskell.
As do I! :-)
On the whole though, I'm not saying Haskell is bad compared to other existing languages. Instead, I believe FP can be a whole lot more than Haskell, and that this is currently not properly being explored, partially because of Haskell's dominance.
I will have to look into that.
This is not true. You will very likely need some kind of executable at some point to run your program. What you write is a solution to a problem. With FP, you don't need to know what the underlying architecture is, only how the functions are composed from smaller functions.
E.g. in big data applications, you might map a pure function
fover a data source and split the computations over many nodes. This can be expressed simply asfmap f stream. Done. Let the compiler figure out how to turn that into executables, config files and deployment actions.True, and agreed. There are certainly upsides to non-strictness, which is why it became popular in the 80's in the first place. For the flagship of FP, I think it's a bad quality.
OTOH, maybe it's possible to turn non-strict code into strict code at compile time.
Interesting, do you have more info about this?
I'm not really concerned with the bottom. While I'm in favor of fully functional programming, I don't think it's necessary. I'm not really sure what you're commenting on though.
Sort-of. If you're programming as a learning exercise it's fine. If you want to make something "real", you will likely need libraries, which are often made by more experienced devs. So for real-world development it has a bit of a wall in its learning curve.
When you come across a function with a polymorphic type with 7 instance requirements... I can understand optimization aspect of it but damn...
Just put
NoImplicitPreludeinto your.cabalfile or put{-# LANGUAGE NoImplicitPrelude #-}at the top of ever file. I useProtoludefor example: stephendiehl.com/posts/protolude.htmlFor example this:
head . fmap f = f . head. Iffbottoms on the second element in the list, the left will bottom and the right not. In a lazy language both won't.Bottom is just the name for crashes (which is different than errors), ie non-recoverable, like
panic!()in Rust. Strict languages don't need to bother, because a crash will just instantly crash the program. In a lazy language this is not the case, so you need a name to talk about this behavior.Ah, sorry, I meant "fully functional programming" isn't necessary, not bottom :-)