I want to be able to tell my friends why #mastodon is better than the birdsite, so I wrote a thing: "Mastodon Is Better than Twitter: Elevator Pitch"
https://www.codesections.com/blog/mastodon-elevator-pitch/
I want this to be as persuasive as possible to outsiders, so I'd appreciate as much feedback as possible from Mastodon users
This is the sort of programming ethos to which I aspire:
> I was watching TV, and there was a commercial which proclaimed, "It's time to do what you want!" I replied to the TV, "It's time to write a JSON parser in 6502 assembly language?" Somehow I don't think that's what they had in mind, but the TV is right, I should do what I want.
>
> So, here is my JSON parser.
@codesections Did you know that C compilers are still only required to support up to 4095 characters on a line of source code? If you have a line of code in your C program that's longer than that, the standard doesn't guarantee it has to be compiled correctly :)
TIL: many #pascal compilers allowed identifiers of any length, but only examined the first 8 characters to determine what the identifier pointed at.
So `foobarbaz` and `foobarbazqux` are both valid, but refer to the **same** variable!
What I _didn't_ learn was why anyone thought this was a good idea. I assume it was for performance reasons, since Free Pascal doesn't do it anymore (https://wiki.freepascal.org/Identifier#Significant_characters) and 8 makes me guess it has something to do with memory representation.
Anyone know?
I *really* like the Redis protocol, RESP. I don't even use Redis itself all that often, but I've implemented RESP (or subsets of it) multiple times – it's just a great format for programmatic communication
> Hmmm, it's never good when a new #linux kernel is released just two days after the previous one.
What, you'd prefer that they *not* release a fix? :D
(Obligatory xkcd: https://m.xkcd.com/463/ )
I missed this post when it came out in December: In Defense of Blub Studies, https://www.benkuhn.net/blub
Some really excellent points:
> Blub studies is a never-ending treadmill of engineering know-how. It’s the fiddly technical details of how Git stores data, or how Postgres locking semantics [work], or why pip install failed this time.…Blub studies is more generalizable than it seems, and has its own way of compounding over time, too. That makes it a lot more useful than you’d expect
TIL: #zsh was released in 1990, barely a year after #bash.
(I would have sworn that Zsh was at least a decade younger. But I would have been _confidently_ wrong, which is the absolute worst kind of wrong to be!)
citations:
zsh: https://en.wikipedia.org/wiki/Z_shell
bash: https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29
git wip: What the heck was I just doing? https://carolynvanslyck.com/blog/2020/12/git-wip/
No, #google, when I said "irclog", I certainly did _not_ mean "IRS login". You're getting to be as bad as Clippy ever was.
I regret my !g
Dear #Mastomind: Any guidelines on E-Ink / B&W/grayscale / low-refresh rate app design / UI/UX?
I've recently come into possession of an e-ink book reader, and am discovering the joys (seriously) and limitations (dittos) of e-ink displays and software designed for them.
I've just begun looking for any information concerning design guidance for e-ink devices, and am coming up very short. If you're aware of any such resources please respond to thread.
Boosts welcomed.
#eink #uiux #AppDesign #SoftwareDesign #Interfaces #BlackAndWhite #LowRefresh
Are there any programming languages/runtimes/frameworks with a "garbage collection" strategy of just never collecting any garbage? (During program execution; obviously the memory would be freed when the process exited)
It wouldn't work for _most_ use cases, but for extremely short lived programs (e.g. CLI scripts) it seems like this would be an easy way to avoid the stop-the-world costs of a GC without any memory safety risks.
Does this exist? Or am I missing some reason it'd be dumb?
Lawyer-turned-programmer with an interest in web development, open source, and making things as simple as possible.