Hacker News Reader

Comment by agumonkey | Hacker News Reader

These sorts of minimalist bare metal abstract PL articles are so thrilling to me. APL comes to mind.

I wonder how high you can go with only 1MB say.

Assuming you mean static code size, my Mu project currently supports an interpreted Lisp (macros, fewer parens, infix) implemented in a compiled memory-safe low-level language without _any_ C in 450KB. The "runtime library" (mostly in the safe low-level language) requires 120KB. Without unit tests, the binary sizes drop down to 200KB and 30KB respectively, which gives you some sense of the space devoted to tests in each case.

As the tests hint, Mu doesn't do anything to try to reduce code size. It's small just by focusing on the essentials. What's left is written for ease of comprehension.

(An example of "essentials": Mu still cannot free memory. I run my programs in Qemu with 2GB which seems to suffice.)

More details: https://github.com/akkartik/mu

Author here. I assume you're referring to https://github.com/akkartik/mu/blob/main/shell/evaluate.mu? It's hard for me to tell, since there's 819k lines of code in Mu according to find . -type f | grep -v '\.git' | xargs wc -l. Does it have lambda and support metacircular evaluation? If not, then why do you think it's LISP-like? If you do nothing to reduce code size, then why do you call it Mu? (I assume by "Mu" you're referring to what UNICODE calls the MICRO SIGN.) 30kb is two orders of a magnitude larger. I don't see how it's relevant to SectorLISP.

Sorry to tramp over your thread! Mu isn't too related to SectorLISP, I was just responding to the side-discussion about what we can build in under 1MB.

To answer your question, evaluate.mu does support lambda (I call it `fn`). My estimates of size were based on `ls -l a.bin` after `./translate shell/*.mu`.

I actually didn't really think of the micro interpretation of 'mu' until years after I started the project. The interpretation I had in mind was https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_t...

It that case it'd be really cool if you implemented John McCarthy's metacircular evaluator in Mu LISP syntax to demonstrate it's a LISP. Sort of like how when John McCarthy shared the idea for LISP one of the first things he had to do was show that it's able to do the same things as a Turing machine.

No upvote needed :) but sure I'll post it here.

(I haven't done this so far because I find metacircularity to not be very interesting. It was interesting when JMC proved it could be done. Mu's whole reason for existence is linear rather than circular bootstrapping. We can disagree over whether I get to call it a Lisp or not, but if it has the full power of macros I'm happy.)

And Justine, if you want to join our ever continuing argument about bootstrapping processes and trust in programming language toolchains, Kartik is the right person to talk to :p

He probably was just responding to my 1MB limit. Don't be too harsh.

the variable/register idea is neat, I always wanted some veneer on top of raw registries.. almost like a cpu monad

major points for having a thorough test suite, it has saved my a** on my own projects countless times, and I still encounter projects too often IMHO that have barely any test suite if any at all

1 MB is huge.

Keep in mind that IBM PC/XT had only 640 kB, but there were compilers and interpreters for any language, which were available for it.

Moreover, before IBM PC, a CP/M computer with Zilog Z80 or Intel 8080 had usually only 32 kB or 48 kB, but you could use without problems Basic interpreters, Pascal, Fortran, Cobol and PL/M compilers and many others.

However, in order to fit in 32 kB, the compilers themselves were typically written using a macro-assembler, and not in a high-level language. The C language became popular for such tasks somewhat later.

The original Macintosh had 128k and managed to load a graphical OS and an app in that space. The ROM certainly helped, but it was quite a feat.

> Keep in mind that IBM PC/XT had only 640 kB

And that's the maximum (without bank switching schemes like EMS). The first version had only 64 KB. There were even plans for a 16 KB version with no disk drive but I don't think it was ever released.

The base model of ZX Spectrum only had 16 Kb, but it was enough for it to run BASIC.

And then there's FORTH, which is tiny even in a naive implementation, but can be taken to extremes as well: https://pygmy.utoh.org/3ins4th.html

k9 [0], an APL like, is under 160KB and includes a database in that.

[0] https://shakti.com

I shall gather all these projects on a wiki.

https://www.red-lang.org/p/about.html

Almost as batteries-included as python.

I love Red and want to use it more. Sadly my professional life keeps giving me hardware that I can't run it on, so Red is getting marginalized. I wish I had more skill and time to help them out with the 32 to 64-bit transition. [1]

[1] https://gitter.im/red/red?at=5e09152cd5a7f357e6a1af83

Ha, I didn't know the whole distribution fit in 1MB. Thanks

L - an embedded subset of Common Lisp used in Roomba, ran in 1MB of ram total afaik including compiler and support OS.

1MB is really a lot if you know what you're doing, what language you actually can't fit into 1MB of ram due to inherent specifics of language itself, not because interpreter/compiler doesn't optimize for such cases?

oh wow, roombas still run this subset of CL ??

ps: ohh that paper was on the frontpage not long ago, I just didn't realize it was used in Roombas

A lot, we only had 640KB to play with on most MS-DOS, Amiga and Atari computers, and 8bits had 64-128 KB.

hmm but were there high level languages being usable on these ? I remember a CLISP impl on some atari (but I think the dev had a ram addon).

all in all, I'd really love to have or make a 1MB minimalistic shell with a tiny lisp/prolog/smalltalk

Plenty of them, here is a non-exaustive list.

C, C++, Modula-2, Pascal, AMOS, Clipper, FoxPro, Turbo Basic, Quick Basic, Turbo Prolog, PC-Lisp, Native Oberon,...

Most then existing HLLs were very usable in 640Kb. If you go down to 8-bits, while translators for many of these did exist the utility was rapidly diminishing. You'd essentially have system's native version of BASIC + assembler for anything practical. The rest were more of parlor tricks.

In that context Forth was quite practical. That was its heyday.

INTERLISP was available for the Atari 800 (which max'd out at 48KiB RAM).

I wrote a full CAD/CAM suite for lathe/mill work in a few hundred K, working RAM was another 500K or so...

Honestly you and people writing similarly small applications should gather and write a book.

I don't know if I'm an alien but whenever I see frugal yet non trivial application my brain rejoyces.

This was back when 1 MB was considered and amazing amount of memory. It took two years to write this, about 50K lines of high level code and another 10K or so of assembly. Today you would approach such a project in a completely different way, you'd use much more time to make it look pretty and just that part would probably be much larger than the whole package that I wrote.

The funny thing is that even so many years later the original software is still in use in some places and there is a whole company centered around that core that has been re-written a couple of times to keep it up to date and to expand its functionality.

I highly doubt the present day version would fit in something that small. What's interesting to me is that that old stuff tended to be super productive to work with, zero distractions, just some clearly defined task in a clearly defined environment, if it worked it was bullet proof. No hackers, SaaS, a million connectivity options and no eye candy. Just that one job to be done and done as good as the hardware would allow you to.

But that's exactly my point. I think we forgot to aim at super productive, zero distraction, lightweight. And it would be of high educative value to see this sort of work again. Both on the small scale details and the pragmatic value.

The sad part to me is that most web apps reenact the same functions but in a css-transition-capable DOM. But functionally I'm not sure you get more.

I've tried to adhere to the same principles when building pianojacq.com, even so the linecount is huge for such a limited amount of functionality.

Reply on news.ycombinator.com