I came across a PICO-8 tutorial today. While I was aware of the platform, I didn’t know much about it. What I found most interesting is that the limitations, in particular the restriction to 8192 “tokens” that your Lua source code can maximally have, made the person conducting the tutorial optimize the code several times to reduce the number of tokens used. He achieved that mostly through basic refactoring, often using the DRY principle, but also sometimes making the code a little more concise/clever/obscure. This (artificial) limitation adds a dynamic to development for PICO-8 that I find fascinating. It adds a forcing function for “keeping code lean” which I haven’t seen like this anywhere else. The only other similar thing I can think of is the 140/280 character limit on Twitter. Or maybe demoscene contest categories that limit the code and/or binary sizes to a certain amount of bytes. Do you know of any other programming environments or IDEs that use soft metrics or hard limits or any other tricks to introduce an awareness for wastefulness to programming? And how do you feel about that as a means to improve code quality?

Minor counterpoint story: My Mu project leans heavily on projects like the bootstrappable compiler (https://github.com/certik/bcompiler) and StoneKnifeForth (https://github.com/kragen/stoneknifeforth) which impose draconian limits on lengths of various names. In Mu I went the route of having no such limit, and having long names like https://github.com/akkartik/mu/blob/0671315c1af4707fcab30b11967c88fbaa386bf3/085next-word-or-string.subx#L353 made a huge difference in making the setup feel more ergonomic, so that I wasn't immediately hankering for something better the moment I got it working. The net effect: someone coming to my project only has to learn 2 notations, unlike in other bootstrapping projects where they have to learn 4 or 5, because the bottom two were built so parsimoniously that they're no fun to program in at all.

Android’s VM has a 64K method limit that results in tech to remove unused bits of code. https://developer.android.com/studio/build/shrink-code.html#shrink-code

One of the things discussed on the last episode of the podcast is Devine's interest in keeping the core of Orca small (around 600 LoC in the original JS, if memory serves) to make it easier to port to other languages. And the things you make in it are severely limited by the amount of screen real estate.

If anyone hasn't seen Joseph White's practice talk explaining the Pico8 design philosophy definitely check it out

There is an irreducible limit to the size of any given program. Part of it is due to Ashby's law of requisite variety (see Stafford Beer, Platform for Change), but a lot has to do with the compactness of the notation, and the ease with which redundancy is squeezed out. It is a very interesting exercise to study simple projects and boil them down to near the irreducible minimum. In fact, this is how i designed my Beads language; by starting with projects and then designing a notation that would allow for minimal number of words to express that action. The beauty of less code is there is less chance for error, provided you haven't over minimized and obscured logic by blindly pursuing word count as the goal. One must always balance readability with compactness. This was the original mistake of Iverson, which took him a long time to realize, that APL's invented alphabet was obscuring the power of his language (hence his use of ASCII in the J language sequel to APL).

ColorForth takes this idea of "creative limitation" farther than any other language I can think of. https://colorforth.github.io/cf.htm • The language is written using 48 ASCII characters, which enables you to code using a special keyboard layout (if you like) where your fingers never leave home row. • Identifiers are typically limited to 6 characters. They must fit into 32 bits after being compressed using "Shannon coding". • Source files are called "blocks" and are limited to 256 "words". An entire block fits on the screen at once, so there is no need for scrolling. • Function definitions are typically 1 line long. That's not directly enforced, but Forth code becomes increasingly hard to decipher when functions are longer than this.

FORTH and its cousin Postscript are very compact languages. I think FORTH is probably the most compact language, but also very difficult to read, as effectively you are pushing things into the stack, and you have to memorize how many items on the stack are consumed by each operator. APL had built-in graphing which was wonderful in its day (character graphics based plotting!), so it became more popular. FORTH was targeting embedded systems. If i am not mistaken it was invented for telescope control. FORTH was actually embedded into each Microchannel board; the Microchannel architecture was invented by Data general, and then licensed by IBM for their PC. The beauty of that architecture was that the boards each had some firmware on them, written in FORTH that would negotiate for interrupt vectors and low memory space. They needed a super compact language, so they used FORTH. But the terrible readability has hindered FORTH's general commercial use. I am surprised at how little people use J and FORTH given that they both work very well, and are super powerful. If you are doing a one man project, you might not care about readability. Perhaps it is all the hoopla around functional programming that makes people ignore these very interesting languages.

@Scott Anderson Thanks for sharing that talk. I hadn’t seen it. I obviously love how he approached the design of his fantasy consoles. So many thoughtful design decisions! For instance moving from a character limit to a token limit to rectify a bias towards minification and encourage shareable code. Love this stuff.

I'm watching Joseph White's talk now. I really like his phrase "careful friction".