31–40 of 163 posts
The entire article comes down to this quote: WHY IS EVERYTHING SO JANKY AF?
And my reaction was, is it really so yanky? Maybe it's not yanky enough for me to notice. Except for the handling of long lines, that's really slow. I wish it is just yanky. However I don't understand one thing. Did the author switch to something else or he's still using emacs after this long and convoluted rant?
I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my…
At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility.
Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.
Earlier quoted context omitted.
Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigati…
I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost. I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.
I don't think there's an argument to be had for all structures, just that you can do it for each custom structure, and that's the point.
Maybe the editors of the old tried to bite off too much when they attempted embedded structures, and they didn't have the right abstractions in place. If you look at https://tylr.fun it shows that things that weren't being done back then, there are interesting approaches now.
Earlier quoted context omitted.
Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.
Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.
"gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins."
— https://mobile.twitter.com/id_aa_carmack/status/568861553245...
But I am perfectly willing to embrace structural editing if it makes editors much, much more efficient and less complex (e.g. you don’t need to cache things).
Maybe things become “janky” because many of us are a bit too good at limiting source files to at the most 1K lines, so we tolerate the minor hickups that we encounter?
Earlier quoted context omitted.
Print debugging is a technique that will never go out of style. It works on any system, is used by programmers of any level of experience, is very quick to use and requires no tooling to understand. And sometimes, even if you do have other great tools at your disposal, it’s still the easiest way to track down a problem.
Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.
If the system can't emit any data, well, you're kind of stuck anyway.
I very much like this article. I especially like the comparison to TempleOS. I think Terry Davis blew computing wide open. That is what a personal computer can do, when it’s treated as an instrument instead of an appliance, and the user treated like the player of said instrument, instead of a child in a china shop. Imagine if you could plug your guitar into a computer, have that audio file, be a widget in a buffer, a…
Hell, all of what you describe is basically available in the form of Mathmatica.
And "share a program with a friend" is called a webpage with Javascript. We have the universal VM, just not in the shape that you would like.
I don't want to be too dismissive of this stuff but I think at one point we gotta try using all these new fancy ideas that would be good for everyone, instead of constantly just imagining "what if they existed". Let's actualize a bit!
https://www.reddit.com/r/emacs/comments/so7os8/notdeft_notes...
https://www.reddit.com/r/emacs/comments/speq69/uomf_pathinde...
https://www.reddit.com/r/emacs/comments/zl8nfa/is_there_some...
https://takeonrules.com/2022/02/26/note-taking-with-org-roam...
The long story short is that we need something to process text automatically in easy to compose and easy to query ways. Emacs peoples mostly hate databases, and SOME DB models are strict, hard to keep bending, graph DB have not succeed so much so far, so it might be ad unsolved problem, a VERY OLD one, let's say:
- ~612 BC Ashurbanipal of Nineveh cataloguing system
- ~245 BC Callimacus Pinakes cataloguing system
- ~1545 libraries of Babel by Conrad Gessner
- 1673-94 Gottfried Wilhelm Leibniz, Scrinium Literatum
- ... to the Mundaneum (Paul Otlet/Henry La Fontaine)
- ... to the web first concept, the search engine concept
...
Natural language is not much computable directly, some modern ML tools try to work on it, some classic algorithms try to do the same, most results are not much good at small scale, they are just good at very large scale for very limited results.
But the point of Emacs is another, is the LispM concept, witch was also the Xerox PARC Smalltalk workstations concept: as we need ways to act on text with automation so we need OSes as a single application, where the source is live, changeable, where anything is a function the user can use anywhere so that if I have a CAS on my desktop I can solve and ODE with it inside an email and link the email in a paper.
Old systems was limited by the tech of their time, Emacs by the size of its community and the burden of legacy it have, but they show a starting point that's effective. The rest is still to be invented, implemented and done. NO OTHER TOOLS so far have proven to be better in general so...
Earlier quoted context omitted.
What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. > I'm always struck by the useful directions that desktop computers were going in the 70s, and how computing could be so much better than it is right now. But we've veered so off-course from all of this, away from composability and towards independent boxes ("applications") that can't talk to each ot…
> What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. No, more like Interlisp, which is kinda like Smalltalk in terms of being an active environment, only without having to deal with... you know... Smalltalk in order to use it. Plus, there's something to be said for a plan that's probably now mostly forgotten, to re-write Emacs to use Guile as its lan…
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.