Re: Editorial by Russell Jones/Attack on Gosub

[Dan Barclay]

Absolutely, positively, correct as has been pointed out by those who
know the language many times.

Some folks just don't get it. If *they* don't want to use it they can
just leave it alone.

FWIW, I think C# and C++ need this badly. Many times algorithms need
to be corralled, but they don't always need to be a separate proc.
GoSub is perfect for that. Great tool.

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

[Dan Barclay]

On 26 Jan 2001 17:28:56 -0800, "Patrick Troughton" Patrick wrote:

>
>Dan Barclay <dbarclay@ih2000.net> wrote:
>>Absolutely, positively, correct as has been pointed out by those who
>>know the language many times.
>
>Ah, so by that logic, those who disagree do so only because the don't know
>the language? Give me a break. You're not fooling anyone.

No, but many who comment on how degenerate it is to use Gosub
certainly don't. You seem to be applying the reverse of that logic.

>> If *they* don't want to use it they can
>>just leave it alone.
>
>Ah, so by that logic, if you don't want to use it (VB.NET), you can just
>leave it alone. HTH!

Not trying to get VB.not changed, just trying to get them to include
VB in .net.

>
>>FWIW, I think C# and C++ need this badly.
>
>If only C++ had a Gosub/Return, it might escape obscurity and finally get
>the respect it deserves for all these years....

Probably. At least from the folks who do use it.

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

[Jake Jones jake615_]

I think Russell's attack on Gosub was misguided.

There's nothing inherently kludgey or unstructured in the Gosub/Return construct
properly used, and it in fact can often add to the clarity and simplicity
of the code. Gosub/Return is particularly useful for isolating involved
alogorithm implmentation code from the logical flow of a procedure. By
moving the implementation into a local subroutine, the logic of the code
segment can be made much more comprehensible to someone who is looking at
the code for the first time.

For example:

Sub DoSomething()
If someCondition then
gosub Special_Algorithm
else
[statements]
End if
exit sub

Special_Algorithm:
[long series of statements]
Return
End Sub


(imagine instead that the else clause was 150 lines down further into the
procudure if the whole of Special Alogorithm was included within the if structure.)

Making a separate procedure out of the algorithm renders the module less
comprehensible, because there is no clue in the structure of the module that
some private sub which implements the alogorithm is really only a part of
the implementation of Sub DoSomething (and should not be called by any other
method of the class.) Further if the routine within the gosub relies on
a lot of DoSomething's local variables or parameters, turning the alogorithm
into its own procedure means you've got to pass all of DoSomething parameters
and local variables to the new routine, or clutter up the namespace by giving
what would otherwise be local variables module visibility.

[Patrick Troughton Patrick]

Dan Barclay <dbarclay@ih2000.net> wrote:
>Absolutely, positively, correct as has been pointed out by those who
>know the language many times.

Ah, so by that logic, those who disagree do so only because the don't know
the language? Give me a break. You're not fooling anyone.

> If *they* don't want to use it they can
>just leave it alone.

Ah, so by that logic, if you don't want to use it (VB.NET), you can just
leave it alone. HTH!

>FWIW, I think C# and C++ need this badly.

If only C++ had a Gosub/Return, it might escape obscurity and finally get
the respect it deserves for all these years....

/Pat

[Phil Weber]

> Ah, so by that logic, if you don't want to use it (VB.NET),
> you can just leave it alone. HTH!

Patrick: If Microsoft provided a compatible upgrade path from VB6, I suspect
he would. Dan's issue (if I may presume to speak for him) is not with VB.NET
per se, it's with the fact that it's incompatible with VB6 code.
---
Phil Weber

[Steve Dee]

Jake,
This was a joke right? I can't believe that you were serious about this.

<Jake Jones jake615_> wrote in message news:3a721ada$1@news.devx.com...
>
> I think Russell's attack on Gosub was misguided.
>
> There's nothing inherently kludgey or unstructured in the Gosub/Return
construct
> properly used, and it in fact can often add to the clarity and simplicity
> of the code. Gosub/Return is particularly useful for isolating involved
> alogorithm implmentation code from the logical flow of a procedure. By
> moving the implementation into a local subroutine, the logic of the code
> segment can be made much more comprehensible to someone who is looking at
> the code for the first time.
>
> For example:
>
> Sub DoSomething()
> If someCondition then
> gosub Special_Algorithm
> else
> [statements]
> End if
> exit sub
>
> Special_Algorithm:
> [long series of statements]
> Return
> End Sub
>
>
> (imagine instead that the else clause was 150 lines down further into the
> procudure if the whole of Special Alogorithm was included within the if
structure.)
>
> Making a separate procedure out of the algorithm renders the module less
> comprehensible, because there is no clue in the structure of the module
that
> some private sub which implements the alogorithm is really only a part of
> the implementation of Sub DoSomething (and should not be called by any
other
> method of the class.) Further if the routine within the gosub relies on
> a lot of DoSomething's local variables or parameters, turning the
alogorithm
> into its own procedure means you've got to pass all of DoSomething
parameters
> and local variables to the new routine, or clutter up the namespace by
giving
> what would otherwise be local variables module visibility.
>
>

[Steve Dee]

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. It's just a holdover from line
basic, when we didn't have functions or subroutines. It's just basically
BAD STYLE and is NOT faster,more efficient, or more understandable. You
have a lot of (real) issues to complain about, don't complain about crap
that should have gone away years ago.

"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:lv547tc5msrf5mbes3p97ba3ve8s7dbp5p@4ax.com...
> On 26 Jan 2001 17:28:56 -0800, "Patrick Troughton" Patrick wrote:
>
> >
> >Dan Barclay <dbarclay@ih2000.net> wrote:
> >>Absolutely, positively, correct as has been pointed out by those who
> >>know the language many times.
> >
> >Ah, so by that logic, those who disagree do so only because the don't
know
> >the language? Give me a break. You're not fooling anyone.
>
> No, but many who comment on how degenerate it is to use Gosub
> certainly don't. You seem to be applying the reverse of that logic.
>
> >> If *they* don't want to use it they can
> >>just leave it alone.
> >
> >Ah, so by that logic, if you don't want to use it (VB.NET), you can just
> >leave it alone. HTH!
>
> Not trying to get VB.not changed, just trying to get them to include
> VB in .net.
>
> >
> >>FWIW, I think C# and C++ need this badly.
> >
> >If only C++ had a Gosub/Return, it might escape obscurity and finally get
> >the respect it deserves for all these years....
>
> Probably. At least from the folks who do use it.
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Denis Cléroux]

> 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. It's just a holdover from line
> basic, when we didn't have functions or subroutines. It's just basically
> BAD STYLE and is NOT faster,more efficient, or more understandable. You
> have a lot of (real) issues to complain about, don't complain about crap
> that should have gone away years ago.

Steve,

I actually ran, once, in a situation when GOSUB-RETURN was the *ONLY*
way of implementing a faster, more efficient, more understandable code. All
in good style.

I once wrote a scientific-oriented software in which I had an algorithm
that had over 30 variables to deal with. This algorithm was required for
different variables values within a single function - with slightly
different variable values, of course. Now, the code looked somewhere like
this:

--------------------------------------------
Function MyFunction(var1, var2, var3)
. . .
'Declare and set MANY variables...
. . .
Gosub DoAlgorithm
. . .
'Change some variables
. . .
Gosub DoAlgorithm

If SomeCondition Then
'Change some other variables
Gosub DoAlgorithm
Else
'Change different variables
Gosub DoAlgorithm
End If

Exit Function

DoAlgorithm:
'My very-very complicated algorithm with 30+ variables
Return

End Function

--------------------------------------------

Now, I don't mind writting functions or subroutine that have 5, 10 or 15
parameters. But when the function requires more than 30 parameters, then the
overhead of passing these variables to the function though the stack (ByVal
or ByRef) really *DO* adds up. Gosub-Return helped me, on this single
context, to avoid passing a long list of variables many times to a single
function, a function that wasn't required anywhere else in the program.

This function was simpler, faster and easier to manage than any other
alternative I could think -- and no, I couldn't pass the variables out using
an array. This algorithm implied multiple complex numbers (enclosed within a
Type structure), Double precision numbers, integers and boolean values. Even
more, each variable names were very important to maintain for clarity.

True: using a function for my algorithm would have been academically
correct, probably more up-to-date structurally speaking - but certainly not
as efficient on speed and memory, easier to read, to maintain and to run.

Stop thinking that because a situation never occured to you to use a
particular statement or function, implies that no one else requires it, that
it should be considered obsolete and should be removed -- we have enough of
Microsoft thinking this way.

Denis Cleroux

** VB.NET promotes reusable code -- simply rewrite everything from scratch.

[Zane Thomas]

On Sat, 27 Jan 2001 01:38:23 -0500, "Denis Cléroux"
<denis.cleroux@cgocable.ca> wrote:

>Now, I don't mind writting functions or subroutine that have 5, 10 or 15
>parameters. But when the function requires more than 30 parameters, then the
>overhead of passing these variables to the function though the stack (ByVal
>or ByRef) really *DO* adds up.

Which is why in .net you would pass a reference to a structure, or maybe
even some other object, instead of passing the whole pile of variables.
There _are_ realistic alternatives to GoSub.

Personally I'd rather dig ditches than work with 30 variables at a time,
but then I haven't done much scientific programming so I have to assume
there are algorithms which really cannot be expressed any other way.

But hey, speaking of 'some other object' (a class) here's an idea, I hope
<g>:

So let's go with your example, more or less, I assume the details are not
important. You have some monster algorithm with 26 variables (a thru z)
and you want to use it as described in your post. How about creating a
helper class (guess it _could_ be static) to encapsulate that part of it:

class HelperClass
{
// 26 variables
int a;
...
Something z;

//
// there's a constructor here, I just didn't write it :-)
//


void MonsterAlgorithm1()
{
// code I never hope to see in my lifetime
}

void MonsterAlgorithm2()
{
// more of my worst nightmare
}
}

For some reason or other you wrote that in c# - don't know why. :-) But
anyway, now we're in your VB code:

Function MyFunction(var1, var2, var3)
. . .
' WAS: Declare and set MANY variables...
' IS:
Dim foo As new HelperClass( many variables passed here? );
. . .
foo.MonsterAlgorithm1()
. . .
'Change some variables
' ok :-)
foo.a = 1
foo.b = 123.456
. . .
foo.MonsterAlgorithm1()

If SomeCondition Then
'Change some other variables
foo.MonsterAlgorithm1()
Else
'Change different variables
foo.MonsterAlgorithm2()
End If

Exit Function


Does that work for you?



---
Ice Z - Straight Outta Redmond

[David A. Rothgery]

Denis Cléroux <denis.cleroux@cgocable.ca> wrote:
> Now, I don't mind writting functions or subroutine that have 5, 10 or 15
> parameters. But when the function requires more than 30 parameters, then the
> overhead of passing these variables to the function though the stack (ByVal
> or ByRef) really *DO* adds up. Gosub-Return helped me, on this single
> context, to avoid passing a long list of variables many times to a single
> function, a function that wasn't required anywhere else in the program.

Y'know, there's nothing wrong with module, class, or structure-level
data...

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

[Patrick Steele]

In article <MPG.14dc8f093b3d1aa4989689@news.devx.com>,
drothgery@myrealbox.com says...
>
> Y'know, there's nothing wrong with module, class, or structure-level
> data...
>

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.

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

[David A. Rothgery]

Patrick Steele <psteele@ipdsolution.com_> wrote:
> drothgery@myrealbox.com says...
> >
> > Y'know, there's nothing wrong with module, class, or structure-level
> > data...
> >
>
> 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?

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

[Patrick Steele]

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

[Mike Mitchell]

On Fri, 26 Jan 2001 17:42:52 -0800, "Phil Weber" <pweber@devx.com>
wrote:

> > Ah, so by that logic, if you don't want to use it (VB.NET),
> > you can just leave it alone. HTH!
>
>Patrick: If Microsoft provided a compatible upgrade path from VB6, I suspect
>he would. Dan's issue (if I may presume to speak for him) is not with VB.NET
>per se, it's with the fact that it's incompatible with VB6 code.
>---
>Phil Weber
>
Oh, Phil! Thank you thank you thank you! At last a line I like from
one of the movers and shakers at Fawcette Towers (sorry, DevX!!).
"...the fact that it's incompatible with VB6 code." Cor blimey, I
think I'll print that out in big letters and hang it on my bedroom
wall so that it's the first thing I see when I wake up!

MM

[Mike Mitchell]

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. It's just a holdover from line
>basic, when we didn't have functions or subroutines. It's just basically
>BAD STYLE and is NOT faster,more efficient, or more understandable. You

So if you have:

Sub AnyRoutine

code a...
xxx arg1, arg2, arg3, arg4

code b...
xxx arg1, arg2, arg3, arg4

code c...
xxx arg1, arg2, arg3, arg4

code d...
xxx arg1, arg2, arg3, arg4

End Sub

you could either replace xxx arg1, arg2, arg3, arg4 by

Sub xxx (arg1, arg2, arg3, arg4)

End sub


or you could do GoSub xxx. So with a extra call-out your routine would
be:

Sub AnyRoutine

code a...
xxx arg1, arg2, arg3, arg4

code b...
xxx arg1, arg2, arg3, arg4

code c...
xxx arg1, arg2, arg3, arg4

code d...
xxx arg1, arg2, arg3, arg4

End Sub

(which kind of looks pretty similar to the inline code we started out
with)

or with GoSub it would be:

Sub AnyRoutine

code a...
GoSub xxx

code b...
GoSub xxx

code c...
GoSub xxx

code d...
GoSub xxx

End Sub

(BTW, I deliberately left out the actual GoSub block, so as not to
confuse OOP programmers. Equally I left out the extra subroutine for
the call-out alternative, just to be fair to all my readers.)

Now, let us look again at those bad, bad things you claimed:

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

More understandable? In the GoSub version the actual code that gets
executed is in the GoSub block in the same subroutine right in front
of me, therefore I can read it in situ and understand immediately how
it is 'called' and where from. Also I know it cannot be 'called' from
outside of the subroutine. I know quite a lot about the code in fact.
And I don't first have to look at a different subroutine to find out
what the code does. Don't know about you, but when I read a book, I
like everything to be on the same page, not half of it on the page I'm
reading and the other half in the glossary. I'm a footnotes kind of a
guy, not an endnotes one.

More efficient? In stack push/pop terms? Let's see, in the call-out
method I have to push each one of the four arguments on to the stack
before the call, and then pop them off once I arrive at the called
routine. In the case of GoSub, I can implement a jump and return,
since I don't have to transfer any arguments. You still think it's not
more efficient?

Not faster? Well, I haven't done any timings, but I would suggest
(it's only a suggestion, mind you, so don't get your knickers in a
bunch) that pushing and popping four arguments will inevitably take
more machine cycles than a jump and return, and so if we assume that a
jump, a return, a push and a pop each takes three machine cycles, then
do the maths, come back after school and tell me again what's
efficient.

BAD STYLE?

Ooh, I don't know anything 'bout STYLE - I'm a programmer!

MM