Partager via

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

  • Article

[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

  • Anonymous
    January 28, 2010
    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.)

  • Anonymous
    January 28, 2010
    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.

  • Anonymous
    January 29, 2010
    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.)

  • Anonymous
    January 29, 2010
    The comment has been removed

  • Anonymous
    January 30, 2010
    The comment has been removed

  • Anonymous
    February 01, 2010
    "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.

  • Anonymous
    September 19, 2010
    @MarkJ...I'd assume because C++ is more efficient and faster than .net?

  • Anonymous
    January 12, 2011
    The comment has been removed

  • Anonymous
    March 04, 2012
    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.

  • Anonymous
    September 08, 2018
    I'm still learning from you, while I'm improving myself. I definitely love reading all that is posted on your website.Keep the stories coming. I loved it!