Vincent Gable’s Blog

June 17, 2010

The Arrow Points Up

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they’re current working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher.

First the C guys can’t imagine writing in assembly anymore, but C++’s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy “scripting” language for validating web forms. And on and on.

And in the short term, in the moment, they’re often right. But this arrow points only one way, and that’s in the direction of ever-higher abstraction. To judge how much time remains before the next leap forwards, look at the leading edge of the industry.

John Siracusa (emphasis mine)

Here’s my two cents on the future of abstraction: systems are clearly getting wider (paralell), not faster; technologies like Grand Central Dispatch help us deal with concurrency today, but longer term, I think a functional programming abstraction is the answer.

March 4, 2009

Retest Your (Low Level) Optimizations

Filed under: Programming,Quotes | , ,
― Vincent Gable on March 4, 2009

(Measuring before and after applying an optimization is) more important these days. With optimizing compilers and smart virtual machines, many of the standard optimizing techniques are not just ineffective but also counterintuitive. Craig Larman really brought this home when he told me about some comments he received after a talk at JavaOne about optimization in Java. One builder of an optimizing virtual machine said, in effect,

“The comments about thread pools were good, but you shouldn’t use object pools because they will slow down our VM.”

Then another VM builder said,

“The comments about object pools were good, but you shouldn’t use thread pools because they slow down our VM.”

Not only does this reinforce the need to measure with every optimization change, it also suggests that you should log every change made for optimization (a comment tag in the source code is a good option) and retest your optimizations after upgrading your compiler or VM. The optimization you did six months ago could be your bottleneck today.

Martin Fowler (PDF), 2002

I’ve written before about the decay of machine-specific optimization. Even if your code isn’t run by a VM, I think it’s reasonable to expect that (at least some of it) might be run on a smartphone in the near future.

Powered by WordPress