Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

Acme mouse chording is really cool, doing something similar with keyboard-oriented editors is much more tedious and often outright painful ( http://acme.cat-v.org/mouse ).

I suspect ken spends most of his time thinking rather than typing, and I have found this to be true of most great hackers.

Other famous Sam users include Brian Kernighan, Bjarne Stroustrup(!) and Tom Duff. Kernighan writes at least as much English as code and I wonder how that affects his editor usage patterns, but I suspect that even when writing natural languages most time is best spent thinking (his writing style is very concise and clear, one could say similar to ken's code).

I think the obsession with saving keystrokes is very misguided, I still use editors like vi frequently, and having to think about what magic combination of commands to use to perform a task can be very distracting, is fun and feels good, like a tiny puzzle game built into your editor, but it doesn't help you write better code faster IMHO.

P.S.: Is interesting who has stuck with Sam and who moved to Acme (Dennis Ritchie switched to Acme, and most of the Go team Google besides ken use it too).

See also: http://sam.cat-v.org/

Except that PCREs (or most of their implementations which are used in all those languages, re2 and Go's standard regexp package are exceptions) have some fundamental issues: http://swtch.com/~rsc/regexp/regexp1.html

There is also sam -d ;) http://man.cat-v.org/plan_9/1/sam

(It hides the GUI and gives it a more ed-like interface that you can easily script, but this is kind of a hack for Plan 9-nuts ;)

The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature.

People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing tools for pipelines is because they are trying to recover structure from the data that was already present before the previous stage of the pipeline threw that structure away by dumping it to flat text!

Text is obviously a convenient way for humans to view a program's output, so clearly it's useful that all Unix programs (ls, ps, etc) can dump their output as text. But there's no need to dump to text until the output is being sent to a human. If you're piping "ls | grep" there is no reason for "ls" to dump to text and "grep" to parse it back from text, especially since "grep" doesn't know anything about the format of ls's output. It would be way more convenient if you could say something like:

    ls | grep 'file.size > 1M'

But the only way to do this today is to parse ls's output first. There would be no reason for this if ls could send structured data to grep.

What I'm describing is similar to Monad, Microsoft's next-gen shell. AIUI it can send .NET objects between processes instead of flat text. But IMO it's too imposing to mandate a single object representation like .NET objects.

I'm experimenting with the idea of letting people specify the output of command-line utilities as a Protocol Buffer schema, for example:

  message DirectoryEntry {
    optional uint64 inode = 1;
    optional string name = 2;
    optional uint64 size = 3;
    // etc.
  }

I think this could be a compelling way of making the next generation of usability in command-line pipelines, by saving people from having to write ad-hoc parsers all the time.

Seems like it shouldn't be too hard to write a little function (perl, python, whatever) to act as a "visitor" to hold this state, then just pass it little closures (maybe a hash/map?) to evaluate the regexs and pass the match into a code block?

Something like (perl):

&visit_matches(

{ ' +' => sub { $x += length( $1); },

  '#+' => sub { print $1, ' at ' $y, ',', $x'; $x += length( $1); },

  '\n' => sub { $y++; }
 

});

(not an exact match to the pseudo-awk, but enough to get the idea)