3 ms·

> 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

> 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]

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]