Re: Larkin, Power BASIC cannot be THAT good:

On Thu, 21 May 2009 00:28:08 -0700 (PDT), Tim Williams
<tmoranwms@xxxxxxxxx> wrote:

On May 21, 12:28 am, "JosephKK"<quiettechb...@xxxxxxxxx> wrote:
Over 20 years ago a coworker of mine wrote a comefrom static analysis
program to analyze his programs.  He was rather shocked to see how
much he had been abusing goto.  And this was with a version of basic
that had subroutines with parameters.

I regularly use QuickBasic, which is quite capable of OO style
subroutines (although calling QB OO, with its narrow "object"
functionality, is a stretch), but which of course allows GOTOs. I
find there are a number of places were GOTO is simply too useful to
pass up. Here's a recent example:

.
.
.
FOR i = 1 TO LEN(In$)
k = ASC(MID$(In$, i, 1))
l = Ascii2Seven(k)
m$ = Num2Hex$(l AND 255)
GOSUB PrintByte
IF l > 255 THEN
m$ = Num2Hex$((l AND &HFF00&) \ &H100)
GOSUB PrintByte
END IF
NEXT
PRINT
.
.
.

So it chews through In$, one byte at a time, doing whatever
Ascii2Seven does (ooh, a user-defined function!). The rub is, for
expandability reasons, Ascii2Seven may return a one-digit number
(i.e., values 0 to 255) or a two-digit number (I believe the sign bit
is set in this case). Printing the other byte requires a seperate
call to PrintByte, for state reasons. SUB would be inelegant here
because a number of variables would either have to be passed as
operands or SHAREd globally, neither of which really make any sense.
Printing one or both bytes at the same time (which could, in
principle, be done with one call to, say, PrintSeven instead of
PrintByte) just moves things around and meets the same problem.

Other times, I've used GOTO or GOSUB to call a routine which has a lot
of common variables (i.e., its scope includes main) or to branch to a
single routine from multiple exit points out of a SELECT CASE or
somesuch.

Most of the time, I do write SUBs and FUNCTIONs, great for compact
bits of code that might be useful in other places, or which are fairly
specialized but have little effect on other parts of the program (for
instance, a game engine, menu, physics, AI and other systems can all
be sectioned into seperate subroutines, for the most part). On
average I would suppose GOTO and GOSUB count as "rare" (<1% of all
subroutine calls?) in my usage.



What really matters, and what everyone time and time again keeps
missing is, GOTO and SUB must both be used responsibly. Since there
is no check on programmers being responsible, there is no check on
programmers producing managable code, regardless of language
structure.


Yes. I write thousands-of-lines programs, in various languages, that
are almost entirely flat, with every variable global and static, a big
GOTO state machine, with most subroutines done as JSR/RTS or
GOSUB/RETURN. If you do this carefully, you get fast, tight, clean
code, no possibility of memory or stack problems, and *zero* bugs. If
you do any programming carelessly, you get an ugly mess.

Anybody who ships embedded systems that have bugs is a bad programmer,
in any language. I'm on the mailing list for one analytical instrument
software package from a big company that uses all the latest languages
and version/bug control tricks. They average about ten new reported
bugs per week.

John


.

Relevant Pages

  • Re: Use of subroutines
    ... > control structure is, in its fundamental form, just a GOTO statement. ... clicking on the subroutine from hundreds of subroutines, ... there are more possible interactions between ... > and modularization. ...
    (comp.lang.fortran)
  • Re: Bad code organization -- Re: Use of subroutines
    ... > That is not about equivalence of GOTO and CALL, ... > bad choices of dividing code into subroutines ... > deliberate obsuring or rampant inconpetence ... they introduce more chances for bugs creeping ...
    (comp.lang.fortran)
  • Re: Could I put commands in a variable
    ... > remember was PRINT, GOTO, and a variety of line numbers. ... I actually think Perl is perfect for this... ... > structure of and wouldn't mind an easier solution. ... Subroutines will make your life *much* easier, ...
    (perl.beginners)
  • Re: use go to doing some case studies and induced problems
    ... these case studies are not so worthy of writing them as ... there is no way to jump to some code at the end of the main program without either using subroutines and/or functions, using GOTO, or doing something completely absurd and unreadable with a huge IF block or the like. ... Writing things with a clear and explicit structure instead of the quick and immediate way (such as goto statements) can sometimes take more work at first, but that work goes directly into things that make the program easier to read, easier to debug, and easier to extend later, and thus in the long run it does save time -- often a lot of it. ... So that was all the work that I'd been avoiding, all to do in a lump, plus all the work of doing it the first time. ...
    (comp.lang.fortran)
  • Re: Bad code organization -- Re: Use of subroutines
    ... >> the overall logic of the code is buried within subroutines, ... > intent to obfusticate or by sheer incompetence, ... it is more than either intent or incompetence. ... > That is not about equivalence of GOTO and CALL, ...
    (comp.lang.fortran)
Quantcast