Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Backward Compatibility: How Long Is Long Enough?

If programming technology is to evolve smoothly within a language as well as between languages, we need better agreement on advance warning for breaking changes, and on how long vendors should support deprecated code.


advertisement
he media, particularly over the past decade, has made a huge point of discussing how fast computer technology changes. Terms such as "Internet years" and "Moore's law" have been used so often that they are part of the public vernacular. However, the practitioners of computer technologydeveloperswhen confronted with the reality of technological shifts, will have a wide range of reactions running the gamut from eager acceptance to resigned acquiescence to angry denial to complete loss of trust and abandonment of the altered technology.

Recent shifts in focus—from text files, COM, classic VB, and C/C++ to XML and Web services, .NET, and Java—have helped illuminate some of the problems involved in rapid change. Although some programmers embrace these changes, either individually or en masse, others question whether XML provides any real gain over text files, or decry the loss of COM and deterministic finalization, detest the march toward Web services, protest the language changes to VB, or deny the increasing influence of Java. Although software vendors try to ease the pain of such transitions by offering "backward compatibility," "interoperability," and "support," the reality is that these services, like the replaced technology itself, are finite.

As just one example, a loooong time ago (in Internet years), the Basic language introduced a command called "GOTO," which let programmers write commands such as GOTO 200. The command caused the interpreter to stop executing code at one point in a program and to begin executing code at another point, line 200 in the example.



10 PRINT "START" 20 GOTO 200 30 PRINT "END" 40 END 200 PRINT "Hello" ' print something 210 GOTO 30

The ability to jump around within program code quickly led to the concept of structured programming, in which the GOTO was augmented with an "execution stack" (a way of automatically keeping track of certain points in a program) and two new paired commands called GOSUB/RETURN. This new command let programmers write GOSUB 200which would, like the GOTO command, jump to line 200 and begin executing code therehowever, the language also pushed the address of the code line after the GOSUB onto a stack. When the machine found the command RETURN, it would pop the top address off the stack, and begin executing code at that point. In other words, the GOSUB command automatically executed an implicit GOTO command that returned to the command following the GOSUB.

10 PRINT "START" 20 GOSUB 200 ' push line 30 onto the stack 30 PRINT "END" 40 END 200 PRINT "Hello" ' print something 210 RETURN ' pop the top value off the stack executing an _ implicit GOTO back to line 30

That's a useful concept. By adding the ability to use named code blocks rather than line numbers (yet another layer of indirection), you get code that begins to look relatively modern:

Sub Main Print "Start" Call printHello() Print "End" End End Sub Sub printHello() Print "Hello" End Sub

Because people (even programmers) understand words better than abstract line numbers, such additions made programming easier and paved the way to a period of prolific coding. However, code isn't as adaptable as people. The relatively simple concepts that make the last example easier to understand than the first example also introduce a potential problem. The language vendor must decide whether to continue to support the first version.

That's easy once, but often becomes more and more difficult as the older version becomes less and less popular. The problem occurs when the vendor decides to stop supporting the older features. Now you have a problem. How do you migrate code from earlier versions to later versions when the supported feature set changes between versions?



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date