Creative Programming for Young Minds

[Opry99er]

http://pages.ebay.com/link/?nav=item.view&id=351349771185&alt=web

 

 

Anyone have these? Thinking about buying them for my son. He is only 6, but reads and thinks at somewhat of a higher level...

 

How is the content of these books? Is it geared toward young kids or teens?

 

Anyone have a scan I can take a look at?

[+OLD CS1]

I was considering picking those up as I have another volume. Tell you what, you get those two and I will donate the one I have. It is yellow, so I assume it is a different volume than the red and orange ones.

 

If you want, I will try to scan mine up and give you a sneak-peek.

[Opry99er]

I think there were 3 volumes.

 

If you could just take a good phone pic of some text and maybe a program listing, it will tell me if we are in the ballpark.

 

Thanks, bud!

[+Schmitzi]

I have seven of them, and some more

 

too much for AA, so please just download them here:

 

ftp://u67140205-atariage:TeXasTI994A@toxic-instruments.com/_DOCUMENTS.bak/CreativeProgramming/

[Opry99er]

Wow! Thanks Schmitzi!! That is a big help!

[+OLD CS1]

Yeah, the yellow "All Stars" is the one I have.

[+Ksarul]

For the longest time, I thought there were only the three volumes plus the Yellow All Stars. Ernie Pergrem had four more--and scanned the whole series. Owen, you probably need to look at the HUGE library of scanned TI books on Acadiel's Hexbus site.

[+Schmitzi]

Yes, i think that was my source, times ago

They are very good arranged on that site, with perfect overview.

thx

[matthew180]

Run away! I just sampled the first volume of "Creative Programming" and a few exercises into the book I was presented with this:

 

10 GOTO 100
20 PRINT "LOVES"
30 GOTO 90
40 PRINT "HIS"
50 PRINT "TI"
60 GOTO 160
70 PRINT "TO"
80 GOTO 140
90 GOTO 70
100 CALL CLEAR
110 PRINT "TEX"
120 GOTO 20
130 END
140 PRINT "PROGRAM"
150 GOTO 40
160 PRINT "HOME"
170 PRINT "COMPUTER"
180 GOTO 130
190 PRINT "TRICKY"
200 GOTO 130

I'm speechless (which is why I'm writing this. )

 

Let us take absolute beginners to programming, and within a few lessons teach them the biggest sin of all programming! The single command and practice that is synonymous with BASIC and that prevents, to this day, anyone from taking any variant of the BASIC language seriously. GOTO. And worse, being used for *fun* in all its spaghetti glory.

[Opry99er]

Wow.... That.... Is.... Beyond words...

[Omega-TI]

Damn, that's horrid... even by my standards!

 

[+OLD CS1]

Being that it is obviously deliberately spaghetti, perhaps this was an example of how NOT to do things? I hope.

[Opry99er]

That was my initial thought too... Then I thought... "Well, maybe this is teaching kids how 'program flow' can be non-linear".... Then I thought about that for a minute... and then I threw up all over myself.

[Bill Loguidice]

I understand it's garbage code, but I do like the idea of challenging the reader to really think about /try to follow the flow of the program. Assuming the rest of the examples/teaching aren't like that, I like that single idea in isolation.

[Opry99er]

^^I can see that.

[JamesD]

I think that program was about understanding how GOTO works so I don't worry about it too much, but they should point out that is bad coding style.
I converted an 80's BASIC game to C several years back and found lots of problems that were caused by GOTOs going all over the place and the programmer couldn't see his mistakes.
My C port was probably the first version of the game that actually worked right.

[matthew180]

In my opinion using bad practice in a learning environment, for any reason, is unacceptable. You could certainly come up with ways to demonstrate non-linear program flow using good design. GOTO is a command that does not require extreme examples to understand. Also, at that point in the whole series (a few exercises into the first book) it is too early to start introducing non-linear program flow.

 

The example is teaching that GOTO is how you control overall program flow, which it should never be used for. That is a path to unmaintainable spaghetti code. GOTO (unconditional jump) should only be used as a looping construct in the absence of language-supported constructs like WHILE, FOR, DO, etc. Since many ROM BASIC implementations eliminated every loop construct except FOR, and requiring line numbers, use of GOTO for program flow is almost inherently encouraged and an easy trap to fall into.

 

Allowing direct line number branching as the target of a THEN or ELSE statement is almost as bad.

[Opry99er]

Quick question for you, Matthew.

 

In my own development projects, I use IF THEN ELSE quite a bit. When working with TIdBiT, I will often transfer program flow to a subroutine defined by a label, IF a condition is met..

 

IF X<1 THEN GOSUB CharUpdate

 

Or something of the like.

 

Often this is all I will need to specify conditions, but in certain cases, a GOTO(top of sub for additional processing) is required.

 

In these cases, my code is translated

 

2000 IF X<1 THEN GOSUB 2800 :: RETURN

2010 GOTO 1990

 

This is, essentially, an IF THEN ELSE statement, only I am putting the ELSE on a separate line so that if the condition is met, it will branch to the SUB 2800, then come back from the sub, then RETURN to the primary game loop. (GOSUBs calling GOSUBs)

 

Would this be an example of poor craftsmanship?

[+Schmitzi]

Hi,

my basic is really rusty, but isn´t this here the same

(it´s also interesting for me, although not answering your question)

 

2000 IF X<1 THEN GOSUB 2800
2010 RETURN

 

Sorry if dumb question

[Opry99er]

Not in the case I am describing. Here, we are already in the midst of a GOSUB, preparing to call another GOSUB. Line 2000 checks for a condition, if true, program flow branches to SUB2800. Once 2800 is completed, it will return to the GOSUB statement, then RETURN back up the line to the original GOSUB that called LINE 2000.

 

Assuming X is equal to or greater than 1, the program GOTOs the top of the sub, which is 1990.

 

This is not exact code from one of my projects, but I have similar code.

 

I am just wondering if this can be improved upon, based on the fact that we generally dislike GOTOs.

[unhuman]

Are you gonna buy it? I'll defer to you, otherwise I might get 'em.

[matthew180]

In these cases, my code is translated

 

2000 IF X<1 THEN GOSUB 2800 :: RETURN

2010 GOTO 1990

 

This is, essentially, an IF THEN ELSE statement, only I am putting the ELSE on a separate line so that if the condition is met, it will branch to the SUB 2800, then come back from the sub, then RETURN to the primary game loop. (GOSUBs calling GOSUBs)

 

Would this be an example of poor craftsmanship?

Using GOSUB is great, especially when you can use a label that describes what the subroutine does. Functions that call functions are perfectly okay too, just try not to get carried away or you will end up with something like Object Oriented design.

 

Using GOSUB helps modularize your code, and when reading through the code you know the program flow will come right back to where the GOSUB call is.

 

The GOTO in your example might be a problem though, since it jumps backwards over the IF THEN and I can't tell what you are doing.

[Opry99er]

You should see my menu code for the game... Sometimes 7-8 GOSUBs calling GOSUBs and then a work back up the line. Gets ridiculous, but it works.

 

I'll dig through my code tonight and find an actual example of an unconditional jump to show what's happening there...

 

In redesigning certain portions of the menu once full functionality was achieved, I tried adding a few GOTOs to readjust program flow and ended up murdering a bunch of stuff... It was bad, and I am still dealing with the aftermath of it on one really bad bug. I need to stop and rethink the flowchart, but a big part of me just wants to add in a hack to deal with the condition... Would solve the problem in a jif, but I will hate myself in the morning on the GOTO walk of shame.

[matthew180]

Owen, your menu complexity problem is the design. However, you had to solve the problem once to know what you wanted to do, now you have to figure out how to really solve the problem. Basically you have to solve the problem to know how to solve the problem. That is part of learning though. I, or any number of other people here on the forum, could have handed you a menu solution, but this is your project and you would not have learned anything from that.

 

To me it looks like you are stuck in what I call the "TI Trap". It is a way of presenting a menu that requires many levels and lots of text. Like TOD, "now type the name of the character to receive the ...". Ugh. Painful. While the old systems are restrictive for sure, there are better ways. Look at games like the Classic Zelda and other such games on other systems. You will find that interacting with merchants and such in the game is all done very quickly and efficiently through pop-up menus that let you make selections with the controller, etc.

 

Separating your "data" from the "presentation" is also important. Your menu code should not have anything hard coded into it, otherwise expanding it or using it for another project will be difficult. This idea is typically known as MVC (model, view, controller) and can be put into practice on any platform and any programming language. You might want to try writing just a menu system as a stand-alone program.

[Omega-TI]

Quick question for you, Matthew.

 

Would this be an example of poor craftsmanship?

 

Poor craftsmanship? I took the blue in that department! Instead of writing a bunch of code to detect for one specific error that could have resulted at a specific point in the programs interaction, I exploited the ON ERROR n command in XB. It saved a ton of work, time and space in the program.