50 Years of BASIC - TIME

[+Random Terrain]

This post may not be safe for work or kids.

 

 

People who use BASIC be like this:

youtube.com/watch?v=bqzgfAqfHFU

https://www.youtube.com/watch?v=bqzgfAqfHFU

 

 

People who use anything else be like this:

 

youtube.com/watch?v=Z7kUKBHDuak

https://www.youtube.com/watch?v=Z7kUKBHDuak

[Mr SQL]

What I always found with basic was that as a programming introduction language it was good in that you could quite quickly see the flow of the program and get a grasp on what was needed to achieve the target. However what it was bad at was teaching good coding practices e.g. leading to code reuse and the underlying structures that were needed for larger programs. It worked well when taught in conjunction with one of the other languages (think it was Pascal I learned it with) but didn't really scale up for collaborative projects.

 

Microsoft, in my mind, bastardised the language when they went to visual basic. It allowed people to get something on the screen quickly without understanding anything about what was going on behind the curtain. This created a series of basic programmers that lacked the nous to actually apply the skills they had to anything outside the visual environment, and in turn led to the maligned reputation.

 

 

It also led to countless "business applications" created by hopelessly clueless self-appointed "programmers," riddled with bugs, crazy logic, security holes, and every brain-dead code cliché ever invented.

 

I should know. I got stuck fixing them at every employer I went.

 

 

-dZ.

 

You could as easily be describing Java or c#.

 

BASIC introduced alot of folk to programming who would otherwise not have programmed, which is one of the reasons it's better suited for engineers and scientists to rapidly solve problems with.

 

Scientists aren't programmers, so giving them a simple programming language lets them do real work and leverage their knowledge of science is a great idea.

 

Usually a programmer can sit with the knowedge worker to build a program to spec but there are undeniably instances where it is more advantageous for the knowedge worker to do the programming and BASIC is a perfect fit.

 

A prime example, Excel 2016 has not only BASIC, but the legacy BASIC runtime (VB6) runtime from 1998. There's an ever increasing volume of VBA excel applications that are largely applied financial formula; were these to be rewritten in Java/c# you would have a situation where the programmers didn't understand the formulas and the formulators, didn't understand the programming.

[DZ-Jay]

You could as easily be describing Java or c#.

Uh... No. Absolutely not.

 

Java and C# are languages specifically designed for systems engineering, so they include many constructs that lead to commonly understood patterns.

 

Of course, you can write bad code in any language, but you are more likely to never learn the right way of doing things, or that there are good design patterns, if you are stuck on a language that does not promote or encourage them.

 

Like I've said many times already, I am not castigating BASIC as a useless language. In fact, like many of you here, I started with it as well and I have fond memories of it.

 

It is very easy to pick up and it is extremely accessible to the layman. Those are it's strengths. What I argue is that it does not get you much farther than that, and that if it is the only language you ever learn, your ability to solve certain common problems in software engineering, or to follow good practices and design patterns, is severely limited.

 

Of course, a talented individual can write elegant, beautiful, correct, and efficient code in BASIC; and my contention is that such an individual gained his mastery of the art on another language -- or inspite of -- BASIC's limitations, by venturing outside of it.

 

The bad "business applications" in VB I mentioned are real. I don't compare these to bad Java or C# applications, where you can point to inexperience or incompetence most of the time.

 

There is a certain special naïveté imbubed in those VB applications that make them recognizable, where some common mistakes are repeated and some particular anti-patterns are followed. These, in my experience, transcend enterprises, industries, and even geographical areas.

 

True VB programmers (those who know nothing but VB and never touched anything else) are as unique a breed as they are abundant; and at some point in time about 10 or 15 years ago, they were everywhere.

 

dZ.

Edited July 25, 2016 by DZ-Jay

[Mr SQL]

Uh... No. Absolutely not.

 

Java and C# are languages specifically designed for systems engineering, so they include many constructs that lead to commonly understood patterns.

 

Of course, you can write bad code in any language, but you are more likely to never learn the right way of doing things, or that there are good design patterns, if you are stuck on a language that does not promote or encourage them.

 

Like I've said many times already, I am not castigating BASIC as a useless language. In fact, like many of you here, I started with it as well and I have fond memories of it.

 

It is very easy to pick up and it is extremely accessible to the layman. Those are it's strengths. What I argue is that it does not get you much farther than that, and that if it is the only language you ever learn, your ability to solve certain common problems in software engineering, or to follow good practices and design patterns, is severely limited.

 

Of course, a talented individual can write elegant, beautiful, correct, and efficient code in BASIC; and my contention is that such an individual gained his mastery of the art on another language -- or inspite of -- BASIC's limitations, by venturing outside of it.

 

The bad "business applications" in VB I mentioned are real. I don't compare these to bad Java or C# applications, where you can point to inexperience or incompetence most of the time.

 

There is a certain special naïveté imbubed in those VB applications that make them recognizable, where some common mistakes are repeated and some particular anti-patterns are followed. These, in my experience, transcend enterprises, industries, and even geographical areas.

 

True VB programmers (those who know nothing but VB and never touched anything else) are as unique a breed as they are abundant; and at some point in time about 10 or 15 years ago, they were everywhere.

 

dZ.

 

There are bad business applications written in Java and c# too; modern kit [insert any language] may be to blame, the developers draw controls on the screen and wire them up with the mouse and set properties.

 

The point about the enduring presence of Excel BASIC applications illustrates there will always be better BASIC programs than c# or Java programs where the knowledge worker must necessarily be close to the code. Microsoft adding full compatibilty with 1998 legacy BASIC back to Excel and Access makes this pretty clear since those office products have market share. The same concept holds true for scientists and engineers because BASIC constructs are far easier to work with. I've worked with scientists who have been made to learn a c variant in their phD curriculum and by and large they have an unwieldy grasp of it while those who learned BASIC can still leverage their knowledge with it easily.

 

Regarding the systems engineering, that's a good point but systems engineers are aleady computer experts. Even there, BASIC has been used as a model to improve the shortcommings of c languages; PowerShell is an awesome c variant that is arguably as RAD as BASIC which was the design goal for this systems language because c# and vb.net could not match wsh (based on legacy BASIC) for development time.

[Tickled_Pink]

To be brutally honest, I miss BASIC. Good old fashioned line-numbered BASIC. It was a fun language to code in.

 

Languages that make use of OOP are just depressing. No fun whatsoever.

[Papa]

I'm feeling pretty good...

 

[lord_mike]

Forgive me for getting in late. I just saw this post now. I was just thinking the other day, "Why BASIC?" Why did BASiC become the default language of microcomputers instead of something better? After all, the early computing pioneers were all familiar with other languages such as Fortran, why did BASIC become the default language. I think the simple answer is Tiny BASiC:

 

https://en.wikipedia.org/wiki/Tiny_BASIC

 

It was extremely small, which was necessary for the early micros, and it was free. Compilers take up a lot of resources such as memory and in the absence of those, required some sort of sequential storage that was not available for micros at the time. It only made sense that a really tiny interpreter would be used, even it made slow machines even slower. By the time microcomputers got more powerful, BASIC was already entrenched as the default microcomputer language.

[DZ-Jay]

I just came across the following excerpt from Niklaus Wirth on why he thought the need to invent Pascal. Of course, he doesn't mention BASIC by name, but we know what he's talking about...

 

 

The desire for a new language for the purpose of teaching programming is due to my dissatisfaction with the presently used major languages whose features and constructs too often cannot be explained logically and convincingly and which too often defy systematic reasoning. Along with this dissatisfaction goes my conviction that the language in which the student is taught to express his ideas profoundly influences his habits of thought and invention, and that the disorder governing these languages imposes itself into the programming style of the students.

 

 

 

It more eloquently expresses my more terse opinions posted before: that a language (any language, including computer languages) by its nature of enabling expression, necessarily influences the ideas and thoughts that drive them; and that a lack of structure, discipline, or guidance in the former will in turn reflect on the latter.

 

I just thought it was a nice quote. Carry on.

 

-dZ.

[Mr SQL]

Forgive me for getting in late. I just saw this post now. I was just thinking the other day, "Why BASIC?" Why did BASiC become the default language of microcomputers instead of something better? After all, the early computing pioneers were all familiar with other languages such as Fortran, why did BASIC become the default language. I think the simple answer is Tiny BASiC:

 

https://en.wikipedia.org/wiki/Tiny_BASIC

 

It was extremely small, which was necessary for the early micros, and it was free. Compilers take up a lot of resources such as memory and in the absence of those, required some sort of sequential storage that was not available for micros at the time. It only made sense that a really tiny interpreter would be used, even it made slow machines even slower. By the time microcomputers got more powerful, BASIC was already entrenched as the default microcomputer language.

 

Good perspective Lord_Mike, agree with all those points. I'd add that the early computing pioneers familiarity with Fortran you mentioned was also a big influence as BASIC is derived from Fortran, we could consider the more complete BASIC's Tiny Fortran.

[Mr SQL]

dZ, interesting quote from the author of Pascal; he seems to be referring to multiple languages though - probably he saw shortcommings in several of them he felt were resolved in Pascal.

 

I remember trying a Pascal compiler in the 80's, it was pretty cool but don't see too many people using the language today.

 

Perhaps it's concepts have seen reuse in the lightweight scripting languages.

[DZ-Jay]

dZ, interesting quote from the author of Pascal; he seems to be referring to multiple languages though - probably he saw shortcommings in several of them he felt were resolved in Pascal.

 

I remember trying a Pascal compiler in the 80's, it was pretty cool but don't see too many people using the language today.

 

Perhaps it's concepts have seen reuse in the lightweight scripting languages.

I think it's common knowledge that Witth was referring to BASIC, albeit trying to be more diplomatic than, say, Dijkstra.

 

As for the use of Pascal, well, just know that Pascal begat Turbo Pascal, which begat Object Pascal, which begat Delphi, which begat C#. There is a continuity of sorts in these on their philosophy, if not strictly on the syntax.

 

Also know that what eventually became VisualBasic was very similar in structure and procedural philosophy to good old Pascal, much more so than perhaps something more "freeform" like QBasic.

 

dZ.

[+frankodragon]

This post may not be safe for work or kids.

 

 

People who use anything else be like this:

 

youtube.com/watch?v=Z7kUKBHDuak

https://www.youtube.com/watch?v=Z7kUKBHDuak

I think someone you all know needs a pair of those jeans.

 

 

 

I usually tried to type in those magazine and manual programs for Commdore 64 and VIC-20 machines but I had no idea what all that meant. Probably because I sucked in algebra. For instance FOR T=10: NEXT T. Probably the only think I could understand was the PRINT "[text]" command.

[carlsson]

Perhaps you mean FOR T=1 TO 10:NEXT T which makes a little more sense if you think of T as a variable, a piece of memory you can refer to by name and that holds one value at a time. The FOR command then sets up a loop, a chain of assigments where this little variable gets to hold an increasingly larger value until it has reached its peak at 10. The NEXT command just is a marker to increase the value and loop once again.

[Keatah]

BASIC introduced alot of folk to programming who would otherwise not have programmed, which is one of the reasons it's better suited for engineers and scientists to rapidly solve problems with.

 

Scientists aren't programmers, so giving them a simple programming language lets them do real work and leverage their knowledge of science is a great idea.

 

Usually a programmer can sit with the knowedge worker to build a program to spec but there are undeniably instances where it is more advantageous for the knowedge worker to do the programming and BASIC is a perfect fit.

 

A prime example, Excel 2016 has not only BASIC, but the legacy BASIC runtime (VB6) runtime from 1998. There's an ever increasing volume of VBA excel applications that are largely applied financial formula; were these to be rewritten in Java/c# you would have a situation where the programmers didn't understand the formulas and the formulators, didn't understand the programming.

 

This was undoubtedly me. Applesoft BASIC was really rewarding to work with back in the day - especially for BBS programming. Couldn't get enough of it!

 

Screw that dickisrtraja guy!

[DZ-Jay]

 

This was undoubtedly me. Applesoft BASIC was really rewarding to work with back in the day - especially for BBS programming. Couldn't get enough of it!

 

Screw that dickisrtraja guy!

Highlights For Children and the Weekly Reader introduced me to reading when I was very young, and I will forever be grateful to them; but I don't use them any more and as an adult, I find other works of literature more fulfilling and productive.

 

You see, I don't take anything away from the merits of the introductory tool, but I accept its place in the continuum of experience.

 

And yes, we already know Dijkstra is a tool.

dZ.

[Mr SQL]

Highlights For Children and the Weekly Reader introduced me to reading when I was very young, and I will forever be grateful to them; but I don't use them any more and as an adult, I find other works of literature more fulfilling and productive.

 

You see, I don't take anything away from the merits of the introductory tool, but I accept its place in the continuum of experience.

 

And yes, we already know Dijkstra is a tool.

dZ.

Very cool dZ; I enjoyed reading Dr Zeus and curious George!

 

But I would point out that you are indeed still using the same language, but having learned and practiced over time, you are using it at a much higher level.

 

So why should it be any different with a programming language?

 

BASIC is introductory but also simultaneously advanced given the versitile range of applications that have been built include even compilers.

 

The problem with Dijkstra's argument is that programming complexity is more specific to the program genre than the language:

 

The programmers writing C compilers in BASIC are far more advanced than C programmers who cannot write compilers.

[+TwentySixHundred]

Wow this is a very informative discussion that will definitely help me with my bB projects, so far i have learned that i have already picked up bad practices and alot of spaghetti/messy code lol. Thinking i might start using the gosub structure rather then the goto because as much as i understand the goto it can get confusing to read. I find when the code grows im needing to 'rem' nearly every condition otherwise im code hunting for a long time looking the next condition statement..... Obviously this is an issue when placing the condition outside the main loop, once there is multiple conditions it's a game of where's wally/waldo.

 

I do have a question though, out of all languages i have tried to understand Batari BASIC is one the only that makes sense. From reading along BASIC is still used however others have dominated the market and more practical for modern day uses. Guess im asking what modern day languages are similar to BASIC? Im fairly sure bB is more of a hybrid/custom language <--- or i could be wrong? I enjoy bB for Atari fun projects but wouldn't mind learning a more versatile language for other practices. Any suggestions are welcome thanks

[Keatah]

Some people are wired differently and understand different languages with different levels of insight and direction. That dickheadstraja guy doesn't take that into account.

[DZ-Jay]

Wow this is a very informative discussion that will definitely help me with my bB projects, so far i have learned that i have already picked up bad practices and alot of spaghetti/messy code lol. Thinking i might start using the gosub structure rather then the goto because as much as i understand the goto it can get confusing to read. I find when the code grows im needing to 'rem' nearly every condition otherwise im code hunting for a long time looking the next condition statement..... Obviously this is an issue when placing the condition outside the main loop, once there is multiple conditions it's a game of where's wally/waldo.

 

I do have a question though, out of all languages i have tried to understand Batari BASIC is one the only that makes sense. From reading along BASIC is still used however others have dominated the market and more practical for modern day uses. Guess im asking what modern day languages are similar to BASIC? Im fairly sure bB is more of a hybrid/custom language <--- or i could be wrong? I enjoy bB for Atari fun projects but wouldn't mind learning a more versatile language for other practices. Any suggestions are welcome thanks

 

For regular (non-retro) programming you may want to try VisualBasic.Net or my favourite Delphi, which is based on Object Pascal, itself based on Turbo Pascal.

 

As for program structure, that's more of a discipline, so it comes with practice and experience. BASIC does not prevent you from making well structured programs at all; my complaint is that it makes it very easy to not do so, which lends itself to bad habits.

 

A good way to get started with good structured practices is to build games in the "top-down" or "deconstructive" approach. In fact, I find it exceedingly easier because it is closer to the way humans think. In this approach, you delineate your logic in big obscure chunks of general routines, and little by little you fill in the individual logic for each one. For instance, consider the following first iteration:

' Main loop
Do
  ' Update game state
  Gosub ReadUserInput
  Gosub UpdatePlayerState
  Gosub UpdateEnemyState
  Gosub DetectCollisions

  ' React to events
  If (EnemyDead) Then Gosub KillEnemy
  If (PlayerDead) Then Gosub KillPlayer

  ' Do everything else
  Gosub UpdateScore
Loop

Notice that at this point I have absolutely no idea what any of those routines will do, but they give me the skeleton of what my game program needs to do.

 

On my next iteration, I break down the functionality for each sub-routine into smaller chunks, again not really caring about the implementation yet. For example,

Sub ReadUserInput
  ' We'll implement these later
  Gosub ReadIoBus
  Gosub DecodeIoSignal
End Sub

And on it goes. As you work on the implementation, you may realize that some of those routines may not be too long, and so you may just put the code in-line without losing much of its modularity. Also as you progress, performance may be concern, so you may want to take multiple of those routines and consolidate them into more optimize code.

 

However, always remember that optimization should be a degenerative process due to necessity: it implies that you have already well defined, structured, and working code and you are making a conscious decision to break the structure in order to reach some performance objective. Starting with non-structured spaghetti-code first is not really "optimization," it's just sloppy coding.

 

Like I said, you can do this rather well in BASIC as in any other language. Other languages (like Pascal) sort of push you in this direction by mere constraints of the language, other languages (like C#) invite you nicely into this approach by offering lots of facilities and syntactic sugar to make it easier to follow good practices than not. Yet still other languages (like C) paint a big target on structure practices and give you a loaded gun, but really don't care which way you aim and will get out of your way if you decide to shoot your dog or yourself in the foot. (I love programming language analogies! )

 

To me BASIC falls in between those: it offers some facilities for structured code while at the same time putting a big bright sign saying, "Come one and all! It's so easy and fun! you don't even have to follow any rules!" This makes it easy to learn, but just as easy to miss some good practices.

 

-dZ.

Edited February 27, 2017 by DZ-Jay

[+TwentySixHundred]

Ok so the skeleton structure is more of a 'template' mainloop with the all possible subroutines to fill the blanks later, rather then adding subroutines later to a working mainloop? The gosub routines have me a bit confused as to how they work though; do they check conditions within those sub routines every read cycle? Because im used to having the if statements checked for conditions then if one is met the goto command with direct to a code block outside the main loop. Just so im understanding this correctly i will paste the source and a bin of a project im working on, pre warning it's a mess and im fairly novice so don't slam dunk me too hard . I have basically learnt by trial and error and doing what makes 'sense' to me so there is nothing professional about it at all lol. However i think if i post the code it will help to get a full understanding if you can point out a few bad practices im using that would be great.

 

Atari 2600 OS v0.3.0 (2017) (TT2600).bin

 rem conditions

   includesfile multisprite_bankswitch.inc
   set kernel multisprite
   set romsize 8k

 rem Resets all varible reset OS

__refresh

 player0x = 74
 player0y = 40
 player1x = 200
 player1y = 90
 player2x = 24
 player2y = 72
 player3x = 200
 player3y = 90
 player4x = 200
 player4y = 90
 player5x = 24
 player5y = 60
 ballx = 200
 bally = 0
 z = 0
 g = 0
 score = 0

 rem Main desktop OS loop
 
__desktop
 scorecolor = 10
 COLUBK = 164
 COLUPF = 10
 COLUP0 = 12
 COLUP1 = 10
 COLUP2 = 10
 COLUP3 = 10
 COLUP4 = 10
 COLUP5 = 10
 
 rem clock

 h = h + 1
 if h > 59 then i = i + 1 : h = 0 : score = score + 1
 if i > 59 then j = j + 1 : i = 0 : score = score + 40
 if j > 59 then k = k + 1 :j = 0 : score = score + 400

 rem OS restart

 if switchreset then goto __refresh

 rem exit folder trigger

 if player2x = 200 then ballx = 21 : bally = 48

 rem boundry

 if player0x < 6 then player0x = player0x +1
 if player0x > 148 then player0x = player0x - 1
 if player0y < 10 then player0y = player0y + 1
 if player0y > 86 then player0y = player0y - 1

 rem playfield and sprites

 playfield:
 XXXXXXXXXXXXXXXX
 ................
 ................
 ................
 ................
 ................
end

 player0:
 %00000000
 %00000110
 %00001110
 %01011100
 %01111000
 %01110000
 %01111000
 %00000000
end

 player1:
 %11111111
 %10000001
 %10101001
 %10111001
 %10101001
 %10110111
 %10000110
 %11111100
end

 player2:
 %11111111
 %10000001
 %10100001
 %10110001
 %10100001
 %10110111
 %10000110
 %11111100
end

 player3:
 %11111111
 %10000001
 %10111001
 %10010001
 %10001001
 %10110111
 %10000110
 %11111100
end

 player4:
 %11111111
 %10000001
 %10111001
 %10010001
 %10110001
 %10010111
 %10000110
 %11111100
end

 player5:
 %00111100
 %00100100
 %00100100
 %01001010
 %01010010
 %11111111
 %10000001
 %01111110
end

 rem tone reset

 AUDV0 = 0 : AUDC0 = 0 : AUDF0 = 0

 rem player input function

 if joy0up then player0y = player0y + 1
 if joy0down then player0y = player0y - 1
 if joy0left then player0x = player0x - 1
 if joy0right then player0x = player0x + 1

 rem tolder exit function 1

 if collision(player0,ball) then goto __reset

 rem game exe function

 if z > 6 then goto __game1
 if player4x = 24 then goto __gamestart

 rem open folder function

 if collision(player0,player1) then goto __folder

 drawscreen
 goto __desktop

 rem open folder fuction1

__folder
 if joy0fire then AUDV0 = 10 : AUDC0 = 12 : AUDF0 = 4
 if joy0fire then player2x = 200 :  player2y = 90 : player3x = 24 : player3y = 60 : player4x = 24 : player4y = 72 : player5x = 200 : player5y = 90

 drawscreen
 goto __desktop

 rem folder exit function 2

__reset

 if joy0fire then AUDV0 = 10 : AUDC0 = 12 : AUDF0 = 6
 if joy0fire then player2x = 24 : player2y = 72 : player3x = 200 : player3y = 90 : ballx = 200 : bally = 0 : player4x = 200 : player4y = 90 : player5x = 24 : player5y = 60 : z = 0

 drawscreen
 goto __desktop

 rem game exe function1

__gamestart

 if collision(player0,player1) then goto __gamestart2

 drawscreen
 goto __desktop

 rem game exe function2

__gamestart2

 if joy0fire then z = z + 1

 drawscreen
 goto __desktop

 rem game varible preset

__game1

 player0x = 74
 player0y = 10
 player1x = 90
 player1y = 70
 player2x = 200
 player2y = 90
 player3x = 200
 player3y = 90
 player4x = 200
 player4y = 90
 ballx = 200
 bally = 90
 z = 0
 score = 0

 rem main game loop

__game11

 rem reset system to OS

 if switchreset then goto __refresh

 scorecolor = 164
 COLUBK = 12
 COLUPF = 12
 COLUP0 = 164
 COLUP1 = 10
 COLUP2 = 10
 COLUP3 = 10
 COLUP4 = 10
 COLUP5 = 10

 rem enemy - fly game logic

 a = a + 1
 c = c + 1
 if a > 200 then b = b + 1
 if b > 10 then player1x = (rand&127) : b = 0
 if c > 200 then d = d + 1
 if d > 10 then player1y = (rand&63) + 1 : d = 0

 rem game timer and gameover

 e = e +1
 if e > 240 then f = f + 1 : e = 0
 if f > 5 then g = g + 1 : f = 0
 if g > 1 then player1x = 200 : player1y = 90 : player4x = 24 : player4y = 72: player3x = 24 : player3y = 60 : goto __gameover

 rem game sprites

 playfield:
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
end

 player0:
 %00011000
 %00011000
 %00011000
 %00011000
 %01111110
 %01101010
 %01010110
 %01111110
end

 player1:
 %00000000
 %00000000
 %01010100
 %00111000
 %00010000
 %00000000
 %00000000
 %00000000
end

 rem tone reset

 if joy0fire then AUDV0 = 0 : AUDC0 = 0 : AUDF0 = 0

 rem game player input function

 if joy0up then player0y = player0y + 1
 if joy0down then player0y = player0y - 1
 if joy0left then player0x = player0x - 1
 if joy0right then player0x = player0x + 1

 rem game player boundry

 if player0x < 6 then player0x = player0x +1
 if player0x > 148 then player0x = player0x - 1
 if player0y < 10 then player0y = player0y + 1
 if player0y > 86 then player0y = player0y - 1

 rem kill enemy trigger

 if collision(player0,player1) then goto __kill

__drawscreen_loop

 drawscreen
 goto __game11

 rem kill enemy trigger1

__kill

 if joy0fire then goto __splat

 drawscreen
 goto __game11

 rem kill enemy trigger2

__splat

 rem random spawn directly after kill

 if joy0fire then AUDV0 = 10 : AUDC0 = 10 : AUDF0 = 4
 player1x = (rand&127) : b = 0
 player1y = (rand&63) + 1 : d = 0

 score = score + 1
 
 drawscreen
 goto __game11

 rem game over loop

__gameover
 
 scorecolor = 10
 COLUBK = 164
 COLUPF = 10
 COLUP0 = 12
 COLUP1 = 10
 COLUP2 = 10
 COLUP3 = 10
 COLUP4 = 10
 COLUP5 = 10

 ballx = 21
 bally = 48

 playfield:
 XXXXXXXXXXXXXXXX
 ................
 ................
 ................
 ................
 ................
end

 if joy0fire then goto __refresh
 
 drawscreen
 goto __gameover

I have no doubt this probably needs a complete rewrite and a great example of not what todo however i guess we all gotta start somewhere. Yeah any help would be great as i know there is way too many goto commands making it very hard to follow resulting in the need of so many remarks everywhere lol. It's embarrassing posting this to folks that actually know what they're doing

[DZ-Jay]

Actually, in that example I meant that the GOSUB lines in the main loop call actual subroutines.

 

It depends in how you want to structure your code and the level of encapsulation, but I would put any logic inherent which each subroutine within it, rather than polluting the main loop with a bunch of confusing code.

 

So, for instance, in my own code the subroutine to update enemy state will itself contain any necessary loops to iterate through all enemies. It would also include any special conditional logic to determine whether an enemy should be updated or not. These could potentially be other subroutines themselves.

 

The idea is to encapsulate code for a particular functional aspect in one specific place, where it is can be easily reviewed, updated, and tested.

 

How do you communicate from one subroutine to the main program, well that's a matter of your own style. Since BASIC doesn't provide function return values, one way is to use global variables for state information.

 

For example, it is a lot easier to read (and debug):

   Gosub SetEnemyCollisionFlag
   If (EnemyCollisionFlag = 1) Then Gosub KillEnemy

Than this...

 

    If (BulletActiveFlag = 1) and (EnemyActiveFlag = 1) Then
      If (EnemyX = BulletX) and (EnemyY = BulletY) Then
        ' insert code here to kill enemy
      End If
    End If

Especially if you have a bunch of similar code contiguous for various conditions or events.

 

The former code encapsulates the logic in distinct subroutines and it can be easier to follow.

 

Again, the granularity is up to you, but it is generally considered good practice to keep your code clean in neat functional components, which is easier to test and maintain. Optimization can be done if and when performance becomes a concern.

 

dZ.

[+TwentySixHundred]

I think i got it, so if i set global variables, then if that variable is triggered ie: __kill_enemy=1 rather then preset 0 it will automatically goto a subroutine located outside the mainloop to check for conditions using the if statements? So basically rather then having if statements trigger the event the global variable will actually trigger the event (subroutine). If im understanding this correctly my lack of global variable use is actually bloating the mainloop with if statement making it confusing to follow? Actually makes alot more sense now im thinking about it, i never really understood what global variables where used for but now it's becoming alot clearer.

 

Thanks for taking the time to help me with this, im actually getting more excited to rewrite this program. Guess i should do some more reading about setting global variables as they seem to work hand in hand with the gosub statement and could be really useful. Looks like using the gosub statement clutters the mainloop by using a global to make the decision of when to jump to a subroutine is better practice. As you can probably tell im very novice and lacking alot of fundamental knowledge however it's fun learning and understanding my mistakes

Edited February 27, 2017 by Tony The 2600

[fujidude]

It's Time to give BASIC its due. Some people drink Mountain Dew while programming. Do you want to know a dirty secret? It's basically true that bad habits can cause defective doo-doo.

 

Ah yes, the bad habits argument against BASIC. I agree it is a valid point. But try to offer beginning programmers en environment which makes learning to program easy and three things jump out relatively quickly:

• An interpreter will need to be used to allow immediate feedback for experimentation with program changes.
• Keywords and constructs will need to be easy to remember, and thus similar to every day language patterns.
• Goto like branching should be available (even though it is not the best habit to form) because it allows someone to actually get started making very short, simple programs without the rigor of being forced to into rigid structure. Structure while over-all will provide for better written, easier to maintain, and easier to modularize software (of the sizes that useful software requires), it is actually a cumbersome and unnecessary burden when writing very short programs which are primarily for learning about programming computers.

Without making the kind of sacrifices that those kind of requirements have, it is very likely that a pretty good percentage of people who 1st learned to program in BASIC back in the day, may not have bothered to learn any programming at all.

Edited February 28, 2017 by fujidude

[fujidude]

And how is GOTO different than JMP?

 

The argument can be made that using JMP is not a good habit to get into either, and that JSR should be the law of the land. But then, for something real small and tight, the JMP actually is the better choice in many cases.

[DZ-Jay]

And how is GOTO different than JMP?

 

In the same way that BASIC is different from Assembly Language.