What are you wanting to get out of the system?

I jump to thinking of syntactic solutions:

1. TXL.ca (strongly-typed, functional, parse-based)

2. Ohm-JS (a DSL for pattern-matching based on PEG principles)

And then, there’s

3. Lisp

Jimmy Miller thinking about evaluation as term rewriting and want to read an overview of concepts, sub areas, state of the art, where and how it's used

Paul Tarvydas I usually am interested in parsing stuff, but today it's not the case 😄

Ah, so interested in theory rather than a particular system. “Term Rewriting and All That” is the big canonical text. Very theory heavy.

kframework.org has quite a few publications on the latest work going on fmse.info.uaic.ro/publications

PLTRedex is also a pretty good resource if you are looking for a system to define languages in.

Check out Maude and Stratego and mathematica

Of course I have my own stuff I’ve written in this area (not research) so I can’t help but link to it

jimmyhmiller.github.io/meander-rewriting

jimmyhmiller.github.io/building-meander-in-meander

youtube.com/watch?v=9fhnJpCgtUw

I have friend steeped in this stuff. So if you want something more specific, let me know.

Great list of resources, thanks!

I have this one bookmarked:

strlen.com/files/lang/aardappel/thesis.pdf

There's also Pure (agraef.github.io/pure-lang), probably the closest to a general-purpose programming language based on term rewriting.

My own Leibniz project (science-in-the-digital-era.khinsen.net/#Leibniz) is based on term algebras and term rewriting as well. Its main inspiration is the OBJ family of algebraic specification languages, the latest of which (Maude) has already been mentioned. But the older papers on OBJ, mainly by Joseph Goguen and collaborators, are still worth reading.

A technique that looks like a nice complement to term rewriting is equality saturation (arxiv.org/abs/1012.1802). I am currently playing with it in Leibniz. Instead of reducing a term to a normal form, equality saturation compactly represents all equivalent terms, so that you can pick the one that is "best" for your purposes. Of course this works only for rewriting systems implementing equivalence transformations.

ODC in action:

This is kind of what Wrangler does vis.stanford.edu/wrangler

It's now a commercial company called Trifacta

Cool, thanks. Didn't know about them 🙂

It's definitely a very promising idea. Sketch-n-sketch is also similar. I'm not familiar enough with the research to know the right things to Google

I know the feeling 😄

Structured editing is one of the terms we seem to overlap a bit.

Love the hybrid approach. Start with the concrete, gradually abstract.

How similar/different is outcome-driven coding to programming by example? Certainly, normal people don't follow recipes, let alone write them. They have a sense for what a good outcome will be, and if it's not going that way they'll double check, tweak, and outright ignore the steps. Is improvisation what makes us human?

Good programmers, on the other hand, generally have two uncanny skills:

1) Can play computer, can model, often in their heads, what the steps will actually do rather than what they should do, it's like how an artist can imagine what a subject actually looks like rather than an simpler abstraction.

2) Can sense edge cases and complicating interactions. Yes, but when you combine this with that what happens?

Liveness helps to address (1). There are challenges certainly, but what do we do to help a person with (2)? You could say static checks try to address (2). I have a recent example in mind.

Trying RubyMine for fun, it flagged an obviously fine stretch of code:

@instance_variable = [an, array, of, things]

@instance_variable.map(&:whatever)

# ... later in the method ...

@instance_variable = nil

as potentially raising "NoMethodError: undefined method for nil:NilClass." Smart tool not so smart? Typing @instance_variable based on all its uses ignoring control flow? Replace @instance_variable with local_variable no error. Why the difference? Thread safety! Would be nice if the tool explained as much, but there you have it. (Of course, no sane person uses threads in Ruby, or ever, but that's another conversation.)

ODC and Programming By Example are definitely related, but PBE is more general in my mind since it can also consist of textual/symbolic/node-based structures. With ODC, the user interacts directly with the program output on a canvas, and the examples being pulled in are also viewed based on their output before being added.

Having to "play the computer" is one of the pains we're trying to solve for designers.

Today, with vector based tools, designers have to imagine how their design will look in the final medium (after handoff to dev). We want them to immediately see the real output -- the user experience that ships -- and pass real data though it, so they can evaluate the quality and robustness of the design in real time and improve it as needed.

Another potential difference between ODC and PBE can be level of granularity. Instead of working back from a finished example, ODC can leverage the steps you went through. Reifying steps is a great way to understand a complex artifact and then abstract from there. I keep coming back to the Fusion 360 Timeline as a potentially crazy powerful tool. Here's a video with a flavor of how its used. youtube.com/watch?v=o5NsPOcXLho

Nice, the timeline looks like a powerful learning tool. Cool how he fixed the rounding of the box. I think for code, it's way more complicated (halting problem etc.)

Interesting that you thought of CAD. CAD inspired our approach, but in the sense that current vector graphics UX design tools are CAD (focus on geometry) where they should be more specialized like BIM (understand the physics, i.e. a digital product is the interplay of code and data).

Fabrik may be what you're looking for - a visual programming environment based on dataflow-style box and wire diagrams on top of Smalltalk, which lower level components are built in. sp.cmc.msu.ru/courses/smalltalk/fabrik/figure3.gif

Fabrik began with an attempt to mix arbitrary layout and cell types in an object-oriented spreadsheet. The spreadsheet approach broke down with the complex expressions needed for synthetic graphics and other generative structures. The wiring approach addressed this problem and also opened the way for bidirectional constructions.

You can definitely get the feeling of a "spreadsheet on wheels" from it. Brad Cox, the creator of Objective-C, really admires it as the highest stage of programming modularity, basically as a super-object level that is directly manipulable and visible.

@Riley Stewart Thanks for the link. I wasn't able to figure out whether they we're able read Smalltalk code in the sense that the visuals were persisted/encoded as traditional Smalltalk files that you could continue working on with a text editor. One of the key things we're doing with ODC is to keep the original source language, e.g. TypeScript, intact by natively reading and writing to it so that devs can collaborate on the files without friction or loss of detail.

Good question. I was excited by WinFS when it was first announced, but it never made it to market. Maybe it would resonate with the "non-files" crowd today,

Aren't developers (UNIX developers) the ones who invented files and directories in the first place?

multiple processes have to operate on the code. Examples are: version control, compiler, and ide. Some people may want to use a tool you haven’t heard of or don’t exist yet. All these iOS apps operate like little islands where the author has to export the data from one app to another to do different tasks.

There are good arguments for and against filesystems, which carry different weight for different applications and/or user profiles. So why should one expect developers to manage data in the same way as the users of their applications?

George Campbell A file system is essentially just an app too. It's an app that allows you to store and retrieve data via a GUI interface or a programmatic interface. The only real benefit (or unfair advantage?) it has is that every programming language/environment has built-in APIs for interacting with the app.

I think the right path forward is for OS developers to abandon the idea of a file system as a “blessed app”, and create better and more general ways for apps to share data directly with each other. Mobile OS’s have been heading in this direction for a while.

This will make the “desktop” metaphor entirely obsolete, but that's ok. I'd say its time has passed.

It's probably overreaching to say that search-based interfaces are inherently more abstract than filesystems, but they are certainly inherently abstract, and presently more abstract than filesystems.

Dev tools face a pressure to be low-abstraction, because we never know what weird detail is going to get picked up and branched on by our eldritch runtime stack of OS, language VM, etc. For that weird detail to be invisible because of our shiny UI is intolerable. This kind of thing already happens far too often for my taste. My dev tools need to be an anchor in this ocean of insanity, not another contributor. So I think dev tools, at least for professionals and those who wish to be such, are unlikely to change and absolutely should not change until the underlying OS does.

I also reject the notion that "smart college students" are incapable of learning a hierarchical file system. If they're not getting it, you're doing a bad job teaching it. (Granted, the attempts of mainstream OSs to split the difference don't help, with multiple dumbed-down views onto the same tree. Funny how devs gravitate toward OSs that make that tree easier to see.)

Andrew F, "we never know what weird detail is going to get picked up and branched on by our eldritch runtime stack." In contrast we have the lie of WYSIWYG tools where some aspect of the WYG is hidden deep in a sub-sub menu panel or actually, truly invisible.

Nick Smith What does a "better and more general way for apps to share data directly with each other" look like that isn't "essentially an app"?

Or did you mean a file explorer rather than a file system? Calling file systems apps feels not even wrong. Syscalls are not apps.

The big difference between system software and application software is one of incentives. An OS maker needs people developing apps, and so has an incentive to standardize and maintain interfaces independent of products or apps. Two apps interchanging information often lack such transparently aligned incentives.

Kartik Agaram

What does a "better and more general way for apps to share data directly with each other" look like that isn't "essentially an app"?

My vision for inter-app communication demands that apps exist in a wholly new (i.e. not-yet-invented) operating environment that offers a novel model of data communication. The model will not be message-passing (i.e. syscalls, APIs, etc); it will be something closer to shared immutable state. But the details are unimportant here (and I'm still working on them). My main point is: this would be the "standard" you are speaking of, but it involves no "intermediary app", and it involves no "central file system". (After all, have you ever heard of an immutable file system?)

Andrew F I don't know if anyone is saying they're incapable of learning it. It's just a challenge, when a fundamental mental model that previously all students had needs to be taught. A pre-requisite becomes part of the course, and room needs to be made for that in the limited time the educators have with the students.

One of the high school educators on the stream we were discussing this on made a comment to the effect of: CS classes are increasingly teaching digital literacy skills that used to be addressed elsewhere.

Like Kartik Agaram says with "Two apps interchanging information often lack such transparently aligned incentives." Apple at least wants apps on their platform so that they can make their devices essential and charge rent. Facebook, on the other hand, has very little incentive to have people use any software, site, or service but their own.

Joe Nash says, "teaching digital literacy skills that used to be addressed elsewhere," and the letters AUTOEXEC.BAT flash through my mind.

Never underestimate the power of Worse is Better! Files and directories, especially in the Unix tradition, are the simplest level of object that can be meaningfully shared between programs. The issue is that a file is just a stream of bytes to whoever reads it; the knowledge of how to turn that into information stored separately, which makes interoperability buggy yet still feasible. Instead of a stream of bytes, maybe files can contain the behavior that makes them information bearing objects, so that an unforeseen consumer doesn't have to write more string munging routines, just send a message. This has to be consistent and ubiquitous from the bottom up in order to work, which requires an operating system alien to the current ones we use and more like Smalltalk.

Filesystems are really just trees (DAGs if you add in symlinks (that don't create cycles please!)), so representing, traversing, and serializing them shouldn't be infeasible in a language that elevates the file to an object. This also opens up the possibility of distributed object spaces in the vein of Jini/Plan9, where access across machines/networks can be mediated mostly transparently, especially with some notion of capabilities, which file systems already have a primitive level of in W/R/X permissions. The possibilities are endless, which is probably why so many people get lost and we remain in the enduring 70s frame of Unix.

Joe Nash Fair, they're not outright saying it's impossible, but I think the last quote on the article about "get used to it, this is not going away" absolutely represents despair toward actually accomplishing it. And yeah, despite all our big dreams, filesystems aren't going away either, at least not soon enough to give up on teaching people how to use them.

Particularly if A and B are seeing each other's edits in real time, you could make a case to keep things simple and maintain a single sequence of operations that either side can unwind things from. In your example A would first undo B's operation. Doesn't really use CRDTs' special properties, though.

That's the crux of the problem. People don't expect their undo/redo stack to be affected by other people's actions, but there can be cross-client dependencies between the stacks. We're already doing undo/redo history rewriting, e.g. to incorporate other peoples changes on component properties (I set a rectangle to green, you set it to red, I undo + redo, and we should be back to red to not loose your changes).

But this class of problem seems beyond that because the operations in the undo/redo stack don't capture the dependencies to other people's actions. Hmm... 🤔

If you haven’t seen en.wikipedia.org/wiki/Operational_transformation yet… 🙂

@Alex Cruise Have read a bit about OT, but that reading quickly guided me towards CRDTs as being a more modern approach that's easier to implement. Problem is, this scenario might not fit with CRDTs. What made you think of OT? Are there examples where you've seen this case solved elegantly?

OT is the only thing I’ve seen that works at all! 😅

Current mental model: Undo redo is time traveling. Undo redo combined with multiplayer and other people's undo redo is the multiverse with conflicting timelines 🥳💥

yeah, I’ve thought (and built) quite a bit about versioning over the years. If you want to get really fine-grained, OT or something equally complex seems like the way to go… But if you don’t mind forcing updates to be more coarse-grained, in which a thing with a long-lived identity is CRUD’d, it doesn’t need to be so hard

But it’s never easy

Domain model versioning always comes up eventually when you have enterprise customers… Some people are trusted to propose changes but not to make it so; they need to be able to save their work persistently, and someone else has to come along and move the pointer once they decide the proposed version is good

It’s easy to say “you should trust your users” but subjectively, I don’t want to be trusted so much! I want someone else to check my work! 🙂

It can also be tempting to go full git, with parallel histories that sometimes merge eventually, but git is confusing enough for developers, let alone non-technical users

Good point on how coarse-grained ops are, because I'm thinking a hybrid approach could be needed. Certain ops, like changing simple component properties, are frequent and need to be optimistically applied. Other things, like inserting new components with dependencies on an import statement and state management could use another approach.

A nice middle ground my team proposed recently, which supports some of the reasons you want branching, is to store every pointer between entities as an (id, version) tuple rather than just an id… If the version field is null, it means we want to point to whichever version is the latest; if it’s not null, it means we want to pin that specific version

Postgres allows some components of a composite foreign key to be null, so you can still have referential integrity

Versioning is also sometimes necessary even when there’s no approval workflow… the best example I know is when version n-1 needs to be in effect until some specific date/time, then version n needs to take effect automatically

For our case, the code being edited is versioned using git and push/pulled via GitHub where approval can happen via PRs and automatic checks.

I'm inclined to think that on the design canvas itself (we're a UX design tool), everyone should be seeing the exact same thing in real time while they work.

yeah, if you don’t need to be responsible for merging up in userspace, that simplifies things quite a bit 🙂

The crux of the challenge is to avoid an invalid source file with multiple people doing structural edits and undo + redo 😂

Undo/redo within the user’s work in progress, with respect to an immutable snapshot is fine… Undo/redo across commits is much, much harder. 🙂

Sometimes you can get away with making things command-driven, and have as many commands as feasible be idempotent

My instinct: model "Undo" as a regular operation that can conflict with others. If A creates something, B builds on it (more generally, makes a dependent change), and then A hits Ctrl-Z it should register a conflict in exactly the same way as if A manually deleted the thing. Maybe the only difference would be that the parent state of the undo op is guaranteed to be the result of the op it's undoing, rather than incorporating other changes (this sidesteps the question of whether A's client has seen B's edits). But the basic idea is that you need to handle all those cases anyway, so just use them for Undo. Ed: I guess I should be explicit that in this scenario the undo stack or whatever is probably private state, scoped to the client.

Andrew F Makes sense. We already use reverse ops for undo, but they don't have the concept of a blocking conflict error. I guess the thing that tripped me up was the search for conflict-free ops, but it seems like if program structures are dependent, yet can be independently removed (or at least attempted to), it's unavoidable to run into blocking conflicts since the program would otherwise end up in an invalid state.

In practical terms, these will be edge cases, but they still need predictable behavior. For user A there is still the option to first delete the open state expression that user B added, and then remove the Dialog along with the open state that no other elements depend on now.

The option for conflicts that I am curious about (but haven't seen any serious work on) is to include conflict markers in the fundamental data model, so they can just stay there until whatever squishy human process is relevant can decide what the right answer is. Optionally, automatically squash nested or adjacent conflict markers (less felicitous if you want to annotate each conflict site or branch, maybe record who made each change).

Incidentally, for me the idea of explicit conflict markers is tied to my ancient ideas for an editor for prose/poetry that lets you keep around various possibilities for a line or passage. So I guess if you go that route, and also use it for conflict markers, uh, let me know. :)

Ah, interesting. I think that has real merit in knowledge work where it's a collaboration to sort out a complicated topic. I recall also wanting branching for our pitch deck, where we could try out variations and target different audiences.

Andrew F Fossil has the distinction between "branch" and "fork". One is for intentionally branching off, the other for managing conflicts without the "stop the world and rebase before you can go on with your work" approach of git: fossil-scm.org/home/doc/trunk/www/branching.wiki

The rules for what's natural change depending where you are on the scale from Google Docs-style live collaboration to git-style merging commits.

If it's a platform where users can see different states locally, then I think User A's local state should roll back to as if they had never created the Dialog, and User B should now be treated as having implicitly created the Dialog the moment they made a dependent element. User A can't really "complain" about their undo being ignored, because they understand that User B is allowed to have the same idea they previously had.

Chris Knott We have to contend with both real-time and git-style for our case 😂

For real time, the program must always be in a valid state, otherwise we can't compute the visual outcome that needs to be rendered onto the canvas where the designer is doing their work and interacting with the program. Multiple designers viewing the same canvas should be seeing the same thing (converging on it at least, as updates cross the network).

Then, once the design work is ready to go into the shared git repo via a push, a traditional conflict can occur, e.g. if developers renamed a component that the designer added new instances of.

While we could technically have diverging local states for the canvas for each designer (visual programmer more generally), I suspect that would amount to mind-melting complexity that these "end-user" programmers would rather do without. The way we can go about exploring different design choices (program structures) would be driven by creating separate branches, where each branch checkout has a single shared + converging canvas.

This sounds exactly like a description of what HTML and CSS are. HTML is a description of a document without much regard for how a particular client will render it. CSS is a bunch of optional hints to the client about how to render it. Browser clients are designed for all sorts of different device types, and when a new device type comes along there's often a web browser for it that adapts existing HTML to work passably well with the new type of device. (I'm always shocked when I load my wildly complex website, loaded with SVG animations, on, say, a PlayStation, and it works 99% perfectly.)

I suspect you meant something more than this, though. How is what you're imagining different from HTML/CSS? I'm sure you've got lots of thoughts about this.

It does. But html and css are far more concrete than I'm thinking. Instead of the presented api being in the form of user interactable elements, present a machine api (think graphql ish) and let a program design a bridge from your api to UI. Maybe a better example is in order. Will see if I can make one when I'm at my desktop.

I would encourage you not to think of HTML in terms of "user interactable elements" but rather data types. Most of the data types are well named enough (input types: text, date, color, datetime, email) some less well named (input types: checkbox <should be boolean>, radio <should just be hints on select>) output types: p, section, h1. Because it's old and has accumulated age there are warts to it, but I think you'll find it still fits the bill and has the benefit of already working even when used well

I'm not necessarily opposed to thinking about HTML in that way. I just consider it slightly more constraining than what I'd like (which may or may not be possible). This is all indirectly inspired by Smalltalk and the ability in older systems to edit the UI of your own operating system immediately. That would be challenging in modern apps, if only because of the resulting merge conflicts 🙂.

Here's a very rough sketch of what I'm thinking of.

inthedarkcoder.com/images/SlackImageHosting.jpeg

The hope would be that this kind of api declaration could also span to entirely different UI types, because the programmer in fact makes no statement about any UI type at all. But then it starts to sound like SciFi where "Magic AI does everything"

Good questions. I'll give a go...

• Arbitrary Limits? Good OS-level IPC. It existed in 19-bleeping-77 friends dl.acm.org/doi/abs/10.1145/800214.806544! (For reasons that were entirely lost on me as a young man, my father gave me a physical copy of that paper as a gift.)
• 10,000 hours? Should be enough to digest the links on my desktop. By then I hope I'd have a clearer picture.
• Future of programmer interaction? Dancing.

I clarified the questions. I'm not clear on what you meant by the first answer. Second, many tabs and things to do is a problem we can all work on; I think not having time to read everything is a common problem, and more, knowing about the things you would like to read is even harder (cause you do not know what you do not know) -- I think this community can help with that. Dancing would be ... interesting, maybe with better AR we'll get there soon 🙂

I was being a bit obscure for effect...

What should we be able to do but can't for no good reason? IPC should be a lot easier. It certainly is in a language like Go, but that's the exception. Now I'm looking at the seven devices I happen have within reach that don't reliably communicate with each other despite that being half their job.

With 10,000 hours, I just wanted to make the observation that what I would do still depends on learning a thing or fifty.

As for dancing, it's the embodied aspect of AR/VR that holds more promise than the obviously more easily seen visual aspect.

Universal communication between devices seems exactly as a thing I was hoping to get as an answer. It is basically sci-fi and we are in awe when some devices manage it, instead of it being standard as in the movies 🙂

Regarding coding in AR/VR I wonder whether at some point we will be able to code by gesturing - moving us from coders towards wizards.