[nurettin]

Fire up your python IDE and make a bouncing ball. Nowadays programming feels a lot like an MMORPG. You can't do a solo mission, lest you will get stuck behind some bushes unable to move.

You have to go downtown, fetch some libraries, visit their documentation stores, check facebook, take a look at your stackoverflow pending events, polish your IDE to work with whatever you've just downloaded, copy-paste some code, refurniture until it works, then refactor until you are satisfied. Repeat forever.

Before, all my turbo pascal adventures were solo missions. Batteries were included. I did not leave the IDE and did not need another book. I did not download additional manuals. It was all there.

[phtrivier]

I share the overal nostalgia here (I learned BASIC on an Amstrad 6128 with nothing but a book and some teenage summer nights to waste.)

I also agree that I don't know which took I would point out to a kid wanting to start today, that would not involve a probably complicated setup.

That being said, I also remember being pretty frustrated that the best I was able to do - lacking resources, books, Internet, etc... - was put a couple of pixels around, and pretend it was a game (and be ashamed of it, even if it was in 1993 or something.)

A kid starting Unity3D today, on the other hand, would probably, (after a few hours lost installing stuff), create a decent-looking game in a few weeks of following Youtube tutorials and stealing art assets all over the internet.

Or is it not even possible ?

Anyway, my questions would be: what kind missions where you doing, entirely solo ?

Do you think the language itself had anything to do with the ease of starting ?

Do you think it would be satisfying to someone to start with something that lets them draw stuff, bounce a ball, etc... in a "limited" language, in a "fake" environment, before diving into the "hard" part, trying to do it by hand, etc...

[nurettin]

Had the exact same experience with C= 64 and the guidebook that came with it.

Never thought I was doing something silly peek/poke'ing memory and using data segments to represent sprites on screen. I was adding numbers to represent pixels on a 16 bit row as soon as I learned how addition worked at school.

Later on, I was using sin/cos to represent motion as soon as I learned how trigonometry worked at school. Along with some bresenham algorithms book I found at a university to draw lines and circles more correctly and effectively.

Some time later, I was visualizing prime numbers and geometric primitives in ways I could only imagine.

Later, I was using derivatives to represent optimal solutions to targeting problems as soon as I learned how differential equations worked.

Later, I was using field equations to represent gravitational pull in n-body simulations as soon as I learned about them.

Then things became more abstract, like visualizing finite automata and abstracting logic circuits.

Until that time, I did not need to leave the editor or download someone's libraries. It was all there. My age of discovery was a continuous experience that spanned over 10-13 years and defined my abilities as a programmer today.

I was never ashamed of "putting two pixels together" or envious of kids that "could make a game in two weeks using stolen assets and unity" - a program that places sprites on screen using easing algorithms and accelerated graphics. More power to them.

[FiddlyPack]

Highly recommend you check out PICO-8