Alex Clark said:
Well, depending on how you interpret it, many have stated that their
personal preference is for the "less ambiguous, more precise" nature of C#'s
parenthesising, almost as though it's impossible to determine what a piece
of code is doing when the () suffix to a method call is optional.
I don't think anyone's said they've found it impossible. They've just
expressed their personal preference, and I don't see what's wrong with
that. Do you really not think there's a difference between "I find it
easier to tell the difference between a property and a method when a
method call always has brackets and a property access never does" and
"I find it impossible to determine what a piece of code is doing when
the () suffix to a method call is optional"?
Surely the word "over-zealous" implies that C# is being *too* zealous,
i.e. that it is wrong to behave in the way it does. If you had
suggested that C# was merely zealous, that would have not have been as
judgemental IMO.
but if you code one routine in both C# and VB.NET and hand them
over to someone who's never really coded before, I would wager they're a lot
more likely to understand what the VB.NET code is doing than the C# code ---
precisely because VB.NET is, by its very nature, a much more naturally
readable language than C#.
.... for someone who's never really coded before, yes. Using words
instead of symbols has that effect, certainly.
This doesn't make it better or worse than C#, but it does mean that
its focus is not on ensuring every semi-colon is perfectly placed
Ironically, when it comes to *placement* VB is sometimes fussier than
C#. VB requires that you explicitly say when you want a statement to
span more than one line.
C# could care less whether you place the statement-terminating semi-
colon on a line on its own, at the end of a line, of several (blank)
lines later. It does require it to exist, however.
but rather on keeping the syntax closer to something a mere mortal can
understand, rather than just coders.
I tend to find that non-coders don't really *want* to read my code much
- does your experience differ?
It's an interesting dilemma though - do you design a language so that
people can read it easily if they have no experience, or so that if
they *do* have experience they can read it even more easily? Obviously
going too far in either direction is a bad idea, but I think it's not
unreasonable to think it owes something to heritage.
I *suspect* that going back to C and VB "classic", most C developers
who wrote any code as part of their job were writing code as *most* of
their job. I believe, however, that many VB developers were writing VB
as part of doing a different job - VB made their lives easier, but
without them needing to get really interested in how it all worked.
Before anyone gets worked up, I am *not* saying that this applied to
all VB developers - but a far greater proportion than C programmers. I
also believe this is part of why VB is able to reasonably claim it is
the most popular programming language. I'd be interested to see how the
numbers might change if "amount of time spent working with language"
became part of the statistic.
On a more general note, both languages have been getting more
complicated - C# 3 is very significantly more complex than C# 1, to the
extent that I have sympathy for anyone starting from scratch at this
point. To a C# 1 programmer, a piece of code using query expressions,
generics, iterator blocks and the like would be hard to understand
(particularly in terms of deferred execution and other nuances). To an
experienced C# 3 developer, it's likely to be significantly easier to
understand than the semi-equivalent C# 1 code.
It does look cool, but I don't have the time at