https://futureofcoding.org/ logo
Join Slack
Powered by
<@UCUSW7WVD> in his Convivial Computing Salon Q&am...
# thinking-together
a
@Kartik Agaram in his Convivial Computing Salon Q&A: Mu has a "*barbarian ethos*" in the sense that barbarians trade with nearby settlements for technology they don't have, similar to how Mu minimizes dependencies, but he's creating it on a Mac, in a text editor, etc.
i
That rocks. (Sad I missed the live stream, but I only realized it was happening 15 minutes after it started. I hope there will be videos soon)
👍 1
k
Here are the slides. I'll also paste the links I posted into the conference Slack: Paper: http://akkartik.name/akkartik-convivial-20200315.pdf Repo: https://github.com/akkartik/mu Compiler summary: http://akkartik.github.io/mu/html/mu_instructions.html Me: http://akkartik.name You've seen them all, but it may be helpful to lay them out in one place.
KartikAgaram-Convivial-Slides.pdf
c
Why is it necessary to have SubX and Mu as different languages, can't you just have a restriction of Mu with the same syntax?
I understand the benefit in terms of making the implementation of the compiler/translator easier, but I don't see this as being a part of the system that users will really care about understanding
k
Since Mu has to be safe, I have to disallow a lot of stuff that is allowed in SubX. Like goto 🙂
c
What is the advantage of this representation; 
8b/copy 0/mod/indirect 1/rm32/ecx 8/disp8 0/r32/eax
why not 
registers['eax'] = memory[registers['ecx']]
k
Relative to the binary: 1. It's text. 2. It raises errors immediately and with error messages rather than just 
segmentation fault
. Relative to conventional syntax: 1. It's easy to translate, and that means less stuff for you to understand if/when you end up wanting to understand the internals. Which is the whole point of Mu, to not leave you without a paddle.
c
I used Python but hopefully you get the idea. I'm trying to draw a distinction between the physical fact that "registers" is a 8-big dictionary with certain keys, and a particular way of writing information
One is a compromise we have to make to the machine, the other one I don't see why you "give way" so much to the binary representation, which only the machine likes not humans
k
I'm not sure I'm quite following you. If you like I'd love to do a quick call sometime. I'm on vacation all this week and weekend, so more flexible than usual.
🏖️ 2
Mu's hypothesis is that trying to cater to humans (in the short term) has costs. So at lower levels it might reduce total cost to cater less to humans in the short term, and cater more to machines and to humans in the long term (by being easy to learn albeit with some initial hump). For example, this notation is trying to avoid creating a new standard. It's so close to x86 that you can use an existing standard. And I can implement it with just machine code too, and the implementation can be relatively ergonomic. Perhaps a Python-like syntax can be implemented in x86, but it feels like it would be larger and more complex.
c
I will compose my thoughts better then get back to you properly later in the weekend
❤️ 1
k
i
You should do a top-level post, Kartik!
p
oh, where was this announced?
k
Oh no, there was never an announcement in #CLYCGTCPL. It did get announced on #C5T9GPWFL: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1588578156478000 It also got broadcast on Twitter a bunch, and I mentioned it on my usual haunt: Lobste.rs (though I see I missed Mastodon)
p
Oh.
Open in Slack
PreviousNext
Powered by