4 ms·

I would not say that dependency of the layers is like a tree and if trunk breaks, everything does. I'd rather see the levels of programming abstractions as a gr

I would not say that dependency of the layers is like a tree and if trunk breaks, everything does. I'd rather see the levels of programming abstractions as a graph with lower/higher level nodes. As it is pointed out in the comments above, x86 has surprisingly much of a duct tape in it. There is a lot of much more saner platforms, but programming still lives happily on x86. Why? Because it does not matter at all so often. x86 is hidden from us with OS, compilers and virtual machines. That's where the beauty of programming shines: if you have a lame implementation below your level, just abstract it away as far as resources allow you (e.g. full-scale managed memory programming is theoretically possible in DOS but noone did it because of CPU/memory constraints). Another example: Win32 API and MFC and other native stuff is horrible, but .NET platform seems to be quite sane. Javascript is horrible, but jQuery is, um, beautiful. On the other hand, a hardware guy still operates with an abstraction of a microcontroller. If memory is corrupted, his abstraction fails also. It's just that the HW guy does not have to invent good abstractions often (or rather at all). The point is, abstracting may be self-healing: if something is broken at some level, a level above can use the good parts to build a fully functional emulation.

Periodic 13y ago
This is why I think higher-level programming is easier. I love to build an abstraction around a complication so that I don't have to think about it anymore. It was only very recently that I began to embrace what kind of programmer I am. I prefer high level abstractions; I prefer the mathematical underpinnings; I detest doing things manually. Other people have the opposite inclinations and I'm happy that the world has both. I have recently had to work with C++ on some systems-level code. It's the lowest-level I've had to work on for a while. I find that having to think about things like memory management and system peculiarities like buffer alignments gets in the way of thinking about the higher level algorithm or problem. In this case I did not have the luxury of being able to build abstractions around some of the quirks I encountered. On the other hand, when I work at a high level with a suitably high-level language, I can recognize patterns and abstract them away. For example, I've seen many instances of the pattern b = a.f(); if (b != null) { c = b.g(); if (c != null) {...}} This pattern is fairly common, and in a suitably rich high-level language I can abstract it and just write c = a.f().g(); It saves me a lot of thinking and honestly feels a lot easier.

Periodic 13y ago

This is why I think higher-level programming is easier. I love to build an abstraction around a complication so that I don't have to think about it anymore. It was only very recently that I began to embrace what kind of programmer I am. I prefer high level abstractions; I prefer the mathematical underpinnings; I detest doing things manually. Other people have the opposite inclinations and I'm happy that the world has both. I have recently had to work with C++ on some systems-level code. It's the lowest-level I've had to work on for a while. I find that having to think about things like memory management and system peculiarities like buffer alignments gets in the way of thinking about the higher level algorithm or problem. In this case I did not have the luxury of being able to build abstractions around some of the quirks I encountered. On the other hand, when I work at a high level with a suitably high-level language, I can recognize patterns and abstract them away. For example, I've seen many instances of the pattern b = a.f(); if (b != null) { c = b.g(); if (c != null) {...}} This pattern is fairly common, and in a suitably rich high-level language I can abstract it and just write c = a.f().g(); It saves me a lot of thinking and honestly feels a lot easier.