3 ms·

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 implemen

by 13of40 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
      [deleted]
    - ehaliewicz2 3y 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 3y 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 3y ago
> only a fool would actually implement one No, only a fool would let his boss know that he did.

by 13of40 3y ago

kqr 3y 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 3y 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 3y 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 3y 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 3y ago
    [deleted]
  - ehaliewicz2 3y 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 3y 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 3y ago

> only a fool would actually implement one No, only a fool would let his boss know that he did.