codesections @codesections@fosstodon.org

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.

https://github.com/ppelleti/json65

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

https://redis.io/topics/protocol

(err, ^^^ was intended to be a reply to @IanTester. Not sure how I messed that up)

> 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

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

I just observed the following exchange in a bug tracker:

user: *reports bug*
a maintainer: AFAIK, this is a known issue

something about that strikes me as ... circular? ...tautological? I'm not quite sure. Maybe it's that is raises the possibility of something being an unknown known issue?

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?