4 ms·

> 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

> 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.
colordrops 5y ago
Other than the constraint of time, low level systems understanding and Haskell are orthogonal and not at odds. Why not both?

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.

colordrops 5y ago

Other than the constraint of time, low level systems understanding and Haskell are orthogonal and not at odds. Why not both?