Hacker News Reader

Comment by coffeemug | Hacker News Reader

Deciding whether a program does "one thing well" is a matter of granularity. `ls` with its 38 flags is absolutely tiny compared to, say, finder, which displays multimedia previews, allows you to connect to remote servers, and probably does a bazillion other things.

Yes, `ls` isn't perfectly clean in a mathematical sense, but it's still tiny compared to modern software, and passing a couple of flags for common tasks now and then is far more convenient than writing `ls | map ... | sort ...`.

Unix is not a mathematically perfect Unix, but it is most definitely an acceptable one.

View on HN

The article hinges far, far too strongly on the "do one thing" part of the definition, and largely ignores the "do it well". The optional flags to 'ls' are there to help "do it well".

If we're going to use the overzealous puritism of the article's definition, why not go further? My keyboard driver isn't unix-ey, because I can use it to input a 'k'. Or a 'K'. Or a lot of other characters. The argument in the article would mean that for a keyboard driver to be unix-ey, it should only output a single character. Nevermind the fact that I have 104 options on the HID at my fingertips, if my driver allowed that, it wouldn't be "doing one thing"!

> The optional flags to 'ls' are there to help "do it well"

And by default `ls` does it's job well.

By default, `ls` doesn't even list all files. So no, it does not do its job, let alone 'well'.

It hides hidden files by default. It would be bizarre if it didn't do that.

Ah, hidden files. That's files with "-hidden" in their name, right?

In an alternative universe, Dennis Ritchie would have fixed the bug and yes, the current behaviour would indeed be seen as bizarre; as it actually is on systems which didn't have this bug to turn into a feature.

> My keyboard driver isn't unix-ey, because I can use it to input a 'k'. Or a 'K'. Or a lot of other characters.

You're missing the article's forest for its trees. The author is claiming that "filter or sort the items in a list" and "get a list of files in a folder" are two different "things". That's not a frivolous, hair-splitting thing to say - the difference between generating a list and re-ordering it should be apparent to anyone who writes code.

After all, when you write a function that returns an array, do you typically have it take in a boolean argument for whether or not to reverse the array's contents?

> After all, when you write a function that returns an array, do you typically have it take in a boolean argument for whether or not to reverse the array's contents?

And the granularity of unix is much more course than a single function. Have you never written a program or application that returns the array and sorts it?

Yes, but I preferably compose it of two functions: one that gets the data and one that sorts it.

Only rarely that isn't the right thing to do. For example: if the data comes from SQL, I tend to do the sorting in SQL, it I see that as a problem with SQL: it composes badly.

Is there anything stopping you from doing that with current unix tools? You can do that, I'll continue using the more pragmatic option.

There isn't, but if you see the base system as the library to build your tools on, a library function to get all files in a directory and, optionally, sort them by name, doesn't seem like a good design.

Big data sets in general composes badly, you have to do the filter+sort+pagination as close to the data as possible. It has to be embedded in the query protocol, you don't want to transfer one billion entries over the network, just to later filter out 5 of them and then sort.

That depends on the expressive power of your protocol.

For example, a JVM program running on a client could send a _program_ to a JVM program running on a server to run it there, with the server using the security features of the JVM to enforce that that program is well-behaved by limiting what interfaces it can call, how long it can run, etc.

With that in place, a service could provide a call that produces the data and takes client-provided Java code fragments that filter and sort the result, and use hotspot to do optimizations across the stack.

(SQL, in both theory, can accept query fragments to insert into queries, too, and that can be done in practice, too, by concatenation of query fragments, but it always feels like a hack, and typically doesn't enforce security)

Yeah, but you write those 2 functions once, and use the result combination all the time without separating them. You don't want to write both of them all the time, which is what happens on the shell (unless you create an alias, or a program... which is exactly what 'ls' is)

I don't think I missed its trees - I called out the article as missing the 'doing it well', and the bit you quoted me on was the bit of satire on overzealous puritanism.

We'll have to agree to disagree here. I think of a 'tool' as more than just a named simple function - the author's definition of 'do one thing' is ridiculously narrow (hence the satire).

Reply on news.ycombinator.com