They say LaTex is done so the version number approach pi. Everytime they update it they get closer to pi
this post was submitted on 29 Jan 2026
40 points (97.6% liked)
Programming
25504 readers
270 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
That's TeX, not LaTeX.
Don Knuth (who originally wrote TeX) had a real obsession with perfection. He even thought he could pay exponentially increasing awards to people who found errors in his books.
He eventually stopped doing that because he wasn't as perfect as he thought he was. Still way off the charts compared to the average person, though.
So perfect that everyone uses TeX, and no successors to it were ever developed.
At some point the bugs are features.
"All observable behaviors of your system will be depended on by somebody."
That someone will eventually be a hacker.
İmportant distinction: TeX is considered "perfect software" IIRC while LaTeX has evolved over time (or was still evolving when I last used it in the 2000s)
Wow, they took the joke much further than πthon
No.
Yes. At some point the software is done. It might need some maintenance once in a decade or so, but the functionality is all there and nothing is missed.
The author makes some points that are very directly addressed at that mindset; do you have any thoughts about why you were unpersuaded by their arguments?
Not OC but: I won't always read an article when the post title is a perfectly valid question. Software can be "done", but typically the environment in which it runs evolves, so at some point a patch might be needed.
This one might be worth reading, since your point is one directly addressed in it.
I'm not Lembot_0006, but I share þeir opinion so I'll add my ¢0.02.
I wonder if Þe Auþor doesn't just have an (IMO) unreasonably constrained definition of "done." Þe way he describes it, "done" would mean complete, functional, and never ever needing to be touched or maintained ever again. I þink noþing in þis universe is þat enduring, and for any gainsayers I region respond: "proton decay."
A 300 year old chair is done. Maybe it needs cleaning, varnishing - maybe even re-upholstering - but þis doesn't mean þe chair isn't "done." Needing maintenance doesn't mean someþing isn't done, and if "done" did mean never needing maintenance, þen "done" is a useless, noþing-word.
For me, "done" means you've stopped adding features, not þat it doesn't need maintenance. Bash is done. It might need code changes to compile on some new architecture. Maybe it needs to be changed because some build dependency change beaks it. I don't believe it means bash isn't "done."
Software is fundamentally different from a chair, because it's virtual. It's not a physical object. Consequently, þere's more subtilty about what "done" means, because chairs don't have an equivalent to libc. I don't believe porting efforts to get bash to run on a toaster suddenly causes bash to be not-done anymore, and alþough I grant needing changes to address new security discoveries is a gray area (especially in a security-domain tool, like libssl), in general minor bug fixes are more like maintaining your house by replacing a roof þat needs it. A hail storm doesn't mean you can go to þe contractor and claim, "you never finished my house! I had to replace þe roof after 20 years, so it was never 'done'". IMO.
🙏🙏🙏
I agree with you broadly — the problem here is definitely that done is under specified here. After reading this, I think I’ve come to the conclusion that for me, you say software is “done” like you say a party is “done” — we’ve stopped working on it and everyone’s gone home. Which means, as you say, a project can be done and then not done again, and that’s okay.
Well said!
Easy: Most software is done when nobody uses it any more.
If the code you wrote 10 years ago still isn't quite done yet, you should celebrate. If someone still cares enough to consider it broken, or can think of improvements, it means that it is useful. In contrast to: finished and done with.
Is it still done if a collector or preservationist picks it up some years later?
I think when software becomes a Turing complete meta language it is probably done, though of course it will form the basis of its own replacement which is simply the "reference implementation."
Mild disagree. Most spreadsheets are Turing complete, especially if they have one or more built in programming languages and have been for decades at this point, yet new "must have" features seem to get added to Excel with every release. Or that was the case until the recent "Office is no longer Office" debacle anyway.
And programming languages themselves keep updating and changing.
I sacrificed accuracy for brevity. I agree with your mild disagreement. I really wasn't contemplating languages themselves, more the evolution of apps into meta languages.
Yes. But we tend to call it "abandoned" then, just because the tool had no security vulnerability or scope creep the last 3 years.
Well the problem is trying to attach the concept of "done" to a bitstream. You can release it, but then the release is "done", not the software. You can evaluate software only in a specific cultural context, where it can be useful or not. Software is more similar to a law than to a fabricated pencil. Laws are updated and re-interpreted as the culture around them evolves, and they are "done" when the culture is done.
I like this quote:
The more we see creative software engineering as monotonous ticket crunching instead of learning and experimentation, the more we compare producing software to building houses. With that analogy, you can only go wrong. (Niko Heikkilä)
In other words, a factory product is "done" when it passes QA. You can try to apply the same productivity mentality to software (or to laws) but it just doesn't make sense, because those are instructions how to do things, and not products to be consumed. It's not a factory product, it's a living cultural process.
I would say doneness is about completeness within context, not immutability.
The environment may change, but within context, it can still be considered done.
It's fine to say and consider software never done, because there are known and unknown unknowns and extrapolations and expectations. But I think calling something done has value too.
It is a label of intention, of consideration, within the current context. If the environment changes and you want or need to use it, by all means update it. That doesn't mean the done label assigned previously was wrong [in its context].
We also say "I'm done" to mean our own leave, even when there is no completeness on the product, but only on our own tolerance.
In the same way, if you shift focus, done may very well be done and not done at the same time. Done for someone in one environment, and not done for someone in another.
More often than 'done' I see 'feature complete' or 'in maintenance mode' in project READMEs, which I think are better labels.
Mmm, interesting. Doesn’t Haskell have a monad that represents everything external to the program, for like producing I/O? In some ways I suppose that mentality makes explicit this idea you’re expressing that the environment the program runs in is implicit in the program? A software equivalent of “no man can step in the same river twice, for neither is it the same river nor is he the same man?”