4 ms·

>this hides from me what's being presented to the compiler Isn't that the whole point of abstractions? Like, when you write a function call, you see "foo()" bu

>this hides from me what's being presented to the compiler Isn't that the whole point of abstractions? Like, when you write a function call, you see "foo()" but the compiler sees all the individual instructions in the function. The same with macros, templates, etc. And on a purely visual level, the example 'jtsummers gave just seems to be an extension of code folding and other tools that let you focus on one part of the code while ignoring another.

geocar 9y ago
> Isn't that the whole point of abstractions? Abstractions are the wrong thing to chase. Just because an abstraction will put you further away from a technical problem, doesn't mean will get you closer to solving your business problem.
TeMPOraL 9y ago
The essence of programming is being capable of constantly walking up and down the abstraction ladder. Trying to hide behind a perfect abstraction is as problematic as the belief that abstractions are evil because they're too complicated. Abstractions are transient. You want to use them when they help you, but it's good to be able to step down and verify what's going on.
- edmccard 9y ago
  >The essence of programming is being capable of constantly walking up and down the abstraction ladder ... it's good to be able to step down and verify what's going on. Good, yes, desirable, often, but I wouldn't call it "essential" to the art of programming. I once worked for a company whose data was managed by a COBOL application on a mainframe a couple hundred miles away; there was no walking down that abstraction ladder (without shelling out a five-figure support fee), so our in-house IT department had to take advantage of the fact that the 3270 terminal emulator we used to access the mainframe, could be driven through a COM interface. I'm sure there are lots of other examples of jobs that don't have the luxury of being able to step down and verify lower-level code, and I wouldn't characterize them as missing out on some "essential" aspect of programming.

geocar 9y ago

> Isn't that the whole point of abstractions? Abstractions are the wrong thing to chase. Just because an abstraction will put you further away from a technical problem, doesn't mean will get you closer to solving your business problem.

TeMPOraL 9y ago

The essence of programming is being capable of constantly walking up and down the abstraction ladder. Trying to hide behind a perfect abstraction is as problematic as the belief that abstractions are evil because they're too complicated. Abstractions are transient. You want to use them when they help you, but it's good to be able to step down and verify what's going on.

edmccard 9y ago
>The essence of programming is being capable of constantly walking up and down the abstraction ladder ... it's good to be able to step down and verify what's going on. Good, yes, desirable, often, but I wouldn't call it "essential" to the art of programming. I once worked for a company whose data was managed by a COBOL application on a mainframe a couple hundred miles away; there was no walking down that abstraction ladder (without shelling out a five-figure support fee), so our in-house IT department had to take advantage of the fact that the 3270 terminal emulator we used to access the mainframe, could be driven through a COM interface. I'm sure there are lots of other examples of jobs that don't have the luxury of being able to step down and verify lower-level code, and I wouldn't characterize them as missing out on some "essential" aspect of programming.