I began on the TRS-80 Model 1 with built in Level 2 BASIC. The “graphics mode” on that thing amounted to each of the “characters” in the 64x16 text display could be divided into six pixels. Was enough to create some blocky space invader like things.
I essentially learned to program by typing in listings from these books and paying a little attention.
For those who recognize those covers and want some nostalgia click into the listings. They have images of the original pages with the cheesy illustrations.
Memorized some BASIC lines on the ZX Spectrum but wrote my first lines of code in Turbo Pascal. Wrote among other thigs a savegame editor for Eye of the Beholder 2 and showed it to my teacher in school and he let me skip programming classes.
Just to get nostalgic for a moment. The generation of us kids that learned on these early PCs will be unique in the span of history. How we had to learn will never happen again. There was no internet or stackoverflow. We were lucky to have a small section at the bookstore. Just the circumstance of having these machines that didn’t have a vast array of games already in existence for them, thus forcing us to learn useful skills to make them fun, that’s just never going to happen again (outside perhaps of post-apocalyptic rebuild civilization from scratch scenarios). We experienced a truly unique moment of history at the dawn of a life changing and world changing technology.
The first computer I ever used did not have a monitor. The only output was to paper, continuous feed with those alternating dark and light green stripes. You entered numbered lines in BASIC. If you wanted to edit a line, you retyped the entire line with the same line number again.
Hypercard at home in the late 80s. I designed a series of first-person RPGs; one of them was quite elaborate: a first-person homage to Space Quest taking up 5 floppy disks.
When I was twelve I was taking classes at a local community college: Turbo Pascal 4.0 and then Fortran 77 were among them. I wrote a football simulator in a group of 4; it was some of the most fun I’d ever had programming. I’d get driven around by these three college students, we’d discuss probabilities of different yardage gains on a screen pass, etc. In the end you could select a large number of teams from D1 college, call different plays, and the rules were complete.
Lua has tighter design than Python by a lot. Its somewhat limited scope and abstractions help with that.
Yeah, using iterators in Python can be confusing sometimes. Over lists, since they don’t have “keys” , you just do for v in list. If you need the indexes on lists, you have to use an enumerator: for i, v in enumerate(list). And for dicts, you want to use for k, v in dict.items(); using for k in dict iterates on keys. You can also do for v in dict.values(). So yes, it is confusing.
And don’t get me started on metaclasses in Python. Oh God, it hurts. ;)
Auugghhh. Hadn’t even heard of these, thanks for pointing them out. The ‘joy’ of being in an enterprise is that we’re always a good 5-10years behind the curve.
None of those existed 10 years ago. Well, Erlang (on top of which Elixir and by extension Phoenix are implemented) did, but it was far from ideal for web development back then. Things changed - a LOT.
Actually, Python is simpler. The problem there is not the iteration expression - it’s the defaults they chose for the iterators.
for x in object in Python calls a function in that object that returns an interator, which it then calls. What the iterator returns depends on the implementation of that iterator. In the case of lists, it returns elements; in the case of dicts, it return keys.
dict.items() returns a different iterator, which returns tuples with key and value, much like the foreach example you just gave. That function call (.items()) on dict is just a way of picking a different iterator to use instead of the default. The syntax is fine. The problem is in the default iterator chosen for dict, if anything.
enumerate() is just a helper. It wraps an iterator with an iterator that keeps track of which iteration you’re at. Similar things exist in a lot of languages that use iterators, like Enum.with_index/2 in Elixir, or enumerate() in Rust.
OMG! I remember those books. I think I used them to learn to program too, although there was also an orange one that was rather thick too that had a lot of games in it. Also I had to save to casset tapes at the time.
I was in high school during the late 70s. During my last couple of years in high school, we got a “computer lab”. It was a Commodore PET. I wrote some very pathetic “games” for it. I recall one was a minefiueld game were you had to traverse across the screen without stepping on a mine. Totally random with no way for you to determine where mines were. Another was a vertical scroller where you just had to avoid stuff. As pathetic as these were, at least when we first got the computer, there was nothing else and kids would play them. Later somebody got their hands on some real games.
Ooh - I know the answer to this. TRS-80 Level 1 Basic! I used to write my own (terrible) text based adventure games (using a knockoff of the standard two word parser). Was too young and inexperienced to figure out how to properly reuse the parser using goto to make the equivalent of functions… so had to rewrite it for each room. Alas.
That’s pretty much exactly what C# does with foreach as well. It only works on classes that implement the IEnumerable interface, which enforces a GetEnumerable() method. I just like the static typing in C# because I know ahead of time what I’m dealing with.
