5 ms·

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?
        7y ago
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.

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?
      - 7y ago

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.