5 ms·

Abstractions are a necessity for portability. You can't talk about "little heads reading data off the hard disk" if your program is expected to work on SSDs too

Abstractions are a necessity for portability. You can't talk about "little heads reading data off the hard disk" if your program is expected to work on SSDs too. Or what about the "quantum-holodisks" that arrive in 2020? The vague understanding of the software and hardware stack is a good thing - it could change at any time.

deleted 17y ago
[deleted]
deleted 17y ago
[deleted]
- coliveira 17y ago
  Abstractions are a good way to control complexity, but they should be open in the sense that you can easily see behind it and take control if needed. So, the idea is not to avoid abstractions, but to make them manageable.
  - deleted 17y ago
    [deleted]
ntoshev 17y ago
If you don't need to push technology to its limits, you don't need to understand the stack. Everything basically works, every program will work on both SSD and rotational disks, it will just have different performance characteristics. Some of the purely software opaque abstractions are bad in the sense that all abstractions are inherently limited, and sometimes your job is easier if you can just access the layer beneath and get your job done. So a transparent framework is one that "doesn't get in your way" (like AWT for Windows GUI development versus MFC differ a lot in giving you options to customize what you do using raw win32 API).
coliveira 17y ago
You can't expect that you program will perform well in any platform. Considering "little heads" is a good way of thinking about systems if this is the current implementation and if the bottleneck is there. There might be a future when accessing the disk is as fast as accessing main memory, but we should better not design software thinking about this possibility for now.
cabalamat 17y ago
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)

deleted 17y ago

[deleted]

deleted 17y ago

[deleted]

coliveira 17y ago
Abstractions are a good way to control complexity, but they should be open in the sense that you can easily see behind it and take control if needed. So, the idea is not to avoid abstractions, but to make them manageable.
- deleted 17y ago
  [deleted]

ntoshev 17y ago

If you don't need to push technology to its limits, you don't need to understand the stack. Everything basically works, every program will work on both SSD and rotational disks, it will just have different performance characteristics. Some of the purely software opaque abstractions are bad in the sense that all abstractions are inherently limited, and sometimes your job is easier if you can just access the layer beneath and get your job done. So a transparent framework is one that "doesn't get in your way" (like AWT for Windows GUI development versus MFC differ a lot in giving you options to customize what you do using raw win32 API).

coliveira 17y ago

You can't expect that you program will perform well in any platform. Considering "little heads" is a good way of thinking about systems if this is the current implementation and if the bottleneck is there. There might be a future when accessing the disk is as fast as accessing main memory, but we should better not design software thinking about this possibility for now.

cabalamat 17y ago

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)