Mu's code looks quite alien, requiring editors to be specially configured to colorize it in a sane manner. So this page provides links to the source files showing how it currently looks in my custom setup.

Whetting your appetite: some example programs.

• x.mu: a simple program to add two numbers together. Shows that at bottom Mu is a simple VM bytecode designed to convert directly to machine code.
• factorial.mu: everyone's favorite example, showing how Mu supports conditionals and loops without any special syntax, using the special labels '{' and '}'.
• tangle.mu: another (contrived) version of factorial showing Mu's ability to 'tangle' code from multiple places into a single function or 'recipe'.
• counters.mu: lexical scope
• simple examples showing off support for concurrency: fork.mu, channel.mu
• simple examples showing off hardware control: display.mu, console.mu.
• screen.mu: example program showing print primitives that inject a screen dependency which can be faked for testing.
• static_dispatch.mu: example program showing mu's ability to define recipes with headers, and allow recipes with the same name but different headers to coexist.
• chessboard.mu: a little program for 2 people to play chess, with thorough tests of its behavior including both screen and keyboard handling.

Part I: basic infrastructure

000organization.cc: the basic skeleton program. Compiles and runs but doesn't do much. Later layers hook into this skeleton to add functionality. Mu's guarantee: you can load features up until any layer, and it will compile and pass all tests until that point. More details →
001help.cc: just a simple test layer to show how to hook into the skeleton. Also summarizes how to invoke Mu, behaviors that later layers will be providing.
002test.cc: Mu's minimalist test harness, relying on a couple of one-liners in the makefile to autogenerate lists of tests to run.
003trace.cc: support for logging facts about our program, and for checking the facts logged in tests. (tests for the test harness)

Part II: the Mu virtual machine, designed to compile easily to machine language.

010vm.cc: core data structures: recipes (functions), instructions and reagents (operands).
011load.cc: the textual representation of recipes and how it's turned into the data structures.
012transform.cc: after Mu programs are loaded but before they are run they can be transformed in an extensible manner akin to lisp macros. Think of this as the core of Mu's ‘compiler’ for providing high-level features atop the core.
013update_operation.cc: our first transform: check for unknown recipes before the program runs.
014literal_string.cc: extend the loader to support literal strings in various instructions.
015literal_noninteger.cc: extend the loader to support non-integer numbers.
020run.cc: executing Mu recipes by executing the list of instructions they contain. Future layers will define more primitive operations that can be used in instructions.
021check_instruction.cc: harness for adding per-primitive checks to run before running a program.
Various primitive operations: on numbers, booleans, for control flow, and comparing values.
029tools.cc: various primitive operations to help with testing and debugging.

030container.cc: Mu supports compound types akin to records, structs or classes.
031address.cc: adding and removing layers of indirection to Mu data.
032array.cc: all Mu data structures are bounds-checked.
033exclusive_container.cc: tagged unions or sum types.
034call.cc: calls to recipes look just like primitive operations.
035call_ingredient.cc: how recipes pass arguments or 'ingredients' without introducing any syntax and breaking the metaphor of recipes as lists of instructions.
036call_reply.cc: recipes can return arbitrary numbers of values to their callers.
037recipe.cc: passing recipes around as first-class values in higher-order functions.
038scheduler.cc: running multiple recipes concurrently using routines that might execute in interleaved fashion.
039wait.cc: primitives for synchronization between routines.

Part III: transforms to provide 80% of the benefits of high-level languages.
040brace.cc and 041jump_target.cc: how Mu provides structured goto-less programming without introducing the syntax of conditionals and loops other languages require.
042name.cc: how Mu transforms variable names to raw memory addresses.
043new.cc: rudimentary memory allocator that is aware of all global types in any Mu program.
044space.cc: how variables in different routines are isolated from each other using spaces. Mu ‘local variables’ are allocated on the heap.
045space_surround.cc: Chaining spaces together to accomodate variables with varying lifetimes and ownership properties.
046closure_name.cc: how spaces can implement lexical scope.
047global.cc: support for 'global' variables that are always available inside a single routine. Mu has no variables that are available transparently across routines.
048check_type_by_name.cc: a simple transform to deduce missing types in instructions on the basis of previous instructions in the same recipe.
050scenario.cc: Mu's first syntax — not for code but for tests. (example)
052tangle.cc: support for layers in Mu programs. They've been so good to us.
Support for shape-shifting or generic data structures that can contain type ingredients: 054dilated_reagent.cc, a new syntax for allowing whitespace in types; 055parse_tree.cc, a new syntax for representing complex types as trees using whitespace and parentheses (s-expressions); 056recipe_header.cc, a new syntax for introducing ingredients and products with the name of a reagent; 057static_dispatch.cc, allowing multiple variants of a recipe to coexist with support for different headers; 058shape_shifting_container.cc, a new syntax for wildcard type ingredients in containers; and finally 059shape_shifting_recipe.cc, support for type ingredients in recipes. Everytime you call a shape-shifting recipe with a new set of types for its type ingredients, it creates a new variant of the recipe for you matching those types.

998check_type_pointers.cc.html: After all our messing about with types, a final pass to make sure we didn't introduce any invalid types.
999spaces.cc.html: Maps summarizing various address spaces in the core, and the conventions that regulate their use in previous layers. various address spaces in the core, and the conventions that regulate their use in previous layers.

Part IV: beginnings of a standard library

070string.mu: strings in Mu are bounds-checked rather than null-terminated. They're also unicode-aware (code points only; no control characters, no combining characters, no normalization).
071channel.mu: channels are Mu's only synchronization primitive, queues that can cause the routine reading or writing from them to stall without taking up CPU resources.
072array.mu
073list.mu: linked lists where each node points to the next, permitting fast insertion/deletion but slow for search.
074random.cc
075duplex_list.mu: doubly linked lists that can be traversed both forwards and back.
076stream.mu: data structure to efficiently append strings.

Part V: Nascent tools for browsing Mu codebases, and for teaching programming to non-programmers by getting them hooked on the value of tests. The eventual goal is an environment that watches programmers as they manually test their code, and turns these interactive sessions into reproducible test scenarios.

080display.cc: primitives for using the keyboard and screen.
081print.mu: helpers that can swap the real screen with fake ones for testing.
082scenario_screen.cc: writing tests that check what is printed to screen. (examples)
084console.mu: helpers that can swap the real keyboard and mouse with fake ones for testing.
085scenario_console.cc: writing tests for keyboard and mouse using the fakes. (examples)
090trace_browser.cc: a zoomable UI for inspecting traces generated by Mu programs. Allows both scanning a high-level view and drilling down into selective details.
091run_interactive.cc: hacky primitives for running Mu code in the programming environment below.
092persist.cc: more hacky primitives for supporting saving/restoring sessions in the Mu programming environment.

Finally, the programming environment, the first major application in its own directory. Stop loading after each of these layers to get a working version with just fewer features. The readme for the app contains instructions for running it.

edit/001-editor.mu: data structures for a simple text editor widget. Load just this layer to see just the rendering and line-wrapping at work.
edit/002-typing.mu: support for moving the cursor anywhere with the mouse and typing text in there.
edit/003-shortcuts.mu: support for various keyboard shortcuts for manipulating text you've typed in.
edit/004-programming-environment.mu: combining two text editor widgets, one on the left, one on the right.
edit/005-sandbox.mu: support for running mu code in the right-hand widget using code from the left, and displaying results in a sandbox below on the right. You can have multiple sandboxes, and hit F4 to rerun them all at anytime with the latest version of the code on the left side.
edit/006-sandbox-edit.mu: click on the title bar of each sandbox to pop it back into the sandbox editor and make changes to it.
edit/007-sandbox-delete.mu: click on the 'x' in the title bar of a sandbox to delete it.
edit/008-sandbox-test.mu: click on the results of a sandbox to turn them green and save the output as golden/expected. Any future changes to the output will then be flagged in red.
edit/009-sandbox-trace.mu: click on code in a sandbox to open up a drawer containing its trace. The trace can be added to using the stash command.
edit/010-warnings.mu: support for rendering warnings on both the left and in each sandbox.
edit/011-editor-undo.mu: support for undo in the editor widget.

The zen of mu:

• traces, not interfaces
• be rewrite-friendly, not backwards-compatible
• be easy to port rather than portable
• global structure matters more than local hygiene

Mu's vision of utopia:

• Run your devices in 1/1000th the code.
• 1000x more forks for open source projects.
• Make simple changes to any project in an afternoon, no matter how large it is.
• Projects don't slow down with age, they continue to evolve just as fast as when they were first started.
• All software rewards curiosity, allowing anyone to query its design decisions, gradually learn how to tweak it, try out increasingly radical redesign ideas in a sandbox. People learn programming as an imperceptible side effect of tinkering with the projects they care about.
• Habitable digital environments.
• A literate digital society with widespread skills for comprehending large-scale software structure and comparing-and-contrasting similar solutions. (I don't think anybody is literate by this definition today. All we can do easily is read our own programs that we wrote recently.)