4 ms·

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the Project's Philosophy/Homogeneity section in [1] The Power of Structure. I am proposing we need to really start considering a different paradigm, and attempting to do it right, and that's structural editing. People are wondering if it's possible to be writing better structural editors. We all know there have been attempts to do those, and, well, lo and behold, those were janky too. But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". Well, in fact, I could tell you how we could do exactly that: you could start small. You start with what you know. And you know that you could, say, start with structuralizing the {} brackets. That's a semantic unit. So, that's a start. Even without getting down to the compiler level. But I am not arguing I am about to do wonders for something as complex as some mainstream langauge in terms of a structural editing. I believe it can certainly be attempted, though, and certainly improved, peacemeal. And what you can't do: mix it with the traditional string-based editing. Or take python: that one would structuralize pretty nicely by indentation. Would it accomplish everything? No. But it would certainly help. The gist of it boils down to the fact that you don't need to start at that very complex level, you can do things piecemeal and still get many benefits. Ask yourself this: can you edit a /list/ structurally, i.e. edit like in a string-based editor while maintaning an actual list behind the scenes? Sure, you can. A tree? Absolutely. Look at Paredit. THERE'S NO REASON FOR THAT TO BE JANKY. NO reason why that wouldn't work. It can absolutely be done. And, really, structural editing like I am proposing /subsumes/ string-based editing, because you can just write a specialized editor for general strings, and use that for things you don't know how to structure yet. And yet, even those string-based editors can be specialized further, as some semantic units like words, expressions and even characters are often immediately apparent. What does that give us? At the very least: object identity and programmatic access, and having the ability to pick your own data structure. This kind of small things are what's actually going to be very useful for stuff like note-takers and computational notebooks and REPLs and what not. We don't need to start with programming languages (though I am going to do a Common Lisp IDE). Please, ask me anything! Let's talk! PS Another very important point is that ambiguity can be localized. Look at the Alchemy section in [1] where I discuss dealing with the reader (but I also talk about it in Rune). PPS And thank you for posting this. It's exciting to be reading comments. Truly. [1] https://project-mage.org/the-power-of-structure https://project-mage.org/the-power-of-structure

PurpleRamen 4y ago
> But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". What does that mean? > start with structuralizing the {} brackets. That's a semantic unit. So, vim. Getting simple structure done is not the problem. We have them everywhere and everyone can build their own tools in proper environments. Supporting the big picture and custom structure is the unsolved problem. The best we get in that realm would be support for XML, Lisp, maybe also JSON and YAML and the likes. But all those are hyper specialized tools, optimized for those specific cases. What we lack is something good which generalize this. > The gist of it boils down to the fact that you don't need to start at that very complex level, No, there is, there always is. Because if you start simple, you always end up with the wacky unsatisfying solutions at some point. Nothing scales well to infinity. Micro-managing and macro-managing are different scopes with different solutions. Simple is good for the micro-levels. Complex is good for the macro-parts. Think about the text-editing of advanced text-editors, and the abilities of vim. Advanced text-editors are simple, and not bad. But compared to the complex editing of vim it still cannot be compared.
- some-mthfka 4y ago
  > What does that mean? That means they are trying to solve some very difficult, general problem first. But, you see, that's exactly the problem: you don't want to go general. You want to go: specialized. And here's the key: then you want to mix and do the interplay for your simple, specialized well-working elements. And, indeed, you can define some general interface properties for that, once you have it. > Getting simple structure done is not the problem. I agree! > What we lack is something good which generalize this. I can't emphasize this enough, but trying to find a general structure and fit it for everything is a path to failure, and I am arguing vehemently against such structures or approaches [1]. Strings are such a general structure. Although there were others proposed, like Ted Nelsons zig-zags. That's where you do not want to go. But again: generalization is not the problem, the problem is the ability to specialize. But, yes, you are right: there has to be an overarching system, and that's exactly what I want to do. A system where the simple parts can interplay. And importantly: embed. The simple structures I listed, and a few others? Those will be enough for the applications that I want to do. And that will be plenty useful to me, already at that. See, the fact of embedding itself lets you manage the complexity, because that's where a lot of complexity lies within: in hierarchies. And then, when you are doing editing operations, you have full and easy introspection into all the structures that you are operating on, so, doing them right will be possible. PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. PPS I am sorry for responding slowly, there are quite a few comments. [1] https://project-mage.org/on-flexibility https://project-mage.org/on-flexibility

PurpleRamen 4y ago

> But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". What does that mean? > start with structuralizing the {} brackets. That's a semantic unit. So, vim. Getting simple structure done is not the problem. We have them everywhere and everyone can build their own tools in proper environments. Supporting the big picture and custom structure is the unsolved problem. The best we get in that realm would be support for XML, Lisp, maybe also JSON and YAML and the likes. But all those are hyper specialized tools, optimized for those specific cases. What we lack is something good which generalize this. > The gist of it boils down to the fact that you don't need to start at that very complex level, No, there is, there always is. Because if you start simple, you always end up with the wacky unsatisfying solutions at some point. Nothing scales well to infinity. Micro-managing and macro-managing are different scopes with different solutions. Simple is good for the micro-levels. Complex is good for the macro-parts. Think about the text-editing of advanced text-editors, and the abilities of vim. Advanced text-editors are simple, and not bad. But compared to the complex editing of vim it still cannot be compared.

some-mthfka 4y ago
> What does that mean? That means they are trying to solve some very difficult, general problem first. But, you see, that's exactly the problem: you don't want to go general. You want to go: specialized. And here's the key: then you want to mix and do the interplay for your simple, specialized well-working elements. And, indeed, you can define some general interface properties for that, once you have it. > Getting simple structure done is not the problem. I agree! > What we lack is something good which generalize this. I can't emphasize this enough, but trying to find a general structure and fit it for everything is a path to failure, and I am arguing vehemently against such structures or approaches [1]. Strings are such a general structure. Although there were others proposed, like Ted Nelsons zig-zags. That's where you do not want to go. But again: generalization is not the problem, the problem is the ability to specialize. But, yes, you are right: there has to be an overarching system, and that's exactly what I want to do. A system where the simple parts can interplay. And importantly: embed. The simple structures I listed, and a few others? Those will be enough for the applications that I want to do. And that will be plenty useful to me, already at that. See, the fact of embedding itself lets you manage the complexity, because that's where a lot of complexity lies within: in hierarchies. And then, when you are doing editing operations, you have full and easy introspection into all the structures that you are operating on, so, doing them right will be possible. PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. PPS I am sorry for responding slowly, there are quite a few comments. [1] https://project-mage.org/on-flexibility https://project-mage.org/on-flexibility