The whole point is that random character sequences are often valid Perl
When I read the headline I also assumed “valid Perl program” meant it did something interesting. I was expecting to read an article about an interesting image to text conversion process that produced non-trivial Perl programs.
“Feeding garbage to OCR” is a really boring way of generating text. I was assuming it would be something more interesting, like creating a symbolic representation of the splatters and generating text from that. Using OCR is basically piping /dev/urandom to perl and seeing what happens. The fact that they’re valid perl programs is worth a laugh but the generation method is totally uninteresting.
Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.
It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.
I think the author's primary point is, "Merging changes sucks, don't make your users do that," with a corollary: if your program loads configuration from a directory that is only populated by the user, there's nothing to merge and thus never any merge conflicts. Case in point: /etc/polkit-1/rules.d. I can add whatever rules files I want in there and they're never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That's a hell of a lot easier than merging conflicting changes to code/configuration.
Additionally, switch performs extra sanity checks that checkout doesn't, for example switch would abort operation if it would lead to loss of local changes.
What checks? Under what situation does checkout lead to loss of changes? If I make changes and attempt to checkout a ref that would overwrite them, I get the following error:
error: Your local changes to the following files would be overwritten by checkout:
some/file
Please commit your changes or stash them before you switch branches.
Aborting
To my knowledge it's not possible to overwrite changes when switching branches/refs (git checkout <ref> without any other arguments or flags) so I guess what the author really means is, "If you use checkout incorrectly you can overwrite local changes." As far as I can recall I've never accidentally git checkout <ref> <some/file> so I don't see a reason to retrain my muscle memory. I do use git restore since it's behavior is a lot more obvious than checkout/reset though sometimes I still use git checkout <ref> -- <some/file> because muscle memory.
Scenario: I'm in the middle of writing a new feature.
Boss, to me: "Shit broke. Go figure it out."
Me, thinking: I'm in the middle of doing some complex work. If I commit/stash and close the open files, it will take a day for me to remember WTF I was doing.
Me: "Oh look, worktrees! I can leave my workspace intact with all the files open, pending changes, test results, terminal output, everything! And just create a new worktree to checkout the production version and debug! I'm saved!"
Also setting up a worktree is really easy. git worktree add ../hotfix prod-branch && cd ../hotfix and get working. Though in reality it's cd ../hotfix && git checkout prod-branch because I've never needed more than one secondary worktree.
The presence of semicolons is not a language killer.
I'm not saying it is. But every time I have to work in a language that requires semicolons I'm constantly forgetting them and constantly reminded of how nice it is to not have to care in Go.
I’m a cishet white dude so I experience effectively zero discrimination directed at me, but I am on the spectrum.
I guess basically everyone I regularly interact with either is also on the spectrum or has intense interests regardless, or is used to people like that. Though TBF I have learned to not get intense if I’m in public talking to random strangers. But if someone asks me a question like, “how do computers work”, I will answer at great length.
I’ve written programs in C. I’ve written programs in assembly, for x86 and for microcontrollers. I’ve designed digital logic and programmed it into an FPGA. I’ve built digital logic circuits with transistors.
I’ll still take Go over C any day of the week. If I’m doing embedded, I’ll use TinyGo.
Ethan @ firelizzard @programming.dev Posts 7Comments 206Joined 2 yr. ago
When I read the headline I also assumed “valid Perl program” meant it did something interesting. I was expecting to read an article about an interesting image to text conversion process that produced non-trivial Perl programs.