GOSUB VS SUB

[Raven_Singularity]

I'm not quite sure what you're asking about F2.

[RhoSigma]

Hi, just wanna give my two cents on this topic :)

1.) I use GOSUB/RETURN in most cases when it comes to reduce the  EXE's size by pulling together code sequences which are redundant in several parts of my project. If the affected code don't need passing any arguments or relies on global variables only, this is a quick way to put the redundant code into a GOSUB routine and just calling it from any place I need it. (eg. the GuiToolsDemo.bas of my GuiTools project https://www.qb64.org/forum/index.php?topic=809.msg100182#msg100182)

2.) To create some kind of black box modules, hence just show the main functions of a library under F2, but hide the sub-code or rendundancies within the main functions. This i will usually do with some pseudo argument passing, giving the GOSUB routine arguments/result a prefix like the initials of the GOSUB routine and assigning values to it before actually calling the GOSUB routine, and later get back the result the same way. (currently only done that way in my LZW-Packer library https://www.qb64.org/forum/index.php?topic=783.0)

In general, treating GOSUB/RETURN as it never would have exist is rude in my opinion, you just need to know what you wanna achive in your program using your personal programming style. Important is, whatever way you choose to use, be consistent on it throughout your projects, avoid to mix different styles of doing things, it will help YOU understanding things you did, when looking at it after a year and it will also help other users to understand/adapt to your style, when you publish code snippits here in the forum.

[FellippeHeitor]

Truth be told, I even have SUBs in my code that have GOSUB in them. Judge me. :-)

[jack]

in my opinion, gosub's are ok, but the problem is that it can lead to some very hard (or impossible) to decipher spaghetti code.
if people confine the subroutine code in clearly defined sections, then subroutines are ok.

[RhoSigma]

...
in my opinion, gosub's are ok, but the problem is that it can lead to some very hard (or impossible) to decipher spaghetti code.
...

I would agree with you 25- 30 years ago, today spaghettti code is rather a phenomenon caused by people (out of that era), which played around a little bit with programming in the ancient times and comming back to it todays, (maybe because they got retired and feeling bored now or for other reasons). Those people simply "re-enter" programming today with the attitude which was usual for that ancient time (mostly because they find old code snippits on a floppy disk, and they don't know how to do it better). Instead of doing the right thing, learning what has changed in the past 25-30 years first, they simply stumble into the modern programming world with their old stuff.

In short i think, spaghetti code is a matter of insufficient programming skills (at least seen to the rules and methods applicable todays), and whenever those people appear here on the forum, we should kindly try to help and move those fellows into the right direction. Spaghetti code is not the fault of GOSUB/RETURN or GOTO, it's simply insufficient knowledge how to do it right.

[Raven_Singularity]

"Spaghetti code is not the fault of GOSUB/RETURN or GOTO, it's simply insufficient knowledge how to do it right."

I can tell you, spaghetti code was almost guaranteed with C=64 or GW-BASIC code.  You ran out of line numbers in one part, then used GOTO because renumbering 200 lines of code (and all references to those lines of code) is no fun at all.  The more complex the program got, the worse the spaghetti code became.  I started mapping out the line numbers in the thousands for the various parts of my programs, just so I never had to renumber anything.  It did look silly on small programs, mind you, lol.

The early BASIC spaghetti code was directly the fault of the BASIC editor (or lack thereof).  Since Q-BASIC, there has been no excuse for using GOTO or other code kludges.  It's been all IDEs since then, probably because of how ubiquitous QBASIC became for new programmers looking to try programming.  Even QuickBASIC v4.5 was nowhere near as advanced as say Turbo Pascal (and nowhere near as fast), but for "included with the operating system" it was truly amazing!  Light years beyond C=64 or GW-BASIC.  I think I've only spent a few hours programming in BASICs that require line numbers since that first time I loaded Q-BASIC.

Personally, I find more modern IDEs to be mostly garbage.  QuickBASIC v4.5 was my dream programming environment as a kid, built-in help allowed me to learn [almost] the whole language without opening a book.  I find a lot of modern programming IDEs have too much clutter and garbage that gets in the way of actually focusing on programming, and can have performance issues on larger projects.  I loved DOS 16-colour text mode GUIs, like PC-Tools and the Norton suite.  Very efficient, everything can be done with a couple key clicks.  Modern GUIs often require you to use the mouse, or jump through hoops with the keyboard -- why should I have to press 7 keys to do a basic function?  I feel mouse-oriented apps often forget about user efficiency altogether -- that is, actually getting the task done in the shortest period of time.

I have been enjoying getting back into programming these past months, in a modern programming language that also respects the old-school Q-BASIC/QuickBASIC efficient IDE style.  It also seems to compile quickly.  ~2,700 lines of code in ~3 seconds... not sure how it would perform with 50,000 lines of code.  Back in the day, QuickBASIC v4.5 took about that long to launch your app on a 286 when you hit F5, and significantly longer if you wanted to produce a standalone .EXE file.

In the modern era, spaghetti code usually refers to programmers that don't know how to program themselves, but are okay at reading other people's code.  They do their programming jobs by doing web searches for everything they're trying to accomplish, then gluing the pieces they find together until they mostly work.  Nobody will be able to tell at first glance what this code does, as there is zero structure present.  But the original spaghetti code was definitely GOTO.  What an ugly nightmare it was with forced line numbers and GOTO.  There were literally magazines with terrible BASIC code, sometimes having a dozen GOTO statements.  I think a few of the programmers reveled in writing ugly obfuscated code, making their programs seem more ineffably impressive to the general public.

Q-BASIC might be one of the greatest contributions to computing by Microsoft ever.  Did they actually produce the IDE themselves?  Or just buy up a preexisting software package.  I've never looked into the history of the IDE itself, I was just an enthusiastic user at the time.  Pretty sure QuickBASIC v4.5 was my favourite app on my 286, although I also loved speed-running Wolfenstein 3D using a mouse + keyboard (everyone else had Doom on their 486s, I had Wolf3D on a 286).

[Raptor88]

Hi Raptor88,

Here is an example of a recursive sub. It calls itself over and over again until the job is done.

IMHO it is the most beautiful and elegant kind of code you can write. I hope this fractal inspires:
.... snip to save bandwidth ....

Nice screensaver.  As previously mentioned, recursive subs are beyond my scope for now but it's informative to see a working example.
Thanks,
Raptor88

[Raptor88]

To further add to what I said:
.... snip to save bandwidth ....

Interesting read.
Thanks,
Raptor88

[Jack002]

No, we still need gosub today. The concept of a program is to do some big job (I'm waving an arm left to right) and to do that you split it into smaller and smaller jobs. Many you need to do more than once. So write a function or a subroutine.
The first all encompassing gosub anyone will ever need is the "get ready". You call it to set up things for the main process.
Later you might need a "finish up". Close files, tidy things somehow.
If you don't take a large plan and break it into smaller ones you'll never get a program off the ground.

Any program worth looking at will have subroutines. The work is ordered and structured by them. One may make a menu, one loads files, one saves files, one formats data, one gets inputs to add to something, one makes a box on the screen, etc etc etc.

So you mention recursion earlier. I love that. Lots of things can be done with it, but you have to do it right. You'll kill your stack if it gets away from you. Ever see a recursive sort? They are wonderful. I did some recursion, not sure what they were now.

[Raven_Singularity]

No, we still need gosub today. The concept of a program is to do some big job (I'm waving an arm left to right) and to do that you split it into smaller and smaller jobs. Many you need to do more than once. So write a function or a subroutine.
The first all encompassing gosub anyone will ever need is the "get ready". You call it to set up things for the main process.
Later you might need a "finish up". Close files, tidy things somehow.
If you don't take a large plan and break it into smaller ones you'll never get a program off the ground.

Any program worth looking at will have subroutines. The work is ordered and structured by them. One may make a menu, one loads files, one saves files, one formats data, one gets inputs to add to something, one makes a box on the screen, etc etc etc.

So you mention recursion earlier. I love that. Lots of things can be done with it, but you have to do it right. You'll kill your stack if it gets away from you. Ever see a recursive sort? They are wonderful. I did some recursion, not sure what they were now.

Nobody was suggesting that subroutines are not useful anymore, just that the GOSUB statement is less robust than the SUB + END SUB method.

[freetrav]

"Spaghetti code is not the fault of GOSUB/RETURN or GOTO, it's simply insufficient knowledge how to do it right."

I can tell you, spaghetti code was almost guaranteed with C=64 or GW-BASIC code.  You ran out of line numbers in one part, then used GOTO because renumbering 200 lines of code (and all references to those lines of code) is no fun at all.  The more complex the program got, the worse the spaghetti code became.  I started mapping out the line numbers in the thousands for the various parts of my programs, just so I never had to renumber anything.  It did look silly on small programs, mind you, lol.

In GW-BASIC (I can't speak for C64 BASIC), you didn't have to hack around with changing line numbers or GOTO/GOSUBing to random code blocks inserted somewhere when you "ran out" of numbers; all you had to do was RENUM your program - you could even renumber sections of your program; see https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/gwbasic.chm/RENUM.html

The early BASIC spaghetti code was directly the fault of the BASIC editor (or lack thereof).  Since Q-BASIC, there has been no excuse for using GOTO or other code kludges.  It's been all IDEs since then, probably because of how ubiquitous QBASIC became for new programmers looking to try programming.  Even QuickBASIC v4.5 was nowhere near as advanced as say Turbo Pascal (and nowhere near as fast), but for "included with the operating system" it was truly amazing!  Light years beyond C=64 or GW-BASIC.  I think I've only spent a few hours programming in BASICs that require line numbers since that first time I loaded Q-BASIC.

The early BASIC spaghetti code was directly the fault of the PROGRAMMER, not the TOOL - if you didn't plan out your code, you would end up with spaghetti code. Certainly, BASIC as a language didn't encourage planning (or other good habits), the way languages such as FORTRAN, Pascal, or ALGOL - or even COBOL - did, but if you developed the good habits, you could still use them in BASIC and get good results (I speak from direct personal experience; I started with AppleSoft BASIC and Apple Pascal).

Personally, I find more modern IDEs to be mostly garbage.  QuickBASIC v4.5 was my dream programming environment as a kid, built-in help allowed me to learn [almost] the whole language without opening a book.  I find a lot of modern programming IDEs have too much clutter and garbage that gets in the way of actually focusing on programming, and can have performance issues on larger projects.  I loved DOS 16-colour text mode GUIs, like PC-Tools and the Norton suite.  Very efficient, everything can be done with a couple key clicks.  Modern GUIs often require you to use the mouse, or jump through hoops with the keyboard -- why should I have to press 7 keys to do a basic function?  I feel mouse-oriented apps often forget about user efficiency altogether -- that is, actually getting the task done in the shortest period of time.

I tend to consider most modern IDEs to be not garbage, but simply overkill for the kind of programming I do. I agree that the QBASIC/QB64 IDE is nearly ideal; I use Microsoft's Powershell ISE for working in Windows PowerShell, and Notepad++ for most other languages. On the other hand, I'm not busy writing large projects with several myriad lines of code; I tend to write small programs with focussed purposes, rarely with display-oriented presentation - following the UNIX philosophy of 'do one thing, do it well, and chain lots of do-one-thingers together to do more complex jobs'.

[bplus]

So a good use of GOSUB is when you find you are writing redundant code snips in the main program or loop or in a SUB or FUNCTION and you want to keep the variables "global" in that same level of code.

[MWheatley]

I'm not quite sure what you're asking about F2.

I fiddled with it, so that I could articulate the problem more precisely.  And in doing so, found the answer that had previously eluded me!  So, problem solved....

Malcolm

[Jack002]

Nobody was suggesting that subroutines are not useful anymore, just that the GOSUB statement is less robust than the SUB + END SUB method.

Qwerkey  was:

I wouldn't even bother using it then.  Just pretend that GOSUB has never existed.

[Pete]

It's like saying who's the greatest super hero, Batman or Superman? If you don't know the one correct answer, it's because you're too much of a woose to stand up for your own damn opinion! Sorry, Qwerty, Catwoman's just eye-candy.

Like Fell, I too include GOSUB in subs; so like he said, judge him.

I like to keep my libraries SUB free, and only use GOSUB. That way, when I put libraries into other programs, I don't have to sort through subs that are not part of my new creation. Still, I could prefix name all of the subs, so at least it wouldn't be messy when I search them.

SUBs are great for more variable control, otherwise using GOSUB is great for times you just have two or more repeating routines in your code, and you just want one routine to handle them.

Pete