I started writing a new post this morning about one of my favorite topics: levels of abstraction. While looking for references, I ran across this post I wrote for Google+ on January 6, 2012. So, with the author’s permission, I’ll reuse that post here.
I just read an article from Fast Company’s Co.Design lamenting about the poor design of programming languages.
While the article misses the boat in a number of ways (like offering a snippet of C++ or Java and calling it Perl [note: the article has since been fixed, although it justified the error by claiming Java is very similar to Perl]), it completely misses the most fundamental concept of computer architectures: from transistors and gates to the pretty user interfaces, computers and the software that runs them, are built in layers.
No software developer considers the physics of electrons in silicon while writing a new program. Yet, they are, in fact, building a system that will ultimately leverage that physics. Instead, they take for granted the layers and layers of abstractions that have been built on top of that physics. Transistors, gates, CPUs, RAM, microcode, opcode instruction sets, assembly languages, compilers, editors, make utilities, testing frameworks, version control systems, networks, and on and on and on.
Perl (of which I’m no real fan), C, C++, Java, and many others are all just different tools in a vast abstraction layer toolbox. And as any craftsman knows, the right tool makes any job easier.
So, Perl is difficult to understand for programming “noobs”. So what? It’s the wrong tool for them. It’s also the wrong tool for fault tolerant distributed parallel processing, PhotoShop scripting, transforming XML into web pages, or controlling a Lego Mindstorms robot. But, it’s quite well suited to regular expression evaluation tasks, for scripting a server start up, and many, many other tasks.
In the world of computing, if something seems particularly difficult, you’re probably working at the wrong level of abstraction.