|
|
|
|
|
by somedudetbh
1324 days ago
|
|
It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" by people who presumably use Unix? Maybe it's a philosophy like "Don't do sins" is a philosophy of Christians? More of an aspiration than an actual practice? I can't really think of any Unix programs in common use that do one thing well. Inevitably, they grow to redundantly include features that other programs have. If anything can be said to be the actual lived Unix philosophy it's probably something like:
1) Try to make your programs communicate using text, where the 'record' is separated by a newline.
2) If you have a choice between making a program a little more friendly to use, or making it's text communication a little simpler to compose with, go with the second option. E.g. if there's nothing to output when a program runs don't output "Nothing to output", just output nothing. I don't think Emacs really fits with the unix philosophy, whether my version or the common version, at all. One of the main things I like about emacs is that it's like a vision of an alternate computing universe, where we assume that we're operating in a giant image that's meant to be programmed and customized all the time. What if most of your work was done in a LISP repl with a bunch of UI tweaks? It's like using a research project from a 70s or 80s "Future of Computing" lab that never actually shipped, except it did ship. It feels like it should have a lightpen attached. I don't even really think it's particularly practical to use emacs at this point, I just like this vibe and reminder that nothing about the way we use computers was inevitable so much that I stubbornly still use it. |
|
It's worth a read, but do bear in mind that the whole Unix mindset is an evolutionary dead end.
I mean the sad fact is that we're slowly learning that Unix with all its baggage is like an internal combustion engine: it seemed like a good idea at the time, so we adopted it, and now it's ubiquitous and it's a race to move on to something else before the bill for all the damage it's caused civilization comes due. People favor comprehensive, feature-rich programs over small composable ones. The Unix process model and fork(2) in particular break down utterly in the presence of threads. It took fucking forever in tech-industry time to come up with a single solution for dynamic linking, something Windows and Amiga OS solved in the fucking 80s. Linux is only just now getting an async I/O solution that begins to approach the robustness and comprehensive of what VMS had in the 80s and Windows NT had in the early 90s; before that, it went with the Unix assumption of "disk I/O takes zero time to execute, and you can poll for everything else!" You want to know what else Windows had in the early 90s that Unix, and especially Linux, only caught up with in slipshod fashion later? ACLs. One reason why Windows got an EAL4 certification under the Common Criteria well before Linux.
Postel's law was wrong (you want strict protocol conformance to avoid surprising behavior), ASCII text protocols were a mistake (parsing and unparsing them just converts electricity into waste heat), piping together unstructured blobs of text is NOT robust and programs should communicate via objects with checkable types... Just, on and on, mistake after mistake.
And C. Just... C. If null pointers were the billion dollar mistake, how many trillions' worth of damage were done by the totality of all C's foibles, pitfalls, and undefined behaviors? Honestly if we do nothing else, we should halt ALL greenfield development in C. It's unsafe at any speed.