Why are there so many programming languages?

Programming languages will continue to evolve, challenging projects and providing interesting opportunities for software developers.

Back in the late 1990s, I spent some time evaluating development tools. It was the heyday of fourth generation languages (4GLs) and client/server computing, with PC-based applications accessing server-based data. There were many tools to choose from.

Because there were so many tools, there was a lot of competition. Some tools failed completely. Some were left as niche tools, with expensive support and little or no further development.

In our evaluation, we concluded that the most viable options for application development were general-purpose third generation languages (3GLs) with a large installed base and good vendor support, in particular C/C++, Visual Basic, and the then-new Java. More advanced 4GLs, such as FOCUS and PROIV, were more risky because skills were less available, there was vendor lock-in, and there was a higher risk of the tools failing. The long-term risks outweighed the efficiency advantages.

Since then, the market has developed much as we imagined. Fourth generation languages (4GLs) have not become dominant. Java has become a dominant language and technology. For Microsoft platforms, the .NET platform, with C# as well as Visual Basic, is now dominant. C/C++ remains the language of choice for a lot of technical development.

Although there has been some consolidation around Java and .NET, there has also been a great proliferation of languages, especially for web development. Java Server Pages (JSP) and ASP .NET are understandable as extensions to the Java and .NET architectures. Other web languages, such as PHP and Ruby, have grown too. There continues to be an expansion of interest in all types of programming languages and environments, such as creating an improved language that runs in a Java environment or running Tcl in Google Chrome, to pick a couple I have come across recently. Even the 4GLs of the 1990s continue to hang on.

Some of the proliferation is rational competitive evolution, with better tools overtaking the less able. However, there are other forces at work.

There is a fundamental characteristic with tools that are specialised for a particular purpose, such as client/server tools in the 1990s, or today's web development tools. They provide value because they meet the requirement well, but their specialised nature makes it harder for them to evolve. Change in underlying technical requirements therefore drives new tools, though the old ones linger on.

The evolution of open source drives proliferation by allowing old tools to survive. Tools which could not survive as commercial offerings can be developed and kept going by a few dedicated individuals or desperate organisations.

And of course personal preference, stubbornness and gratuitous reinvention all drive people to use different tools.

Whatever the reasons, programming tools are continuing to proliferate. If you need to choose a language for a new project, you need to think carefully about long-term viability. This year's hot technology may be next year's legacy.

But on a personal level, this continued diversification can be a good thing. As well as continually generating new opportunities, it is one of the things that makes the job fascinating. Although it may be irresponsible to say to, I hope this trend continues.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Google Docs saves the day!

Google Docs' collaboration features are particularly good for occasional users because they do not require any software setup on your PC.

In my company, we work remotely from each other and use technology to collaborate. We use email.

We make a lot of use of Skype. Recently we have started using Dropbox for sharing files.
The one bit of the collaboration puzzle that we still have problems with is when more than one person needs to work on the same document at the same time. This is useful for collaborating on design, and on client presentations and proposals. We do not do this very often, so our approach is not that well thought through.

Last week we needed to work together on a data model for a new part of our Advisor product. We tried lots of different methods.

First, we tried the YuuGuu add-on to Skype. We have used it before, and it worked very well. But since then I had bought a new PC, and I needed to reinstall YuuGuu. I could not then connect through to my colleague's PC, so we tried something else.

We tried Windows remote assistance, which lets two people share one session. But we had a lot of difficulties sending the remote assistance request from one PC to the other. We tried using Windows Messenger/MSN Messenger/Live Messenger (or whatever it is this week), which can make it easier, but got caught up in version differences and could not get it to work.

Being Linux enthusiasts, we tried a shared Virtual Network Computing (VNC) session on one of our Linux machines. We have used this before, and it worked very well. We even have a virtual machine on one of our servers that we use just for shared VNC sessions. But the server was running a bit low on memory, so we could not use that. I tried using another Linux machine, but hit problems configuring the network and VNC.

I spent two or three hours trying, and failing, to get these methods to work. Then I stumbled into Google Docs. Google Docs is an online office application, with word processor, spreadsheet, and presentation and drawing software. It allows you to share your documents with other people, and, if both of you are editing it at the same time, to see each other's edits in real time.

For our data modelling session, we used the drawing application on Google Docs while talking on Skype. It let us all see and change the models as we discussed them, and, although it is not a specialised data modelling tool, it worked really well for our session.

I am sure we could have got any of the other methods to work, and they would have allowed us to share much richer applications than Google Docs. However, because they require software on the PC, and because we do not use them often enough to have an up-to-date installation and configuration, they were just too hard. Because it does not require any setup on the PC, Google Docs is just much easier.

For simple collaborative working, the combination of Skype and Google Docs is an excellent option, and much easier than more feature-rich solutions.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Climbing the code face

Testing is not something that we do because we are strong at development. It is something we do because we know that we are weak.

Over the past few weeks I have been working hard on a new version of our Metrici Advisor product. Some days the work goes well. Some days, not so well. Last week it was very heavy going indeed - I had been working long hours and was feeling rather unwell.

I always write tests as I code, and so most of my time is spent swapping between the real code and test code. This was getting very hard and frustrating. I was finding errors in code I had written previously. I kept losing my place in the code and the tests, and getting lost in the twisty bits. And worst of all, the tests kept failing, and it was taking a long time to get a clean run through.

But then I realised something that made me cheer up. By testing as I code, I can overcome the difficulties that I have with development.

If I was infallible, then all my earlier design decisions would be perfect. I would not lose my place in the code. I would not need to write tests, but if I did I would always pass them first time. If I was feeling overworked and under the weather, it would not make any difference to my work.

But I am far from infallible. I get things wrong all the time, and have to rework the code frequently. I mistype things, and put errors in as I work on the code. I have bad days, and some days I can not seem to remember how the code works at all. Sometimes I spend hours wondering why my code does not work, only to find a silly error in my test data.

But the thing that made me cheer up is realising that by writing tests as I code, I can make progress despite these shortcomings. I do not test because I am some sort of super-guru of development who writes beautiful tests to prove how clever I am, I test because I am an all-too-fallible human who stumbles from error to error. And yet, despite these disabilities, a process of testing as I code lets me deliver high quality code to very ambitious deadlines.

Development is like climbing a mountain. When you climb, gravity is always against you, and there is a constant danger of falling. However good you are, you have to constantly insure against danger with ropes and pitons and cams and other equipment. But by accepting the danger and the constant possibility of error, and doing something about it, you can literally climb mountains.

The internals of our system, like most large systems, is horrifically complicated, much more complicated than the most gifted of developers could deliver unaided. But by recognising our shortcomings, and adopting processes that overcome our weaknesses, we can deliver it. By accepting our weakness, we can scale the mountains of development.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.