[dead]
Making a Python interpreter in 1024 bytes
71–80 of 120 posts
Re: Making a Python interpreter in 1024 bytes
#72Reading the article, I can't believe I just found out Code Golf is a thing. I've been a programmer for more than a decade. But yes, amazing project! I like that it's human-made :)
The quintessential example is donut.c. I was amazed when I first came across it. https://www.a1k0n.net/2006/09/15/obfuscated-c-donut.html
This one is my favorite:
https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
Re: Making a Python interpreter in 1024 bytes
#73Earlier quoted context omitted.
Got it. You're looking at the problem from the other direction. Yes, tabs are unambiguous if they're the only thing used for indentation. It's when some people use tabs and others use spaces that ambiguity arises. But there are other cases where the variable-width nature of tabs can create ambiguity all by itself. Take this example from R7RS small: (cond ((> 3 3) ’greater) (( If you write it like this, a smart editor…
Surely tabs are only ambiguous if one considers the point of indentation to be to align things visually in relation to each other, as opposed to just being, y'know, indented. Besides, I'm sure many people would look at your Scheme snippet and argue that it's not really about indentation as much as alignment of the subforms, because in a Lisp those two things are basically equivalent, and that the distinction between…
> the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
It all works swimmingly until you introduce a nested scope (indentation, tabs) in the middle of an aligned scope (spaces). At that point it still works in the sense that everything is correctly aligned however depending on the editor the tabs might not all have the same width if you aren't able to disable tabstop.
So it isn't generally recommended for lisps in practice (because most common editors will correctly align any given block but when considered in whole the formatting will be inconsistent) but poses near zero problems for most c like languages. (If you're determined you can manage to create problems in a c like by nesting an anonymous lambda within an aligned list of statements or similar such shenanigans. However pretending that python or c++ is a lisp is generally frowned upon so in practice all tabs can be expected to appear to the left of any spaces.)
Re: Making a Python interpreter in 1024 bytes
#74Earlier quoted context omitted.
> you may use tab characters in a different way than most people seem to As far as I'm aware there are three primary and entirely independent uses for tabs. Indentation, field separation, and typesetting. When it comes to typesetting and also to display of fields with a narrow maximum width the concept of a tabstop is useful. Boneheaded things with tabs was in reference to code editors (where tabs are more or less ex…
Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meanin…
The cond example commits a sin (see my other reply), in the F# example tabs (were they permitted) would introduce no ambiguity if used solely to communicate indentation, and the only change I would make to the F# example were I formatting it myself would be to also align the `=` characters. Actually that supposedly bad style is more or less exactly how I write nix expressions (as a matter of practicality I do not use tabs when writing those FWIW).
Re: Making a Python interpreter in 1024 bytes
#75I hate when they measure the size of source code instead of the size of a binary.
I appreciate .kkrieger much more than this monstrosity
Re: Making a Python interpreter in 1024 bytes
#76Reading the article, I can't believe I just found out Code Golf is a thing. I've been a programmer for more than a decade. But yes, amazing project! I like that it's human-made :)
This is my favorite : https://www.cise.ufl.edu/~manuel/obfuscate/pi.c
Re: Making a Python interpreter in 1024 bytes
#77This seems to be in the same spirit as Justine Tunney's SectorLISP. Very cool. https://justine.lol/sectorlisp/
SectorLISP makes an important question in its implementation: how much can strip down Lisp before stops being Lisp. Same is not done for submitted interpreter. So, although SectorLISP goal is to be a Lisp-reduced-to-its-essentials implementation, the Python-1024 goal seems to be imitating Python in most minimal code possible.
Re: Making a Python interpreter in 1024 bytes
#78tl;dr:
1. Choose a small fragment of the language
2. Adapt an existing interpreter
3. Use a tool to shorten the code, 'minify'
Re: Making a Python interpreter in 1024 bytes
#79Re: Making a Python interpreter in 1024 bytes
#80Reading the article, I can't believe I just found out Code Golf is a thing. I've been a programmer for more than a decade. But yes, amazing project! I like that it's human-made :)