7 reasons why frameworks are the new programming languages
In the 1980s, the easiest way to start a nerd fight was to proclaim that your favorite programming language was best. C, Pascal, Lisp, Fortran? Programmers spent hours explaining exactly why their particular way of crafting an if-then-else clause was superior to your way.
That was then. Today, battles involving syntax and structure are largely over because the world has converged on a few simple standards. The differences between the semicolons, curly brackets, and whatnot in C, Java, and JavaScript are minor. Interesting debates about typing and closures still exist, but most are moot because automation is closing the gap. If you don't like specifying a data type, there's a good chance the computer will be able to infer exactly what you meant. If your boss wants JavaScript but you like Java, a cross-compiler will convert all of your statically typed Java into minified JavaScript, ready to run in a browser. Why fight when technology has our backs?
Today, the interesting action is in frameworks. When I sat down with other faculty members at Johns Hopkins University to plan out a new course, frameworks dominated the conversation. Is Angular better than Ember? Is Node.js all that?
We designed a survey course that would explore the architecture of the most important software packages that are the foundation of the Internet. This was the center of the action, worthy of a survey course that would explore the architecture of the most important software packages girding today’s Internet.
Plus, the practice of coding is different now. Most code is now a long line of API calls. There's occasional reformatting of the data in between API calls, but even those jobs are usually handled by other APIs. A lucky few get to write clever, bit-banging, pointer-juggling code for the guts of our machines, but most of us work with the higher layers. We simply run pipe between APIs.
Because of this, it's more important to understand how an API behaves and what it can do. Which data structures does it accept? How do the algorithms behave when the data set grows larger? Questions like these are more central to today’s programming than ones about syntax or language. Indeed, there are now a number of tools that make it simple to call a routine in one language from another. It's relatively simple to link C libraries to Java code, for instance. Understanding the APIs is what matters.
The shoulders of giants are worth standing on
Imagine you've become a disciple of Erlang or another new language. You decide it offers the best platform for writing a stable, bug-free app. This is a nice sentiment, but it could take years for you to rewrite all the code available for Java or PHP into your latest language of choice. Sure, your code could turn out to be dramatically better, but is that worth the extra time?
Frameworks let us leverage the hard work of those who came before us. We may not like the architecture they chose and we may argue over implementation details, but it's more efficient to stifle our complaints and find a way to live with the differences. It's so much easier to inherit all the good and the bad of the code base through a framework. Taking the macho route by writing everything yourself in your favorite new language rather than one of its more popular frameworks won’t allow you to enjoy the cream of your new choice as quickly as it would to simply defer to the framework makers and their APIs.
Knowing the architecture is what matters, not the syntax
When most of the coding is stringing together API calls, there's not much advantage in learning the idiosyncrasies of the language. Sure, you could become an expert on how Java initializes static fields in the objects, but you would be much better off figuring out how to leverage the power of Lucene or JavaDB or some other pile of code. You could spend months grokking the optimizing routines of Objective-C compilers, but learning the ins and outs of the latest Apple core library will really make your code scream. You'll get much further learning the picky details of the framework than the syntax of the language on which the framework rests.
Most of our code spends most of its time in the inner loops of libraries. Getting the details of the language correct can help, but knowing what's going on in the libraries can pay off dramatically.
Algorithms dominate
Learning a programming language can help you juggle the data stashed in the variables, but that only takes you so far. The real hurdle is getting the algorithms correct, and those are usually defined and implemented by the frameworks.
Many programmers understand it's dangerous and wasteful to spend time re-implementing standard algorithms and data structures. Sure, you might be able to tune it a bit to your needs, but you risk making subtle mistakes. Frameworks have been widely tested over the years. They represent our collective investment in a software infrastructure. There aren't many examples of when it makes sense to “go off the grid,” toss aside the hard work of others, and build an algorithmic cabin with your own two hands.
The right approach is to study the frameworks and learn how to use them to your best advantage. If you choose the wrong data structure, you could turn a linear job into one that takes a time that's a quadratic function of the input size. That's a big hassle once you go viral.
Comments