Not Another C# Versus VB Article

By Nigel Shaw Jun 2, 2005

24 comments

It's common knowledge that VB.NET and C# are functionally equivalent. Hence a frequently-heard argument for choosing one or another is that because they are functionally equivalent, neither poses a clear advantage. This argument has merit, but because it attempts to be diplomatic and avoid subjective opinion, it fails to get to the heart of the matter.

This article does not simply consider objective arguments. Rather, I attempt to explore some of the highly subjective factors which influence developers working in VB versus C#. These subjective factors taken collectively over time contribute to a certain culture. The VB culture is different from the C# culture.

By examining the history of the two cultures and their current trends, we can make predictions about how the choice of one language or another might influence the production of quality code in a production shop.

The Culture of Visual Basic

The purpose of Visual Basic was to create a mass market for software development tools. Prior to Visual Basic, application development languages were viewed as complex and restricted to the domain of skilled programmers. Visual Basic was syntactically simple, and it enabled virtually anyone with a few hours of time to learn how to create simple applications. In the days when software development was seen as more of a black art than an engineering discipline, the ability to be able to join the ranks of “software developers” was a powerful aphrodisiac for many computer users.

And join they did. Millions of “power users” of computers became millions of “software developers”. It happened that Visual Basic came along just as the demand for new software applications was escalating rapidly, driving demand and hence salaries for software developers higher.

The fact that Visual Basic was lacking in the fundamental building blocks of object oriented programming didn’t matter much at the time. Software was still relatively simple. Distributed application development was client-server at best. The web was so new that application development models for it had barely started to evolve—the business world didn’t even know where the web was going, so how could developers possibly know how to program for it? Web applications were hacked together, and it didn’t matter. To compound the hacking methodology, the sheer demand for web applications began to accelerate at a pace that exceeded even the wildest expectations by an order of magnitude. Application developer salaries skyrocketed, demand continued to increase, and the perceived need for a sane, sustainable application development model was left trailing far behind.

The peak of this trend coincided with the peak of the Internet boom. Vast armies of grossly under skilled developers were paid enormous sums of money and elevated to cult-like status to hack together anything that would even remotely resemble a software application. And Visual Basic, with its lack of formality and constraints that might slow down the hacking process, was just the right food for the frenzy.

Visual Basic was launched in March of 1991. In 2000 Microsoft announced .NET. in a move that swept the slate clean and replaced Visual Basic with what was in effect an entirely new development paradigm. The underlying classes against which programmers developed were completely replaced by the .NET Framework. The kludgy third party tools were swept aside and replaced by a clean third party tool model. The lack of inheritance and the limited implementation of polymorphism enforced for so many years by the underlying limitations of the Visual Basic engine architecture was overcome by throwing the old engine out completely.

With these changes, Visual Basic was reborn as a powerful new development platform, functionally equivalent to C#, J# and Java. In fact, of the Visual Basic of the 90’s, only two things remain today; the culture and the syntax. The culture of Visual Basic is the culture of the 90’s: build it fast, hype it up, sell it, and don’t worry about whether the story will hold together tomorrow, or even hold together at all.

To grasp how this culture affected trends in software development, it’s instructive to hear what Niklaus Wirth had to say about it in 1997. Niklaus Wirth is one of the most influential thinkers in the software world. A professor at ETH Institute in Zurich, Wirth designed Pascal, Modula 2 and Oberon. In the early 1970s, he was one of the people who proposed program development by stepwise refinement. He's the author of many important books, including "Algorithms + Data Structures = Programs" (Prentice Hall, 1975) and "Systematic Programming" (Prentice Hall, 1973) He was awarded the Turing Prize in 1984, and has also received five honorary doctorates and several other awards.

In a well known interview with Dr. Carlo Pescio, published in Software Development, June 1997, Pescio asks Wirth:

"You probably know about the 'good enough software' concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Do you think there is anything developers and software organizations can do about that? I guess many developers would be happy to be given more time to develop better software, but at the same time they are rushed in the name of corporate survival. 'Educating the users' seems more a wild dream than a possibility."

to which Wirth replies:

" 'Good enough software' is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensable luxury, but a simple necessity.

Recently I read a final report of a research project funded by the Swiss National Science Foundation. The project's naive goals were identified as follows: First, how can easy programming be achieved (in particular, for non-experts)? Second, how can a mechanism be realized that allows hiding the difficult parts of parallel programming? After more than 30 years of programming we ought to know that the design of complex software is inherently difficult. This despite of the fact that, for decades, the industry has been advertising programmers' positions by claiming that programming is easy. Later on, when doubts arose even to the advertisers, they switched to promising a wide variety of tools to facilitate the arduous tasks. Tools became the slogan; the right tools, paired with clever tricks and serious management methods, would work wonders. Then Edsger Dijkstra called Software Engineering 'Programming in spite of the fact that you can't'.

Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience, on precise, logical thinking, and on pedantic exactness. No magic will do. In the light of all this it is particularly sad that in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic. As a result, software engineering has become the El Dorado for hackers. The more chaotic a program looks, the smaller the danger that someone will take the trouble of inspecting and debunking it."

comments

Continue reading this article:
1 2 3 4 Next Page >

Useful article?
Email It

Follow @cmswire
Related Articles:

Knowledge Management in 2012? Probably Dead

Wrapping Your Head Around the SharePoint Beast

5 Signs Your Company Doesn't Get Social Business