5 ms·

Abstractions are not only necessary for portability, they are necessary for understanding increasingly complicated software systems. Say I write a program in P

Abstractions are not only necessary for portability, they are necessary for understanding increasingly complicated software systems. Say I write a program in Python. Python is implemented in C, but I don't have to care about C. The C source of the Python implementation is compiled to x86 machine code, but I don't need to know how that works either. Machine code is miplemented using logic gates, which in turn are implemented using electronics. Again, stuff I don't need to know about. I write my program using a text editor which uses KDE, and below that, X Windows. These are both complex software systems, and again I DON'T NEED TO KNOW ABOUT THEM. Underneath X is the graphics card. This presumably uses some sort of memory-mapped display, but I don't know the details. Back in the days of CP/M systems with 64K of RAM, one could understand a computer system in its entirety. It simply isn't possible now.

anamax 17y ago
> Again, stuff I don't need to know about. Until you do.... For example, disk addresses are numbers. In most cases, consecutive numbers means adjacent blocks which means that accessing a, a+1 is much faster than accessing a, a+2034. Except that that's not true for certain values of a which depend on the disk's actual layout, which can change (because the disk may decide that a or a+1 is bad and remap it to some other place). All abstractions leak at some point. (My fun one was some non-existent memory that could be written and then read reliably in certain ways. Yes, there really wasn't a DIMM plugged in, but I could write to the relevant physical address and get back what I'd written.)
- LogicHoleFlaw 17y ago
  How did... how was that even possible?!
  - derobert 17y ago
    L1, L2, and L3 data cache make that easily possible. The write is cached, and the read is satisfied from the cache. Alternatively, there could be aliasing going on, and that read/write is actually going to a different DIMM (and thus corrupting memory elsewhere)
    - anamax 17y ago
      Nope. It wasn't caches, aliasing, or memory mapping. I could write to any physical address in the slots with no DIMMs and get back what I read, just like I could with the slots that had memory. I figured it out when I noticed that all reads (from the slots with no dimms), regardless of address, returned the last value written to any address. In other words, a read from 104 returned what I wrote to 100 if that was the last write. The data bus was behaving like a set of capacitors.
- Confusion 17y ago
  Until you do.... And then you turn to someone with expertise on the subject or obtain the expertise. You cannot possibly be an expert on everything computerrelated.
  - Pistos2 17y ago
    Exactly. Low level knowledge is nice to have in some situations, but is for the most part not required to accomplish a lot because high level knowledge and tools are often sufficient.
  - anamax 17y ago
    > And then you turn to someone with expertise on the subject or obtain the expertise. I think that it's possible and even reasonable to understand the fundamentals a couple of levels of abstraction either direction from your area of expertise. In the cases where that's not enough, it's still very useful in helping you interact with someone who has relevant expertise.
andreyf 17y ago
Right, and that's exactly the immaturity I'm talking about - you're writing in a language designed by A interpreted by a program written by B in a language designed by C compiled to an architecture defined by D, where A B C D are sets of people who have with little or no interest in what the others are doing. Between KDE, X Windows, and the graphics card, how much code complexity and hardware is necessary to do what Ivan Sutherland did nearly half a century ago? Understanding a computer system in its entirety simply isn't possible now. Precisely! But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using.
- lmkg 17y ago
  But what advantage is there to be gained? On the one hand you're removing accessibility to an underlying layer, but on the other hand you're also removing the need to deal with it, except for a small fraction of edge cases. If I'm writing a document in MS Word, my concern is what the document says and how it looks. Will knowing the specifics of hardware drivers for the hard disk or monitor help me do this in any way?[1] This is the same argument that C won against assembly back in the day, and the same argument that C is losing against yet-higher-level languages in the past decade. The utility you can squeeze out of low-level facilities, past one or two layers of abstraction, is small, especially compared with the level of effort required. You view it as "siloing." Most of us view it as specialization. Programmers get to focus on the novel aspects of their problem space, and the pieces like hard disc drivers that are universal get placed in the hands of specialists whose general solutions are still better than a million people making their own solutions. [1] To be perfectly honest, I do structure write my docs with the compression scheme of .docx files in mind, albeit in very vague general terms. However, this is more vanity than anything else, a word document being a kilobyte bigger or smaller has a vanishingly small chance of having a nonzero impact on anyone's life.
  - andreyf 17y ago
    Faster programs. GUI's were possible with early 60's hardware [1]. UX performance hasn't scaled linearly with hardware speed, and I imagine that back abstractions are to blame. 1. http://www.youtube.com/watch?v=mOZqRJzE8xg http://www.youtube.com/watch?v=mOZqRJzE8xg

anamax 17y ago

> Again, stuff I don't need to know about. Until you do.... For example, disk addresses are numbers. In most cases, consecutive numbers means adjacent blocks which means that accessing a, a+1 is much faster than accessing a, a+2034. Except that that's not true for certain values of a which depend on the disk's actual layout, which can change (because the disk may decide that a or a+1 is bad and remap it to some other place). All abstractions leak at some point. (My fun one was some non-existent memory that could be written and then read reliably in certain ways. Yes, there really wasn't a DIMM plugged in, but I could write to the relevant physical address and get back what I'd written.)

LogicHoleFlaw 17y ago
How did... how was that even possible?!
- derobert 17y ago
  L1, L2, and L3 data cache make that easily possible. The write is cached, and the read is satisfied from the cache. Alternatively, there could be aliasing going on, and that read/write is actually going to a different DIMM (and thus corrupting memory elsewhere)
  - anamax 17y ago
    Nope. It wasn't caches, aliasing, or memory mapping. I could write to any physical address in the slots with no DIMMs and get back what I read, just like I could with the slots that had memory. I figured it out when I noticed that all reads (from the slots with no dimms), regardless of address, returned the last value written to any address. In other words, a read from 104 returned what I wrote to 100 if that was the last write. The data bus was behaving like a set of capacitors.
Confusion 17y ago
Until you do.... And then you turn to someone with expertise on the subject or obtain the expertise. You cannot possibly be an expert on everything computerrelated.
- Pistos2 17y ago
  Exactly. Low level knowledge is nice to have in some situations, but is for the most part not required to accomplish a lot because high level knowledge and tools are often sufficient.
- anamax 17y ago
  > And then you turn to someone with expertise on the subject or obtain the expertise. I think that it's possible and even reasonable to understand the fundamentals a couple of levels of abstraction either direction from your area of expertise. In the cases where that's not enough, it's still very useful in helping you interact with someone who has relevant expertise.

andreyf 17y ago

Right, and that's exactly the immaturity I'm talking about - you're writing in a language designed by A interpreted by a program written by B in a language designed by C compiled to an architecture defined by D, where A B C D are sets of people who have with little or no interest in what the others are doing. Between KDE, X Windows, and the graphics card, how much code complexity and hardware is necessary to do what Ivan Sutherland did nearly half a century ago? Understanding a computer system in its entirety simply isn't possible now. Precisely! But there's absolutely no reason why it can't be, aside from the inelegant, weak, and opaque abstractions we're using.

lmkg 17y ago
But what advantage is there to be gained? On the one hand you're removing accessibility to an underlying layer, but on the other hand you're also removing the need to deal with it, except for a small fraction of edge cases. If I'm writing a document in MS Word, my concern is what the document says and how it looks. Will knowing the specifics of hardware drivers for the hard disk or monitor help me do this in any way?[1] This is the same argument that C won against assembly back in the day, and the same argument that C is losing against yet-higher-level languages in the past decade. The utility you can squeeze out of low-level facilities, past one or two layers of abstraction, is small, especially compared with the level of effort required. You view it as "siloing." Most of us view it as specialization. Programmers get to focus on the novel aspects of their problem space, and the pieces like hard disc drivers that are universal get placed in the hands of specialists whose general solutions are still better than a million people making their own solutions. [1] To be perfectly honest, I do structure write my docs with the compression scheme of .docx files in mind, albeit in very vague general terms. However, this is more vanity than anything else, a word document being a kilobyte bigger or smaller has a vanishingly small chance of having a nonzero impact on anyone's life.
- andreyf 17y ago
  Faster programs. GUI's were possible with early 60's hardware [1]. UX performance hasn't scaled linearly with hardware speed, and I imagine that back abstractions are to blame. 1. http://www.youtube.com/watch?v=mOZqRJzE8xg http://www.youtube.com/watch?v=mOZqRJzE8xg