16 ms·

> As a result, both languages have steep learning curves compared with other languages. Well yes and no. In a way the features such as immutability and algebra

> As a result, both languages have steep learning curves compared with other languages. Well yes and no. In a way the features such as immutability and algebraic data types are things you should know about as a software developer even if your current language means you can't use them at the moment. My 16 year old son has learned Rust coming from a python at school background and is now writing small games in the bevy game engine.

surement 4y ago
> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.
- cosmic_quanta 4y ago
  You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.
  - jeremyjh 4y ago
    I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.
    - ghostwriter 4y ago
      > Its not impossible to do serious work without them but I'm not sure its worth doing. How do you think the folks on Java and C# find their work worth doing on their end in that case?
      - jeremyjh 4y ago
        Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.
        ghostwriter 4y ago
        Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?
        jeremyjh 4y ago
        I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.
        ghostwriter 4y ago
        I get this point and I agree with it, but I also object to your comment on having to use transformers as otherwise it's not worthy. My objection has to do with seemingly different standards and expectations applied to levels of users of mainstream languages. In my opinion they should be the same, even if Haskell allows for safer and better results with transformers: they are not universally required and expected to be used by all haskell developers. If `unsafePerformIO` does the trick for them at the moment, so be it: they won't be worse off than Java devs.
        jeremyjh 4y ago
        If you aren't going to learn to write Haskell in the spirit of Haskell why learn it at all? Learning a language also involves learning the communities norms and accepted practices.
      - mayoff 4y ago
        Java code is always in the IO and Except monads.
    - weavie 4y ago
      I would say using them is beginner->intermediate. Writing them is intermediate->advanced.
      - cosmic_quanta 4y ago
        That's a good distinction
      - jeremyjh 4y ago
        I'd agree in general and almost made this same point but it depends on what you are doing. If you write a transformer that is essentially just a specific kind of Reader (like ResourceT), then you can just follow existing examples and not really have to understand how to write all the instances yourself.
  - sshine 4y ago
    You don’t even really need to understand monad transformers in general to use just the ‘ReaderT IO’ pattern, and if you want to go crazier, free monads are both easier to understand, and more flexible.
- anon291 4y ago
  You don't need to know that to write haskell Effect systems and monad transformers are advanced topics. They're possible to use in my language yet most people do not and can still write software. Certainly no need for them in Haskell to be successful. You can just program at the lower levels of abstraction common in other languages. The only difference is that Haskell's community tends to emphasize abstraction
  - klntsky 4y ago
    There's no way to even get a job without understanding monad transformers.
    - tome 4y ago
      If true that's sad and hopefully effectful will bring than to an end https://github.com/haskell-effectful https://github.com/haskell-effectful
  - YuukiRey 4y ago
    I hear this opinion every so often but I just don't think it's really the case. Many libraries out there expect you to use Monad transformers. You might try to keep MTL out of your own application code, but you'll find that the rest of the ecosystem favors it. You can still use these libraries without MTL, but it's often not ergonomic and therefore not really an option.
yboris 4y ago
steep learning curve usually means the opposite of what the author wants to say: "The common expression "a steep learning curve" is a misnomer suggesting that an activity is difficult to learn and that expending much effort does not increase proficiency by much, although a learning curve with a steep start actually represents rapid progress." https://en.wikipedia.org/wiki/Learning_curve https://en.wikipedia.org/wiki/Learning_curve When writing, consider "challenging learning curve" instead (I'd love other suggestions too).
- creata 4y ago
  Easy fix, put time on the y-axis.
- blep_ 4y ago
  If essentially everyone uses it to mean one thing, that's what it means now. That's how definitions work.
  - IAmYourDensity 4y ago
    Does that apply to “Hacker” in Hacker News?
    - ketralnis 4y ago
      Sure. Language is contextual. If you find yourself explaining why hacker isn't really hacker to the people that you talk to _about_ hacker news, then yes it is actually impeding communication
- thomastjeffery 4y ago
  You can consider a function with a steep slope from either perspective. The defining factor is the context that function exists in.
- martinflack 4y ago
  I always imagined a mountain climb. So steep learning curve would mean daunting, high effort, high "drag" (gravity), but if you undertake it and push hard, you do, in fact, gain tons of utility (rather than proficiency per se) in a short amount of time.

surement 4y ago

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

cosmic_quanta 4y ago
You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.
- jeremyjh 4y ago
  I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.
  - ghostwriter 4y ago
    > Its not impossible to do serious work without them but I'm not sure its worth doing. How do you think the folks on Java and C# find their work worth doing on their end in that case?
    - jeremyjh 4y ago
      Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.
      - ghostwriter 4y ago
        Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?
        jeremyjh 4y ago
        I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.
        ghostwriter 4y ago
        I get this point and I agree with it, but I also object to your comment on having to use transformers as otherwise it's not worthy. My objection has to do with seemingly different standards and expectations applied to levels of users of mainstream languages. In my opinion they should be the same, even if Haskell allows for safer and better results with transformers: they are not universally required and expected to be used by all haskell developers. If `unsafePerformIO` does the trick for them at the moment, so be it: they won't be worse off than Java devs.
        jeremyjh 4y ago
        If you aren't going to learn to write Haskell in the spirit of Haskell why learn it at all? Learning a language also involves learning the communities norms and accepted practices.
    - mayoff 4y ago
      Java code is always in the IO and Except monads.
  - weavie 4y ago
    I would say using them is beginner->intermediate. Writing them is intermediate->advanced.
    - cosmic_quanta 4y ago
      That's a good distinction
    - jeremyjh 4y ago
      I'd agree in general and almost made this same point but it depends on what you are doing. If you write a transformer that is essentially just a specific kind of Reader (like ResourceT), then you can just follow existing examples and not really have to understand how to write all the instances yourself.
- sshine 4y ago
  You don’t even really need to understand monad transformers in general to use just the ‘ReaderT IO’ pattern, and if you want to go crazier, free monads are both easier to understand, and more flexible.
anon291 4y ago
You don't need to know that to write haskell Effect systems and monad transformers are advanced topics. They're possible to use in my language yet most people do not and can still write software. Certainly no need for them in Haskell to be successful. You can just program at the lower levels of abstraction common in other languages. The only difference is that Haskell's community tends to emphasize abstraction
- klntsky 4y ago
  There's no way to even get a job without understanding monad transformers.
  - tome 4y ago
    If true that's sad and hopefully effectful will bring than to an end https://github.com/haskell-effectful https://github.com/haskell-effectful
- YuukiRey 4y ago
  I hear this opinion every so often but I just don't think it's really the case. Many libraries out there expect you to use Monad transformers. You might try to keep MTL out of your own application code, but you'll find that the rest of the ecosystem favors it. You can still use these libraries without MTL, but it's often not ergonomic and therefore not really an option.

yboris 4y ago

steep learning curve usually means the opposite of what the author wants to say: "The common expression "a steep learning curve" is a misnomer suggesting that an activity is difficult to learn and that expending much effort does not increase proficiency by much, although a learning curve with a steep start actually represents rapid progress." https://en.wikipedia.org/wiki/Learning_curve https://en.wikipedia.org/wiki/Learning_curve When writing, consider "challenging learning curve" instead (I'd love other suggestions too).

creata 4y ago
Easy fix, put time on the y-axis.
blep_ 4y ago
If essentially everyone uses it to mean one thing, that's what it means now. That's how definitions work.
- IAmYourDensity 4y ago
  Does that apply to “Hacker” in Hacker News?
  - ketralnis 4y ago
    Sure. Language is contextual. If you find yourself explaining why hacker isn't really hacker to the people that you talk to _about_ hacker news, then yes it is actually impeding communication
thomastjeffery 4y ago
You can consider a function with a steep slope from either perspective. The defining factor is the context that function exists in.
martinflack 4y ago
I always imagined a mountain climb. So steep learning curve would mean daunting, high effort, high "drag" (gravity), but if you undertake it and push hard, you do, in fact, gain tons of utility (rather than proficiency per se) in a short amount of time.