79 karma · joined January 10, 2023
https://news.ycombinator.com/item?id=34375137
The Emacs is Not Enough is quite ranty, and its style is not to some people's taste (well, it is kind of a rant, after all).
If you want the meat, indeed, please see any other articles on the homepage, or, for an overview of the project, this:
https://project-mage.org/the-power-of-structure
Thank you.
> show me a better editor than emacs first
I will. Just one correction: it's not going to be an editor. It's going to be many editors forming a cohesive whole.
Rune: Rune Is Not an Editor.
Other than that, what can I say? Yes, I have to prove my words, even though, in my opinion, the writings have enough to convince you that it can be done. And I will do my best to deliver.
That's the kind of viewpoint you get after years of using Unix or Windows.
> Sorry, but not reading that, not after the first article.
Ok. That one is not a rant, but whatever, you are arguing against its contents, and I don't see why I should be repeating myself. Sorry it's too long.
> And if you don't work with a solid foundation, you will start accumulating bloat of small pieces.
Exactly: you need a solid foundation to give you all the flexibility & meta-flexibility that you need. Otherwise meet bloat.
> That's wrong. Problems will always exist. Everything is a compromise of tradeoffs < XML is such a basic type, for tree-structures.
Hey, look, you keep arguing with the article you have decided not to read, and you are arguing with a strawman. I don't know what you think I am trying to do.
> Structures are also such a compromise. It enables you to handle more and press it into a form
You know what real flexibility means? It's the ability to decide when you want structure and when you don't. And this is the kind of structural editing I am proposing: you can simply recreate a string-based editor within it, for any of your elements. At the higher-level, it can be reused. No structure where none is required? Sure. I am all for it. But there's much more structure out there that meets the eye.
> Then maybe you just don't understand the problems tackled here at all.
Or maybe you don't? Because, explain your point better, please.
No, not for the text editor, but may be for some users. If a tree falls, does it make a sound?
After all, maybe you are just not a power user and don't have the same frame of reference that power users have.
> It has to be shown that structural editing makes an editor simpler, faster and in suited for a broader range of tasks. Until then, text is the king.
Text might be the king until then, yes, but so is C++ and the children running with AKs in Africa. Doesn't mean it's right or acceptable.
To me, I have argued extensively, that yes, structural can be absolutely simpler and faster and more versatile. Without a question.
> I would not say that CL itself is a problem, but on the other side the lisp community likes to write essays about the perfect software in the sky but delivers mostly nothing.
I am sorry, but I am not a part of that generation, if there's one. Yes, I can see how strange it is to not see what's claimed to be a very powerful language overtake the world. I agree on that, it's a bit mysterious.
But some things just take time, I think. For the people to get accustomed to it; to go through some pain first, perhaps.
Look, the only reason I am using CL is because it's an image-based language. That's simply crucial for interactivity. What are my other options? Smalltalk isn't bad at all, but I like macros too much, and the stability too.
> in praxis it raises a lot of red flags for me.
You have to account that the community hasn't been as nearly as large as for any other mainstream programming language. So, aren't your expectation, perhaps, a bit too high for the output of that community? It only has something like 3k packages online. Python has 420000+. Where is all the amazing python userland software that has lived for >5 years?
And, you know, as small as it is, people have published some pretty cool libraries. Stable libraries. Sublanguages. Macro libraries. FWIW it's pretty cool as it is. A game was published two days ago: https://store.steampowered.com/app/1261430/Kandria/
Is it amazing? Haven't played it, don't know. Maybe? But what exactly is all that software you are expecting to begin with?
I don't know the name for it, but there ought to be some cognitive bias that says: "things that don't happen, can't, and won't".
Of course, I get it. I would be sceptical too. Maybe even very sceptical. But there's no other way to deal with sceptisism other than to analyze what's actually proposed, and whether it's doable.
Glamorous Toolkit[1] promotes the idea of moldable development[2].
There's a talk on it: Tudor Gîrba - Moldable development.[3]
The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook.
The site on moldable development states its difference with literate programming:
They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).
And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment.
The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool.
But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated.
It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself.
I can't say I can compare it to Project Mage in any meaningful way, except it's also a live environment.
[1] https://gtoolkit.com/ [2] https://moldabledevelopment.com/ [3] https://www.youtube.com/watch?v=Pot9GnHFOVU
Yeah, that's a way to do this, but if you start small, you will then later find yourself walled within your initial assumptions about what you really want. Oh, well.
> By all means I wish you good luck and I'd like to check in on the project in one year or something.
Sure, and thank you!
Building my own solution which the website is dedicated to.
You can't stop people from trying, but that's just the wrong paradigm to try those things. My point: we can still have an environment that can do all of these things. Embed a spreadsheet and interface a database textually. Why, is what emacs giving us really the end of it, you think? Because I don't.
If you like mediocrity, sure. That's what so many have OK'd, and that's fine, not everybody has to care about tools.
And you are right for being sceptical: it's only natural, I would be too if I saw what I wrote without knowing what it was. As an Emacs user, I could be dismissive of new efforts, because, you know, emacs is enough and all.
And I have said this a few times in the comments, but I am far from tired: the point of structural editing is not just editing.
If you have time, take a look at Alchemy and what I want to do in it:
https://project-mage.org/the-power-of-structure#AlchemyCL
Slime for lisp didn't do it for me.
My thoughts on tree-sitter:
https://news.ycombinator.com/item?id=34375137#34379449
> org is unmatched
Yeah, but is it even good? I am using it myself, have been for many years. It doesn't bring me joy to say this: but it's not enough either. Far from it. Miles, and galaxies away from it. It could be so much better (the experience of note-taking and computational notebooks).
> an adept of a language which is since decades more known for rants about programming than for delivering amazing software for end-users
Look, all the rest of the languages didn't deliver it for me either (and for the computing industry at large, even though many people would prefer not to think about it).
Computer industry is very young. Very young. I get the skepticism, but just think of it!
Emacs kind of did deliver, to a point, for some time -- and that's written in lisp. One of the longest-living pieces of software.
Or are you saying that Common Lisp itself is a problem? I mean, it's was simply the most practical choice on my part. I don't consider myself an adept, I don't consider CL perfect, but it's suitable for what I want to do.
Exactly, a custom structure, a custom object. That's my point. And that point is: the ability to specialize on custom structures, which are unavoidable if you are to keep your sanity.
I have expounded the point about structural editing (tangentially) on some other comments here, in this top-level thread (unless you want to read the article [1]).
Didn't know about that one. Jesus, Elpa, really? Not that it changes anything.
>> A table editor within emacs will be janky > This is completely wrong. There are half a dozen Emacs packages that give you variations on the theme of a table, and none of them are slow or janky in my experience.
Haha, have you used org-made lately? Have you tried formatting a large table? Is it fast, you think?
Look, make a 100colx100000row table that you can edit (although, something like 10 by 20 will do the trick too). Not just view, but edit. It's not a question of whether it will be janky, it's a question how long you have to wait before exiting the damn thing in a furious fit of anger. That's just what you get with plain-text, plain and simple. I don't see how this is even an argument.
And then, why do you think it is that there are half-a-dozen packages there for it anyway? Is it, perhaps, because no one of them really does the job?
> This one is actually caused by your clipboard manager rather than an Emacs package.
I take a rant license on that one.
> Etc.
But, you see, that's the problem: these problems don't end.
On the one hand, this is a UI problem, so that's just how I would prefer it. When you have a lot of output (like thousands of lines in a batch), you really don't want to go looking for where that thing begins.
On the other hand, you can't easily access the latest execution run programmatically. So, then, the input part shouldn't be there as well.
That doesn't mean you couldn't select a run of input-output dialogue, though. Visually, the run of UI input-outputs could be the same, it's just that how you work with all that stuff that has to be structured.
Existing solutions don't integrate within an environment, and not within each other.
> XML
I go into much trouble to explain my position on general data structures in the article I have linked previously. You can't, in general, really optimize general data structures for specialized use-cases. That's why they are called general!
You wouldn't use a map where you could use a vector, right? But a map would still do the trick, no?
If you start doing all that, you are then trying to fit logs through a meatgrinder. You then have bloat, inefficiency, and all that other good stuff. I mean, you see, this is exactly why we have so many problems right now: people trying to use a general solution for everything. But all those solutions aren't good enough for one reason: they can't specialize. And you can't make them so. (That's the whole point of the topic article, too, just applied to strings.) And they can't interoperate.
> even 99.99% of relevant cases of your domain
Currently, that's more like 50% and the rest is unattainable without access and the knowledge of structure. And the first 50% doesn't even work that well either. I list a few applications on the website, so, don't take this as a bunch of empty claims: those can't be done efficiently (or practically) via the general means.
> Normal editing today is: you press a key, something happens, that's all. Sometimes you add a modifier, but that's mostly it. Vim on the other side, you have modes, you have parameters for key presses, you compose commands to create new commands on the fly. That all is several steps more complex than just a simple key press. Vi-Input is a whole language in itself, highly complex on a cryptic level, all just to macro-manage micro-tasks.
It may be complex in comparison to notepad, sure, but, I mean I haven't seen what's so cryptic about it, not really.
But is it perfect? I don't think so. Whatever is responsible for structural analysis should also be responsible for editing and all the extension capabilities, if you are to have a truly powerful system.
For me, the real problem lies in the integration with the client environment. Tree-sitter is fundamentally separate from the client application. That places questions on the introspection capabilities.
I mean, suppose your comment has structure. Suppose it's a markdown document, that comment in your code. And suppose you want to edit it that way: as a markdown document (or anything more complex). So you may want a markdown parser for that. Suppose you can write that parser in tree-sitter. Suppose you can even do structural-embedding. But how are you going to control and customize it? How are you going to write complex interaction policies between different structures? Embedding is where such seperation starts running into limits.
Why does this happen? I believe it's simple: APIs aren't enough. What you want is for the user to have access to the building blocks of whatever is being manipulated. And, so, keeping those blocks away from the user is never going to be that.
What's more, tree-sitter is still not really structural. That means it can't handle ambiguity well. For instance, in a lisp expression, you can insert a stray parenthesis. Paredit or a tree-sitter solution is going to tell you that your structure is malformed. A truly powerful structural editor is going to simply assume that parenthesis doesn't disrupt the structure around it, and so, it will simple keep track of it, and maybe it will find a match within the same expression at some later point in time.
Yes: a structural lisp editor doesn't have to care about a stray parenthesis. It just keeps keeping everything around it intact. It's a local ambiguity.
And, at last, the very important idea of structural editing is not even editing: it's the ability to treat structures as objects. It's the ability to present objects using a textual interface. Suppose you have a table structure, multiple layers of it. You need direct access to all that. Editing it should be easy, but it's really secondary.
Tree sitter doesn't deal with this.
I still see tree-sitter as useful, because you still need to deal with all the plain-text files out there. Perhaps, it could be used to import plain-text into a structural-editor representation, and then it may be, again, used on small subexpressions to identify their nature, incrementally, at runtime (but not the whole document, like what a usual incremental parser would do). So, that's the value of it as a parsing tool.
So, yeah, it's a useful tool, but when it comes to some advanced points of power-use and extension, it's not really enough.
Thanks for the question, it's thought provoking in many ways.
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.
Of the link provided (on a skim, so I may be wrong), they seem to be all doing structural editors for specific languages, and that's where their ambitions end. That's their focus: some language. My focus is: applications. Within a power-user environment, which can't be done without a GUI toolkit, which can't be done without image-based programming.
Surely, there are some efforts which I like. Glamourous Toolkit. Not particularly about structural editing, but whatever Smalltalk stuff you take, it just tends to be interesting. Ultimately, they fail to deliver in some way, for me at least. (I comment on GT in the "All Else is Not Enough" appendix article.)
I mean, yeah, look: practical applications. First of all: usable to myself. Then: flexible enough to fit anybody else.
PS The topic article is a rant, I admit. And I rant here and then a bit in the main article, sure. But, please, don't be too quick to classify everything there as a rant, even if it stylistically looks so.
PPS I have to take at pijul again, maybe I missed something, thank you.
That reminds me of: Terry Davis' TempleOS Brutal Take Down of Linus Torvalds
https://youtu.be/gBE6glZNJuU?t=388
All computer people today have been jedi-mindtricked, they obsess on if there's one thing they all wanna show you they know is scaling. Everybody is obsessed with scaling. Guess what. Scaling works both ways. You can get bigger. What happens if you look the other direction and you scale down? It doesn't get bad, it gets worse when you scale up. It gets better when you scale down.
I think it's a fundamental problem of flexibility of specialization vs generality. I laid out my thoughts on this on the website in the "On Flexibility" article (There's an article on print statements, too, by the way).
Modes don't do that. Neither do they let you control the underlying structure, they give you no ability to treat structures as objects. Yes, they do provide a common interface, but that's where the pros end. Ofc its emacs, and there are projects like Multi-Major-Modes that at least try to subdivide a document into editable areas... speaking of ridiculously slow.
As for constraints and prototype OO: I think those will simply do great for GUI building, and for flexibility. I think you need such abstractions to be able to deal with customization and complexity of embedded structures. I am basing Fern on the Garnet GUI framework [1], which had ~80 projects and was pretty fun to use judging by what people say.
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.