I used to be a VB programmer since VB2 … I’ve used VB for too much to be able to learn C++ (whenever I tried to learn the WIN32 APIs or the MFC/ATL I found that VB can do what I need in quarter the time and tenth of the effort, so I abandoned learning C++), but when I had the chance to do things in C#, I did (first I learned .Net on the VB.Net syntax … then I found that C# is too similar to be a true other language … whatever I learn in VB.Net adds to my knowledge in C# and vice versa … so why not add another language in my arsenal and have more oppertunities in work).
Now I’m paid more to do the same work (with the same effort), have much more respect for the same knowledge I have, and I’m treated better in the community (just out of not advocating VB anymore).
I’m not saying that I don’t like VB, but if the hype says that you need to slightly adjust to become more professional-looking, I think I’ll go with the hype.
The argument that the modern IDE makes it easier to work with case-insensitivity can also be completely turned on it’s head. It’s very easy, if you have incorrectly typed a variable, to change it.
Maybe it is because I’ve grown so used to case sensitivity, and the importance of case to define meaning given a vague context (i.e. the ability to see the scope of a variable in any location) but I find case insensivity rather clumsy.
For a start, I often see code written that changes case at will because the programmer can’t decide on a style. Should it be fooBar, FooBar or foobar? It changes all over the place, making the code very hard to follow. With case sensitivity, you are forced to make a consistent decision. Again, with the modern IDE, if you decide to change it, it is very quick and painless to do so. Though this argument could be countered, the refactoring tools used to quickly standardise the casing I find when it is imposed, it is followed more strictly.
Then there is the issue of differing public and local variables, made even more prominent with the advent of properties. I personally find Hungarian Notation and such likes to be far too pointlessly verbose. You can often tell from the context what a variable is. firstName will be a string for example. Add to that the context of assignment and it’s even easier to tell. Hungarian notation then just complicates and clutters the code (as does endifs etc. imho, though I can understand the argument for clarity) With casing though, you can use a separate casing for differing scopes. I believe the standard .NET casing is lower-camel for parameters (and my personal preference for local variables) e.g. firstName and Delphi casing (all separate parts begriming with a capital) for public variables e.g. FirstName. This does make for clean and nice looking code imo.
And on side note, no-one should ever, ever, under any foreseeable circumstance, use all lowercase for compound variable names. It makes it almost impossible for people to read, especially if they don’t know what the words are, and makes it very hard to glance over code.
As for the comment that implied the closer to the vernacular the better, this is not really the case. It’s often cited that high level languages are closer to the vernacular than low level languages. While this is often true, this is not really the purpose. The idea of higher level languages is to shift from byte-pushing to being able to solve problems in a manner that is more familiar to the way a person would think about a problem. That is why there are so many different languages; each one is designed to solve a different problem, so exposes the functionality in a way that is closest to the way that particular problem would be considered.
The other problem is that the closer to the vernacular it is, the further it is from any other language. I can’t begin to imagine what it is like for someone who doesn’t speak English to learn English API’s, let alone when most of the language they are programming in is alien to them.
Braces and other intuitive symbols make far more sense for not only globalisation, but also for quickly glancing over code. Endifs and such likes are a double edges sword. Yes, they make it easy to follow complex branching and iterating code, I will agree. But they also make glancing over the flow of code difficult, and I find that I am more often glancing over code than exploring the depths of a eight branched, multi-itterational algorithm. Modern IDE’s have features to help this, such as highlighting matching braces (though Visual Studio could do much better in this, by implementing such features as allowing for the ability to temporarily highlight multiple braces at a time in differing colours to see the flow of code - a similar technique would also help when studying complex expressions, and to tooltip with the begriming of a branch or iteration when hovering over the closing brace)
Ken Granderson’s comment about in-line assignments I would agree with. I personally rarely use them and have only recently completely figured out the logic of them. In some cases too, his ++i example could confused some programmers. However, anyone who has properly learnt the language would be able to work out such code.
Personally, I find I prefer the C syntax as it tends to create cleaner code, and is actually allot easier for me personally to read. At the end of the day, it’s what you feel comfortable with. Verbose or consice. I prefer consice.
I grew up with C++. Anyone’s first reaction to something different is that it is not as good.
Well, as a C++ guy, i can say I originally disliked the “feel” and look of VB.NET syntax. But after coding with it for almost 2 years, I know prefer it, and it feels like a chore to program in C++ wiht it’s case sensitivity. I love VB for getting things done.
And many applicatoins don’t really matter if you get 100% speed. JIT compiled VB.NET will run around 97% of compiled C++ speed and that is plenty fast. And JIT compiled java code can also match C++. We must remember that after a code is compiled it is all the same langague: machine. Whether your wrote it in C++, java, or VB, it is all machine after compile. JIT compile gives a slow down in the beginning but after that you have the potential to go just as fast as code written in C++.
java was orinigally slow becuase it was interpreted. But now it is commonly JIT compiled and is much faster than it used to be.
VB.Net IDE is great and background compiler rocks, but IMO C# is a better designed lenguage, and VB focuses on ease at the expense of simplicity.
All the lacks I’ve found in VB are a first-day-candy second-day-snare: features allowing people to start coding faster but generating some confusion about OO desings and, at the end, what your code do. IMO VB is a always-compile-never-works lenguage.
Some examples:
Assignment and equality are different things. Using the same symbol is hazy
bool a = 2 == 3; // simple
Dim a as Boolean = 2 = 3 // not so much
Allowing static methods be called as if they where instance methods it’s a great idea if you want to confuse people. A VB programmer usually tries to override a static method. C# syntax teaches C# programmers that this is a senseless.
Overrides, MustOverride, Overrideable and NotOverrideable keywords are scientific but more confusing and hard to write than the c# equivalents:
override, abstract, virtual an sealed. Just as 1, 2 an 5 cents Euro coins.
Overloads. The only utility of this keyword its to increase the confusing with the override keyword family :D.
Implicit casting everywhere it’s a bad idea, but Option Strict it’s very severe and having thousand of casting functions (DirectCast, CType, CInt, CBool…) so nobody uses it. The result is that visual basic code usually converts to string and go back. No body knows what the type of a individual sub expression.
Furthermore, the ‘implicit casting everywhere idea’ make generics a bit harder to understand to VB programmers.
By the way, it’s funny to see CInt to cast to Integer, and CBool to cast to Boolean, Why not using Int and Bool data types instead?
Everything can be Nothing. In VB you can assign Nothing to an integer, a char, a DataTime and they get it’s default value. This is an asymmetric behaviour with some problems:
VB programmers understand worst value-types.
VB programmers think on String class as a value-type just because VB return true when comparing Nothing and “”, another surprising behaviour.
Everything can be Nothing idea makes Nullable types difficult to understand.
Writing ByVal everywhere makes ByRef hard to find.
Not writing ByRef on calling it’s a mistake. Writing it is clearer to understand.
Allowing passing a Property ByRef it’s a great idea if you want to never understand what a Property is, and what ByRef really means.
Even more, allowing passing a literal as a ByRef parameter its a daring to the logic. Passing Nothing ByRef it’s the climax of the stupidity.
What’s supposed to do this code?
Function IncAndReturn(ByRef a As Integer) As Integer
a += 1
Return a
End Function
IncAndReturn(Nothing)
Visual Basic events / delegates syntax make Visual Basic programmer to forget delegates. Delegates are first class types in .Net, but not for visual basic programmers.
Object default return type. If I forgot to write the return type, please compiler, remind to me, probably it’s not just an ‘object’
Some code path without return. If I’ve forget to return something, please remind to me, don’t return nothing.
Not Initialized local variables should be marked. Write ‘= null’ when you are coding cost 1 second. Take notice of a lost initialization at runtime cost 2 minutes.
References in VB.Net 2005 are hidden. The average VB programmer builds a one project solution?
Visual Basic allow not writing parenthesis on methods without parameters, writing parameters on properties and arrays are acceded with parenthesis, this is a more confusing approach than the C# one:
What People is?
Visual Basic
People() - A Method or a Property
People(2) - A Method, a Property, a Array, a Collection with a default parameterized property or a Named property.
People - A Method, a Property or a field
C#
People() - A Method
People(2) - A Method
People[2] - A Array (or a collection with an indexer)
People - A Property or a Field
With these examples, I want to show the problems of the Visual Basic “first-day-candy second-day-snare” philosophy, not a deep C# - Visual Basic comparison.
I’ve not mentioned for example missing features of VB 2003 like using statement, unsigned data types, unsafe code… and VB 2005 missing features like anonymous methods, Iterators and NullableT special synthax.
Sorry for my bad English.
Make everything as simple as possible, but not simpler.
Albert Einsteing
I keep seeing the reasoning behind choosing Visual Basic (.NET, version 6, whatever) being code readability. I say rubbish.
When you learned to program, I hope you were taught proper design and program development methodology. If you start your code on paper (or whiteboard or visual design tool) and not in the editor, you won’t need an overly verbose language to make your code readable. Implement a proper design, document your programs, comment correctly, and write clean code.
And putting
} // END OF METHOD
after the closing brace is a small price to pay for using a cleaner language and being paid more.
But this takes effort. Wonder if this is where the ‘lazy’ reputation came from?
A quote from Francesco Balena “Programming Visual Basic 2005: The Language” page xxii:
“I find it quite ironic that most developers can argue for hours about which language can be more efficient or productive, yet they fail to leverage Visual Studio to its full potential, for example, by learning how to write macros, templates, and code snippets, or how to customize the IDE to fit their needs or programming style”.
I just starting to swtich from VB.NET to C#. (7 Sweat Years with VB). The main reason is that I’ve seen tons of excellent programmers contribute a lot of ADVANCE coding from C++ to C#.
I understand that I can use a conversion tool to translate back and forth. And I also undestand I might not feel comfortable Case Sensitive.
But I want to be native, and directly talk to C++ guys without the need of “middle man”.
After reading every word in this blog, I’ve come to the conclusion that everyone is right and nobody is wrong. Bottom line is-- do what YOU want and what YOU think matters the most. If you want more money and unfortunately (more respect), than the choice is obvious, if you’re in a position where RAD is essential, than I’m sure we’re all clear on that choice as well. The languages themselves are just tools-- and like a well seasoned mechanic-- he doesn’t work on Ferrari’s with a hammer alone (at least not mine). It’s funny how people are always trying to improve their cicumstances, yet never willing to improve themselves. The differences between the two languages are minimal for the most part- and if you really enjoyed what you do- than you would enjoy the challenges that each language poses. Isn’t that what programming is about anyway- the challenges, overcoming the obstacles, creating the unthinkable, doing the impossible? I say let’s focus on what intrigued us about coding in the first place and quit splitting hairs. For God’s sake man-- can’t we all just get along?!
Ruby reduces the need for boilerplate code 10 fold with vims code folding i can see the structure of the code and also rails has some verry powerful dwim to help reduce complexity also you got attr_reader and frends to help write boilerplate by the languige .
lets say i want a simple utilaty that prints how many times you repeat a word
x = Hash.new(0)
ARGF.each do |line|
words = line.split
words.each {|word| x[word] += 1}
}
x.keys.each{|word| puts “#{word} repeated #{x[word]} times”
Coming from a Java, PL/SQL and C background to .NET I have consistently been amazed by the way that VB developers blindly defend what is probably the most horrific syntax ever invented.
The fact that the majority of VB developers have absolutely no idea of what else is out there does not deter them in any way from sharply stating “VB is better!”
Often they reason that VB is more like English so it must be better. This would of course be true if computers spoke English, which in fact they do not, they speak machine code. Now C was originally designed as a sort of cross platform assembly language and through this has become very popular with people who actually have a clue about what they are doing, and so C# has inherited much (but not all) of this design.
