ℙ𝕖𝕡 🙴 ℕ𝕠𝕞

18 Apr 2025

a better system

I have been learning a little about the Rust programming language which was developed at the Mozilla company and which is a newish and popular compiled language. It is considered good for “systems ” program and maybe could be simplistically summarized as a “memory safe” c/c++ . It does not use a garbage collector but instead has a strict compiler that makes sure that referenced variables are always valid. It appears to have lots of good libraries and api's and seems to compile and run fast, perhaps as fast or faster than [go].

What is more is has all the stuff that you would expect from a modern statically typed language: closures, anonymous functions, higher-order functions, recursion, methods, interfaces (which are called 'traits') and lots of other stuff which I probably don't understand properly. Its all wonderful, but ...

Learning this language does make me ponder some simple questions: How important are all these features? Which ones are really essential and which are more-or-less just 'syntactic sugar'? What features could we do without?

But let me be more concrete because that is how my brain works:

Rust code to count the number of hashes in some text

  let hashcount = text.chars().filter(|c| *c == '#').count();

Looking at the rust code above we can see all sorts of lovely syntactic pavlova:

We have some type inference with the “let hashcount = ...” where the compiler works out what type of type hashcount will be by resolving the expression on the right hand side.
Also, we have method calls with the dot notation with references automatically dereferenced (unlike c which makes you write “->” if text is a reference).
Then we have “method chaining” if that is the right term
And there is a higher order function “filter” which takes a function as an argument.
And the function argument “(|c| *c == '#')” is anonymous and includes various bits of shorthand syntax which I probably can't explain properly.

But we could also do all that as follows:

caveperson counting of hashing in some text


   let mut count = 0; 
   for c in text.chars() { 
     if c == '#' { count++; }
   }

Personally I prefer the code above which is very 1980's procedural “do this” and then do that". But the first code snippet is more interesting . Its all functional and object-oriented and modern. The problem is that interesting is not necessarily good in the world of programming and especially in the context of code maintenance.

On the other hand, I do greatly appreciate the “text.chars() ” phrase because rust is working out for me what is a “character ” and then handing me an iterator which is all very smooth. There is a caveat that Unicode doesn't believe in characters just grapheme clusters and code points and “text.chars()” gives me code points which doesn't seem as useful to me as a grapheme cluster. For example, what am I going to do with an isolated diacritic*?

Any way, what is the point of this blog post? I do have one, really. My point is that not all programming language features are equal or of equal importance. We need a way to manage complexity and to make code readable and maintainable but we don't need elegance. Elegance is interesting and maybe stops coders from getting bored, and maybe it gives them an endorphin rush when they reduce twenty lines of code to two.

So, the point of this post is very reductionist: we only need three things in a compiling system:

A good simple-to-implement virtual machine that will run on both Harvard and Von Neumann architecture which has at least one stack
A simple language to language map as a compiler (where the target language is the assembler language for the virtual machine)
A way to create named code units that can call each other and use a universal naming system.

The idea of the virtual machine is just to provide a stable target for the compiler and to avoid redundancy and obsolescence. The inclusion of a stack can be, and is, debated but since the stack makes implementing more complex language recognisers and translators (context-free and context-sensitive) much easier, then it seems like a good idea.

If we can define our compiler as a map between the valid 'words' in our source language to the valid 'words' in the virtual machine assembler language, then the language that we use or create to write programs becomes unimportant, as it probably should be.

The 3^rd idea is really quite banal and I find it baffling that nobody has bothered to include it in a computer language. It says simply that the system or compiler should always be able to locate (locally or remotely) whatever named code unit or 'atom' that the system uses, whether that be a function, class, class/method etc Named code units are essential because we need a way to read and test small chunks of code otherwise entropy and chaos takes over.

Anyway, I believe these three ideas contain the kernel of a system that can be radically simpler and therefore more robust than the systems that we currently have. I also believe that the ℙ𝕖𝕡 🙵 ℕ𝕠𝕞 system is a big step towards fulfilling the 2^nd requirement. That is: it is a step towards expressing a compiler as a map function (if that is not an oxymoron) from one language to another.