Programming Languages and Tools

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.

Libraries

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.

Efficiency

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.

Tools

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:

  • Closures
  • Higher order functions like map, filter and fold (aka reduce)
  • Reflection
  • Class based objects
  • Duck Typing
  • Automated Testing (Unit, Integration, End to End)
  • Debugging
  • 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.

The Example of JavaScript

JavaScript is an example of a flawed language that managed to achieve remarkable success. Its success is not intrinsic to the language, but is due to the fact that it drives browsers and has a ton of libraries.

Here’s a quick sampling of some of the libraries/frameworks available for JavaScript

Lodash: This library offers a whole host of data processing features, like the ability to zip data, partition it, and even run data through a pipeline. It is not only useful in and of itself, but it also enables JavaScript developers to write in a more functional style (and this isn’t the only library to allow this).

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.

And this doesn’t include libraries designed for very specific purposes, such as the many game design libraries in JavaScript, You can get a sampling here.

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:

2 thoughts on “Programming Languages and Tools

  1. I agree that the language, in and of itself, doesn’t matter. What does matter is the ecosystem, the tools, libraries, and internet mind-share around it. People argue endlessly about which is best, but it’s always seemed to me that the real issue is to avoid languages or frameworks whose ecosystem either isn’t there, or is fragile, subject to disappearing if a small company or small open-source project disappears.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s