Comment by some-mthfka | Hacker News Reader

Comment by some-mthfka | Hacker News Reader

Parent Full thread

> 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