Randy Holloway at Microsoft

Great, so you admit that we now have TWO dialects of Visual Basic ? So what should the company train its employees on ?

You don't have two dialects of Visual Basic. You have VB 6 and VB.NET, which have similar but not identical syntax and are based on different underlying technologies. If want to take advantage of the CLR, use VB.NET or another .NET language. If you don't, you can use VB 6 or another language.

First, VB.NET and VB are not the same thing. VB.NET isn't "VB 7.0". If you want VB, then use VB 6.

Second, every language in the .NET stable is the same way: VB to VB.NET, unmanaged C++ to managed C++, J++ to J#. What's more, you have a new language, C#, which is what many people are using, having moved from any variety of previous tools (Java, C++, J++, VB, etc.), which doesn't even LOOK like their old tools.

Third, every new version of VB has been a "new dialect". When you start to use features of the newer versions of VB, you must walk away from older versions of VB, because your code won't run any more.

In short, this happens to everybody who wants to move to .NET, but only the VB people whine about it. How does that reflect on the VB sub-culture of Windows developers, compared to the rest of us?

Gods, I'm glad I'm not a VB developer: not because VB was bad, but because the community has nearly as much whining and in-fighting as the Java community.

I don't think you needed to add your disclaimer. In fact, I applaud you as someone from Microsoft saying it plain as day. I get asked quite often about VB6 to VB.NET and my answer is always the same: Yes, they sure do *look* alike in syntax, but that's where the similarity ends. For all intents and purposes, VB.NET is a brand new language built from the ground up to be CLS compliant and to take full advantage of the .NET platform. It just so happens that because the syntax is familiar, a VB6 developer can make the transition a little quicker and concentrate on what they really need to know (the CLR, FCL, BCL).

To me, after quickly reading parts of Joel's article, he just has written a lot of biased crap.

Hopefully the next month's column is better again :-)

"Since when is VB considered to be an application that requires backwards compatibility?"

Since the same time that VC++ is. VC++ users can still purchase a current, supported tool that works with their existing code. VB users, on the other hand, can no longer purchase VB6, and current versions of VB won't compile legacy code. Do you not recognize a double standard?

Some of the early marketing aside, I didn't think VB.NET was ever represented as anything other than what it is. Furthermore, I never understood why it should be anything other than what it is.

I've never understood the VB criers.

I applaud you as well. This post was finally enough to convince my boss that Microsoft doesn't care about VB6 users. No one wants to learn more VB6. VB.net is just as complicated as C#. Moving to VB.net is more expensive than just redoing our entire system in PHP/HTML.

If VB6 and VB.Net are not the same then why confuse your user by using VB as part of the name? You could have pick any other old name. I am sure if you called it something else (Joe Blow.Net) then no one would be complaining about VB.Net is not compatible with VB6. I don't expect VB6 to be able to compile VB.Net code but I do expect VB.Net to compile VB6 code. Does it? I don't know since I don't use VB at all. But from what you wrote, it doesn't seem like it would.

I am sure if I open a company and use the name Microsoft.Hello as my company name, Microsoft would sue my butt off for trying to confuse the customer. Or are you telling me that Microsoft wouldn't because everyone should know that Microsoft and Microsoft.Hello are two separate companies and only cry baby would complain and expect them to be the same?

That response by Anonymous is the whole point of what Joel was saying, I think. In order to move forward from here, developers have to learn something new. The move from desktop API programming to a more web-based thin client programming model means that there is less of a reason for a developer or shop to put their eggs into MS' basket.

If a shop does decide to go with ASP.NET for their web-based programming, Windows is no longer required on the desktop and, for the amount of time that MS allows Mono to exist, Windows is not even required on the server. That is Joel's point and one that I don't think anyone can argue with.

The implication that this is a Bad Thing can be debated, though. Will Mono and thin clients allow the world to slip from MS's fingers? Will developers choose to avoid the WinForms vs. Avalon choice and go with Java? Will Microsoft refuse standards and interop in order to help maintain specialization in the field in order to encourage continued Microsoft-based development?

Those are the questions that you should be debating, not whether VB7 is VB7.

I think most of us who are professional developers on windows have moved to C#.
I think the bigger point which he made and I think is correct is about the Longhorn wave of technologies. In particular why should I write Avalon applications? It won't be on my customers desktops and means I'm either going to need get a compatibility SDK from someone or just plain ignore it for a while. Avalon BADLY needs the equivalent of Win32s.
VB6->VB.NET is just plain tough, fundementally it's an old product running with old technologies, at some point MS were going to have break a few hearts. I've made the decision to go VB6->C# rather than to VB.NET because I prefer the syntax and the temptation to just run old code through a converter is lessened.

I think Joel missed some very key points in his assessment. And I wonder whether part of the reason is that he is trying to justify to himeself his decision not to move to .NET. IMO he failed to appreciate that doing nothing was not an option for MS. MS needed to move forward and provide a development platform that could compete with Java, which was making significant inroads into the Enterpise Development space. Whether or not you agree with Joel that memory management is the key to productivity improvements in virtual machine environments there does seem to be consensus that C#/Java is more productive than C++/COM for Enterprise class applications. Losing developers to Java has more negative consequences than providing an MS alternative. Once you make the decision to go to provide a new development platform, it makes sense to provide a range of languages that allow easy transition for existing developers C->C# and VB->VB.NET. Now I agree that some VB developers may feel that the new platform offers less clear advantages for them than for C developers in the short term. They always had a managed environment, but strategically one platform for MS application developers makes a lot of sense.

Of course the risk is always that the greater the change the more likely that your customers will examine your competitors offerings, but Java was and is a significant competitor.

My anecdotal experience around the city of London is that Windows Forms is growing as a development platform of choice for the client. Click-once will really help that. And where folks are using thin clients ASP.NET is very strong. .NET seems to be winning the client war. IMO the real battle is going to be for the server. On the server Java on a Unix is still seen by many banks as the preferred choice.

Remember Java emerged in '95 and took a long time to gain its current acceptance in Enterpise Application Development. NET will take time too, especially as new development budgets have only recently begun to open up.

A few days ago, the fantastic Joel Spolsky posted a great little article on the death of the Windows API. The biggest problem with this article is that you can't attack the individual writing it. Joel worked at Microsoft for ages and is one of Microsoft's most knowledgeable former employees (certainly one of the more influential). He's fantastically smart and truly gifted. He obviously didn't write this article off the cuff and really believes in what he's saying. The stir from the article has really been 2 sided: the people who agree (I won't posit on the reasons) and those who disagree (duh). In this case, though, Joel's arguments were strong enough that the 'disagree' camp has been fairly quiet, myself included. It just feels like something's missing. Not that Joel's missing the mark, more like a basic premise is fuelling through to a point which is following through to a conclusion which you don't agree with. Along the way are some very good (and valid points) but you just feel like something's missing... That's how I felt, and apparently I'm not the only one. Well, someone else with more cycles than I've got right now took a stab at this, and I can't say I disagree with the premise. Olivier Travers writes this great piece with some good explanations: However, Joel's whole argument relies on a premise that he never bothers to back up: "[the web as a platform] is Good Enough for most people and it's certainly good enough for developers, who have voted to develop almost every significant new application as a web application." After reading Joel's memo, no doubt Epic Games will surely stop using DirectX (gasp, the latest version even) and commit to creating Unreal Tournament 2005 in the browser. Good stuff. It doesn't blow Joel's piece out of the water, but then I don't think it was meant to. Joel's article is great. Has a hundred valid points and needs to be listened to. Most uf "us" just don't agree with his conclusion. Read both articles. It'll grow hair on your chest. Update: I did a piss poor job actually saying my opinion on this topic... Which I realised when another blogger said stuff I didn't agree with. Harry Fuecks wrote a piece: Among many points he mentions how VB.NET doesn't support VB 6 and he concludes by saying; The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing. While this is true (that VB.NET doesn't support VB6), this is something us VB guys are used to. Every version of VB fundamentally changed the way we programmed. This is a big (huge) change, but it's not really all that foreign to us. What I wonder is how ASP 3.0 developers feel about ASP.NET? ASP.NET is software architecture ideals applied, which is great, but I wonder how ASP 3.0 developers, of the type who could care less about OOP and are more...

THANKS FOR THE LINK, THAT SITE IS DYNO-MITE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Frankly I can't find a thing to argue with in Joel's article. Clearly Bill was half asleep the day he approved this change of direction.

I've been assisting a developer recently who has been trying to reproduce an NT Service I wrote years back in VB6 as a C# program. In trying to uncover various code paradigms we've looked at tons of example .Net programs on the web. We're finding that most of them are hilariously convoluted, full of meaningless code fragements and effectively "dead" code, and some just downright don't work under load or except within a single network segment (the latter being mostly socket-based programs). The "skid mark" comments left all over the code by the VS.Net IDE are merely amusing once you get used to them.

Indeed, the "productivity" promised by .Net seems to be limited to ASP.Net applications or simple web service consumers that can operate in blocking mode.

So far I'm having a good laugh, but it isn't *my* deadline that's approaching. Almost makes me glad my primary role isn't as a developer any longer.

Why do people still insist that if your a VB programmer your are less professional than the C# programmer ? They're both based on the CLR.
98% of what you can do in C# you can do in VB and visa versa.

I do agree with Joel in that WinForms seems like a dead end with WinFS coming out.

If VB.NET isn't the successor to VB6, then we can expect a VB7, no ?

In my opinion,

There will be a time when most of the code will run on server computers, i.e. Windows Server. By that time, the Internet connections in our workplaces, houses, and mobile devices will be strong enough for anyone to be able to use Terminal Services successfully to connect to our remote accounts, hosted somewhere (either by our company, or by a Windows Server Hosting Service) and run the code they need on those servers (with many processors, huge memories, etc.) At the same time, the powerful Internet connections will have been conquered all the World (let's say 80-90%) and not only the North America and Western Europe.

I cannot predict a date for this but it will be not now, and not in the the next few years. Maybe not in the next ten or twenty years, but I wouldn't count on that, that's why it's better not to predict a date at all.

However, at that unknown time, Microsoft will probably indeed sell thin Windows clients, or maybe, give Windows clients away for free. They won't count on the client. By that time, all the DirectX games will run excellent on the server and viewed on a thin client through powerful Terminal services AS IF they would have been run locally. (Of course, there is a small problem with this because bits travel at most with the speed of light and if at that time, people will be able to go on the Moon in vacation and try to run games on their Earth-based servers, they will probably reach into difficulties. But maybe matter-copying (and/or teleportation) will be also developed and help us to solve those).

Also, by that time application developers will only be useful if they know the OLD C++, VB or the "OLD" .NET stuff to maintain legacy still existing applications, because new applications frameworks and tools (Visual Studio .NET 2020 for example ;-)) will be smart enough to allow "programming" using natural language and some cool visual tools that we simply can't imagine with current technology and minds. By that time, Application Development will be mostly (let's say another 80-90%) automated. All the classic business problems that are today solved by developers will be solved immediately by powerful frameworks which will be used directly by the "customers" (for example, a non-IT manager can use them because they may "speak" natural language, i.e. directly speaking with them like he or she must today speak with the developer!)

However, I think that Microsoft will not try to stick with the current (rich) type of Windows client forever. As technology will evolve and as the natural moving to the server-side will develop they will move on as they usually do. They will try to get more from the server market. And because of their products integration on the server side, I think that even if struggle will come up, they will win over environments like Linux, which are good in any of one specific directions but not as a integrated whole of directions. And Microsoft will indeed will later need a smaller number of developers (and will fire people or move them to other areas such as content creation, or so) to create their project, but those that have really strong skills should not be fear. Microsoft as a company will evolve and not involve. And they will not do like IBM did: they won't start creating I don't know what phones or so. They will be in the software industrion. For many years. Very many. I'm thinking that my grand-grand-grand children will still be able to want to be MCSDs like me :-)

I forgot to say, but as you can surely tell after reading my SF (?) story, the end of the story is that what the winner is not the rich client of today nor the Web itself. Rich clients contents (applications) will be moved to the servers, and the Web will only be used as a protocol to get to the servers from the new thin clients.

Therefore, I think for the moment, it's natural for Microsoft to invest heavily in things like Longhorn. They will be the future servers. They are currently also investing in Web Services and so because they KNOW that there won't be only their servers running out there. Linux/Unix and others won't die. But in my opinion Windows Server services will get the very much required integration between them, and that's what will sell them on good money even if Linux will be still free.

And I posted an answer for those interested

http://blog.thetechnologist.net/PermaLink,guid,69f0dc60-0898-4825-89ef-e1e62861e8f8.aspx

PingBack from http://hairgrowthproducts.info/story.php?id=4058

PingBack from http://debtsolutionsnow.info/story.php?id=7174

PingBack from http://topalternativedating.info/story.php?id=4963