/

If you're a developer, wouldn't you like to get more done? And if you're a manager, wouldn't you like your developers to be more productive?

I would argue that in the 90s, individual developer productivity was higher than it is now. Our goal here is to understand:

  1. Why it was higher
  2. The (good) reasons it went downhill
  3. What we can learn to improve productivity

Why was it higher?

The short version is that there was more productivity-oriented tooling; but exactly what was it?

RAD IDEs

Rapid Application Development - Integrated Development Environments

In the 90s, programming languages weren't just languages; they were entire toolsuites. There were two most dominant general-purpose languages, C(++) and Pascal. Each had its own tool suite.

The example I'm most familiar with is Delphi. This was made by Borland, and is a descendent of Turbo Pascal (if anyone is interested, there's an Open Source version called Lazarus).

The big advantage here was that it allowed one to drag and drop components onto forms (or reports), edit the properties, attach them to databases, and then it created the backend code to make it all happen. Want to know what happens when you click a button? In the GUI editor, go to the Events tab, click the onClick event, and the code will appear in the code editor.

These were not the only languages with an attached and integrated tool suite; MS Access is a classic example of one that's still like this.

Domain-Specific Languages

These were languages that specialised in particular areas. There were a number that specialised in databases/tables; amongst these were SQL and the xBase family of languages, the second of these being one of the main inspirations behind TOP. These languages had their drawbacks, but they were usually particularly good in the areas they specialised in.

Why Did it Go Downhill?

From about 1995-2005, there was a lot of change happening.

Fragmentation

Fragmentation of Programming Languages

From there being only a few languages, there was a great proliferation of languages; Javascript, Perl, PHP, Python, Ruby, and other scripting languages hit their stride around this point. Competing more directly with C/Pascal, we had Java and C#.

This meant that each language community put the majority of their effort into the language, and less into the tooling. When there *were* efforts towards tooling, they were often multi-language, meaning that more languages got covered, but at the expense of other IDE features.

Open Source got a big boost during this era too. With so many langauges being available for free, people also, in my opinion, became less willing to pay for both languages, and IDEs that would make them more productive.

Was this good? Yes, we got some great programming languages out of it, and got people to rely less on C. Was it worth it? Yes.

Fragmentation of GUIs

In the early 90s, each OS generally had one GUI, and that was what you developed for. The primary GUIs were MacOS and Windows, with XWindows (Unix) also being in the mix.

Then came the Web. The web was not well-designed to be a GUI (especially in the early days), but that didn't stop people trying. None of the GUI design tools worked for making web interfaces.

Was this good? Yes, because now when people wanted to use a program, they could just go to a website, instead of having to have a box with some disks and a manual mailed to them (or they'd have to go to the store to get it). Was it worth it? I'd say yes.

Scaling

Programs changed from the days when most PC programs were made by developers sitting at home coding. Suddenly there were issues of scale (which had been faced before, but often on corporate servers, rather than PCs).

Scaling of Concurrent Users

With the advent of the web in 1995, suddenly many more programs were being run on centralised servers. On the plus side, people didn't have to distribute their software any more; it was nicely there on the server. On the minus side, this meant that programmers were suddenly having to worry about scaling their programs to multiple simultaneous users on the same computer.

Was it a good idea? Yes, because of all the things we can do with the Internet. Was it worth it? Yes.

Scaling of Developers

Instead of a single person working on a program, there were now multiple people working on programs. Source control programs existed (eg. RCS, SVN), but with the release of git in 2005, we finally had an Open Source solution for source control that was powerful and actually worked.

Having multiple people working on a program introduces some overheads. Wanting to keep the production environment running while testing in a shared area introduces more overheads. Think about the amount of time it takes you to make an one-line (or one-character) change on your local, vs. the amount of time it takes to commit it to development, staging and production in a useful way. Then there's documentation and the like.

Was this a good idea? Yes, because now multiple developers can work together, and websites are less likely to go down. Was it worth it? Yes.

Scaling of Development Teams

With the scaling of the team, UI designers were introduced. This was definitely a good thing, but generally meant that there was one more person who had to be involved in the GUI design; it was no longer enough to drop some components on a form and call it done. In some cases, the design tools weren't even fully accessible to the developers unless extra licenses were bought.

Inflexible Languages

Many drawbacks to OOP have been pointed out over the years, and various OOP modifications have been made to overcome them (eg. roles, aspect-oriented programming, and the like). A full-orbed OOP system is useful, but a poor one has its own scaling limits just like non-OOP programming does.

Just as the "everything is a function languages" (like early PHP) found it more productive to add the object-oriented paradigm, so the "everything is an object (and only an object)" people were hampering their developers. Unlike the other items in this list, this one is currently alleviated by the mere existence of multi-paradigm langauges (but how to get people to use them?)

Downhill Summary

Were the things above worth it? Yes. Did the things above make our lives harder by reducing the available tooling? Also yes. What can we do about it? Read on!

How Can we Improve Productivity?

Much that once was is lost, for none now live who remember it. ... And some things that should not have been forgotten were lost. History became legend. Legend became myth. And for two and a half thousand years, the Ring passed out of all knowledge.

Galadriel (voiceover), The Fellowship of the Ring movie, Peter Jackson, Fran Walsh, and Philippa Boyens

There are still things we can learn from RAD IDEs and DSLs.

What can we learn from Domain-Specific Languages?

Before delving into DSLs, I'd like to make a very brief visit to:

Multi-paradigm Programming

Each programming paradigm is a tool in your toolbox. The more paradigms a programming language allows for, the more tools you have in your toolbox. Each paradigm not available is one less tool in your toolbox.

With this in mind, the best way to get the benefits of a DSL in the modern era is not to use the DSL, but to integrate the paradigm of the DSL into a language which is already multi-paradigm. My personal preference is Raku (see Paradigm Comparisons for more information).

Learning from DSLs

No doubt there are many things we can learn from DSLs, but I'm not familiar enough with most of them to derive the lessons here. I can highlight only one particular one we can learn from (that's not a markup language), and that is Table-Oriented Programming. In the 1995-2005 era, Table-Oriented Programming (TOP) was argued to be an alternative all-encompassing paradigm to OOP. Neither won this argument, but OOP was accepted in large part ("everything is an object, but maybe not just and object"), whereas TOP, to the extend it was used at all, was left to SQL and spreadsheets. But the lessons that TOP has can be applied in a multi-paradigm setting without disrupting the other paradigms, and will improve our data handling.

What can we learn from RAD IDEs?

Lessons from RAD IDEs

The lesson here is easier for me to identify, probably because I've spent more time over the years using various RAD IDEs. The big lesson is, in many cases, visual editors of various sorts make people more productive. I think I can best express this by making a bullet list of the things that I think should be implemented in an IDE that fully supports Programming Productivity:

UI Churn/Volatility

One final lesson -- this isn't from RAD or DSLs, but from the SmartDB advocates.

Slides for The Database: Persistence Layer (NoPlsql) or Processing Engine (SmartDB)?, Toon Koppelaars

In the talk referenced, Toon Koppelaars made points similar to the following:

This is why I added a database design tool to the list of editors