Power10: Reduce verbosity through #light
[This post is part of a series, "wish-list for future versions of VB"]
IDEA: Add a #light directive, like F#, to reduce VB's verbosity. We already eliminated the dreaded "_" to make VB syntax look cleaner. We could also use layout as in Python and F#'s "light syntax" to be able to omit noise words like End Function, End Sub, End If, End Class, End Module -- they don't have any significance, especially since the IDE is hardcore about introducing intendation.
Module Module1
Sub Main()
Dim s = Console.ReadLine()
If s = "" Then
Console.WriteLine("you pressed enter")
Else
f(s)
Sub f(ByVal s As String)
Console.WriteLine("you wrote " & s)
Provisional evaluation from VB team: A new syntax for the language would be a MAJOR upheaval. In this case we don't think it brings enough benefit. In any case, we think that the new WPF-based VS2010 editor will be capable of achieving the same effect through plugins.
Comments
Anonymous
February 11, 2010
The comment has been removedAnonymous
February 11, 2010
Please don't do this, it's unreadable!Anonymous
February 15, 2010
I have to say I really don’t like this idea – it makes the code much less readable for no obvious gain. I did like Paul Vick’s idea of lower case keywords (I’m not sure why – it just looked ‘neater’), but this doesn’t appear to improve the appearance of the code at all.Anonymous
February 18, 2010
Bad idea. But do you know what's an even worse idea? Encouraging people to use IDE plugins to mangle standard VB into some weird custom language no-one else understands. How can we build a VB community if we can't read other people's code? Will Microsoft support cope with users who ask questions in weirdo language? People have been creating weird custom languages for decades by mangling C and C++ with macros. Most respected programmers think it's an appalling idea (Raymond Chen, Bjarne Stroustrop). http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspxAnonymous
February 19, 2010
Yuuuuuuuuuuuuck. But I definitely like the idea of lower-casing the keywords. Are we going to see that idea pop up in this series?Anonymous
February 25, 2010
The more I think about this one, the more I think it's a bad idea. It is just too big a change for very little benefit. Is it proposed only that the End Ifs etc be hidden (which would be OK but still cause potential confusion) or that the developer would be able to omit them entirely when writing new code? The latter would mean that indentation would be syntactically significant, which is undesirable. The former would be just as bad: it would look to the developer like the items could be omitted in new code, even though they actually couldn't.Anonymous
March 02, 2010
The comment has been removedAnonymous
October 30, 2010
Please do not lower case keywords, it makes it ugly and when you press enter and ur variables capitalize as per ur declaration, u get feedback that uve typed ur variable correctly!! Also uppercased keywords and variables are much more beautifulAnonymous
May 10, 2011
I'm a bit of a latecomer to this discussion, but I really like the suggestion above (Donny) regarding property syntax. Especially with WPF, I make use of a LOT of properties, and they always end up completely overwhelming my classes. Each property requires two extra "End" lines. For even a dozen properties, that's an extra 24 lines of code that seem completely unnecessary - "End" could be inferred just as "Break" is inferred in a Select Case statement. The Set parameter is also a pain during refactoring. Many times I've changed the type of my several properties only to have to go back because I forgot to change the type of the Set parameter (especially annoying when the types are generally compatible, like upgrading from Integer to Long or something like that). I like the trimmed down property syntax in VB10, but it's useless since it doesn't allow me to implement the INotifyPropertyChanged interface in my Model classes (now that would be a fantastic feature).