Survey posted 2009-01-01 15:46 by Michael.

Contribute ideas to surveys by sending a mail to survey@ticalc.org.

Become a better programmer has been my resolution for the past 5 years... It is something I will do anyway, so it is a good resolution.

Yeah, I've been programming for at least 15 years, and I'm still getting better. There was a time where I wrote programs with lots of Goto statements jumping outside of If...Then blocks and other horrible stuff. I also remember the days when I would write the code to an entire program all at once and then spend the next month or two debugging it enough to actually run (never mind the remaining logic errors). :-) Over time I discovered better strategies and now I know how to write small pieces of code and test them a little at a time, which is *much* more pleasant.

<<There was a time where I wrote programs with lots of Goto statements jumping outside of If...Then blocks and other horrible stuff.>>

(If you mean :if (condition) :then :goto x :end than disregard what I have to say; I'm talking about :if (condition) :then :(code) :goto x :end)

is this part of what causes err: memory? I often wonder what causes the error, and if (as I have somehow came to believe might me true) goto statements within if then blocks have something to do with it, I want to know. Also is it the same situation with loops, and is just :if (condition) :goto x (also) a problem? (for that matter, if it's caused by something different, by all means tell me.) Sorry about the off topic post (although it does apply somewhat to the become a better progammer option), but this has been bothering me for a long time and I don't know where else to ask this.

yes it causes err memory because a certain part of ram is set aside to look for that end, which it will never find

When you run for example the main program from inside a game it also create a memory leak. For example in a shooter or RPG when you die I always did the bad mistake of resetting the game by running the launcher right after the GameOver screen to save time and space, but it is something to not do. Have your code so it returns somewhere you can go back to the title screen or stop execution completly and have the user run the program again.

Sorry for the late reply (I wish they had a comment counter for surveys too so I would know when new comments are posted). When I wrote that I was actually thinking of a QBasic program I wrote, but I did plenty of that on the Z80 calcs in TI-BASIC, too.

Using Goto anywhere inside an If...Then...End block that jumps outside the block does cause a memory leak and will result in the program gradually running slower and slower and then ending with Error: Memory. It's because the interpreter still thinks it's inside the If block and reserves space on the stack because it's waiting to encounter the End, which it never reaches. Every time the block executes it thinks it's getting nested deeper and deeper inside If blocks until memory runs out. I'm pretty sure that using Goto to jump out of any other type of loop will cause the memory problem as well.

Just If ...:Goto (without the Then) isn't a problem since it's not considered a block (there is no End to wait for).

In fact, I remember the manual for the TI-82 and TI-85 (if I remember right) mentioning this problem in the section that lists all the error messages, but the funny thing is that back then I thought the manual meant the error would occur immediately. Since it never did happen right away, I ignored that part of the manual and then wondered for so long why my programs were always getting slower and crashing with a memory error when the answer was right there. :-)

This only affects the Z80 calcs' TI-BASIC, by the way. The 68K calcs seem to have a better interpreter which is clever enough to notice a Goto jumping out of a block and automatically adjusts itself to avoid the problem.

               .

>>I wish they had a comment counter for surveys too so I would know when new comments are posted.

Me too.

>>(The rest)

Thanks a lot! Now I can (mostly) fix that problem in my programs (who'd have thought my old style that I used before I knew about If Then blocks was actually better!?).

To answer his other question: yes, something like While ... Goto A ... End will cause the exact same error, for similar reasons.

== Solution 1 ==
When jumping out of an If ... Then block, embed the target label into a dummy If ... Then block:

:If 0:Then
:Lbl X
:End

If you're jumping out of nested logic, nest the dummies accordingly. I learned this trick from a program which had the following code:

:If 0:Then
:If 0:Then
:Lbl X
:End:End

== Solution 2 ==

Don't use Goto, it is evil (or "harmful", depending on who you ask :P ). Check the page I linked.

== On a slightly related note ==

Hmm, need to dust of an Z80-calc, because now suddenly I wonder what the following code would do:

:While 1
:Disp "1"
:Goto 2
:Disp "3"
:Stop
:End
:Lbl 2
:Disp "2"
:End

If this does what I think (hope) it will do, that would mean we could (hackishly) implement procedure calls!

>When jumping out of an If ... Then block, embed the >target label into a dummy If ... Then block:
>
>:If 0:Then
>:Lbl X
>:End

Actually, after I learned what the problem was, I was thinking something more like this:

Instead of using this:

:If (condition)
:Then
:(code)
:Goto X
:End

Use this:

:If (condition)
:Goto Y
:Lbl Y
:(code)
:Goto X

Another solution (albeit somewhat redundant) could be:

:If [condition]:Then
:[code]
:EndIf
:If [same-condition]
:Goto [label]

But the real solution, in my opinion, is to use subprograms and other structures instead of Gotos.

The problem with subprograms is that (in my experience) all your classmate will forget to copy them along with the main program.
Since the kind of programs that have enough complexity to need subprograms are generally the ones I actually want lots of people to use, it should be able to cope with the calc-savvy-ness of lots of people. (It's been a while since I was in high school, so this might have improved).

One technique is to have a single program call itself and use a variable of some sort (or maybe Ans) to indicate which routine to run. You'd check the variable at the beginning of the program to see what to do, or whether to start from the beginning. You'd have to have a way to know when the variable isn't defined, though. Maybe use a system variable, or use a list where you can use the instruction to set the size of the list, which automatically creates it if it doesn't exist. (It's been a long time since I've done any BASIC programming on the Z80 calcs, so I can't go into much more detail. I've spent a lot more time in TI-89 BASIC, which still isn't perfect, but does have better solutions for this situation.)

> One technique is to have a single program call itself and use a variable of some sort (or maybe Ans) to indicate which routine to run.
You really don't like headaches, do you? You won't use my wonderfully contrived, possibly-unstable hack which will strip any remaining readability from your program just because you've got a pretty straight-forward, completely clean and kinda readable alternative...? :(

Seriously though, thank you for the advice Travis! It will require a little bit of mucking about to determine whether the program was just started for the first time, or if it was called to perform a subroutine, but that's the only downside as far as I can see. (A "wee bit less" than the downsides of my hack, to put it mildly.)

To determine whether your program just started, I suggest the following:

:If Ans=sqrt(42)
:Then
: [start program]
: [foo]
: [bar]
: 1->Z:sqrt(42)
: prgmSELF
: [more stuff]
:Else
: [determine which procedure to start, based on value of Z]
:End

Just choose a value that's easy to calculate to denote your program is already running. By putting it in Ans (instead of a variable which keeps it value until explicitly overwritten), you can be almost sure it won't be there by accident. For instance, a user has to break your program using On, at the exact moment after Ans was assigned, but before the next expression is evaluated and then immediately start the program again to accidentally (doing it on purpose is pretty easy) make the program think it was already running.

Argh, the interpreter (at least the one in an 83) is just a little too smart... :( Executing the following program

:ClrHome
:Disp "A"
:1->Z
:While Z
:Goto 2
:End
:Disp "C"
:Stop

:Lbl 2
:Disp "B"
:0->Z
:End
:Disp "OOPS"

will output A, B, OOPS. When checking the condition again, it will remember where it found the End. So, to use a procedure, the following hack is needed:

:ClrHome
:Disp "A"
:2->Z
:While Z
:If Z=2
:Goto 2
:0->Z
:End
:Disp "C"
:Stop

:Lbl 2
:Disp "B"
:1->Z
:End

This /will/ output A, B, C. So, here's the general recipe for a procedure:

:SomeCode1
:Call Proc
:SomeCode2
:Stop
:CodeForProc

will turn into

:SomeCode1
:2->dummy
:While dummy
:If dummy=2
:Goto Proc
:0->dummy
:End
:SomeCode2
:Stop

:Lbl Proc
:CodeForProc
:1->dummy
:End

Pro:
- You get the functionality of procedures (or, using (for instance) Ans, functions).

Con:
- Procedure needs to know which dummy to use
- Becomes a horrible mess if you want to allow one procedure to call another (you'd need separate dummies).
- The "horrible mess" mentioned above will seem peanuts when you want to allow a procedure to call itself (maybe use a list of dummies and use one variable as a "stack pointer" telling which item in the list to use??).

Conclusion: proof-of-concept: yes, usable in real life: no :(

[ps. This is not off-topic of course; I voted I wanted to become a better programmer ;) ]

Voted to get another calculator though it is not at the top of what I would wish for this year. The top of my plans relate to reading.

A 92+ would be the calculator I would prefer.

There's no doubt that I will become a better programmer with Computer Science as my major, but I may, sadly, be moving out of the relm of calculators and on to bigger things.

Or do like me or what Fryedsoft did until 2003 and continue coding for calcs anyway during your hobbies or when you have time :D . He coded calcs since 1992 and did games until 2002 (in 2003 he had a project that he never finished, it was Legend Of Flandel or something). I myself finished school in 2004 but still do games from time to time

I work yet still fit in time for calculator programming, but maybe that's as Z80 assembly isn't as horrendous as PHP is. ;-)

Oh, come on, PHP isn't that bad :P
I'll take it any day over java(script) *shudders*
xD

Perl is far superior to the slow, useless, and stupid language that all the noobs are learning called "PHP."

Also, Javascript and PHP aren't even close to doing the same thing... JS is client-side, and PHP is server-side.

JavaScript (and other ECMAScript-derived languages) is an absolute joy to use when used properly. Try writing a lambda expression in PHP, for example!

No thanks :P

I prefer LISP for that sort of thing. :)

I want to learn Erlang this year, but who knows about that.

Well, I probably will still create calculator programs, just fewer and farther between.

No matter how busy I get, I'll die before I leave the realm of calculators.

Being an engineering student, then an engineer, I will never leave my calculator :)
I'm constantly using it, and making programs to make my life easier.