Microsoft's C++ bigotry

[Dave]

Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
>Well Mid is supported but once again you may want to indicate specifically
what you
>are doing. It
>could simply be the .NET environment and not the actual function. And, it's
possible
>the VB.NET
>variation may be relatively easy to implement with a performance improvement.
>Paul ~~~ pclement@ameritech.net
>Microsoft MVP (Visual Basic)

Hey, if you have any pull with MS (I assume that's what Microsoft MVP means
..), ask them to just confer with some of the members of the old VB6 development
team to find out how to get Mid and ReDim performing acceptably. Although
a lot of people mention the poor performance of Mid, ReDim is even slower.
It may be discouraging to some people to port an app to VB.NET and then find
out that extensive array usage is penalized.
I found an ugly hack around the problem (by redimming in large blocks), but
if Microsoft just fixes the **** thing we won't need the hacks.

[Kent]

Pat,

It should have been a no brainer for the monopolists to realize all by them
selves that a VB7 with managed extensions was needed. The fact that they
didn't provide a migration path then and still don't today speaks volumes
to the level of commitiment they have provided to the VB community.

They don't listen and they don't care... yet. If things keep going the way
they are, they soon will. You're defense of them is not helping any. Admit
the problems exist and say you won't stand for it. Point out the alternatives...
Hit em where it hurts most, that's how you make change.

Kent

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>"Jonathan West" <jwest@mvps.org> wrote:
>>
>>
>>I don't think anybody would have complained if a compatible language had
>>been provided in addition to VB.NET. The problem is that option was not
>on
>>offer from Microsoft.
>
>No, but did the .NOTters ever ask for a VB7 with Managed Extensions? No,
>they focused their attention on two strategies...
>
>1 - Compromising the VB.NET language (such as adding GoSub and getting rid
>of BitAnd, BitOr, etc.)
>2 - Rejecting the whole concept of .NET itself.
>
>The first strategy only succeeded in pissing off the pro-.NET folks which
>split the VB community in two.
>
>The second strategy was even more stupid than the first. It succeeded in
>pissing almost everyone off, pro-VB.NETters and MS. In fact, it alienated
>MS - the very people they wanted to help them. Even the ".NOT" phrase they
>thought they so cleverly coined worked against them.
>
>Both were self-defeating, and doomed to failure. The .NOTters should have
>pursued a third strategy...
>
>3 - VB7 with Managed Extensions.
>
>...Almost no VB.NET programmer would have objected to this option. The .NOTters
>would have got the compatible language they wanted, and the VB.NETters would
>have got the no-holds barred language they wanted. The VB community would
>never have been split in two. Plus, rather than a condemnation of .NET,
a
>VB7 with Managed Extensions would actually be considered an endorsement
of
>.NET while still retaining "language stability". The .NOTters were their
>own worst enemy.
>
>Would MS have listened? Maybe they would have, maybe no. I don't know. But
>since it was never tried, we never found out.
>
>There's more I wish I could say, but I'm under NDA....
>
>/Pat
>---------------------------
>It's the platform, stupid.
>---------------------------

[Jonathan West]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3e2ea0c1$1@tnews.web.devx.com...
>
> "Jonathan West" <jwest@mvps.org> wrote:
> >
> >
> >I don't think anybody would have complained if a compatible language had
> >been provided in addition to VB.NET. The problem is that option was not
> on
> >offer from Microsoft.
>
> No, but did the .NOTters ever ask for a VB7 with Managed Extensions? No,
> they focused their attention on two strategies...

To be honest, until VB.NET actually hit commercial release, asking for yet
another language to be added in parallel to VB.NET was hardly the best and
most practical way forward, and would have been laughed out of court by MS.
The idea is only being talked about now because it's now too late to go back
and remake VB.NET with the proper compatibility it ought to have had in the
first place. if they went back and changed VB.NET, those who went with it in
v1 would come up with exactly the same arguments that the .notters expressed
during the beta.

>
> 1 - Compromising the VB.NET language (such as adding GoSub and getting rid
> of BitAnd, BitOr, etc.)

If you go back through the threads, you'll find that the beta 2 changes were
decidedly *not* what was asked for - by anyone!

> 2 - Rejecting the whole concept of .NET itself.

No, this is a misunderstanding of the position of those who were arguing for
compatibility (with the exception of MM). You are failing to make the
distinction between language and platform again. Several times, Karl and
others said words to the effect of "We like the idea of .Net. We just wish
that Microsoft had included Visual Basic in it". The key point was that
VB.NET had so many changes to core language elements that for all practical
purposes it was a new language and should be given a new name. That was the
origin of the "Visual Fred" name coined by Bill Vaughn.

The argument was never against the dotnet platform itself. I suspect that
some of the netters knew this perfectly well, and deliberately chose to
characterise the argument as pro/anti dotnet in order to portray the notters
as a bunch of reactionary old gits who didn't want to keep up with progress,
or were afraid of losing their VB guru status.

>
> The first strategy only succeeded in pissing off the pro-.NET folks which
> split the VB community in two.

The split divided the community fairly neatly into the following groups

1. Those who had created substantial VB5/6 apps and were responsible for
maintaining and extending them,

2. Those who hadn't ever created substantial apps in VB5/6, or had created
them but were not responsible for their further development.

I won't say that absolutely every member of the two groups conformed to
those descriptions, but I've described the characteristics of the large
majority. Also, there were occasional mavericks such as Bill Storage, who
had code and wanted Microsoft to break it, but overall, those two groups
defined the argument.

The requirements of the two groups were incompatible with each other, and so
at best Microsoft could only keep one group happy with any decision on the
syntax of a single version of VB. Microsoft tried to keep both groups happy
with the beta 2 rollbacks, and simply enraged everyone, not least with their
lack of decisiveness on an issue which really admitted of no compromise.

Microsoft had to choose to meet the requests of one and ignore the requests
of the other, or go with two completely separate languages in addition to
C#. Which group (if their requirements were met) was in a better position to
help Microsoft assure the overall success of the .Net platform by bringing
substantial apps to it in a short time? The anser to that question should
have been the deciding factor in how Microsoft proceeded. It is still the
key point in how Microsoft should go on from here.

>
> The second strategy was even more stupid than the first. It succeeded in
> pissing almost everyone off, pro-VB.NETters and MS. In fact, it alienated
> MS - the very people they wanted to help them. Even the ".NOT" phrase they
> thought they so cleverly coined worked against them.
>
> Both were self-defeating, and doomed to failure. The .NOTters should have
> pursued a third strategy...
>
> 3 - VB7 with Managed Extensions.
>
> ..Almost no VB.NET programmer would have objected to this option. The
..NOTters
> would have got the compatible language they wanted, and the VB.NETters
would
> have got the no-holds barred language they wanted. The VB community would
> never have been split in two. Plus, rather than a condemnation of .NET, a
> VB7 with Managed Extensions would actually be considered an endorsement of
> NET while still retaining "language stability". The .NOTters were their
> own worst enemy.
>
> Would MS have listened? Maybe they would have, maybe no. I don't know. But
> since it was never tried, we never found out.

It was tried - but the pro vb.netters characterised their arguments in the
way you have in this post.

>
> There's more I wish I could say, but I'm under NDA....

You've probably broken NDA by even admitting that :-)

--
Regards
Jonathan West

[David Rothgery]

"Gary Nelson" <gn@contanet.es> wrote in message
news:3e2e5706@tnews.web.devx.com...
> David,
>
> > Because in a language strictly tied to a platform,
>
> In a world tending toward platform independent languages that is a null
> argument. So when Windows 64 comes out we change all the definitions
again?

Perhaps, though 32-bit values on most 64-bit platforms don't have the
performance issues that 16-bit values do on most 32-bit platforms (certainly
the Itanium and the Athlon 64/Opteron don't).

> > Integer should be the optimal integer size on the platform
>
> Why?

Because a type called Integer (or int, in the C-style world, or whatever
keyword has a name that strongly suggests 'default integeral data type') is
the integer type that's going to be used most of the time, and library
functions that require an integral type as a parameter will take one; it
doesn't make sense to delibrately de-optimize code.

> > (and no, Jonathan, implementing
> > Integers as 32-bit integers behind the scene and making them act like
> > 16-bit integers would not be a good idea; you'd have a base integer type
> > with very strange behavior, so experienced programmers would use Long
> > for everything).
>
> Excuse me, but that is abusrd. No one is talking about making them work
> behind the scene as something else.

Jonathan West suggested exactly that, as a hack to get around the
performance issues caused by using 16-bit values extensively on 32-bit
systems.

> > Lots of people claim that they never had any problems with GOTOs,
> > GOSUBs, C-style pointers, or self-modifying code, but it doesn't keep
> > them from being errors waiting to happen either.
>
> As if there are no errors waiting to happen in VB.Net.

Of course there are; no language is perfect (and some of the language design
errors in VB.NET are a direct result of trying to maintain backward
compatibility).

But defaulting to pass by reference, GOTOs, GOSUBs, C-style pointers, and
self-modifying code are gotchas that are pointed out in every freshman CS
student's first or second programming class. And when you're making radical
changes to a language anyway (completely changing the core libraries for
GUIs, database access, IO, web programming, string handling, collections,
and a host of other things; adding full OOP support; changing from reference
counting to garbage collection; changing from On Error-style error handling
to exception handling), you might as well fix obvious design errors. The
VB.NET team went a long way there, though not quite far enough IMO (see the
Beta 2 rollbacks, changing Wend to End While instead of just dropping the
construct entirely [as it's completely redundant with Do While/Loop]).

--
Dave Rothgery
drothgery@alum.wpi.edu

[Dan Barclay]

On Wed, 22 Jan 2003 07:50:32 -0600, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>On Wed, 22 Jan 2003 09:15:16 -0000, "Gary Nelson" <gn@contanet.es> wrote:
>
>
>¤ That's funny, because my main problems are with changes in the core
>¤ language. Because I've been programming for a very long time (since
>¤ gwbasic), and have had plenty of problems with third party tools, I
>¤ generally do most of my programming in the core language.
>¤
>¤ Problem one: Gosub
>¤
>¤ I've got a truckload of Gosubs, about a thousand in just one program.
>¤ Whether you like it or not, until VB.Net Gosub was part of the core
>¤ language.
>
>It was one of the few language elements to go. Microsoft has been more or less de emphasizing this
>construct for years and never optimized it for Visual Basic:
>
>PRB: Poor Performance with the GoSub Statement
>http://support.microsoft.com/default...b;en-us;174808

The poor performance is a direct result of the implementation hack
they installed at (as I recall) about VB4. It has nothing to do with
GoSub inherently. In fact, in earlier versions (particularly in real
compiled code of the DOS versions) GoSub was *much* faster than a Sub
or Function. It compiled to a masm Call/Ret pair.

Instead of using the pseudostack hack they came up with they could
have picked any number of other implementation methods including
straight code substitution (like a macro) in which there would be
*zero* call overhead.

Do not confuse performance with behavior. Behavior is a result of
implementation design decisions.

Gary is not alone, by a long shot, in his use of GoSub. It's a useful
construct. Like *any* other, it can be misused (care to survey .cls
files of typical projects???). If you've never learned to use GoSub
(or classes!) properly, that's unfortunate but it does not mean they
are bad things that you should expect Microsoft to protect you from.

Duplicate code fragments are a virus in code that lives through years
of maintenance. It's a hard fact that, at some point, one copy of the
fragment will be fixed or enhanced and others will be missed. Its
proper usage is as a code-only container for eliminating duplicate
code fragments.

FWIW, Delphi provides almost a direct replacement using their nested
procedures.

By the way, 2 years ago I was told by MS that GoSub was cut due to
lack of time to get in implemented... then I was told it was dropped
on purpose. Dunno which is right.

>In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
>you indicate in your following points, I'm surprised that you continued to use GoSub.

In most places I use them it would require extensive parameter lists.
The idea is to eliminate duplicated code fragments for maintenance
reasons, but to replace them with equally long parameter lists or,
(God forbid) module level variables would only trade one problem for
another.

>
>¤
>¤ Problem three: Mid$
>¤
>¤ Four hundred times slower in VB.Net. I make extensive use of Mid$. All
>¤ routines that use Mid$ must be rewritten. Is not Mid$ part of the core
>¤ language?
>
>Well Mid is supported but once again you may want to indicate specifically what you are doing. It
>could simply be the .NET environment and not the actual function. And, it's possible the VB.NET
>variation may be relatively easy to implement with a performance improvement.

Hmmm... if they've made Mid$() slow, using your argument of GoSub,
perhaps this means they're about to drop it?

Dan
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Tom Shelton]

"Dave" <dave_doknjas@yahoo.ca> wrote in message
news:3e2ead07$1@tnews.web.devx.com...
>
> Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
> >Well Mid is supported but once again you may want to indicate
specifically
> what you
> >are doing. It
> >could simply be the .NET environment and not the actual function. And,
it's
> possible
> >the VB.NET
> >variation may be relatively easy to implement with a performance
improvement.
> >Paul ~~~ pclement@ameritech.net
> >Microsoft MVP (Visual Basic)
>
> Hey, if you have any pull with MS (I assume that's what Microsoft MVP
means
> .), ask them to just confer with some of the members of the old VB6
development
> team to find out how to get Mid and ReDim performing acceptably. Although
> a lot of people mention the poor performance of Mid, ReDim is even slower.
> It may be discouraging to some people to port an app to VB.NET and then
find
> out that extensive array usage is penalized.
> I found an ugly hack around the problem (by redimming in large blocks),
but
> if Microsoft just fixes the **** thing we won't need the hacks.

That's not a hack... ReDim maybe slightly slower in VB.NET, but it is also
slow in VB6 especially as your array gets larger. It has never been good
practice to ReDim arrays 1 element at a time. And if you want a dynamic
container - System.Collections.ArrayList.

I'm sorry, but for the most part, I find .NET to be just as fast or faster
in some cases. It usually comes down to changing the way you do things.
Take file I/O. Gary keeps complaining about how slow it is - and it is if
you use the VB.NET intrinsic functions. But if you take the time to figure
out the stream classes in System.IO, which are not all that difficult, then
you would find that it is just as fast. The platform has changed, and
performance optimizations that worked in the old environment don't
necesarrily work in .NET.

Tom Shelton

[Dan Barclay]

>a small but vocal minority
>of idiotic .NOTters like DB, KP, MM, GN

Hey! A promotion! I get to change my number!

Thanks!

Dan (#1 now!)
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Patrick Troughton]

Hi Kent,

You're deluding yourself if you think VB.NET isn't here to stay. The fact
is that .NET is already success, and getting bigger and bigger every day.
Every month, more and more companies are adopting .NET. Just in the last
few weeks....

Allstate Insurance....
http://www.microsoft.com/resources/c...eStudyID=13648

CNET...
http://www.microsoft.com/resources/c...eStudyID=13550

Nasdaq Stock Market, Inc....
http://www.microsoft.com/resources/c...eStudyID=13543

Volvo Cars....
http://www.microsoft.com/resources/c...eStudyID=13469

This is in addition to the hundreds and hundreds of companies who are already
using .NET.

In fact, .NET is now being used for everything from web sites to nuclear-powered
aircraft carriers (PC Magazine, "Mobile Application Tools", October 15th,
2002).

I can personally say that I know of another huge company that started on
a *major* VB.NET project just a few weeks ago. I can't give out the name,
but it has over 5,000 stores in 60 different countries throughout the world.
I can almost guarantee that everyone in this newsgroup has heard of it, and
has probably shopped there a few times, too. I suspect that when the app
is done, you will probably hear about it somewhere. I'm not under NDA with
this company, but I'll let them announce it when they're ready.

Even software vendors are embracing .NET because it's so much easier to work
with....
http://news.devx.com/cgi-bin/dnewswe...em=45350&utag=

ZDNET reports that .Net is one of the top job skills in demand....
http://zdnet.com.com/2100-1104-978922.html

.NET has won numerous industry awards...

PC Magazine's 18th Annual Technical Excellence Awards
Best Development Tool: Visual Studio .NET
http://www.pcmag.com/article2/0,4149,140708,00.asp

Software Development Magazine
Jolt Award for Best Libraries, Frameworks, and Components Microsoft .NET
Framework
http://www.sdmagazine.com/jolts/

Productivity Award for Best Languages and Development Environments Microsoft
Visual Studio .NET http://www.sdmagazine.com/jolts/

Those of you who have read my posts before know that I have few friends and
family in the IT industry. Just this weekend, I met up with a couple friends
from a consulting firm. They tell me that their .NET business is booming
and that their bench is filled with Java programmers who are starting to
worry that they don't have any clients.

I've been one of VB.NET's biggest supporters (beta 2 rollbacks notwithstanding)
since Day One and .NET has exceeded even my expectations.

Kent, I'm not going to argue with you. If there's one thing I've learned
from this newsgroup is that people make up their minds before posting, and
rarely change them, no matter what you say or how much proof you have.

So this will be my last post to this thread. If you're anything like the
other .NOTters, you will probably want to flame me or resort to personal
insults since .NOTters were never able to defend their ideas with logic or
facts.

The only thing I can say is if the .NOTters had listened to me two years
ago, they would be laughing all the way to the bank, too. And if they don't
start picking up .NET, they shouldn't be surprised when they're out of a
job a few years from now....

Later....

/Pat
--------------------------
It's the platform, stupid.
--------------------------

"Kent" <KP@KP.org> wrote:
>
>Pat,
>
>It should have been a no brainer for the monopolists to realize all by them
>selves that a VB7 with managed extensions was needed. The fact that they
>didn't provide a migration path then and still don't today speaks volumes
>to the level of commitiment they have provided to the VB community.
>
>They don't listen and they don't care... yet. If things keep going the
way
>they are, they soon will. You're defense of them is not helping any. Admit
>the problems exist and say you won't stand for it. Point out the alternatives...
> Hit em where it hurts most, that's how you make change.
>
>Kent

[Kent]

"David Rothgery" <drothgery@alum.wpi.edu> wrote:
>But defaulting to pass by reference, GOTOs, GOSUBs, C-style pointers, and
>self-modifying code are gotchas that are pointed out in every freshman CS
>student's first or second programming class. And when you're making radical
>changes to a language anyway (completely changing the core libraries for
>GUIs, database access, IO, web programming, string handling, collections,
>and a host of other things; adding full OOP support; changing from reference
>counting to garbage collection; changing from On Error-style error handling
>to exception handling), you might as well fix obvious design errors. The
>VB.NET team went a long way there, though not quite far enough IMO (see
the
>Beta 2 rollbacks, changing Wend to End While instead of just dropping the
>construct entirely [as it's completely redundant with Do While/Loop]).

Then they should not have called it VB since calling it VB provides some
some hope of backward compatibility. They also should have provided VB7
with managed extensions as Dan and others have suggested. What we have not
is not acceptable. The jobmarket for VB.Net and overall lack of interest
in it shows this. The MVP crowd may have talked themselves out of work.

[Paul Clement]

On Wed, 22 Jan 2003 11:08:24 -0600, Dan Barclay <Dan@MVPs.org> wrote:


¤ >
¤ >It was one of the few language elements to go. Microsoft has been more or less de emphasizing this
¤ >construct for years and never optimized it for Visual Basic:
¤ >
¤ >PRB: Poor Performance with the GoSub Statement
¤ >http://support.microsoft.com/default...b;en-us;174808
¤
¤ The poor performance is a direct result of the implementation hack
¤ they installed at (as I recall) about VB4. It has nothing to do with
¤ GoSub inherently. In fact, in earlier versions (particularly in real
¤ compiled code of the DOS versions) GoSub was *much* faster than a Sub
¤ or Function. It compiled to a masm Call/Ret pair.
¤
¤ Instead of using the pseudostack hack they came up with they could
¤ have picked any number of other implementation methods including
¤ straight code substitution (like a macro) in which there would be
¤ *zero* call overhead.
¤
¤ Do not confuse performance with behavior. Behavior is a result of
¤ implementation design decisions.

Correct. The decision was to de emphasize its usage, which is one of the reasons they suggest using
Subs and Functions as they had no plans on optimizing it.

¤
¤ Gary is not alone, by a long shot, in his use of GoSub. It's a useful
¤ construct. Like *any* other, it can be misused (care to survey .cls
¤ files of typical projects???). If you've never learned to use GoSub
¤ (or classes!) properly, that's unfortunate but it does not mean they
¤ are bad things that you should expect Microsoft to protect you from.

I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
is.

¤
¤ Duplicate code fragments are a virus in code that lives through years
¤ of maintenance. It's a hard fact that, at some point, one copy of the
¤ fragment will be fixed or enhanced and others will be missed. Its
¤ proper usage is as a code-only container for eliminating duplicate
¤ code fragments.

Problem is it isn't a container but a containee that affects the flow of logic within its container.
It causes the code to branch down and then back up through the code in its container - a prime
example of spaghetti code.

¤
¤ FWIW, Delphi provides almost a direct replacement using their nested
¤ procedures.
¤
¤ By the way, 2 years ago I was told by MS that GoSub was cut due to
¤ lack of time to get in implemented... then I was told it was dropped
¤ on purpose. Dunno which is right.
¤
¤ >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
¤ >you indicate in your following points, I'm surprised that you continued to use GoSub.
¤
¤ In most places I use them it would require extensive parameter lists.
¤ The idea is to eliminate duplicated code fragments for maintenance
¤ reasons, but to replace them with equally long parameter lists or,
¤ (God forbid) module level variables would only trade one problem for
¤ another.

Well I think you know from our past discussions that I will never buy this. First GoSub is a
branching mechanism. Branch and returns (used instead of Subs and Functions) lead to some rather
confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
Functions, causing the same types of problems.

If you are worried about long parameter lists, you can use a parameter array.

¤
¤ >
¤ >¤
¤ >¤ Problem three: Mid$
¤ >¤
¤ >¤ Four hundred times slower in VB.Net. I make extensive use of Mid$. All
¤ >¤ routines that use Mid$ must be rewritten. Is not Mid$ part of the core
¤ >¤ language?
¤ >
¤ >Well Mid is supported but once again you may want to indicate specifically what you are doing. It
¤ >could simply be the .NET environment and not the actual function. And, it's possible the VB.NET
¤ >variation may be relatively easy to implement with a performance improvement.
¤
¤ Hmmm... if they've made Mid$() slow, using your argument of GoSub,
¤ perhaps this means they're about to drop it?

Yes, but the migration path for those Visual Basic functions are likely to remain for quite a while
(as they did for GoSub in "Classic" VB).


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Mike Mitchell]

On 22 Jan 2003 09:23:14 -0800, "Kent" <KP@KP.com> wrote:

>Then they should not have called it VB since calling it VB provides some
>some hope of backward compatibility. They also should have provided VB7
>with managed extensions as Dan and others have suggested. What we have not
>is not acceptable. The jobmarket for VB.Net and overall lack of interest
>in it shows this. The MVP crowd may have talked themselves out of work.

Ah, but they *always* know best, don't they?

MM

[Mike Mitchell]

On Wed, 22 Jan 2003 07:50:32 -0600, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
>you indicate in your following points, I'm surprised that you continued to use GoSub.

It could be replaced by a Sub or a Function, but that would be to
completely miss the point of GoSub! The one way GoSub was extremely
useful was when you had a piece of standard code in a procedure and
you had to execute it again and again. However, suppose the code in
question utilised several variables. If you were to write a separate
Sub or Function, you'd have to pass arguments representing those
variables. This is quite a significant overhead if you're executing
the same bit of code ten times throughout that one procedure. And so
you use GoSub instead. Because GoSub can only sit somewhere inside
your procedure (I tuck mine away at the bottom, following the error
hander), it is "global" to the procedure. That is, whatever variables
are active inside the procedure are automatically available to the
GoSub code.

So you can replace the several lines of code at multiple places in
your procedure with just a GoSub MyRoutine, and it makes the code far
more readable. Also, no overhead is lost through continually passing
arguments to a Sub or Function which would have to be called again and
again instead of using GoSub.

This is why GoSub was and is absolutely the right choice in certain
circumstances.

MM

[Mike Mitchell]

On Thu, 23 Jan 2003 01:19:51 +1100, Jason Sobell iGadget
<igadget_@hotmail.com> wrote:

>How often do you call a function that takes and returns no parameters? This
>is the only time GoSub can be used, unless you are storing your data in
>global variables

Eh? I don't think you can quite understand how GoSub is used! You just
whack a chunk of code at the foot of your procedure (could be
elsewhere, but that's where I place it), stick a label at the start
and a Return at the end. Then you GoSub LabelName, the code in the
GoSub block is executed and hits Return, sending you back to the
statement following the GoSub call. All variables known to the
procedure which contains your GoSub code are also known to the GoSub
code, i.e. you don't have to pass anything!

However, if instead of GoSub you wrote a separate Sub or Function,
you'd have to pass arguments to it to replicate the variables which
are already known within your procedure. So, if you needed to execute
some standard piece of code ten times as your procedure is being
executed overall (we're not in the GoSub code yet!), you have three
choices: (a) Duplicate the code throughout the procedure, (b) Call a
GoSub block, or (c) Call an external Sub or Function. Sometimes option
c is right; sometimes option b is very handy. Option a is almost never
wise.

MM

[Mike Mitchell]

On Wed, 22 Jan 2003 12:34:19 -0000, "Jonathan West" <jwest@mvps.org>
wrote:

>Simply stated in terms of the way they are presented in the language, that
>would be the object model that accesses the .Net framework.

But surely that would require a "VB7 with Managed Extensions" to be
pretty much what VB.Net is already? If it's going to be able to
understand the .Net framework, I mean.

MM

[Dan Barclay]

On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>Correct. The decision was to de emphasize its usage, which is one of the reasons they suggest using
>Subs and Functions as they had no plans on optimizing it.

LOL. Your argument is that they made it slow on purpose? Ya know,
before VB7 came out I wouldn't have believed this but now you've
cleared up a lot of confusion for me.

I was misinformed that they accidentally created an ugly hack to get
around With and some other gotcha's, then were too scared to touch it
once they got it working. Silly me for believing that!

They kinda backed themselves into that hack because of the
interpreter. The sad part is that, now that they're using a pure
compiler, they could have gone to source substitution. It would have
been dead simple, and performance overhead would have been zero.
****, I offered to implement it if they'd provided a preprocessor
hook(s) for the Basic[sic] compiler.

Again, silly me, I didn't realize that they wanted to sabotage it!
So, *** do I know!

>¤ Gary is not alone, by a long shot, in his use of GoSub. It's a useful
>¤ construct. Like *any* other, it can be misused (care to survey .cls
>¤ files of typical projects???). If you've never learned to use GoSub
>¤ (or classes!) properly, that's unfortunate but it does not mean they
>¤ are bad things that you should expect Microsoft to protect you from.
>
>I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
>use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
>is.

Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
makes about as much sense though. I've been outta touch but I'm glad
you're keeping up with 'em.

>¤ Duplicate code fragments are a virus in code that lives through years
>¤ of maintenance. It's a hard fact that, at some point, one copy of the
>¤ fragment will be fixed or enhanced and others will be missed. Its
>¤ proper usage is as a code-only container for eliminating duplicate
>¤ code fragments.
>
>Problem is it isn't a container but a containee that affects the flow of logic within its container.

Certainly it is a container, and it works quite well. You *really*
should learn something about it.

>It causes the code to branch down and then back up through the code in its container - a prime
>example of spaghetti code.

LOL. You've *got* to be kidding. This is exactly what Subs and
Functions do, by your definition, except that they also carry their
own variable space. We've gotta stop that Sub branching, yessireee.

Hmmm... have you been implementing your GoSubs using GoTo's and
branches? Like I said, maybe you should learn something about it.

Sounds like all you want in your toolbox is a hammer. Why do you
insist that everybody else leave their screwdrivers at home as well?

>¤
>¤ FWIW, Delphi provides almost a direct replacement using their nested
>¤ procedures.
>¤
>¤ By the way, 2 years ago I was told by MS that GoSub was cut due to
>¤ lack of time to get in implemented... then I was told it was dropped
>¤ on purpose. Dunno which is right.
>¤
>¤ >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
>¤ >you indicate in your following points, I'm surprised that you continued to use GoSub.
>¤
>¤ In most places I use them it would require extensive parameter lists.
>¤ The idea is to eliminate duplicated code fragments for maintenance
>¤ reasons, but to replace them with equally long parameter lists or,
>¤ (God forbid) module level variables would only trade one problem for
>¤ another.
>
>Well I think you know from our past discussions that I will never buy this. First GoSub is a
>branching mechanism.

Branching mechanism? That's why it was initially implemented with
Call/Ret, huh?

>Branch and returns (used instead of Subs and Functions) lead to some rather
>confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
>Functions, causing the same types of problems.

Nope.

Please see my previous discussion (which you snipped) regarding taking
the effort to properly use it.

Oh, and while you're at it maybe you should educate some of the idiots
on how to use classes before someone gets the bright idea that we
should be protected from those as well.

Holy cow! Just think of the crap someone is going to write using
inheritance!!! ****, I was planning to use that some day and now
they'll probably remove it because it has sharp edges.

>If you are worried about long parameter lists, you can use a parameter array.

Same issue. It adds complexity where none is needed. Keep it
simple...

>¤ Hmmm... if they've made Mid$() slow, using your argument of GoSub,
>¤ perhaps this means they're about to drop it?
>
>Yes, but the migration path for those Visual Basic functions are likely to remain for quite a while
>(as they did for GoSub in "Classic" VB).

Has MS said to migrate from Mid(), or is that just your opinion?

Dan
Language Stability is a *feature* I wish VB had!
(#6)/(#1!)
Error 51
Error 3
Error 9
....