I hope I'm not bikeshedding if I recommend that you increase the overall text contrast of that page. Especially the red on black in the sample code and output image will be invisible to many people. And if you add white-space: pre to your textarea you'll ensure that lines won't wrap.

Thank you so much for the feedback @Fabian Iwand! I've deployed your suggestions

Much better, thanks! 😅

Don't the long multi-line and blocks hinder read-aloud-ability? I can imagine listening on the phone and having to periodically ask, "how many quotes is that?"

I didn't design github.com/akkartik/mu to be read aloud, but now that I think about it, it feels a bit nicer to read aloud since statements really occupy a single line and are therefore constrained to be short. The cost: lots more temporary variable names, so you'd have to ensure they're don't sound too similar to each other.

Have you considered creating just a style of JavaScript that is convenient to read aloud?

I'm curious if you've given thought to the treatment of camelCase words. For example, in createElement do you consider the function to be known to the receiving party so that any ambiguity would be acceptable? Or did you use a specific diction in the past?

Dragon NS for example seems to require post editing commands, which doesn't seem like a reasonable workaround for natural language.

(Perhaps all special characters should be aliased to onomatopoeias like "Pow" and "Whoosh" ... 😬)

@Fabian Iwand I'd almost rather enforce everything be lowercase as far as language keywords go (but symbol names and strings should be able to contain any character)

Kartik Agaram thanks for calling that out - note that putting many lines on one line with ' is optional, so the following are identical:

at foo ' add 40 ' log

and

at foo

add 40

log

so you can trade vertical and horizontal space when writing the language

I will check out Mu - about to catch a ✈

The quotes as the start of a block are not optional, however

The quotes as semicolons seem to hurt readoutability - you would want that boundary to either be uniform, saying "ret" each time eg, or best yet unnecessary by making statements expressions that are bounded in arity. I keep getting confused by the structure of it as the semantics of the at/call/push paradigm are nearly inside out from the standard ALGOL style procedure call. The simplicity of your approach is very refreshing compared to JS; however, I only wish it could sit under it rather than above it.

Ultimately, I think the most "readable" languages look like en.wikipedia.org/wiki/HyperTalk or Ruby - quite verbose, though with linguistic affordances carrying a lot of context. We have communication hard-wired into our brains, but inventing languages that take advantage of this is more of an art than a science. The more whoever is learning it knows a different type of language, the more the impedance mismatches between them will trip them up compared to an absolute beginner.

Have you read the papers around Applescript? It might be interesting to see how they approached some very similar design constraints.

if only serialization were one of the hard parts 😕

@Alex Cruise Agreed its not the hard part but I feel leaving it to the end breeds fragmentation and becomes an obstacle to interoperability

The main gain of dbuf over protobuf is self-describing, are you aware of gRPC reflection? github.com/grpc/grpc/blob/master/doc/server-reflection.md (protobuffer can do it too but its not well documented)

I use msgpack.org at my day job (it was originally created by one of our founders), it also has that property 🙂

Tom Larkworthy That’s a nice help tool but my goal is to go much further. Instead of having dedicated endpoints that each accept a specific data layout, have a server that could natively understand requests of different shapes.

@Alex Cruise Since you brought up out of the tar pit in a different channel, that is where I’m going with this. Using the same type system for the wire, relations, indexes, cached intermediate values and having it all be more runtime adaptive.

You might be interested in the various WebAssembly efforts to standardize struct/reference/complex types

I have followed the progress of the GC proposal. I think its going to have limited usefulness as it tries to cater to a wide variety of type systems

My snarky impression is they’re reinventing IDL and large parts of the JVM but apparently there are enough people involved who have been around awhile that they have a decent shot at success 😕

Yeah there's plenty of talent involved. I guess part of what makes any big system is just belief

It's a good update (looks like you've accomplished a lot ). You probably know this but parts would be difficult to understand for someone new to the project, I would probably just chuck a link to the Welcome page at the top if you are planning to send it out to a wider audience.

Thanks that's a great idea!

I really think state machines are one of the major missing abstractions in the industry… So far every attempt I’ve seen to make them generic has a pretty thin and/or tortured encoding

they'd certainly be easier to prove correct and it'd require a big shift in thinking for a business process to translate to state machines. docker solved half of the problem but it solved the wrong half

I wouldn’t call it “wrong”, just extremely Necessary But Not Sufficient. 😉

haha, "wrong" in a sense that it doesn't solve a problem it wasn't designed to solve - it does certainly have its place