💾 Archived View for zaibatsu.circumlunar.space › ~krixano › phlog › 120219_Re_Yargo_Unix.txt captured on 2020-09-24 at 01:56:15.
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
-- Reply to Yargo concerning Unix Philosophy -- Yargo[1], don't think you are so special that I'd only call you out, I also called out Modern Programming Philosophies for focusing more on unproven programming practices rather than software's end product - however, I've recently discovered that that particular post didn't have the correct permissions set so people may not have been able to read it. I've changed the permissions so it should be readable now. What yargo fails to mention is that he admitted to me prior that his chat terminal application used an (inferior) design of files rather than a traditional client-server model that utilizes Unix-Domain Sockets because the former was less complex. But the fact is, the client-server model is better for the user in almost every way. If you don't know, yargo's chat application has a tail mode. Because yargo uses files and believes in the Unix philosophy so much, he uses the "tail" program so the user can get updates to this chat file. However, when you send a message, you are automatically booted out of tail mode and have to go back into it. Additionally, when the user has a half-typed message and another user sends a message, that sent message shows up on the end of what you've already typed, making it harder to see clearly what you are typing. Meanwhile, a friend of mine created a chat program using Unix-Domain Sockets that has *none* of these problems. Of course, you don't need a client-server model to fix these problems, but you *do* have to re-implement something that will track updates to the chat file, display them, and lock this file when needed. See the problem here? By trying to be simple and use files and the "tail" program, he both made the user-interface worse *and* made it harder for him to improve the user interface. (he also made the program take longer to develop because he didn't do it correctly in the first place, wasting his precious time that he cares so much about!) But guess what his excuse for not improving the user interface is? He doesn't want to do file locking because he wants to keep the program "simple"! But everyone not fooled by the Unix philosophy knows that "less complex" and "simple" just means easier and quicker for the programmer to program - even at the expense of the user. "less complex" and "simple" means to half-ass the job. What these people don't realize is that everything needs to be in balance. But they hold onto a Unix philosophy that is about simplicity even when it hurts the user. And I say all of this because we *really* need to get our act in gear. I *am* being a little mean, but if I have to be this person for people to realize the gravity of our situation, then I will be. Some other things that are conveniently not mentioned: 1.) The Unix philosophy of oversimplification at the expense of the user has metastasized to a great portion of the programming industry, in such a way that tools that would primarily be used by actual users who are not programmers are adhering to these Unix philosophies (including piping, more on this later). 2.) The majority of users don't use Piping, and I would bet the majority of Programmers don't either. Why? Because Piping is a terrible design and is unnecessarily confusing and unintuitive. Of course the Unix developers didn't know this when they created it, but characteristic of the Open-Source and Unix communities, bad designs like this grew and spread their cancer to more of the programming industry. So it's ironic that yargo would say the Unix Philosophy "implies that users at the minimum know how to build pipes at the command line" and yet say that Unix philosophy isn't the problem! 3.) Unix philosophy was decent at the time (at least, it would have been if they implemented the practices correctly, but they didn't as far as I'm aware). But it's been over 30 years, don't you think we have better techniques now? Don't you think we would have learned by now that Pipes are not good - that there are more intuitive and easier things than pipes? (I'll have an example of this coming up soon, a shell I'm working on called Paled) Let's also not forget that Unix and it's philosophy was created so early in the industry's lifetime when many things were different (including no/uncommon graphical-user-interfaces), that to hold onto that means you haven't had any good ideas for the majority of the industry's lifetime - that there's been no progress (which might actually mostly be true, aside from a couple of exceptions, but anyways...) 4.) The Unix philosophy isn't just "to have simple tools, which do one job well and can be combined for complicated tasks". This is just the most-referenced part. There's actually more to the philosophy, and different versions of it too. But let's not conflate the technical or defined definition with what's out there in the real world. The real world (descriptivist) definition is just as valid as the defined (prescriptivist) definition, and the fact is that from the start of Unix, Unix developers were hostile towards users. And it continues to this day... People expect you to read a badly-written manual because they can't be bothered to answer simple questions, so that should tell you something (that many programmers are bad writers, and that programmers are selfish and don't care about their users). For the longest time the Unix developers expected you to read the source code of the program because they couldn't be bothered to write any documentation. The Unix developers half-assed things so much that they wrote easily-fixable bugs in what little documentation they did eventually create instead of just fixing the bug, even when at the time backwards-compatibility wouldn't have affected many people (due to unix being so new). 5.) To say that coding philosophy can never be the problem is a pretty idiotic statement to make. If my coding philosophy was "care about the programmer's time more than the user's", then it's obvious that that's a problematic coding philosophy, right? Don't buy into these often-said excuses that Unix and Modern programmers are continuing to spat at their users.... Users need to hold us programmers to higher standards if we are going to actually improve in anything. The low expectations of users should tell us something - it should tell us programmers that we are pathetic, that we can't get our act together, and that users have zero faith in programmers creating good software that is easy to use and doesn't bug out all the time. It's sad when users have so low expectations that the common belief is that computers are untrustworthy and unstable - and that's because they *are*, and *we've made them like that*. 6.) For you to claim that programmers aren't "grasping the importance of good definition and implementation of interfaces -- for APIs and functions as well as CLI/GUI.", yet hold onto the same philosophy that was created at a time when not much in the way of good design had been proven yet is pretty ironic, and it shows the fallacy in your thinking. Not many of these modern "coding practices" have even been proven, so what makes you think that when unix was created we had provable programming designs. 7.) The problem with the unix philosophy is in the name "philosophy". You should be able to figure this out yourself. 8.) Yargo, you're right about at least one thing... poor education. Instead of teaching programmers to care about the users, do actual research before buying into coding "philosophies" and "practices", and teaching how to effectively write programs that run as efficiently as possible by utilizing things like bulk-instantiation (arrays, memory pools, SOA and AOS, etc.), we are teaching them to write "clean code" and "OOP" and fancy marketing terms! For people who are curious about learning what early opponents to Unix thought about it, you should read "The Unix-Haters Handbook", but skip the first chapter (because it's kinda a load of crap). [1] gopher://zaibatsu.circumlunar.space:70/0/~yargo/clog/xv-bad-interfaces-reply-krixano.txt