It is indeed a good way to add regression testing to code with no tests. But it's no substitute for TDD. It can't tell you why something is the way it is, nor can it distinguish between intentional and incidental (although maybe some would argue you shouldn't, given Hyrum's law and all). But it will at least guide you as you try to figure that out and stop you breaking stuff constantly.
The problem is some stuff is a real pain to test with static assertions. Such as I was saying about compilers. It would be a real pain to maintain an expected AST in a unit test, then you'd have to go rework it all if you change the shape and or add/remove nodes etc.
You can mix the approaches, have some static assertions(as sanity checks) but make most snapshot tests. Like I said I wouldn't use snapshot testing for a fibonacci method, but there are problems out there that are a real pain to test via static assertions.
Emojis aren't 7-bit clean. They're hard to type. They don't mean things the same way words do. `foo | grep -i error` communicates intent better than `foo | grep :-/` or whatever goofy hieroglyph someone chose instead of, like, a word with clearly defined meaning.
In my experience with live codebases, "error" or "warning" rarely mean the same thing to the same person, but admittedly you're much more likely to guess that they're in use as opposed to crying-green-clown emoji
I'd like to recommend rofimoji. I have it bound to a hotkey, so whenever I want to type an emoji, I just hit that hotkey and then a window pops up with my most recent emoji already visible at the top. Then I start typing in words that describe the emoji that I want like "crying" and it filters the list. Finally I select one and it pastes it into whatever text box I had selected before I hit the hotkey. My only complaint is I wish it worked for all unicode codepoints instead of just the emoji.
Yes that's why I also mentioned text labels. (strikethrough ansi codes aren't also fun to type). Besides, where are you needing 7but clean data ? Isn't that a narrow use case ?
It's the robustness principle. "Be conservative in what you do, be liberal in what you accept from others." A CLI author shouldn't assume support for UTF-8.
ok in that context use error or ok, just dont use color as ~10% of ppl have an issue with seeing colors perfectly (that includes people with epaper displays)
I really wish you wouldn't. All the rinky dink colors and animations screw with the CLI output when you don't correctly detect whether the user's running the app interactively.
Keep it plain text. Regular, old, boring output is good.
I agree. So many TUIs from webshit devs don't even bother to call isatty, let alone check terminfo to see if ANSI escape codes are even valid for this terminal.
But modern open source subscribes to Mao's Continuous Revolution Theory. Calls for some measure of stability and sanity are usually dismissed with some form of the argument "awwww, is poor diddums afwaid of a widdle change?" Or in this case, "still using vi on your ADM3A, old timer? Our software is not for you."
Emacs on a Link MC5, although something doesn't like how the terminal handles flow control. I'm not sure if it's the O/S, the UART, the cable, or the terminal, but I have issues with I/O corruption. Even something a simple as a directory listing will get messed up, and on both FreeBSD and Linux, so maybe that rules out the O/S. Oh well. I'll figure it out some day.
I'm very impressed. This isn't a paper so much as a monograph. And I'm very inclined to agree with the results of this study, which makes me suspicious. To what journal was this submitted? Where's the peer review? Has anyone gone through the paper (https://arxiv.org/pdf/2506.08872) and picked it apart?
I love the parts where they point out that human evaluators gave wildly different evaluations as compared to an AI evaluator, and openly admitted they dislike a more introverted way of writing (fewer flourishes, less speculation, fewer random typos, more to the point, more facts) and prefer texts with a little spunk in it (= content doesn't ultimately matter, just don't bore us.)
So long mode is the best fix for this issue but it disables syntax highlighting and line numbers. Vscode can handle long lines just fine without disabling anything.
They also forced us to waste relatively valuable vertical screen space on the task bar, taking away our ability to move it to the left or right screen edges.
I wish there was a big, friendly "buy now" link that would get me the print book and EPUB file. The site promotes the book. I'm not sure why they don't make buying it stupid simple.
