3 ms·

While I will always be nostalgic for TI-Basic as my first language, I think it really stunted my programming understanding when I moved on to "real" languages.

While I will always be nostalgic for TI-Basic as my first language, I think it really stunted my programming understanding when I moved on to "real" languages. I remember absolutely struggling to understand the idea of structs/classes, because in TI-Basic, everything is quite flat and global -- you get nearly no encapsulation. You have 27 named variables that could hold a floating point number (A-Z and Theta), the Ans variable which was the result of the last computation (and was slightly faster to access than normal variables), 1-indexed lists with maximum length 999, and strings with length bounded only by RAM (something like 16KB or so). If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language. It did force you to learn to think outside the box to solve problems though!

Jtsummers 4y ago
Those limitations always baffled me for the TI-83/84 line. They weren't present in the TI-85/86 line. Lists were bounded only by system memory (both in capacity and number of lists), and variables could be up to 8 characters (still limited, but not as bad as only 1 letter names). The main limitation high school me ran into was when I wanted to implement some recursive programs and had to recreate the call stack using lists as the stack. It was effective, and certainly made understanding an actual call stack easier later on when I got to my CS courses. I stopped using it after 1999, though, when a kid I was tutoring (wasn't sure which one) stole it from me. Replaced it with an HP-48G, I had a lot more fun programming in RPL than BASIC (which I'd been using for close to a decade by that point in some form or another).
acjohnson55 4y ago
I remember all those constraints, but I think for me, it was a really good thing, because it helped me understand the reason for the more complicated features of real programming languages. I knew cramming things into lists or strings was a kludge. But before I had learned TI-BASIC, I had attempted to learn C and JavaScript. Back in the 90s, I feel like most books on programming in stores were more like language reference manuals than instructional books. It was like, "here is every feature, good luck to you". After TI-BASIC, I was like, oh, I see why being able to dynamically allocate memory is so great. I see why explicit function parameters are so great. I see why return values are great. Et cetera. But what really did it for me was learning Z80 assembly. That gave me an understanding of pointers, memory architecture, system calls, build process, toolchain, and so forth. Between the two very different calculator programming experiences, I was finally primed to be able to learn C.
donatj 4y ago
> If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language. I think all TI graphing calculators support matrices, certainly the entire 8x line including the 83. It’s a much better way to handle large data sets than string finagling when programming them. You can treat them as a 2 dimensional array. The TI-73 has some dumb price/grade-ranged restrictions on operations and dimensions. I collect calculators and own almost every model of TI graphing calculator except some of the newer color models. http://blogs.jccc.edu/math/files/2011/12/Matrices-and-the-TI-83-84.pdf http://blogs.jccc.edu/math/files/2011/12/Matrices-and-the-TI...
- gamegoblin 4y ago
  Matrices were fine if your data mapped to 2 numeric dimensions snugly, but otherwise waste a ton of space. Space was the main constraint here. With strings, you could get very close to base256 encoding, because you could store any valid token as a single byte, and there were almost 256 tokens. E.g. SIN, COS, TAN are all single tokens. Whereas matrices take up 9 bytes per element. A lot of games used bitmaps to store sprites or level data, so as long as you avoided a few forbidden patterns, you could encode 8 pixels per token which was pretty cool.
dmurray 4y ago
So it embraced an extreme microservice architecture where every result must get serialised to a string and deserialised by the next function/service that processes it. How ahead of its time!
IIAOPSW 4y ago
You did your hacks out of string manipulation? I didn't even know that was in there. I just used the list variables (basically vectors and matrices) when I needed more than 27.

Jtsummers 4y ago

Those limitations always baffled me for the TI-83/84 line. They weren't present in the TI-85/86 line. Lists were bounded only by system memory (both in capacity and number of lists), and variables could be up to 8 characters (still limited, but not as bad as only 1 letter names). The main limitation high school me ran into was when I wanted to implement some recursive programs and had to recreate the call stack using lists as the stack. It was effective, and certainly made understanding an actual call stack easier later on when I got to my CS courses. I stopped using it after 1999, though, when a kid I was tutoring (wasn't sure which one) stole it from me. Replaced it with an HP-48G, I had a lot more fun programming in RPL than BASIC (which I'd been using for close to a decade by that point in some form or another).

acjohnson55 4y ago

I remember all those constraints, but I think for me, it was a really good thing, because it helped me understand the reason for the more complicated features of real programming languages. I knew cramming things into lists or strings was a kludge. But before I had learned TI-BASIC, I had attempted to learn C and JavaScript. Back in the 90s, I feel like most books on programming in stores were more like language reference manuals than instructional books. It was like, "here is every feature, good luck to you". After TI-BASIC, I was like, oh, I see why being able to dynamically allocate memory is so great. I see why explicit function parameters are so great. I see why return values are great. Et cetera. But what really did it for me was learning Z80 assembly. That gave me an understanding of pointers, memory architecture, system calls, build process, toolchain, and so forth. Between the two very different calculator programming experiences, I was finally primed to be able to learn C.

donatj 4y ago

> If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language. I think all TI graphing calculators support matrices, certainly the entire 8x line including the 83. It’s a much better way to handle large data sets than string finagling when programming them. You can treat them as a 2 dimensional array. The TI-73 has some dumb price/grade-ranged restrictions on operations and dimensions. I collect calculators and own almost every model of TI graphing calculator except some of the newer color models. http://blogs.jccc.edu/math/files/2011/12/Matrices-and-the-TI-83-84.pdf http://blogs.jccc.edu/math/files/2011/12/Matrices-and-the-TI...

gamegoblin 4y ago
Matrices were fine if your data mapped to 2 numeric dimensions snugly, but otherwise waste a ton of space. Space was the main constraint here. With strings, you could get very close to base256 encoding, because you could store any valid token as a single byte, and there were almost 256 tokens. E.g. SIN, COS, TAN are all single tokens. Whereas matrices take up 9 bytes per element. A lot of games used bitmaps to store sprites or level data, so as long as you avoided a few forbidden patterns, you could encode 8 pixels per token which was pretty cool.

dmurray 4y ago

So it embraced an extreme microservice architecture where every result must get serialised to a string and deserialised by the next function/service that processes it. How ahead of its time!

IIAOPSW 4y ago

You did your hacks out of string manipulation? I didn't even know that was in there. I just used the list variables (basically vectors and matrices) when I needed more than 27.