We developers are not a superstitious lot. We work in a field where every cause has an effect and where anomalous events cause consternation and force remediation rather than elicit awe. There is no escape hatch by which we can dismiss unexpected developments as "God's will," or in its less-religious articulation, "Who can explain such things?" Part of this refusal to accept the inexplicable derives from the awareness that the software and hardware we work with is created by peers, rather than being natural phenomena who hide their secrets inscrutably.

As such, we don't indulge in the superstitions of other professions. But if we were to start, certainly "the curse of version 6" would be an excellent point of departure. For at least the last 30 years, version 6 of programming languages has often been particularly difficult, problematic, or in the case of a successful release, the point at which products begin a long downhill slide.

Consider Perl 6, PHP 6, VB6  each one so delayed as to try the patience of even the most dedicated aficionados. PHP 6 was such a twisted child that despite being under development since 2005, it had to be cancelled in favor of an upcoming version 7, whose release date remains unknown.

Perl 6 was first described in 2000. Fourteen years later, a full implementation has not been shipped, although nearly complete versions exist. The problems with Perl 6 were legion, and as the thorny politics spilled over the years, the language began its long, unabated free fall.

Visual Basic 6 (VB6) illustrates that the problem can even strike companies such as Microsoft, which has full control over its tool releases and has shown itself adept in advancing other languages, such as C#. VB6 was the last language to be ported to .NET. The migration to the new platform was greatly resisted by the community as a kind of "forced march," which was a reasonable assessment as there was considerable syntactical difference between VB6 and VB.NET. The result is that many programmers stayed with VB6 even though it was no longer being revved by Microsoft  writing what was immediately legacy code that many sites are still dealing with today.

VB6 is not the only Microsoft language that hit a road bump with that release. So did the much loved Visual C++ 6.0 compiler. At the time of its release in 1998, it was well regarded and widely adopted. However, it was the last native C++ compiler. It took four years for another release, which came out as part of the .NET toolchain. Earlier, Microsoft C 6.0 was the last pure C compiler from the Redmond giant. Thereafter, all C compilers were C++. PC developers who recall the early days of C programming might remember that the market leader, Lattice, basically disappeared after version 6 of its compiler. There is no doubt that if a version 6 does ship, it tends to bend the direction of the future. Java 6 was probably the least important major release of Java. It was also the last one under Sun's ownership and it marked the beginning of a five-year delay before another major release would appear.

It's easy and perhaps correct to view the "curse of version 6" as an example of cognitive bias, especially confirmation bias. Or put another way, given enough research, couldn't any release number equally support the idea of a curse? Perhaps, but I submit to you that certainly among major programming languages, version 6 has a negative track record no other release numbers can match.

The search for a possible cause should start by considering where the sixth release of a given tool or language appears in the product's lifetime. 1.0 is the big kick-off release. 2.0 corrects 1.0 and adds some missing features. By version 3, two paths emerge: The way of incremental upgrades or the path of a huge, monumental change. If the former path is initially chosen, there will eventually come the time when the language or toolchain must switch to the stop-the-world release, else interest and expansion of the community or tool sales will begin to stall. My thesis is that if that dramatic moment has not occurred by version 6, it occurs then or the product dies. Five releases without a massive change means a product that's been around for long time with no significant resolution of known limitations. So, version 6 has a do-or-die timing to it. This is certainly true of Perl 6.

Vendors that hewed consistently to the incremental upgrade path come to a decision point by version 6  what to do with a product that's now long in the tooth? Many times, companies release an incremental version 6 and then move on in dramatic new ways, supplanting the product with a whole different product line: (VB6, Microsoft C 6.0) This makes sense. By version 6, likely many years have passed since the original release and the need is now for something completely different. Companies that cannot find the recipe for addressing that "something different" begin a decline or stagnation. (Lattice, Sun Java).

It's tempting to go beyond programming languages and consider other deadly version 6 releases: WordPerfect 6.0, Internet Explorer 6, and so forth, but I think doing so definitely slips us into the cognitive bias I referred to earlier. I see it strictly as a phenomenon in programming languages.

C# now sits at version 5.0. Anyone for C# 2015?

 Andrew Binstock

Editor in Chief

[email protected]

Twitter: platypusguy

Google+