John Montgomery’s entry on “Express “Orcas” Principles” got me thinking about the whole “principles” thing. Just like you should always be able to give an elevator pitch for your product, I think you should always have a clear idea of your product’s principles. I particularly liked Bjarne Stroustrup’s description of C++’s principles in “A Brief Look at C++0x”:
C++ is a general-purpose programming language with a bias towards systems programming that:
- is a better C
- supports data abstraction
- supports object-oriented programming
- supports generic programming
By “systems programming”, I mean programming the kind of tasks traditionally associated with the operating system and fundamental tools. This includes the operating system kernel, device drivers, system utilities, networking, word processing tools, compilers, some kinds of graphics and GUI, database systems, games engines, CAD/CAM, telecommunications systems, etc. This kind of work is strongly represented among current C++ users.
I recently wrote up a paper that tried to distill some new ideas we’ve been kicking around here in VB-land and decided to submit it to Bill’s latest ThinkWeek. Remains to be seen whether he actually reads it (submitting papers is quite in vogue these days, so there are a lot of ‘em), but I started the paper by laying down what I see as VB’s “principles”:
Visual Basic is a general-purpose programming language that prioritizes ease of use. In particular, Visual Basic is designed with the following principles in mind:
- Approachability. English-like syntax is used to promote the clarity and readability of code. Wherever possible, meaningful English words or phrases are used instead of abbreviations, acronyms or special characters.
- Simplicity. Extraneous or unneeded syntax is generally allowed but not required. Language semantics prioritize understandable behavior over technically “correct” behavior.
- Flexibility. Data types can generally be omitted for brevity and speed of development, but can be introduced at any time to improve error checking or environment feedback.
- Pragmatism. Working in a natural way is a higher priority than language purity. Supporting more than one way to accomplish a task is acceptable if it supports common development methodologies.
- Platform support. The language enables programmers to take advantage of the major features of the .NET Framework and is always consistent with its conventions.
Do we always fully live up to these principles? Probably not. Do we always strive to achieve them anyway? Definitely.
how about reasonable backwards compatibility? The versions of QuickBASIC, PDS, and Visual Basic had that until VB.NET thourghly broke it.
What is needed are
1)Option IntBase 16/32 to choose whether integer and long will compile to int16/int32 or int32/int64
2) Printer compatibily object that acts as an adapter between the VB6 style of printing and the .NET Method
3) VBGraphics compatibility object that acts as an adapter between the VB6 style of graphics and the .NET Method. Basicaly works by having an attach method that associates a .NET graphics object with the VB6 drawing object.
#2 and #3 also fulfills point #2 Simplicity as VB6 it was way easier to print or draw something than the .NET way.
4) Support Nested Sub/Functions or restore Gosub/Return. Personally I recommend Nesting Sub/Funcitons as they have more capabilities and you can upgrade old gosub code by two subsitutions.
If you want the people who use VB6 to move over the VB.NET then you need to respect their investment in their existing code base. We don’t want to be limited to using COM Interop and other things of that nature. We want to be able to move our codebase over so we can use .NET new feature without having to re-write.
Drop the keywords after End. So instead of End Sub it’s now just End. End If becomes End and so on.
Many times I’ll have a method start out as a Sub and change to a Function and it’s a pain to change both the function definition and the end statement.
Drop the Dim statement also, at least for variables whose type is declared.
Dim o as Object becomes
o as Object or
Less keywords cluttering up the screen means easier readibility, at least for me.
>> Many times I’ll have a method start out as a Sub and change to a Function and it’s a pain to change both the function definition and the end statement.
You mustn’t be using VB.NET 2005 then. If you change a Sub to a Function it changes the End Sub to an End Function automatically. An excellent solution since it maintains the descriptiveness and removes the pain of having to retype. Win-win!
>> Drop the Dim statement also, at least for variables whose type is declared.
Dim o as Object becomes
o as Object or
Those 4 keystrokes are going to make all the difference. Yeah.
>> Less keywords cluttering up the screen means easier readibility, at least for me.
Time for C# perhaps?
I’m primarily a C#/Java developer but do have to work in VB on occassion. I learned to program with BASIC and did a lot of VB / C++ before .NET came out.
I never liked VB but it was where the money was at back then.
You mustn’t be using VB.NET 2005 then. If you change a Sub to a Function it changes the End Sub to an End Function automatically. An excellent solution since it maintains the descriptiveness and removes the pain of having to retype.
Lotusscript has been doing this since at least 1999… Great to see that .Net is catching up 🙂
thank for the vb coding rfull details
If these are the guiding principles then you would do better to scrap them. VB.NET has well and truly lost its way compared to VB6. You are making all the mistakes that MFC made and C# did so well to ditch. The .NET framework is still the best part of VB.NET.
You’ve wasted the past 5 or 6 years taking us in circles and trashed our existing code that we invested millions in. How do you explain removing features that you then slowly added back in? Scheduling is a poor excuse. Your actions deserve no loyalty from your consumers.
Now in VB.NET 2005 you’re even adding new attributes to the framework to force the VB compiler into doing things that no sane person would want to do and that contradict the VB language syntax making the code unreadable. You even have to add attributes to generated code to stop FXCop reporting violations on it. You show no shame. Pathetic!
You are unwittingyly sowing the seeds to cause a mass exodus to C# and you can’t even see it. Bet your web download stats are showing it though! You sure convinced me. You are also indirectly killing the Windows desktop platform that VB apps so often targetted.
Your principles are more like:
– Confusion (keyword choice)
– Stupidity (feature removal and partial re-introduction, lack of upgrade path, very poor quality releases)
– Pointlessness (My Namespace, operator overloading, partial classes)
– Code Hiding (new attributes and code that appears to have no caller cos its called by "external code" these days)
I can’t wait for your new dev lead to start. Things can only get better.
the other day one of my C# developer friends found himself applying for a job at a VB only camp. They asked him to write a sample application so he comes to me and asks "Damnit, what’s the keyword to override a function? Overloads?".
Naturally my response wasn’t very pleasant at first but the point is that I do not see the keyword choice as too confusing (save Friend, which is totally out of left field).
I think your idea of what any sane person to do is inherently limited. Partial Classes, and Operator Overloading, are hardly pointless. As for My it’s a convenient implementation of the OO Facade pattern. Everyone loves OO until you use it then people talk about how stupid abstraction is.
I do understand you have some concerns. I have concerns about why C# can’t figure out what I intend by passing a property ByRef, or why they insist that I type ref when I call that function. I’m a bit confused why you have to use VB keywords to describe what C# keywords do. I’m confused why they use destructor syntax for Finalizers when they are expressedly NOT destructors. What the hell is a void return? Maybe my mathematics education is lacking but if if doesn’t return a value IT’S NOT A FUNCTION. I was particularly impressed that C# insists on including those break; commands at the end of switch case blocks even though the C# switch doesn’t support fallthrough anyway. They just figured you’d appreciate the extra typing needlessly. And why is it ok that C# has Operator Overloading and Partial Classes and a FAR WORSE upgrade path from VB6.
So you’re upset that there is no upgrade path but then when the VB team introduces things to improve the upgrade path you b*tch about them. You’ll have to excuse me if I think you’re talking out of your @$$, but I was a legacy VB developer for 6 years and I’ve never been happier with VB than since VB.NET so you don’t represent the whole community. By all means run to C# and spare us your "contributions" to the community.
Pingback: Panopticon Central