6 ms·

Learning Haskell – Miscellaneous Enlightenments

52 points by ducaale 6y ago

shallowthought 6y ago
Man, whatever you're working on must be incredibly interesting and difficult to necessitate a language with the advanced tools necessary to translate even the most abstract of thoughts into code. Now, if you'll excuse me, I have to write a web app that accepts this API and returns these things... and implement auth... sigh.
- chowells 6y ago
  You could be writing that web app in Haskell. The tools are all there. The language is a lot more pleasant to use than most. It wouldn't really help, of course. Business requirement drudgery is business requirement drudgery in any language.
  - shallowthought 6y ago
    I was very, very obsessed with Haskell for about 9 months, during which time I attempted to make a very simple web app at least 5 times. I like debugging, but I just flat-out couldn't make it work. Plus, constantly feeling stupid is a huge drain on one's motivation to continue. Plus, the community was... not helpful. I mean, I get the whole "Avoid success at all costs", to avoid the language becoming entangled with the desires of large corporate interests, but it did feel a little extreme. Mind, this was 7 years ago, and I assume haskell stack and a few other tools make things a lot easier. Actually, this is something I've always wondered: I know that any Haskell enthusiast would, upon hearing someone say, "I like the ideas, but it's just too hard to program in", respond, no, it's not, you just didn't learn it the right way, or this IDE with that extension makes it much easier, or you really should have started with Learn You A Haskell. But what I'm really curious about is this: Putting all that said, assume for the moment that Haskell really is too complicated for anyone without an advanced degree in hyperbolic topology to understand. Do you care?
    - sullyj3 6y ago
      Given that I don't have a degree in hyperbolic topology, that would definitely put a damper on my appreciation for the language, yep haha. I'd probably consider myself to be on the lower side of average intelligence for programmers, and I like it a lot. Granted, I haven't gotten around to writing a working web app in it yet.
    - CyberDildonics 6y ago
      I like to use my complexity budget on the problems I'm solving, not the tools I'm using. Haskell has been around for 30 years, sucking people in and spitting them out again.
      - rowanG077 6y ago
        So I'm guessing you write all your code in brainfuck given that it has possibly the lowest complexity of all PLs? Tbh this complexity budget is a rather stupid notion in regard to programming languages. Higher level languages allow you to spend less cognition on the language provide you actually know the language. There's a very clear reason we are moving away from C to more complex languages.
        CyberDildonics 6y ago
        There is more cognitive overhead to bf, the programming language does not help you mitigate it. C++ destructors and rvalues help condense ownership without having to think about the execution path of a whole program. I'm not aware of what haskell features + tools pragmatically decrease the complexity of a program. If an experienced programmer is still fighting with the language heavily after 9 months and can't figure out a good way to debug programs, that should be a red flag if it is a consistent scenario.
        rowanG077 6y ago
        GADTs are insanely helpful in writing correct by construction code. That function indicate the effects it has in the type is possibly the greatest feature Haskell has. Haskell LSP is great allowing to write and evaluate doctests in real-time. Haskell can be learned in a couple of months of serious learning. If you don't get it after 9 months you simply weren't serious in learning it. It's not like Haskell is harder then any other language. It's concepts are different which makes it hard to learn. But C++ and Python are much harder to write code in then Haskell.
  - lmm 6y ago
    I disagree; a powerful language lets you push all the junk aside and avoid repeating yourself. The worst part of writing a webapp in, say, Java, isn't the business requirements, it's interfacing with the ridiculous reflection-based authentication library and threadlocal-based database session management and whatever other crap.
- agentultra 6y ago
  Most of my limited production Haskell experience has been schlepping enterprise JSON using AWS Lambda and calling REST APIs. I’ve not had any bug reports in ages. Which is counter to what most of the teams were used to when deploying services in JavaScript or Ruby. Usually you test like hell, QA, ship, get a few error reports from users, fix them, get one or two a couple months later and fix those... then a year later you change something and get a bunch of new error reports about the feature that used to work... and you fix those. Haskell forced me to address most of those errors before my program would compile. I had to write a few tests but orders of magnitude fewer than I was used to. I shipped fast. I got one report from the customer many months later when I made a mistake due to a miscommunication of requirements. One test case prevented that kind of error happening again inadvertently and shipped in less than an hour. Haven’t heard any reports since. Haskell is my go to where I can get away with it. Absolutely solid stuff.
  - Tainnor 6y ago
    I have quite a personal interest in learning more about pure FP, type systems, theorem provers and all the hot stuff. But: you're also comparing Haskell to completely dynamic languages like Ruby or JS. There are things in the middle. Even Java lets you avoid many silly typing errors and if you use something like Kotlin (and you use it well, not just as a slightly more modern Java), you can IMHO get quite far in terms of correctness for typical web backends. Now the power of languages like Haskell may be warranted in more complex scenarios and I don't want to claim there are no benefits to it, but there are degrees in between the madness that is JS and something like Haskell.
dllthomas 6y ago
> I realized that there is no way to take a value out of an IO purely, that is, you cannot have a function IO a -> a. It is not because IO is a Monad and Monads are special cased magic, but simply because the constructor of IO is not exported out of its module. That's not really why. Even if you could unwrap the IO constructor, there is no `a` inside it! As it turns out, with you can unwrap the IO constructor if you import GHC.Types from ghc-prim: Prelude> import GHC.Types Prelude GHC.Types> :set -XUnboxedTuples Prelude GHC.Types> let (IO f) = getChar Prelude GHC.Types> :t f f :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Char #) What's inside is a function. You can't get the return value out of a function without running it. You can, of course, run it. `unsafePerformIO` will give you a thunk that, when forced, will do just that.
- dwohnitmok 6y ago
  While true (and perhaps is another minor enlightenment, that the parameters of a type signature do not need to actually correspond to any runtime values, which the article talks about in its own way later), I do think this is an extremely important point that I appreciate the article bringing up and want to hammer home myself. I often see the sentiment on HN and other programming forums that the "magic of Haskell's mysterious and arcane type system with the bogeyman of inscrutable category theory and monads" (to exaggerate just a tad) prevents you from mixing pure and non-pure code in Haskell. That's not what's going on. It's just a clever choice by the standard library to not export certain functions that unwrap a type (or at least hide it behind a function with the word unsafe in it), a trick that is used by any language that has support for private and public functions. Indeed this exact same thing can be replicated by any language that is expression-focused and has support for immutable bindings. Just modify your standard library to wrap everything side-effectful in an IO type and don't let users unwrap that.
  - dllthomas 6y ago
    On reflection, I think that's a really good perspective. If you'll notice, my ultimate conclusion was "actually, you sort of can" so it makes a lot of sense to look at it as "you can't because that's not the interface they chose to expose." There are important reasons why that's what they chose, but that's a separate question. (Both of these questions are valid interpretations of the original wording of the question, but they are interesting considered separately.)
chowells 6y ago
There's a lot good in there, but the laziness section is missing one key insight still: you have to think of strictness in terms of evaluation dependency. For Int, (+) is strict in both arguments. That doesn't mean throwing a + b someplace causes a and b to be evaluated. It means that after the expression a + b has been evaluated, both a and b have been evaluated (at least as long as the result is non-bottom). Since it's a direct data dependency, you know a bit more. You specifically know a + b must evaluate a and b before it adds them. That's not necessarily true with all strict evaluation. You can use seq to create an evaluation dependency between two values that need not care about ordering. If c = seq a b, the when c is evaluated, both a and b will have been evaluated, and c will evaluate to the b. But there is explicitly no ordering there. The compiler may choose to evaluate either a or b first, by whatever metrics it wants. It takes a lot of practice to get the hang of thinking about evaluation like this. But it's the key to not having memory use problems in Haskell while also not breaking code with unnecessary strictness.
xupybd 6y ago
How do I get a job using a functional language? Do people hire experienced imperative programmers and train them to use languages like Haskell?
- justanargentine 6y ago
  Yes, there are banks using Haskell for many important processes.
- aspaceman 6y ago
  Yeah there are. At the high end I think Jane Street will train you in OCaml when you're a junior new hire, assuming you show the competence and care to figure it out. I imagine you have to show some functional programming experience (using it, not work experience), knowledge, or even aspirations, but I've often heard of the actual practical experience coming from the job.
- the_only_law 6y ago
  You can, and I know a few people who work with it, but from what ive heard theres very few positions out there so you hace to be very good as opposed to just an average Haskeller.
sullyj3 6y ago
The point about let exressions is excellent, and I definitely relate to the author. I think they're underemphasized in FP evangelism to people used to the imperative paradigm - "look, this is pretty similar to how it'd look in python if you were disciplined about not reusing names."
sullyj3 6y ago
Should probably note that class Convert a b requires MultiParamTypeclasses
r00tanon 6y ago
Reminds me of my exposure to APL. So great. Why isn't it a mainstream language? Probably many of the same reasons Haskel is not yet a thriving mainstream language. 90% of problem domains yield well to procedural/hybrid languages. The rest could stand the additional rigor and even provability possible with pure FP languages.

52 points by ducaale 6y ago

Man, whatever you're working on must be incredibly interesting and difficult to necessitate a language with the advanced tools necessary to translate even the most abstract of thoughts into code. Now, if you'll excuse me, I have to write a web app that accepts this API and returns these things... and implement auth... sigh.

chowells 6y ago
You could be writing that web app in Haskell. The tools are all there. The language is a lot more pleasant to use than most. It wouldn't really help, of course. Business requirement drudgery is business requirement drudgery in any language.
- shallowthought 6y ago
  I was very, very obsessed with Haskell for about 9 months, during which time I attempted to make a very simple web app at least 5 times. I like debugging, but I just flat-out couldn't make it work. Plus, constantly feeling stupid is a huge drain on one's motivation to continue. Plus, the community was... not helpful. I mean, I get the whole "Avoid success at all costs", to avoid the language becoming entangled with the desires of large corporate interests, but it did feel a little extreme. Mind, this was 7 years ago, and I assume haskell stack and a few other tools make things a lot easier. Actually, this is something I've always wondered: I know that any Haskell enthusiast would, upon hearing someone say, "I like the ideas, but it's just too hard to program in", respond, no, it's not, you just didn't learn it the right way, or this IDE with that extension makes it much easier, or you really should have started with Learn You A Haskell. But what I'm really curious about is this: Putting all that said, assume for the moment that Haskell really is too complicated for anyone without an advanced degree in hyperbolic topology to understand. Do you care?
  - sullyj3 6y ago
    Given that I don't have a degree in hyperbolic topology, that would definitely put a damper on my appreciation for the language, yep haha. I'd probably consider myself to be on the lower side of average intelligence for programmers, and I like it a lot. Granted, I haven't gotten around to writing a working web app in it yet.
  - CyberDildonics 6y ago
    I like to use my complexity budget on the problems I'm solving, not the tools I'm using. Haskell has been around for 30 years, sucking people in and spitting them out again.
    - rowanG077 6y ago
      So I'm guessing you write all your code in brainfuck given that it has possibly the lowest complexity of all PLs? Tbh this complexity budget is a rather stupid notion in regard to programming languages. Higher level languages allow you to spend less cognition on the language provide you actually know the language. There's a very clear reason we are moving away from C to more complex languages.
      - CyberDildonics 6y ago
        There is more cognitive overhead to bf, the programming language does not help you mitigate it. C++ destructors and rvalues help condense ownership without having to think about the execution path of a whole program. I'm not aware of what haskell features + tools pragmatically decrease the complexity of a program. If an experienced programmer is still fighting with the language heavily after 9 months and can't figure out a good way to debug programs, that should be a red flag if it is a consistent scenario.
        rowanG077 6y ago
        GADTs are insanely helpful in writing correct by construction code. That function indicate the effects it has in the type is possibly the greatest feature Haskell has. Haskell LSP is great allowing to write and evaluate doctests in real-time. Haskell can be learned in a couple of months of serious learning. If you don't get it after 9 months you simply weren't serious in learning it. It's not like Haskell is harder then any other language. It's concepts are different which makes it hard to learn. But C++ and Python are much harder to write code in then Haskell.
- lmm 6y ago
  I disagree; a powerful language lets you push all the junk aside and avoid repeating yourself. The worst part of writing a webapp in, say, Java, isn't the business requirements, it's interfacing with the ridiculous reflection-based authentication library and threadlocal-based database session management and whatever other crap.
agentultra 6y ago
Most of my limited production Haskell experience has been schlepping enterprise JSON using AWS Lambda and calling REST APIs. I’ve not had any bug reports in ages. Which is counter to what most of the teams were used to when deploying services in JavaScript or Ruby. Usually you test like hell, QA, ship, get a few error reports from users, fix them, get one or two a couple months later and fix those... then a year later you change something and get a bunch of new error reports about the feature that used to work... and you fix those. Haskell forced me to address most of those errors before my program would compile. I had to write a few tests but orders of magnitude fewer than I was used to. I shipped fast. I got one report from the customer many months later when I made a mistake due to a miscommunication of requirements. One test case prevented that kind of error happening again inadvertently and shipped in less than an hour. Haven’t heard any reports since. Haskell is my go to where I can get away with it. Absolutely solid stuff.
- Tainnor 6y ago
  I have quite a personal interest in learning more about pure FP, type systems, theorem provers and all the hot stuff. But: you're also comparing Haskell to completely dynamic languages like Ruby or JS. There are things in the middle. Even Java lets you avoid many silly typing errors and if you use something like Kotlin (and you use it well, not just as a slightly more modern Java), you can IMHO get quite far in terms of correctness for typical web backends. Now the power of languages like Haskell may be warranted in more complex scenarios and I don't want to claim there are no benefits to it, but there are degrees in between the madness that is JS and something like Haskell.

dllthomas 6y ago

> I realized that there is no way to take a value out of an IO purely, that is, you cannot have a function IO a -> a. It is not because IO is a Monad and Monads are special cased magic, but simply because the constructor of IO is not exported out of its module. That's not really why. Even if you could unwrap the IO constructor, there is no `a` inside it! As it turns out, with you can unwrap the IO constructor if you import GHC.Types from ghc-prim: Prelude> import GHC.Types Prelude GHC.Types> :set -XUnboxedTuples Prelude GHC.Types> let (IO f) = getChar Prelude GHC.Types> :t f f :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Char #) What's inside is a function. You can't get the return value out of a function without running it. You can, of course, run it. `unsafePerformIO` will give you a thunk that, when forced, will do just that.

dwohnitmok 6y ago
While true (and perhaps is another minor enlightenment, that the parameters of a type signature do not need to actually correspond to any runtime values, which the article talks about in its own way later), I do think this is an extremely important point that I appreciate the article bringing up and want to hammer home myself. I often see the sentiment on HN and other programming forums that the "magic of Haskell's mysterious and arcane type system with the bogeyman of inscrutable category theory and monads" (to exaggerate just a tad) prevents you from mixing pure and non-pure code in Haskell. That's not what's going on. It's just a clever choice by the standard library to not export certain functions that unwrap a type (or at least hide it behind a function with the word unsafe in it), a trick that is used by any language that has support for private and public functions. Indeed this exact same thing can be replicated by any language that is expression-focused and has support for immutable bindings. Just modify your standard library to wrap everything side-effectful in an IO type and don't let users unwrap that.
- dllthomas 6y ago
  On reflection, I think that's a really good perspective. If you'll notice, my ultimate conclusion was "actually, you sort of can" so it makes a lot of sense to look at it as "you can't because that's not the interface they chose to expose." There are important reasons why that's what they chose, but that's a separate question. (Both of these questions are valid interpretations of the original wording of the question, but they are interesting considered separately.)

chowells 6y ago

There's a lot good in there, but the laziness section is missing one key insight still: you have to think of strictness in terms of evaluation dependency. For Int, (+) is strict in both arguments. That doesn't mean throwing a + b someplace causes a and b to be evaluated. It means that after the expression a + b has been evaluated, both a and b have been evaluated (at least as long as the result is non-bottom). Since it's a direct data dependency, you know a bit more. You specifically know a + b must evaluate a and b before it adds them. That's not necessarily true with all strict evaluation. You can use seq to create an evaluation dependency between two values that need not care about ordering. If c = seq a b, the when c is evaluated, both a and b will have been evaluated, and c will evaluate to the b. But there is explicitly no ordering there. The compiler may choose to evaluate either a or b first, by whatever metrics it wants. It takes a lot of practice to get the hang of thinking about evaluation like this. But it's the key to not having memory use problems in Haskell while also not breaking code with unnecessary strictness.

xupybd 6y ago

How do I get a job using a functional language? Do people hire experienced imperative programmers and train them to use languages like Haskell?

justanargentine 6y ago
Yes, there are banks using Haskell for many important processes.
aspaceman 6y ago
Yeah there are. At the high end I think Jane Street will train you in OCaml when you're a junior new hire, assuming you show the competence and care to figure it out. I imagine you have to show some functional programming experience (using it, not work experience), knowledge, or even aspirations, but I've often heard of the actual practical experience coming from the job.
the_only_law 6y ago
You can, and I know a few people who work with it, but from what ive heard theres very few positions out there so you hace to be very good as opposed to just an average Haskeller.

sullyj3 6y ago

The point about let exressions is excellent, and I definitely relate to the author. I think they're underemphasized in FP evangelism to people used to the imperative paradigm - "look, this is pretty similar to how it'd look in python if you were disciplined about not reusing names."

sullyj3 6y ago

Should probably note that class Convert a b requires MultiParamTypeclasses

r00tanon 6y ago

Reminds me of my exposure to APL. So great. Why isn't it a mainstream language? Probably many of the same reasons Haskel is not yet a thriving mainstream language. 90% of problem domains yield well to procedural/hybrid languages. The rest could stand the additional rigor and even provability possible with pure FP languages.