.NOT My Views

[Ralph]

Excuse me?

concession would've

AFAIK, IntPtr and UIntPtr are exactly that, i.e. platform-sized
integers! Aren't them?

Roman

Yes, in .NET. (actually they are structures that serve as a container for a
platform-specific sized thingy specific to a pointer or handle.)

What Karl was talking about is the VB Classic's "Integer" datatype and
migrating code to VB.Net. As VBc didn't have a platform-specific 'integer'
or 'int', a lot of VBc code is written that depends on it being 16-bit. When
32-bit was needed a "Long" was used. While reworking code to a new size or
datatype is rather trivial for a couple of routines - amounting to little
more than a search and replace with a new datatype, it can be quite annoying
for projects numbering hundreds if not thousand of lines of code.

As an example, there is an often told story (perhaps apocryphal), that when
MS was converting toys and utilities from Win3.1 to Win98 that Solitaire,
when recompiled, mysteriously occasionally froze. The developer tested
several bogus theories until it was found that there was a simple
timing/test loop that counted down to zero on an integer. When the loop had
a simple range of 32,767 the expected delay was trivial - but when it became
2,147,483,647 the delay became unacceptable.

Easy fix, sure. Showstopper, of course not. But many 'easy' fixes soon
requires just that many unit/system tests and adds to the cost

Karl's point is simply if VB.Net wanted to truly be version "7", they would
have been better off to have left the traditional, "VB", sized, datatypes
alone.

-ralph

 

[Dragon]

What Karl was talking about is the VB Classic's "Integer" datatype and

migrating code to VB.Net. As VBc didn't have a platform-specific 'integer'
or 'int', a lot of VBc code is written that depends on it being 16-bit. When
32-bit was needed a "Long" was used. While reworking code to a new size or
datatype is rather trivial for a couple of routines - amounting to little
more than a search and replace with a new datatype, it can be quite annoying
for projects numbering hundreds if not thousand of lines of code.

Ok, ok. Misread that.

Karl's point is simply if VB.Net wanted to truly be version "7", they would
have been better off to have left the traditional, "VB", sized, datatypes
alone.

It seems to me that it didn't want to be "VB 7" though. 8=]
However, to my mind, changing types when converting from VBC to VB .NET
is the lesser evil — too many more complicated changes have been
performed, so after you have dealt with control arrays, default
instances and other VBC-specific stuff, changing Long to Integer would
appear a piece of cake.

A problem is that a person finds a VB6 API declaration, copies it into
his VB .NET app, sees that it doesn't work, posts it here and someone
(like me 8=]) has to correct him.

Anyway, sorry and thanks,
Roman

 

[Ralph]

What Karl was talking about is the VB Classic's "Integer" datatype and
migrating code to VB.Net. As VBc didn't have a platform-specific 'integer'
or 'int', a lot of VBc code is written that depends on it being 16-bit. When
32-bit was needed a "Long" was used. While reworking code to a new size or
datatype is rather trivial for a couple of routines - amounting to little
more than a search and replace with a new datatype, it can be quite annoying
for projects numbering hundreds if not thousand of lines of code.

Ok, ok. Misread that.

Karl's point is simply if VB.Net wanted to truly be version "7", they would
have been better off to have left the traditional, "VB", sized, datatypes
alone.

It seems to me that it didn't want to be "VB 7" though. 8=]
However, to my mind, changing types when converting from VBC to VB .NET
is the lesser evil - too many more complicated changes have been
performed, so after you have dealt with control arrays, default
instances and other VBC-specific stuff, changing Long to Integer would
appear a piece of cake.

A problem is that a person finds a VB6 API declaration, copies it into
his VB .NET app, sees that it doesn't work, posts it here and someone
(like me 8=]) has to correct him.

Anyway, sorry and thanks,
Roman

You are quite correct - All things considered, the mucking about with
datatypes is THE 'least' of all the challenges to be met in migrating code.

Your observation: "It seems to me that it didn't want to be "VB 7"" sums up
the both the challenges and VBer's general complaints against MS rather
well.

-ralph

 

[Bob Butler]

It seems to me that it didn't want to be "VB 7" though. 8=]

That strikes right to the core. Although it was billed as VB 7 it was not.

However, to my mind, changing types when converting from VBC to VB
.NET is the lesser evil - too many more complicated changes have been
performed, so after you have dealt with control arrays, default
instances and other VBC-specific stuff, changing Long to Integer would
appear a piece of cake.

The majority of things that were changed did not have to be though. New
features could have been added without changing existing VB syntax. Even if
I accept the premise that changing Long to Integer was a comparatively
simple change, what possible justification could there be for doing it?
Adding Int16, Int32 and Int64 made sense but at the same time leave the
legacy names intact or deprecate them. Making seemingly gratuitous changes
like that was just one more nail on the coffin for VB.Net in my opinion.
The flimsy excuse that 'integer' in VB.Net should compare to 'int' in C# is
laughable since doing that at expense of making 'Integer' incompatible with
'Integer' is inane.

A problem is that a person finds a VB6 API declaration, copies it into
his VB .NET app, sees that it doesn't work, posts it here and someone
(like me 8=]) has to correct him.

And if they had considered that it'd mean a lot less frustration for people
trying to switch and a lot fewer cries for help due to stupidity in the
VB.Net syntax. Letting VB.Net be compatible with VB6 would have made sense
and drawn a lot more people into the language. Then again, that would have
meant having a .Net version of VB instead of having C# and C# with a coat of
VB paint.

 

[Dragon]

Have to agree with you. Compatibility with VBC would be nice.

However, IMO, the best choice will be to introduce 2 languages:

1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
totally backwards compatible with VB6, and able to make unmanaged
applications or managed ones with framework class library support.
2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
language we have now, uncompatible with VB6, but having more features,
i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
ability to make *unsafe* code, and so on.

Thus, a person could continue developing his VB6 projects, the he'd look
at Bb, say "Hey, that's a cool thing!" and gradually switch to it.

Unfortunately, MS's thoughts usually differ a bit from developer's
thoughts.

 

[Herfried K. Wagner [MVP]]

1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
totally backwards compatible with VB6, and able to make unmanaged
applications or managed ones with framework class library support.
2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
language we have now, uncompatible with VB6, but having more features,
i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
ability to make *unsafe* code, and so on.

Thus, a person could continue developing his VB6 projects, the he'd look
at Bb, say "Hey, that's a cool thing!" and gradually switch to it.

That's actually something the petition (see my signature) is asking for.

Unfortunately, MS's thoughts usually differ a bit from developer's
thoughts.

Sadly that seems to be true :-(.

 

[Stefan Berglund]

Have to agree with you. Compatibility with VBC would be nice.

However, IMO, the best choice will be to introduce 2 languages:

1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
totally backwards compatible with VB6, and able to make unmanaged
applications or managed ones with framework class library support.
2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
language we have now, uncompatible with VB6, but having more features,
i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
ability to make *unsafe* code, and so on.

Thus, a person could continue developing his VB6 projects, the he'd look
at Bb, say "Hey, that's a cool thing!" and gradually switch to it.

Ha ha ha. A few years ago that would have been the right thing to do. Too late
for that now. Fortunately there are great alternatives out there, but I'm
especially fond of those that can deliver GUI and/or console apps to Windows,
Linux, and MAC OS X platforms (and several others) -- all from a single code
base.

Suppose they called a war and nobody came.

 

[Paul Clement]

¤ Have to agree with you. Compatibility with VBC would be nice.
¤
¤ However, IMO, the best choice will be to introduce 2 languages:
¤
¤ 1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
¤ totally backwards compatible with VB6, and able to make unmanaged
¤ applications or managed ones with framework class library support.
¤ 2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
¤ language we have now, uncompatible with VB6, but having more features,
¤ i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
¤ ability to make *unsafe* code, and so on.
¤
¤ Thus, a person could continue developing his VB6 projects, the he'd look
¤ at Bb, say "Hey, that's a cool thing!" and gradually switch to it.
¤
¤ Unfortunately, MS's thoughts usually differ a bit from developer's
¤ thoughts.
¤

No way what you suggest could have been accomplished in time for the release of .NET. They're still
adding features now that were left out in the initial version.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[alpine]

¤ Have to agree with you. Compatibility with VBC would be nice.
¤
¤ However, IMO, the best choice will be to introduce 2 languages:
¤
¤ 1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
¤ totally backwards compatible with VB6, and able to make unmanaged
¤ applications or managed ones with framework class library support.
¤ 2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
¤ language we have now, uncompatible with VB6, but having more features,
¤ i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
¤ ability to make *unsafe* code, and so on.
¤
¤ Thus, a person could continue developing his VB6 projects, the he'd look
¤ at Bb, say "Hey, that's a cool thing!" and gradually switch to it.
¤
¤ Unfortunately, MS's thoughts usually differ a bit from developer's
¤ thoughts.
¤

No way what you suggest could have been accomplished in time for the release of .NET. They're still
adding features now that were left out in the initial version.

So? They could easily have done an interim release of VB that didn't
target the .NET platform and then release another version that did
when it was ready. That would have been the *correct* way to go
rather than screwing every owner of existing VB code. Hell! they're
*still* releasing versions of FoxPro that don't target .NET so why the
hell they thought it was OK to screw VB developers is *way* beyond any
level of comprehension.

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'(e-mail address removed)

 

[Ralph]

So? They could easily have done an interim release of VB that didn't
target the .NET platform and then release another version that did
when it was ready. That would have been the *correct* way to go
rather than screwing every owner of existing VB code. Hell! they're
*still* releasing versions of FoxPro that don't target .NET so why the
hell they thought it was OK to screw VB developers is *way* beyond any
level of comprehension.

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'(e-mail address removed)

While I would disagree with the "easily" attribute, I can certainly agree
with the "could have done" statement.

Perhaps, the fact that Mr. B has always been more closely associated with
the "Office" group and sided with them in their earlier failed attempts to
take over VB; the fact he took an early interest in FoxPro; and the fact
that his strongest competition for power (in the days of the "office of
three") came from the 'Development' group; might have something to do with
the current situation.

Like most corporate decisions I imagine there are multiple sub-plots running
behind the current scenario. But it is easy to comprehend that in the final
analysis .NET is a major financial and technology move designed to protect
their future investment in platform-specific software solutions. Note, that
is protecting 'their' investment, not anyone else's. Dollars talk.

[There is still an opportunity to address this issue. One hears things.
Rumor or wishful thinking? Who knows?]

-ralph

 

[Paul Clement]

¤ On Mon, 17 Oct 2005 08:35:46 -0500, Paul Clement
¤
¤ >
¤ >¤ Have to agree with you. Compatibility with VBC would be nice.
¤ >¤
¤ >¤ However, IMO, the best choice will be to introduce 2 languages:
¤ >¤
¤ >¤ 1. "Visual Basic .NET with managed extensions" (version 7.0, 7.1 etc.) -
¤ >¤ totally backwards compatible with VB6, and able to make unmanaged
¤ >¤ applications or managed ones with framework class library support.
¤ >¤ 2. Something like "Bb" (Basic flat) (version 1.0, 1.1 etc.) - the
¤ >¤ language we have now, uncompatible with VB6, but having more features,
¤ >¤ i.e. operator overloading, support for UShort, UInteger, ULong & SByte,
¤ >¤ ability to make *unsafe* code, and so on.
¤ >¤
¤ >¤ Thus, a person could continue developing his VB6 projects, the he'd look
¤ >¤ at Bb, say "Hey, that's a cool thing!" and gradually switch to it.
¤ >¤
¤ >¤ Unfortunately, MS's thoughts usually differ a bit from developer's
¤ >¤ thoughts.
¤ >¤
¤ >
¤ >No way what you suggest could have been accomplished in time for the release of .NET. They're still
¤ >adding features now that were left out in the initial version.
¤
¤
¤ So? They could easily have done an interim release of VB that didn't
¤ target the .NET platform and then release another version that did
¤ when it was ready. That would have been the *correct* way to go
¤ rather than screwing every owner of existing VB code. Hell! they're
¤ *still* releasing versions of FoxPro that don't target .NET so why the
¤ hell they thought it was OK to screw VB developers is *way* beyond any
¤ level of comprehension.

Simple reason. Visual Basic would have continued to be criticized for not being on par with the
C-based languages and developers (not necessarily Classic Visual Basic) would have started using C#
instead. An interim release would have just prolonged the inevitable.

Who wants to wait seven to ten years to work with a new development platform when they can use it
today?

FoxPro is different. It's actually a database application development product that's a bit more
specialized than Visual Basic.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Gary Nelson]

Paul,

Simple reason. Visual Basic would have continued to be criticized for not
being on par with the
C-based languages

Who cares? I certainly don't, and I am certain that all of those of us who
continue to develop in VB6 don't either.

and developers (not necessarily Classic Visual Basic) would have started
using C#
instead.

Which they have anyway. Have you been to TechEd? How many demos are done in
Vb & how many in C#?

An interim release would have just prolonged the inevitable.

And what exactly is "the inevitable"?

Who wants to wait seven to ten years to work with a new development
platform when they can use it
today?

I predict that many of us here will still be developing Vb6 programs in
seven to ten years, because we are locked into it. A smooth transition in
seven to ten years would be fine for me.

FoxPro is different. It's actually a database application development
product that's a bit more
specialized than Visual Basic.

With a lot less developers using it.

Gary

 

[Gary Nelson]

Ralph,

Like most corporate decisions I imagine there are multiple sub-plots
running
behind the current scenario. But it is easy to comprehend that in the
final
analysis .NET is a major financial and technology move designed to protect
their future investment in platform-specific software solutions. Note,
that
is protecting 'their' investment, not anyone else's. Dollars talk.

Which is why some heads should be rolling at MS. Just think about it: VB6 is
now a direct competitor to the .Net platform. MS makes no money from VB6.
Thousands of developers will still be developing with VB6 in the years to
come. All of that is a drag on the .net platform. If MS had made an easy
transition it would have been a big push for the .net platform and all of
these useless discussion would not be taking place. Just think how many
man-hours have been wasted on this subject.

Gary

 

[Paul Clement]

¤ Paul,
¤
¤ > Simple reason. Visual Basic would have continued to be criticized for not
¤ > being on par with the
¤ > C-based languages
¤
¤ Who cares? I certainly don't, and I am certain that all of those of us who
¤ continue to develop in VB6 don't either.
¤

Well I did as did many others who are now using VB.NET.

¤ > and developers (not necessarily Classic Visual Basic) would have started
¤ > using C#
¤ > instead.
¤
¤ Which they have anyway. Have you been to TechEd? How many demos are done in
¤ Vb & how many in C#?
¤

That isn't the point. The *only* path to .NET would have been C# while Visual Basic would have
continued to lag behind - even further. There would have been no option for Visual Basic developers
to develop .NET apps in a Visual Basic language.

¤ > An interim release would have just prolonged the inevitable.
¤
¤ And what exactly is "the inevitable"?
¤

The inevitable is what we have now.

¤ > Who wants to wait seven to ten years to work with a new development
¤ > platform when they can use it
¤ > today?
¤
¤ I predict that many of us here will still be developing Vb6 programs in
¤ seven to ten years, because we are locked into it. A smooth transition in
¤ seven to ten years would be fine for me.
¤

Well I wish you luck, really. There is very little call for new development in/for Visual Basic 6.0
and there will be even fewer job opportunities in the future. Resources are drying up and you can't
even rely on Microsoft to maintain information about the product. All I can recommend is to hang on
to those old MSDN libraries if you have them.

¤ > FoxPro is different. It's actually a database application development
¤ > product that's a bit more
¤ > specialized than Visual Basic.
¤
¤ With a lot less developers using it.

Which is another reason why there's no valid comparison.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Gary Nelson]

Paul,

Well I did as did many others who are now using VB.NET.

Is that why most prefer to use C#?

¤ > and developers (not necessarily Classic Visual Basic) would have
started
¤ > using C#
¤ > instead.
¤
¤ Which they have anyway. Have you been to TechEd? How many demos are done
in
¤ Vb & how many in C#?
¤

That isn't the point. The *only* path to .NET would have been C# while
Visual Basic would have
continued to lag behind - even further. There would have been no option
for Visual Basic developers
to develop .NET apps in a Visual Basic language.

VB for .NET could have been much more compatible with VB6 if MS had wanted.

¤ > An interim release would have just prolonged the inevitable.
¤
¤ And what exactly is "the inevitable"?
¤

The inevitable is what we have now.

I'm not in agreement there. I don't think that the present situation was
inevitable.

¤ > Who wants to wait seven to ten years to work with a new development
¤ > platform when they can use it
¤ > today?
¤
¤ I predict that many of us here will still be developing Vb6 programs in
¤ seven to ten years, because we are locked into it. A smooth transition
in
¤ seven to ten years would be fine for me.
¤

Well I wish you luck, really. There is very little call for new
development in/for Visual Basic 6.0
and there will be even fewer job opportunities in the future. Resources
are drying up and you can't
even rely on Microsoft to maintain information about the product. All I
can recommend is to hang on
to those old MSDN libraries if you have them.

I'm not looking for a job. The last time I looked for a job was over 20
years ago. There is a very good probability that we will be using VB6 until
it stops working.


Gary

 

[Paul Clement]

Gary,

¤ > Well I did as did many others who are now using VB.NET.
¤
¤ Is that why most prefer to use C#?
¤

What percentage of Classic Visual Basic developers prefer to use C#? Did I miss that poll?

What about those who are now using Visual Basic.NET including those who never even used Classic VB?

¤ > ¤ > and developers (not necessarily Classic Visual Basic) would have
¤ > started
¤ > ¤ > using C#
¤ > ¤ > instead.
¤ > ¤
¤ > ¤ Which they have anyway. Have you been to TechEd? How many demos are done
¤ > in
¤ > ¤ Vb & how many in C#?
¤ > ¤
¤ >
¤ > That isn't the point. The *only* path to .NET would have been C# while
¤ > Visual Basic would have
¤ > continued to lag behind - even further. There would have been no option
¤ > for Visual Basic developers
¤ > to develop .NET apps in a Visual Basic language.
¤
¤ VB for .NET could have been much more compatible with VB6 if MS had wanted.
¤

Some features yes, some no because the current implementations differed from those in .NET. But this
issue has been debated endlessly.

¤ > ¤ > An interim release would have just prolonged the inevitable.
¤ > ¤
¤ > ¤ And what exactly is "the inevitable"?
¤ > ¤
¤ >
¤ > The inevitable is what we have now.
¤
¤ I'm not in agreement there. I don't think that the present situation was
¤ inevitable.
¤

Oh, so you think that Microsoft was going to maintain a Classic and .NET version of Visual Basic
forever?

¤ >
¤ > ¤ > Who wants to wait seven to ten years to work with a new development
¤ > ¤ > platform when they can use it
¤ > ¤ > today?
¤ > ¤
¤ > ¤ I predict that many of us here will still be developing Vb6 programs in
¤ > ¤ seven to ten years, because we are locked into it. A smooth transition
¤ > in
¤ > ¤ seven to ten years would be fine for me.
¤ > ¤
¤ >
¤ > Well I wish you luck, really. There is very little call for new
¤ > development in/for Visual Basic 6.0
¤ > and there will be even fewer job opportunities in the future. Resources
¤ > are drying up and you can't
¤ > even rely on Microsoft to maintain information about the product. All I
¤ > can recommend is to hang on
¤ > to those old MSDN libraries if you have them.
¤
¤ I'm not looking for a job. The last time I looked for a job was over 20
¤ years ago. There is a very good probability that we will be using VB6 until
¤ it stops working.

Hey, as long as it serves your needs and its obsolence does not dictate a job change then you're all
set.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Kevin Provance]

Oh, so you think that Microsoft was going to maintain a Classic and .NET

version of Visual Basic

forever? <

Actually, no I don't.

I think at some point .NET is going to get the same shaft as VBC and leave
another group of developers holding thousands of lines of useless code for
the next self applyed "big thing."

We'll see how much sympathy the .NETheads get from those of us who knew
better *when* that moment comes.

- Kev

 

[Casey Provance]

1) ppl isn't a word. It's Internet ghetto talk.
2) If you have the knowledge to make a time machine, then .NET should be way
to simple for you, in which case you should be doing something more
productive than defending an already doomed development tool.

<g>

- Kev

 

[Gary Nelson]

Paul,

¤ > Well I did as did many others who are now using VB.NET.
¤
¤ Is that why most prefer to use C#?
¤

What percentage of Classic Visual Basic developers prefer to use C#? Did I
miss that poll?

What about those who are now using Visual Basic.NET including those who
never even used Classic VB?

I don't have any statistics. But I do know that C# is the 'in' language with
MS. Just try attending TechEd without a decent knowledge of C#.

¤ VB for .NET could have been much more compatible with VB6 if MS had
wanted.
¤

Some features yes, some no because the current implementations differed
from those in .NET. But this
issue has been debated endlessly.

The first three words in your last phrase are what have created endless
debates. 'Some features yes'. All VB6 users are programmers. Some are very
good. That means that we can take a look at what MS did and do a pretty good
calculation of what was really necessary and what was not.

¤ > ¤ > An interim release would have just prolonged the inevitable.
¤ > ¤
¤ > ¤ And what exactly is "the inevitable"?
¤ > ¤
¤ >
¤ > The inevitable is what we have now.
¤
¤ I'm not in agreement there. I don't think that the present situation was
¤ inevitable.
¤

Oh, so you think that Microsoft was going to maintain a Classic and .NET
version of Visual Basic
forever?

No, but I do believe that a much smoother transition could have been
achieved.

¤ >
¤ > ¤ > Who wants to wait seven to ten years to work with a new
development
¤ > ¤ > platform when they can use it
¤ > ¤ > today?
¤ > ¤
¤ > ¤ I predict that many of us here will still be developing Vb6 programs
in
¤ > ¤ seven to ten years, because we are locked into it. A smooth
transition
¤ > in
¤ > ¤ seven to ten years would be fine for me.
¤ > ¤
¤ >
¤ > Well I wish you luck, really. There is very little call for new
¤ > development in/for Visual Basic 6.0
¤ > and there will be even fewer job opportunities in the future.
Resources
¤ > are drying up and you can't
¤ > even rely on Microsoft to maintain information about the product. All
I
¤ > can recommend is to hang on
¤ > to those old MSDN libraries if you have them.
¤
¤ I'm not looking for a job. The last time I looked for a job was over 20
¤ years ago. There is a very good probability that we will be using VB6
until
¤ it stops working.

Hey, as long as it serves your needs and its obsolence does not dictate a
job change then you're all
set.

I wouldn't consider that having a Damocles' sword hanging over my head being
'all set'.



Gary

 

[Abubakar]

these useless discussion would not be taking place. Just think how many

man-hours have been wasted on this subject.

Lots !
:_)

-Ab.
http://joehacker.blogspot.com