[ebarns]

Not necessarily true :( Python is pretty out of the box in my opinion. There is setup involved if you want to create proper dev environments but you can avoid it also. Always love how easy it is to jump straight in and start coding something.

[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