BLOG – Currents – 23 Feb

It’s been one of those weeks where I have been buried in the realms of DAO, ADO and somebody else’s programs. As I have been working my way through the process I have also been thinking about programming languages and how they have developed.

I started my programming career coding in Assembler, APL and Basic. In University there was Fortran, C, Pascal, Prolog, Lisp and Cobol. Later there was C++, object orientation, object databases and then the development platforms like the James Martin IE, Visual Studio and the Delphi IDE. Over the years there have been other languages like mainframe scripting, JCL, JavaScript, VBScript, HTML, ASP and others.

Working on the migration project raises a number of issues that have to be solved like the differences in access SQL versus T-SQL. It's been my experience that the date handling parts show the biggest difference. There are also some subtleties when working with sub selects in SQL. Sometimes the differences are very minor but essential to get that part of the project working.

The IT industry in general is always trying to push people to the next greatest thing. For Microsoft this is SharePoint. For others it is the latest iteration of Java. Not so long ago it was Web 2.0 and Ajax. Ironically many like myself spent a great deal of time migrating older systems to newer platforms. For the current project this is Access to SQL Server. Since Delphi 5 is so old without a complete platform change the project needs to stay in Delphi and because of the way component packages work is cannot even be moved to a later version.

This kind of restrictions can raise all sorts of tricky barriers. Delphi 5 marked the first entry of Borland into ADO. Since ADO is the best option this means the developer is stuck with the best implementation available. At the time of writing the current owners of Delphi have not been able to find the necessary components because the platform is simply too old. In this situation it often boils down to some creative programming. When not rewriting a whole system is also necessary to quickly come to grips with the pieces that need to be changed and how the last programmer put them together.

In this case the previous programmer was one of those what I call "clever" programmers. Instead of using the simplest and most direct solution they leverage all the tricky pieces of the development environment. For example instead of directly calling a new form a call in action list which then calls the form. It's clever, it works, but it is unnecessarily complex and provides no real benefits.

As I was thinking about these things I read an article about the need to COBOL programmers in Australia. The Sydney-based company Object consulting has produced a paper outlining those languages they believe will no longer be supported in the near future. These include .NET 2.0 and Cold Fusion. Their view is that programming languages typically have a three-year shelf life. So if you have a built-in FoxPro, Pascal, RPG or Smalltalk you should get rid of it and implement something newer. They have some valid reasons like non support and no further development of such environments. Of course they also specialise in moving applications from older to newer architectures.

The problem with such altruistic opinion is that there are still a huge number of legacy systems written in the old languages like COBOL. The biggest problem is that the programmers who knew these languages are getting old and retiring. The new programmers coming up through the ranks have never been exposed to such languages and now there is a serious issue of maintenance.

It is estimated that nearly half of the current systems in major organisations are still COBOL and RPG based. In Australia this includes all of the major banks, all of the large insurers, and more than half of the government systems. This means that legacy COBOL, Fortran and say Delphi applications are becoming more difficult to maintain. I worked with COBOL for four years but I would find it difficult to jump right in and maintain an application.

So the question becomes should young people be trained in such languages so that they can migrate to more easily. Or will the future be a large series of major redevelopments, almost from scratch, to provide applications for the future. The longer these large organisations wait to bring their applications into the modern age the more difficult will be because those that know the old languages will have retired. On the plus side for these experts they will be in demand and there should be some lucrative offers to entice them out of retirement.

Another issue is what to do when such a system fails and is no one there to fix it or repair it. This could be very costly in say the banking or insurance worlds. So if you are a young programmer reading this my advice is learn as many of the old languages as you can, why you are learning new ones. With such a skill set it will be easy in the future not only to find a job but a good one with a high salary. It might be more fun to code in Ruby on Rails or JavaScript but the real money will be in these legacy migrations.

Industry News

Somebody has found a privacy hole in Apple's iTunes Store. If you know what to do you can find out what someone else has purchased. Ironically the technique was discovered by Andrew McAfee through the gifting interface. The privacy ‘hole’ was set up with the intention to warn you if your gift had already been purchased by the recipient. Personally I do really care if somebody knows what kind of music I like that the privacy advocates to.

If Apple notified the recipient to somebody who tried to send them or enquire about their gifts this might be better but that doesn't happen. There are also some legal concerns in places like the US where the Video Privacy Protection Act makes it illegal for those buying a ‘video tape’ to provide information about the customers viewing habits which is what this hole does. Just ask Netflix what happens when you provide seemingly innocent details about what their customers are watching. Amazon has a clever solution for Kindle gifts. If the recipient already has its they get a credit for the value of the purchase.

On the subject of privacy is apparently quite difficult to wipe sensitive data, or any data, off a flash drive. Some of those white coat wearing people have worked out a traditional disk erasure techniques do not work very well on flash media. Even when files are shown is deleted the majority of the data may still be present even if they are "securely erased". It is something to do with the way that the data is stored on the technology used compared to traditional hard drives.

The researchers found example as much a 67% of the data stored in the file remained from an SSD using say the secure erase feature found on Apple's Mac OS X. Different technologies and products varied in general it was always more than 50% of file left after the operation. Even defragmentation utilities did not wipe the data. Even degaussing did not work as well as it does on a hard drive. The best solution still seems to be keeping encrypted information and then deleting the encryption keys so that the data will remain encrypted forever. The data storage capabilities of flash drives increase this will become a more important security issue for the future.