4 ms·

I agree with you, and I'd say that we are perhaps in the bottom, or the middle of the S curve in software. Despite all the technological progress in hardware, o

I agree with you, and I'd say that we are perhaps in the bottom, or the middle of the S curve in software. Despite all the technological progress in hardware, our software is very slow and buggy. We end up increasing complexity in the name of 'productivity' and going up in abstractions, but we end up lacking fine-grained control and performance in modern systems. I hope that we see a paradigm shift back towards writing robust and performant systems instead of stacking abstractions. Sure, Monads and Transformers are all fun to use, make code coincise and are very satisfying when they compose well, but, what's the hidden cost, and is it worth it? As a user that encounters bugs at a disproportionally high rate, I'd say no. The trade-off in increasing abstractions is not worth the trade-off.

jolux 6y ago
Your experience of using Haskell is that it causes more bugs than less abstract languages?
- PartiallyTyped 6y ago
  No, on the contrary, my experience with Haskell is that my code is mostly bug free, but ends up less performant because you can accidentally create huge trunks in the heap and it consumes too much mental stamina. However, there exists an intermediate plane of abstraction over C and under Haskell that is absolutely horrendous and results in all sorts of weird bugs and unpredictable situations.
  - tachyonbeam 6y ago
    I've heard people say that Haskell would be better with eager rather than lazy evaluation, because of the mental burden that it causes. IMO that doesn't seem like a hard problem to solve. We can design pure functional languages with eager evaluation.
    - zozbot234 6y ago
      Haskell would be better if it used polarity and focusing to make both strict and lazy evaluation first-class citizens in the language. A stricrly-evaluated counterpart to Haskell is just ML, which we've had since the 1970s.
      - tachyonbeam 6y ago
        I've coded in OCaml, which wasn't pure immutable, but rather immutable by default. Because it has mutability, that removes the focus on immutable data structures, making it a very different language.
      - jose_zap 6y ago
        You can make any module strict by using the XStrict language pragma in Haskell.
  - jolux 6y ago
    What about Rust?
    - PartiallyTyped 6y ago
      It solves memory problems and certainly doesn't shoot your foot with destructors, weird moves and so on like C++, it lacks a garbage collector which imho is a big plus (though, as C# and Java show it is not necessarily a big problem), and I prefer the trait system over than Cxx's virtual classes/interfaces. I also like that the compiler is very helpful, it introduces some friction while writing, but I suppose that is my lack of expertise.
UnpossibleJim 6y ago
I think this has more to do with management timeline expectations and income valuation than software development. I do understand that they're almost inseparable, as software has to make money. But, timelines need to take into account the "craft" of software creation and not just the desk hours, for lack of better terms =/ Short timelines and quick turn arounds don't leave time for refactoring and quality code creation. First passes tend to be the final draft, more often then not.
- PartiallyTyped 6y ago
  This issue however, exists in more than just commercial software. Personal example, OSes feel bloated, I switched from BigSur to Mojave in my 2018MBPro and I saw significant improvements in responsiveness with virtually no change in usage behavior. Even software whose supposed features are stability and speed feel bloated, e.g. weird bugs in Unity, photoshop is sluggish without any significant increase in the visible features.
hypertele-Xii 6y ago
It makes sense though, the cost of hardware per performance has nosedove, whereas the cost of human labor has probably gone up? Why pay devs to write fast code when you can buy faster computers faster and cheaper? I wonder when the trend reverses. It must, at some point, mustn't it?
- PartiallyTyped 6y ago
  > Why pay devs to write fast code when you can buy faster computers faster and cheaper? Because you can do more in the same time. Speed and responsiveness are features, the issue is, the general population has come to accept that bugs are not only acceptable, but just that, 'bugs' that you can shoo away by restarting the machine/program. > I wonder when the trend reverses. It must, at some point, mustn't it? I hope so. As we have seen with spectre and now AMD's equivalent, speculative execution is risky and very complex to get right. We can't rely on ever increasing complexity on CPUs and fabrication processes, at some point quantum mechanics will bite back.

jolux 6y ago

Your experience of using Haskell is that it causes more bugs than less abstract languages?

PartiallyTyped 6y ago
No, on the contrary, my experience with Haskell is that my code is mostly bug free, but ends up less performant because you can accidentally create huge trunks in the heap and it consumes too much mental stamina. However, there exists an intermediate plane of abstraction over C and under Haskell that is absolutely horrendous and results in all sorts of weird bugs and unpredictable situations.
- tachyonbeam 6y ago
  I've heard people say that Haskell would be better with eager rather than lazy evaluation, because of the mental burden that it causes. IMO that doesn't seem like a hard problem to solve. We can design pure functional languages with eager evaluation.
  - zozbot234 6y ago
    Haskell would be better if it used polarity and focusing to make both strict and lazy evaluation first-class citizens in the language. A stricrly-evaluated counterpart to Haskell is just ML, which we've had since the 1970s.
    - tachyonbeam 6y ago
      I've coded in OCaml, which wasn't pure immutable, but rather immutable by default. Because it has mutability, that removes the focus on immutable data structures, making it a very different language.
    - jose_zap 6y ago
      You can make any module strict by using the XStrict language pragma in Haskell.
- jolux 6y ago
  What about Rust?
  - PartiallyTyped 6y ago
    It solves memory problems and certainly doesn't shoot your foot with destructors, weird moves and so on like C++, it lacks a garbage collector which imho is a big plus (though, as C# and Java show it is not necessarily a big problem), and I prefer the trait system over than Cxx's virtual classes/interfaces. I also like that the compiler is very helpful, it introduces some friction while writing, but I suppose that is my lack of expertise.

UnpossibleJim 6y ago

I think this has more to do with management timeline expectations and income valuation than software development. I do understand that they're almost inseparable, as software has to make money. But, timelines need to take into account the "craft" of software creation and not just the desk hours, for lack of better terms =/ Short timelines and quick turn arounds don't leave time for refactoring and quality code creation. First passes tend to be the final draft, more often then not.

PartiallyTyped 6y ago
This issue however, exists in more than just commercial software. Personal example, OSes feel bloated, I switched from BigSur to Mojave in my 2018MBPro and I saw significant improvements in responsiveness with virtually no change in usage behavior. Even software whose supposed features are stability and speed feel bloated, e.g. weird bugs in Unity, photoshop is sluggish without any significant increase in the visible features.

hypertele-Xii 6y ago

It makes sense though, the cost of hardware per performance has nosedove, whereas the cost of human labor has probably gone up? Why pay devs to write fast code when you can buy faster computers faster and cheaper? I wonder when the trend reverses. It must, at some point, mustn't it?

PartiallyTyped 6y ago
> Why pay devs to write fast code when you can buy faster computers faster and cheaper? Because you can do more in the same time. Speed and responsiveness are features, the issue is, the general population has come to accept that bugs are not only acceptable, but just that, 'bugs' that you can shoo away by restarting the machine/program. > I wonder when the trend reverses. It must, at some point, mustn't it? I hope so. As we have seen with spectre and now AMD's equivalent, speculative execution is risky and very complex to get right. We can't rely on ever increasing complexity on CPUs and fabrication processes, at some point quantum mechanics will bite back.