Contents
This article explains the benefits of a Microsoft .NET application development organization coding in C# versus coding in VB.
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 avoids 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 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 higher salaries for software developers.
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#.
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.
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 who 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.
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?
- 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:
- 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 because VB syntax and semantics make it more difficult to avoid common programming errors and hence to program well.
- Hiring a good C# programmer is easier than hiring a good VB programmer. This is because of (1).
- 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).
- Hiring a good VB programmer costs the same as hiring a good C# programmer. There are many good VB programmers, and some of them are much better than some C# programmers. However this is the exception, not the rule.
- A good programmer accomplishes two to ten times what an average programmer accomplishes, and causes 90% less bugs and headaches.
- 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 who are good is about same number as the 80% of C# programmers who are good.
- 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.
- 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.
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 in as much 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 exhaustive list:
- 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 difficulty to catch errors. C# binding is always early.
- 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.
- 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]
- 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.
- VB allows implementation of interfaces with methods of different names, making it confusing and difficult to find the implementation. C# does not.
- 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.
- 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.
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 towards 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.
- April 19th, 2005: Minor grammar fixed and removed reference to an internal project in our shop that is meaningless to the broader audience. Clarified several sections that might be taken to be slights against VB developers to indicate that it's not VB developers that are the problem. It's the upbringing of the language in the context of the environment... i.e. its culture. Removed section of additional benefits of C# since it's orthogonal to the point.
- April 19th, 2005. I apologize to anyone who is or was offended by this article. Please read it carefully. If after reading it carefully you think that it slights good VB developers, please let me know exactly where/how and I'll fix up the article. My intention is not to slight any good developer, or even a bad one who's trying. Criticizing the factors that lead to a culture that makes it difficult for developers to be good... now that I have no problem doing.
- April 22nd, 2005: I'm getting so many comments about how I say that C# is a better language than VB (even though I never say this) that I edited paragraph 2 to reflect that they are functionally equivalent.
- May 10th, 2005: DotNetRocks' Carl Franklin read my article and commented on it in a recent issue of DotNetRocks, which you can download here: .NET Rocks! - Kimberly Tripp on SQL Server 2005. Being pro-VB, Carl was pretty negative on the article. I would have no problem with that except that I thought that he also missed the point and tried to ridicule the article by taking excerpts out of context. But you be the judge. I've transcribed his comments word for word in a comment slot below, so you can read them, comment, and, of course, rate his comments.
- May 20th, 2005: Some posters have asked me to indicate that this article, and in particular the 80/20 comment, are based on my opinion and not on empirical or statistical data. They are my opinion.
|
|
 |
 | My vote of 2
crobor | 18:35 2 Aug '09 |
|
|
Interesting historical part, but very arrogant attitude and lack of objectivity. Unnecessary contribution to further polarising of C# vs VB.NET, where there is no need to, since neither of them is superior.
modified on Monday, August 3, 2009 7:05 PM
|
|
|
|
|
| A list of (relevant) facts for a switch from VB to C#
crobor | 19:07 29 Jul '09 |
|
|
Dear colleagues,
Thank you everyone who tried to bring some light into the gloomy discussion of VB.NET vs C#.NET for your constructive comments. Thank you, Nigel, for the informative part of your article.
I have worked with VB.NET so far, since my previous employer as well as my current clients work with VB.NET. I am now starting an own development, and have asked myself if I should stay with VB, or do it in C#. I have got a broad background in programming, which goes back to Occam and Assembler, and I even worked in PHP and JavaScript, so curly brackets wouldn’t be the problem.
I tried to find out the pros and cons of VB and C#. Unfortunately, the bulk of the discussion here is like the tantrum of little boys, who try to defend either their VB or C# territory. This ridicules the entire .NET community, I have to say.
We, as programmers, should stay to facts and find solutions to problems, not fight unnecessary wars. Staying to facts also applies to you, Nigel. Your article could have been brilliant.
Anyway, I am not religious, and I want to find an independent comparison of important differences between VB and C#, to help my decision of which one to choose right now in the very next future. I try to put the facts of your posts, dear fellow programmers, in a simple list for comparison purposes, and mark them as either pro-VB, pro-C#, or as “irrelevant to the decision”. This will certainly be my own opinion, but it will not be guided by “VB is the only way” or “C# is the only way”. I invite anyone to add their perception to the list (without the C# or VB blinders, please).
---begin list
- Syntax differences, e.g., C# uses curly brackets … irrelevant
- ”With” clause in VB … pro-VB (increases efficiency)
- case-sensitivity … pro-VB (I love the IDE adjusting the case automatically)
- availability of code examples online … pro-C#
- general acceptance of C# as more professional, even if not judged rationally … pro-C#
- event handling differences … irrelevant
- Option Strict On/Off in VB … irrelevant (just switch it on)
- learning curve, losing time when switching to C# from VB … pro-VB
- opening up C# clients when switching to C# from VB … pro-C#
- maximising efficiency and creating own code library in only one place by staying with VB … pro-VB
- VB’s On Error Goto … irrelevant (just don’t use it, I always use Try/Catch)
- VB’s optional parameters … irrelevant (just don’t use them, use overloads instead)
- VB allows/supports blah blah … irrelevant (VB doesn’t FORCE you to practice bad habits, even if it allows it … so just don’t do it)
- OO concepts … irrelevant (should be implemented regardless of the language)
- IDE … pro-VB (personal preference)
---end list
I better stop here. Just tried to catch some facts which I consider important for my decision-making, plus listed things which have been lifted up into a big hype in the article or the posts, but which I really consider irrelevant.
I have not decided yet which way I will go. I would love to stay with VB and maximise efficiency there, but the argument of becoming available to C# projects is the major one making me think of switching. On the other hand, after developing in many different environments/languages I made the choice at one stage to focus on .NET. I will certainly not give up VB.NET, C# would merely be another branch of .NET. Hmm, am I losing focus again?
Sorry, this has become a bit longer than intended. I would love to get comments about REAL issues concerning the language choice (especially for a switch from VB to C#).
Thanks,
Rudi
|
|
|
|
|
| My vote of 1
_Khallaf | 16:47 9 Jul '09 |
|
|
CV-Centric, C-Racist, tribute to the C-Minded employer. Personal phobia.
|
|
|
|
|
| You C# guys have it all wrong
Alexander Higgins | 18:44 21 May '09 |
|
|
Wow vb is the quick and dirty, red-headed step child of the programming world? Not at all. Its all about effeciency . If your all about formatities and semantics, then why aren't you programming in C++? Because it an ineffecient language to develop in, correct? For example, you can develop a large project in C# 2 to 4 times faster in than you can in C++. You can also develop that same project 2 to 4 times faster in VB than you can in C#.
I can program in all 3, I know from personal experience, and that's why I prefer VB over the others.
- Casting: CType is uncomfortable, and also option strict is off by default, so almost all the VB code has random conversion between types.
What is so uncomfortable about Ctype? Its absolutely natural. Create a ctype operator you define a function that that takes Type1 as an argument and casts it to Type2
operator ctype(byval I as numericstring) as string. No differert then calling System.Convert.ToString(value as object). Random conversion. Ok.
Dim D as double=1.59
Dim I as integer= D
Loss of precision, yes. But I full understand that converting a double to an integer will make me lose precision, further I am instructing the compileter to convert the double to an integer by assigning the double value to an integer. Why should I have to instruct the compiler to do the same thing twice??
That annoys me about C#. For example, if I don't want to add an import statement, or using in C# and I need to use a generic list...
System.Collections.Generic.List<string> myList = new System.Collections.Generic.List<string>();
Dim Mylist as new System.Collections.Generic.List(Of String)
Annoying, that is a lot of typing and repeating that hundreds of times during the life cycle of a project wastes a lot of time, back to my original point that VB is faster to develop in.
Option strict Off by default, yes this does allow for stupid mistakes. Misuse of interfaces? Come on. Even the comment that C# makes the use of interfaces clearer becuase the method names must match exactly. NO!!
You can't look at C# and tell well a class method is implenting and interface or not. In fact, you can't even tell if the class itself is implementing an interface or inheriting another class. In VB its clear because you use the keyword Implements or inherits. Methods that implement an interfaces are declared "Implements IHttpModule.Init." or such.
I can go even further... I converted the entire BlogEngine.Net project to VB. What a pain. What is the point of having an interface the declares a property Readonly only to have the class that implements the method make the property read/write. I don't remember how many interfaces I had to recode becuase of that. That's a misuse of an interface.
Variable declaration. Matter of personal preference, same goes with you example about the for each loop.
I'll give you the boxing and unboxing noting that IMO that is a design flaw in .NET itself, an unfortunate side effect of having to deal with garbage collection of managed objects. Yes, design flaw. In C++ you can declare a structure (Ie look at just about any networking protocol.. DNS,DHCP,ETC) and can copy the bytes in memory from structa directly to struct b. Example, You Have FFFFFFF in memory, while that could represent Uint32 Max value or -1 as integer, it could be 4 different bytes or even flags in a bit field. With proper design casting from one object type to another should not incur boxing/unboxing overhead. The problem lies with how memory is allocated on the manage heap, with Interior Pointers (IntPtrs) pointing to possible several different memory locations (which is why you can't perform pointer arithmetic on managed objects). Point being is that issue could and should be fixed.
Encapsulation is a benifit of OOP. You shouldn't be concerned with the interals of how your TV works to get a great picture.. its should just work, period.
Hiding delegates. First of all, What is the need to actually code the delegate? Again wasting time typing something that's not needed. In my option C# is way more confusing in how it handles events. While In both VB and CSharp you can progammatically add an eventhandler (addhandler or mymethod +=new eventhandler) but that makes the code so much harder to follow. You don't know what methods are attached to what events. In VB, you can declare a method and mark it with handles
sub buttonclick(sender as object, e as eventargs) handles button1.click
Its clear that method handles the button1.click event. Also, notice everthing lower case. So much faster to type, again effeciency. Imagine searching google and for codeproject and not getting any results because the results where case sensitive. Did you mean CodeProject?
Evolution will demand that computers interface with with humans in a natural manner and not vice versa. When I typed codeproject, I mean CodeProject, CodePROJECT and even CodPeroject. yeah, typo. But even google gets that.
Dim b(2 - 1) As Integer() <-- invalid, you can't declare an array with a bounds specifier
Dim d(1) as integer
int[] d = new int[2];
Again less typing in vb even with the longer integer keyword.
-->Also, .Net arrays are zero-based, but VB try to hide this declaring one element more at the end (so 0 is commonly -->not used). This creates trubles with buffers.
This causes me "trubles". Vb arrays are zero based, what are you talking about? Adding one more elment? heh?
Dim D(1) as integer gives me an array that is 1 element long. To access that element d(0)=MyIntValue
And who cares if your using [] or (). It makes it easier to use one for everything. Do you really care if you're accessing a function, an array or a property? In the end what matters is you are retrieving a value. another annoyance of C#. Properties, variables accessed using the variable declaration, by a function needs to have () or you get the method group error. Annoying. Extra typing. Not needed. VB is smart enough to know ...
Dim b as new stringbuilder
b.append("hello world")
dim s as string = "VB.net says " & b.tostring
StringBuilder b = new StringBuilder();
b.append("Hello World");
string s = "C# says " + b.tostring();
Why do I need () to call the new method? Uneeded. Again for b.tostring... uneeded. And how annoying + for the string operator. String1 = String2 and string3.
Seperate equality and assignment operators == and =, more unneeded typing. You can tell from the context of the code just like the context of a sentence if = is for equality or assignment.
Returning nothing or null. You can look at the glass half empty of half full. To me that's an advantage of Vb, an extra line of code that I don't have to write.
Function GetUserName(Email as string)
Dim UserName
Dim dr as sqldatareader= sqlhelper("CheckUserName", new string() {"@Email"}, new String(){Email})
while dr.read
username=dr(0)
end while
dr.close
return username
end function
What ever method calls Calls GetUserName needs to check whether the UserName variable is null or empty regardless so why the need to return null? Declaring GetUserName as String or even UserName as string could throw an exception (cannot cast type dbnull to type string). Exception catching sucks.. period. It slows application performance. Its better to check that UserName is nothing or UserName.GetType is gettype(dbnull). Think about it, whenever you pull anything from a db you need to perform a sanity check. For that matter request.querystring, session, the list goes on and on...
Which leads to me to on error resume next. What a gift. It can lead to bad programming but I can think of several example where I would have literally begged for it in C#. Lets say you need to import an new clients site into your homegrown CMS. You make an html parser to help automate. The problem is the existing site is not templated so some pages are missing keyword meta tags, some descriptions, some titles. Some have body content inside of a div with a class of content, some inside of the fourth td in the third tr in the fifth table of the nth div tag, etc...
What a nightmare having to try catch all of that.. simpler solution... on error resume next. Take the following code. As I was writing it, it orginally used a try catch and it became spaghetti code. The I refactored calling methods to get the respective elements. I guess you could say I used a try statement caught an unreadable code exception and finally resorted to ON ERROR RESUME NEXT
Example
Dim Obj As WindowsLoginToken = impersonate.Main(UserName, Password)
Dim Uri As New Uri(Me.TxtUrl.Text)
Dim Ie = CreateObject("internetExplorer.Application")
Ie.Navigate(Uri.ToString)
While Ie.Busy
System.Threading.Thread.Sleep(100)
End While
Pagebody.Text = ""
pagetitle.Text = ""
pagekeywords.Text = ""
pagedescription.Text = ""
Me.pagepubdate.Text = ""
On Error Resume Next
If Request.QueryString("cmsID") = 0 Then
Me.Pagebody.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).innerhtml
Me.pagetitle.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("b")(0).innerhtml
Me.pagedescription.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(1).innertext
Me.pagekeywords.Text = Ie.document.GetElementsByTagName("meta")(2).getattribute("content")
Else
Me.Pagebody.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).innerhtml
Me.pagetitle.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(1).innertext
Me.pagedescription.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(2).innertext
Me.pagekeywords.Text = Ie.document.GetElementsByTagName("meta")(2).getattribute("content")
End If
If pagetitle.Text = "" Then
Me.pagetitle.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("b")(0).innertext
End If
If pagetitle.Text = "" Then
Me.pagetitle.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(0).innertext
End If
If pagetitle.Text = "" Then
Me.pagetitle.Text = Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(1).innertext
End If
If Me.pagedescription.Text = "" Then
Me.pagedescription.Text = pagetitle.Text
End If
Me.pagepubdate.Text = Date.Parse(Ie.document.body.GetElementsByTagName("Table")(2).getElementsByTagName("TD")(4).getElementsbyTagName("p")(0).innertext).ToShortDateString
If Me.pagepubdate.Text = "" Then
Me.pagepubdate.Text = Ie.document.fileModifiedDate
End If
Ie.quit()
Ie = Nothing
impersonate.undoimpersonate(Obj)
There are several more situation I needed to do that same. One feed provider was providing a Tab deliminated Text file that routinely had some columns (tabs) missing. Another time was importing an XML document generated in PHP which had almost no logical structure whatsoever. Ever write your implementation of a network protocol based off of nothing but raw ethernet data off the wire (winpcap)? You can ignore / drop malformed packets or you can try to parse them the best you can. Not everyone follows standards.
Ever write an HTTP Prox/Fuzzer? (similar to webscarab)? The biggest problem using raw sockets is knowing when the server and/or client is finished sending data... You can set a timeout and catch the exception, but if your using async call backs you can drop a connection. Ran into writing my own SSL Handshake implementation... after hours of frustation, well ON ERROR RESUME NEXT and Voila!!
Look at the winAPIs they don't throw exceptions, a pointer is passed and its up to you to check wether or not the point has an error code and you can call GetLastError or formaterrormsg to get the error details. To think about the ASP.Net pipeline works the same way. it executes reqardless and set the raises the application_error event. The reason we have try catch is it makes it easier for vendors to notify you an error occurred. Yes its more structured so you can trap errors when they occur, but you can't look down on VB for employing the same methods the underlying operating system uses. The functionality is built directly into the kernel, and is integrated into windows script host which runs javascript and vbscript.
We could on and on, back and forth forever. What's really at issue here is ego. I remember I used to work construction and mexicans starting working my trade. The where a dozen of them on a single crew where my crew had 3 to four workers. But their whole crew earned was the same as our crew, but 12 of them could do 4 times the work of our crew. Similar situation here.
You can hire 2, maybe 3 programmers for the price of a single C# programmer. I started my position at a little over 30k a year. What a bargain. I would say I can at least hold my own with the best c# programmers out there. Now is an employer going to hire 2 of me or 1 of you?
That's the issue here, not the culture, not the language itself, but survival of the fittest. You need to look at your history. Assembly programmers where making the same complaints when C came along. C programmers made the same complaints when C++ came along. C++ made the same about C#.
The only difference here is that C# programmers have managed to put a black cloud over VB. But in any case, programming will move to higher and higher level languages. The more natural and humanlike the interface the more widely adopted the language will be. Progamming languages do not last for ever.
|
|
|
|
|
| My vote of 1
Nic Rowan | 21:32 12 Mar '09 |
|
|
What rubish.
You say "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."
Is the VB team suddenly going to see the light and just obtain this knowledge and suddenly become "better" just by learning a new syntax?
I've been developing for years in many languages including C , C# and VB.Net. People should write what they're comfortable with. Learning C# is not suddenly going to make them good developers.
I've seen just as much shockingly bad code written in C# as I have VB.NET.
This whole language debate is rediculous.
|
|
|
|
|
|
|
I think what the author try to say is VB team will have more chances to become 'better' when learning C#, because C# culture & community encourage best practice & oo design, whereas VB culture emphasize on rapid development. One example is good practices like test-driven & domain-driven was introduced among C# community years earlier than VB.
Of course any developer can ignore them & write bad code regardless C# or VB.NET.
|
|
|
|
|
| Statistics are facts, not opinions - you should rewrite
Alan Lindsay | 22:02 11 Feb '09 |
|
|
Nigel,
You note that you changed your article to reflect that your 80%/20% comments were opinion, but that really fails to remedy the error. Opinion or not, it is an incorrect use of statistics and it suggests a level of accuracy that your disclaimer proves to be false.
I realize you wrote this a long time ago, and no doubt you are weary of making corrections and additions. However, your article still attracts readers and comments so I urge you to rephrase your opinion about the relative skills of vb vs c# programmers, so as to eliminate the statistical inplication. Simply saying that in your own experience far more vb programmers were mediocre than were exceptional would seem to express your sentiments, without implying that you are speaking authoritatively about the skills of the entire vb community. Your statistical comments about c# programmers should also be revised.
You clearly put a lot of time and thought into this and have taken time to respond to criticisms and make corrections. For that I commend you. Too bad so many posters share your opinion but not your talent.
Alan
|
|
|
|
|
| Anders Hejlsberg
Maximilian Mayerl | 6:17 22 Jan '09 |
|
|
First of all, good work! But Anders didn't write the world's first Pascal compiler 
|
|
|
|
|
| My vote of 1
Redmist77 | 21:25 19 Dec '08 |
|
|
Subjective but without substance.
|
|
|
|
|
| Who says C# is more terse?
lianaent | 6:40 13 Nov '08 |
|
|
As a programmer for ummmm, 44 years, I've always worked in whatever language was available. Since 2001 I've been working in VB.Net. I know good design practices and I follow them religiously - no matter what the language. I've taken C courses (anyone remember Forth - the precursor to C?), can read and to some extent write C#, I've never had a need to really work in C# - until now.
I've just taken a new job where the language of choice is C#, so I've been immersing myself in C# and converting VB programs to C# for practice. One thing I've noticed is that after converting, C# code takes some 50% more lines of code than VB! What's so terse about that??
Part of the problem is all the curly brackets. True, they don't take up much space, but they're required and make the code a lot less easy to view on a single screen. Code gets harder to read when you have to scroll to see the whole block of code. VB code that I could fathom on a single screen now takes two screens in C#. Another problem is the switch statement where every case requires a break. Is that better coding practice?? Seems like a waste to me.
And what's wrong with "With"? I learned that every time you refer to a property of a class the CLR has to re-instantiate that class. Using "With" allows you to instantiate that class only once - particularly nice when you have to reference 20 properties for example. I find it much easier to view these references in a single block then to look at a class name repeated 20 times for no good reason.
Optional parameters can lead to sloppy code? So, don't be sloppy!
And can anyone tell me whether "r[5]" refers to the sixth row of a datatable or the sixth column of row r? You have to view the code in context. I find the syntax r(3).item(5) much clearer and less ambiguous. And what in the world is so clear or terse about semicolons everywhere? (Why do you NOT need semicolons after if, using, and other block constructs?)
Even the VB IDE is easier to use and work in.
I could care less about the culture - I'll work in whatever language I have to (and I've worked in well over a dozen totally different languages from machine and assembler to Fortran, Pascal, Forth, Single Parameter Analysis, and on to SharePoint CAML, VB.Net and C#.Net). I've written extremely complex and robust video processing and graphics applications in VB.Net - with NO memory leakage.
I am just not enamored of C# - and probably won't be until they adopt more of the VB culture!
|
|
|
|
|
|
|
Ok, I have not been a programmer for 44 years. However I was a programmer for 20 years and an Software Engineer/Architect for the last 15 years, so I think I am qualified to discuss this with you. I am a consultant and have written in Pascal, ADA, Forth and goForth, Fortran (punch cards even), PL/I, Assembly 68000, C, C+, C++, Java, C# and of course the beast VB.Net.
Now that the creds are on the table. I have worked with every type of Archtects/Developer/Integrator/Testers and I have also written hardware drivers.
One Thing vb sucked and VB.Net Sucks, unless you are writting code exclusively for withing your company.
Using the Optional parameters are a toss up for the compiler. Take this code that I had to support that a MCAD VB.net guy wrote. Pre Vb.Net Vb6
Public Sub GetEmployee()
...
End Sub
Public Sub GetEmployee(Optional Name as String)
...
End Sub
See any problems - most likely not, because your compiler won't either. This is a hidden Bug. Which one will run at runtime, Flip a freaking coin. Cause that is what the CLR will do. See the guy thought he would be cleaver and overload a method, then his code that used the Name parameter Needed to be used to not use the Name paramter. so he added the Optional Paramter keyword. ( BAD MOVE )
We did not find this for 2 weeks, C# this cannot happen
Ok another One?
Here you go, Your r[5] example, is totally bogus. r(3).item(5) is better to read??? come on, I thought you have been a coder for 44 years.
obviously not in and OOL, that is Object Oriented Language, see there is OOA, OOP, OOL, and a lot more acronyms you may want to look up.
Any way
Here is a correction of your little example
In the module File:
Module Module1
Sub Main()
Dim aTest As Test
aTest = New Test
Dim Result As WidgetItem = aTest.r(4)(5)
End Sub
End Module
Say I do not have access to the other file What exactly does aTest.r(4)(5) tell me. Hmmm in every other
main stream language in the industry. I am accessing an object's with a 2 dimensional array, which returns an object, however since this is VB the both must be arrays right? Wrong See code below. It is a method returning a Generic list of objects
In a File:
Public Class WidgetItem
Public Value As Integer
Public Sub New(ByVal value As Integer)
Me.Value = value
End Sub
End Class
Public Class Widget
Inherits List(Of WidgetItem)
End Class
Public Class Test
Private aWidget As Widget
Public Sub New()
aWidget = New Widget()
aWidget.Add(New WidgetItem(1))
aWidget.Add(New WidgetItem(2))
aWidget.Add(New WidgetItem(3))
aWidget.Add(New WidgetItem(4))
aWidget.Add(New WidgetItem(5))
aWidget.Add(New WidgetItem(6))
End Sub
Public Function r(ByVal number As Integer) As Widget
Return r(number)
End Function
End Class
Now for C#
the module
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Test aTest = new Test();
WidgetItem Result = aTest.r(4)[5];
}
}
}
the other file
namespace ConsoleApplication1
{
public class WidgetItem
{
public int Value;
public WidgetItem(int value)
{
this.Value = value;
}
}
public class Widget : List<WidgetItem>
{
}
public class Test
{
private Widget aWidget;
public Test()
{
aWidget = new Widget();
aWidget.Add(new WidgetItem(1));
aWidget.Add(new WidgetItem(2));
aWidget.Add(new WidgetItem(3));
aWidget.Add(new WidgetItem(4));
aWidget.Add(new WidgetItem(5));
aWidget.Add(new WidgetItem(6));
}
public Widget r(int number)
{
return r(number);
}
}
}
Wow plain as Day I am calling a method r in the object aTest and it has a collection attached to it.
So your question
And can anyone tell me whether "r[5]" refers to the sixth row of a datatable or the sixth column of row r? You have to view the code in context. I find the syntax r(3).item(5) much clearer and less ambiguous. And what in the world is so clear or terse about semicolons everywhere? (Why do you NOT need semicolons after if, using, and other block constructs?)
Does it really matter - I mean should you be using foreach statements and r(3).item(5) can be written in C# as
r[3].item[5] and wow I know i am accessing arrays and not calling methods.
And another thing - ByVal or ByRef does not really matter for objects because VB.Net is using, dare i say it pointers, so where is this 50% more code? Does that include method parameters?
C#: public Wigdet GetWidget(int number, string name)
VB: Public Function GetWidget(ByVal number as Integer, ByVal Name As String)
Do you Know which language you are working with?
If you post it, I am sure there will be a few C# people that can reduce it, A LOT!
And what's wrong with "With"? I learned that every time you refer to a property of a class the CLR has to re-instantiate that class. Using "With" allows you to instantiate that class only once - particularly nice when you have to reference 20 properties for example. I find it much easier to view these references in a single block then to look at a class name repeated 20 times for no good reason.
Who told you the clr instantiates the class everytime a property was referenced, well no easy way to say it, lied to you. And you should also be using a "using" statement for it. By the way, that came from C#.
I love the statement about "looking at the classname repeated 20 times."
So you must use With Alot, Here is some advise. Try a Generic List, or maybe overload your contructor to
accept a DataRow. Of course i am assuming the object with 20 properties is coming from a Database Table and
you for sure are not writting multiple lines of code in VB or C# to put a DataRow into an object are you????
A little Reflection and it is a 5 line foreach statement in C# and by the way VB too. Bu You see VBers do not think like us C# people.
So What is wrong with "With", try this
Dim w As WidgetItem = New WidgetItem(1)
Dim f As FidgetItem = New FidgetItem(2)
With w
.Value = 4
With f
.Value = 5
.Value = 6
End With
End With
is that not confusing and more lines of code then
w.value = 4;
f.value = 5;
f.value = 6;
like 2 times the amount? Maybe my math is wrong 
Even the VB IDE is easier to use and work in.
really? I mean seriously this is a gripe?
Ok try this?
start a console app
Define a class, I do not care call it test
in the module type dim aTest as Test =
OMG did you see the class name appear - wow neither did I. In C# the classname and the namespace appears
so what is easier - Oh it must be the dropdown for get to the method name at the top.
Sorry if this seems like a rant, But I am so freaking tired of people saying how great VB is and
they have never coded in another language. Which I am pretty sure you have not or at least not from scratch. You know developed the framework, etc.. Otherwise you would not have written this tid bit
There are other things in VB that are just not good in any language, but are in VB.Net
using varables for Select statements
goto Statements
using the name of a function to return something from it
love this one - lets use a finally to return the value
Optional paramters - as stated earlier
instead of overloading methods
Cannot overload operators in vb.net - talk about cleaner code
widget = widget + widget - this instead of 20 property lines
I with everyone else who is C# developer will wait for the vb code
so we can reduce the lines for you
|
|
|
|
|
|
|
You got it right. It is a rant. Try decaf.
What point is there in bashing a language using contrived and implausible code? It's called a "straw man" argument and it is not well regarded as a debate technique.
All the noise and smoke obscures any serious points you might have made. Sometimes short and concise code is better than long and verbose. The same goes for arguments.
|
|
|
|
|
|
|
Lawrence Thurman wrote: Optional paramters - as stated earlier
instead of overloading methods
Using Optional paramater is a better way to overload methods. Why have
Public sub new
me.new("bob")
end sub
Public sub new(name as string)
me.new(name, 15)
end sub
Public sub new(name as string, i as integer)
me.new(name, 15, Enuma.a)
end sub
Public sub new(name as string, i as integer, j as EnumType)
me.new(name, 15, j)
end sub
when they can all be combined into a single statement
Public sub new(optional name as string="bob", optional id as integer=1, optional j as enumtype=enuma.a)
end sub
Also optional makes it much easier to set flags on some recursive functions
sub cleanfiles(parent as io.directoryinfo, optional filetypes() as string = new string(){".aspx",".ascx"})
Dim childtypes as new generic.list(of string)
for each filetype as string in filetypes
for each fi as io.fileinfo in parent.getfiles(filetype)
Updatefiles(fi)
if fi.extension=".config" then childtypes.addrange(readsubfiletypes(fi))
next
next
For each di as io.directoryinfo in parent.getdirectories
if childtypes.count>0 then
cleanfiles(parent, childtypes.toarray)
else
cleanfiles(parent)
end if
next
end sub
This will not compile... What are you talking about?
Lawrence Thurman wrote: Public Sub GetEmployee()
...
End Sub
Public Sub GetEmployee(Optional Name as String)
...
End Sub
Cannot overload operators in vb.net - talk about cleaner code
Maybe ten years ago VS 2002/2003 (net 1.0/1.1) but you sure can now. Problem is MS tends to give VB the functionality of C# in the next release of .net
IE, Operator overloading became available in 2.0, but in 2.0 we did not see inline variables in intellisense. in 2.5 /2008 we see them now. in 2.0 you couldn't declare an inline delegate, in 2008 i believe you can, etc....
MS is now giving you dynamic C#, so we VB can expect to see it in the next release of .net, perhaps VS 2010..
|
|
|
|
|
|
|
Lawrence Thurman wrote: goto Statements
Have you ever looked at assembler?? it is full of jump statements which are equivelent to goto
Lawrence Thurman wrote: I with everyone else who is C# developer will wait for the vb code
so we can reduce the lines for you
Both languages allow you to basically write almost anything on a single line
dim sr as new io.streamreader("1.txt")
dim sr2 as new io.streamreader("2.txt")
dim results As new list(of double)
dim pows as new list(of dtring)
dim pow
do
pow = sr.readline
results.add(pow * sr2.readLine)
pows.add(pow)
loop until sr.endofstream
sr.close
sr2.Close
dim answer
for i as integer = 0 yo pow.count - 1
answer += results(I) * math.pow(results(I), pows(I))
next
return answer
But give that a shot...
However, I believe the OP was making a general statement about how much more typing is involved in C#. You guys are the NUMBERS experts. VB programmer is algorithm #1 and the C# guy is algorithm
When comparing the Big OH the number of keystrokes involved in programming in Vb and C#, and you have vb= O(n) then csharp = O(n*2) to 0(n*3). Of course you could code much more effieciently in CSharp if you A) program in VB then B) go here http://www.developerfusion.com/tools/convert/vb-to-csharp/[^] and convert your code to csharp
Consider, if you average line of code that contains 10 words, that means you probably had to hit the shift key at least 10 times because c# is case sensintive.
If you write on average 100k lines (not including curly brackets) of code a month, with each line containing 10 shifts, then you have already had to do 1 million more operations that the VB guy. Now lets throw in the syntax requirements,
end of line = [;] = 1 additional operations * 100k=200k
so you are already at 1.2 million keystrokes more than the VB programmer.
don't forget your method bodies --
method body = [{] + [tab] + [{] + [enter] + [tab] --- line of code -- +[;] + [enter] + [}]
= 8 operations per code block
Time/keystrokes wasted keeping your brackets nice and pretty...
If you are still in denial..
Install a keystroke logger.
Program in VB, Program in C#. Compare the size of the log files.
|
|
|
|
|
| C# to copy features from VB.net
Olivier Giulieri | 20:05 27 Oct '08 |
|
|
On the topic, the next version of C# is going to borrow dynamic types and optional parameters from VB.net.
"Isn't it amazing? It took us 10 years to get back to where we were" Anders Hejlsberg (Microsoft Technical Fellow) joked.
http://reddevnews.com/blogs/print.aspx?blog=2885[^]
|
|
|
|
|
|
|
As long as these features are only used as intended, they will of course improve the language.
However, as with any new feature we will of course se some cases of misuse. Like the use of optional parameters in newly designed classes...
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
| Waste of space
Member 1121797 | 9:22 22 Sep '08 |
|
|
I've been programming long enough to remember the days when you wrote in the language you had access to. If a client had a Fortran compiler, you used it. Assembler or COBOL, okay by me. Whatever you had is what you used. Memory and storage were expensive and you did as much as you could in 2k chunks. Make sure you stay within a byte or word boundry and pad only when you need to. Sloppy coding cost time and money.
I've worked with all kinds of programmers over the years and some of the BEST often programmed in VB. Most, if not all, could program in C as well as C++, C#, and a few other languages to boot.
Most of these youngsters arguing about C# vs. VB .Net have never written a driver for a new card or even know how to trap a hardware interrupt before the OS sees it.
Bottom line is that we wrote software to make a company more efficient so that the company could make more money. If the software could do that, it was good software. If not, ... Ask yourself if that's still the case for you. If it's not, it should be!
|
|
|
|
|
| Completely ridicules advertisement for C#
maxxnostra | 8:39 13 Aug '08 |
|
|
I am lead architect (leading team of 12 developers all of them proficient in both C# and VB) for .NET development in medium sized enterprise. In my whole .NET life it was always proven that VB.NET is much easier to work with then C# even my strongest C# developers that were religiously sticking to C# began to understand the power and simplicity of VB.NET compared to C#. Heck – the most serious work is done in VB.NET not in C# and by those C# developers. My real life experience is different from those marketing type of articles. Come on --- no real facts or strong emphasis on any claims made in this article – just subjective observations. There are not real facts for backing up the language cultures. VB was not made to mass market software development – it was a language that naturally evolved in MS Windows environment (hence the words VISUAL for object oriented approach) from already popular and only language natively supported in MS DOS (Basic for DOS – scripting batch files it is all BASIC like syntax and semantics). MS put an excellent effort to bring this language on the scale with other more serious programming languages (like Borland C++). The language it self deserves more credits then any other. C# on the other hand was completely marketed towards bring all C programmers (even Java as Java is also a derivation of C type language) to a .NET world – while VB.NET was naturally inherited in .NET. Sow what is the outcome – more serious programmers, experienced, are getting to .NET with familiar language. Knowing that MS “was going in battle” for programming languages with Borland (C,C++, Delphi) and Sun’s Java, does it is sound natural to those programmers, if they move to .NET, to use VB. Hell NO… It was marketing effort for C# - completely purely out of interest for MS, not for the good and stability of the language it self but to have a language that could be more easily adopted.
<b>80% of C# programmers are good, while 80% of VB programmers are not good</b>. 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:
<i>Throwing something like this is completely ridiculous as the whole article by the way.
When you say 80% of C# or VB you are talking about all types (experienced, not experienced, beginners and masters) which in reality would be significantly more beginners or not experienced developers. That implies VB is chosen language for beginners not the VB programmers are LESS good or worthy then C# programmers in general. How about the rest of the 20% can those be compared and measured up.</i>
<b>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. <b>
<i>This is completely opposite explanation of mine above - it only means that VB community is bigger but also it has more beginners in it</i>
<b>
and because VB syntax and semantics make it more difficult to avoid common programming errors and hence to program well. </b>
<i> NOT TRUE -- VB Syntax and semantics are easier to use - and what's that about common programming errors – what are the common programming errors , mistyping is more prone to C# then to VB. </i>
I AM SICK OF THIS ARTICLE --- really no real appreciation for VB.NET at all. I was expecting facts but this is all too week for me to even consider it as article. Shame on you for publishing irrelevant subjective facts. It is unfortunate that VB even in today’s incarnation with .NET still has to take the hit. How much more effort you want MS to put into VB to make you all stop attacking it for no relevant reasons.
Search for the other articles on this site or anywhere else (a complete comparison of VB.NET and C# is a good unbiased technical comparison) to get more realistic comparison. Do not let advertisments like this judge for you.
|
|
|
|
|
|
|
Appreciate VB.NET?
No, I don't think any C# programmer really appreciate the existence of VB.NET. For those who know C#, there is no reason to learn VB.NET. There is nothing useful they can learn from VB culture.
From the economy point of view, a company should use only one language (between VB.NET & C#). In my country, VB.NET had lost its place to C#.
Even for the VB veterans, some are more appreciate VB classic than VB.NET. That's what the petition all about: http://www.classicvb.org/petition/
|
|
|
|
|
| Totally agree
cockiest | 19:06 30 Jul '08 |
|
|
Choosing between c# or vb.net is more than the personal preference!
|
|
|
|
|
| The truth hurts
ixup | 5:31 6 Jun '08 |
|
|
I love vb.net i really do, when i look at C# even though i understand it and can write it, it just hurts, any one who thinks curly brackets make a difference is an idiot but i am realizing that vb.net is being taken less and less serious, and i understand from a business perspective it would be pointless to have two identical products and that is why vb.net and c# have gone down their own paths. I wish there was a clarification from microsoft where exactly these two languages stand because they are fooling both parties.
Visual Basic Lover
|
|
|
|
|
|
|
I'm right there with you. I learned to program in BASIC on an Apple ][e in high school. I went to college and after deciding Electrical Engineering wasn't for me, got a degree in a major called Business Computer Information Systems, which most Computer Science majors would probably look down upon because I programmed primarily in COBOL. In my jobs I avoided C and languages with C-like syntax whenever possible. Although I took OO classes, dabbled in C++ and Java, I always felt like what is the point -- why have brackets and cryptic symbols (I'm simplifying things here) if you don't have to? In my mind, the evolution of programming languages should be to make things easier, not more difficult. I got into web development. After programming in Perl, ASP (VB Script) was a revelation for me in 1996 -- I could write code that made sense when I looked at it. I had a lot of success with ASP and SQL Server -- started a company built on it, sold said company for a lot of money. The acquiring company was impressed with what we were able to accomplish as a 2-person company, and their programmers (CS majors) were highly impressed with our code. We were definitely not lazy and definitely used good coding practices.
I never understood the elitism from the C-C++-Java people. They could program "better" than me, but I ended up being far more successful than they were. They still toil away in cubicles and I have coasted by for the last 8 years with part-time consulting jobs and the money I banked from the sale of my company. It was always about results for me, not how you got the results. This article reeks of elitism. The so-called culture of the C# people is about elitism. I want no part of that. I've never needed to call myself a "good programmer".
Now I am faced with rewriting an entire legacy application in .NET. Is there a business reason to use C# over VB? I don't know. I guess if I did it in C#, I can add C# to the list of many languages I know. It seems that my time, and the client's time would be better utilized if I did it in VB.
|
|
|
|
|
|
|
Well curly brackets make me feel comfortable
Anyway C# or VB.net doesn't make a difference (except for some minor differences) they both compiles to IL and get executed by the same “engine” the CLR so why compare them ?
|
|
|
|
|
| A point of view from a BASIC programmer...
Robert Royall | 8:55 7 Aug '07 |
|
|
Yes, I admit it. I am a BASIC programmer. I always have been, from the time I was six years old and used my Atari 800 BASIC cartridge to do my math homework problems for me. From there I learned to do simple coding in GW-BASIC and BASICA in my early teens, and I started learning some of the advanced IO and system functions in QBASIC when I was in high school. Afterwards I wrote crude and simple games and utilities in Visual Basic 5 and 6, and learned Access Basic and VBA for some database work in a few jobs I had.
And then I found C++, and everything changed.
I knew VB had its limits. There were things I wanted to do that I couldn't do, because the language had no terminology, no understanding of those things. I had to learn C++ because it was closer to the system, it gave me access to those things in Windows that VB chose to hide away.
C++ is hard, and reasonably so. A computer is so unimaginably complex, and while BASIC kept me safe from that complexity, it also kept me from expanding my mind and understanding. Byval used to be just a silly meaningless keyword to me; it slowed down my program, drove up my memory overhead, and all it did was make sure that my function wouldn't overwrite the parameters it was given. Surely I was careful enough I could keep my program from doing that myself, right? But C++ taught me what byval and byref really meant, and what they did to the system hardware, and why my memory overhead grew, and why I couldn't overwrite a byval parameter.
It took me a long time to learn what pointers were and what they were used for. I learned OOP, and constructors/destructors, and the correct way to instantiate new objects. I had been writing code nearly my whole life in BASIC... but C++ taught me how to program.
I wholeheartedly agree with this article. Most VB programmers come from a purely BASIC background. Their idea of OOP is encapsulated in VB classes, and polymorphism is something you have to declare with Implements Interface. They link to 3rd party libraries through some mysterious art called COM, without really knowing what COM is or what it does in secret, underneath the compiler. Many VB programmers have never dreamt of a constructor that could take parameters. API calls are an option of last resort, and the average VB programmer considers it a form of blackest voodoo.
Unfortunately, many of those VB programmers who have migrated to .NET treat it like it's just a bigger, more confusing VB6. A project I migrated from .NET 1.1 to .NET 2.0 had about 60 compile errors because every MessageBox statement used a hard coded number value for the button argument instead of using the enumeration. I couldn't count the number of warnings I got from converting numbers to strings and vice versa.
The long and short of this is that C# is familiar and appealing to C++ and Java developers. The reason most C# developers are better than their VB.NET counterparts is because most of those C# developers came from a background that tought them what their hardware did with the code they compiled. A lot of VB programmers don't have that background - they just know that the program acts the way they tell it to act without knowing why it acts that way.
I still program in VB.NET at work, not by choice, but because that's what most of the people I work with use. But even so, I still tend to think in C#, because now I know how to program... instead of just writing code like I have been for all those years.
Please don't bother me... I'm hacking code right now. You remember what "hacking" really means, right?
|
|
|
|
|
|
|
I aggree with your observation that most of the c# sharp programmers come from C world of programming which in comparison to VB before .NET made them superior. That superiority came from VB's own lack of low level access (methods/calls tools name it whatever yo like) to a hardware resourses (heck not even to some of API's becasue of the types that were not supported - pointers mostly that need handles not simple ByRef). Very true observation that VB was limited in pre .NET times. But this is comparison of VB.NET to C# - which has nothing to do with old VB (before .NET) to other languages. On the other hand there was no professional VB programmer that did not touch C++ for the limitations that they were hitting with VB - so it was just a matter of time when you as junior VB will really understand what are the limitations of classic VB (or understand the logic behind ByVal and ByRef parameters).
|
|
|
|
|
|
|
Last Updated 20 May 2005 |
Advertise |
Privacy |
Terms of Use |
Copyright ©
CodeProject, 1999-2010
