I notice that Darryl Taft has a very interesting article today over on eWeek asking “Will VB 9 Win Over the VB 6 Faithful?”. I think the headline is a bit off, since the real question is “Will VB 2005 Win Over the VB 6 Faithful?” given VB 9.0’s status as almost-entirely-vaporware at this point. The answer to that question is “yes, definitely, in my opinion,” but time will tell. Only once we know what happens with VB 2005 will we really be able to start talking about how VB 9.0 will or won’t change that new status quo.
There was one section that caught my eye, though:
Will Microsoft’s play to win back developers be successful?
Joel Spolsky, founder of Fog Creek Software in NY, said he thinks Microsoft should keep things simple.
“My impression is that the developers who appreciated VB for its simplicity and easy learning curve have long since given up and aren’t going to be impressed by language ‘featuritis,’ and are certainly not going to be pleased by a raft of complex new language features to learn,” Spolsky said.
“Those who might be excited by something like LINQ are the exact kind of programmers who already switched to C#, or, increasingly, Python. I fear that by adding these complex new language features VB.Net stands to alienate what’s left of its core constituency who just want to get things done.”
This is the downside of announcing these features at the PDC, which is a über-geek conference, instead of someplace like TechEd, which is more of a conference for normal human beings (or at least as normal as programmers ever get). Yes, indeed — if you go and download our VB 9.0 introductory paper, you will be regaled with all kind of cool geeky language features like type inference and anonymous types and query comprehensions! All aimed at the kind of language wonks who are going to be going to the PDC and downloading such papers so they can dissect the semantics of each feature on their blogs. This is fine as far as it goes, but the problem with all this is that then people like Joel start to lose sight of the forest for the trees because they start to think that the average user is going to actually have to give a damn about all this wonky stuff to be able to get their work done.
The truth is that if you go back to the halcyon days of VB 6.0, you’ll find a phenomenal amount of complexity in the language. Just go read a book like this one and you’ll find out just how many complex features went into making simple things work in VB. And yet, all that complexity and featuritis was hidden under a fairly approachable and simple facade that allowed people to, as Joel puts it, “just get things done.” This is really no different. The practical upshot of LINQ is that you’ll be able to take objects that you already work with every day and easily write queries over them. That’s about it. You won’t have to understand the mechanics of anonymous types, lambda expressions, type inference, extension methods, or query comprehensions to make it work. You won’t even have to know what any of those things are. All you have to know is that you can type “Select” and write a query. Something, I might add, that most VB users already have to do in one way, shape or form already. In many ways, the additional semantic overhead for many users should be almost zero.
The only difference between now and VB 6.0 days is that in VB 6.0 days we didn’t go to the PDC and talk about how VB was going to support the new IFoo interface and the new IBar interface and extend ITypeInfo so that we could support this feature and change IDispatch so that we could support that feature. No, instead all those details were relegated (if discussed at all) to C++ sessions about new COM features and VB just didn’t bother to show up. Now, instead of saying “you’ve got to learn C++ if you want to understand how the nitty-gritty of this language works,” we’re just saying, “if you want to know, you’re all adults, here it is.” But, hey, if you don’t care about all the new whizzy language features — and, let’s face it, most non-language geeks shouldn’t — then don’t. LINQ will just work fine and your life only gets easier, not harder.
It’s that simple.
As a FoxPro developer I learned Fox’s implementation of SQL while I was learning FoxPro itself. The simplicity and readability of Select…From…Where was easy to learn.
As you know, some of the inspiration for LINQ came from Visual FoxPro. Having a built-in SQL implementation makes FoxPro life _easier_, not more complicated. It will be the same for Visual Basic, and once everyone catches the vision and gets used to using SQL, they’ll wonder how they lived without it.
Cindy Winegarden, MCSD, Microsoft Visual FoxPro MVP
…company chooses to stick with what is basically VBScript for their main product. They even wrote their own compiler (or some such nonsense) for other OS support. For them language innovation ended in about 1995 with ASP 1.0. Nothing wrong with that but just consider the source when you see the media quoting him.
Well said Paul. Simple indeed 🙂
Incorrect. In VB6 days msft definately did go to conferences and talk about IXXX. Back in 1997 I remember attending a Microsoft VB conference where whole sessions were dedicated to COM and how to trick VB into playing with vtables.
Or perhaps that was my fault for only attending Matt Curland’s sessions…
VB4-VB6 were successful because they mimiced the simplicity of VB1-VB3. I wonder how difficult it would be to create a VB6 shell hosting VB.Net 2005. I reckon you could get pretty far.
I have to agree with Rob here. I love Joel Spolsky’s writing. We use FogBugz at work and it’s perfect for what we want to do.
I just can’t take him seriously when he starts talking about new language features. I mean seriously…FogBugz is still written in classic ASP. CoPilot may be written in C++, but that’s not really their flagship product now, is it?
I’ve been silent on your blog of late and on the entire LINQ feature. I gotta say, with the very bit that we know of so far, VB 9 has a chance of winning me back from C#.
I do worry that the language is getting clutered. I asked Anders at TechEd about the difficulties in balancing features with complexity and where C# stood, and I appreciate it’s a difficult job, but I think maybe, just maybe, it’s starting to look overboard (let’s not forget, there’s still a lot of time to add a lot more features to 3.0).
I understand anonymous types, and lambda expressions and so on (well, I don’t understand why SELECT X is _after_ the FROM in C#) but I think VB.Net can do a better job to deliver it meaningfully than C#. It’s not a matter of understanding, it’s a matter of productivity. No C# isn’t hugely bloated, but it isn’t getting any prettier either.
Thinking about switching to VB.Net makes me think of something I keep rolling in my head. A bad programmer will write bad code no matter what language’s he or she is using. But damnit, there are just more bad VB programmers, and I don’t want to maintain On Error Resume Next or default instances. It’s fine for existing code or old-school vb 6 developers, but throw me a bone and give me a 3rd flat Option Anal which disables all those things that result in lower maintaince. Then you’ll win me over.
The unattributed conclusion that caught my eye was "Moreover, with the Language Integrated Query framework, which lets users program data and access databases for data without having to know or use SQL, Microsoft is delivering even more to developers."
There’s no way that LINQ users can "access databases for data" without at least moderate SQL proficiency, especially for VB query comprehensions that are modeled on SQL syntax.
Karl: I definitely understand where you’re coming from, and it’s something we’re also thinking about for Orcas. The problem is that VB covers such a broad range of customers, we also cover a huge range of coding styles. Some features that one segment loves is hated by another segment of users. We’re thinking about whether there’s some way for users to define a certain kind of coding "style" that the IDE can then enforce. We’re not talking about allowing people to actually change the language, just about being able to say "I don’t want x, y or z to appear in my code." We’re still early, so I can’t say how likely it would be we’d do something like that, but…
Roger: Yes, I saw that too, and I agree. Since we’re going to be SQL-like, it’s not like you can avoid it…
While it is interesting to see language innovations, such as LINQ, one of the main sticking points, that of migrating large VB 6.0 applications to .Net, remains. It is this point alone that has forced our organization to conclude that a complete re-write using replacement technologies is the only realistic solution. Because Microsoft didn’t provide a smooth migration path from VB 6.0 to .Net, like they did for C++, they forced companies to examine their available options and opened the door for competing products.
Regarding LINQ, how does this language feature integrate with ESB based back-end solutions? If the strength of LINQ is to simplify database access but doesn’t provide adapters to platform independent architectures, large corporations cannot seriously consider LINQ as a must have technology.
Overall, technological innovations are to be applauded, but it is critical for Microsoft to guide and support its existing customer base as they attempt to evaluate and adopt technologies. If Microsoft spent as much time enhancing its migration strategies and tools as it did on language extensions, it would greatly improve its image and, perhaps, result in some customer loyalty. In today’s competitive markets, not all companies can afford re-writes of existing, working solutions just to keep current. If VB is ever to regain is popularity, Microsoft must not leave its customers struggling with application migration nightmares.
VB .net is great, I am just growing weary of a new language (or significantly different language) every 12-14 months… makes it hard to become an actual expert.
Of course you can become an "_expert" in the taxonomy of today’s programmers but in order to become an "Expert" programmer where one really comprehends the dimension of the source orchestration… it helps to limit the ‘new versions’ and keep the ‘upgrades’ to a carefully focused minimum.
I’d like to speak to the point about VB2005 winning back VB6 programmers.
Possibly. It seems to be a more complete effort than VB2003 was. Gee, "edit and continue" came back. What will they think of next?
However, VB6 was the last of the RAD tools, where all "VB" since are OOP tools. What VB6 programmer (or any other type) wants to give up his entire code inventory and his entire career skill set and start over as a "stranger in a strange land", absorbing these very real business costs along the way?
Keeping existing VB6 code in VB6 is one answer. Re-writing everything you ever wrote and then re-debugging it is another. I have to ask "Was all this REALLY necessary?"
"Was all this REALLY necessary?"
No of course not!
In fact the switch from QuickBasic to Visual Basic wasn’t necessary.
Keeping up to date with language technologies _is_ tough. One of the hardest things isn’t so much learning the new stuff, it’s working out what’s discardable so you can concentrate on what’s really useful to help you get the job done.
If you don’t want to spend the time keeping up to date that’s fine. I don’t think many of those reading this blog would question someone’s priorities if they said ‘I want to spend more time with my partner/family/friends, rather than working out new language features".
I know all of us would respect that.
But people who come on here whining "oooh it’s too hard, there’s too much to learn, my brain hurts" are doing those of us who’d rather like to be taken seriously as professional developers no favours!
You’re making other development cultures tar us all with the same brush.
Tell you what! Stick with VB6. If you’re not the kind of person who doesn’t want to learn new technology then you’re probably not working on anything that critical.
Anybody working with VB6 on projects that are business critical knows either they’ll need to upgrade their skills or that the existing stuff will be kept in VB6 (sensible idea!) and that there’ll be support work for them if they want it, so you won’t find them on here boring us with their whinging.
Whatever you ‘I miss VB6’ guys do, pleeeeeeease do us a favour and don’t post on here complaining that Bill isn’t looking after you. It’s getting very very very old.
Steve, I appreciate your point of view, even though I don’t entirely agree with it. I will show you the respect that you failed to show me by not insulting you personally and by not impugning your professionalism as a programmer.
I will state that you ignored my central point, which was that these changes entail costs which are – and should be – real concerns to all professional programmers. Dismissing such statements as being "whinging" is a finely reasoned and stinging retort, but ignores the essential reality.
While it is clear that .NET offers many things that were not possible in a non-OOP environment, it is also clear that VB6 was perfectly adequate for many business-critical solutions up to this point. To effectively obsolete such solutions by cutting off the technology which supports them does, in fact, impose costs on the businesses which currently use them.
Leaving solutions in VB6 is viable only for the short term – i.e., until some future direction of Windows causes some aspect of the uynderlying COM technology to break. Been there, done that already; the time frame seems to be shrinking as time goes on.
I have been in the business for quite some time, and cannot be fairly characterized by your statements above as "not wanting to learn new technology" ( I have learned, by necessity, several different sets of development technologies on multiple OS’s so far); nor is it fair to assume that I am not working on "anything that critical". Those sweeping assumptions have no basis in fact, nor did you have any justification nor reason for making them other than wishful thinking.
First up, apologies for the rather harsh tone of my comment, the comments posted in reply to this post caught me at a bad time <sound of embarassed shuffling of feet>
I guess what I should have said was if people are developing smallish departmental apps then they shouldn’t worry too much as those apps can and should stay in ‘classic’ VB.
If these ‘classic’ VB apps are either enterprise size or/and business critical then the decision to rewrite in newer technology is one that obviously should not be made lightly. Any major enhancements/fault fixing unless such a decision is made (normally by people with more clout then us humble coders) could be done in the existing code base.
More importantly I’m can’t see that COM will be removed from Windows any time soon as it’s pretty well intertwined with so much and it’s seems pretty unlikely MS will want to spend time and money changing COM such that it breaks (why do new work on an ‘obselete’ technology).
As for MS’s direct support for developers (things like support incidents etc), I’m not entirely sure how much use those writing enterprise/business critical apps make of it anymore, COM, VB6 etc is pretty mature tech is it not?
There’s plenty of applications based on ‘obsolete’ technology still doing fine out there with no direct support from the ‘manufacturers’, mainly because the apps themselves are mature and so don’t need major work.
TBH apart from the threat of newer versions of Windows losing COM support (which as I said above I’m not convinced is a threat in the medium term anyway) I don’t think I quite get what people are worrying about.
If there’s a factor not mentioned above that I’ve missed then I’d gratefully accept new information!
SD – Thanks for your clarification – I do appreciate it! I see now we have more in common that I understood at first glance.
For my own part, I am not so concerned that MS will do much further work on COM; I have somewhat more concern that development in other and newer areas going forward will have the unfortunate side-effect of breaking COM either in whole or in part…this sort of thing has a history and may in fact be unavoidable, but is a direct result of decisions made to strike out in a new direction rather than to continue to support and improve tried and true working technology.
Aside from the issue of costs which I raised above, I am not yet convinced that .NET is *progress* as opposed to *evolution* for marketing reasons. You may remember that COM was promoted as being the newest, latest and greatest once upon a time, and look at it now!
And while .NET offers the possibility of a programming language seperated from the OS (providing a platform-independent programming language) I can remember when the same claims were made for "C" in the 1980’s. Whether other OS publishers will ever decide to support the 8000 lb gorilla is debatable; I can’t imagine why they would!
But the rest of your statements are well said, and hard to argue with. I guess I’m grumpy because the future route for developers has been imposed and other options substantively removed, rather than having been presented as an option which can (given time) *demonstrate* proven reliability and superiority which would make its adoption a true no-brainer – a genuine "pull" from the developer community rather than a "push" from MS.
Ah, well, we live in interesting times…
Sorry, but the last "VB" was version 6. .NET’s offering should be called , maybe, "B#", since it bears only a small resemblance to the "real" VB.
And having reviewed VS2005, the resemblance is getting smaller all the time. Can’t see how this morphing language will EVER win anybody back, especially all those programmers who were burned so badly by Microsoft’s decision to obsolete all their code and substitute a still-buggy "framework". If we have any sense at all, we’ll be long gone from VB by the time version 9 is released.
VS2005 is, frankly, so bad that no one should be using it for any serious business development; I am sure the propellor-beanie set are all aglow, gasping about the latest and greatest toys from Microsoft (and spewing their usual vitriol against anyone who has the temerity to disagree with them), but if you make your living by delivering solid and stable product to paying customers, .NET simply should not be up for consideration at this point.
In fact, I think you could make a good case that VS2005 is actually worse than VS2003, so if VB9 (just a name at this point) follows this trend, there will be even less of a reason to use it – assuming any "VB" programmers are left by then…