A well crafted demo, nice! How do you see it "deployed"? Would it be some kind of IDE extension / Web app / Desktop app / Notebook (a'la jupyter)? Would it interact with with other existing languages or be its own thing?

Kartik Agaram take a look at that! looks cool

Thanks @Marek Rogalski 🙂 Atm I don't have a reason to close any of those doors yet, e.g. I could see it being general purpose but indeed also like the notebook use case. The deployment I see in my inner eye the most, for my purposes, would look more like a whole desktop system +/ CL(U)I, where I'd e.g. run ls to pop up a Explorer/Finder-like UI where I visually filter/select some files and then write more commands that work with the given selection.

Words probably don't communicate that vision quite as much as I see it, I hope I'll have another demo to show for that in the future!

I guess I know what you mean - a visual shell. At least that's how it sounds to me. Anyway can't wait for the next update!

Right now I’ve got

• A stack-based VM that reads in bespoke ASM and can execute it
• A compiler that takes in scheme forms and outputs ASM for my VM
• Some simple bash scripts to route stuff round the various bits

The VM and the compiler are totally implemented in awk. Doing stuff in memory with awk is painful, so I persist stateful stuff, like the environment, and the code to be executed, etc. on disk in tmp text files that the compiler manages.

• What hoops are you jumping through to run Acme?
• Have you done a lot of stuff outside of html+js? I've only seen f.awk and this. Cool!

• acme is a breeze to run with plan9port
• I guess I’m technically a full stack dev? I’ve worked on front end web, backend (java and ruby and php), and both iOS and android…and then just enjoy playing around with a bunch of languages

JS is defo where I’m most cozy, though

Kartik Agaram hit me up if you have questions about plan9port. It’s fun.

It is incredibly impractical, but I’m implementing scheme using awk.

I love the spirit.

Most of your examples for "misaligned AI" are actually examples of misaligned human users of AI. People who either pursue goals that are bad for the rest of us, or who let bad things happen through negligence.

I'd say our problem is not "An AI with the strategic brilliance of Sun Tzu, the patience of a tortoise, and the moral compass of a drunk pirate", but rather "An AI with the strategic brilliance of Sun Tzu, and the patience of a tortoise, in the hands of a drunk pirate."

Thanks! It's of interest for at least one person here: me 😄

Readability, or maybe better explorability, is one of the main criteria for my current work. As is communicating intent. My context is quite different, so the approach of circuit diagrams is probably not for me, but the layering approach is probably quite universal.

Rete.js needs a feature for this. It allows you to group things, but not hide contents.

Layering and eliding requires a change to the implementation of connections. To do layering, connections need to be triples {direction, sender, receiver}, but, the usual implementation of connections is as doubles {sender, receiver}. This is trivial to implement, but requires a change in mindset. My guess is that thinking in terms of "infinite canvases" blinds one to seeing this minor extension to connections. [Likewise, the code to route messages needs to take direction into account, requiring 4 slightly different methods].

I don't know what direction means. Is the direction not from sender to receiver?

Direction is one of [down | across | up | through]. The common idea is to use only 'across' connections from sender to receiver. Adding 'down' and 'up' makes it possible to compose little networks inside of containers. The containers send their inputs 'down' to their children and get outputs from their children 'up' to their own output ports. The 4th direction 'through' rounds things out and lets you stub out functionality. In analogy, /bin/bash scripts do this kind of thing - they allow one to compose groupings of commands, where commands might be other bash scripts recursively. Same here. You track which way connections point, which lets you compose little networks recursively. [aside, tracking direction also provides a way to wrap "scope" around timing issues, but, that's another discussion].

Can you not derive the container's "ports" by whether the connections start or terminate outside the container? Or is the point that the architect gets to pick the interface of the container, too? Or is there some other reason the connection needs to be segmented at the container boundary?

The Architect builds completely stand-alone Parts. This means that it is impossible to see where external inputs come from or go to. You can't see the whole outside network because each Part is stand-alone and is not privy to information about how it will be used. Analogy: building circuits and buying ICs - the manufacturer gives you a spec sheet which says what the input and output interface is for each IC (it's "pins"), but, only the Architect determines how the IC will be used in a circuit - the manufacturer cannot predict how an IC will be used. Parts are little black boxes with input ports and output ports. Containers ("Choreographer Parts") compose little networks using child Parts. Parts inside a container might be code Parts ("Worker Parts") or might be other containers, there is no way to tell at Architecting time.

FP tries to accomplish something similar, but the building block of FP is the function, which effectively has 1 input port and effectively 0 output ports. The fact that functions can hard-wire blocking calls to other functions in their code complicates things. "Return signatures" syntactically look kinda like outputs, but really aren't outputs.

[I have to step away now, but, will resume in the morning.]

The first two sentences were all I needed, thanks.

Relevant — fantastic video essay about music notation: youtube.com/watch?v=Eq3bUFgEcb4

Basically teaching code + music can solve many problems wrt education.

The real controversial position would be math must die :P

musitude!

I do like to think that learning staff notation blocks you from thinking about music in other ways. I'm not going to risk it anyway

To be clear, "Notation must die" is the position Tantacrul is lambasting. He makes a pretty strong and entertaining case. :D I know just enough staff notation to kind of hate it, but haven't been able to come up with an actual improvement. There are quite a few constraints.

I'll just pull out one of the arguments he would probably make here: code as music notation fails at one of the most central uses of notation, namely performance by humans on ~actual~ analog instruments.

To be a bit pedantic: a computer is an actual instrument. But that's besides the point :)

Alright, you. 😂

Basically staff notation can be ported into an ascii DSL that can be played from Javascript (code) to trigger (MIDI) events.

Humans can obviously read the DSL, so in theory humans can use live coding to both practice and play it automatically or play it live or play analog.

The real challenge is standardization of tracker notation.

Flexibility of using code is losing many constraints and adding your own code. I'm confident that with a few iterations I can even get better swing patterns than DAWs and hardware with randomization for each drum tick.

Andrew F Yes I watched it and it's great! I think musitude is an excellent example of computer scientists trying to 'solve' pseudo-problems in other fields without understanding them

But I don't think the problem with staff notation is that it's difficult to read. It's that once you learn it, it makes it difficult to think about music in any other way. It's a standardising force that has wiped out a lot of musical practices.

I think there is a trap when making computer music systems to make awkward reinventions of staff notation though.

with the computer person obsession with lists of lists you end up with a very two dimensional view of staff notation and music in general. MIDI makes things worse by forcing everything into a piano-shaped box

An alternative starting point is Canntaireachd or Konnakol which are both very symbolic but are related through speech rather than notation, so a much better match for dynamic text

Yes of course.

Basically the idea is

Map each culture / instrument / genre to 1 DSL

drums -> en.wikipedia.org/wiki/Drum_tablature

guitar -> ultimate-guitar.com

irish folk -> en.wikipedia.org/wiki/ABC_notation

indian -> bol

western -> staff dsl

A programming environment like mine or any other basically just provides primitives and accurate timing. People can build their dsls, custom scales what not.

In case of highly improvisational stuff .... you just use random numbers but mention them clearly inside the code.

The musician can thus compose music, play it with samples or even read the DSL to play it with an orchestra.

I think tracker notation can act as a more universal DSL but that is best done after all other DSLs are done. Tracker music already convers most modern genres quite well.

I enjoyed the writing, but couldn't quite tell what was going on with the demo. Pressing keys didn't seem to add or remove any lines. It wasn't clear if the parallel horizontal line segments along the left were dynamically reflecting some state or just drawings on the wall. I couldn't reproduce the mouse drawings in the text with a for the previous click and b for the next click.

Keep going! This is interesting stuff.

I've tried that too, did change the color of lines, I figured that pressing some keys would do that. But didn't get what else to do.

Thanks for checking it out and your feedback!

I just uploaded a new version of the demo. You will have to clear the browser cache or use a private window to try it.

At the bottom you should see a number of example programs. Initially only the "mouse pointer" program is active. You can click on it's name to view the code and edit it. Any changes come into effect immediately (unless you have a syntax error). The idea is to gradually explore by enabling more and more of the example programs.

Some obscure commands:

• Talise(...) = tagged line segment = create a new tagged line segment
• q(the_query) = query the memory for the_query return a set of lines
• for _, line in ipairs(...) do = lua's weird way to iterate over sets
• q(the_query, "name for query", {R, G, B, A}, width) = same as q(...) but also render the lines in the given color, thickness (you can omit the name)

In the Agents tab you can add your own agents. They will persist in the browser cache! The examples will be reset with every refresh!

What to expect ...

this is what I see. How can I "run" some particular program?

Looks like you need to check the box to the left of any example, maybe. Sorry, I'm not able to try it just yet..

Yes, you have to tick the checkbox next to the name to enable/run it. the little arrow ">" to the very left allows you to single-step a program when it is paused.

Running a program means, its code is evaluated once for each frame.

Yep, I did that, but all other windows to wide. Maybe you can record some tiny gif?

oh! I see now, thanks

This should give an idea