Pinderkent

When you mention the Ada programming language to most developers, they tend to think of embedded software development, typically in mission-critical environments such as aircraft and electric power plant control systems. But we shouldn't think that such environments are the only place where Ada can be of use. For the past several weeks, I have been working with a shipping company that makes extensive use of Ada for their in-house software.

I haven't seen a company use Ada this extensively for such a wide range of software development tasks. They have back-end database applications written in Ada. They have client-side applications written in Ada. They've developed an in-house framework for developing Web applications using Ada. Even their custom build system is itself implemented in Ada.

So today I had an opportunity to talk with one of the managers there about why they use Ada so much. His responses were very interesting, I think. He said that Ada was introduced to their company by one of their developers in the early 1990s. Although they've had some difficulty finding developers who are proficient with the language, this manager reported enormous productivity gains for those developers they do employ.

I asked him to elaborate on the productivity benefits of Ada. The first benefit he mentioned was that it's a language that inherently leads one to develop high quality software. This is no accident, of course. The language was designed for this very purpose, and thus explains why it has been successfully used for a vast amount of mission-critical software. The manager said that some developers initially found it too restrictive, but soon enough discovered that by following its best practices, they'd produce software with fewer bugs.

The manager went on to discuss how by using Ada and peer-review, they were able to eliminate a great many bugs before their software was deployed. As anyone who has deployed large-scale applications knows, the earlier a bug is found, the better. But the manager also pointed out that by writing less-buggy software in the first place, his developers ended up spending less time investigating and fixing their mistakes, and instead were able to produce more software to help meet the company's business needs.

Many developers have reported similar benefits from programming languages like Eiffel, Haskell and Standard ML. Strong, static typing and other features like design by contract are known to help lead to reliable software. And so I asked the manager if they were considering using such languages. He replied that they had actually considered using Haskell for some smaller projects, and one of their developers was in the process of familiarizing herself with the language. He promised to keep me up to date with their developments, of which I am eager to hear about.

So far, this has been one of the most interesting clients I have worked with in the past while. After working with numerous Java, C#, VB.NET and Perl development teams over the last few years, it's refreshing to see a team that adopts an alternative technology like Ada, and manages to boost their productivity to a level that is rarely achieved. Maybe it's time for more developers to consider the use of Ada, even those who are working on fairly typical business applications.

Chris Diggins has written a great article about the power that visual programming languages might hold. One specific example he mentions is Scratch. Another is Logo. Perhaps we will see a much greater use of such languages in the future. But I am hesitant to think that such will be the case. Part of the reason is the impact that modelling languages like UML, and the tools built around such modelling languages, have had on today's developers.

Most developers have no doubt had to deal at one point or another with the various UML-based tools that are on the market. A number of these tools allow for the generation from UML of code in a variety of programming languages, including Ada, C, C++ and Java. Many developers have come to consider such tools as what constitutes "visual software development".

For developers who have years of experience using more traditional, text-based development tools, these UML-based systems can be quite painful to adapt to. Most capable developers will see a rather significant productivity drop while they try to learn these tools. The biggest complaint I'm aware of is how a developer will know exactly what he or she wants to do, but ends up spending numerous hours fighting with the UML-based development system to get that simple task completed. So from personal experience, I can say that many developers have come to consider visual development tools to be a major hassle, and a complete hindrance to the software development process.

In many ways, I think that's unfortunate. Although I haven't been able to look into it much, the idea of Scratch does sound very interesting. But I think it may be near impossible for such a technology to work its way into the development process of tomorrow, let alone that of today. I think too many developers today have gotten a very negative impression of visual development, and will want nothing to do with such techniques, even those techniques which take a different, and perhaps more effective, stance.