Ever since programming languages have been invented and humans have been developing applications with these languages, we’ve had language wars over which language was faster, more powerful, more memory conscience, more concise, more elegant, more readable, more WHATEVER .
First FORTRAN reigned supreme and along came COBOL and then LISP and C, and Pascal, and Smalltalk, and Perl, Java, C++, Objective-C, C# and about a thousand other languages with weird names.
Well next time you are about to have your nerd fight over which language really is best, you might just want to pause and rethink your tune.
Thanks to powerful tools, the need for speed, and the shifting nature of programming itself, your next nerd fight should be over framework APIs, not programming language syntax.
Today, battles involving syntax 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 code generation and preprocessors (pre-compilers) are closing the gap. If I want to write code in Java or C# but the project uses JavaScript code, guess what? There’s a preprocessor for that!!
Syntax is really becoming irrelevant. Why? Because the reality is that our code (or rather compiler) is smart enough to check itself! Whether you are using a compiler or an IDE to do static checking of your code, YOU, the developer don’t really need to worry about “Do I end a statement in a semi-colan?” and “Do I need the ‘new’ keyword here?”. If you need it, the IDE will tell you, if you don’t, you get the green build light!
I love compilers because they are constantly watching my back and telling me when I screw up. I let them do the thinking for me and spend my time pondering the big questions about my code. The IDE is the peon, the programming assistant that handles those petty details. Scott Hanselman once wrote a blog post about how we are abstracting on the shoulders of giants. And let me tell you something from experience…
The shoulders of giants are worth standing on!
I don’t know how many times I’ve been working with developers that are so concerned about knowing the keywords of the language they are working with inside and out (not saying that knowing your language well is not important) but they aren’t familiar with the Framework or any of the APIs that work with the language at all.
Its frustrating when I am reviewing some great code that a developer has just spent a day or two writing to implement a data structure that has O(1) time complexity when searching for x node WHEN THE DATA STRUCTURE IS ALREADY AVAILABLE THE FRAMEWORK! (Please stop writing your own HashSets people!)
Stop re-inventing the wheel!
Instead, learn how to use these Frameworks and APIs to your advantage. Study the Frameworks and learn how to use them. 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. 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.
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 C# initializes static fields in the objects, but you would be much better off figuring out how to leverage the power of Entity Framework, ASP.NET, or some other pile of code to work with you.
Computer languages are largely agnostic. They’re designed to be open, accepting, and almost infinitely malleable. They’re meant to do whatever you want. Sure, sometimes you need to use a few extra characters because of the syntax, but those are merely keystrokes. After that, it’s mainly if-then-elses, plus occasional clever bits. All of the language will still help you get the results you want the way you want to get them. If there are strictures, they’re designed to keep your code as bug-free as possible, not limit what you can do.
Frameworks are powerful. Understanding and utilizing these frameworks are a problem too many of us as developers make. Next time you are in charge of a project, try to think at a higher level of not which programming language is best for the project, but instead what problem domain does your project lie in and what framework best fits that problem set. Doing this will allow you to leverage much of the clever work by smart developers before us and concentrate on the important aspects of how the system works together as a whole.
As Andrew Coates once said (video below):
and I have to say, he hit the nail on the head with that one!
P.S. .NET is the best framework 🙂
If you enjoyed this post, please comment and subscribe to my blog at jasonroell.com!