really cool! what runtime do you use in the browser? a js implementation?

SqueakJS VM (https://squeak.js.org). It can run regular Smalltalk images (from Pharo/Squeak/Cuis) inside the browser. It does actually run a graphical interface using BitBlt on a canvas. I like to use HTML/CSS and therefore run a 'headless' variant of SqueakJS. I implemented a plugin which does the DOM manipulation. All code (outside that plugin) is developed in a regular Smalltalk environment and the compiled bytecode (CompiledMethod in Smalltalk) is sent to the browser through WebSockets. Clients can send events (aka Announcements) back to the server. The Smalltalk image in the browser is around 200Kb. This includes code to communicate, but not the UI classes. These are loaded on application startup (with every app needing its own classes) and can be done at runtime dynamically. Only load what is necessary.

Nice. What's your goal for this project? Planning to build a site/app entirely in Smalltalk? Just hacking for fun?

I'm trying to build a platform for kids to learn to program, for fun and to learn stuff. Influenced by Alan's DynaBook and Papert's ideas. Some info is here https://github.com/ErikOnBike/CodeParadise/blob/master/introduction.md

"Oh, you're still here?"

Kartik, I am extremely here.

What's the thinking behind only having hex numbers? That 0x5f5e100 might as well be a roman numeral, compared to the adjacent 100 ms comment.

yeah, i’m never going to stop following this project

Hex started out as just a temporary thing, but changing it now creates cascading consequences.

• It's weird to support it in Mu but not SubX. 10 may mean different numbers in one file vs another.
• Supporting it in SubX requires writing more SubX without syntax sugar. Including improving error messages in some situations.
• Supporting it in SubX requires thinking about all the 2-digit opcodes in SubX that I've been writing in hex because that's how the Intel manual represents them.

But yeah, it is a gotcha that 10 means 16. There's a reason why I always prefix numbers with 0x unless they're a single digit. I might revisit this. A PR would certainly put me over the edge..

is there a "layer" where you plan to drop specifying the registers?

do you have a plan to support other CPU architectures?

The Mu stack minimizes notations, but my plan is to have one more (called 'level 3' in http://akkartik.name/post/mu-2019-1). It's still very much vaporware. The hazy plan is some combination of shell (http://www.oilshell.org/blog/2017/02/05.html), awk (http://www.oilshell.org/blog/2016/11/13.html) and lisp (http://paulgraham.com/bel.html). But it'll stay interpreted so the implementation is easy to understand. To do anything that requires performance I expect people to write small pieces in the existing level 2 (with registers) that can then be glued together using level 3.

I'm not attached to any particular syntax for level 3, I just don't want separate languages for commandline vs scripts. And I don't want the commandline to accrete features without a coherent design the way shells historically did. In the fullness of time I fully expect a MuPy fork, a MuSmalltalk fork, and so on. I'd love to contribute to them if someone else starts them.

CPU architectures similarly will need their own fork. From http://akkartik.name/akkartik-convivial-20200607.pdf (section 2.1):

Portability is explicitly a non-goal. Portability guarantees require extra effort to maintain, and can be particularly challenging for newcomers who may not be inclined to ensure their changes work on platforms they don't regularly run. Rather than attempt to fight a losing battle, we retreat from it entirely. That doesn't mean it's somebody else's problem. I'm very interested in contributing to a RISC-V fork or ARM fork (which has been increasingly on my mind). But it's unlikely to be a priority in 2020 at least.

how much do you envision those forks sharing? or once forked they have to be kept in sync "manually"

at some point in the abstractions (I know you don't like that word :P) do you think some upper layer can ignore which of the forks is below?

I hope we can come up with tools to reduce/automate the manual burden of merging, particularly if forks have good tests. But I don't plan to mandate some 'standard' that all forks have to follow below some level. I think that gets us to the same situation as today, with creeping complexity. Anybody can do what they want within their fork, and the goal is to make it easy for forks to stay internally consistent and comprehensible. Going between forks is important but secondary.

The point of the project is to teach people knowledge from the 'ground up' right? I guess adding abstractions moves further away from that goal? Nice video, as always 🙂

Next step, a re-implementation of ncurses 😛

I find your choice to stay with hex and the choice to maintain the numerical op codes instead of mnemonics very interesting. I understand why you made those decisions, but it does seem intuitively "weird" to me.

Is it just because it's foreign to me and different from the status quo, or do those choices fundamentally make the language more or less clear in some way?

You already make a distinction between SubX with syntax sugar and SubX without syntax sugar. Is it worth it to add another layer of syntax sugar for translating bases (or translating mnemonics)?

I've been thinking about your mnemonics debate. IIUC, You are worried about ambiguity, but if it's a "separate pass" it could be easily user modifiable, allowing the user to choose names that are less ambiguous to them. You could have "syntax skins".

More layers of syntax sugar arguably goes against your principle, "It uses as few notations (languages, syntaxes, intermediate representations) as possible." But it might help with the principle of "It focuses on encoding intention". Or at least encoding understanding. I'm not sure. I very easily fall into the trap of assuming "more productive" is equivalent to "better understanding".

Funny story on ncurses: I started out with a Lisp prototype of Mu back in 2015 that depended on a wrapper around ncurses. Since then I've gradually moved down the stack to: * a C program calling ncurses * a C program calling termbox, which is a simpler replacement for ncurses * forking termbox to rip out stuff I didn't use, gradually understanding its internals, still sending patches upstream (http://arclanguage.org/item?id=20221) * dropping my fork of termbox and making syscalls directly. What was interesting here was realizing how few syscalls I need. ncurses actually doesn't do much for many features we associate with it, just prints bytes to stdout.

Bottomline: ncurses is quite old, and a lot of the stuff it does was valuable in a world where everyone had thin terminals and very slow internet connections to their servers. It manages an in-memory copy of the screen just so it can compute the minimum it needs to change and send only those bytes over the wire to the server. But for most of us it now runs locally and there's nothing to send. It's all complexity we pay for but don't need. Another source of complexity is support for a huge database of ancient terminal types, none of which anyone uses anymore.

So check out http://akkartik.github.io/mu/html/103screen.subx.html. It's been quite a journey to boil ncurses down to ~300 static instructions of machine code. And there's exactly one ioctl() in there, see if you can spot what it's needed for.

Ray Imber "Mnemonics debate" sounds like you've been reading more deeply here than most people I talk to. Can you point me at any links to stuff you've read on my site or repo, just so I can respond at the best level for you? Or let me know if you're just going by the paper, and I'll respond.

Kartik Agaram Your journey with ncurses and termbox is fascinating. Thanks for sharing. I've tried both for some toy side projects, including dealing with bindings to other languages. TBH, even at the api leveI, I came to similar conclusions. They were big dependencies and I ended up having to manage most of my own state anyway. There was a point where I was looking into creating a terminal emulator, and I ran into the "huge database of terminal types" problem. There is an almost absurd backwards compatibility burden these things impose. It's such a weird artifact of history with seemingly little modern benefit.

This is a tangent, but there is a lot of hidden conservative corporate politics that keep that stuff alive. The recent news about Cobol programmers still being needed for maintenance should tell you that these old mainframes and their dumb terminals are still around, and have a surprisingly long shelf life.

Re: ioctl Damn screen size 😛 you could just force a fixed terminal size. It would be like programming a graphing calculator. It adds to the authenticity of the experience /sarcasm. (I'm full of terribly bad jokes. Ignore me and don't actually do this lol.)

Re: the "mnemonics debate" Your project has really caught my attention! I think it's a very cool idea. I've read two of your blog posts: http://akkartik.name/post/mu-2019-1 http://akkartik.name/post/mu-2019-2 and the github issue here: https://github.com/akkartik/mu/issues/39 I'm about a 1/3 through your paper. I'm slowly reading it in my free minutes through-out the day.

I knew it! You've already read almost anything I could say about mnemonics. The only argument left to mention, I think, is that ambiguity complicates error handling, and again this is error handling one must implement fairly close to the metal, in unsafe machine code.

https://www.laarc.io/item?id=1945

This, incidentally, is also why I try to minimize syntax sugar: any part of the pipeline that emits error messages can be confusing if the code it's referring to was generated by some syntax sugar it's oblivious to.

That said, syntax skins that don't persist in the source code could be interesting. None of this stuff is black and white. SubX does use syntax sugar, as you point out. We just have to take costs into account. I don't yet feel confident that I am estimating costs right in any of my design choices so far. That'll require a newcomer to actually spend time with Mu and tell me how easy it has been for them to learn/retain.

Fun tidbit, because it was mentioned in the laarc thread you reference, I first learned assembly with "the Art of Assembly" book and HLA. I have fond memories of it. That probably gives away some bias I have 😄

You have definitely made me question some assumptions I had about assembly language. I intuitively want mnemonics. I think your worry about making the user have to look up extra tables in their mind may not be as big of a problem as you think (especially if you provide good documentation). But you bring up some really good points about the implementation complexity, especially around error messages at this level.

If you do support mnemonics, also supporting a base 10 to base 16 translation seems like a natural next step. The two syntax sugars compliment each other.

There is probably still value in having a base 10 translation pass without a mnemonics pass, but maybe less so.

"That'll require a newcomer to actually spend time with Mu and tell me how easy it has been for them to learn/retain."

lol. I get the hint. Curiosity might get the better of me and convince me to pull the repo and play with Mu. But I make no promises 😏

The face behind the pizza! 😛

Really excited to see where you land on the 3d/rendering side. We want to do something similar, where having 2d and 3d in the same space isn't something special. Just plop something down in the workspace and go to town.

I'm also looking forward to seeing the 3D. I've already got 3D animated graphics, and I'm interested in ways to make the programming interface more visual (right now programs are plain text). Integrating 2D and 3D in the same UI is something I'm thinking about.

My plan is to have the programming model be 2D, but embedded in a 3D space. This allows for a few things I think I'll like, such as: • Depth (with DOF/volumetrics to limit visual noise/clutter) separates different working spaces akin to tabs in a text editor. Switch spaces by moving back and forth through Z. I don't plan for this to be truly spatial — rather, spaces can come and go as needed. • Splines can be used to show connections between spaces separated in Z. Splines, like spaces, will come and go as needed. My goal is that, even if points can be "teleported" or "jumped" without wires, there should be a way to visualize the movement using a transient wire. Nelson's "show connections" is a Hest doctrine.

Jeez, going super deep! I have a similar 2D /3D model in my project. One thing the watch out for is aligning 3D objects to a 2D coordinate space - Perspective cams can really make the alignment difficult to see, especially if the cam can't rotate around object and can only pan/zoom. I've stuck with ortho because of this. Looking forward to seeing what you build!

This evokes the most excellent research question, "What does productive programming look like in VR?" 😄

Ryan King — Great advice. On the one hand, I trust my instincts here, because I have a background in 3d animation. On the other hand, that means I've had more practice comprehending 3d spaces than most people. So this idea will either be something I can strike a good balance on, or something I need to toss out and take a different direction. One way to find out :)

Ray Imber — For my money, it certainly doesn't look like all the VR coding environments I've seen which just.. put your text code in a floating rectangle. I'd think it looks more like Gray Crawford's work.

Also reminds me of the Zoomable GUI stuff: https://ieeexplore.ieee.org/document/1316870 https://blog.codinghorror.com/zoomable-interfaces/

Yes! I'm building Hest initially just for my teammates, who make these zoomable interactive industrial simulations. So the design of Hest is, in many ways, an outgrowth of our design work on these simulations.

on the off chance you haven’t checked it out, 3blue1brown has a great series on linear algebra that i’ve been going through: https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab

in the middle of it i realized that i could probably de-abstract a lot of it into examples using pictures of dogs... so that’s one of the newer projects i’m working on

Grant's video on the determinant was quite helpful to me.

https://www.amazon.com/gp/product/0128006455/ref=as_li_tl?ie=UTF8&tag=pharr-20&camp=1789&creative=9325&linkCode=as2&creativeASIN=0128006455&linkId=8d99f0006f611ac309e1c72906f78e17

While we are talking graphics books, I can't recommend 'Physically Based Rendering' highly enough. Not just for its excellent coverage of all things rendering, but also for being the best Literate Programming book you've ever seen. Oh, and they won an Oscar for it 😉

If you want to learn how deep the graphics/rendering rabbit hole goes, this is the book...

I'm not familiar with this book (though I am quite familiar with the results of PBR, less so the techniques behind it). Thanks!

Apparently the whole book is free online: http://www.pbr-book.org

Impressive that it is free; however I'd still buy it, since I regard it as the best tech book ever written - and I have purchased each new edition. The fact that you can 'compile' the text of the book into a production-quality rendering engine is astonishing.

Even without sound, that was captivating and super cool. Well done!

So, this is an old prototype. Is this the project you're going to be working on full time now? Or are you starting something new from scratch that takes this as one of its inspiration?

i like the visual design of this a lot!

An example program even a text-mode environment could create! This could be the drosophila of FoC demos.

Ivan Reese thanks! 🙂 And I will polish a bit this prototype to fix some glitches and try to explore its possibilities as far as I can, but it will stay as a prototype. In part because the code base is very old (I have used some pre-standard Web Components). So you are right: I am starting something new from scratch and also from Scratch (bad pun intended, sorry 😄) that will use the good parts of zed (I will then have to carefully choose what to keep).

Speaking as someone who finds PureData difficult to use (it really sucks at High DPI, and doesn't feel intuitive to me at all), this is an exciting looking project 🙂

I also enjoyed that. 🙂 Can one zoom in and out from the virtual canvas in addition to being able to scroll around?

There is no built in zoom in/out, for now I use the browser zoom feature which helps. Actually I thought to do a zoom out at the end of the video (but forgot it, gasp) to show all the code in the canvas. I find it very intuitive to navigate the code from a far view, you can spot relatively well where is the code you want to focus. So whatever I will build, there will be this kind of zoom/navigate in the canvas.

Ok, here a screenshot of the zoom out of the canvas from the video:

Audio sounds good to me.

Also — I love that this was a tiny update. I think this is perfect for this channel. Nobody should feel pressured to have to show a list of new features or some sort of massive breakthrough. It should suffice to say "this is what my project looks like today" or "I've just been thinking about buttons."

Also also — love to hear that you're working with Daniel Garcia! Hopefully we'll see more folks in the community joining forces.