12 ms·

The biggest lie about Haskell is that it's easy to learn. No it's not, and I do use it at work. Sure, it's not THAT difficult to get a basic understanding until

by li4ick 7y ago

The biggest lie about Haskell is that it's easy to learn. No it's not, and I do use it at work. Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects. But, even if you finish the Haskell Book(http://haskellbook.com http://haskellbook.com), which is like 1300 pages, you're still going to be unable to contribute to a serious code base. Anyone who says otherwise is lying. Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. Now you have to understand how to really structure a program as either a stack of monad transformers, or free monads or anything else. Then you get into concurrency and to do that you have to understand how Haskell actually works, what non-strict computation does etc. etc. Otherwise you're going to get some nasty behaviour. You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens. Don't get me wrong, Haskell has spoiled me, and I don't really want to touch any other language (I still like Clojure, Rust, Python, Erlang). Once you get past that the language is a joy to use.

yakshaving_jgt 7y ago
You don’t need to understand the internals of a thing to use the thing.
- Quekid5 7y ago
  This is exactly right. I use lenses all the time, but I have absolutely no idea how they're actually implemented, nor do I need to know. This is abstraction. If there's one thing Haskell does well it's abstraction. EDIT: It's really bizarre. We see these same responses to all the Haskell-or-Idris-or-whatever threads -- I wonder if there's some imposter syndrome going where "I can't immediately read/write Haskell" somehow morphs into "Haskell is useless". IME it's really rare for people who actually program in Haskell to have serious issues with the language. Yes there are issues from a smaller ecosystem, package management was bad (Stack fixed that), etc. etc. but there are very few fundamental problems with the language. Something so small as just Pattern Matching is a huge increase in productivity. Thankfully, quite a few languages have adopted pattern matching these days (Scala, Rust, TS, maybe even C++23?). (The really big payoff comes from granular effects, but I'm sure the rest of the world will realize in about 20-30 years' time. The Erlang people already have, albeit in a different way.)
  - marcosdumay 7y ago
    People look at weird syntax and discussions about things that have no resemblance to the problem they are facing, and conclude it must not be useful for anything real. Yes, those problems have no resemblance to any real problem because of abstraction, but most people's experience with abstraction is in a Java-like language where nothing good ever gets out of it.
- mantap 7y ago
  Only if you have infinite memory. In theory there's no difference between folding left and folding right (if associative), in practice there is a right way and a wrong way.
  - yakshaving_jgt 7y ago
    > In theory there's no difference between folding left and folding right There's no difference in practice either for a sufficiently small dataset. > in practice there is a right way and a wrong way Sure, but that's true of all technologies. Yes, Haskell can't help you escape the limitations of our world — or indeed our hardware — but it doesn't pretend to either.
    - magicalhippo 7y ago
      > There's no difference in practice either for a sufficiently small dataset. As a non-Haskell user, just for reference what's "sufficiently small"?
      - yakshaving_jgt 7y ago
        It depends on your needs. This is neither constrained to Haskell specifically nor functional programming more generally. If you were building a website for your local Italian restaurant, what would your needs be? Do you need an ElasticSearch cluster to handle customer menu item queries? Do you need a database at all? In Haskell's case it's best to avoid lists entirely, as they're _usually_ not the optimal data structure. But best for whom? Does the beginner care that a set operation would be more effective than a list operation for their given use-case?
        magicalhippo 7y ago
        Not sure how that's an answer to my question? In my day job, I frequently generate records returned from a database along with local changes to be posted later, and say compute the sum of one of the columns. That sounded like something I'd use folding for, with my limited knowledge, so I was just curious at which point (order of magnitude) I'd have to worry about doing it this way or that. But if lists are not to be used, what should I use for the above? And will the data structure you propose be fine with either fold?
- tutfbhuf 7y ago
  You don’t need to understand the internals of a thing, until you do. Everything works fine as described in documentation until it doesn't for your use case. You might be lucky and find help from stackoverflow, otherwise you need someone who really grok it.
  - pwm 7y ago
    Sure and at that point you need to learn those internals. That's just the way it is with everything, no?
    - vbezhenar 7y ago
      When things go wrong, you might not have time to do so. When my project started to leak memory at enormous rate, I was able to find the issue quickly enough. But if I didn't know how all those things work, I would spend weeks or months learning all those things. Restarting application every 10 minutes for a week is not a good idea.
      - pwm 7y ago
        How is this different for Haskell than with anything else? If you want to be an expert in something, anything you do need to put in the work and learn it inside-out. There is no royal road. I fail to see how this is specific to Haskell...
        ukj 7y ago
        It boils down to the steepness of the learning curves. If I am in the business of system reliability, I will choose the language with shallower rabbit holes. Abstraction layers are great for builders and terrible for fixers. I am both, so I need to strike a balance.
        vbezhenar 7y ago
        I agree with you, I don't think that it's different for Haskell.
  - 7y ago
- barrkel 7y ago
  This has not been my experience of using technology effectively. Without an understanding of the implementation details, you inevitably use something inefficiently or for not quite the right purpose. I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. Get to a certain scale and it's not enough to know about indexes; you need to understand the structure of b-trees, disk I/O performance, how CPU cache performance affects b-tree navigation even when index is cached in memory, how to use compound indexes effectively to reduce random access through the index, etc. The constraints of CPU and memory never go away, and if you're trying to scale something, you're going to be limited on either or both of those resources. That in turn forces you to understand execution and memory behaviour of the abstractions you're working with. All abstractions leak when pushed.
  - yakshaving_jgt 7y ago
    > I cannot imagine anyone using a database effectively on any significant amount of data without understanding… You'd be surprised just what proportion of systems running in the market operate on amounts of data you would not deem "significant". And as I said in another comment, Haskell doesn't try to pretend that computations run with no hardware constraints. > All abstractions leak when pushed Yeah. But we might have wildly different ideas for where that boundary is.
    - barrkel 7y ago
      I wouldn't be surprised because I seek employment in areas where my skills are valuable.
  - tome 7y ago
    > I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. But conversely you probably didn't have to understand what filesystem the database runs on, whether it is in a RAID array, whether the network connection was over Ethernet or T1, etc. All abstractions leak. The question is how leaky they are. In my experience Haskell abstractions are much less leaky than most.
- mehrdadn 7y ago
  There was this piece of common knowledge floating around a number of years ago about how you need to know at least 1 level of abstraction beneath you well, and have a working knowledge of the second one below it, to use your tools effectively. I don't recall where the advice floated around or came from but it was something along those lines, and it's pretty true.
  - yakshaving_jgt 7y ago
    I’m not sure I agree with that. How does this work in the context of CSS? Do people making websites need to understand how WebKit paints the screen? The word “effectively” seems rather arbitrary here too.
    - mehrdadn 7y ago
      I feel like being able to find an exception doesn't mean the rule is invalid?
      - yakshaving_jgt 7y ago
        How many exceptions should I find to invalidate the rule?
        mehrdadn 7y ago
        Enough to show it's at least on the same order of magnitude as the number of situations where the rule does hold.
    - goto11 7y ago
      I actually think you do need to understand rendering logic to some extent to use CSS effectively. For example I have seen many having a hard time understanding why it is trivially easy to align an element to the top of the screen but tricky to align something to the bottom of the screen - something which would be symmetric and equally simple in a typical application GUI framework. But understanding how layouts are generated makes this clear.
kccqzy 7y ago
> But to understand Lens? Very few people actually understand Lens. That's a lie. The basics of optics can be taught to even new Haskell programmers in an hour or so. Don't start in the deep end with generic optics with scary signatures like (Profunctor p, Functor f) => p a (f b) -> p s (f t). Start with something concrete like (String -> IO String) -> (User -> IO User) and then introduce the type variables one at a time. I've taught the basics of lenses, traversais, folds and other useful optics many times.
z3phyr 7y ago
But that is true for many other languages of the similar caliber, like Rust and C++ are also extremely complicated!
- IshKebab 7y ago
  In terms of mental concepts I will maybe give you Rust - lifetimes, and the borrow checker take some getting used to. But C++ doesn't really have any complicated concepts. Sure it has a lot of features, and some of them have complicated edges (ADL, template metaprogramming, etc.), but most application code rarely uses those things.
  - vnorilo 7y ago
    I’m not sure lifetimes are that much more complicated than the way C++ does implicit type coercion of user classes, resolution of compile time polymorphic functions, namespaces or SFINAE. I do agree it’s more like death by a thousand paper cuts rather than the torso-cleaving katana of the borrow checker. However I tend to believe any C++ codebase of consequence will run into some of this stuff, unless practices that avoid all the pitfalls are metoculously followed. Which implies a rather thorough understanding of said complexities.
    - IshKebab 7y ago
      Those are all advanced C++ features. Lifetimes smack you in the face 5 minutes into "Hello world".
  - reubenmorais 7y ago
    Maybe not complicated in terms of how abstract it is, but pretty much everything in C++ is very complicated in terms of all the little rules and exceptions and subtle interactions between behaviors and compilers leveraging UB to do insane things. You can do a lot without thinking about it but if you want to have a precise understanding of things prepare to have to read a ton of rules. It's a language lawyer's dream language.
  - wwright 7y ago
mlthoughts2018 7y ago
Another item is the crazy amount of compiler pragmas you have to use literally modify the meaning of syntax to get to a minimally viable state to work on a real project.
moocowtruck 7y ago
There is plenty to agree with here! But learning haskell isn't the biggest issue for me, I work in a large org and getting ppl to want to learn it with me or care at all is the biggest roadblock for me. The first thing they are looking for is nice IDE like and tooling experiences among many other things.
- efnx 7y ago
  I used to want that too. Spacemacs has pretty good support out of the box if you’re willing to use stack. Vim w/ the haskell-vim-now collection is good too. But soon after you realize that all you need is any text editor and a terminal (to run ghci(d)).
- agumonkey 7y ago
  May I ask you about your drafting/recruitment process regarding haskell ?
lngnmn1 7y ago
> Very few people actually understand Lens. Exactly this. Unnecessary over-abstract bullshit for narcissistic idiots to get attention. GHC does not use lenses and it seems to be ok.
coldtea 7y ago
>Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects. The analogy with Promises, which by now everybody knows, even if pedantically flawed because they don't fit this or that criterium of Monads, is quite useful to get the idea...
- falcolas 7y ago
  > which by now everybody knows I wouldn't make that assumption. Between people who program in languages that don't offer promises, and people who use promises but still get them wrong, there's not exactly what I'd call a strong base of understanding.
duckqlz 7y ago
Come on it only took me 3 semesters of category theory and I was ready to use ‘do’
- SomeOldThrow 7y ago
  How do you even take 3 semesters of category theory?
  - copperx 7y ago
    By failing twice.
- platz 7y ago
  Thinking that you need to learn "Category Theory" in order write Haskell is like saying you need to read George Boole's 'Investigation of the Laws of Thought' (1854) in order to write a conditional statement. In other words, it's not. "Category Theory" is for mathematicians and people interested in highly abstract mathematical theory. It doesn't help you write Haskell programs.
  - crimsonalucard 7y ago
    You need it for a deeper understanding of type classes and algebraic data types. You can get by without it but I would say your understanding of things like a "functor" will be flawed.
    - platz 7y ago
      This is not true. For example, The typeclassopedia contains all you need to know about functors and doesn't go into detail about the underlying Category Theory.
      - tome 7y ago
        Agreed. Having worked closely with them, I would say such Haskell luminaries as Simon PJ, Lennart Augustsson and Neil Mitchell have not "learned category theory" (and I don't think I'm being too offensive to them if I state that). In fact the only figure of highest repute in the community who puts much stock in category theory is Edward Kmett.
random314 7y ago
> You think I'm done? Let's get to Lens. Couldn't you also say that about C? If you think K&R C is enough of an introduction, wait until you see the Linux kernel!
- pjmlp 7y ago
  Or those 200+ UB use cases.
willtim 7y ago
> You think I'm done? Let's get to Lens. Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is. I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).
- karmakaze 7y ago
  Not to refute your findings but it seems unfair to call commonly selected aberrations not hidden complexity and the Java memory model as such. The only things you can compare is the complexity inherent to the task vs that which is added by the choice of implementation which is subjective based on familiarity.
  - willtim 7y ago
    I was calling out the Java memory model and concurrent programming in Java as being very complex. It's inherent to the language itself and almost impossible to change. I was only calling it "hidden" complexity as most people do not see an issue when writing single threaded programs. Concurrent programming I genuinely believe is easier in Haskell.
    - karmakaze 7y ago
      And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.
      - willtim 7y ago
        Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.
caconym_ 7y ago
I agree. I've never used Haskell at work (apart from some toy projects I did completely on my own as proof-of-concepts and/or quick-fixes) but I did spend a fair amount of time learning it myself, and that's what it took to get to the point where I could understand what was going on in "real" projects, let alone contribute at that level. And, yes, Lens is where I stopped. I grokked the basic mechanism and used the library in some limited cases but a real understanding of the whole zoo of Lens-related types always eluded me. Doubtless I could have figured it out given time, but working on my own toward my own goals it was a real slog. So I started learning Rust instead. :) Oh, and TH is an absolute nightmare. Just putting that out there. No, I don't know how I'd do it better.
- tome 7y ago
  As someone who is very interested in the experience of people learning Haskell I'd like to ask a question. Why did you stop learning Haskell after lens eluded you, rather than just turning your attention to some other aspect of Haskell instead? (After all, I've been interested in lens since it first came out seven or so years ago. I'd consider myself an expert in that type of technology and yet there are still parts I don't understand!)
  - caconym_ 7y ago
    I felt that I'd reached a point of reasonable proficiency with the language, and since I'd been learning it mostly for my own entertainment I decided to turn my attention to some other new hotness (Rust, IIRC) rather than slog through increasingly more difficult and obscure (to me) features of the language with diminishing returns for my personal projects. Entertainment is maybe not the right word, though it was definitely entertaining. Learning Haskell was the beginning of a personal renaissance in my approach to programming, and as a self-taught programmer (and professional software engineer looking to expand my horizons) that was a huge deal.
    - tome 7y ago
      > I felt that I'd reached a point of reasonable proficiency with the language Ah, well that puts quite a different spin on things!
methehack 7y ago
The article is called "you are already smart enough to WRITE Haskell" not "LEARN Haskell". I think the point is that Haskell is quite powerful and useful without learning the whole of it. Basically, nobody knows the whole of it. This is a perspective worth considering. The bones of Haskell are great and it's academic origins (god bless them) have it running around in knight's armor and a tutu (or something). You could most likely use it effectively on a properly advised, disciplined team ("we don't use language extensions"). It might also get dressed up in other clothing and be what we're all using some day. The power and expressivity seem immense. Imagine, for example, if the Rust documentation team got a hold of it. Holy crap!
KirinDave 7y ago
> you're still going to be unable to contribute to a serious code base. How is this different from Ruby with Rails, or Erlang and OTP? Or Python and Tensorsflow? > Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. I absolutely agree it can be super irritating when you find a new extension that radically changes syntax. I have made jokes and complaints you can find in my comment history on this very site about it. But I don't think this is very different from C# or C++. Folks tend to exclude and create style guides for their language. At least Haskell has the decency to label these features explicitly. Most of the really exciting libraries of 2018-2019, fused-effects and polysemy come to top of mind but there are many others, don't use terribly exotic extensions. My favorite web framework Spock also doesn't use anything to exotic either (and in fact uses nearly identical extensions to the more popuplar Servant, nearly). So I think that the community is moving forward with a consensus on what the valuable and expected extensions are. What we could do to improve this is make the consensus more accessible to newcomers both by talking about it (and not in the context of Alexis's great extensions post last year [0] or Chris Martin's suggestsions and awareness-raising efforts (e.g., [1]). Hopefully the community can agree to raft a bunch of uncontroversial extensions together and say, "This is GHC 2020, we just agree this is the default language spec unless you tell ghc otherwise." > You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens. Is this any different from ANY data structure library an the majority of its consumers though? I still run into senior software engineers with amazing history who still don't understand things like, "What is the asymptotic runtime of a modern sorting algorithm" or "what alternatives to cardinality estimation could we use here than the default library bloom filter?" or more frustratingly to me, "Why this HAMT is not in fact constant time access even in practice for your specific use case, yes they're rad all praies Bagwell but it's the wrong structure for this case." We could write a whole thing about sane uses of lens and ways to resist its excesses. Maybe now that I have finally quit twitter, I will do that this year. [0]: https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated... [1]: https://twitter.com/chris__martin/status/1102457521380442112 https://twitter.com/chris__martin/status/1102457521380442112
whateveracct 7y ago
I've only ever read half of LYAH and a few chapters of a couple other books. I don't know how Lens works under the hood. I've been writing Haskell for pay for several years with no problem. The rest of the stuff I should learned on the fly by reading Haddocks, misc articles, and plugging away with ghci & sketching ideas by hand (e.g. writing my own state monad for learning)
segmondy 7y ago
You can say this about most languages. C++, Forth, Prolog, Rust, lisp, etc. Most languages are easy to learn, and that's what the article is talking about. Mastery is a whole other topic.
paultopia 7y ago
Yes yes yes on the serious code base. Or even a non-serious code base: the problem is that everyone else's code uses these fancy features. So, for example, you read the docs to some open source library, and all the examples use these 20 language extensions. So congratulations, you can't tell what the code does without learning them.
pyrale 7y ago
> Anyone who says otherwise is lying. Anyone who has experienced things you didn't should be discredited, because obviously your personal take is the definitive take about it.

by li4ick 7y ago

yakshaving_jgt 7y ago

You don’t need to understand the internals of a thing to use the thing.

Quekid5 7y ago
This is exactly right. I use lenses all the time, but I have absolutely no idea how they're actually implemented, nor do I need to know. This is abstraction. If there's one thing Haskell does well it's abstraction. EDIT: It's really bizarre. We see these same responses to all the Haskell-or-Idris-or-whatever threads -- I wonder if there's some imposter syndrome going where "I can't immediately read/write Haskell" somehow morphs into "Haskell is useless". IME it's really rare for people who actually program in Haskell to have serious issues with the language. Yes there are issues from a smaller ecosystem, package management was bad (Stack fixed that), etc. etc. but there are very few fundamental problems with the language. Something so small as just Pattern Matching is a huge increase in productivity. Thankfully, quite a few languages have adopted pattern matching these days (Scala, Rust, TS, maybe even C++23?). (The really big payoff comes from granular effects, but I'm sure the rest of the world will realize in about 20-30 years' time. The Erlang people already have, albeit in a different way.)
- marcosdumay 7y ago
  People look at weird syntax and discussions about things that have no resemblance to the problem they are facing, and conclude it must not be useful for anything real. Yes, those problems have no resemblance to any real problem because of abstraction, but most people's experience with abstraction is in a Java-like language where nothing good ever gets out of it.
mantap 7y ago
Only if you have infinite memory. In theory there's no difference between folding left and folding right (if associative), in practice there is a right way and a wrong way.
- yakshaving_jgt 7y ago
  > In theory there's no difference between folding left and folding right There's no difference in practice either for a sufficiently small dataset. > in practice there is a right way and a wrong way Sure, but that's true of all technologies. Yes, Haskell can't help you escape the limitations of our world — or indeed our hardware — but it doesn't pretend to either.
  - magicalhippo 7y ago
    > There's no difference in practice either for a sufficiently small dataset. As a non-Haskell user, just for reference what's "sufficiently small"?
    - yakshaving_jgt 7y ago
      It depends on your needs. This is neither constrained to Haskell specifically nor functional programming more generally. If you were building a website for your local Italian restaurant, what would your needs be? Do you need an ElasticSearch cluster to handle customer menu item queries? Do you need a database at all? In Haskell's case it's best to avoid lists entirely, as they're _usually_ not the optimal data structure. But best for whom? Does the beginner care that a set operation would be more effective than a list operation for their given use-case?
      - magicalhippo 7y ago
        Not sure how that's an answer to my question? In my day job, I frequently generate records returned from a database along with local changes to be posted later, and say compute the sum of one of the columns. That sounded like something I'd use folding for, with my limited knowledge, so I was just curious at which point (order of magnitude) I'd have to worry about doing it this way or that. But if lists are not to be used, what should I use for the above? And will the data structure you propose be fine with either fold?
tutfbhuf 7y ago
You don’t need to understand the internals of a thing, until you do. Everything works fine as described in documentation until it doesn't for your use case. You might be lucky and find help from stackoverflow, otherwise you need someone who really grok it.
- pwm 7y ago
  Sure and at that point you need to learn those internals. That's just the way it is with everything, no?
  - vbezhenar 7y ago
    When things go wrong, you might not have time to do so. When my project started to leak memory at enormous rate, I was able to find the issue quickly enough. But if I didn't know how all those things work, I would spend weeks or months learning all those things. Restarting application every 10 minutes for a week is not a good idea.
    - pwm 7y ago
      How is this different for Haskell than with anything else? If you want to be an expert in something, anything you do need to put in the work and learn it inside-out. There is no royal road. I fail to see how this is specific to Haskell...
      - ukj 7y ago
        It boils down to the steepness of the learning curves. If I am in the business of system reliability, I will choose the language with shallower rabbit holes. Abstraction layers are great for builders and terrible for fixers. I am both, so I need to strike a balance.
      - vbezhenar 7y ago
        I agree with you, I don't think that it's different for Haskell.
- 7y ago
barrkel 7y ago
This has not been my experience of using technology effectively. Without an understanding of the implementation details, you inevitably use something inefficiently or for not quite the right purpose. I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. Get to a certain scale and it's not enough to know about indexes; you need to understand the structure of b-trees, disk I/O performance, how CPU cache performance affects b-tree navigation even when index is cached in memory, how to use compound indexes effectively to reduce random access through the index, etc. The constraints of CPU and memory never go away, and if you're trying to scale something, you're going to be limited on either or both of those resources. That in turn forces you to understand execution and memory behaviour of the abstractions you're working with. All abstractions leak when pushed.
- yakshaving_jgt 7y ago
  > I cannot imagine anyone using a database effectively on any significant amount of data without understanding… You'd be surprised just what proportion of systems running in the market operate on amounts of data you would not deem "significant". And as I said in another comment, Haskell doesn't try to pretend that computations run with no hardware constraints. > All abstractions leak when pushed Yeah. But we might have wildly different ideas for where that boundary is.
  - barrkel 7y ago
    I wouldn't be surprised because I seek employment in areas where my skills are valuable.
- tome 7y ago
  > I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. But conversely you probably didn't have to understand what filesystem the database runs on, whether it is in a RAID array, whether the network connection was over Ethernet or T1, etc. All abstractions leak. The question is how leaky they are. In my experience Haskell abstractions are much less leaky than most.
mehrdadn 7y ago
There was this piece of common knowledge floating around a number of years ago about how you need to know at least 1 level of abstraction beneath you well, and have a working knowledge of the second one below it, to use your tools effectively. I don't recall where the advice floated around or came from but it was something along those lines, and it's pretty true.
- yakshaving_jgt 7y ago
  I’m not sure I agree with that. How does this work in the context of CSS? Do people making websites need to understand how WebKit paints the screen? The word “effectively” seems rather arbitrary here too.
  - mehrdadn 7y ago
    I feel like being able to find an exception doesn't mean the rule is invalid?
    - yakshaving_jgt 7y ago
      How many exceptions should I find to invalidate the rule?
      - mehrdadn 7y ago
        Enough to show it's at least on the same order of magnitude as the number of situations where the rule does hold.
  - goto11 7y ago
    I actually think you do need to understand rendering logic to some extent to use CSS effectively. For example I have seen many having a hard time understanding why it is trivially easy to align an element to the top of the screen but tricky to align something to the bottom of the screen - something which would be symmetric and equally simple in a typical application GUI framework. But understanding how layouts are generated makes this clear.

kccqzy 7y ago

> But to understand Lens? Very few people actually understand Lens. That's a lie. The basics of optics can be taught to even new Haskell programmers in an hour or so. Don't start in the deep end with generic optics with scary signatures like (Profunctor p, Functor f) => p a (f b) -> p s (f t). Start with something concrete like (String -> IO String) -> (User -> IO User) and then introduce the type variables one at a time. I've taught the basics of lenses, traversais, folds and other useful optics many times.

z3phyr 7y ago

But that is true for many other languages of the similar caliber, like Rust and C++ are also extremely complicated!

IshKebab 7y ago
In terms of mental concepts I will maybe give you Rust - lifetimes, and the borrow checker take some getting used to. But C++ doesn't really have any complicated concepts. Sure it has a lot of features, and some of them have complicated edges (ADL, template metaprogramming, etc.), but most application code rarely uses those things.
- vnorilo 7y ago
  I’m not sure lifetimes are that much more complicated than the way C++ does implicit type coercion of user classes, resolution of compile time polymorphic functions, namespaces or SFINAE. I do agree it’s more like death by a thousand paper cuts rather than the torso-cleaving katana of the borrow checker. However I tend to believe any C++ codebase of consequence will run into some of this stuff, unless practices that avoid all the pitfalls are metoculously followed. Which implies a rather thorough understanding of said complexities.
  - IshKebab 7y ago
    Those are all advanced C++ features. Lifetimes smack you in the face 5 minutes into "Hello world".
- reubenmorais 7y ago
  Maybe not complicated in terms of how abstract it is, but pretty much everything in C++ is very complicated in terms of all the little rules and exceptions and subtle interactions between behaviors and compilers leveraging UB to do insane things. You can do a lot without thinking about it but if you want to have a precise understanding of things prepare to have to read a ton of rules. It's a language lawyer's dream language.
- wwright 7y ago

mlthoughts2018 7y ago

Another item is the crazy amount of compiler pragmas you have to use literally modify the meaning of syntax to get to a minimally viable state to work on a real project.

moocowtruck 7y ago

There is plenty to agree with here! But learning haskell isn't the biggest issue for me, I work in a large org and getting ppl to want to learn it with me or care at all is the biggest roadblock for me. The first thing they are looking for is nice IDE like and tooling experiences among many other things.

efnx 7y ago
I used to want that too. Spacemacs has pretty good support out of the box if you’re willing to use stack. Vim w/ the haskell-vim-now collection is good too. But soon after you realize that all you need is any text editor and a terminal (to run ghci(d)).
agumonkey 7y ago
May I ask you about your drafting/recruitment process regarding haskell ?

lngnmn1 7y ago

> Very few people actually understand Lens. Exactly this. Unnecessary over-abstract bullshit for narcissistic idiots to get attention. GHC does not use lenses and it seems to be ok.

coldtea 7y ago

>Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects. The analogy with Promises, which by now everybody knows, even if pedantically flawed because they don't fit this or that criterium of Monads, is quite useful to get the idea...

falcolas 7y ago
> which by now everybody knows I wouldn't make that assumption. Between people who program in languages that don't offer promises, and people who use promises but still get them wrong, there's not exactly what I'd call a strong base of understanding.

duckqlz 7y ago

Come on it only took me 3 semesters of category theory and I was ready to use ‘do’

SomeOldThrow 7y ago
How do you even take 3 semesters of category theory?
- copperx 7y ago
  By failing twice.
platz 7y ago
Thinking that you need to learn "Category Theory" in order write Haskell is like saying you need to read George Boole's 'Investigation of the Laws of Thought' (1854) in order to write a conditional statement. In other words, it's not. "Category Theory" is for mathematicians and people interested in highly abstract mathematical theory. It doesn't help you write Haskell programs.
- crimsonalucard 7y ago
  You need it for a deeper understanding of type classes and algebraic data types. You can get by without it but I would say your understanding of things like a "functor" will be flawed.
  - platz 7y ago
    This is not true. For example, The typeclassopedia contains all you need to know about functors and doesn't go into detail about the underlying Category Theory.
    - tome 7y ago
      Agreed. Having worked closely with them, I would say such Haskell luminaries as Simon PJ, Lennart Augustsson and Neil Mitchell have not "learned category theory" (and I don't think I'm being too offensive to them if I state that). In fact the only figure of highest repute in the community who puts much stock in category theory is Edward Kmett.

random314 7y ago

> You think I'm done? Let's get to Lens. Couldn't you also say that about C? If you think K&R C is enough of an introduction, wait until you see the Linux kernel!

pjmlp 7y ago
Or those 200+ UB use cases.

willtim 7y ago

> You think I'm done? Let's get to Lens. Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is. I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).

karmakaze 7y ago
Not to refute your findings but it seems unfair to call commonly selected aberrations not hidden complexity and the Java memory model as such. The only things you can compare is the complexity inherent to the task vs that which is added by the choice of implementation which is subjective based on familiarity.
- willtim 7y ago
  I was calling out the Java memory model and concurrent programming in Java as being very complex. It's inherent to the language itself and almost impossible to change. I was only calling it "hidden" complexity as most people do not see an issue when writing single threaded programs. Concurrent programming I genuinely believe is easier in Haskell.
  - karmakaze 7y ago
    And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.
    - willtim 7y ago
      Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.

caconym_ 7y ago

I agree. I've never used Haskell at work (apart from some toy projects I did completely on my own as proof-of-concepts and/or quick-fixes) but I did spend a fair amount of time learning it myself, and that's what it took to get to the point where I could understand what was going on in "real" projects, let alone contribute at that level. And, yes, Lens is where I stopped. I grokked the basic mechanism and used the library in some limited cases but a real understanding of the whole zoo of Lens-related types always eluded me. Doubtless I could have figured it out given time, but working on my own toward my own goals it was a real slog. So I started learning Rust instead. :) Oh, and TH is an absolute nightmare. Just putting that out there. No, I don't know how I'd do it better.

tome 7y ago
As someone who is very interested in the experience of people learning Haskell I'd like to ask a question. Why did you stop learning Haskell after lens eluded you, rather than just turning your attention to some other aspect of Haskell instead? (After all, I've been interested in lens since it first came out seven or so years ago. I'd consider myself an expert in that type of technology and yet there are still parts I don't understand!)
- caconym_ 7y ago
  I felt that I'd reached a point of reasonable proficiency with the language, and since I'd been learning it mostly for my own entertainment I decided to turn my attention to some other new hotness (Rust, IIRC) rather than slog through increasingly more difficult and obscure (to me) features of the language with diminishing returns for my personal projects. Entertainment is maybe not the right word, though it was definitely entertaining. Learning Haskell was the beginning of a personal renaissance in my approach to programming, and as a self-taught programmer (and professional software engineer looking to expand my horizons) that was a huge deal.
  - tome 7y ago
    > I felt that I'd reached a point of reasonable proficiency with the language Ah, well that puts quite a different spin on things!

methehack 7y ago

The article is called "you are already smart enough to WRITE Haskell" not "LEARN Haskell". I think the point is that Haskell is quite powerful and useful without learning the whole of it. Basically, nobody knows the whole of it. This is a perspective worth considering. The bones of Haskell are great and it's academic origins (god bless them) have it running around in knight's armor and a tutu (or something). You could most likely use it effectively on a properly advised, disciplined team ("we don't use language extensions"). It might also get dressed up in other clothing and be what we're all using some day. The power and expressivity seem immense. Imagine, for example, if the Rust documentation team got a hold of it. Holy crap!

KirinDave 7y ago

> you're still going to be unable to contribute to a serious code base. How is this different from Ruby with Rails, or Erlang and OTP? Or Python and Tensorsflow? > Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. I absolutely agree it can be super irritating when you find a new extension that radically changes syntax. I have made jokes and complaints you can find in my comment history on this very site about it. But I don't think this is very different from C# or C++. Folks tend to exclude and create style guides for their language. At least Haskell has the decency to label these features explicitly. Most of the really exciting libraries of 2018-2019, fused-effects and polysemy come to top of mind but there are many others, don't use terribly exotic extensions. My favorite web framework Spock also doesn't use anything to exotic either (and in fact uses nearly identical extensions to the more popuplar Servant, nearly). So I think that the community is moving forward with a consensus on what the valuable and expected extensions are. What we could do to improve this is make the consensus more accessible to newcomers both by talking about it (and not in the context of Alexis's great extensions post last year [0] or Chris Martin's suggestsions and awareness-raising efforts (e.g., [1]). Hopefully the community can agree to raft a bunch of uncontroversial extensions together and say, "This is GHC 2020, we just agree this is the default language spec unless you tell ghc otherwise." > You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens. Is this any different from ANY data structure library an the majority of its consumers though? I still run into senior software engineers with amazing history who still don't understand things like, "What is the asymptotic runtime of a modern sorting algorithm" or "what alternatives to cardinality estimation could we use here than the default library bloom filter?" or more frustratingly to me, "Why this HAMT is not in fact constant time access even in practice for your specific use case, yes they're rad all praies Bagwell but it's the wrong structure for this case." We could write a whole thing about sane uses of lens and ways to resist its excesses. Maybe now that I have finally quit twitter, I will do that this year. [0]: https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated... [1]: https://twitter.com/chris__martin/status/1102457521380442112 https://twitter.com/chris__martin/status/1102457521380442112

whateveracct 7y ago

I've only ever read half of LYAH and a few chapters of a couple other books. I don't know how Lens works under the hood. I've been writing Haskell for pay for several years with no problem. The rest of the stuff I should learned on the fly by reading Haddocks, misc articles, and plugging away with ghci & sketching ideas by hand (e.g. writing my own state monad for learning)

segmondy 7y ago

You can say this about most languages. C++, Forth, Prolog, Rust, lisp, etc. Most languages are easy to learn, and that's what the article is talking about. Mastery is a whole other topic.

paultopia 7y ago

Yes yes yes on the serious code base. Or even a non-serious code base: the problem is that everyone else's code uses these fancy features. So, for example, you read the docs to some open source library, and all the examples use these 20 language extensions. So congratulations, you can't tell what the code does without learning them.

pyrale 7y ago

> Anyone who says otherwise is lying. Anyone who has experienced things you didn't should be discredited, because obviously your personal take is the definitive take about it.