Content Management System (CMS) News, Reviews, Events and Analysis.
 
 
 

Not Another C# Versus VB Article

By Nigel Shaw  | Published Jun 2, 2005   Comments  23 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."

In a minute, we’ll look at how the culture of Visual Basic affects the quality of code produced, even today, and how the last remaining vestige of Visual Basic, the syntax, unfortunately continues to reinforce the culture.

But first, let’s review the culture of C#.

The Culture of C#

To understand the culture of C# is to understand the story of Anders Hejlsberg, its chief architect. Hejlsberg deeply admired Niklaus Wirth. Wirth created the Pascal language from Algol, the first high-level language with a readable, structured and systematically defined syntax. Hejlsberg created the world’s first compiler for Pascal, and extended the language to include object-oriented capabilities (Object Pascal). Both were focused on the language’s elegance, at least in part because the language was designed as a teaching tool for students of programming languages to learn structured, and later object-oriented, development techniques.

Pascal was first embedded in a commercial development environment by Borland, with the release in November 1983 of Turbo Pascal, which employed Hejlsberg’s compiler on a licensing arrangement. Hejlsberg worked for Borland for thirteen years from 1983 to 1996 during which time he was the chief architect of Turbo Pascal and later Delphi.

Delphi, a direct competitor to Visual Basic, was regarded as vastly superior technically, even by Microsoft, who routinely plundered its inventions. To preview some of the features of each successive version of Visual Basic, it was generally recognized that one only had to look at the current version of Delphi.

Delphi, however, was hampered by a relatively insignificant development and advertising budget. While Microsoft plowed hundreds of millions of dollars into promoting Visual Basic, Borland had to rely primarily on technical excellence to drive usage through word of mouth. Hejlsberg knew his work would never achieve mainstream adoption while he remained at Borland. At the same time, Microsoft gradually came to realize that Visual Basic would never achieve the technical excellence of Delphi without Hejlsberg.

About the time when these two forces were starting to draw Hejlsberg and Microsoft together, a thunderbolt hit that would dramatically accelerate the fusion. That thunderbolt was Marc Andreessen’s endorsement of a brand new language (or at least one with a brand new name): Java.

Java’s precursor was developed by Sun’s Patrick Naughton, Mike Sheridan, and James Gosling in 1990-92, who had the far-reaching notion of connecting together small devices, such as video recorders and televisions, in cyberspace with a common programming language. The first version of Java was called “Oak” and was architecture-neutral, distributed, portable, object-oriented and secure. Although these qualities turned out to be just the qualities needed to develop applications for the web, the adoption of Oak for the web would have to wait until 1994. But the fact that Oak’s true potential would take several years to recognize was much less important than the culture in which it was born. For in 1990, Naughton, annoyed with the disparate directions in which Sun was heading, nearly quit and took his work to the more idealistic and focused neXT, owned by Steve Jobs. It was only because Sun’s CEO, Scott McNealy, solicited a report on the failings of Sun from Naughton, and heeded the report, that Naughton stayed. McNealy agreed Naughton would be allowed to create a small team of engineers outside of mainstream Sun in order to “do fewer things better."

Designed by a small team dedicated to technical excellence, Oak/Java was the antithesis of Visual Basic. Yes, it was more difficult to learn, but it was more powerful. And the proof was in the pudding. Java applications, when architected and built by skilled Java developers, were more powerful and feature-rich than the vast majority of Visual Basic applications.

Marc Andreessen, CEO of Netscape and therefore the “God of the Internet” at the time, was one of those who saw the potential of this new language. In 1994 he told the San Jose Mercury News: "What these guys are doing is undeniably, absolutely new. It's great stuff."

Coming from most people, such an endorsement would have been just another spark. Coming from Andreessen, it was the thunderbolt that shocked the world into a near-frenzied adoption of Java, and ultimately brought Microsoft and Hejlsberg together.

For Java was not perfect either, and by then the brilliant Hejlsberg was envisioning the next generation of application development language. Hejlsberg envisioned a language which would fully embrace the emerging component model for application development by making the three key constructs of component development—properties, methods and events—first class elements of the language.

In Java, for instance, properties don’t really exist. They’re “faked” by using the “get xxx” and “set xxx” syntax. In a property inspector they show up as “xxx” and you have to know that you put the get and set in the right places. This and other anomalies made Hejlsberg the perfectionist uncomfortable. He felt that the ideal language would require no such kludges or workarounds, but should instead roll all of the core constructs right into the syntax, giving the programmer a “one stop” experience. The problem was that this would require fundamental rewiring of the compiler, and significant research and development expense.

With Java rapidly gaining ground, by 1996 Microsoft was getting very concerned. They were taken off guard by the fact that an elegant, precise language that required a significant degree of programming skill and dedication to use effectively was making headway against Visual Basic. They also recognized that they needed more than just some reworking of the Visual Basic engine. They needed fundamental change. They made Hejlsberg an offer he couldn’t refuse. If he would come to Microsoft, he would be given a clean slate and a massive budget to create a “perfect” version of Java. In 1996 Hejlsberg began work on Microsoft’s J++ 6.0 and WFC, the Windows Foundation Classes for Java, as chief architect of both.

Microsoft J++ 6.0 and the WFC, born out of intense desire by the world’s most qualified software architect to make the very good Java even better, were the successors to Object Pascal and the Delphi Visual Component Library. And soon they would become the precursors to C# and the .NET framework.

For in 1997 Sun sued Microsoft over the changes it was making to Java, stopping the work cold.

Undeterred, with massive financial reserves, and wanting to get even with Sun, Microsoft upped the ante. It gave Hejlsberg an even cleaner slate, the mandate to write a new language that would be better than Java, and backed by a programming toolkit that would be better than Java’s.

The result, born in a culture that puts technical excellence first, unfettered by prior constraints and guided by the wisdom not only of Hejlsberg’s years of experience with Turbo Pascal and Delphi, but also by the wisdom gleaned from Java, is the C# language.

Syntax, Semantics and Cultural Persistence

We've seen that the cultures of VB and C# are very different. And we've seen that this is no fault of the programmers that use them. Rather this is a product of the combination of factors that collectively could be called their upbringing—business environment, target market, integrity and background of the original language developers, and a myriad other factors.

One factor, however, that seems to have a greater effect on the culture than others, is the syntax and semantics of the language.

To what extent do syntax and semantics play a part in the culture that builds up around a language and to what extent, vice versa, do the syntax and semantics depend on the culture in which the language was created?

The truth is, both—just as spoken languages both grow out of culture and influence culture. For instance, in the far north the language syntax has evolved several words for the different types of snow. Interactions then use the language to express nuances of snow, creating a more snow-centric culture.

So in Visual Basic, the decision to include in the syntax and semantics the ability to assign numbers directly to strings and vice versa was a result of the designers’ desire to attract a broad base of developers who would probably not understand the notions of strongly typed variables. Once the syntax permitted it, such assignment became widespread, reinforcing the designers’ original premise.

Once this cycle of self-reinforcement begins, the cultural habits quickly become entrenched and widespread, and are extremely resistant to change. Minds tend to gravitate to like minds. User groups tend to attract homogenous followings. Visual Basic instructors tend to propagate what their instructors taught them.

This awareness of the immense inertia of embedded culture is precisely the brilliant insight that caused Microsoft to keep Visual Basic and to make it nearly 100% backward compatible at the syntax level. They recognized that trying to get legions of developers to abandon their old cultural norms and adopt new ways was foolhardy.

The brilliant insight Microsoft had was not to support multiple languages—if this was the case then surely it would not have bothered with J#, which is syntactically so close to C# that support for language’s sake alone would be ridiculous. The insight Microsoft had was to support multiple cultures.

In Concrete Terms

What does this mean in concrete terms? What impact does this have on today’s application development? How does the decision to adopt Visual Basic or C# affect programs written today and tomorrow?

  1. 80% of C# programmers are good, while 80% of VB programmers are not good. This is not to say that everyone who programs in VB is less skilled than everyone who programs in C#. This is to say that (a) the VB syntax and semantics is designed to attract less skilled programmers and, in combination with other factors examined above, this has created a culture that is populated with less skilled programmers and (b) because VB syntax and semantics make it more difficult to avoid common programming errors and hence to program well.
  2. Hiring a good C# programmer is easier than hiring a good VB programmer. This is because of (1).
  3. Hiring the average C# programmer costs more than hiring the average VB programmer. This is because the average C# programmer is a better programmer than the average VB programmer, and this is because of (1).
  4. Hiring a good VB programmer costs the same as hiring a good C# programmer. There are many good VB progammers, and some of them are much better than some C# progammers. However this is the exception, not the rule.
  5. A good programmer accomplishes two to ten times what an average programmer accomplishes, and causes 90% less bugs and headaches.
  6. At the time of writing there are probably almost as many good VB programmers as there are C# programmers. This is because there are many more VB programmers than C# programmers. The 20% of VB programmers that are good is about same number as the 80% of C# programmers that are good.
  7. In the near future, there will be less good VB programmers than C# programmers. This is because many of the good VB programmers are switching to C#. This is partly because they like the language better, but mostly because they like the culture better. As the cultural separation becomes more evident and self-reinforcing, it will accelerate until there are very few good VB programmers left.
  8. VB programmers, on the average, know less about good object-oriented, distributed, loosely coupled application design and development than C# programmers, on average. This is because their language has not supported these notions, so their culture has grown without them. Although these notions are supported now in VB, they are more slowly being adopted than in the C# culture because of cultural inertia.

Propagation of the Culture in .NET

Under .NET, The VB language retains constructs that support the existing (old) VB culture. This was done, of course, in order to avoid alienating the culture’s members. Many of these constructs are still used by VB programmers, even though they should be avoided. Others are not harmful except inasmuch as they continue to provide cultural reinforcement of habits, including those that are harmful. Examples of key differences are listed below. These are simply examples and not an exhausive list.

  1. VB by default allows support for late binding. Although it can be turned off with “Option strict”, the culture is such that it’s usually left on. This leads to numerous difficult to catch errors. C# binding is always early.
  2. VB still supports the old “On error goto” construct. This leads to sloppy or non-existent error handling. C# supports only the superior try…catch error handling.
  3. VB supports optional parameters. Although VB developers often list this as an advantage, it is a disadvantage because the use of optional parameters weakens the contract between the caller and the method, allowing the developer to slacken his analysis and get away with it until bugs creep in. [note: C# param array construct is not the same as optional params]
  4. VB supports the legacy VB functions, with reference to Microsoft.VisualBasic.dll. Many of these functions are slow and they should all be avoided in favor of the .NET framework. However many VB programmers still use them. In new VB projects, this dangerous namespace is included by default.
  5. VB allows implementation of interfaces with methods of different names, making it confusing and difficult to find the implementation. C# does not.
  6. VB supports background compilation. While this speeds the development cycle for small projects, it slows down the IDE in large projects, contributing at least in part to the culture tending to gravitate toward small projects.
  7. C# namespaces are managed in way that makes programmers aware of namespaces and their importance. VB namespaces are managed in a way that hides them from the programmers by default. Careful attention to namespace management is a fundamental tenet of strong application design and its importance cannot be overestimated.

Conclusions

Conventional arguments between Visual Basic and C# focus on the functionality differences. Since these differences are minimal, it is argued that the choice of VB or C# should remain a matter of personal preference.

These arguments fail to take into account the deep cultural differences between the VB and C# camps.

The truth is that while there are some exceptional VB teams that write exceptional quality code, this is the exception, not the rule. Most VB teams have trouble writing high quality code, and this trait is ingrained deeply into their culture by environmental factors beyond their control, and continues to be propagated by the VB syntax and semantics in Microsoft .NET.

Therefore:

  • If an organization is content to write average quality software and has average VB developers, there may be no benefit in switching to C#.
  • If an organization has an exceptional VB team and wants to continue to improve, there is a real danger in continuing in VB. The danger is that the programmers will leave for opportunities in C#. Once even one top developer does this, the polarization of the group toward the old VB culture may accelerate, thus accelerating the attrition.
  • An organization with an exceptional VB team should switch to C#. The exceptional VB team will have no problem learning the new syntax, so there is no danger. The team will then reap the benefits of the C# syntax, semantics and culture for years to come.

—-
Nigel Shaw owns and operates Exia Corp, an Ottawa Canada-based company specializing in software application frameworks. Their flagship product is the Exia Web Solution Framework.

Editor's Note:
Another authoritative discussion on C# and VB cultures can be found over at www.theserverside.net. WindowsITPro has another article worth a gander.

 
Was this article useful?
   Share
 

23 Reader Comments

1 | Patrick — June 7, 2005 8:10 AM

Good article. Sums up my development experience over the last seven years exactly. A must read for VB programmers who are frustrated and don't know why.

2 | Dan — June 17, 2005 3:15 PM

Excelent!!!!

I wish I could wirte :-). You have sumed up most if not all of the arguments I have built up over the past few years on the subject.

Dan

3 | Shamblin — July 6, 2005 11:12 AM

I think this article is full of crap.

4 | Hamilton — July 6, 2005 11:27 AM

As stated in the following artiecle, “As developers, our job isn't to work at the lowest level but to create solutions and be productive.”

You need to provide your readers the like to this page: http://www.windowsitpro.com/Article/ArticleID/42613/42613.html

It is a better article on the differences.

5 | RObert — July 13, 2005 12:52 PM

Its all about the benjamins. Who ever wrote this article is narrow. It's not about the code, its about consistancy and ready to market. There are over 100,000 pre written routines in VB as to C#. I don't want another application with 300,000 ways to do something simple. C# is just as bad as Javascript. This Joe writes it this way that Joe writes it his way. When it would be nice to fire the guy and not have another developer re-write it because its not his way. VB.Net offers a better infrastructure. And if you have large projects. Ever heard of objects… I'd hope so.

6 | TonyP — July 20, 2005 12:50 PM

This is an extremely one-sided article. I have to correct you on a few things. First of all, it is VB.Net and not VB. Second, you stated that VB.Net supports “On error goto” construct. Although this is true, it also supports the “try..catch..finally” construct that is implied C# holds a monopoly on in your article.

Don't get me wrong, I love C#. I do feel it has a cleaner syntax. But they are some great advantages in VB.Net. First, I don't have to waste time re-inventing functions that are already predefined in VB.Net. If you are using Visual Studio.Net, the intellisense is smarter in VB.Net. Raising events are easier in VB.Net than in C#. There is no equivalent to the “With” keyword in C#. I can review all available exposed events, methods, etc of a object in the Declarations list in Visual Studio.Net using VB.Net.

This dicussion is like trying to drive a car with a spare tire as a steering wheel. When you work for company that wants products on time and under budget, VB.Net clearly wins out. If you are lucky enough to get with a company that actually cares about quality of the product, rather than quantity, then C# or VB.Net is perfect.

7 | Andr� Luiz Sobreiro — June 21, 2006 5:49 PM

Good. I am a VB.NET programmer I and agree with all of you. I just want to comment about one thing. I don't know if it is happening in other parts of the world, I can tell about my city and my country, Rio de Janeiro - Brazil.

Here the companies already prefer to get a C# professional rather than a VB.NET one. And the cause is exactly what Nigel Shaw speaks of in this article. It's true we can more easily find better programmers using C#, becouse VB is easier to learn.

I am already learning C# because of this. However, I really think VB.NET is better. If you are a good programmer, you can make applications faster and of equal quality than what a good C# programmer would do. So, until we start to make higher quality applications in VB.NET, I don't see a future for this language.

8 | DotNEt42 — December 6, 2006 10:45 PM

The author nailed it. Right to the point. He makes no claims and backs up everything with facts and actual events/data.

It is a preference; a preference for culture.

Thank you.

9 | James Foxall — December 8, 2006 2:53 PM

This article is written with an obviously biased, even elitist, C# perspective. I'm VP and part owner of a multi-million dollar software company currently in the throws of migrating our VB6 application (that's right, a LARGE commercial product done in VB6) to VS2005. In addition, I've written over a dozen books on VB and C# for publishers such as Sams and Microsoft Press; I have a lot of experience here.

In the end, a tool is a tool. I've personally written applications in VB6 that simply SQUASH competing products done in C++ because I and my team knew what we were doing, invested in training and 3rd party components, implemented solid processes, and cared about what we doing. Lots of would-be carpenters create utter crap using the same tools that others employ to build beautiful furniture and homes.

The gist of this article is that people will migrate from VB.NET to C# because of the culture. I think this is false. VB is every bit as capable as C#. True, many programmers that lack formal training or demanding real-world experience will continue to use some of the deprecated functionality of VB (ala On Error Resume Next). However, do you believe these people will move to C#? Of course not. If the advanced features of VB.NET confuse them, C# must scare the hell out of them. I have the luxury (or curse, depending on how you look at it) to go with whatever language I choose, and I chose VB.NET. I hate semi-colons and curly braces. Case-sensitivity? PLEASE. I don't consider these features modern or elegant in the least. That said, I respect the language and those that choose to use it. In the end, they're both “flavors” of the .NET Framework. Let's talk about the end result shall we? I don't get freaked out amongst C# programmers because “they use a a real language”, as some would put it. I'm happy to compare the end results and discuss user satisfaction - isn't that what matters?

Articles like this don't serve the development community, they just confuse people and create more animosity among brethren.

Pick a tool, get good at, care about what you do, and write great software.

James

10 | Will Asrari — February 20, 2007 4:46 PM

I enjoyed very much.

Some more beefs with Visual Basic .NET:

1. No collapsable regions within methods = large amount of wasted real estate.
2. lack of using { } statements
3. Case-insensitivity makes it hard to create a truly standardized application.

Think variable studentId with method StudentId. Visual Basic .NET can't tell the difference.

Dim studentId as integer = 5

Response.Write(studentID)
Response.Write(StUdeNtId)
Response.Write(studENTid)

All the same output.

11 | Schneider — July 25, 2007 10:27 AM

I agree with James Foxall, this article is BS.

I use both and still prefer VB.NET. The IDE works better for VB. The runtime compiler since before 2005, actual works worse now in 2005 because of C#.

Eric Schneider

12 | Anthony — October 22, 2007 2:08 AM

I think James Foxall put it very well. This article was written by an insecure fellow trying to boost his self-esteem by convincing himself he is superior because he does C#. Please.
Besides, he is wrong. After some teething pains, Visual Basic usage is again experiencing strong growth, stronger than C#: http://www.tiobe.com/tpci.htm
So sorry bud. The rest of the world doesn't seem to agree with you, and the market share of C# is still at a miserable 3.74%, despite having been out for more than 5 years now.

13 | Marcus — November 20, 2007 10:47 AM

I come back to this article again & again, & the more I have to suffer writing VB, as I convert it to C#, the more I agree with it.

So I find it amusing that those that defend VB do so in such a way that further justifies the arguments of this article.

For example the last two comments that Visual Studio intellisense works better with VB & the number of people using VB is going up, which both suggest that VB is easier to use & learn for the “mass market” which the author mentions in the first line of his 'The Culture of Visual Basic' paragraph - the culture that is satisfied with writing average code: obvious really.

14 | Robin — November 25, 2007 7:59 AM

“Dim studentId as integer = 5

Response.Write(studentID)
Response.Write(StUdeNtId)
Response.Write(studENTid)”

Good lord. If you are trying to obfuscate your code, having methods, functions, properties and variables with names that only differ by case is certainly the way to do it. Would a good programmer even need this feature? I doubt it. At least I hope not to have to maintain code like that.

15 | Mike — January 30, 2008 5:45 PM

Using the site shown by Anthony, http://www.tiobe.com/tpci.htm, I read the details of the report. The author claims C# was the big winner of 2007 and is predicting that Java and C# will become the most popular languages.

As for the intellisense, I was completed frustrated with it when working in VB.NET. I was so glad to return to C# and see the intellisense shine again. I am shocked to read that someone thinks intellisense is so much better in VB when my experience is just the opposite. In general, I prefer case-insensitive but I understand C# uses it and I am able to make intellisense easily go to the correct place by typing UpperCase for Classes and lower case for variables.

My background was programming in Delphi 1-7. I created fast, reliable and robust applications that ran circles around most of the VB apps other developers were creating. Not until VB6 did I start to see mature apps.

The always compiling VB compiler would get out of sync far too often. I could run the code but the IDE did not think the code was valid. I had to exit the IDE and then restart to clear it. On big solutions, the VB compiler irritated me when I was trying to do copy and paste and the code was not yet correct.

I like the semi-colon in C,C#,Java,Delphi,etc. for the same reason I use a period at the end of sentence in the English language. ; means the end of statement regardless of number of lines which makes readability formatting easier.

Namespace is a great organizing methodology for large solutions. It is very straight forward and visual with the folders and sub folders in C#. In VB.Net, took extra unnecessary work.

This article is a great resource for me because it clearly explains the VB.Net and C# as a culture problem much more than a language problem.

With no baggage, would an up and coming developer learn VB.Net as their first language? I learned Pascal as my first language using a book written by Wirth. At the time, other people with Fortran experience were struggling to understand the “new” idea of records and pointers.

My knowledge of Pascal as my first language has always served me well. So to answer my question above, I think a new developer is better served by learning Java or C# as a first language. Knowing either one allows a developer to easily learn the other and gain a good knowledge of current programming practices.

16 | wayne — February 5, 2008 12:11 PM

VBA is great.


17 | exBorlandian — June 30, 2008 10:37 AM

The classic C/C++/C# talibanians full of fear…

18 | nac — August 20, 2008 9:31 AM

Heck. Right tool for the right job. I love it that folk think that being able to use { and } in code in C# somehow makes them anything like the level of a C developer! Makes me laugh. So much hand holding by M$. Java with a different coat. Yeah, you'll bet all the gullible folks saying it's wonderful. As if. And there is no business process that can not be modeled on M$ software that was around in the year 2000. VB6/SQL Server/ADO, VBScript, ASP; Business, sorted. They are just being forced right now to “upgrade” to .Net of any flavour and all you sheep follow suit. Eeek. Why were you not championing Java? You could use { and } in that language.

Remember…right tool…right job..

19 | Jobert Enamno — August 21, 2008 1:14 AM

Hi I'd like to post this. It's from Wikipedia http://en.wikipedia.org/wiki/Comparison_of_C_sharp_and_Visual_Basic_.NET

Comparison of C Sharp and Visual Basic .NET
From Wikipedia, the free encyclopedia
(Redirected from Comparison of C sharp and Visual Basic .NET)
Jump to: navigation, search
The correct title of this article is Comparison of C# and Visual Basic .NET. The substitution or omission of a # sign is because of technical restrictions.
This article is part of the
Programming Language Comparison
series.
General Comparison
Basic Syntax
Basic Instructions
Arrays
Associative arrays
String Operations
String Functions
List comprehension
Object-oriented programming
Database access
Evaluation strategy
List of “hello world” programs
Comparison of ALGOL 68 and C++
Compatibility of C and C++
Comparison of Pascal and Borland Delphi
Comparison of Pascal and C
Comparison of Object Pascal and C++
Comparison of Java and C++
Comparison of Java and C#
Comparison of C# and Visual Basic .NET
Comparison of ABAP and Java
This box: view • talk • edit
This article or section is written like a personal reflection or essay and may require cleanup.
Please help improve it by rewriting it in an encyclopedic style. (January 2008)

The original .NET Framework distributions from Microsoft included several language-to-IL compilers, including the two primary languages: C# and Visual Basic. There is heated debate among the greater .NET community about which language is better in general, or for specific purposes. Below is a comparison of the two languages.
Contents
[hide]

* 1 Compatibility
* 2 No second class languages
* 3 Development Environment
o 3.1 Exclusive C# Development Environment Features
o 3.2 Exclusive VB.Net Development Environment Features
* 4 Language features
o 4.1 Features common to all .Net languages
o 4.2 Features of Visual Basic .NET not found in C#
o 4.3 Features of C# not found in Visual Basic .NET
o 4.4 Criticisms of Visual Basic .NET not applicable to C#
o 4.5 Criticisms of C# not applicable to Visual Basic .NET
* 5 Syntax comparisons
o 5.1 Keywords
o 5.2 Comments
o 5.3 if-then-else
o 5.4 For loop
o 5.5 Equality and other comparison operators
* 6 Performance
* 7 Adoption and community support
* 8 Other languages
o 8.1 C++/CLI (formerly Managed C++)
o 8.2 J#
o 8.3 Minor languages
o 8.4 CIL
* 9 References
* 10 External links

[edit] Compatibility

It should be noted that all .NET programming languages share the same runtime engine, and when compiled produce binaries that are seamlessly compatible with other .NET programming languages, including cross language inheritance, exception handling, and debugging.

[edit] No second class languages

One of the main goals of .NET has been its multi language support, and the concept of “no second class languages”. That is, all of the various Microsoft languages should have the same level of access to all OS features, and all expose the same level of power and usability.

It should be noted that Visual Basic and Visual Basic .NET are completely different languages and are not backwards-compatible. Visual Basic .NET shares only syntax similarities with Visual Basic. The Abstract syntax tree for Visual Basic .NET and C# are closely matched and the IL produced by the compiler is virtually identical. It is possible to compile C# code into IL and use a decompiler to convert the compiled IL back into Visual Basic .NET source code - such is the similarity between the languages.

C# shares syntax similarities with Java. Both C# and Visual Basic .NET share structural similarities with other modern high level languages such as Java and C++. However the differences between Java and .NET are numerable, as can be seen in Comparison of Java and C Sharp.

[edit] Development Environment

Visual Studio provides minor differences in the development environment for C# and VB.Net. With the release of subsequent versions of Visual Studio the differences between the languages have reduced. For instance early versions of Visual Studio had poor support for intellisense in C# compared to Visual Basic .NET.

[edit] Exclusive C# Development Environment Features

* Exceptions that are documented in XML comments are displayed by Intellisense

[edit] Exclusive VB.Net Development Environment Features

* Default namespace is hidden (can be disabled)
* Certain project files are hidden (user can show them)
* A namespace My lists a lot of functions shortcuts (using the registry, application-specific functions, etc..)
* A delegate can be made using AddressOf myObject.theFunction

[edit] Language features

The bulk of the differences between C# and VB.NET from a technical perspective are syntactic sugar. That is, most of the features are in both languages, but some things are easier to do in one language than another. Many of the differences between the two languages are actually centered around the IDE.

[edit] Features common to all .Net languages

These features are common to both C# and VB.Net as well as all languages running the .Net platform.

* Garbage collection

[edit] Features of Visual Basic .NET not found in C#

* Auto-wireup of events, ie VB.NET supports the Handles construct
* Support for optional variables. Visual Basic .NET is better suited for DLL interoperability which is a particular advantage for automating Microsoft Office
* The ability to skip lines of code using GOTO
* Marshalling an object for multiple actions using an unqualified dot reference. This is done using the With…End With structure.

[edit] Features of C# not found in Visual Basic .NET

* Supports unsafe code blocks for improved performance at the expense of not being verifiable as “safe” by the runtime
* Anonymous methods
* Partial Interfaces
* Iterators and the yield keyword
* Multi-line comments (note that the Visual Studio IDE supports multi-line commenting for Visual Basic .NET)
* Static classes (Classes which cannot contain any non-static members, although VB's Modules are essentially sealed static classes with additional semantics)
* Can use checked and unchecked contexts for fine-grained control of overflow/underflow checking

[edit] Criticisms of Visual Basic .NET not applicable to C#

* Optional strong typing
* Conversion of Boolean value True to Integer may yield -1 or 1 depending on the conversion used
* Assigning and comparing variables uses the same token, =. Whereas C# has separate tokens, == for comparison and = to assign a value.

[edit] Criticisms of C# not applicable to Visual Basic .NET

* By default, numeric operations are not checked. This results in slightly faster code, at the risk that numeric overflows will not be detected. However, the programmer can place arithmetic operations into a checked context to activate overflow checking.
* Lack of optional parameters in functions, a feature present in both Visual Basic.NET and C++.
* In Visual Basic .NET property methods may take variables
* Visual Basic .NET has better interoperability with older versions of Microsoft Office
* C# is case sensitive so it is possible to have two variables with the same name, eg variable1 can be different to Variable1. Visual Studio will correct the case of variables as they are typed in VB.NET

[edit] Syntax comparisons

Visual Basic .NET terminates a block of code with End BlockName or Next for a for loop which is more familiar for programmers with experience using T-SQL. In C#, the braces, {}, are use to delimit blocks, which is more familiar to programmers with experience in other modern languages such as C++ and Java.

In C#, when a block is not defined for a statement, the next statement will be treated as the block.

Often C# developers will add comments at the end of scope to more easily mark where the scope started. For instance some C# developers use } // End If to mark the end of a nested if statement. This can negate the argument that C# is a cleaner language to read.

[edit] Keywords

Keywords are very different between the two languages.

A comparison: (VB.NET vs C#)

* Me vs this - a self-reference to the current object instance
* MyBase vs base - for referring to the base class from which the current class is derived
* Shared vs static - for declaring methods that do not require an explicit instance of an object
* NotInheritable vs sealed - for declaring classes that may not be inherited
* NotOverridable vs sealed - for declaring methods that may not be overridden by derived classes
* MustInherit vs abstract - prevents a class from being directly instantiated, and forces consumers to create objects references to only derived classes
* MustOverride vs abstract - for forcing derived classes to override this method
* Overridable vs virtual - declares a method as being able to be overridden in derived classes

Notice above how some C# keywords such as sealed are used to represent different things when applied to method or class definitions. VB.NET, on the other hand, uses different keywords for different context

[edit] Comments
C# Visual Basic .NET
// Single Line Comment ' Single Line Comment
/* Multi-line

comment */
not available
/// XML Comments ''' XML Comments

Note that for Visual Basic .NET, multiple lines of code can be commented or uncommented using the Visual Studio IDE. As such having no support for Multi-line comments in the language is a disadvantage only when the IDE is not used.

[edit] if-then-else
C# Visual Basic .NET

if (condition)
{
// condition is true
}

If condition Then
' condition is true
End If

if (condition)
{
// condition is true
}
else
{
// condition is false
}

If condition Then
' condition is true
Else
' condition is false
End If

if (condition)
{
// condition is true
}
else if (othercondition)
{
// condition is false and othercondition is true
}

If condition Then
' condition is true
ElseIf othercondition Then
' condition is false and othercondition is true
End If

[edit] For loop
C# Visual Basic .NET

for (int i = 0; i {
// loop from zero up to one less than number
}

For i As Integer = 0 To number - 1
' loop from zero up to one less than number
Next

for (int i = number; i >= 0; i—)
{
// loops from number down to zero
}

For i As Integer = number To 0 Step -1
' loops from number down to zero
Next

[edit] Equality and other comparison operators
C# Visual Basic .NET

if (a == b)
{
// equal
}

If a = b Then
' equal
End If

if (a != b)
{
// not equal
}

If a > b Then
' not equal
End If

if ((a == b) & (c == d) | (e == f))
{
// multiple comparisons
}

If a = b And c = d Or e = f Then
' multiple comparisons
End If

if ((a == b) && (c == d) || (e == f))
{
// short-circuiting comparisons
}

If a = b AndAlso c = d OrElse (e = f) Then
' short-circuiting comparisons
End If

[edit] Performance

[edit] Adoption and community support

Both C# and VB.Net have high adoption rates, and very active developer communities and Microsoft fully supports both communities. However, C# does have an advantage in terms of the level of community activity on the Internet. Also, there are more books available for C# than VB.Net, and publishers report that C# books significantly outsell the VB.Net counterparts.

Examples of the increased community and industry adoption include:

* According to a survey conducted by Visual Studio Magazine (which self-identifies as a VB centric publication) “41 percent said they used C#, 34 percent programmed in VB.NET, while 25 percent responded with 'other.'”[1]
* Stephen Wiley, marketing product manager at Apress has reported “C# titles outsell VB.NET title books handily, by somewhere between a 2-1 and 3-1 margin.”[1]
* blogs.msdn.com, the blogging site for Microsoft employees, has 27,500 posts that discuss C#, while only 8,880 mention VB.Net (November 15, 2007)
* Google Groups, a Usenet search engine returns 36,900 hits for “VB .Net”, and 65,700 for C#
* Amazon returns 9,923 hits for C#, and 2,149 hits for “Visual Basic .Net” (November 15, 2007).

As counter examples

* VB.NET is the most popular download of all the Express downloads. C++ is the most popular download among students. 80 percent of all downloads for the Express line were by non-professionals.[

20 | SJB — August 21, 2008 11:56 AM

I tend to agree with the authors comments and feel that many of the responses totally miss the point. Nigel clearly states that the languages are similar in terms of capability but goes to some length to point out that this is perhaps a small consideration commercially. Responses that then say 'hey, VB is as good as C#' have either not read the article or take offense at their preferred syntax..

21 | Jobert Enamno — August 21, 2008 10:01 PM

Hi to the author of this forum…I'd like to share my experience as .Net Developer. I am a Filipino Software Engineer and a graduate from famous IT school which offers and which is always the first to offer latest technology components. In that school it only offers C#.NET as our first step to learn the .NET platform. In our curriculum we don't learn Visual Basic because if you deploy VB.NET then you are left behind from IT trends today which I prove that more and more company are using C#.NET effectively from year 2005 up to the present.

Have you ever heard before guys that Microsoft had planned that it's later versions of Windows OS would not support VB or VB.NET? Well that planned was not pushed through since many companies which were very dependent to VB had protested the plan…But now those companies have lately realized that C# is very good in deploying world-class softwares. But this notion doesn't imply that C# is better than VB but C# programmers have unbeatable skills and creativity. This means that as C# programmers the thirst for extraordinary output is common.

Well back to Microsoft's plan to not support VB in later versions of Windows OS was obviously the plan to monopolize C#.NET

22 | james — September 9, 2009 8:00 AM

Its' very simple:

C# programmers are much better than VB programmers, and it's only because they agree with this article. its' a way of thinking, nothing else. if you support VB, it means you will never be good programmer as C#.
That's it!


C# programmers (that moved from VB6 - just on time!)

23 | Lewis Carrol — April 22, 2010 5:26 AM

Five years later, we see an increase in the amount of VB programmers vs. C# programmers. The prophecy fails.

Leave a Response

  Remember me?

Related Featured Articles Articles

 

Job Openings  View all | Post a job | feed RSS

Featured Events  View all | Add event | feed RSS

STAY UP TO DATE
Subscribe to our RSS feed...
SUBSCRIBE TO OUR RSS FEED

Find us on Facebook

Just Commented On




Resources