« Performance Counter Blues... | Main | Love the MSDN Product Feedback Center »
February 24, 2005
Grumpy Grimes
Richard Grimes steps down, and has some things to say about .NET.
They say you forget the pain of childbirth. Apparently, you also forget the pain of pre-.NET development. I haven’t forgotten the insane amount of work it was to build a Web site with tables that let you sort and page data. I haven’t forgotten how much work it was to write client-side and server side code to validate form fields. I haven’t forgotten all the cross browser testing that you had to do.
I also haven’t forgotten the pains of VB6. How just adding a reference to a DLL locked it while the IDE was open, making recompiles difficult. I remember how small the available class library was, and how far to often you had to Declare that you wanted to use something in the Win32 API, and how writing multi-threaded VB code was essentially impossible. People called it the glass ceiling. It felt more like titanium, and “Hardcore Visual Basic” existed to drill holes through so that you could glimpse the heavens beyond.
I’m sorry for those who hate .NET because it’s not perfect, but for anyone who says it’s not an order of magnitude better, well, I just don’t know what you’re on. I honestly do wish I had a nickel for everyone who I’ve heard mutter “If I have to go back to VB6/ASP, I swear I’ll quit my job.”
Recently, I have been doing a lot of work in VB6, focusing on VB6 - VB.NET interoperability, because I believe that interoperability, not migration, is the sweet spot. As I move between the languages, I realize what a beautiful thing VB.NET is. It feels like a turbo-charged VB. It’s just a lot of little things. I love that fact that I get this:
Dim x as New SomeObject(Arg1, Arg2)
Instead of the klunky:
Dim x as SomeObject
Set x = new SomeObject
x.Init Arg1, Arg2
The language has been cleaned up like this in just countless places. Maybe it takes a while to get in the groove, but when I’m in VB.NET, I feel like the code is just flying into the IDE. VB6 bonks at me if I type what it considers syntax error, and don’t fix it right this instant! And with what’s coming in Visual Studio 2005, VB6 really starts to feel like it has a hand-crank on the front.
Grimes argues that VB.NET isn’t VB. He’s right in that it’s not VB6, but it’s definitely the next species on the evolutionary tree. I’m working on an article that includes VB6 and VB.NET code, and I realized that it was really important to clearly label the code listings as VB6 or VB.NET, because otherwise you have to stare at the listing for a long time trying to figure out which one you’re looking at. Some people think it’s fun to call VB.NET “VB Fred”, claiming that it’s just not at all the same language as VB6. If that’s the case, then there sure is one hell of a family resemblance.
Grimes also makes the argument that if you’ve going to .NET, you might as well learn C#. Unfortunately, I come into the game with a lot of experience teaching developers who are moving over to .NET. Any other trainers out there, feel free to chime in with your own findings, but I find the experience to be universal. VB6 developers get productive with VB.NET much faster than C#. Honestly, you can get a very long way in VB.NET without learning OO, threading, delegates, casting, etc. With C#, you have case sensitivity, you have to cast everything (which just doesn’t make sense coming from VB6), event wiring in C# is just plain clunky compared to “Handles”. I could go on and on, but if someone says that a VB6 developer will learn C# just as easy as VB.NET, all I have to say is, you’re wrong. I spend a considerable amount of my time on exactly this, and VB6 developers are just up and running a lot faster if they start with VB.NET instead of C#.
In the end, it doesn’t appear that Grimes had one good thing to say about .NET. Nothing good about .NET today, nothing good about where it’s going. Apparently millions of developers (and growing every day) are wrong, they’re deluding themselves, tricking themselves into thinking they like .NET because Microsoft tells them they should, unable to think for themselves. I’m proudly one of them. VB.NET is my favorite language.
Posted on February 24, 2005 at 09:22 AM | Permalink
Comments
on the training:
I find that to be good with .net, you need to be able to read both c# and vb.net. However, which language you use for the 90% doesn't matter a whole lot - it's more important for each person to use what they're productive in.
I've seen some vb6-ers that were better taught c# because they brought less vb6 preconceptions over, and some who were better taugh vb.net because they didn't get hung up on syntax.
Posted by: Philip Rieck | Feb 25, 2005 4:58:15 AM
You are missing the point as to why people are upset and continuing to get upset about VB.NET. To switch over an app from VB6 to VB.NET is as difficult as switching a app from Java to C#. It can be done but oh it is ever so painful.
This isn't about writing new application. VB.NET is wonderful for that it is truly insanly great. What it is about is the real world where people have to maintain existing application. This about a world that has existed before the explosion of the internet and still have to maintain thousands of traditional applications, not asp apps.
For these developers, like me, VB.NET fails and fails miserably. Great for new apps, but for converting and extending the life of the older application it sucks, and sucks hard.
I personally converted a DOS Rocky Mountain Basic application to Visual Basic 3.0, I then converted the VB 3.0 app to a VB 6.0 object oriented setup (to escape the memory limitations of fixed arrays, and to make custom features like reports easier to add.) The conversion to VB.NET more like the conversion from Rocky Mountain Basic to VB3 than from VB3 to VB6.
VB.NET make arbitary changes to the langauge to point where a lot of techniques don't work or work as expected.
For example array bounds, in VB.NET you can't go Dim anArray(10 to 35) as integer. At first I accepted the reason is because the .NET runtime had to support zero bound arrays only for interoperability. But then as time went on and other langauges started to work with .NET that it was an excuse not a valid reason.
There a number of solution that could have been implemented to allow the vb compilier to emit IL that works with array bounds. One I thought of is to have the IL declare an array of 0 to 15, and subtract an offset based on the lower bound anytime the array is accessed. Then note that using array bounds is slower than using 0 to X.
The another is form control arrays. Again it is an excuse not a reason why it couldn't be implemented. I can inherit a control, add a index property, declare an array of controls, use AddHandler in the initialization to get 90% of the way there. But if I do that the IDE starts getting in my way instead of helping me as in VB.
One of the most offensive changes is the change from integer to short, long to integer, etc. This make copy and paste of old vb6 routines unreliable and forces use the cumbersome conversion wizard.
There isn't a VB6 graphic library to wrap around the graphics object. Again I am forced to write my own conversion classes to get the job done.
The vaulted COM interoperatability fails when you try to bring a VB6 Modal form from a VB6 ActiveX DLL and you have to click twice on the form to use a mouse on it. Once to transfer focus to the VB6 form and a second to get on the control you want. However the cursor focus is right and you can start typing right away if intial focus is on a text control.
And despite COM support, VB.NET fails to support global multiuse ActiveX DLLs forcing you to declare a globabl variable of your own.
I am critical because I got this wonderful tool that I can't use because it doesn't support my older applications.
Rob Conley
Posted by: Rob Conley | Feb 25, 2005 7:01:28 AM
Scott - Amen.
Posted by: [email protected] | Feb 25, 2005 12:23:24 PM
In response to Rob, I 100% agree that migration of all your VB6 code is not the answer. I call this the "migration myth". I don't think that most VB6 code should be migrated. If it works fine in VB6, then leave it in VB6. However, .NET gives you lots of functionality for free that (and this is the important part) you can completely use from an existing VB6 application. This is the sweet spot, as far as I'm concerned.
Posted by: Scott Swigart | Feb 25, 2005 1:48:05 PM
> I’m proudly one of them. VB.NET is my favorite language.
I agree with you, but unfortunately VB.NET is not *Microsoft's* favorite language, and it shows.
Guess how many lines of Enterprise Library code were written in VB.NET? Zero. If Microsoft doesn't think VB.NET is a worthy Enterprise language, who am I to disagree?
Posted by: Jeff Atwood | Feb 25, 2005 4:22:33 PM
I'm agreeing with Phillip here.. asking a developer to get management to shell out a couple of grand just so they can start writing their apps in .Net is just crazy. .Net is good for... The "Net". Desktop apps need a responsive platform to run on. Not one that's a layer on top of an existing OS. A buggy layer on a potentially buggy OS and a very buggy IDE. Who cares if the IDE has everything but the kitchen sink. It's all stripped down crap designed to put the smaller companies out of business just like their backup/defrag/etc/etc apps did. None of them are worth the disk space they occupy but they were just enough to convince Joe Newbie that he didn't need to buy real software to do those chores.
There are bugs in the .Net IDE that were killed in VB2.0... now they're back! As far as the languages go, it's all "bread and butter" for the contractors since they're starting something new fairly often. For the corporate developers, it's a nightmare. They're stuck trying to get .Net to get along with their legacy code for no apparent reward in the end. All they get is 26mb min installations with up to 90% slower screen refresh rates. This might not matter for web programmers (which is what .Net is really for) but desktop programmers think it sucks.
Posted by: Jim Beam | Feb 25, 2005 9:06:03 PM
Just a rant...
Call me whatever..., but how come we didn't hear people complaining during the VB6 days about MS not writing things in VB? We just "assumed" that MS would use C++, and no one cared. But now, my God, they're using C#! Of course they are, just like VB6'ers are using VB.NET, C++'ers are using C#. What do you expect? An acorn to grow into a pine tree?
And why in God's good name does everyone complain about the VB6 --> VB.NET upgrade path? We all know it's a load of cr*p by now. Get over it. No one demands all the C++ apps to be upgraded to C# right? I don't hear anyone whining how C# is now just Visual C-Fred. The only reason VB6 _might_ be easier to migrate is because it was more like managed code in an unmanaged world than C++ ever was. VB Runtime anyone?? And people complained THAT was big? Give me a break... Perhaps .NET really IS the next version of VB, and C# was just added so the C-family folks didn't go running home crying because they had to program in, dare I say, Basic? If .NET was a VB only thing, it would have been deemed unworthy by the anti-VB crowd, no matter how good it was. All the "real" developers would still be using C++... just like in the VB classic days. So, I wager to bet, that if the VB Runtime had "allowed" a C style language, VB would have garnered respect? I wonder...
I don't know, perhaps I live under a nice cozy little rock, but it really gets tiring listening to all the b*tching and whining in this industry every time VB does something good. It's time for that small, but annoyingly loud group of anti-VB protesters to put away their signs and just GO AWAY and let us get some real work done! VB has and always will be a HUGE success. Too bad for you. We like VB and no matter how much you try to denigrate VB6/VB.NET and brainwash us, we're NOT switching to C#. If you think for a minute that the teeming millions of "non-CS degreed corporate duhvelopers" as we're called, that are churning out REAL business applications that provide REAL value, give a rat's a33 about the academic purities and so called "advantages" of C# over VB.NET, then you really have to get out of the basement more. What matters is getting the job done efficiently, cost-effectively, on-time and within budget. Oh yeah, and making sure we have time left at the end of the day to spend with our families in this thing called "life". Not sure about you, but my little 10 month-old son is the best "framework" I've had the pleasure to play with yet!... ;-)
Posted by: Leigh Kendall | Feb 26, 2005 5:56:16 AM
You are happy about that one-liner? Seems you never had a look at Visual FoxPro:
x = CREATEOBJECT("SomeObject", Arg1, Arg2)
And we have this since, uhm, 1995 or VFP 3.0. In other words: There is a true OO alternative available from Microsoft for those who need a powerful, mature (read: without zillions of bugs) development system, which is not aimed only to the enterprise needs, but more for the small to midrange level. Easy Xcopy deployment? VFP has this since the beginning. No needs to register anything. Just copy your EXE plus two DLLs onto your box and there you go. Don't want to wrack your PC with a 2Gb Visual Studio install? The whole VFP development system fits onto a 16Mb USB stick.
Data-engine? Already included and much faster and more powerful than the rest in that area (Access, MSDE etc). ODBC, ADO, OLEDB, XML, WebServices? All included.
In Short: There's no "You MUST convert to DotNet", you have other alternatives, especially since DotNet is just plain overkill for a regular Desktop application.
See http://msdn.microsoft.com/vfoxpro for more info.
Posted by: wOOdy | Feb 26, 2005 6:42:03 AM
"This is the sweet spot, as far as I'm concerned.'"
What will you do when they break your existing VB6 code because they don't have to maintain compatibility any longer due to the fact that support for VB6 has ended (did you know that support for VB6 is about to run out?)?
You have **still** missed the point which is, there is no viable path forward, short of a total rewrite, for existing VB code assets. Your statement about leaving VB6 code in VB6 shows that you are just as clueless as MS is on this issue.
Posted by: Bryan | Feb 26, 2005 8:52:01 AM
Scott,
I share your overall sentiments and have been preaching the same ideas on VB migration for a long time. I discuss this issue at length in this recent intereview at www.devsource.com/article2/0,1759,1767213,00.asp
Posted by: Jackie Goldstein | Feb 26, 2005 9:59:01 AM
In respnse to:
"I agree with you, but unfortunately VB.NET is not *Microsoft's* favorite language, and it shows.
Guess how many lines of Enterprise Library code were written in VB.NET? Zero. If Microsoft doesn't think VB.NET is a worthy Enterprise language, who am I to disagree?"
First, Microsoft writes almost all of it's internal line of business applications using VB/VB.NET.
Second, Avanade - not Microsoft - worked on, polished, and wrote a great deal (if not all) of the Enterprise Library so to say that Microsoft made some decision that they use C# instead of VB.NET is largely inaccurate.
Posted by: Alex Lowe | Feb 26, 2005 5:24:41 PM
In response to:
------------
What will you do when they break your existing VB6 code because they don't have to maintain compatibility any longer due to the fact that support for VB6 has ended (did you know that support for VB6 is about to run out?)?
You have **still** missed the point which is, there is no viable path forward, short of a total rewrite, for existing VB code assets. Your statement about leaving VB6 code in VB6 shows that you are just as clueless as MS is on this issue.
----------------------
I'm a little lost here. What exactly do you think Microsoft is going to do to break existing VB6 applications? VB6 apps are going to continue to run on today's and future operating systems for as far as the eye can see.
Yes, I'm well aware that they're ending support for VB6, but let me ask you this, how much VB6 "support" are you actually using these days? My guess is, it's been a very long time since you've called PSS with a VB6 question.
There is a migration myth. Look at C, COBOL, FORTRAN, Pick BASIC, you name it. There are many "obsolete" languages with truly staggering code bases out there. Also, more code is written in those obsolete languages every day.
Microsoft can stop supporting VB6, they could yank it from MSDN, and it won't make the VB6 code base stop running or go away. It's going to follow the same trend as with every other language. When it makes sense, some of the applications will be rewritten using new technologies, and for some apps, they will be extended using VB6.
Now I'm not saying that you should embark on a new large development effort using VB6. What I am saying is migrate your VB6 code as it makes sense, with some code never migrating. Extend your VB6 applications with VB.NET (You can use 100% of the .NET Framework from VB6 with some really simply wrappers (often 1 - 10 lines of code)). You want your VB6 app to call a Web service? Trivial. You want to use Regular Expressions in your app? Simple. You want to use the Appication Updater Application Block to have your VB6 application know that there's a new version available, and automatically download it? Piece of cake. When SQL Express comes out, you can use it, from your VB6 app, in place of MSDE or Access, and have Access-like features, like the ability to connect to a database by just giving it the path to the MDF file.
That's my point. Keep VB6, but use all of .NET from it. At some point, it will make sense to rewrite apps, and (IMHO) .NET is a logical thing to rewrite them in. There's nothing new here. When VB6 came out, I remember people saying "it's time for us to rewrite this and get it off of PowerBuilder.
Posted by: Scott Swigart | Feb 26, 2005 9:13:43 PM
"Microsoft can stop supporting VB6, they could yank it from MSDN, and it won't make the VB6 code base stop running or go away."
Until your users run a Windows update one day and it introduces new "features" that break VB6 code. That is the other side of VB6 support, that they will fix things in either the VB6 runtime or the OS that become broken which, after support is dead, they don't have to do.
You may trust them to maintain compatibility but you sound like an MS shill so, I guess you would. I sure as hell don't.
Posted by: Bryan | Feb 26, 2005 10:39:59 PM
Maybe you're right. Maybe we don't need VB.NET (Properly called Visual Basic 7.0, 7.1, and soon 8.0)
Perhaps we do need a Visual Basic 6.0 2.0
Well then again, maybe we should have stuck more with a Visual Basic 3.0 5.0. Win16 Anyone? But still I think QuickBasic 1.0 14.0 would keep my existing QBasic codebase from getting broken. Who needs C# when we can just work in Pascal 17.0b or hell, let's just improve x86 Assembler and stop fiddling with all these new fangled "Languages" that won't "compile" on my Commadore64.
One the other hand let's look at it more honestly. Microsoft should have taken VB6 given it object-oriented capabilities as far as implementational-inheritance.
Cleaned up the syntax as bit, especially with the Property Get, Let and Set stuff. Maybe add some neat shortcuts like assignment operators &=, +=, etc. Even though they're really just multiplying by a power of 2 we could use those > operators from C++.
Hey, you know what would be good? If we could do free multithreading.
You know sometimes, rarely, I wanted to dynamically instantiate controls. But how would I hook up the events? Need a little clarification on this event business, kinda reminds me of function-pointers. I guess with these new processors I'm gonna want 64-bit integers. Let's call them Longer.
Anyway I guess what I really want is to kinda improve the COM model a little bit, there are some things I might like to make my code more elegant. Parameterized Constructors, maybe static members. Enumerations are a neat little trick. Oh and god I need a way to keep from running into all these name collisions.
You know I like VB but there are times when I gotta duck out of it. Like Console applications, Windows Services. And web applications are ok, but VBScript feels limiting to me.
While I'm at it I'll tack on some neat-to-have libraries I've noticed out there like RegularExpressions and serialization. Ooh crytography, yeah, need some of that. This SOAP thing seems interesting. XML has potential. While I'm at it stream based File I/O might be neat and a lower level interface for that damned WinSock control. Finish it off with some tweaks to the visual editor, maybe and improvement in the menu editor. Support for UniCode so I can localize. Disconnected DataBase access? I guess that could be useful.
Well now that that's all settled the only major problem I have with the language is that it's limited to Windows. Wish Microsoft would let the cat out of the bag so it can work on some other platforms.
I think that's a suitable VB6 2.0 but a really crappy name. VB 6.1, no no, VB 7.0? I guess that's the logical next step. But I need something to emphasize all these new perks. I'll Call it Visual Basic 7.0++ on COM+2.0
What's that? COM+2.0 has been renamed to .NET? Hmm, oh, okay, Visual Basic .NET it is then.
Posted by: Anthony D. Green | Feb 27, 2005 3:32:39 AM
"In the end, it doesn’t appear that Grimes had one good thing to say about .NET. Nothing good about .NET today, nothing good about where it’s going."
Is this the only article I have written about .NET that you have read? Take a look at my site and you'll see that I have written many, many articles pointing out the good parts of .NET. I was pointing out worrying signs about the direction that .NET is moving.
Posted by: Richard Grimes | Feb 27, 2005 7:09:19 AM
Blog link of the week 08
Posted by: Daniel Moth | Feb 27, 2005 3:35:03 PM
> First, Microsoft writes almost all of it's internal line of business applications using VB/VB.NET.
Such as? All the internal MS .NET projects I know about are C# -- MCE, Team System, etcetera.
> Second, Avanade - not Microsoft - worked on, polished, and wrote a great deal (if not all) of the Enterprise Library so to say that Microsoft made some decision that they use C# instead of VB.NET is largely inaccurate.
Whether it was MS or some company subcontracted by MS makes no difference-- the message is clear. You want the best Enterprise code? You want C#.
From reading blogs over the last 6-8 months, I get a palpable sense that VB.NET is rapidly ceding its reputation as the "development language for millions of developers" to C#.
I also read recently that VB.NET books don't sell as well as C# books. Yet more evidence.
Posted by: Jeff Atwood | Feb 27, 2005 9:00:11 PM
Screw "the message" Microsoft sends. Think for yourselves people. We're on a common framework with a common type system and in 99.9% of cases common ability. The MS devs decided to do what they did in C#, if you know both languages then you know that more likely than not that application could have been written in VB.NET just as easily so what message is there?
If everytime someone writes a .NET "Hello World!" application they do so in C# and you know that you can write the same app in Basic does that really "send the message" that the best "Hello World!" applications have to be written in C#?
Check the net sometimes, anyone with a 2nd grade education can write a Basic C# converter.
There is no evidence of anything. Most people are right-handed (at least in the USA) does popularity really translate into superiority?
Hath not a VB coder reference types? Hath we not namespaces? When you prick us do we not RaiseEvent Me.Bleeding(Nothing, EventArgs.Empty)?
Posted by: Anthony D. Green | Feb 27, 2005 10:08:49 PM
>>From reading blogs over the last 6-8 months, I get a palpable sense that VB.NET is rapidly ceding its reputation as the "development language for millions of developers" to C#.<<
Jeff-
Reality check...
What percentage of "average" corporate developers, you know, the ones that probably make up 80%+ of Microsoft's programming revenue stream, do you think write blogs, let alone actually read any?? I would venture to say maybe, *MAYBE*, 5%?? As a consultant, this is the marketshare I work with, and most don't even know what a blog is for cryin' out loud. So when I hear the vocal majority of MS-tools bloggers spewing C#, it really doesn't worry me too much. This is NOT the "real" world of programmers as much as they may think they are, it's really a very small minority. And of that small subset, a good majority are speakers, authors or work for MS etc. This is why I always find the likes of Scott, Rocky Lhotka and Billy Hollis refreshing in a sea (no pun intended...) of C# voices.
Posted by: Leigh Kendall | Feb 28, 2005 7:13:06 AM
Back in the day when there were less than 10,000 computers in the entire world and the vast najority had the IBM label on them, IBM introduced a new line of computers - system 360 - that was totally 100% INcompatible with their previous major line, the 1401.
IBM damn near lost every customer for that little move, to the point that they promised to never do that again.
Looks like Microsoft did the same thing with VB.NET, breaking any FORWARD compatibility for VB6, where the VAST VAST majority of MS' (clients) development programmers exist(ed?).
That there is bitterness throughout that group is completely understandable. That those who manage (read: PAY) those programmers are equally bitter should not be a surprise.
It's real easy to spout drivel like "get over it" and "get with the future" and "so leave it in VB6", but none of that crap solves the problem!
That VB6 developers and shops were left high and dry will be a blight on Microsoft forever and has no doubt also precipitated the slower than expected adoption of .NET. Technical zealots bask in .NET and tout its bright future while those in the trenches suffer yet greater pain as Microsoft pays less and less attention to VB6 and its ilk.
Posted by: Jim Nelson | Feb 28, 2005 12:01:39 PM
Why should the VB6 people be treated any different than say the c++ people. They are not forced to convert c++ code to c#.
The problem of the lack of support for VB6 is that a serious VB application doesnt' exist in isolation. It relays on other libraries, and technologies like database access, directX, etc. So while our existing too may be not be broken at first we will steadily loose access to newer tech as microsoft pushes on with .NET.
Now what I am asking for is not to hold time still. But give me a complier that will take my foo.cls, foo.frm and compile a .net application out of it. That will allow me to reference .NET libraries.
There is no good technical reason why this can't be done. When oddball languages like ML are being ported to use .NET and emit IL, what is so hard about taking the bits of text of VB6 and generating IL from hit.
Is really that hard to map picMyFoo.Line (10,10)-(100,10), vbBlack to the equivalen graphis call?
Posted by: Rob Conley | Feb 28, 2005 12:53:50 PM
> Hath not a VB coder reference types? Hath we not namespaces? When you prick us do we not RaiseEvent Me.Bleeding(Nothing, EventArgs.Empty)?
OK that made me laugh.
> So when I hear the vocal majority of MS-tools bloggers spewing C#, it really doesn't worry me too much. This is NOT the "real" world of programmers as much as they may think they are, it's really a very small minority.
Do you think so? When I see an author posting that he doesn't write VB.NET books any more because publishers are telling him *VB.NET books don't sell*, that's seriously disturbing.
> This is why I always find the likes of Scott, Rocky Lhotka and Billy Hollis refreshing in a sea (no pun intended...) of C# voices.
I agree, but my concern is, I am starting to see much evidence of a "sea" of C# *programmers*. (No pun intended.) The VB world always had that one strength: numbers. Sure, snooty C programmers may have thought VB6 was a toy language, but who could argue with millions of productive developers? Now, in the .NET world, I'm questioning whether we even have that!
Bottom line, if you want the most online code samples, if you want the best support from Microsoft, if you want to contribute code to the most significant .NET open source projects, you want C#. Now WE, as VB.NET programmers, are in the minority.
And that hurts.
A lot.
Don't get me wrong, I'll still do VB as I have for 10 years, but the hard evidence of this ongoing change is difficult to deny.
Posted by: Jeff Atwood | Feb 28, 2005 10:16:25 PM
>>Do you think so? When I see an author posting that he doesn't write VB.NET books any more because publishers are telling him *VB.NET books don't sell*, that's seriously disturbing.<<
I don't know... I mean, perhaps it's because so many VB6 developers haven't moved over yet? Did you see this interesting post by Dino Esposito?:
http://weblogs.asp.net/despos/archive/2005/02/16/374175.aspx
Anyhow, not to bash my own, but I don't really think your typical VB developer is as enthusiastic about embracing new technologies, let alone sitting down to read through technical books. I see it a lot; VB'ers that just don't want to RTFM. Not that I'm a book hound, but I do believe in the value of *quality* books and I always take note when visiting new developers to casually peruse their bookshelves to see what they've been reading. What books they have, do they use the MSDN docs, what trade rags etc. I think overall the C#/C++/Java mentality is just more into this stuff. Is it the educational background or just that they are more technical and VB'ers are more business oriented and just want to get the job done without really caring how? Don't forget, there were a lot of those types (C/Java) also doing VB6 back when and thus perhaps driving some of the VB6 book sales. So, I think it may be a combination. I still contend however, that the majority of VB6 corporate development will stay in the VB-syntax world. I mean really, I can't tell you how many VB'ers I've met that just don't like JavaScript. I can't imagine C# sitting to well with them then. I could be way off, but only time will tell...
Posted by: Leigh Kendall | Mar 1, 2005 4:48:53 AM
Well here, I'm a VB.NET dev. I worked in VB6 for more time than I have in VB7.1. I've made the transition and despite their irritatingly habitual silence, other have.
Where did we stumble and what did we accomplish/overcome that our colleagues in legacy VB are struggling with? Did we accidently bypass these pitfalls? Did we have more help than they have now? What is it about the two groups that seperates them?
Posted by: Anthony D. Green | Mar 1, 2005 3:01:39 PM
C++ to C# ? That's a serious downgrade in my book any day.
Posted by: Bill | Mar 7, 2005 5:33:43 AM
The comments to this entry are closed.