VB6->VB.NET Transition, Philosophical 2

[dilettante]

I was reading JohnK's thread in VB Pro and I don't think he got what he was looking for. I'm not sure the other scattered bits on the topic of VB.NET got to what he was interested in either.

VB Pro is a good forum to discuss the topic, since it affects serious VB developers more than prospective VB.NET developers. But rather than have it scattered here, there, everywhere I decided to add my 2 cents here.

Organizations doing serious VB6 right now face a dilemma. There probably will not be a VB7 in the sense some might like. So it's stay or go (to .NET).

Like it or not, VB is the PC equivalent of Cobol in many ways. It lets a lot of hacks in the door, but it also permits a skilled developer to crank out a lot of code on a tighter timescale than C++ or Java when it fits your problem-space.

A lot of people predict a shift from VB to C#. In part this is because VB.NET seems to introduce enough complexity that "you may as well write C#." I'm not so sure.

C# introduces some new things, but many of these are just the .NET framework and not C# itself. In many ways C# is just a replacement for VJ++ in the aftermath of both MS's and Sun's dirty-dealing and counter-dealing. How many VBers that sell their code actually went to Java?

My own prediction is that some mature VBers will go over to C# - some for good reasons related to capabilities, others for poor reasons, like dissatisfaction with VB changes. VB hacks will try it here and there, but will mostly come back. The bulk of serious VB developers may look at C#, and even use it for things here and there - but in general will make a gradual move to VB.NET along with their C#. After all, VB6 won't die off for about two years - and look how much VB5 is still being cranked out and maintained.

I think a couple things will force a change to .NET, whether VB, C#, or managed C++:

* Client/server developers are being pressured to do something about "rich-client" (fat client) deployment headaches. .NET addresses this to some extent.

* OS's beyond XP (NT 5.1) may offer diminishing support for COM/DCOM.

* Script and ASP developers will have to move to .NET languages like VB.NET as VBScript support drops off. Some people limping along with VBScript will have to turn to VB developers (or turn into one themselves). That VB will be VB.NET, not VB6.

The transition to VB5 was tough too. Maybe the difference here is that C# and Java offer alternatives that weren't there four years ago.

A move is unavoidable - the questions are when and to where.

Opinions?

 

[chiph]

I think a move to .NET is inevitable. Just not this year, and maybe not for most of next year.

A good comparison is the transition from VBXes to OCXes. You had a mature technology that people understood and were making a profit from, and here comes this new thing that MS promises is "bigger and better". It was greeted with some skepticism at first, but as we now know, the VBX developers who didn't make the switch are now out of business.

Convincing the corporate managers to switch is a different issue. Right now, they're correct in not switching. I wouldn't build a product around the .NET beta either. But by October or November, plans need to be in place for changing all new development over to .NET. and placing existing VB6 code in maintenance mode.

Chip H.

 

[srikanth80]

what is that SOAP(simple object access protocol) all about

 

[dbleyl]

hi,
I agree that the move will be inevitable. But for who? I recently saw a job posting for a C# developer and one for a VB developer with definite .net experience.

If you have a lot of experience with VB, VB.net may be the way to accentuate your experience. Rather than stopping cold turkey and switching to C# or Java. If you are tired of people rolling thier eyes at you when you tell them that you are a VB programmer, you will choose C#.

I'm trying to keep up with several baskets: focusing on C#, keeping up with Java, maintaining C++ and learning enough VB.net to be dangerous.

--Don

 

[chiph]

Wow, Job postings for .NET experience already? Probably want "2-3 years experience", too! LOL

I think the emphasis is probably going to switch from "Oh, you know C" or "You're a VB guy", to "Say, do you know .NET?" Having .NET framework knowledge will probably be more important that knowing the particular syntax of a language. Already I find myself saying "How did they know that was in the .system class?"

Unfortunately, I haven't had time to play with VB.NET since I got the beta. I really want to, it's just that my day job is in crunch mode.

I'd like to set up some kind of collaborative effort here -- maybe building the classic "CD Collection" application. It's been discussed before that the FAQ area can be used for this. Or, Dave will set up a private T-T site for us if we pay him enough money.

Chip H.

 

[dbleyl]

It didn't say how much experience, but I bet your right. Reminds me of the VB positions that stress UNIX experience.
Is there something covert going on over there? 'We write all our VB code in emacs. IDL too. If you are a vi guy, there's no future for you here.'

I think you're right about the framework: The CLR is going to be where it's at. Languages just become implementation details.

Anyway, a collaboration would be really cool.

You should post a call for project ideas.

 

[dilettante]

Project ideas? Hmm... well, obviously the first things people wil want to do is reimplement something they understand, to catch the "flavor" of things. But is that the way to go?

Seems like we need projects that are... "Dot-Netty" whatever that means. Maybe we need to start lists, like "what makes Dot-Net a new thing" and "how the new VB helps VBers?"

Sounds like a new thread from here.

 

[dilettante]

Oh yeah, 2 more cents:

What about a simple TCP/IP head-to-head game like checkers or something with text chat. This could demonstrate .Net deployment and SOAP or some such transport in peer-to-peer fashion. Boring, but something to start with.

 

[dbleyl]

I say forget about the Hello world or Data Access Objects projects and go for something .nutty.
How about a project management program that handles Configuration Management issues like version control, concurrent releases, code library, Project planning, etc? A life-cycle development tool.

It could be a tool for used for future collaborations.

 

[SimonG]

I am unclear as to all the fuss many people are making of the switch to .net. To me it seems blindingly obvious that this is the way forward. Ok there is an issue for system architects in that there is a definite dividing line between existing applications and .net applications. However, I have been developing vb.net since the first release of beta one and have had little difficulty in transferring from one VB6. The biggest hurdle I have found if the rewrite of the ADO object model, but aside from that the programming language enhancements and other advantages to the VB developer are numerous, far outweighing the general problems through the development time they will save. Then to top it all we have been gifted with an IDE to die for.

Hence in conclusion think we should approach this in a positive way as opportunity to increase efficiency and generally make the developers life easier.

 

[chiph]

I agree with you, Simon. .NET is a big leap forward, and represents a powerful way to write applications.

I had lunch with a couple of fellow developers today, and they were complaining about how .NET isn't multi-platform. I agreed, but said that from a practical standpoint (selling applications), it didn't matter since everyone runs Windows. Besides, for those runing Linux, there's a team porting .NET over to that platform (don't recall the project name, saw it on Slashdot last month).

One things for sure, .NET will separate the men from the boys.

Chip H.

 

[dilettante]

... or deepen the recession! ;-)