5 ms·

I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.

josephg 5y ago
I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.
- slmjkdbtl 5y ago
  I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
  - ncmncm 5y ago
    Yet, we may characterize lazy programmers as hoping to use immutable data structures and pay no attention to performance. We all know that performance takes extra work to ensure, then, and is uncertain even with the extra work.
  - drenvuk 5y ago
    I would. Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it. Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best practices that have cropped up in the past few years has been more for helping teams of people deal with growing code bases rather than helping programmers deal with limited hardware. In computer science this should be self explanatory. For optimal runtimes the act of making copies is avoided. Why people usually seem to ignore the fact that they're wasting cycles for the sake of the holy grail of clean, functional programming and immutability has eluded me. Typescript, focus on immutability, microservices even. I hate all of them but they have their purposes. They solve people problems. Maximizing hardware performance is not in the list though.
    - slmjkdbtl 5y ago
      Yeah now I wouldn't use immutable structure in an performance intensive application, but I do _hope_ one day we have some cycles to spare and can use it without worrying too much. To me it's like garbage collection, it's nice to have if we can afford some performance cost.
    - rackjack 5y ago
      Abstraction is at the core of programming... complaining about people not "properly managing mutable state" is like complaining about choosing Java over C because they're not "properly" managing memory and instead using a garbage collector. Maximizing hardware performance is, truth be told, largely irrelevant for the vast majority of applications. If they can meet their goals/deadlines/whatever, you can call them lazy, but I think most would call them efficient. Though I must admit, every time my browser lags when viewing what SHOULD be a static site, I do die a little inside.
- askonomm 5y ago
  You may call functional programmers who prefer immutable data structures lazy because we want to actually understand what we create, but I don't see how the 10 billion layers of abstractions and state duplications somehow end up making better software.
  - josephg 5y ago
    I agree - I think having 10 billon layers of abstraction is worse for everyone. It’s buggier, more expensive to make and (ironically) often slower in practice anyway; because you can’t optimize what you can’t understand. Java style OO has a lot to answer for. Functional programming is great. What’s not great is loading the entire closure VM environment into my browser - resulting in the software running (in this case) 50x slower. FP is no excuse for making my computer crawl to a halt. And there’s no essential reason FP needs to be slow. For example, look at how well llvm optimizes map/filter/fold in rust. In many cases they’re faster than their imperative counterparts! There are other ways to benefit from immutability that don’t involve burying a garbage collector in useless work. For example, React is a lovely example of immutable ideas, and a fast runtime. I spent a few thousand dollars on a new Mac laptop recently. I wonder what percentage of my clock cycles are going to be wasted due to bad abstractions and inefficient code? Probably most of them. I wish I could take the money I spent on the machine and instead pay people to improve their software. I don’t have billions of cycles per second of actual work to do.
    - comma_at 5y ago
      > What’s not great is loading the entire closure VM environment into my browser There's no VM in clojurescript, it compiles to JS, it is tree-shaken and heavily optimized and minified through Google's Closure compiler. > resulting in the software running (in this case) 50x slower The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives. The same can be done in clojurescript or javascript. I think this is a common misunderstanding, that's why I'm reacting. Nobody claims immutable data structures to be the silver bullet. Computation-heavy parts need to be done in low level code and with primitive types.
- devwastaken 5y ago
  You cannot physically click faster than about 100ms in reaction to a UI. A proper application that isn't 100x less efficient will never be noticed by you unless you go out of your way to measure it. Stable software is more important than unusable fast. "Lazy devs", Work on a team in C graphic code and watch nothing get done.
  - ncmncm 5y ago
    Comparing to C is always pointless. There is no environment constrained to using C for performance. There are only individuals who refuse to move on from C. It doesn't matter what language they move on to. Rust and C++ are both good.
  - ben-schaaf 5y ago
    A 100ms delay is trivially noticeable - I suggest trying to type with that delay. In terms of video people reliably distinguish between a 144hz and 240hz refresh rate which is a difference if just ~3ms.
  - rightbyte 5y ago
    Ever played a FPS game with 100 ms ping? Then compare that feeling to LAN latency.
- jacquesm 5y ago
  That ship sailed three decades ago.
- hayley-patton 5y ago
  The use of persistent data structures can make concurrent programming easier, which allows for better use of many cores. Functional programming can also scale to many computers in distributed systems, e.g. in Erlang.
gpderetta 5y ago
That future is our past. The era of free, continuous order-of-magnitude single threaded CPU improvements is well behind us. Performance is only growing very slowly. On the other hand ram, disk, and network bandwidth/latency is improving continuously, making the CPU even more of a bottleneck.
zupa-hu 5y ago
Welcome to now. Totally works like 99.99% of the time.

josephg 5y ago

I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.

slmjkdbtl 5y ago
I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
- ncmncm 5y ago
  Yet, we may characterize lazy programmers as hoping to use immutable data structures and pay no attention to performance. We all know that performance takes extra work to ensure, then, and is uncertain even with the extra work.
- drenvuk 5y ago
  I would. Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it. Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best practices that have cropped up in the past few years has been more for helping teams of people deal with growing code bases rather than helping programmers deal with limited hardware. In computer science this should be self explanatory. For optimal runtimes the act of making copies is avoided. Why people usually seem to ignore the fact that they're wasting cycles for the sake of the holy grail of clean, functional programming and immutability has eluded me. Typescript, focus on immutability, microservices even. I hate all of them but they have their purposes. They solve people problems. Maximizing hardware performance is not in the list though.
  - slmjkdbtl 5y ago
    Yeah now I wouldn't use immutable structure in an performance intensive application, but I do _hope_ one day we have some cycles to spare and can use it without worrying too much. To me it's like garbage collection, it's nice to have if we can afford some performance cost.
  - rackjack 5y ago
    Abstraction is at the core of programming... complaining about people not "properly managing mutable state" is like complaining about choosing Java over C because they're not "properly" managing memory and instead using a garbage collector. Maximizing hardware performance is, truth be told, largely irrelevant for the vast majority of applications. If they can meet their goals/deadlines/whatever, you can call them lazy, but I think most would call them efficient. Though I must admit, every time my browser lags when viewing what SHOULD be a static site, I do die a little inside.
askonomm 5y ago
You may call functional programmers who prefer immutable data structures lazy because we want to actually understand what we create, but I don't see how the 10 billion layers of abstractions and state duplications somehow end up making better software.
- josephg 5y ago
  I agree - I think having 10 billon layers of abstraction is worse for everyone. It’s buggier, more expensive to make and (ironically) often slower in practice anyway; because you can’t optimize what you can’t understand. Java style OO has a lot to answer for. Functional programming is great. What’s not great is loading the entire closure VM environment into my browser - resulting in the software running (in this case) 50x slower. FP is no excuse for making my computer crawl to a halt. And there’s no essential reason FP needs to be slow. For example, look at how well llvm optimizes map/filter/fold in rust. In many cases they’re faster than their imperative counterparts! There are other ways to benefit from immutability that don’t involve burying a garbage collector in useless work. For example, React is a lovely example of immutable ideas, and a fast runtime. I spent a few thousand dollars on a new Mac laptop recently. I wonder what percentage of my clock cycles are going to be wasted due to bad abstractions and inefficient code? Probably most of them. I wish I could take the money I spent on the machine and instead pay people to improve their software. I don’t have billions of cycles per second of actual work to do.
  - comma_at 5y ago
    > What’s not great is loading the entire closure VM environment into my browser There's no VM in clojurescript, it compiles to JS, it is tree-shaken and heavily optimized and minified through Google's Closure compiler. > resulting in the software running (in this case) 50x slower The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives. The same can be done in clojurescript or javascript. I think this is a common misunderstanding, that's why I'm reacting. Nobody claims immutable data structures to be the silver bullet. Computation-heavy parts need to be done in low level code and with primitive types.
devwastaken 5y ago
You cannot physically click faster than about 100ms in reaction to a UI. A proper application that isn't 100x less efficient will never be noticed by you unless you go out of your way to measure it. Stable software is more important than unusable fast. "Lazy devs", Work on a team in C graphic code and watch nothing get done.
- ncmncm 5y ago
  Comparing to C is always pointless. There is no environment constrained to using C for performance. There are only individuals who refuse to move on from C. It doesn't matter what language they move on to. Rust and C++ are both good.
- ben-schaaf 5y ago
  A 100ms delay is trivially noticeable - I suggest trying to type with that delay. In terms of video people reliably distinguish between a 144hz and 240hz refresh rate which is a difference if just ~3ms.
- rightbyte 5y ago
  Ever played a FPS game with 100 ms ping? Then compare that feeling to LAN latency.
jacquesm 5y ago
That ship sailed three decades ago.
hayley-patton 5y ago
The use of persistent data structures can make concurrent programming easier, which allows for better use of many cores. Functional programming can also scale to many computers in distributed systems, e.g. in Erlang.

gpderetta 5y ago

That future is our past. The era of free, continuous order-of-magnitude single threaded CPU improvements is well behind us. Performance is only growing very slowly. On the other hand ram, disk, and network bandwidth/latency is improving continuously, making the CPU even more of a bottleneck.

zupa-hu 5y ago

Welcome to now. Totally works like 99.99% of the time.