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 head, such that any help the debugger gives is added to zero. Which... is not good.
That is, complaints that ridiculously large forms cause issues in a debugger seem... pointless? Lets say you managed to keep that from crashing, do you actually have a way to make it workable?
Don't get me wrong, if folks are constantly opening JSON files that are gigabytes in size, it makes sense to focus on that and make sure it doesn't crash. I just, can't imagine what benefit you get from opening an X gigabyte file. I can't even see what the advantages of opening an X megabyte file are. That is literally beyond my brain power.
So, looking to rewrite an emacs is always one that strikes me as a huge risk of throwing the baby out with the water. There is more than a fair chance that what you like about the current setup is a necessary implication of choices that you think you don't like.
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.
I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it.
Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
As a general rule I prefer print debugging. I’ll step in with a breakpoint when I have to but odds are I’ve gone through a round of prints first.
I do not enjoy stepping through all of the context setting up the system to fail. I’ve not tried a debugger that can “back up”, that may well be a different experience. But I loathe stepping through code, walking on eggs, overstepping, “oops, thar she blows, start over”. Like Bugs Bunny on the piana.
Rather just toss in some prints, let fly, sift through the wreckage. My builds are fast enough to make the turn around acceptable.
Having worked in embedded, debugging through an Oscilloscope is a cherished memory that I sometimes talk to junior colleagues about. Knowing these things are possible can sometimes help people find more novel ways to think about debugging their applications.
> It's precisely one text terminal or LED scroller away.
This is quite strange. Let us remember the context
> Print debugging is a technique that will never go out of style. It works on any system,
So you are suggesting that watching the blinking of a GPIO pin (I hope you have an oscilloscope, or some other probe, rather than applying to to your tongue) is the same as "Print debugging"?
I contend that in any sensible use of technical English "print debugging" is text output to a console.
In that context there are a lot of systems, possibly most computer systems, do not have access to that. It is not unusual for developers to go to elaborate lengths to attach consoles to these systems - not the same as " It works on any system, "
If you added code to tickle the GPIO specifically to gain insight into the process, whether you leave it in or not, then it’s “print debugging”. Many a microcontroller developer has tickled an indicator LED in their day.
If your simply monitoring activity through an external source (whether it’s an oscilloscope or watching traffic through a network analyzer) then that’s basically black box testing.
> A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.
Actuators work too. It's not unheard of in robotics to debug by adding statements that make some actuator do specific movements that communicate the information you want to surface.
Anything you can use to output nonzero amount of bits to the environment can work for print debugging.
> No it does not. It requires a console, and not all systems have a console.
It does not. You just send the log output somewhere (often a different system). If you have a deployment with no logging infrastructure (either local for smaller setups or distributed for large scale), you have a major problem beyond just debugging visibility.
Via network socket, serial port, parallel port, however the system in question communicates with the world.
If it's an actual standalone deaf, dumb, and blind black box with zero world interaction then you should, at least, have a hardware probe and step debugging capabilities and you can always flash a sign of some kind on some bus or another.
He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thing I go for during debug.
As a side note: While using wgpu-rs to do Rust game development, I grew very fond of RenderDoc (https://renderdoc.org/).
It has great Vulkan compatibility and it helped me greatly when building an object picking buffer by visualising everything from call trees to resource contents and metadata. I believe it should come in handy for any GPU-based project, not just 3D/2D graphics.
This is in the realm of ignorant questions. It could well be that the majority of computer devices have none. E.g. the micro controller in my washing machine
Why is it an ignorant question? The nicer ones let you use JTAG etc connections, and debug to console using ITM or RTT. (STM, nRF etc) Others allow debugging via serial.
> Why is it an ignorant question? The nicer ones let you use JTAG etc connections, and debug to console using ITM or RTT. (STM, nRF etc) Others allow debugging via serial.
Because all those systems, even the very nicest, all over the palnet, very really have "JTAG etc connections,"
Those are things you attached to the system. You attach them in a complex error prone process, at the end of it you have a different system.
A lot of (most?) computers do not have consoles.
It is a common error amongst developers (who do not work in embedded systems) to assume there is a screen supporting text of some sort. It is an error
You connect the debug probe to your MCU (pogo pins or w/e is convenient for the form factor), connect it to a PC over USB, and print to a terminal window in Windows, Linux etc. Or a serial-USB bridge if it doesn't support debug probes. If the MCU is so basic it doesn't support UART, bit-bang it with GPIO. Too easy!
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.
There are ways to debug at scale that aren't step debugging. You can set conditional breakpoints, or breakpoints that run code, or even backwards debugging. You don't have to settle with print debugging, ever. But sometimes it's faster to use it.
I just, can't imagine what benefit you get from opening an X gigabyte file.
Maybe I don't fully understand the context, but... why shouldn't you open a big file?
I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit.
I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds.
If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.
I’ve used emacs to open and edit binaries back in the old days - basically one long line. We often needed to install proprietary software in non standard locations so changing the embedded strings within binaries worked great and better than using vi (pre vim era). Always best if the new path had a length less than that of the existing one.
In any event I guess the whining about editors will never stop but meanwhile they seem to be GoodEnough(tm) for me and most things.
Emacs used to be mocked for being bigger than the OS but now I think most editors are much larger. I used to work at a University lab helpdesk of sorts where first time users of UNIX systems would ask us for help getting started entering their first CSCI programs on a Sun or other UNIX-like os and my unscientific but high n observation is that vi, emacs, ed or cat all worked and occasionally people would find a way to get confused equally on any method when starting out. Level of education didn’t seem to make a difference.
Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options.
On another side note I am glad that most text input fields across many operating systems and applications usually do the right thing with Emacs cursor control sequences e.g. CTRL-a, CTRL-n, CTRL-p, CTRL-e. So hopefully that legacy lives on
Editor ergonomics seem to be very personal, like furniture so I’m glad we have so many options.
A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. He goes to some sandwich shop and ask for a beef sandwich and they offer him a beef + hard boiled eggs + lettuce sandwich with mayo, cherry tomatos and oregano, or a beef + cheese + spinachs + nutmeg sandwich or whatever. But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard.
I used Notepad in Windows for simple text, that used to work OK. Then I changed to some free editor created by a guy as a programming exercise with some interesting extras. Now both have the same problem: if I need to open big text files for some reason, it takes forever.
> A long time ago I read some piece by Groucho, about how it's impossible to find a beef (or ham, or turkey, not sure which it was) sandwich any more. (...) But he can't just buy a simple roastbeef sandwich, maybe with a pinch of mustard.
I need to find that piece, because it resonates. For me, it's hot dogs. I can't find plain hotdogs anywhere anymore. All I want is a bun, a sausage, and some ketchup and mustard on top. But no, everyone has to add at least cucumbers and fried onions, and if you're not careful, you'll end up with bread full of a large assortment of veggies, with barely a sausage in sight.
I imagine the reason for this is economics: this green stuff is probably dirt cheap relative to the sausage, but lets the vendor triple the price of a hot dog without making you feel they're price gouging you.
For the past decade in my area, IKEA was the last bastion of pure, unadulterated hot dogs. But even they recently took that off the menu - the basic hot dog now comes loaded with useless greenery.
I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway).
I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.
I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.
It's not Emacs fault that CSV is a garbage format. Anyone who has spent time dealing with CSV understands the hell that is lurking in it's shadows. I don't think the rants solution, though I did not finish reading it because I frankly got bored, is going to fix any of this, either.
That isnt the problem he is describing tho, it is that you have no primitives in emacs that correspond to a rectangle of text entry boxes like the semantics of csv. You only have sequence of chars.
The author wants people to rewrite emacs as a design system for arbitrary structures of data, with hooks for moving around the structure and editing the structure and i guess contents
I see. I thought the rant was a mess, personally, so I stopped reading it. Theres some irony to be found in an unstructed rant about... structured editing.
Anyway, if that's the point, then maybe tree-sitter can help us get there in the future? I still fail to see how this is an Emacs problem to solve. The vim/neovim model is also using what are essentially string dumps in the form of buffers. I'm sure every other editor is, too, but without going as far as actually having buffers, though I'm not invested enough into anything else to know what it's doing.
> It seems that the syntax highlighting is the culprit.
In that case, it was the fact that adding a bullet point to a list would rescan the whole list (so it could simply update a bullet count in the header). You would need to implement incremental parsing for that, and that's not very easy. And certainly not natural.
> If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming.
Absolutely, that's one of the points.
I must add something, though. It's not just about speed. And, in fact, it's not even just about editing.
Most exciting possibilities of the structural approach stem from the fact that you can start thinking in terms of objects: then you write textual interfaces for those objects, for the purposes of textual (or even graphical) interaction.
The bare-bones example is that if you had a table, or a tree in a note-taking application, then you could query that tree, but you would still retain the textual interface. Even better: you could embed any editor within any other editor, which would directly correspond to a compound structure at hand.
To give you an idea of a note in a KR (knowledge-representation, prototype OO) system:
(create-schema power-of-structure
(:is-a kr-note)
(:title "The Power of Structure")
(:tags '("seamlessly-structural editing" "power"))
(:introduction '("Welcome to Project Mage!"
"The purpose of this article is [...]"))
(:table-of-contents nil)
(:sections (create-schema))
(:related-links nil)
(:footnotes nil))
This note [1] could have any other structure, any other slots, of course. But it's just an object in memory.
Now, all you would have to do is lens that object, aka, construct a tree of embedded editors for it (which Rune will also do via KR, just like the object above).
Another example: code. A large comment block? View and edit it via a note-take application, or a markdown application, or what have you.
Another example (leaving some details aside): attach comments to any piece of code (up to a character). That comment doesn't even have to be a part of the editing workflow. I think that's pretty powerful (and there are more use cases, see Alchemy in [1]).
I had not realized that you wrote the fine article. As I told scruple in a sibling comment, I've been working in a pretty similar system for... some time :)
So I have some reading to do about that Mage Project...
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).
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 head, such that any help the debugger gives is added to zero. Which... is not good.
That is, complaints that ridiculously large forms cause issues in a debugger seem... pointless? Lets say you managed to keep that from crashing, do you actually have a way to make it workable?
Don't get me wrong, if folks are constantly opening JSON files that are gigabytes in size, it makes sense to focus on that and make sure it doesn't crash. I just, can't imagine what benefit you get from opening an X gigabyte file. I can't even see what the advantages of opening an X megabyte file are. That is literally beyond my brain power.
So, looking to rewrite an emacs is always one that strikes me as a huge risk of throwing the baby out with the water. There is more than a fair chance that what you like about the current setup is a necessary implication of choices that you think you don't like.