mal VS Apollo-11

>Would be interesting to see how the interpreter works actually...

It's quite easy to see, there are interpeters for Lisp in like 20 lines or so.

Here's a good one:

https://norvig.com/lispy.html

(It has the full code in a link towards the bottom)

There's also this:

https://github.com/kanaka/mal

Here is one implementation of a lisp (mal specifically) in matlab: https://github.com/kanaka/mal/blob/dcf8f4d7b9cf7b858850a04a0...

Only 260 lines of code, pretty concise :)

have a look at the crafting interpreters book, plus make a lisp (lisp is a great first language to make a compiler/interpreter for, just google "lisp compiler/interpreter" and you'll find lots of resources)

If you're really okay with the limitations of a tree-walk interpreter, you might want to check out MAL, which will teach you how to write a tree-walk interpreter for a LISP. The code for MAL has been translated to most popular languages, so you can work through the creation of an interpreter in the language of your choice. JLox would give you a bit more detail and a more complex language, but I'm not convinced that it's all that important.

Write a small programming language (lisp (https://github.com/kanaka/mal) or brainfuck) in C++ to learn the syntax more. This will teach you a lot about programming languages in general.

So I started some hobbyist game dev using Unity and realised that the full process of making a game has dependencies on a mass of lower-level skills including lighting virtual environments. As a hobbyist photographer I could see some useful analogies from lighting studios and other scenes

So I pivoted, and eventually made money, not from selling a game, but from developing tutorials about digital lighting. I was also able to contribute to a project at work that was making a product based on commercial games engine, not by actually coding it, but by helping to better estimate the costs of the asset generation required.

Coding Unity object scripts in C# also got me back into programming, and I went on to successfully build a self-hosting lisp interpreter following the Make a Lisp guidelines [0].

[0] https://github.com/kanaka/mal/blob/master/process/guide.md

Hijacking the top comment to add https://buildyourownlisp.com and https://github.com/kanaka/mal

I often like to think about https://github.com/chrislgarry/Apollo-11 as an analogy. It's public domain with available source, in the assembly language in which it was written... so it fills all the definitions of OSS!

But the process by which that code arose, the ability to modify any line and understand its impact (heh) on a real execution environment, is dependent on a massive process that required billions of dollars and thousands of the smartest people on the planet. For all intents and purposes, without that environment, it is as reliably modifiable as an executable binary in any other context - or a set of weights, in this one!

But can a Transformer run on the Apollo Guidance Computer?

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

Frequency 2.048 MHz

Memory 15-bit wordlength + 1-bit parity

2048 words RAM (magnetic-core memory)

https://github.com/chrislgarry/Apollo-11/blob/master/Luminar...

You can look at the Colossus 2A code written by Margaret Hamilton and her very small team on Github.

"Burn Baby Burn" might be even more apt!

https://github.com/chrislgarry/Apollo-11/blob/master/Luminar...

My more positive take on this: our runtime environments are bloated because we have ways to enable trust, stability, and iteration speeds that people wouldn't have dreamed of in years past.

Your Notion desktop app and Google Chrome both support embedding & displaying multimedia content that's controlled by people that you may not trust, but they can draw on decades of engineering to sandbox that content. They can independently be updated without worrying about a centralized `flexbox.dll` that may or may not be the right version. They do not require building a new executable to make the vast majority of UI changes. And the cost is simply storage space and initial download bandwidth.

We can look with rose-colored glasses at an era of "every byte of assembly has been hand-crafted." I, too, look in awe at what was achieved with such things as https://github.com/chrislgarry/Apollo-11/tree/master/Luminar... . But that software, per https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw..., took 1400 person-years of work.

We have to compare apples to apples - the abstractions we have today would not prevent such a piece of software from being built, and indeed would allow us to build that exact software, even bit-for-bit the same, much more easily due to abstractions on our tooling itself. We have not departed a world where, given a nation-state budget, one could pay for 1400 person-years of work and create the AGC (though one might make arguments about the distraction levels of modern society, but that's a different thing entirely).

But we also exist in a world where I can build and ship a cross-platform video chat application in an afternoon (well, not counting app store approvals) and be reasonably confident that my app will be compatible with, and secure on, practically any computer or mobile device sold in the past half decade, regardless of how many other apps may have been installed on each device. I'd venture to say that Apollo engineers would, and do, find this aspect of our world fascinating, too.

Thankfully it was eventually migrated to GitHub