Setting the Stage
I’m a software developer, and I like developing software and thinking about it. The software development industry has not been around for that long, so there are things to be discovered and processes to be worked out. This means it’s a good time to think about some of the bigger questions in the field.
Lately I’ve been thinking about how important programming languages are, or if the tools and processes are more important. I’ll start off with an anecdote.
Years ago, when I was a relatively new developer, I joined a small firm in which I was the sole developer. My job was to maintain and develop the firm’s flagship product, a data visualization package written in C. I ported it to C++ to ease maintenance, and continued to maintain the product. I liked my job, but I hated C++ as it was a very primitive, poorly designed programming language. It was so bad that it created entirely new classes of programming problems due to its shortcomings, and it prevented entire classes of solutions, also due to its shortcomings. I still despise that language to this day.
Well, the time came for a rewrite, and being the sole developer, I could choose any language I wanted. So what did I choose? Java? SmallTalk? Lisp?
I chose C++.
Why did I choose a language I hated? Because by then I realized the language didn’t matter that much.
Now this may seem like a strange thing to say. Anyone who’s spent any time in development forums has seen language wars, carried out with such fervor that even ISIS would ask the participants to stop being so dogmatic. So to say that the language is actually not that important seems to completely fly in the face of common wisdom. But it’s true.
To get things done in a language, one must write code. However, the things one can actually achieve is governed by the libraries available. The libraries are units of functionality that developers can re-use. Some of these libraries are part of the distribution for a language product, others are built by 3rd parties. These libraries allow the developer to do things s/he either couldn’t do, or could only do with great effort otherwise. So for instance, you can have libraries for performing complex numerical operations, animations or even GUIs. Even a powerful language will will pale in comparison to a weak one with a powerful set of libraries. And this is one reason I chose C++. At the time, it had the best libraries for the GUI features we needed, and they best adhered to the look and feel of the O/S we shipped on, which was essential for us.
Nowadays, performance is nowhere near as critical as it used to be. Our computers are so powerful that anything we write will be fast enough, except in some rare circumstances. However, efficiency was more important back then. Systems were weaker, and not all languages had efficient implementations. Furthermore, many of our clients used even older (and hence slower) systems, and we wanted instantaneous responses – even a 3 second delay was way too much for us. For this, C++ again reigned supreme.
Programming isn’t just about writing code. We need other tools. These tools can help us debug, design GUIs, profile our code or more. The C++ system I used had an integrated debugger, syntax highlighter and most importantly, a GUI designer. I could draw, drag and drop the widgets I wanted, and with a few clicks of the button, tie them into the events I needed. This was such a huge deal, that I didn’t care about the underlying design of the GUI library, and disregarded far cleaner libraries who didn’t have this tooling. Integrated tooling (or really, any tooling support) was not that common back then. Once again, the C++ system I used reigned supreme.
Note that none of these were advantages of C++; they were advantages of a particular C++ distribution I chose. Had my options been another C++ system that didn’t have these features, I would have dropped C++ like a bad habit and without a second thought.
Asking the Right Questions
Why do people pay so much attention to languages instead of tools? Well, there are a few possibilities. First, they may be more interested in what one can get done in a language outside of a library. This is a bit of an abstract question, as any practical development will leverage existing tools. Second, they may not know what the right question to ask is. The issue here isn’t what language is better or worse; rather, it’s what has the most impact on developer productivity?
When people ask THAT question, then it becomes obvious that we need to evaluate the developer tool set, and that language is only one component of this tool set.
For instance, how quickly can developers produce a solution? What’s the bug rate? How maintainable is the solution? Many variables go into these answers. How good are the developers? What methodology are they using? What tools are they using? These tools include – but are not limited to – the language. For instance, some languages require more lines of code to implement a feature. Since bugs are proportional to lines of code, this generally means buggier products will get produced. Or another example, some languages make refactoring or object decomposition harder, and as a result developers may refactor or decompose less aggressively. Alternatively, some editors have refactoring support which may encourage developers to refactor more often.
Unfortunately, in the past, a lot of the newer languages ignored these factors. For instance, I remember a very nice language called Haskell. It was powerful, elegant, it really was something to behold. But at the time I was checking it out, it had no real tooling support. As a result, I never even attempted to use it in any of my real work, and relegated it to something I played with for fun.
Fortunately, this is getting better. Researchers seem to understand that you cannot ignore the tool set, and many systems now have good libraries and good tools, or are designed to leverage 3rd party tools that provide the same.
My Ideal Tool Set
For instance, ask me what tools matter to me, and I’ll give you a list which includes the following:
- Higher order functions like map, filter and fold (aka reduce)
- Class based objects
- Duck Typing
- Automated Testing (Unit, Integration, End to End)
- Console Logging
- Regular expressions
- Syntax highlighting
- Automatic source code reformatting
- Project support (creation, searching, viewing)
- Rich GUI library
- Build automation
Notice how many of these are not language features, but external tools.
Angular: This is a framework that simplifies coordinating a GUI with the model by use of an MV* framework. In addition to all the automatic data binding, it also adds some useful html attributes.
Vex, Bootbox, Sweetalert and more: These provide enhanced dialog boxes.
Jasmine, Mocha, Chai, Cucumber, Gherkin: These are testing tools that provide testing languages and even specification languages that treat specifications as behavioral tests, thus giving developers the ability to automatically check specs.
Some Cold Water
As I stated at the start, computer science is still a young field. It’s also a hot one. Whether this is an advantage or a disadvantage remains to be seen. The fact that it’s such a hot field means that there’s a lot of research and a lot of tools. However, this means there is also a lot of hype. Everyone seems to have their own tool or methodology to promote, and there have been some spectacular failures. What’s hype and what’s not is not always clear.
But even with useful tools (including libraries), there’s the problem of Balkanization. With so many tools available and no clear leader among them, a large number of people end up using mutually incompatible tools. This means that people moving from one project to another may have to face the learning curve, and this decreases productivity. In addition, if these tools are incorporated into other tools, then we run into the possibility that some project may incorporate a set of tools that clashes with another set of tools, and resolving that also hurts productivity This sort of thing happens depressingly often.
Finally, the newness of the field means there is little hard research on what works and what doesn’t. Given a technology X, the only way to evaluate its effectiveness is to study a statistically significant sample of projects using it, and (controlling for other variables) determining if those products increased productivity.
Although there are few such studies, there are some. Here are a few that I found:
- This studies whether the programming language used affects productivity
- This asks how software tools impact productivity
- Research on how programming methodologies affect productivity.