Re: Editorial by Russell Jones/Attack on Gosub

[Dan Barclay]

On Sat, 27 Jan 2001 01:02:43 -0500, "Steve Dee"
<Steve_Dee@md.prestige.net> wrote:

>Dan,
> C++ and C have always had a way to do Gosub/Return (in a matter of
>speaking). Typically it is an inline macro though...or back in the olden
>days you would use a longjump. Does that mean it's a good thing? No...and
>it wasn't and isn't a good thing in BASIC.

Macro could be a GoodThing, and if done right could possibly take the
place of GoSub... particularly if they made it with multiple entry
points. Macro could bloat the executable, but with as much baggage as
we have these days it may not be noticed.

>It's just a holdover from line
>basic, when we didn't have functions or subroutines.

Nope. Still used. It should be provided in all high level languages.

>It's just basically
>BAD STYLE and is NOT faster,more efficient, or more understandable.

Did someone appoint you Style Judge? It is *far* easier to read code
if you use GoSub properly. GoSub stopped being more efficient about
VB4 as I recall. Prior to that it was much faster than a Call. In
fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.

>You
>have a lot of (real) issues to complain about, don't complain about crap
>that should have gone away years ago.

If you don't use GoSub, then it shouldn't bother you. If it's
crap-code when you get through with it then you apparently *should*
leave it alone. GoSub is just another flow control tool and, more to
the point, it is a fundamental part of the Basic Language. You can
use it or abuse it like any other tool. But, without it the language
isn't Basic.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jeff Peil]

"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:c5a77t4qpur6ve7a8e3qm1nppglpdbcf9t@4ax.com...
>
> Macro could be a GoodThing, and if done right could possibly take the
> place of GoSub... particularly if they made it with multiple entry
> points. Macro could bloat the executable, but with as much baggage as
> we have these days it may not be noticed.

If you ask me, function-like macros are often abused, miunderstood, and a
cause of many erros that are very hard to detect when reading the code.
They *are not* functions, C++ took a much better road with the concept of
inline functions (where you basically are explicitly asking the compiler to
consider inlining a function.) Just to give a good example, one of the more
prominent C++ compiler verification suites recently released an update that
broke ~5 of their tests because they had a function-like macro that looked
roughly like

#define funcmacro(a, b) somecall( (void*)a, (void*)b)

and then they roughly used in it their tests like

funcmacro(var1 + sizeof(sometype), var2 + sizeof(someothertype));

Which after expanding from the preprocessor looks to the parser like

somecall((void*)var1 + sizeof(sometype), (void*)var2 +
sizeof(someothertype));

This of course doesn't work because the usage of the macro expects the
arguments to be evaluated *before* the cast to a void*, and instead the
first portion of each are is cast to a void* and then the addition is
attempted.

The point is, these are tests being written by people to test standards
compliance, so they should have a decent understanding of the language, and
yet they still make this type of error when using function-macros.

> Nope. Still used. It should be provided in all high level languages.

I'm not going to tell you it doesn't belong in basic, but I think that "all
high level languages" is far from accurate.

Personally I believe that there are more elegant mechanisms that a language
can provide, for both goto and gosub in places they are traditionally used
(though I will conceed that there are, at least for goto, a few cases where
it can be a reasonable choice but that's primarily in highly optimized code,
such as heap management routines used in a runtime library, but removing it
from a language as was done with Java is not terribly limiting even when
optimizing*)

*Of course with more modern processors and compilers, this is even less of
an issue, as they can usually generate near optimal code using other flow
control structures that have better scoping rules.

> If you don't use GoSub, then it shouldn't bother you. If it's
> crap-code when you get through with it then you apparently *should*
> leave it alone. GoSub is just another flow control tool and, more to
> the point, it is a fundamental part of the Basic Language. You can
> use it or abuse it like any other tool. But, without it the language
> isn't Basic.

I think you could say that about a lot of things even in traditional MS
Basic, it is not ANSI Basic.

It is fair to say that this is one reason why VB.NET, the language, is not
the language used in VB6. However, if you consider all the variants of
Basic out their that all include basic in their name I don't see how you can
point at one language flow control mechanism and say "to be Basic it must
have this"

[Jeff Peil]

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
in message news:3a73fbf4$1@news.devx.com...
>
> Adding language features and then dropping them without even adding a
> version or three to deprecate them effectively is a BAD thing. Because
> people need time to handle the inertia of these large projects, steering
> them on a new course. THAT is why language stability IS a feature!
>

MichKa,

Understand I'm a big proponent of language stability. I don't disagree with
your points, however I don't see why they apply?

My point was that Dan has every right to call the removal of gosub when
moving between VB6 and VB.NET enough of a change to make the languages
different.

However, I don't think that it alone can be pointed at as the *defining*
feature of languages considered to be dialects of Basic (IOW, if you took
VB6 and just removed gosub support, I think you'd have a hard time making
the cas ethat it is no longer a dialect of Basic.)

[Mark Burns]

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
in message news:3a7486df$1@news.devx.com...
> How many changes would it take to deserve the label of ~BASIC? 1000? 500?
> 200? 100? 50? 10?

Hmmm...sounds like the age-olde "How many Angels can dance on the head of a
pin?" merry-go-round.

> It seems like there is a biblical precedent for this one in Genesis, is
> there not?Abraham arguing with God about backwards compatibility with the
> programs running in Sodom or somesuch? <g>

Hoo boy...when you stretch to make a point, you r-e-a-l-l-y like to
s---t---r---e---t---c---h quite a distance to make it doncha?<g>

[Mark Burns]

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
in message news:3a7491f8$1@news.devx.com...
> "Mark Burns" <mark@iolofpa.com> wrote in message
> news:3a748c73@news.devx.com...
>
> > Hoo boy...when you stretch to make a point, you r-e-a-l-l-y like to
> > s---t---r---e---t---c---h quite a distance to make it doncha?<g>
>
> Ah, well I think they changed the scenario of the argument so that
> non-programmers would understand it when it was laid out in the bible,
thats
> all. They simplified it from "good programmers vs. poor programmers" into
> righteous vs. wicked/evil. So they sent out those three consultants to
raze
> the project.
>
> Any Christian will point out that programming has been an interest ever
> since it became clear how important it was that Jesus saves. <vbseg>
>
> (well, slightly bored and it is Sunday!)

Well for pity's sake...log off and go watch the Superbowl pre-game
as-nauseum hype shows for a while...before you _embarrass_ yourself!<bg>

[Joe \Nuke Me Xemu\ Foster]

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in message <news:3a73fbf4$1@news.devx.com>...

> Adding language features and then dropping them without even adding a
> version or three to deprecate them effectively is a BAD thing. Because
> people need time to handle the inertia of these large projects, steering
> them on a new course. THAT is why language stability IS a feature!

You wussie. REAL PROGRAMMERS can redesign and rewrite megaline mission-
critical apps overnight, anywhere, anytime. Either that or they finagle
a promotion out of the trenches ASAP!

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[David Bayley]

> But a lot of people are going to be hurt by this nonsense.

The port is painful yes, but the reasons being advocated are being blown out
of proportion.

I say that from experience of porting VB5 apps to C#, where the "gratuitous
incompatibilities" of VB.NET are nothing by comparison! All the logic ports
over easily. The vast majority of testing and bug ironing I did in VB5, is
carried over to the new C# versions easily. The syntax differences really
aren't the problem.

The pain comes from porting to the new frameworks and platform, and
re-designing to take advantage of implementation inheritance. From a
business point of view, porting to .NET should only be done to take
advantage of these features.

Having said that, I agree that the gratuitous incompatibilities will make
maintaining parallel code bases in VB5 and VB.NET frustrating. So IMO,
things like Wend/EndWhile and Integer/Long ain't worth it, whereas BitOr and
System.Boolean are. I also agree that dumping Gosub is well out of order,
let alone not deprecating it first.

In short, they could've made it less painful, but far from painless.

--
David.

[Dan Barclay]

On Sun, 28 Jan 2001 01:56:26 -0800, "Jeff Peil" <jpeil@bigfoot.com>
wrote:

>
>"Dan Barclay" <dbarclay@ih2000.net> wrote in message
>news:c5a77t4qpur6ve7a8e3qm1nppglpdbcf9t@4ax.com...
>>
>> Macro could be a GoodThing, and if done right could possibly take the
>> place of GoSub... particularly if they made it with multiple entry
>> points. Macro could bloat the executable, but with as much baggage as
>> we have these days it may not be noticed.
>
>If you ask me, function-like macros are often abused, miunderstood, and a
>cause of many erros that are very hard to detect when reading the code.

I would guess that's right. After sleeping on the Macro as a
replacement for Gosub thing, I'm not so confident it would work.
FWIW, I was thinking of it more in terms of a code fragment
substitution ("named" Include?) rather than a call-like-thing. I
think that would work, except that you'll find that GoSubs with
multiple exit points (and even entry points) are sometimes used.

Actually I guess even that could be implemented if the compiler used
pseudo labels. Yea, I'm pretty sure that would work... an easy fix
for the compiler and the code would look exactly the same to us.

>They *are not* functions, C++ took a much better road with the concept of
>inline functions (where you basically are explicitly asking the compiler to
>consider inlining a function.) Just to give a good example, one of the more
>prominent C++ compiler verification suites recently released an update that
>broke ~5 of their tests because they had a function-like macro that looked
>roughly like
>
>#define funcmacro(a, b) somecall( (void*)a, (void*)b)
>
>and then they roughly used in it their tests like
>
>funcmacro(var1 + sizeof(sometype), var2 + sizeof(someothertype));
>
>Which after expanding from the preprocessor looks to the parser like
>
>somecall((void*)var1 + sizeof(sometype), (void*)var2 +
>sizeof(someothertype));
>
>This of course doesn't work because the usage of the macro expects the
>arguments to be evaluated *before* the cast to a void*, and instead the
>first portion of each are is cast to a void* and then the addition is
>attempted.

Of course, with Basic there are no parameters on GoSubs, so it's just
a inlining code. BUT, the gosub definitions are only valid within the
procedure scope.

>The point is, these are tests being written by people to test standards
>compliance, so they should have a decent understanding of the language, and
>yet they still make this type of error when using function-macros.

You'd think so <g>.

>> Nope. Still used. It should be provided in all high level languages.
>
>I'm not going to tell you it doesn't belong in basic, but I think that "all
>high level languages" is far from accurate.
>
>Personally I believe that there are more elegant mechanisms that a language
>can provide, for both goto and gosub in places they are traditionally used
>(though I will conceed that there are, at least for goto, a few cases where
>it can be a reasonable choice but that's primarily in highly optimized code,
>such as heap management routines used in a runtime library, but removing it
>from a language as was done with Java is not terribly limiting even when
>optimizing*)

Many times there are more elegant solutions with just the options we
have in Basic. Sometimes not. When you have a hammer, everything is
not a nail. Does't mean the hammer isn't useful sometimes.

>*Of course with more modern processors and compilers, this is even less of
>an issue, as they can usually generate near optimal code using other flow
>control structures that have better scoping rules.

Of course, we're talking about this from the language standpoint. The
compiler could do all sorts of things "under the hood" to implement
and then optimize the emitted code.

>> If you don't use GoSub, then it shouldn't bother you. If it's
>> crap-code when you get through with it then you apparently *should*
>> leave it alone. GoSub is just another flow control tool and, more to
>> the point, it is a fundamental part of the Basic Language. You can
>> use it or abuse it like any other tool. But, without it the language
>> isn't Basic.
>
>I think you could say that about a lot of things even in traditional MS
>Basic, it is not ANSI Basic.

I was too broad. In the context of the discussion I was thinking "MS
Basic". That is not the same as ANSI Basic as you point out. For
developers on this path, the MS Basic de-facto standard is the measure
of compliance.

>It is fair to say that this is one reason why VB.NET, the language, is not
>the language used in VB6. However, if you consider all the variants of
>Basic out their that all include basic in their name I don't see how you can
>point at one language flow control mechanism and say "to be Basic it must
>have this"

Agreed. I'm speaking from the point of view of a developer who's used
and counted on the MS Basic language since dirt was invented.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Karl E. Peterson]

Hi Patrick --

Class methods weren't a suitable alternative either, necessarily. There's overhead
with those that goes far beyond the IP push. (Just to emphasize, this is
"over-the-top" tuning, for routines that just can't be squeezed any other way.)

Later... Karl
--
http://www.mvps.org/vb


"Patrick Steele" <psteele@ipdsolution.com_> wrote in message
news:MPG.14dcd64fba32c5ab989694@news.devx.com...
> In article <MPG.14dcd2b04bb7ba7298968b@news.devx.com>,
> drothgery@myrealbox.com says...
> > Patrick Steele <psteele@ipdsolution.com_> wrote:
> > >
> > > True, but his example did at least show a form of encapsulation.
> > >
> > > With global access, any function within the module/class will have the
> > > potential to muck with the values.
> >
> > Well, yeah.
> > But what's the point of putting functions in an object if they're not
> > supposed to work on the same [presumably private to the object] data?
>
> Ok. I was under the impression that this was older VB code (pre-VB4) and
> he didn't have access to classes. In that situation, the GOSUB really
> gave a decent form of encapsulating the data within that one function
> (which may have been inside a huge, global .BAS module).
>
> But if this was post VB3, then I agree with you. It probably would have
> been more efficient to move it into a class.
>
> --
> Patrick Steele
> (psteele@ipdsolution.com)
> Lead Software Architect

[Patrick Steele]

In article <3a75dc39$1@news.devx.com>, karl@mvps.org says...
> Hi Patrick --
>
> Class methods weren't a suitable alternative either, necessarily. There's overhead
> with those that goes far beyond the IP push. (Just to emphasize, this is
> "over-the-top" tuning, for routines that just can't be squeezed any other way.)

Yes. I had the performance issue in mind when I said:

> > It probably would have
> > been more efficient to move it into a class.

"probably would have been" -- Since I didn't know the whole situation, I
didn't want to pin myself down to a "it SHOULD have been converted". See
-- I can learn from my mistakes of spouting off too quickly <g>

If you need a "fast as possible" solution, the overhead of instantiating
and manipulating an object would be a negative.

--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect

[Steve Dee]

Dan,
> the point, it is a fundamental part of the Basic Language. You can
> use it or abuse it like any other tool. But, without it the language
> isn't Basic.

Visual Basic hasn't been "Basic" in the classic sense for a long time. You
know that.

> Did someone appoint you Style Judge? It is *far* easier to read code
> if you use GoSub properly. GoSub stopped being more efficient about

Well yes they did...but not the "Style Judge" of the world. Sometimes it's
hard to get my day job out of my "newsgroup" posts. Part of my job (among
other things) for the past 10 years has been to be the "Style Judge/Code
Cop, etc." Someone must think it is worthwhile or people would quit
recruiting me away from places.

I really don't think that Gosub is easier to read, even if used "properly".
I also think it's a bad idea to expose new programmers to something that the
language dealer (for years) has told us is going away someday.

> VB4 as I recall. Prior to that it was much faster than a Call. In
> fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.

Sure it was...did the speed alone mean it was a good thing? I think
not....and it was more than likely a jmp/ret pair. But if you wanted pure
speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
many routines in ASM for just that reason.

[Dan Barclay]

On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
<Steve_Dee@md.prestige.net> wrote:

>Dan,
> > the point, it is a fundamental part of the Basic Language. You can
> > use it or abuse it like any other tool. But, without it the language
> > isn't Basic.
>
>Visual Basic hasn't been "Basic" in the classic sense for a long time. You
>know that.

It's been a (fairly) consistent language, with all it's parts.

>
>> Did someone appoint you Style Judge? It is *far* easier to read code
>> if you use GoSub properly. GoSub stopped being more efficient about
>
>Well yes they did...but not the "Style Judge" of the world. Sometimes it's
>hard to get my day job out of my "newsgroup" posts. Part of my job (among
>other things) for the past 10 years has been to be the "Style Judge/Code
>Cop, etc." Someone must think it is worthwhile or people would quit
>recruiting me away from places.
>
>I really don't think that Gosub is easier to read, even if used "properly".
>I also think it's a bad idea to expose new programmers to something that the
>language dealer (for years) has told us is going away someday.

Well, the joke's on you. You are wrong. GoSub is a very handy
construct and is not a bad habit. As I've shown before with
pseudo-code examples it's a good way to avoid repeating code fragments
when full-blown procedures are not in order. It's also a good way to
organize code and separate functional fragments from higher level
logic. Repeated code fragments are an open invitation to maintenance
headaches.

>
>> VB4 as I recall. Prior to that it was much faster than a Call. In
>> fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.
>
>Sure it was...did the speed alone mean it was a good thing? I think
>not....and it was more than likely a jmp/ret pair. But if you wanted pure
>speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
>many routines in ASM for just that reason.

What the **** are you talking about??? jmp/ret pair? jmp puts
nothing on the stack! Now *that* could explain some of your problems!
Is the rest of your "style judge" based background as effective?

I should do *what* in assembler? You mean wrap some Basic code
fragments in assembler and call it? If you mean writing tight code in
ASM, that's exactly what I'd do... but that's not what we're
discussing here.

Back to the points: (1) GoSub is a good tool for writing maintainable
code and (2) in previous versions there was *no* performance penalty
compared to any other method of procedure call. In fact, on
performance there was no comparison with a Sub/Function call.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Steve Dee]

Dan,
> It's been a (fairly) consistent language, with all it's parts.

Has it? Look at this:

Unsupported Keywords
Visual Basic for Windows omits about 100 keywords that are supported by
Visual Basic for MS-DOS. Using any of these keywords in the MS-DOS
application that you convert to Windows results in omitted functionality.
You must rewrite any code that relies on these keywords:



ALL INKEY$ SEEKEQ
BLOAD INP SEEKGE
BOF INSERT SEEKGT
BSAVE IOCTL SEG
CALLS IOCTL$ SETINDEX
CDECL ISAM SETMEM
CHAIN KEY SETUEVENT
CHECKPOINT LIST SIGNAL
COLOR LOCATE SLEEP
COM LPOS SOUND
COMMON LPRINT SSEG
CREATEINDEX MKC$ SSEGADD
CSRLIN MKDMBF$ STACK
CVI MKI$ STICK
CVC MKL$ STRIG
CVD MKS$ SWAP
CVDMBF MKSMBF$ SYSTEM
CVL OUT TEXTCOMP
CVS PAINT TRON
CVSMBF PALETTE TROFF
DELETEINDEX PCOPY UEVENT
DELETETABLE PEEK UPDATE
DRAW PEN VARPTR
ERDEV PLAY VARPTR$
ERDEV$ PMAP VARSEG
EVENT POS VIEW
FIELD PRESET WAIT
FILES RUN WINDOW
FN SADD
FRE SAVEPOINT
GETINDEX$ SCREEN
NOTE: Visual Basic for Windows does not support DEF FN functions.
Different Coding Mechanisms
The scoping mechanisms in Visual Basic for MS-DOS are different from those
in Visual Basic for Windows, as shown by this table:

Visual Basic MS-DOS construction Visual Basic for Windows equivalent
COMMON SHARED Public
DIM SHARED (at module level) Dim (at module level)
SHARED attribute (procedure level) None. Use module-level variable, which is
visible to all procedures
COMMON None. Module-level [ASCII 150] only variables are not useful in
Visual Basic for Windows

Visual Basic for MS-DOS applications cannot display forms and graphics at
the same time. This limitation does not exist in Visual Basic for Windows.
Code that displays graphics must be completely rewritten for use in Windows.

> Well, the joke's on you. You are wrong. GoSub is a very handy
> construct and is not a bad habit. As I've shown before with
> pseudo-code examples it's a good way to avoid repeating code fragments
> when full-blown procedures are not in order. It's also a good way to
> organize code and separate functional fragments from higher level
> logic. Repeated code fragments are an open invitation to maintenance
> headaches.

And I still disagree. You could do the same with different constructs.

> What the **** are you talking about??? jmp/ret pair? jmp puts
> nothing on the stack! Now *that* could explain some of your problems!

So you are trying to say that the "classic" Gosub put something on the
stack? I simply said that a "Call/Ret" was more likely a jmp/ret....as it
was in line basic. Or do you not remember that?

> Is the rest of your "style judge" based background as effective?

Must be.....I'm doing quite well thank you very much.

> Back to the points: (1) GoSub is a good tool for writing maintainable
> code and (2) in previous versions there was *no* performance penalty

Since when? Look I really don't want to argue with you and have stated that
someone with a old massive code base such as you have has a problem......I
feel for you. But I don't think that is a good enough reason to hang on or
***** about something that should not be in a modern language.

[Dan Barclay]

On Tue, 30 Jan 2001 00:19:39 -0500, "Steve Dee"
<Steve_Dee@md.prestige.net> wrote:

>Dan,
>> It's been a (fairly) consistent language, with all it's parts.
>
>Has it? Look at this:

Absolutely. I've stated a number of times that there are 3 occasions
where MS has broken MS Basic. Each time with more gusto, this time
with devastation.

VB1 resulted in loss of a number of keywords. *most* but not all were
a result of the environment change. The gratuitous changes were
things like FIELD, CVx() and friends, MKx$() and friends and several
others.

You will also note that VBDOS came out *AFTER* VB for Windows. Many
of the keywords listed below are from the lame ISAM library that was
an add-on library starting with PDS. Those, were linked library
functions and not a part of the core Basic language.

What's more, as I've said *many* times before, I have no beef with
changes to the language that are caused by a change in the
environment. PEEK/POKE/FRE()/ and user I/O are environment related.

I mentioned there were two major hits. VB1 was one, VB4 was the
second. In that change they added Unicode 'support'. In adding this
new type of data they did *not* add a new data type. Instead they
hijacked the $tring data type. In prior versions the *only*
documented way to handle binary data was with $trings. With VB4/32
$trings were documented to corrupt binary data. Millions of lines of
code broken in one fell swoop.

>> Well, the joke's on you. You are wrong. GoSub is a very handy
>> construct and is not a bad habit. As I've shown before with
>> pseudo-code examples it's a good way to avoid repeating code fragments
>> when full-blown procedures are not in order. It's also a good way to
>> organize code and separate functional fragments from higher level
>> logic. Repeated code fragments are an open invitation to maintenance
>> headaches.
>
>And I still disagree. You could do the same with different constructs.

You can do a lot of things with different constructs. You don't need
"If" anymore either. Anything you can do with "If" you can do with
"Select Case". Do you really think you have justification for
eliminating "If"?

>
>> What the **** are you talking about??? jmp/ret pair? jmp puts
>> nothing on the stack! Now *that* could explain some of your problems!
>
>So you are trying to say that the "classic" Gosub put something on the
>stack? I simply said that a "Call/Ret" was more likely a jmp/ret....as it
>was in line basic. Or do you not remember that?

Yes, "Classic" GoSub put something on the stack.

====The source:====
dim i%
gosub ThisSub
end
ThisSub:
i%=i%+1
return
====compiles to:=====

PAGE 1

30 Jan 01

13:10:29
Offset Data Source Line Microsoft (R) Visual Basic (TM) for
MS-DOS (R)

0030 ** I00002: call I00003
0033 ** call B$CEND
0038 ** I00003: inc i%
003C ** ret

=======================
Please note the 'call I00003' to offset 0038, with the ret following.

You'll also note that the i%=i%+1 compiles to a single inc.

>> Is the rest of your "style judge" based background as effective?
>
>Must be.....I'm doing quite well thank you very much.

We get it here for free... and I must say it's worth every cent. You
don't make something better by removing features.

>> Back to the points: (1) GoSub is a good tool for writing maintainable
>> code and (2) in previous versions there was *no* performance penalty
>
>Since when? Look I really don't want to argue with you and have stated that
>someone with a old massive code base such as you have has a problem......I
>feel for you. But I don't think that is a good enough reason to hang on or
>***** about something that should not be in a modern language.

LOL!

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Mike Mitchell]

On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
<Steve_Dee@md.prestige.net> wrote:

>Sure it was...did the speed alone mean it was a good thing? I think
>not....and it was more than likely a jmp/ret pair. But if you wanted pure
>speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
>many routines in ASM for just that reason.
>

That's right! Why simplify when you can obfuscate? Of COURSE most
anything could have been done in assembly language, but you're
incriminating the humble GoSub with far more than it deserves. It
wasn't used for speed, it was used for structure - in the days when
precious few other constructs were available. Why can't you just
accept that GoSub has been around for years, does a perfectly adequate
job in the right hands, has largely been superseded by functions, but
still didn't deserve to be summarily executed for being ancient. No
one is *forcing* you or anyone else to use it!

MM