The modern app
58 points by kreeft
58 points by kreeft
It's missing the terminal pane with a TUI app with bad contrast! /joke
When it comes to enshittification in code editors, I'd say I disagree. "Large" IDEs like JetBrains or Visual Studio never really ran well enough on the scrappy hardware I owned...back then, so I can't speak about those. So I ended up more towards things like Notepad++, VSCode, Emacs or terminal editors.
In that space it's pretty much the same(well I guess not VSCode), but with treesitter and language servers to share the good stuff. But I would like to have nice things...showing images or a nice file explorer. I feel like maintaining such an editor is a hard thing to sustain in this economy.
I like me some nostalgia as well, but I found tranquility in appreciating what I already have and in OSS that aligns more with what I like, even if it's (a lot) less popular.
I very much enjoy the fish in the footer. Just in case you missed it and wanted to go enjoy it as well....
I read this domain as "D-Bus Hell"...
I feel like there’s at least one comment about thinking it was D-Bus Hell or DBU Shell on every dbushell.com submission. Which happen quite frequently. Honestly I’m getting to the point where I’m contemplating flagging them off-topic.
Well… based on https://lobste.rs/domains/dbushell.com it’s actually not that often, and not quite every time.
it's often enough that I've considered writing an article on whether or not D-Bus is in fact, hell (or not).
Also for the record my domain (and name) predates D-Bus project :)
Also for the record my domain (and name) predates D-Bus project :)
Man, that must make these kinds of comments at least a bit frustrating! Reminds me of that scene from Office Space.
For the record, how am I supposed to read it?
I don't think that every time I see it, but this time the title steered me that way. I was looking for something about D-Bus when I first started reading.
I think it's inevitable. Everyone who's ever used D-Bus will read dbushell.com as D-Bus Hell. I did too.
It's ironic that the worse this trend gets, the better Emacs looks (to take my personal "fortress of solitude" as just one example). I almost want VSCode to be as bad as possible, so that I can feel good about my choices in life :P.
Also, I'm curious whether this line from the post is tongue-in-cheek:
Remember when they made entire video games on a 32 KB floppy disk? Those were real developers.
Hopefully we don't need to actually have arguments about what makes someone a "real" developer, as that will quickly degenerate into a pissing contest. "Oh you think you're a real developer because your video game fits on a 32 KB floppy? My video game fits on a 4-byte abacus!" At the same time, I feel there's some truth in the observation that programming ain't quite what it used to be. And the programmers I admire most these days – and hope I can emulate more as I get older – are the ones who know their way around the lower levels of the stack (e.g. Casey Muratori or Andrew Kelley).
...And the programmers I admire most these days – and hope I can emulate more as I get older – are the ones who know their way around the lower levels of the stack...
You know, i hadn't thought about the good dev criteria being about competency levels at levels of the stack...but i can see that being one solid measure for sure.
I was thinking their comment meant more like devs who are more efficient about leveraging the available resources (be they hardware, etc.). One could argue that any dev can make an app that is bloated...but a good dev can make an app that doesn't need loads of RAM to run a very basic app, etc...Kind of like a top notch soccer player can achieve alot without exactly needing a specific cleat/shoe...the player is good regardless.
It’s as good a time as any to reread the Story of Mel, a Real Programmer
The story has become less impressive to me the longer I've spent working in a professional environment.
"It's a fucking blackjack demo, Mel, just use the compiler and get on with some other work already instead of hand-placing instructions on the drum" would probably be my take today.
That's the other side of old compact ultra optimized programs, they were slow to write, hard to modify... I could write a blackjack game that worked as well as Mel's (presumably writing text representations of cards to an output stream) in Emacs using just the Go stdlib, and it would take me a couple hours. How long did it take Mel? How long did it take the author to figure out the code well enough to know where to add the proposed "fix" for the cheating logic? In my day job I regularly write little tools that would have been a $100 standalone utility sold in Byte back in the day... and then I throw the tool away when I'm done.