In the last 8 years of programming, I’ve come across a lot of opinions about programming languages and how elegant, efficient and productive one language is over another.  By nature, these conversations have high potential to turn into arguments, and realizing the futility of the exercise, I avoid voicing my opinions.

Over the years, I’ve worked with Perl scripts, PHP, Java, ASP, ASP .NET,  C#, Visual Basic .NET, Visual Basic 6, JavaScript, C++, C, a bit of ActionScript and SwishScript, GW-BASIC/Q-BASIC, LOGO (that unforgettable turtle!). I’ve worked around people who are proficient in .NET, VB, C#, C++, Java, PHP, Ruby, JavaScript, iOS, and many more languages. In conversations with many of them, I realized that “How cool is the language I know?” is a prominent conversation among programmers, and disagreeing with them in not a option. 

Depending on the kind of people you’re around, if you mention that you’re a big fan of  Microsoft .NET, you’re bound to get strong reactions. Apparently, .NET is “not cool”, whereas some go a step further to proclaim, “It’s a dead platform”. If you mention that you love Functional Programming, every single Java Developer in the vicinity will drop what they’re doing and run towards you to get a glimpse of the colour of your face after they’ve ridiculed your childish beliefs. 

The programming fraternity is fragmented into different multiverse. Java Developers hang out with Java and C++ developers in the OO-universe, Ruby developers hang out in the Ruby-universe. PHP developers, some of whom are immigrants of the ASP-universe, give company to other developers from the functional universe. Each universe is constantly expanding by trying to influence developers around them.  People tend to swear by what they’ve learned and propagate their beliefs to others, thereby trying gathering more support for their beliefs.

Of course, I have my own opinions on some of those languages, but I’m careful not to voice those opinions because of the fact that, it’s not about the language; it’s what you can do with it. I’ve had trouble thinking in some languages and have found some languages a bit quirky, but overall, I do believe each language has it’s place. Generally, some problems are solved more quickly in certain languages because of the way you think while developing in that language, rather than a “feature” in the language. While a language may provide nifty ways of doing commonly performed actions, it should not be the deciding factor for solving a problem in that language.

Take Shell-scripting, for example. Of late, I’ve begun to believe you can do almost anything  using the shell. From accepting HTTP connections, to processing images and serving pdf files on the fly. It’s all possible. Is it generally used to serve HTTP requests in servers? No. Why? Because there are dedicated technologies to do just that. 

I’ve learnt that, as a programmer, it’s crucial to be Language Agnostic. It’s important to be  objective about new technologies as well as unlearn some of your long-held beliefs about certain technologies. It’s important not to be impressed by a shiny new programming language just because it’s trending or because it’s in-demand in today’s job-market. It’s important to have a open mind and know about the what else is out there. 

The next time a fellow programmer from a different universe steps by to explain a cool feature in their language, act bored. 

“The illiterate of the twenty-first century will not be those who cannot read and write, but  those who cannot learn, unlearn and relearn.” — Alvin Toffler

I had a moment of reflection at work today, as I was completing a task.

During college, I was taught the power of Object-oriented programming and, among other things, the importance of abstraction. I had a good understanding of the theory of abstraction and what it did. I had a fair understanding of how to go about abstracting stuff only during my first job/internship. That project had, in my opinion, the most adequate use of abstraction. Not too much, not too little.

An ASP .net project, it had views with HTML, JS, CSS and some server-side tags, codebehind files that wired the data to the views, a Business Logic Layer (that was literally called BLL.vb), and a Data Access Layer. During the documentation of the project, I classified it as having the then-famous 3-tier architecture (MVC was just catching on at the time). It’s the most memorable project I’ve worked on, and the .NET platform blew me away.

Today, I realized the hazards of the overuse of programming abstractions. I was trying to refactor a project to adjust to changes made in an API’s response. The API had one additional field that needed to be captured and handed over to the view. The task entailed modifying the entire chain of layers from the model to the view. This chain of layers in my case wasn’t a lengthy one. But I asked myself, “What if I had abstracted things further?”

I’ve seen vast projects with thousands of lines of code with layer upon layer of abstraction, following the best practices of code ever thought of by man-kind. Yet, the code is fragmented into so many different layers, it is almost impossible to club it all together and get a sense of what’s going on. Not even my IDE can help me put the pieces together.  These projects require vast amounts of documentation and code comments, so that the future members of the team could take over. But are these layers even necessary?

I strongly feel they aren’t. Code should only be as modular as required, not as modular as a book on Software Engineering or expert programming guidelines would like you to have it. We quickly submit to well-organized, deeply modular projects that contain millions of lines of code and accept them to be the hallmarks of Software Engineering. They aren’t. They often contain data being passed from one layer to another, with the layers in between doing nothing but passing data around. Elaborate Interface and Exception definitions do not spell out the formula for robust, testable, maintainable code.

Speaking of maintenance. I think this obsession people have about writing maintainable code is laughable. It’s 2012. Product lifecycles are short, and within 2 years, you’re expected to either work on a new product, or introduce features that can no longer be accommodated in the current architecture. Only portions of the current codebase would be of any use, and the layers of abstraction would sooner or later fall apart. While abstractions you create may help you maintain the product during it’s lifecycle and maintenance period, you will probably feel like rewriting the entire codebase once you hit a roadblock.

Projects should be architected to get things done, and not for detailed blueprints, specifications and diagrams of what is being built. Sure, that’s impressive to the average client, but that isn’t the soul of Software Engineering. Of course, I’m never going to find a firm that actually builds software neglecting code-quality or maintenance, but how I wish I could. Code, would truly be like poetry. Free-flowing transmission of a Software Engineer’s innermost essence. Alas, my next firm will probably adore me for writing thousands of lines of well-commented and documented code, with unit test cases, for displaying a “Hello World” on a Windows 8 desktop.

We tend to be attracted towards ideals, while losing sight of the purpose. The focus on solving the problem at hand gets lost in the infinite layers of abstractions. Limit your layers till the point you solve the problem and one more (for good luck), and not till the point you think your code will be maintainable for hundreds of years.

In a few years, we’ll all be fighting for oil, natural resources, and dive into anarchy anyway. Functional programming may just rule the roost then.