Making a Python interpreter in 1024 bytes
7 points by azhenley
7 points by azhenley
There exists an ancient, forgotten website called Stack Overflow where the code magicians of yesteryear shared their knowledge. I learned a lot of ideas from Tips for golfing in C.
Oh man, this took me back. I spent almost every day between 10-12th grade in high school on Code Golf Stack Exchange. This is how I learned to program and to question base assumptions about programming languages. I'm happy to see that, despite the site's decline, it still has its uses.
For anyone who might recognise me, I used to go by VTCAKAVSMoACE -- VTC for short -- and briefly FlagAsSpam. Cheers for the memories.
To feel human, I write code by hand on the weekends.
Relatable and depressing, a sad story in one sentence.
Making a Python interpreter in 1024 bytes
Oh come on, tone down the click bait. You could have said "I code golfed a code interpreter in 1024 bytes" and it probably still would have gotten clicks from the audience you're after without just outright lying to people
I haven't been here long enough to know if this qualifies for the spam flag, but I want to
I haven't been here long enough to know if this qualifies for the spam flag
Not really, but we do tone down clickbait titles (cf the guidelines on the Submit page.) You can suggest a new one.
The process was quite tedious
…
Now it is your turn
Yeah nah.
Since nothing is compiled, loops work by jumping backwards and reparsing the source each iteration
Genius
Heh, that kind of low-memory flow control was relatively common on old computers despite being very slow. For instance, the 6th edition unix shell didn’t have any built-in flow control: if and goto were separate commands. The fun thing about goto was that it just called seek on fd 0 and because the file offset was shared with the shell, it also moved the point where the shell was reading commands. There are still tricky cases where a unix shell must read stdin one byte at a time to avoid over-reading shared file descriptors…