I actually don't consider Mu to be a language. (I'm the author.) It's a low-level starting point to explore ways to make the standard OS primitives more testable. I don't need it to look nice. Higher level languages can come later, once the foundations are in place.

I actually am growing increasingly suspicious of all our navel-gazing about syntax. We spend all our time in places like HN thinking about how to make small screenfuls of code look nice, but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.

Perhaps one way to think about it is that syntax helps insiders keep a codebase in their head. I'm more concerned with ways to help more outsiders import a codebase in the first place. Because people leave and move on, and it's very hard for software projects today to improve once their original authors move on. More on this: http://akkartik.name/post/readable-bad

(I'm susceptible to carpal tunnel, but it hasn't become a bigger issue. I take wrist breaks.)

[1] I can even imagine doing the translation in machine code, so that Mu then becomes self-hosting without needing any of the current stack. I might go down that road..

This. The pain point that mu addresses is huge. I haven't really looked at the project in much depth yet, or played around with it, but I love that you are tackling this issue. I have spent way too much time wandering around a big code base trying to build mental models of what's going on, and thinking to myself the entire time "there's got to be a better way."

You've effectively created a sort of portable assembly language, but it's more verbose than usual assembly language ("sub eax, 3").

but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.

I think the root of the problem is that software is being written to be more complex than it could/should be, so the solution is to encourage reducing complexity.

Exactly. The verbosity is mostly because of my teaching project. I think teaching assembly can be just as ergonomic as teaching a high-level language. Indeed, most of us from a generation ago learned programming using assembly. It just needs to get a little more ergonomic.

the solution is to encourage reducing complexity.

Yup. The problem is that human beings have a _terrible_ track record at managing complexity. It's not just every software project ever; think about the creep of bureaucracy in ancient China, or the creep of legislation in ancient Rome. Everytime we've created a repository of rules it's gotten complex (and then gamed by smart operators). I think the problem is that it's very hard to justify removing a rule, so such repositories grow monotonically. The only way to periodically prune unnecessary rules is to first track why you created them in the first place (https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence). Hence: tests! I think they are the great advance bequeathed to the human race by software. And they're far more broadly applicable outside software -- though I have no idea how to do this applying. I wrote up some speculative ideas about it at http://www.ribbonfarm.com/2014/04/09/the-legibility-tradeoff a couple of years ago, but that piece isn't very clear.

    substract a 3

    (- a 3)

Programming languages (at least the not-so-academic kind) need to mesh with the problem-spaces being solved, and there are definitely some contexts where most of the work is encoding and applying arithmetic rules.

Anything more than that is for wimps. Brain is the only language I ever program in.