I could bitch about XSLT again, as that was certainly painful, but that’s less about learning a skill and more about understanding someone else’s mental diarrhea, so let me pick something else.

My most painful learning experience was probably pointers, but not pointers in the usual sense of `char *ptr` in C and how they’re totally confusing at first. I mean, it was that too, but in addition it was how I had absolutely none of the background needed to understand them, not having any learning material (nor guidance), nor even a typical compiler to tell me what i was doing wrong — and on top of all of that, only being able to run code on a device that would crash/halt/freak out whenever i made a mistake. It was an absolute nightmare.

Here’s the story:

Someone gave me the game RACE for my TI-83 calculator, but it turned out to be an unlocked version, which means I could edit it and see the code. I discovered this later on by accident while trying to play it during class, and when I looked at it, all I saw was incomprehensible garbage. I closed it, and the game no longer worked. Looking back I must have changed something, but then I thought it was just magic. It took me a long time to get curious enough to look at it again.

But in the meantime, I ended up played with these “programs” a little, and made some really simple ones, and later some somewhat complex ones. So the next time I opened RACE again I kind of understood what it was doing.

Moving on, I spent a year learning TI-Basic, and eventually reached the limit of what it could do. Along the way, I learned that all of the really amazing games/utilities that were incredibly fast, had greyscale graphics, lowercase text, no runtime indicator, etc. were written in “Assembly,” so naturally I wanted to use that, too.

I had no idea what it was, but it was the obvious next step for me, so I started teaching myself. It was z80 Assembly, and there was practically no documents, resources, nothing helpful online.

I found the specs, and a few terrible docs and other sources, but with only one year of programming experience, I didn’t really understand what they were telling me. This was before stackoverflow, etc., too, so what little help I found was mostly from forum posts, IRC (mostly got ignored or made fun of), and reading other people’s source when I could find it. And usually that was less than clear.

And here’s where we dive into the specifics. Starting with so little experience, and in TI-Basic of all things, meant I had zero understanding of pointers, memory and addresses, the stack, heap, data structures, interrupts, clocks, etc. I had mastered everything TI-Basic offered, which astoundingly included arrays and matrices (six of each), but it hid everything else except basic logic and flow control. (No, there weren’t even functions; it has labels and goto.) It has 27 numeric variables (A-Z and theta, can store either float or complex numbers), 8 Lists (numeric arrays), 6 matricies (2d numeric arrays), 10 strings, and a few other things like “equations” and literal bitmap pictures.

Soo… I went from knowing only that to learning pointers. And pointer math. And data structures. And pointers to pointers, and the stack, and function calls, and all that goodness. And remember, I was learning and writing all of this in plain Assembly, in notepad (or on paper at school), not in C or C++ with a teacher, a textbook, SO, and an intelligent compiler with its incredibly helpful type checking and warnings. Just raw trial and error. I learned what I could from whatever cryptic sources I could find (and understand) online, and applied it.

But actually using what I learned? If a pointer was wrong, it resulted in unexpected behavior, memory corruption, freezes, etc. I didn’t have a debugger, an emulator, etc. I had notepad, the barebones compiler, and my calculator.

Also, iterating meant changing my code, recompiling, factory resetting my calculator (removing the battery for 30+ sec) because bugs usually froze it or corrupted something, then transferring the new program over, and finally running it. It was soo slowwwww. But I made steady progress.

Painful learning experience? Check.
Pointer hell? Absolutely.

  • 1
    Pointer for Pointers, and you will feel you are creating black holes in your code. Felt you all the way.
  • 1
    I remember seeing classmates playing mario on the big screen calculator and to me that was sorcery! How could they take mario out of a nintendo machine??? That was bleasphemy to my 13 year old “brain” thing! Years later, I learned the magic behind the sacred glowing box
  • 0
    I've always found pointers rather simple and intuitive. Heck, even pointers to pointers aren't that difficult once you understand simple pointers. Given, of course, that one has the required knowledge to understand them at least a bit, which you clearly didn't have at the time.

    Memory management is another story. Easy to understand, easier to fuck up.

    I'm curious, how did it felt when you finally "got it", when suddenly pointers and data structures weren't just amorphous beasts anymore and became tools and knowledge ?
  • 0
    @pipe Totally agreed.

    Pointers …
    Since I didn’t learn them the usual way, I’m not really sure I had a relatable Aha! moment.

    They’re pretty easy to understand in assembly. Literally the difference between “ax” and “(ax)”. The difficulty is keeping track of them, knowing what areas are of off limits, etc.

    I figured out pretty quickly that they were just the addresses of a byte in memory. (The z80 is 8bit with only one 16bit register (HL), and both halves of it are individually addressable, too, so “byte” is actually accurate).

    It was much more of a surprise when I figured out I could keep more than a single byte there and just do math on the pointer… and then that I could put more pointers a few bytes later on! It was a bit like taking areas of land and building things on them. But I more see these as discreet objects that link together kind of like puzzle pieces?

    But I started using these areas of memory for storing settings, and later things like game items with attributes. Years later when I was learning C, I discovered I had been implementing structs and complex linked lists :)

    You’re right about memory management though: I only had about 27k to work with, and this included my own code. If I wanted to get rid of an area in memory, like an item or mob in a game, I had to figure out a way of tracking which were now “deleted” so I could reuse that space later. So I wrote a basic malloc…. which uses its own linked list, which is dynamic in size, needs a lot of room to expand, … all in assembly, iterating slowly with no debugger, etc.
Add Comment