[FoRK] Should Exist: a new UNIX shell

Jeff Bone <jbone at place.org> on Wed Jun 6 19:17:08 PDT 2007

On Jun 6, 2007, at 4:47 PM, Karl Anderson wrote:

> This is how I felt about MS Visual Studio last I used it 7-odd years
> ago.  Isn't this how desktop developers are expected to work now?  And
> is the browser this generation's version of the Squeak prison?

Good questions...  I don't see Visual Studio as the same sort of  
thing, as the development environment is not even tied to the  
production artifacts...

The browser's a better analogy, but still qualitatively different (in  
another way) --- it's purely the deployment environment, but you  
can't (modulo Wiki-esque things like Jotspot, newish things like  
Greasemonkey, etc.) "extend the environment from within the  
environment."  There's fundamentally a difference between the  
developer's user experience and the end user experience --- more than  
just workflow --- and there's no smooth path between them.

I'm not sure what to call the kinds of things we're talking about;   
old-style Lisp environments, all Smalltalk environments (for the most  
part), etc. have this sort of fundamental characteristic where the  
whole system follows one paradigm and is "open" to interactive  
extensions.  (Again, MUDs are similar.)  Emacs only differs from that  
model in the sense that it's *got* to interface w/ the outside  
work...  and newer Lisps tend to be standalone languages rather than  
all-inclusive (w/ some exceptions, e.g. Dr. Scheme.)

The top contender, IMHO, for this sort of thing these days --- modulo  
Squeak, of course, which is a new instance of an old pattern --- is  
Eclipse.

Personally, I never drank the IDE Kool-Aid.  Far better, IMHO, to  
have a bunch of small, special-purpose yet general tools that can be  
thrown together any which way.  UNIX *is* the environment;  no need  
to replace the existing functionality.  Just give me a better tool  
for exploiting that functionality... :-)

> And the pipe is still passing lines of text,
> so it'll have to adapt or be left behind if someone actually makes use
> of Monad-style object passing in the shell.

Precisely my point.

Along that line --- a real solution will have to accomplish this  
*while still allowing the old text-based tools to be used and even  
intermixed in the same pipeline.*  You could accomplish that by means  
of a universal marshaling syntax that would be self-describing, line- 
oriented, and text-pipe and -tool  friendly.  That's expensive,  
though.  I've been toying a bit w/ the idea of "interface discovery"  
for shell tools, so that tools that supported more structured stdio  
could advertise this fact.  That could allow more efficient passing  
of structured data between tools that supported it, and automatic  
(de-)marshaling when writing to or reading from some other process  
that doesn't support native structured piping.

> Also, I wonder how important all of this really is.

I think that we, as developers, become rather insensitive to the  
roughness of our tools and the ways they fit together (or more to the  
point, do not fit together.)  Small reductions in impedance mismatch  
translate into huge productivity and re-use increases.  (What piece  
of code has been re-used more than the lines of code in grep, for  
example?  Or sed?  Etc.)  The best ideas in UNIX have long legs;   
it's just unfortunate that UNIX started evolving away from that when  
a bunch of punks in a hot tub in Tahoe decided that networks didn't  
need a file interface back in the 80s. ;-)

jb



More information about the FoRK mailing list