4 ms·

I don't think I even know what you mean by 'how computers really work'. Isn't the point of languages to create abstractions so I don't need to learn how a CPU w

I don't think I even know what you mean by 'how computers really work'. Isn't the point of languages to create abstractions so I don't need to learn how a CPU works? I understand why Haskell will never become the language of industry. Lazy evaluation, a hundred and one extensions, the fact you would need to retrain everybody... but I'm not really interested in that. Haskell is a place for ideas, not really practicality. This has been gone over time and again. The reason I use Haskell for personal projects is because they all end up being very few lines of code compared to imperative versions, and it usually just works. For me that's enough benefit to learn it. It would be nice if an ML language actually became popular at some point. But that won't be for a long time.

ilovecaching 5y ago
> Isn't the point of languages to create abstractions so I don't need to learn how a CPU works? This is the entire problem with Haskell. This isn't the reality we live in. In our world there's a concrete need to understand performance at the level of the hardware and the kernel. Let's not even talk about compilers, which have to make many tradeoffs and often produce sub-optimal code without human guidance. The kernel itself doesn't always make the right decisions on where to place workloads, how to balance IRQs, moving tasks between cores, etc. If you want to become a better software engineer, learn how your computer actually runs code, don't learn Haskell. Edit: It's not letting me respond to your reply directly, so here is my reply: We all have different experiences in the industry, but my experience has been that I often need to diagnose and solve performance issues that involve using perf, ftrace, bpf, pprof, etc. I'm not saying we should all write C, I'm saying that you need to know how to look under the hood when you're using a language that does more work for you. Understanding how to look under the hood (again this is my experience) and know what you're looking at is far more important than mastering high level language concepts. You can change out the language, but the kernel, hardware, etc. remain the same. It's also important to understand these things because security is only becoming more important and attackers exploit the gaps in your knowledge. Spectre was a huge deal and it requires an understanding of how a pipeline works, how your program interacts with the cache, etc. If I ask you how to find out how may instructions your program ran, how many branches it took, how many branch mispredicts there were, if it was exhibiting false sharing, etc. could you tell me? You can't optimize something or know if you're being attacked if you don't understand how things work or what the baselines are.
- erik_seaberg 5y ago
  If I want to brute force a problem on an underpowered machine, I need to focus on pushing its exact limits. But if I want to solve a very complex problem, I need to not be distracted by them. I like Rust but I’m not sure how often the extra specificity from the dev pays for itself in hardware.
- Alekhine 5y ago
  I don't think this is even a Haskell criticism as much as it is a software engineer criticism. You can be ignorant about hardware in most languages, especially Python. Going by what you've said, it sounds like you want the industry to return to C/C++ for everything. As for Haskell, I'm not experienced enough to make a real defense of it, but I've been told the compiler is pretty damn good. It's a decently fast language. I don't know how it compares to something like Go, and of course for very high-performance needs you probably shouldn't use it, but letting it take over isn't the worst thing in the world, and you can still use knowledge of hardware to make it faster. But if that's not enough, just use Rust or something. It's basically Haskell-lite anyway.
  - azurelake 5y ago
    Laziness by default makes it extremely hard to reason about performance, at least for me. So Rust is actually far closer to C/C++ than Haskell lite in terms of being able to think about how the code you write maps to the physical machine.
  - Karrot_Kream 5y ago
    > You can be ignorant about hardware in most languages, especially Python You're thinking in terms of languages and not systems. If you've ever built systems at scale, you'll know that abstractions break down. The best of us write leaky abstractions. When the time comes to debug a leaky abstraction, you need to open up the hood. This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. That's when you need to break down the abstraction layers and break out tools like iperf or Wireshark. Languages like Haskell create such a different execution model (with monads and lazy execution) that it makes it really hard to break through its abstractions and understand what's going on. I've had similar experiences to the author. I've written Haskell for fun and worked in Scala. Most of the folks who have your viewpoint have (in my experience) not worked in a situation where these issues come up. Either the scale of the problem is low so powerful abstractions are more powerful than deconstructing them or they work in problem domains where standards around correctness are a lot lower and programmer happiness is paramount. But if you've ever been in a position where you need to write a high-scale or high-reliability application, languages with highly abstract execution models prove more a liability than an asset. In that regard both Erlang and Rust offer a much more concrete execution model that's a lot easier to reason about than Haskell or monadic Scala offers, at least in my experience.
FpUser 5y ago
>"Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?" In a world where CPU is infinitely fast and has infinitely large RAM
- chii 5y ago
  it's not binary - an abstraction makes for easier, lowers the barrier (in the sense that you can get away with knowing less but still can make it work).
charcircuit 5y ago
>I don't think I even know what you mean by 'how computers really work'. Haskell is a top down language. It is an abstraction over a variation of typed lambda calculus. The compiler compiles haskell into this lambda calculus and then has to figure out how to efficiently evaluate the terms. One can argue that with a "sufficiently smart compiler" it can make things run fast. Unfortunately, this is not really the case and it is not easy to reason what code is being generated for what you write. Are optimizations like deforestation kicking in? There are also plenty of abstractions that the Haskell community gets excited over even though they come with performance impacts. These abstractions may be entertaining, but they are not necessarily practical. If you go deeper in the rabbit hole of FP you might find people talking about how with homotopy type theory a compiler could recognize code and substitute it with a more "optimal" version. Unfortunately, a mythical "sufficiently smart compiler" does not exist and even if it did the compile time would be impacted in trying to optimize your programs. The "how computers really work" argument is that languages should instead be abstractions over the CPU (or other hardware devices) instead of abstraction over computation itself (alternatively you could also see it as an abstraction over graph reduction based hardware but since we aren't running it on such hardware that is problematic). In the real world we have real concerns about resource usages such as processing time and memory. Abstractions over the CPU makes it easier to have a general idea on what the code that is being generated looks like. It may be the case that your use case is not that sensitive to performance or memory usage so continue to have fun using Haskell. As you said Haskell is "not really practical." To your point of Haskell having very few lines of code compared to imperative version I feel that is likely just a matter of what is in the standard library / what libraries you used.
- kaba0 5y ago
  That line of reasoning may have been ok 2 decades ago, but the current CPU model isn’t necessarily serial either, anymore. Sure, you can express nigh everything in C++, but defaults matter — a parallel algorithm may well be in the “worth it to implement” category for Haskell, and be in the “no way that we can make it work” category for some lower level language. Don’t get me wrong, sure, the memory model of haskell may also not be the best which has probably the biggest performance impact, but I really don’t think that there is as much of a difference between comparable high level languages to haskell, so it can absolutely be a good choice for certain applications.

ilovecaching 5y ago

> Isn't the point of languages to create abstractions so I don't need to learn how a CPU works? This is the entire problem with Haskell. This isn't the reality we live in. In our world there's a concrete need to understand performance at the level of the hardware and the kernel. Let's not even talk about compilers, which have to make many tradeoffs and often produce sub-optimal code without human guidance. The kernel itself doesn't always make the right decisions on where to place workloads, how to balance IRQs, moving tasks between cores, etc. If you want to become a better software engineer, learn how your computer actually runs code, don't learn Haskell. Edit: It's not letting me respond to your reply directly, so here is my reply: We all have different experiences in the industry, but my experience has been that I often need to diagnose and solve performance issues that involve using perf, ftrace, bpf, pprof, etc. I'm not saying we should all write C, I'm saying that you need to know how to look under the hood when you're using a language that does more work for you. Understanding how to look under the hood (again this is my experience) and know what you're looking at is far more important than mastering high level language concepts. You can change out the language, but the kernel, hardware, etc. remain the same. It's also important to understand these things because security is only becoming more important and attackers exploit the gaps in your knowledge. Spectre was a huge deal and it requires an understanding of how a pipeline works, how your program interacts with the cache, etc. If I ask you how to find out how may instructions your program ran, how many branches it took, how many branch mispredicts there were, if it was exhibiting false sharing, etc. could you tell me? You can't optimize something or know if you're being attacked if you don't understand how things work or what the baselines are.

erik_seaberg 5y ago
If I want to brute force a problem on an underpowered machine, I need to focus on pushing its exact limits. But if I want to solve a very complex problem, I need to not be distracted by them. I like Rust but I’m not sure how often the extra specificity from the dev pays for itself in hardware.
Alekhine 5y ago
I don't think this is even a Haskell criticism as much as it is a software engineer criticism. You can be ignorant about hardware in most languages, especially Python. Going by what you've said, it sounds like you want the industry to return to C/C++ for everything. As for Haskell, I'm not experienced enough to make a real defense of it, but I've been told the compiler is pretty damn good. It's a decently fast language. I don't know how it compares to something like Go, and of course for very high-performance needs you probably shouldn't use it, but letting it take over isn't the worst thing in the world, and you can still use knowledge of hardware to make it faster. But if that's not enough, just use Rust or something. It's basically Haskell-lite anyway.
- azurelake 5y ago
  Laziness by default makes it extremely hard to reason about performance, at least for me. So Rust is actually far closer to C/C++ than Haskell lite in terms of being able to think about how the code you write maps to the physical machine.
- Karrot_Kream 5y ago
  > You can be ignorant about hardware in most languages, especially Python You're thinking in terms of languages and not systems. If you've ever built systems at scale, you'll know that abstractions break down. The best of us write leaky abstractions. When the time comes to debug a leaky abstraction, you need to open up the hood. This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. That's when you need to break down the abstraction layers and break out tools like iperf or Wireshark. Languages like Haskell create such a different execution model (with monads and lazy execution) that it makes it really hard to break through its abstractions and understand what's going on. I've had similar experiences to the author. I've written Haskell for fun and worked in Scala. Most of the folks who have your viewpoint have (in my experience) not worked in a situation where these issues come up. Either the scale of the problem is low so powerful abstractions are more powerful than deconstructing them or they work in problem domains where standards around correctness are a lot lower and programmer happiness is paramount. But if you've ever been in a position where you need to write a high-scale or high-reliability application, languages with highly abstract execution models prove more a liability than an asset. In that regard both Erlang and Rust offer a much more concrete execution model that's a lot easier to reason about than Haskell or monadic Scala offers, at least in my experience.

FpUser 5y ago

>"Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?" In a world where CPU is infinitely fast and has infinitely large RAM

chii 5y ago
it's not binary - an abstraction makes for easier, lowers the barrier (in the sense that you can get away with knowing less but still can make it work).

charcircuit 5y ago

>I don't think I even know what you mean by 'how computers really work'. Haskell is a top down language. It is an abstraction over a variation of typed lambda calculus. The compiler compiles haskell into this lambda calculus and then has to figure out how to efficiently evaluate the terms. One can argue that with a "sufficiently smart compiler" it can make things run fast. Unfortunately, this is not really the case and it is not easy to reason what code is being generated for what you write. Are optimizations like deforestation kicking in? There are also plenty of abstractions that the Haskell community gets excited over even though they come with performance impacts. These abstractions may be entertaining, but they are not necessarily practical. If you go deeper in the rabbit hole of FP you might find people talking about how with homotopy type theory a compiler could recognize code and substitute it with a more "optimal" version. Unfortunately, a mythical "sufficiently smart compiler" does not exist and even if it did the compile time would be impacted in trying to optimize your programs. The "how computers really work" argument is that languages should instead be abstractions over the CPU (or other hardware devices) instead of abstraction over computation itself (alternatively you could also see it as an abstraction over graph reduction based hardware but since we aren't running it on such hardware that is problematic). In the real world we have real concerns about resource usages such as processing time and memory. Abstractions over the CPU makes it easier to have a general idea on what the code that is being generated looks like. It may be the case that your use case is not that sensitive to performance or memory usage so continue to have fun using Haskell. As you said Haskell is "not really practical." To your point of Haskell having very few lines of code compared to imperative version I feel that is likely just a matter of what is in the standard library / what libraries you used.

kaba0 5y ago
That line of reasoning may have been ok 2 decades ago, but the current CPU model isn’t necessarily serial either, anymore. Sure, you can express nigh everything in C++, but defaults matter — a parallel algorithm may well be in the “worth it to implement” category for Haskell, and be in the “no way that we can make it work” category for some lower level language. Don’t get me wrong, sure, the memory model of haskell may also not be the best which has probably the biggest performance impact, but I really don’t think that there is as much of a difference between comparable high level languages to haskell, so it can absolutely be a good choice for certain applications.