4 ms·

> and are incentivised not to Could you elaborate on that?

bitwize 2y ago
Not much time for in-depth learning when you have sprint commitments to make. Just have Copilot generate the boilerplate and tests and fix them as you go.
- exe34 2y ago
  Gotta keep that velocity up!
- snvzz 2y ago
  Or copy-paste from stackunderflow.
13of40 2y ago
Example: Everyone knows how to use a Dictionary. It's not worth anyone's time to know how it works under the hood, because only a fool would actually implement one from scratch in production code. Niche embedded cases possibly excepted.
- kqr 2y ago
  I would argue this is because we've raised the bar for what counts as a computational primitive, and not a qualitative difference. A modern developer can ignore the details of a dictionary in the exact same way a programmer of the past could ignore the details of the mov instruction. (And be more productive for it.)
  - ale42 2y ago
    The problem is when developers having virtually no background in actual computer science (e.g. algorithm complexity) start implementing their own algorithms because what thy want is not directly available as a primitive. I have the impression that this tendency to use more and more complex software primitives, while at the same time introducing further levels of indirection in the actually run machine code, is one of the reasons that many applications are now as slow (or slower) than they were 10 years ago despite the hardware being much faster. Just compare the performance of an Electron-based application (which seems the go-to solution of most developers nowadays for desktop app implementation) with a native one...
    - kqr 2y ago
      I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives you think are inappropriate. In other words, when people don't care for speed they use Electron. What part of that indicates that people have no background in algorithm complexity? We have traded off run-time speed against other things for ages -- even in computing science.
      - ale42 2y ago
        > I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives Can be... because I'm also a user, and it's frustrating to have the PC bloated by dozens of Electron-based apps using huge amounts of RAM, draining the battery more than necessary, and for part of them, actually slow to use. Perhaps some users don't care because they are either not sensitive to small delays or resource usage, or because they have never seen anything else. I see also an environmental question arising here. More CPU cycles = more energy used. Makes no difference for applications used by small groups of people, but for software used in millions of copies, I'm wondering how many MWh we are wasting (I wouldn't care much —except for battery life— if energy was only from renewable sources... but it's not the case)
      - deleted 2y ago
        [deleted]
      - ehaliewicz2 2y ago
        I'm guessing, just guessing, that most of the people who don't think slow execution is bad are probably not that interested in what the machine actually has to do to execute their code, and hence, are not actually well educated in making those tradeoffs.
- skissane 2y ago
  > It's not worth anyone's time to know how it works under the hood Knowing (at a high level) how your programming language implements dictionaries has relevance to questions like time complexity of various operations, potential security vulnerabilities (a hash table might succumb to hash collision denial of service, especially if the implementation isn’t hardened against that possibility; a tree-based implementation probably won’t have that vulnerability), likely impact of different bugs (e.g. a buggy hash method can cause much more problems on a hash table than on a tree, while for a buggy comparison method it is the other way around), concurrency, etc > because only a fool would actually implement one from scratch in production code I’ve implemented a dictionary before in C. Not for work (only wrote C code for work one single time ever, and it was only a page worth of code that was called from Java, no complex data structures needed), just for my own learning/amusement. That said, C is probably the one context in which people still commonly “roll their own” basic data structures, even in production code, just because C’s standard library is so weak in that regard (and C’s lack of generics/templates doesn’t help either)
- commandlinefan 2y ago
  > only a fool would actually implement one No, only a fool would let his boss know that he did.
boffinAudio 2y ago
You need permission to write software and distribute for modern platforms. This is very disincentivizing .. not so when you've got a compiler/assembler onboard everywhere and can just ship without permission from MegaCorp...
GuB-42 2y ago
You are incentivized to user higher abstractions, sometimes for good reasons (portability, productivity, etc...). But the higher you go, the more magic there is. On a DOS machine when x86 processors actually ended with "86", or on home computers like C64s and Amigas, everything was simple. No concurrency, no security, no networking, you had a processor and it ran instructions. You go from a character displayed on screen and with a little research, have a good idea about everything that happened down to the transistor. Now, it is impossible, most of the hardware components of a modern computer are made of little computers, each one orders of magnitude more complex than these early systems, many of them run encrypted software. It means that now, software development is more about trying to get an idea of what the people who made the layer under yours were thinking about. It is becoming harder to go with first principles, too complex, it is therefore discouraged, as it is more likely to hurt productivity.
- pizza234 2y ago
  > on home computers like C64s [...], everything was simple Simple? I take you've never had to implement a division on the 6502. Or write complex code due to the limitations of 8 bits (which couldn't even directly address the pixels on the X axis) and/or 3 registers.
  - GuB-42 2y ago
    I didn't mean that using or programming the machine was simple, far from it. But the machine itself was simple. If some pixel doesn't light up right on your C64, you can follow the path from your code to the electron beam in the monitor. That entire path could fit in a single person head. It is a puzzle but you have all the pieces in front of you. Now, it is not a puzzle anymore, you just call some drawText() function and then some magic happens and there is text on the screen. If the magic doesn't happen, monitoring the output of your GPU won't help you, there is too much in between, some of it deliberately obfuscated. So you try random stuff that don't make much sense except that because of your experience, you know they work. Or more likely, someone with experience already did it, posted it on StackOverflow, and you found it using Google.

Not much time for in-depth learning when you have sprint commitments to make. Just have Copilot generate the boilerplate and tests and fix them as you go.

exe34 2y ago
Gotta keep that velocity up!
snvzz 2y ago
Or copy-paste from stackunderflow.

13of40 2y ago

Example: Everyone knows how to use a Dictionary. It's not worth anyone's time to know how it works under the hood, because only a fool would actually implement one from scratch in production code. Niche embedded cases possibly excepted.

kqr 2y ago
I would argue this is because we've raised the bar for what counts as a computational primitive, and not a qualitative difference. A modern developer can ignore the details of a dictionary in the exact same way a programmer of the past could ignore the details of the mov instruction. (And be more productive for it.)
- ale42 2y ago
  The problem is when developers having virtually no background in actual computer science (e.g. algorithm complexity) start implementing their own algorithms because what thy want is not directly available as a primitive. I have the impression that this tendency to use more and more complex software primitives, while at the same time introducing further levels of indirection in the actually run machine code, is one of the reasons that many applications are now as slow (or slower) than they were 10 years ago despite the hardware being much faster. Just compare the performance of an Electron-based application (which seems the go-to solution of most developers nowadays for desktop app implementation) with a native one...
  - kqr 2y ago
    I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives you think are inappropriate. In other words, when people don't care for speed they use Electron. What part of that indicates that people have no background in algorithm complexity? We have traded off run-time speed against other things for ages -- even in computing science.
    - ale42 2y ago
      > I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives Can be... because I'm also a user, and it's frustrating to have the PC bloated by dozens of Electron-based apps using huge amounts of RAM, draining the battery more than necessary, and for part of them, actually slow to use. Perhaps some users don't care because they are either not sensitive to small delays or resource usage, or because they have never seen anything else. I see also an environmental question arising here. More CPU cycles = more energy used. Makes no difference for applications used by small groups of people, but for software used in millions of copies, I'm wondering how many MWh we are wasting (I wouldn't care much —except for battery life— if energy was only from renewable sources... but it's not the case)
    - deleted 2y ago
      [deleted]
    - ehaliewicz2 2y ago
      I'm guessing, just guessing, that most of the people who don't think slow execution is bad are probably not that interested in what the machine actually has to do to execute their code, and hence, are not actually well educated in making those tradeoffs.
skissane 2y ago
> It's not worth anyone's time to know how it works under the hood Knowing (at a high level) how your programming language implements dictionaries has relevance to questions like time complexity of various operations, potential security vulnerabilities (a hash table might succumb to hash collision denial of service, especially if the implementation isn’t hardened against that possibility; a tree-based implementation probably won’t have that vulnerability), likely impact of different bugs (e.g. a buggy hash method can cause much more problems on a hash table than on a tree, while for a buggy comparison method it is the other way around), concurrency, etc > because only a fool would actually implement one from scratch in production code I’ve implemented a dictionary before in C. Not for work (only wrote C code for work one single time ever, and it was only a page worth of code that was called from Java, no complex data structures needed), just for my own learning/amusement. That said, C is probably the one context in which people still commonly “roll their own” basic data structures, even in production code, just because C’s standard library is so weak in that regard (and C’s lack of generics/templates doesn’t help either)
commandlinefan 2y ago
> only a fool would actually implement one No, only a fool would let his boss know that he did.

boffinAudio 2y ago

You need permission to write software and distribute for modern platforms. This is very disincentivizing .. not so when you've got a compiler/assembler onboard everywhere and can just ship without permission from MegaCorp...

GuB-42 2y ago

You are incentivized to user higher abstractions, sometimes for good reasons (portability, productivity, etc...). But the higher you go, the more magic there is. On a DOS machine when x86 processors actually ended with "86", or on home computers like C64s and Amigas, everything was simple. No concurrency, no security, no networking, you had a processor and it ran instructions. You go from a character displayed on screen and with a little research, have a good idea about everything that happened down to the transistor. Now, it is impossible, most of the hardware components of a modern computer are made of little computers, each one orders of magnitude more complex than these early systems, many of them run encrypted software. It means that now, software development is more about trying to get an idea of what the people who made the layer under yours were thinking about. It is becoming harder to go with first principles, too complex, it is therefore discouraged, as it is more likely to hurt productivity.

pizza234 2y ago
> on home computers like C64s [...], everything was simple Simple? I take you've never had to implement a division on the 6502. Or write complex code due to the limitations of 8 bits (which couldn't even directly address the pixels on the X axis) and/or 3 registers.
- GuB-42 2y ago
  I didn't mean that using or programming the machine was simple, far from it. But the machine itself was simple. If some pixel doesn't light up right on your C64, you can follow the path from your code to the electron beam in the monitor. That entire path could fit in a single person head. It is a puzzle but you have all the pieces in front of you. Now, it is not a puzzle anymore, you just call some drawText() function and then some magic happens and there is text on the screen. If the magic doesn't happen, monitoring the output of your GPU won't help you, there is too much in between, some of it deliberately obfuscated. So you try random stuff that don't make much sense except that because of your experience, you know they work. Or more likely, someone with experience already did it, posted it on StackOverflow, and you found it using Google.