this post was submitted on 11 Jul 2026
83 points (91.9% liked)
Programmer Humor
32231 readers
649 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, I'm not going to downvote, but something in my brain is screaming "lossy compression!" and so you might say I'm at least wary.
/dev/null compresses everything perfectly. The hard part is recovery and is left to the reader.
infinite compression ratio :o
It is a tremendously stupid idea, which is why I found it funny (also, it's one of those things where name came first and inspired the rest).
But, to take it seriously for a moment (and I'm not trying to defend it, not a fan of LLMs as most of the people here), is it necessarily lossy? I mean, you basically have to include the 5Gb large model for it to work, and you just move the data from the file to hoping the summary can trigger a correct combination of parameters.
I didn't run any larger tests, and I assume that if you managed to keep the API/function names and behavior, the summary would be actually longer than the actual implementation in most cases anyway, so it's probably not even a compression (especially if you include the model).
It's just a food for thought, it's definitely a bad idea to do something like this, to the point where I'm pretty sure you could get millions from investors if you made a startup working on something like this (and that one already exists), but I do honestly wonder if the fact that you kind of have the data in the model would still count as lossy.
When I first saw this, I thought it was obviously a toy to learn something and as an excuse use an LLM. I wasn't sure if the use of an LLM was serious or not (e.g. did the originator know the limitations); however, I did take it seriously for the sake of argument after one of the other comments talked about compression.
I decided that I actually like this project quite a bit as an example to introduce information theory to students. What the compression comment gets wrong imo is that compression is about taking an instantiation of information, reducing it to a minimum set of measurable units of infirmation (i.e. bits) to recreate that instantiation.
What this would aim to do, assuming it works (or rather what a competent human could do) is reduce the instantiation to a set of information that can recreate an instantiation of said information (changing the problem into a non-unique inversion problem) to recreate functionality but not an exact duplicate of the input. To the degree that the description converges on one result then one would end up with the exact same input; however, as human language is notoriously verbose and imprecise this would not compress anything.
Kudos.
That's the joke.