The UNIX Philosophy and a Fear of Pixels

I’ve finally crossed the line from mild discomfort with people who espouse the UNIX way as the pinnacle of computing to total befuddlement that there’s anyone who still wants to argue such a position. One key plank in the UNIX party platform is that small tools can be combined together providing great expressiveness. 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.




Getting a list of text files is easy: ls *.txt. Now how to remove ignore_me.txt from that list? Hmmm…well, you might know that grep can be inverted via a switch so it returns lines that don’t match:

ls *.txt | grep -v ignore_me.txt

There’s also the find utility which can do the whole thing in one step, but it takes more fiddling around to get the parameters right:

find *.txt -type f ! -name ignore_me.txt

This all works, and we’ve all figured this stuff out by reading man pages and googling around, but take a moment to consider how utterly anachronistic both of the above solutions come across to non-believers in 2012. It’s like promoting punch cards or IBM’s job control language from the 1960s. You’ve got to get that space between the ! and -name or you’ll get back “!-name: event not found.” But this isn’t what I wanted to talk about so I’ll stop there.




What I really wanted to talk about are text files and visual programming.




I keep seeing the put-downs of any mention of programming that involves a visual component. I wrote an entire entry two years ago on the subject, This Isn’t Another Quick Dismissal of Visual Programming, and now I don’t think it was strong enough. Maybe the problem is that “visual programming” is a bad term, and it should be “ways to make programming be more visual.” At one time all coding was done on monochrome monitors, but inexpensive color displays and more CPU power led to syntax highlighting, which most developers will agree is a win.




Now go further and stop thinking of code as a long scroll of text, but rather as discrete functions that you can view and edit independently. That’s starting to get interesting. Or consider the discussion of trees in any algorithms book, where nodes and leaves are rendered inside of boxes, and arrows show the connections between them. It’s striking that $500 consumer hardware has over three million pixels and massively parallel GPUs to render those pixels, yet there’s old school developer resistance to anything fancier than dumping out characters in a monospaced font? Why is that?




It’s because tools to operate on text files are easy to write, and anything involving graphics is several orders of magnitude harder.




Think about all the simple, interview-style coding problems you’ve seen. “Find all the phone numbers in this text file.” FizzBuzz. Do any of them involve colors or windows or UI? For example, “On this system, how many pixels wide is a given string in 18 point Helvetica Bold?” “List all the filenames in the current directory in alphabetical order, with the size of the font relative to the size of the file (the names of the largest and smallest files should be displayed in the largest and smallest font, respectively).”




There have been some tantalizing attempts at making graphical UI development as easy as working with text. I don’t mean tools like Delphi or the iOS UIKit framework, where you write a bunch of classes that inherit from a core set of classes, then use visual layout packages to design the front-end. I mean tools that let you quickly write a description of what you want UI-wise, and then there it is on the screen. No OOP. No code generators. If you’ve ever used the Tk toolkit for Tcl, then you’ve got a small taste of what’s possible.




The best attempt I’ve seen is the UI description sub-language in REBOL. Creating a basic window with labeled buttons is a one-liner. Clearly all wasn’t perfect in REBOL-ville, as a burst of excitement in the late 1990s was tempered with a long period of inactivity, and some features of the language never quite lived up to their initial promises.




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.)




Code may still be text behind the scenes, but that doesn’t mean that coding has to always be about working directly in a text editor or monospaced terminal window.