The Unix Philosophy and a Fear of Pixels
prog21.dadgum.com
prog21.dadgum.com
> ... take a moment to consider how utterly anachronistic both of the above solutions come across to non-believers in 2012
While this as the author admits isn't what he wants to talk about, I want to talk about it for a moment. Apart from `find` which is indeed archaic (few people seem to use its many built in features and pipe to simpler programs instead--e.g. preferring to pipe to xargs instead of using -exec), I'm struggling to find what's so old-fashioned about the grep example and what a modern, 2012 design should look like. Is it the '-v'? You can type '--invert-match' instead. Is the problem old-fashioned? I don't think so, I still occasionally pipe the results of find through grep -v and then on to something else. Is piping old-fashioned? Again, what's the 2012 version of these things?
While I don't really like comparing programming languages to spoken languages (much like comparing OS kernels to popcorn kernels), I always liked this quote since I read it:
"Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks." -- Bill Garrett
As for the "meat" of this post, well, we'll see how Light Table turns out. I'm not particularly excited about it but plenty of HNers are.
And the reason is that it's reliable (unlike `ls`) and isn't wasteful (unlike the most-misused-tool-of-all `cat`). I don't understand why similarly newbie-unfriendly tools (like `sed` or `awk` for instance) never get as much heat as `find` does from people unfamiliar with it. Is it because the name implies that it should be a simple tool?
As for what's wrong with the `ls ... | grep -v ...`. It can break in so many ways like for instance, if a filename contains a newline character. If you think that never happens, you're making the same mistake me and a thousand of newcomers before me made once and never repeated again.
As a rule of thumb, never parse the output of ls (http://mywiki.wooledge.org/ParsingLs).
The solution to filenames with newlines in them is one garbage-safe script involving 'rm' and a stern email to whoever created the file. Containing complexity instead of letting it leak into every single script is a good thing.
Even more than that, awk's orientation towards filtering text lines made up of fields makes handling many little pipeline tasks amazingly simple. In combination with being a very nice little general-purpose programming language with good string support, awk is a no-brainer first stop for a lot of things.
[Other more recent programming languages generally have many more features, much better implementations etc, but nothing has improved or really even matched awk's smooth integration into the unix pipeline. Perl, for instance, although it's long tried to bill itself as a replacement for awk, and explicitly includes special features for such usage, can be significantly more awkward (er... :) for the sort of tiny little filters awk's really good at.]
I think Ritchie sums up my feelings for `find` with "...we were somewhat put off by the syntax of their things. However, they were clearly quite useful..." `find` is useful, it's just not Unix-y. Does it still follow some of the Unix Philosophy in spirit? Maybe. I think there's also a chance that Unix Philosophy in its purest form is mostly dead in practice and has been for a while. Just look at the evolution of echo.c: https://gist.github.com/1091803
I'll readily agree that `ls .. | grep -v ..` can break, but I don't find anything archaic or non-Unix-y about it like I do with the `find` version. (Also every time someone uses `cat .. | grep ..`, a kitten dies. :( )
Finally, it's not the newbie-unfriendliness that `find` has, it's the irregularity and kitchen sink of features that aren't expressive and don't generalize well, as the other repliers elaborate on. In my experience `sed` and `awk` are more regular, more generally useful, and have less "intuition traps" than `find`. (As sort of a neatity aside from their surface-level expressiveness, both sed and awk are Turing-complete. I think it's interesting that my man page for sed(1) is 267 lines, my man page for gawk(1) is a hefty 1713 lines, and my man page for find(1) is also a hefty 1446 lines.)
Instead, offer me a graphical solution to the same problem you posed against the 'nix shell. It doesn't even have to work; a series of photoshopped images would be welcome.
Show me something better, because that 'nix philosophy works very well, whereas its replacements don't (seriously, can anyone think of a way to come up with that list of files without resorting to a shell or programming your own solution?)
OP, build that better, graphical interface. When you blow by me because you are so much more productive, don't worry, I'll take notice. Until then you can take my text editor when you can pry it from my cold, dead hands.
Graphical wrappers to plain text are not only 'orders of magnitude harder [to implement]', but that much harder to debug as well. If your GUI client to a remote server beach-balls waiting for a command to complete, is your code wrong, or your connection latent, or your desktop app crashing? An SSH connection to the CLI server can cut through a lot of that pretty quick.
1. open a folder
2. Click the "File Type" column
3. Drag to select all txt files
4. Hold Ctrl, click to deselect the ignore_me.txt
In other words, even for people like me who when asked, "how would u automate that?" would reply, "I'd write a shell script or some Emacs Lisp," it is IMHO often better to do it in a GUI when automation is not necessary. (No joking.)
That is only because most things that need automization have already been automatic. The advantage of cli is that when you need to automate something, the tools are already there, as apposed to needing to find a completly different set of tools, or manually do the same simple procedure a hundred times.
That is not an effective response to my point that at any given time, the task I am doing probably does not need to be automated.
Yes, CLI has advantages. Some of its advocates however seems to be blind to some of its disadvantages.
For the automation part, yes it's going to need scripts, but can your oneliner script handle this file name like this?
-\;?.txt
I think using the best tools suited for the task. If you need scripts to do the job, use scripts, if just few simple clicks, I don't want to bother find exec xargs pipe here and there.
1. Open folder
2. `type:text` in search box
3. Click 'ignore_me.txt' file to exclude, if you can't find it start typing 'ign...' until it shows up
4. Edit > Invert Selection or Alt,E,I
> Here's a simple task: print a list of all the files with a txt extension in the current directory except for ignore_me.txt.
Your solution, and one of the the sibling comment solutions, will select all of those files, not print a list of them. Pedantic, perhaps, but the solution outlined by the OP is not mirrored by your solution.
This isn't automation, this isn't anything but simple file manipulation, that most graphical operating systems are incapable of; it's also a simple display of how graphical UIs fall short of the shell.
5. Shift+right click the selected files, choose "Copy as path" (assume you are using Win7)
6. Paste the result in notepad
If we extend the problem to do something like changing the extension (very common for me) for all selected files, the GUI is useless here. Say I want to turn all .txt files => *.txt.old for a cheap archival? In the GUI, I don't know how to do this. On the CLI, I can simply do a 'find -exec', which also allows me to recursively do the change.
Sure, this would be trivial to implement (even Eclipse has a dynamic rename for variable names) with an extension, but this has to be done for each and every possible activity.
While I could imagine such a system being used for very trivial programming tasks by "non-programmers", I find it very utopistic to even imagine that something as complex as even a primitive compiler could be writ.. described in such form with ease. The actual hard part is not to code it out(as opposed to sketch it out visually) but to manage the complexity by designing it in such a way that it makes sense and works as intended.
I really don't see how visual programming would be helpful with the actual act of designing or even understanding a complex software system with different types, constructs, patterns and their permutations. Perhaps it's just lack of imagination, I sure hope so.
GraphViz is a tool that converts a text format to images, not a pointy-clicky WYSIWYG thing, so I'm not sure how much of a defense of visual programming that is.
In the end, it was (of all things) Actionscript/Flash that ultimately gave me the visual feedback I needed to make real progress in learning to code. These days, I'd probably recommend something like Processing(.org) to a newcomer.
All this just to say: I'm sympathetic that someone wants a programming language that's more visual and that makes it easier to push pixels. I think it'd go a long way to help teaching programming at the very least.
Except the UNIX way of things runs the Internet, and visual programming tools run practically nothing of relevance at all.
Side Note: pixels are not easy to parse, text is.
However, I also decided at that point that it was not for me. The text already has a certain vibe to it so there's no need to add any enhancement via the computer. If anything, it tends to clash with the actual business of programming.
But that's just me, and I'm probably an outlier in this regard.
Do i really need all of that tooling when one simple line in my cron will suffice? Do I really need a huge text editor in order to find and replace words when one sed line will do?
It's a class and style of programming that forces us to be efficient so we can get onto other things.
I spent about 3 years developing software systems graphically using Simulink. It was a horrible experience from an ergonomic perspective: There was far too much mousing, and it had a really bad impact on my wrists and hands.
On the other hand, I do have a very visual imagination, and I find the ability to view the system and logic that I am working on diagrammatically an enormous boon - to the point where I have thrown together crude dependency analysis tools to let me render dependency graphs with graphviz (to help navigate a hairy, undocumented legacy codebase).
So the key, to my mind, is having a set of graphical tools that enable the developer to visualise (and navigate) source documents in a range of ways, whilst keeping the underlying source as text, and the primary input tool as the keyboard.
This should encourage discoverability in the software tools that we use - which is the main bugbear that I have with Unix, (although I am beginning to appreciate it in other ways).
If you want a deeper answer you might want to clarify what you don't like about the post.
I understood it as a call to think more about the tools we use every day -- not just what editor or anything petty like that, but in a big way. The fact that we still edit files in order to write code, and how little has actually changed since the macintosh was released, with regards to graphical programs.
Well, I was, but after all the attempts over the years my curiosity has been sated.
To the extent that you did not know this has been attempted many, many, many(, many, many, many, many...) times, well, that's a measure of how successful the idea has historically proved to be.
Perhaps I too would fall into the "it should all be more visual" local optima sink trap of opinion if I hadn't seen so, so very many tries at the idea.
Mind you, if you produce a working one that actually keeps all of its promises, I will hail your success. I will sing its praises all the harder precisely because I know how hard a problem it is. (Many of your users will take it for granted and think it was easy to build.) But I haven't seen one yet.
The visual part of a UI is graphical data. For reasonably complex things it makes sense to edit graphical data in a graphical editor and to separate it from code.
It sounds a bit in the article like he's talking about funny esoteric 2D visual programming languages but I think he just wants a nice way to make GUIs and has concluded that HTML is reasonable for doing so.
I'd be interested in a graphical shell for an OS (Linux I guess) written purely in HTML and friends. You'd have completely seamless integration with the web.
These days HTML is the most reasonable approach to anything involving
fonts and images and interaction. It's not as beautifully direct as REBOL,
and being trapped in a browser is somewhere between limiting and annoying,
but the visual toolkit is there, and it's ubiquitous. (For the record, I
would have solved the "list all the filenames..." problem by generating
HTML, but firing up a browser to display the result is a heavy-handed
solution.)
I suspect that XAML is somewhat related to Adobe's MXML. Both seem pretty similar in concept to Mozilla's XUL, or even GLADE XML. Recent versions of HTML, with behavior defined in something like jQuery seem to be reaching for this kind of thing as well.
They all boil down to a representation of a tree in memory used to sort out what goes where on a screen.
Also, not all Text based UX is a command line. Russ Cox has an interesting if not exactly short demonstration of the ACME editor. http://research.swtch.com/acme Not all Text based UI's are command lines.
Thus, I suppose my message is that Unix command line is even harder to properly use then he states. But in my opinion, the initial hurdles in learning it eventually pay off over time.
With zsh I can do what he wants without even invoking something that's not a shell builtin.
$ ~/temp/temp % ls
1 10 2 3 4 5 6 7 8 9 ignore_me.txt
$ ~/temp/temp % echo ^ignore_me.txt
1 10 2 3 4 5 6 7 8 9
$ ~/temp/temp %Although the "language" makes creation of functional user interfaces fairly simple, I find the system quite unwieldy as soon as program complexity increases to even a moderate amount.
Just try porting any visual studio project to a different platform and see instead of a sed one liner to edit your makefile you need to open 72000 dialog to change the name of one header file.