Curiously:
> Print debugging.... It works on any system
No it does not. It requires a console, and not all systems have a console.
"gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins."
— https://mobile.twitter.com/id_aa_carmack/status/568861553245...
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.
By the way, there are actually ways to expose a print function on shader code, provided there is driver support.
https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...
If the system can't emit any data, well, you're kind of stuck anyway.
It's also by all recognition, functioning perfectly :)
A huge proportion of computing devices have no method of producing any out put, other than to some form of actuator, at all.
"print statements" are useless in this class of device.
Stretching the definition of "print statement" to recording pulses from a pin is, well, a stretch!
Poor young programmers. If the only tool you have is a hemmer, every problem is a thumb.
Yes, they are. How do you think text terminals work?
It is a long way from "pulses on GPIO pins" to a print statement.
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 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.
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.
You can print debug on an Arduino for example
So, yes, it works on pretty much any system.
And you then have a different system.
My point is consoles are not ubiquitous in computing. Computer systems that lack them are very common
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
So if you connect up a bunch of wires and everything goes well "too easy" you can get output from some, not all, systems.
What you describe is no what the comment about "print debugging" means, to me.
Only when you get into realm of few cents per microcontroller then you don't have it
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.
How?
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.
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.
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.
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.
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).
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 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.
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
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.
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))
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]).
[1] This example is directly from https://project-mage.org/the-power-of-structure
So I have some reading to do about that Mage Project...
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
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.
Edit: big as in ~ 1 MB, sometimes smaller.
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.
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.