3 ms·

>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() tha

by batista 14y ago

>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard. Simple by design might be hard, but "simplify in retrospect" is easy. It just needs you to be willing to sacrifice meaningless backwards compatibility and inflict some temporary pain (rewriting stuff dependent on it) for the benefit of tomorrow. >So you think "ls" has too many command-line flags; how are you going to cut the number in half? Which ones do we keep and which ones get axed? How are you going to provide for all the same use cases that those 35 flags were added for? You don't. Fuck ALL those use cases. Keep only those that are used a large percentage of the time by the large majority. For those that need the extra juice, let them use the old, convoluted version. You don't have to have "ls" be a be-all-end-all. Have both ls AND a power-version if anyone cares to maintain the second. And sure as hell, don't keep competing or duplicated flags just for backwards compatibility.

haberman 14y ago
> You don't. Fuck ALL those use cases. Keep only those that are used a large percentage of the time by the large majority. Disagree completely. Because if you do that, the moment someone comes along and needs something that you're unwilling to provide and can't be layered on top of your work, they're going to make their own "ls" that overlaps a lot but satisfies their need. If we have 15 different "ls" implementations, we're back to more overall complexity. Basically if you want to write code that lives at the bottom of the stack, you have to think of the most crazy hard-core shit that anyone might want to do with your code and how you can accommodate that. Two fantastic examples of software that achieve this in spades: Lua and zlib. Both let you plug in your own memory allocator instead of malloc() if you really need to. Both let you perform your own I/O if you really need to.
- jacktoole1 14y ago
  Heartily agree on Lua. Embedding lua was one of the best library experiences I've ever had. The implementation and language is small and simple, and I think many people undervalue that. Compiling it was as simple as dragging the source files into Xcode (not an ideal long term solution, but quick and easy to compile to any target, and at 10k lines of code, reasonable compile times). As a comparison, I spent 3 days trying to compile Spidermonkey for ARM (with eventual success attributed mostly to finding a useful patch on github).
- bewareofdog 14y ago
  "crazy hard-core shit" This is the problem. When basic understanding of a system (e.g. I/O) is viewed as "crazy hard-core shit" we are in trouble. You do not even need ls in today's UNIX. Globbing, printf, echo and stat can do it all. And if necessary it's easy for the user to write her own custom utilities for displaying file or directory information from the stat struct as long as she is provided with good documentation for the standard C functions. If you don't know how to do these things then you need to learn. And I say that as a dumb end user who can do things in UNIX that apparently most programmers of today cannot or will not because it's "too hard". To me, learning all these high level scripting languages is crazy hard core shit. It would take me forever. They are large and complex. Meanwhile I can do things the short, simple way. And learn about "crazy hard-core shit" like basic I/O at the same time.
- deleted 14y ago
  [deleted]
d0mine 14y ago
People might use only 10% of features that your program provides but the problem is that different people use different 10% (it or similar was said about MS Word bloat).
- batista 14y ago
  Yes, by Joel Spolsky. Only it's not 100% accurate. Some people DO use a different 10%, but the grand majority uses the same 10% (and occasionally has a need for something outside of that).
cturner 14y ago
Users need to be able to get the functions they need. But the unix-way provides a mechanism for getting ls plus the functionality you want: have a shell macro run the minimalist ls and pipe it through a formatter. Unfortunately, although unix scripting was good by the standard of its era, it's still not particularly good. Unix as we know it hints at great ideals that are achievable but lives up to them poorly. As a result, early packagers shoveled hacks into existing layers and we live with the result. Evidence: arguments in commands like cat and ls; the crudeness of ps to represent the process table; inability for scripts to access unix systems calls; kitchen sink shell interpreters. Why do we look to shell interpreters for command-line history? That should be done in a separate layer closer to the terminal. Had it been, we'd have two small unbloaty layers. Instead we have tcsh, bash and zsh. You could have your ls formatting macros live in your personal terminal emulator and you'd never need to copy .bashrc hacks to each system. The formatter code might not even live on the remote system, it might be part of the terminal. I suspect you could lay [racket scheme] + [a transform that converts python style whitespace code into parens code] over a unix that has /proc, and use that to create the layers you needed. With that in place, you could then start taking noise out of the unix tools and work towards a smaller distribution. Plan9 is talked of as "unix done right" but I'm not convinced. Some things it does well, but it has lots of baggage. For example, you have to buy into their desktop to access the OS. How is forcing me to use a mouse and a particular tiling window manager a necessary part of a better unix experience? I'd like to play with a plan9 fork where the only user interface assumption was a terminal, and where you could get a secure connection into that terminal. (Too inept to do it myself so far, but keep playing with idea of running it on linux, ssh'ing to linux as the jump box, and then telnetting into the plan9 instance. Still - what a hassle)

by batista 14y ago

haberman 14y ago

> You don't. Fuck ALL those use cases. Keep only those that are used a large percentage of the time by the large majority. Disagree completely. Because if you do that, the moment someone comes along and needs something that you're unwilling to provide and can't be layered on top of your work, they're going to make their own "ls" that overlaps a lot but satisfies their need. If we have 15 different "ls" implementations, we're back to more overall complexity. Basically if you want to write code that lives at the bottom of the stack, you have to think of the most crazy hard-core shit that anyone might want to do with your code and how you can accommodate that. Two fantastic examples of software that achieve this in spades: Lua and zlib. Both let you plug in your own memory allocator instead of malloc() if you really need to. Both let you perform your own I/O if you really need to.

jacktoole1 14y ago
Heartily agree on Lua. Embedding lua was one of the best library experiences I've ever had. The implementation and language is small and simple, and I think many people undervalue that. Compiling it was as simple as dragging the source files into Xcode (not an ideal long term solution, but quick and easy to compile to any target, and at 10k lines of code, reasonable compile times). As a comparison, I spent 3 days trying to compile Spidermonkey for ARM (with eventual success attributed mostly to finding a useful patch on github).
bewareofdog 14y ago
"crazy hard-core shit" This is the problem. When basic understanding of a system (e.g. I/O) is viewed as "crazy hard-core shit" we are in trouble. You do not even need ls in today's UNIX. Globbing, printf, echo and stat can do it all. And if necessary it's easy for the user to write her own custom utilities for displaying file or directory information from the stat struct as long as she is provided with good documentation for the standard C functions. If you don't know how to do these things then you need to learn. And I say that as a dumb end user who can do things in UNIX that apparently most programmers of today cannot or will not because it's "too hard". To me, learning all these high level scripting languages is crazy hard core shit. It would take me forever. They are large and complex. Meanwhile I can do things the short, simple way. And learn about "crazy hard-core shit" like basic I/O at the same time.
deleted 14y ago
[deleted]

d0mine 14y ago

People might use only 10% of features that your program provides but the problem is that different people use different 10% (it or similar was said about MS Word bloat).

batista 14y ago
Yes, by Joel Spolsky. Only it's not 100% accurate. Some people DO use a different 10%, but the grand majority uses the same 10% (and occasionally has a need for something outside of that).

cturner 14y ago

Users need to be able to get the functions they need. But the unix-way provides a mechanism for getting ls plus the functionality you want: have a shell macro run the minimalist ls and pipe it through a formatter. Unfortunately, although unix scripting was good by the standard of its era, it's still not particularly good. Unix as we know it hints at great ideals that are achievable but lives up to them poorly. As a result, early packagers shoveled hacks into existing layers and we live with the result. Evidence: arguments in commands like cat and ls; the crudeness of ps to represent the process table; inability for scripts to access unix systems calls; kitchen sink shell interpreters. Why do we look to shell interpreters for command-line history? That should be done in a separate layer closer to the terminal. Had it been, we'd have two small unbloaty layers. Instead we have tcsh, bash and zsh. You could have your ls formatting macros live in your personal terminal emulator and you'd never need to copy .bashrc hacks to each system. The formatter code might not even live on the remote system, it might be part of the terminal. I suspect you could lay [racket scheme] + [a transform that converts python style whitespace code into parens code] over a unix that has /proc, and use that to create the layers you needed. With that in place, you could then start taking noise out of the unix tools and work towards a smaller distribution. Plan9 is talked of as "unix done right" but I'm not convinced. Some things it does well, but it has lots of baggage. For example, you have to buy into their desktop to access the OS. How is forcing me to use a mouse and a particular tiling window manager a necessary part of a better unix experience? I'd like to play with a plan9 fork where the only user interface assumption was a terminal, and where you could get a secure connection into that terminal. (Too inept to do it myself so far, but keep playing with idea of running it on linux, ssh'ing to linux as the jump box, and then telnetting into the plan9 instance. Still - what a hassle)