Are Development Tools Really That Primitive?

A blog post I read puts forward the assertion that the programming tools we use are stuck in the past (as in way in the past). The author’s claim is that the languages we use, and the ways we write software, are essentially the same as when people first wrote software in the late 1950’s. While I can understand why the author sees similarities, I would disagree with the premise that tools are stuck in the past. Part of the problem is that the author is conflating “language” with “toolset”. Perhaps it’s semantics, but I think the distinction needs to be made.

Code Is Text

I agree completely with the author that the code we write is still all textual. Our job as programmers is to write that text, and do so in a way that is (hopefully) maintainable, stable, reliable and scalable, within the scope of the requirements. But what I don’t see is why this is a problem.

We still build cars out of metal. We have for a long time now. At one point, cars were made primarily out of wood, with some metal components. Over time, wooden bodies and frames, which provide the structure of the car, were replaced with steel. Now, we see combinations of steel, aluminum and occasionally carbon fibre or advanced composites in some parts of a car. But is this a problem? I mean, we built ships out of metal back in the 1890’s. Does that mean working with metal is old-fashioned? Of course not. Certainly, metals have evolved, but a car is still primarily composed of some form of metal. There’s nothing wrong with that.

The Tools And Environments Have Changed

Languages may still be textual, but that doesn’t mean that they, and the tool around them, are still essentially “1950’s technology”. In the 1950’s, programmers used punch cards or paper tape, painstakingly typed out on primitive equipment, to write their code. Today, we have modern IDE’s with syntax highlighting, real-time syntax checking, code completion and more advanced ways to manage the components (objects, methods, functions, procedures) than were available 60+ years ago. Back in the 1950’s, writing a program of a few thousand lines (or tens of thousands of lines) was a daunting task. Debugging the problems, and finding errors, could take days or even weeks, even for relatively minor problems.

With today’s tools, most errors can be found in a matter of minutes or even seconds. There are still classes of problems that can take days or weeks to find, but these are typically the exception, and not the rule.But many minor problems are found before you build or deploy the code at all. A single programmer can easily maintain tens of thousands or hundreds of thousands of lines of code, and with modern languages, a single “line” could have the equivalent power of a dozen lines of FORTRAN.

We also have tools available to make testing easier, to make it easier to find performance problems, and to point out issues like memory leaks. We have static analyzers that will not only look for common kinds of coding errors, but even make suggestions on style and design. All of this, when used wisely, can contribute to building better quality and more stable code. To address these kinds of issues in the 1950’s required many hours or days of painstaking “benchwork”, looking at program listings, and hand-drawing flowcharts and such to try to understand where things like performance issues were.

Again, let’s look at cars. The first metal bodies were literally hammered and bent into shape by hand. With hammers. And brakes, rollers, English Wheels, lathes and other tools that have been used for decades or centuries. It could take hours or days for a craftsman to create a single part such as a running board or a fender. Fabricating the entire body could take a single person days or weeks, or a team of people several days. Today, bodies are stamped out of steel, with dozens of entire bodies created each day. All from machines monitored by a couple of people in some cases. The underlying material is still metal. But the tools to work the metal have improved dramatically.

Could There Be Better Ways?

There have been experiments with various approaches to programming, using visual programming tools where you work with graphic elements and “wire” things together. I’m sure there is research out there where people try to use spoken natural language instruction to create “programs”. And I would agree with assertions that, as programmers, we are actually pretty bad at sharing and re-using code. Sure, there are a ton of common frameworks and libraries for every language out there. But we have created massive numbers of things (e.g. entire applications for different platforms) that we either can’t share, won’t share or don’t know how to share. Just think about how many implementations of a General Ledger exist out there, and how many more are being created as I type this.

But I remain unconvinced that switching away from text-based languages is going to fix all of the woes that do afflict software. Let’s face it, we still build a lot of stuff that isn’t very good. It crashes. It doesn’t work right. It doesn’t work fast enough. Reliability is still an issue. I’m not sure that visual tools (as an example) will necessarily fix that, and if a visual tool could “figure out how it should work”, then that same sophistication could presumably be applied to conventional text-based languages.

Text has a number of advantages. First, you don’t have to train someone in the symbology before they start to learn to program. In today’s world, people who work with computers know how to type, and they can read the Roman alphabet. Now we have to focus on the language, and what some things mean. Many languages at least borrow a few things from english, such as “if” and “while”. We can “read” the code into some form of english to try to make sense of it (“if this condition is true then we do this thing here, otherwise we do this other thing”, “while this condition is true, do this stuff”). We can build on skills we have, and that we gained starting when we were 4 or 5 year’s old. We don’t have to learn something completely new at the foundational level that may or may not make us more productive.

I’m not saying that we are at the pinnacle of building software. My own anecdotal observations are that, compared to the state of the art back in the early 1980’s (when I got started), we have come a long, long way. That isn’t to say that things can’t improve, both in the tools and in the languages. But given that we still rely on some “primitive” underlying technologies for many of the advanced things in our lives, I don’t think textual languages as the root of what we build is going away soon. It isn’t that it will never go away, and I’m not saying that a seismic shift in how we design and build software isn’t lurking around the corner. But the fact that we still use textual languages comes as no surprise to me, and I am not all that disappointed that we still “type” things to build software.

Advertisements