1. 36

Submitted in response to https://lobste.rs/s/hvf51k/are_we_simple_yet which assumes a newer, simpler stack has to involve C.

  1.  

  2. 4

    As the OP of that thread and someone genuinely interested in a truly simple, minimal operating system, I say bravo! Your work is incredible. I firmly believe that implementation beats theory any and every day of the week.

    How’s that Level 3 programming language coming along? Got any sneak peeks you can share?

    1. 6

      Not yet, I’m still building Level 2. (OP is just an outline of a plan.) Level 3 is just vaporware so far. Thank you, and to all the other commenters!

    2. 4

      Super interesting, thanks for exploring this space with a really fresh look! I think this resolves most of my desires about SubX; I didn’t realize Mu was going to be at that level, which I feel is somewhere between C and Asm in many aspects (but probably above C in others, if you manage to pull out the safety stuff).

      I only skimmed the article, not enough time for a full read now unfortunately. Some quick personal thoughts from that:

      • the a, b <- foo x, y syntax kinda tempts me to think that extending it to work in a “piping” manner could be interesting — i.e. stuff like: x <- add y <- add z or: myarray <- map func1 <- filter func2; though I guess with current semantics of the left arrow it would be limited to funcs that have same return type as param;
      • I really hope something similar could be built for RISCV in future. Maybe then even a cross-platform language could be designed based on lessons learnt on the two cases.

      Thanks again!

      1. 4

        I really admire your work, @akkartik! I feel there is some conceptual overlap between mu and urbit (reboot of computing from ground-up, on top of purposely constrained primitives), but mu seems to be positioned firmly opposite urbit on the legibility & accessibility axis. I’m keeping my fingers crossed for its success.

        1. 3

          Cool! This is the kind of language I hope will be explored more thoroughly in the future. I have an idea for a similar language, built mostly on top of the processor’s instruction set but with a strong type system to support it and features (language constructs, linear (ordered?) types, …) that allow mapping high-level concepts to very low-level code. But it’s going to take a while.

          1. 3

            Way back in the day, I played around with a language with a similar goal called “TACKLE”. Unlike the Mu language here that looks a lot like C, TACKLE was a weird combination of NASM syntax & QBasic. Because I was doing real mode development & most of my experience was in QBasic with a vague familiarity with real mode x86 assembly, this combination really worked for me & I did cool stuff in it.

            It’s sort of unusual to see stuff pitched as explicitly low-level “system languages”. C is used for all sorts of stuff. I think aside from this and TACKLE, the only one I’m aware of is C– (and I don’t even know what C– looks like – just the name).

            Since the machines you’re targeting will need to be built from scrap, are you planning to keep ASCII (with its space half wasted by no-longer-necessary control characters)? Will you remap the graphical characters for high and low range to be something useful as part of the languages you’re building for this?

            1. 6

              Nope, no new encoding. I’m already boiling half the ocean, I’d like to leave the other half to someone else :)

              I do want to add utf-8 support at some point, but yes so far it’s just ASCII.

              I was using “system language” as a sort of shorthand. It’s like this pseudo-category of languages that contains just C. The major characteristic of C that I’m trying to replicate is that it doesn’t use other (“higher level”) languages. Other languages use it in their implementations.

            2. 3

              I keep getting a little arrow emoji in reading your code, is some special unicode character missing from my computer, or is it supposed to be a little arrow?

              1. 3

                Oh sorry I forgot to post my more useful feedback.

                Really cool post, and it will be interesting to see where Mu goes after you’ve hacked on it to a useable state (I would totally play with it). I don’t think the future needs C either, but it’s up to programmers with edge to take the approach of cutting it out of the machine code generation process to make it irrelevant.

                1. 1

                  Sorry, I’m cheating there. The repo just uses <-.

                2. 2

                  Thank you for sharing this again; I couldn’t remember the name.

                  Distinguishing input and outputs of an opcode might be done with a merely decorative sigil, just like the opcode names.

                  I allocate local variables on the stack but forget to clean them up before returning.

                  You don’t need this problem. If none of your functions are reentrant then you can use static local variables instead. Reentrancy was not the default in the ancient tongues.

                  I have what is probably a simple plan for memory safety: divide the program into an upper imperative layer and a lower functional layer. Functions in the functional layer can only return copies. In the imperative layer everything is reference-counted (Rc<RefCell<_>>). With additional complication you could allow the functional layer to modify owned values & mutable references. (This model is unfortunately incompatible with OOP.)

                  I’ve been finding good error messages to be more valuable than syntactic conveniences.

                  Perhaps “design by error quality” should be a thing.

                  1. 3

                    Thank you, yes “design by error quality” feels like a movement I can get behind.

                    But I’m still too much of a lisper to give up recursive functions :)