Comment by PurpleRamen | Hacker News Reader

Comment by PurpleRamen | Hacker News Reader

Parent Full thread

> 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.

> 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

> trying to find a general structure and fit it for everything is a path to failure

Depends on whether you consider everything literal. That nothing can solve everything and your mother is obvious. But solutions which can handle majority, or even 99.99% of relevant cases of your domain, I think we already have that today for structures. XML for example was optimized for decades to handle structures. Not all parts are good for the majority of cases, but the general ideas and concepts are universal enough that flavors of them will always appear when tackling such problems.

So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases.

> 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.

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.

> So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases.

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.

> Existing solutions don't integrate within an environment, and not within each other.

Integration is surface, the interface to the user. Not the concepts or libs.

> I go into much trouble to explain my position on general data structures in the article I have linked previously.

Sorry, but not reading that, not after the first article. Too long, not enough meat, too unfocused. You should write shorter articles and stick to the topic when you want to reach people. Life is too short and full of content.

> 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.

And if you don't work with a solid foundation, you will start accumulating bloat of small pieces.

> I mean, you see, this is exactly why we have so many problems right now: people trying to use a general solution for everything.

That's wrong. Problems will always exist. Everything is a compromise of tradeoffs. It's not possible to have no problems. Well, except to no do it at all. The main reason why people tend to use more generalized solutions, is because it allows them to move faster, and specialize later if necessary.

Structures are also such a compromise. It enables you to handle more and press it into a form, but you will lose liberty to use forms outside your structure. Understanding and managing the tradeoffs is relevant here. There is a reason why we have types in the first place, and not write everything directly in memory like on a canvas. Similar there is a reason why we not have a thousand different types doing slightly the same thing, but use inheritance to build specialized types from a handful of basic types. XML is such a basic type, for tree-structures. And it is a good starting-point to build a foundation for structured editing. It is not the only type, but at the moment, the problem is, that there is not even this.

> It may be complex in comparison to notepad, sure, but,

Notepad is not an advanced editor. Is there even any editor which has a more complex editing than the vi-family?

> I mean I haven't seen what's so cryptic about it, not really.

Then maybe you just don't understand the problems tackled here at all.

> Integration is surface, the interface to the user. Not the concepts or libs.

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.

Reply on news.ycombinator.com