[FoRK] Should Exist: a new UNIX shell
<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
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
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. ;-)
More information about the FoRK