At lunch yesterday, I was part of a fun discussion with myself and Dan Appelman representing VB coders and the 3 “R”s as they called themselves, let's just say Rob Richard, Rory Ray and Ryan (I might be close), who were attending from Chicago - representing C# coders.
Since I was preparing to do my Demystifying C# for VB programmers talk (which was this morning and as fun as always and I wish I had hours and hours to do it in!) we were chatting about some of the syntax differences.
I reminisced about reading an eye opening perspective from a C# programmer who couldn't understand how VB developers knew the difference between getting an item from an array
MyArray(itemnumber1)
and calling a method that takes a parameter
MyMethod(parameter)
because we use parens for both, where C# uses brackets for an array
MyArray[itemnumber1];
and therefore it is visually explicit to them.
This led to the usual casing conundrum that we VB devs just don't get. Because C# (and it's C based predecessors and other languages as well) are case sensitive, developers can use a variety of variations (hmm that's a bit redundant, isn't it...but on the other hand helps illustrate the redundant nature of coding this way... :-) ) of the same word to represent different things.
mything (this ones an integer)
MyThing (this one's a property)
myThing() (this one is a method)
Mything (this one is a class)
This drives us VB devs (well I speak for myself and Dan) a little batty. But the 3 R's were adamant that it is just completely natural to them and they never have any confusion about which is which. The reason for this is that these guys are very strict about their coding standards (which I know I am not following in my above examples). But they insisted that they always recognize a lower cased word as a local variable, etc. and that they truly have no problem when reading or writing their code.
I do, in fact, understand and totally accept this. Since my brain isn't programmed the same way that theirs' are, it would never work for me.
The flip side of this was there confusion over our habit of typing everything in lower case once it has been defined in it's proper case everywhere and letting VB a) fix the casing and b) give us a very quick visual clue if we typed the variable properly. That 2nd feature is because if VB doesn't convert that into upper and lower case, we probably didn't type the correct letters.
It's just as important for me to remember how confusing C# was when I first looked at it or tried working with it. That makes it easier for me to communicate some of these concepts to VB programmers, as I know just where they are coming from and what their perspective is. I still struggle with a lot of things in typing C# and don't always recognize where my mistake was just from the intellisense or compiler error that is being thrown. But for the most part, though some things have gotten natural for me, I can almost always recognize what mistake I might have made based on the wierd error being thrown. I still get killed with () after methods - VB doesn't care one way or another. Some would argue that this encourages me to be a lazy programmer - as I am not being forced to be explicit all of the tim. But I can live with it. I have enough challenges in my life. I'm thankful for free parens!