3 ms·

I think the opposite conclusion is correct: Hurray, we don't have to dive into the intricacies of hardware and low-level programming anymore, but instead can fo

I think the opposite conclusion is correct: Hurray, we don't have to dive into the intricacies of hardware and low-level programming anymore, but instead can focus on end-user value and making programming accessible to more people. Sure, building Electron apps is incredibly wasteful and NodeJS' type system allocates way too much memory for something that C++ would be much more frugal with, but who cares? Hardware is cheap, and processing power is cheap. Computers are becoming a commodity layer that simply facilitates human requirements, rather than being the thing that humans have to understand and optimize for. We've seen the same mind-shift happen for storage: remember the pre-gmail days when Microsoft/Yahoo/Your internal IT department gave you 2MB of email storage, and you had to optimize your mail archive to fit this constraint? Do we really want humans that are better at optimizing mail archives? Of course not, we want mail storage we don't have to think about. And the same is true for computation.

mhh__ 6y ago
I think the issue is that rather than making C++ better we have defaulted to relying on the hardware more. C++ is a deeply, deeply, flawed language - using something else isn't hard (and it doesn't have to be Rust). You'd be surprised at the amount of stuff you can get for free if you make it easy to express. My D scripts are usually shorter than my Python one's (and I write code I want to save not just "it'll do"-type scripts, to my detriment), but because we don't teach people anything other than C++/Java/Python (Haskell is very nice but it's too far away to be helpful to this area of software) we falsely imprint a view that performance always cost's expressiveness or development time. The good news is that this trend does seem to be getting better, and it's only going to get easier thanks to widespread use of infrastructure like LLVM and the social acceptance in industry of wacky languages.
- MaxBarraclough 6y ago
  On a similar note: we rarely make use of abstractions that 'compile away', instead using abstractions that bring a runtime performance cost. An example of this is declarative GUI design. It's a good design idea to use a declarative language for this, as it helps with GUI design tooling (drag-and-drop editors), and eliminates the bugs that could arise from doing the work 'by hand' in a programming language. Most solutions end up parsing XML (or something similar) at runtime, rather than compiling down to an optimised binary. It's possible to 'have it all', in this instance.
  - smichel17 6y ago
    At least on the web, this is a feature, not a bug. It allows the user to modify the page as they see fit. For example, ad blockers or "dark mode" extensions would have a much more difficult job if websites were delivered as optimized binaries. I specify "on the web" because almost all browsers execute the content retrieved from the website with no user interaction besides navigating to a url. Contrast that with operating systems, which all require separate download + run steps (and often a bit flip in between, to mark the file as executable). That's a lot more friction / time for the user to notice if something is not as they expect or want.
    - MaxBarraclough 6y ago
      I agree it makes sense on the web, which is ultimately a document system, but for a native desktop application I figure it makes good sense to compile away as much as possible.
      - smichel17 6y ago
        Agreed on that front — especially since you can distribute the source in addition to the binary so that users can make changes & recompile if they want.
badsectoracula 6y ago
The biggest issue with this sort of thinking is that developers tend to create applications that either assume they're the only applications running in the system - or they use machines so powerful that when you try their applications on a lower end machine (PCs with just 4GB of RAM and weak CPUs are still being sold for example) they might as well assumed they'd be the only applications running in the system.
- jbergens 6y ago
  Oh, I remember old versions of SQL Server, they took ALL the memory on the machine. Did not work well if you tried to run something else at the same time.

mhh__ 6y ago

I think the issue is that rather than making C++ better we have defaulted to relying on the hardware more. C++ is a deeply, deeply, flawed language - using something else isn't hard (and it doesn't have to be Rust). You'd be surprised at the amount of stuff you can get for free if you make it easy to express. My D scripts are usually shorter than my Python one's (and I write code I want to save not just "it'll do"-type scripts, to my detriment), but because we don't teach people anything other than C++/Java/Python (Haskell is very nice but it's too far away to be helpful to this area of software) we falsely imprint a view that performance always cost's expressiveness or development time. The good news is that this trend does seem to be getting better, and it's only going to get easier thanks to widespread use of infrastructure like LLVM and the social acceptance in industry of wacky languages.

MaxBarraclough 6y ago
On a similar note: we rarely make use of abstractions that 'compile away', instead using abstractions that bring a runtime performance cost. An example of this is declarative GUI design. It's a good design idea to use a declarative language for this, as it helps with GUI design tooling (drag-and-drop editors), and eliminates the bugs that could arise from doing the work 'by hand' in a programming language. Most solutions end up parsing XML (or something similar) at runtime, rather than compiling down to an optimised binary. It's possible to 'have it all', in this instance.
- smichel17 6y ago
  At least on the web, this is a feature, not a bug. It allows the user to modify the page as they see fit. For example, ad blockers or "dark mode" extensions would have a much more difficult job if websites were delivered as optimized binaries. I specify "on the web" because almost all browsers execute the content retrieved from the website with no user interaction besides navigating to a url. Contrast that with operating systems, which all require separate download + run steps (and often a bit flip in between, to mark the file as executable). That's a lot more friction / time for the user to notice if something is not as they expect or want.
  - MaxBarraclough 6y ago
    I agree it makes sense on the web, which is ultimately a document system, but for a native desktop application I figure it makes good sense to compile away as much as possible.
    - smichel17 6y ago
      Agreed on that front — especially since you can distribute the source in addition to the binary so that users can make changes & recompile if they want.

badsectoracula 6y ago

The biggest issue with this sort of thinking is that developers tend to create applications that either assume they're the only applications running in the system - or they use machines so powerful that when you try their applications on a lower end machine (PCs with just 4GB of RAM and weak CPUs are still being sold for example) they might as well assumed they'd be the only applications running in the system.

jbergens 6y ago
Oh, I remember old versions of SQL Server, they took ALL the memory on the machine. Did not work well if you tried to run something else at the same time.