For the record, I started doing Windows programming in C in 1990, then moved to C++ and Visual Basic by 1994, and have not looked back since. From the late 70’s, I learned and forgot about a dozen languages, including APL, which is the most incomprehensible language I have ever seen due to its liberal use of symbols, which is also the basis of most of my issues with C-style syntax.

My issue with the C-style syntax is that I believe that is is based on an outdated need to use the bare minimum storage possible for the code, and thus uses punctuation symbols in its syntax, which requires human beings to do a lot of symbol parsing in order to read C-style code.

VB’s syntax recognizes that storage is more widely available and IDEs are smarter than they used to be, and thus can adopt a more verbose syntax that is (IMO) significantly easier for humans to read than C-style syntax.

Specifically regarding your exceptions:

#1: The keywords ‘Sub’ and ‘Function’ immediately inform me whether the method returns a value of not, rather than requiring me to remember that there is no such data type as a ‘void.’ Obvious visual cues like this save me brain CPU cycles better spent understanding the meaning of the code.

Rather than ‘use the same word/character to do 20 different things,’ ‘Sub’ infers one type of method use, while ‘Function’ infers another.

Also, VB uses explicit keywords to let you know that a block of code is a Sub/Function/etc, while C-style languages force you to use your brain as a code parser to distinguish between subs, functions, properties, etc.

This makes it much easier to scan blocks of code that you did not write and more quickly understand what different blocks of code do, as well as makes it much easier to search for different types of code if you do not have VS available.

#2: ‘AndAlso’ and ‘OrElse’ are necessary to preserve legacy ‘And’ and ‘Or’ functionality. I would say that this was a deficiency with the legacy VB language, which always evaluated both arguments before performing the logical operation. I am sure that someone’s old code would break if the functionality of ‘And’ and ‘Or’ were to change.

While I am not particularly fond of the terms ‘AndAlso’ and ‘OrElse,’ I do not have any better suggestions, so I accept them.

I also appreciate ‘IsNot,’ which finally obsoletes the counter-intuitive ‘Not Is’ syntax that I found to be VB’s most clumsy syntactical construct.

#3: Finally, I would be willing to wager a week’s pay that I can visually find the start and end of nested VB blocks than any C# programmer can find the start and end of nested C# blocks, precisely because Whatever/End Whatever is precise and infinitely easier to spot with the human eye than curly braces, which look the same regardless of the type of code block they are defining, and look a lot like parentheses when you have been up too late.

Rather than use the curly brace ‘to do 20 different things,’ Ifs are terminated with End Ifs, Whiles with End Whiles, and so on. Again, the VB language makes the job of interpreting the code one step easier, which gives me more neurons for problem-solving rather than code parsing.

My basic feeling about the syntax differences is that C-style syntax forces you to spend too much time parsing code (oh, the fact that the property does not have a setter means that it is read only), while VB puts the meaning right in front of you (‘ReadOnly Property’).

Thus, IMO VB makes it harder to write undecipherable code, while C-style syntax almost encourages it via its use of symbols and more generic syntax constructs.

While a terse syntax made sense 30 years ago, thanks to advances in storage and CPU power and the powerful IDEs that they have spawned, I find no redeeming value in continuing to perpetuate syntax based on an outdated set of requirements, when a more current philosophy of ‘make the syntax as inutitive as possible and build keystroke saving shortcuts into the IDE’ generates (IMO) significantly easier to read and more maintainable code.