Req0: Don’t add to (or change) the language


[This post is part of a series, “wish-list for future versions of VB“]



“What is this progress? What is the good of all this progress onward and onward? We demand a halt. We demand a rest … an end to progress! Make an end to progress! Make an end to this progress now! Let this be the last day of the scientific age!” [Things To Come, 1936]



“Progress is folly, and unrestful, and dreary. Scientific inventions are perpetually changing life for us — you make what we think great, seem small; you make what we think strong, seem feeble.” [ibid]


IDEA: Don’t add to (or change) the language. There’s a good argument to be made that we should just take a rest from changing the Visual Basic and C# languages. As users put it bluntly, “don’t add new things; just fix what you already have.” The quotes above are from the 1936 film “Things To Come”, written by H. G. Wells, and express the same sentiment.


SCENARIO: A new version of the language comes out, and every single user is put through the hassle of upgrading their projects even if they don’t WANT to use any of the new language features.


SCENARIO: You switch to the new language, and use new language features, but now you can no longer share your projects or code with colleagues who haven’t yet upgraded.


SCENARIO: The language has new features, so you have to invest in updating your own skillset, in writing new coding guidelines for your team, in updating your books.


SCENARIO: You frequently go to the web to find “best practice” code snippets. But now, in the light of the new feature, the code on these web pages is now only “second-best-practice”.


Also, there’s the argument that languages get creaky once you try to fit too many things into them. BASIC has already changed radically: it started as an unstructured  language with GOTOs, then became structured with Subroutines, then a Rapid Application Development environment with Visual Basic, then became object-oriented, and then became partway functional with lambdas and LINQ, and partway declarative with XML literals. (Yes you can still have a GOTO inside a lambda!) Sometimes you just lose the original elegance of a language.


If we go a release without adding new language features, then the compiler team would be free to spend its efforts on performance, refactoring our codebase, rewriting it from C++ into VB, and making it better able to support IDE features like refactoring and compiler-as-a-service.


 


Here is the counter-argument from “Things To Come”:



“Rest enough for the individual man – too much, and too soon – and we call it death. But for Man, no rest and no ending. He must go on, conquest beyond conquest. First this little planet with its winds and ways, and then all the laws of mind and matter that restrain him. Then the planets about him and at last out across immensity to the stars. And when he has conquered all the deeps of space and all the mysteries of time, still he will be beginning.” [ibid]


The rest of the counter-argument consists of all the individual ideas that I’ll be blogging about in the coming weeks.


One thing we’re conscious of is that users see .NET as a “happening” platform. They trust VB and C# (and now F# and IronPython) to bring them innovation and stay on top of future industry trends. They are reassured that their .NET investment is not a dead-end.


 


Provisional evaluation from VB team: This is a decent idea, one that we should consider against the other decent ideas. What do you think? Please blog or comment with your thoughts.

Comments (9)

  1. Kyralessa says:

    Inline XML was a pretty big change to the language, but I think it was a great one.  Most of the changes I’ve seen in VB and C# are additions, new and better ways of doing things but leaving the old ways still working as well.

    I say, change away!  Each change saves me time and trouble when coding.  (Inline XML in VB made me able to stomach XML for the first time in my life.)

  2. Reinier Post says:

    There is a big difference between extending the language compatibly (which only has an impact on programming as soon as someone chooses to use a new feature) and breaking compatibility (meaning existing programs must be modified to run again).

    However the effects can be mitigated with conversion routines.

    If you break compatibility but you provide a 100% correct 100% automatic conversion from old to new, upgrading becomes simple.  You can even provide backwards conversion to allow the programmers to treat the new features as 100% syntactic sugar.

    Conversions can help in the introduction of new features in general.  Provide converters that take existing code and convert it into using the new features.  I don’t expect the VB team to develop refactoring tools but you might help in certifying the 100% guaranteed correctness of particular refactorings proposed by others.

  3. MarkJ says:

    I totally agree with Reinier Post. Either provide 100% backward compatibility or provide a 100% correct and 100% automatic conversion tool.

    Hmmm… slightly off-topic, but can we have 100% correct conversion for VB6 code please? (Hint – buy VBMigration.com or Artinsoft.)

  4. AJ says:

    Is it too much to ask (from one of the most profitable, resource-rich companies in existence) to have both?  Continue to add new features to the language that extend its capabilities and broaden its reach, but invest the necessary resources into improving performance and stability?  There are still bugs hiding in the framework that smell of a lack of testing, and I believe .NET would much more widely adopted if its performance was a little snappier.  

    I don’t expect performance on a level with C++ assembler-optimised native EXE’s, but I’m certain a bit of innovation and research could bring .NET code in line with with native in many areas.

    Maybe Microsoft need to start eating dog-food and write some of their major money-winners in .NET?  Why is Office still C++?  Ditto the Windows shell?  The basic utilities such as Notepad and Calculator?  .NET’s been around for nearly 10 years now, yet its creators aren’t showing enough confidence in it to truly inspire the rest of the development world.

  5. Bob says:

    I think improvement and change are necessary, but as much as possible should be done by expanding the capabilities of the ecosystem (libraries) as possible.

    That said, from time to time breaking changes are a necessity as well.  When they are as radical as the change from VB6 to VB.Net were though you are going to create a lot of pain.  There is no way around this and conversion aids can only do so much.

    "Breaking level" changes between .Net releases to date are not bad, but they come too frequently.  Decision makers have not been generous in the allocation of resources for upgrading existing applications – even when the changes are far from draconian.  In many cases they won’t even spend on updated tools, let alone the time for developers to get up to speed on the new tools and language changes.

    Eating your seed corn?  Ceding competitive advantage?  Yep.  No question.  But management philosophy is driven by such cannibalism, hoping to escape the island before becoming dinner themselves.

    Change (if not always progress) is necessary.  But it needs to be managed if Microsoft expects to play in the Enterprise space in something besides a supporting role.

  6. MarkJ says:

    "Why is Office still C++?" Because it cost some tens of billions of dollars to write Office, so my guess is it would cost billions to migrate it to .Net, and the return on investment would be tiny.

    Why are decision makers not generous in allocating resources to upgrading applications? Same answer, poor return on investment. By the way developers should read "there was a poor return on investment" as "company now in trouble, I am now unemployed". Be grateful your decision makers keep an eye on the money, it pays your wages.

    Why are many of the applications I work on still VB6? Same answer.

  7. mill says:

    @MarkJ…I'd assume because C++ is more efficient and faster than .net?

  8. Madness80 says:

    As a server admin, I prefer VB because I can write ASP, ASPX, VBS, HTA, EXE, and Excel macro's all in essentially the same language. I am not a full time developer, but I have a need to occasionally write code.

    Every time some new product guy comes up with the next "brilliant idea", I get forced into playing "Where's Waldo" with your products. I know what I want to do is in there somewhere, I just have to waste time trying to find it. Could be a new menu structure, or some new function, or a new command line switch. Mstsc /admin, I mean really, why couldn't you just leave /console in there and honor it. Or schtasks /v1, if I'm on Win7 and need to schedule a task against W2K3, couldn't you just create the task as needed instead of forcing me to add another switch? Or at least tell me that I need the switch instead of giving me some obscure account creation error.

    I don't think that MS appreciates the fact that out in the real world, we're running businesses. I don't have the time to continue relearning the tools I need to do my job. And it's the little things that are killer. Did you really need to change winmsd to msinfo32? Why? What was wrong with just leaving the name alone? We already knew it was there.

    What I would like to see is MS take a stance and review every change. The very first question should be about compatability with prior releases. What does it break? Is it absolutely necessary to make the change? Is there any way to mitigate the productivty that will be lost by the millions of users who now have to adjust to the change?

    Back to VB…if you do change something… please be consistent. Please give me ONE VB language that I can use in Excel, VBS, ASPX, etc.

    Thanks for listening (I hope).

  9. weitzhandler says:

    Unagreed in every aspect.

    Languages should be upgrade as long as there are no backwards-incompatibility changes.

    Those jerx who dont wanna upgrate should stick the old versions.