4 ms·

The idea of "marketing Haskell" to me is akin to marketing math and mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it is succinct. Ye

by cs702 6y ago

The idea of "marketing Haskell" to me is akin to marketing math and mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it is succinct. Yes, the benefits of its algebraic type system are many and very real -- if your code compiles, it is correct in many important ways. No one can argue with any of that. But... most people who look into Haskell lose steam as soon as they realize they actually must understand and be able to reason about functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. It's a shame.

JadeNB 6y ago
> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it? Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.
- marcosdumay 6y ago
  Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.
  - JadeNB 6y ago
    > Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine. Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.
6gvONxR4sf7o 6y ago
The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge, or to place an IV, or even to build a table. There's a huge part of the software community that's self taught, but also a gigantic part with degrees in computer science. If there was enough value in these ideas and critical mass of wide adoption, we could just add it to the curriculum, and it'd just be yet another of those things you need to learn to get into the software industry.
- moreaccountspls 6y ago
  >The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge If we're talking about the software engineering equivalent of bridges, I think it would be much more valuable add TLA+ or similar to the curriculum.
  - pwm 6y ago
    Why not both? They are not mutually exclusive and they both would advance the status quo.
    - moreaccountspls 6y ago
      If there was unlimited time, sure.
      - pwm 6y ago
        OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.

by cs702 6y ago

JadeNB 6y ago

> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it? Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.

marcosdumay 6y ago
Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.
- JadeNB 6y ago
  > Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine. Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.

6gvONxR4sf7o 6y ago

The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge, or to place an IV, or even to build a table. There's a huge part of the software community that's self taught, but also a gigantic part with degrees in computer science. If there was enough value in these ideas and critical mass of wide adoption, we could just add it to the curriculum, and it'd just be yet another of those things you need to learn to get into the software industry.

moreaccountspls 6y ago
>The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge If we're talking about the software engineering equivalent of bridges, I think it would be much more valuable add TLA+ or similar to the curriculum.
- pwm 6y ago
  Why not both? They are not mutually exclusive and they both would advance the status quo.
  - moreaccountspls 6y ago
    If there was unlimited time, sure.
    - pwm 6y ago
      OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.