Monday, June 22, 2009

Visual Basic is destined to die

Visual Basic is going to die because there are five specific things that kill parallelism:

1. Shared, global, mutable state.
2. Side-effects all over the place
3. Mutable data in just about any scope.
4. Synchronous communication between threads
5. A highly imperative approach to coding.

All of these things are the bread and butter, the day and night, the warp and woof of life for a Visual Basic programmer. I challenge you to show me any sizable Visual Basic App currently in use in any department in any corporation that does not manifest all five of these elements. Element 4 is the only one that might possibly be missing. If so, it is only because the application is absolutely single threaded, with no split between interface and worker threads at all.

For these reasons, I think Visual Basic is going go the way of dBase and FoxPro. I am not alone. There are many within Microsoft who do not believe that Visual Basic can be saved. Better minds, and less biased minds, know the culture of Visual Basic will have to be violently altered to permit a wide deployment of parallel processing through this language community.

Bill himself, does not like notion dead VB in the EOL category. Bill may personally see to it that the system lives a little longer than it should.

How would Bill save Basic and do a really good job of it at the same time? The only way to achieve this is for Microsoft to (once again) make violent changes to the language and overall software pattern of the Basic language. This happened once before. When VB.Net hit the market, VB programmers almost became violent over the loss of COM objects (such as DAO and ADO) and the kind of performance degradation their favorite sloppy language constructs produced. They screamed their lungs out.

So Bill could order the construction of PB--Parallel Basic--that would not allow Global.bas files, enforce class encapsulation, push immutable data, and statelessness, but... Can you imagine how much more upset VB programmers will be if and when they were to discover than Microsoft had removed the Module, the Global.BAS, and the ability to float global variables, the ability to do functions without classes in PB? Can you image what would occur if every DIM statement produced a value identifier that immutable by default?

I believe the typical VB programmer would be livid to the point of heart-attack and stroke.

It might just be easier for Microsoft to place Visual Basic in the EOL category, and offer no further upgrades to this language. EOL means End of Life. They did it to FoxPro. They did it with their Fortran product (which was excellent). They did it to VBScript & ASP.

This brings us to the subject of Oslo and M. Already there is a theory that Oslo, also known as the M language, is being groomed by Microsoft as the declarative and thread-safe replacement for Visual Basic. According to the poop sheet, M is going to be an extremely parallel language system. Lots and lots of parallelism is going to happen under the hood whether you know it or not (as is the case in SQL). More will be availible if you simply learn & implement a few elementary patterns of development. It has to be seen whether a recalcitrant and stubbornly lazy VB community will even be willing to learn this new programming system.

At this point the Visual Basic programmer is probably screaming his head off "AS IF ANY OF THIS IS REALLY NECESSARY?? WHAT THE FUCK IS THE BIG DEAL ABOUT THREADING?" I have stood nose to nose with 54 year old VB programmers paid $95K+ as they insisted that that sort of programming is categorically unnecessary in an LOB departmental programmer's tool kit. "Yeah, but we'll never have to do that kind of thing around here! Why would it ever be necessary? That just isn't necessary."

Make no mistake about it: we are all going to have to program in parallel. We are going to have to use threads and PLinq and everything else that PCP throws at us. This is the only way our apps will be able to handle the terabytes of data we will be required to process in the next decade. The world changed in June of 2005, and most programmers have still not accepted this fact. Processors are not going to be getting that much faster in single-thread execution mode. Processors are going to become massively more parallel. We are only going to get faster by exploiting multiple cores at a time. We can only process increasing volumes of data by abandoning the single threaded and dual threaded application architecture. This means you will not be able to continue making a living programming in single threaded or dual threaded mode. Parallelism is the new God and maximum imperative of programming.

I find that most programmers in most languages are in a vehement state of denial about the gravity of our current CPU architecture. No where is it more stridently expressed than in the VB world. VB programmers are strident because they have great reason to fear. Many of the better VB programmers have tried their hand at threading. Most of them discovered threading caused all manner of problems in their applications. Basically, threading broke their existing application architectures. This is because of shared, global, mutable state, uncontrolled side-effects all over the place, synchronous communication between threads, and a highly imperative approach to coding?

So what about C# and Java? Java and C# programmers have a tendency to thread more in their apps, but these languages may not survive either. C# is a bit better off than Java. C# has absorbed many features of functional programming, although it is much more difficult than it should be to do immutable data. Also, F# is not a very good challenger for C# on the .NET side. Many question whether it was ever indented to be. Java, on the other hand, has not really absorbed anything of the gospel of functional programming. Java still preaches the old-style of lock-based, synchronous communications thread model. Java is also faced with a serious threat of replacement by Scala, which is surging in popularity all over the world. There is no real doubt that Martin Odersky intends Scala to be the general-purpose replacement for Java on the JEE platform. He has explicitly testified to this in interviews.

Neither Java nor C# is guaranteed survival in the coming marketplace, but I firmly believe Visual Basic is dead.