thanks for this! have you thought about hierarchical data structure manipulation in emacs style cl environments? any tools to look at?

I am not sure I understand the question, but, for instance, Lem is an emacs-inspired CL editor. Not structural or even hierarchical though.

I hate to taint this, but reading up on Fern I have to point to JavaFX. It rings a lot of similarity with what is being talked about here. There may be other frameworks also.

But JFX captures much of this. It doesn't have your schemas (its obviously based on Javas class and object system), but it does have constraints, it does have bindings (not as sophisticated as yours, but they exist and quite useful in practice). It has the scene graph, it handles contextual styling via CSS. It has its layout components, and GUI components. It even has 3D ;).

I will say about the bindings that when the graph gets large it can be fun to try to keep in your head, and, unfortunately, there's no real way to visualize it. So, when something changes (or changes in a way you don't like), it can be an endeavor to source the change and navigate the relationships.

The primary reason I mention this is just to lift it up as an example of many of the concepts you're discussing, but in "production" code, used by many, for quite some time. There may be insights there that can be mined as to possibly decisions that were made that you could apply (or not) to your work. Are the limitations of JFX done by design? Limited by Java? Limited by performance? Limited by "haven't got to it yet"? I don't know, but, anyway, just something you may want to study a little.

I wish you luck on your project!

> Javas class and object system

I can't stress enough how important and helpful prototype OO has been to the current design. I couldn't imagine doing what I want to do without it. For example, some of the concepts such as configurations and contexts rely on dynamic inheritence.

> There may be insights there that can be mined as to possibly decisions that were made that you could apply (or not) to your work. Are the limitations of JFX done by design? Limited by Java? Limited by performance? Limited by "haven't got to it yet"? I don't know, but, anyway, just something you may want to study a little.

Sure, I will take a look. Thanks!

I haven't finished reading everything but so far I like what I read.

In a way, it reminds me of the software research project STEPS which aimed to reinvent computing with much less code than normal software. I consider this project a failure not because its funding got cut before the end but because nobody managed to reproduce their achievements (non reproducible research isn't research).

I wish you more success!

This (STEPS) sounds interesting, do you have a pointer? (It's not the easiest word to google...)

Research out of VPRI: http://www.vpri.org/

The "writings" page has a long list of publications you can check out.

What I want to know is why that implementation (Frank) that Kay uses for all his presentations isn’t available anywhere. Is he the only one that has a license to use it? I mean after all that research could you not zip up the result and throw it on GitHub?

STEPS is a very interesting project, indeed. I don't think it was quite a failure, after all, they did Nile and Gezira, which was pretty cool (powerful vector graphics rendering in a few hundred lines of code). Someone might reuse those in the future, I don't see why not.

But from the limited things that I saw, I got the feeling there was no overarching system. And there was no thinking about flexibility in general (which I consider to be essential to computing). I could be wrong about that, though, I didn't study it very thoroughly, only watched a presentation or two and skimmed the paper. Not that it wasn't ambitious enough already.

> I wish you more success!

Thank you!

Actually there was a lot of thought given to flexibility, I think a lot of the concepts were not exposed well due to the large project scope. Maru (which is the underlying STEPS runtime) for instance was designed to be completely replaceable (See COLA papers) using a composition mechanism similar to fexprs. Maru is also very easily bootstrapped as the VM/runtime and compiler come in at under 2KLOC with all the facilities.

Huh, interesting. I should try to learn more about STEPS in general some time...

> non reproducible research isn't research

Toxic mindset, so committed to this particular shibboleth!

Well, we're not talking about multibillion dollars particule accelerators research here but about software research!

When is that not true?

Have you thought about how your system might be adapted for power users that have accessibility requirements, such as blind people? I'm guessing you'd rather not implement the current GUI accessibility APIs, but would rather have something like Emacspeak that directly implements the alternative UI (e.g. speech output) inside the Lisp environment.

You know, I really haven't thought about that, but now that you mention it, I have heard before that in Emacs, the advice facility is very useful to the goal.

Well, all I can say is that I see no problem in adding speech output or in adding advice. The system is going to be very flexible to the end user.

I think the trick to all accessibility issues is actually logging/tracing. Similar to kafka, you can have consumers watching the UI log to act upon.

Update: I have updated the power-of-structure article with a section on accessibility.

Copypasting:

It's important to think about issues such as accessibility in advance.

I am basing my knowledge about this issue on this article about Emacspeak.

So, Rune will ask lenses to implement the surface-level text commands. Whatever text is shown or assumed to be on screen, the user will be able to copy that text programmatically. So, you could ask a spec-conformant lens stuff like "get the surface level text of the semantic unit at point". Such functions are of general utility.

Next, Runic functions will be required to return some information about the results of their semantic actions. So, if you issue a delete-semantic-unit command, it will return what it has removed (and that would include the info about the surface level text as well as the data-structural unit itself).

The list of such functions and their return-value properties will all be a part of the spec. So, it will be possible to automatically advice all these spec functions for any given lens to invoke the speech functionality.

Isn't It Obvious That C Programmers Wrote Git also a bit ranty. It was never made clear how Mage would make what-git-does better. And isn't it obvious that C Programmers also wrote unix, kernels and userspaces?

The way I read this is you write that assuming the reader cherishes unix, kernels and userspaces as opposed to integrated live lisp environments assuming the role of unix, kernels and userspaces, yet without C. Now try looking at the world as someone who does not cherish unix, kernels, userspaces and C programmers' view of the world...

[note: I do cherish unix, kernels and userspaces; AND lisp. Oh and C...]

and I cherish lisp, and scheme too... and, of course, C programmers wrote a lot of lisps also :)

My point isn't so much to reinvent Git's model (aka tree of blobs/commit/commit-graph), but rather to make it a part of a programmable interactive environment, and then just do the right thing from the user perspective.

That would include:

(1) Develop a UI for navigating the model,

(2) Develop a set of commands that act on the objects of that model.

I do want to append to the Git model by introducing the staging step for the whole tree (this, unlike with commits, won't have to have a history). I also think it could be possible to make it more flexible. So, you could say that there are blobs. But instead of blobs you could have some other kind of object too: for example the kind that would lazily compute itself from the definition of some other similar object. Or the kind of of object that would have knowledge about its contents, have an efficient way of storing it, maybe. So, I don't really want blobs (binary large objects), but rather a general kind of objects. Such objects would obviously need to conform to some API spec. Such objects could be written by the user (although, then he would have to supply the definitions to the others who want to use this). A tree could hold different kinds of such objects.

There's definititely some design that will have to go into commands. The commands would have to be taught to be context-sensitive (e.g. to selections or to the current state of the graph or commit).

A session-time undo graph for the repo-staging tree could be built as well. Easy implementation: copy the whole damn thing to memory on every change (only works for small repos, but that's a start). Harder implementation: define the inverses for the commands and build an undo graph.

I will admit: I am by no means an expert on version control systems. So, thanks for expressing the fact I didn't write about this, there's definitely some challenge to this, and I don't have any sort of final design in my head quite yet.

I enjoyed Emacs is Not Enough, I think it nailed trying to make it's point on why modern computing is so user hostile. I've sent it to emacs users I know, and they, too, have enjoyed it.

It was a bit of one of those train wrecks that's impossible to tear one's eyes away from. It had me thinking "wait, Emacs could be better?" (I've only been using it for a few years). The Emacs is Not Enough post[1] certainly drew more onlookers with its title than this post though many complained about the length and the focus. Admittedly I think I wouldn't have been intrigued if my first interaction with this project was just the root of the site as linked here. The author has certainly done a good job providing multiple avenues to explain this concept.

[1]: https://news.ycombinator.com/item?id=34375137