Re: Move from VB 6 to VB.Net in 5 easy steps
"Jay Glynn" <firstname.lastname@example.org> wrote in message
> > Many of the changes seem to be designed simply to break compatibility.
> > do not make VB.NET any more OO, they simply make it look 'cool.'
> They make it more compatible with the other languages that will be
> on .NET.
I wonder how compatible it will be with VB.Python...but even granting your
premise, you are not disagreeing with me; just rephrasing in different
> > I have never have quarreled with the elegance of Fred.NET. And it
> > can be considered a variant of the BASIC family. But by your own
> > it's not VB.
> It's not VB7. It's not a load and recompile migration from VB6, but I
> that you can still call it VB.
Then it should be called PDS 14. It has little if anything more in common
with VB6 than VB1 had with QBX. Why keep the name the same this time?
> > Why is it, I wonder, that anyone who likes VB.NET starts off by assuming
> > that anyone who doesn't is an ignoramus? I'm reading your opinions
> > carefully and with an open mind. You seem to want to discount mine in
> > advance by assigning me a history that makes you feel superior.
> Never meant to imply anything like that. Simply if all you know is VB,
> the changes make less sense then if you have done a fair amnount of C /C++
> programming or perhaps Java programming.
"Make sense?" If you mean recognisable, then I agree with you. If you mean
more likely to be deemed "A Good Thing," I have doubts. If you mean that
someone who has programmed primarily in other languages will feel more
comfortable with Fred, then, again, I agree.
>Then the changes would ring a
> familiar bell. I am not trying to infer that this has a direct
> to your intellect, or to your development skills. Apologies if it came
> across that way.
Accepted with thanks.
> > >The boolean -1
> > > to not 0, the 0 based arrays etc are being handled the way that most
> > > languages currently handle them.
> > Most languages are different from each other. MSFT recognized this re:
> > and VFP. Only VB was changed to be a semi-clone of C#.
> VB was the only on that did them differently.
The three languages (VB; C++; VFP) all do many things differently than each
other and C++ and VFP have not been coerced into doing them the same way as
> >My concern these
> > past weeks has been to determine whether or not dealing with VB.NET is a
> > waste of time. Nothing you have said in your post suggests that VB.NET
> > offers any greater ROI than C# and, since the success of dotnet is still
> > problematical and its adoption as a desktop standard even more so,
> > to Java, or Kylix must be looked at as a viable alternative. Especially
> > since the suits will consider dotnet to be experimental and unproven.
> > rightfully so, it is.)
> As far as overall adoption, yes we are all waiting to see what happens.
More importantly, so are our bosses <grin>.
> However as far as ROI goes, I think that VB.NET will allow a current Vb
> developer to be much more productive then if they were to have to learn
> There is still a great deal of syntax that is still VB, and there is
> VisualBasic.dll that will make the learning process much easier.
You may be right. Or that may lull folks into a false sense of security.
> > >The there is the argument about it not
> > > being as easy to learn. In my mind this is a good thing.
> > Okay, in your mind it is. In other peoples minds it isn't. If some
> > think VB's more accessible than other languages, then what skin is it
> > your nose? It probably creates extra income for you when you are asked
> > bail them out. At any rate it's an opinion and not a matter of fact.
> No, unfortunately it isn't extra income, it's just extra time that I don't
> have. I work in Corporate America., my paycheck is the same each week
Yeah, me, too. Difference is I like working with the newbies. They're like
puppies - not fully toilet trained, but cute and eager. And my bosses let
me track mentoring time as a separate project that is on-going.
> > Your point has nothing to do with the language, but seems to suggest
> > feel better if you can say that you know a lnaguage thats not easy to
> > So what's stopping you?
> It has everything to do with the language, or at least in the MSFT
> of the language. Everyone knows that VB is easy to learn and to use, or
> that's what we all have been told. The guy in marketing thinks that means
> can write a new front end to his marketing database. He was told that if
> put the database name in this spot and the table name in this spot, the
> magically appeared in the grid. He had no clue about ADO, RDO, ODBC,
> recordset, what DBMS he was using, never mind that the grid he wanted
> have required a 4 table join (his response "What's a join?"). This is not
> easy to use,
I agree. Hey in your corp, who decides these guys get VB on their desktop?
That sounds like it's your real problem, not the jamoke who is using the
tools he's been told to use. It's the folks who are okaying the install that
you need to educate. I wouldn't be surprised if they are C++ folks, or
sysadmins who haven't looked as a BASIC-derived language since an intro to
VB3 in college.
> > > Bottom line to all of this is that we, the professional developers
> > give
> > > a crap about our future, that actually read book on occasion, that try
> > > keep up with technology, now have multiple choices. You can stick with
> > > current version of VB. I see this to be a viable option for at 2 to 3
> > years.
> > > Move to .NET. Now you really have a choice of languages. Move to
> > and
> > > hope that Borland stays afloat (see Hindenburg). Pick up Java and hope
> > that
> > > Sun does the right thing. Of course you won't be doing to many client
> > based
> > > apps, otherwise your users will hang you for the performance hit <g>.
> > > then of course there is C++ if your feeling really geaky and you have
> > long
> > > development cycle. I can't imagine a better time to be in this
> > Interesting. We basically agree - although I think your time estimates
> > dotnet are way optimistic and I'm as much concerned about the
> > performance-hit that client-based apps will take with dotnet as with
> > However, and at the risk of repeating myself - why bother with VB.NET?
> > there were a viable migration path from what there is to what MSFT wants
> > there to be, that would make a difference. If there weren't all the
> > gratuitous incompatibilities, that would make a difference. If VB.NET
> > seen as the big pile of goo that maintained compatibility and VB# was
> > as the really cool way to go for people who knew hard to learn
> > that would make a difference too. Any of the preceding would make me
> > better about VB.NET's long-term prospects.
> The fact that MSFT has stated that VB6 will be around for a couple of more
> years answers your question. I don't look at it as a migration path. I
> have VB3 apps in production. I answered the why VB.NET before, because it
> will be easier to learn for a seasoned VB developer.
Of course, my mileage may vary. Presumably your prognostications carry a
money back guarantee only for as much as I paid for 'em.
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center