Lambda the Ultimate

I'll look through the slide deck. I'm wondering if the features would be a better combination than Emacs (shell commands in buffers, macros, Elisp), along with JScheme (or DotLisp) running in a buffer.

MSFT is definitely making improvements that are long overdue, though I am troubled this is all getting bundled into some far off major release.

Now how amusing is that, ah?

The only thing that concerns me is that they pass around objects instead of text between pipelines, though I guess it makes sense if all your programming languages are .NET-ized. I suppose it could even allow higher-order-programming in the shell.

But, Unix has gotten along fine for decades passing around text. Is there any precedent for MS's approach? What do ya'll think about this?

- It's going to be harder to write shell-aware utilities (simply writing to stdout is not enough, you need .net/ ann oo-aware language etc.)

- Debugging these utilities is goind to be harder (they are not simply text based).

- I am not sure I understand how code can be dual use: both as an element of a pipeline and as the final program that provides human radable and usuable output.

It's kind of like MacLisp vs. Interlisp development. The MacLisp model is based on manipulating text. The Interlisp model is based on manipulating structures (cons cells) in memory.

Text is more space efficient and allows the intermediate state of the computation to be "ill-formed". In the long run, the MacLisp model won.

But then there is also the Genera/CLIM model where the displayed text are "presentations" of real objects and the history of the session retains those objects as long as necessary. e.g. listing a directory in the shell would display the names, but each name would subsequently be "clickable" and represent the file itself.

I would guess how well this new shell works will depend on how cleverly they implement the model. Just this morning in Windows XP the file manager was displaying a 700+ MB file. All I wanted to do was Shift-Delete it to expunge it completely from the disk.

The WinXP file manager choked before I could even type Shift-Delete. Just highlighting the 700 MB file apparently caused it to choke when doing something with the bulk of the file.

An intelligent object-based shell will have to cleverly use small proxies and flyweights in lieu of actual objects in order to avoid these incidental choke holds based on large objects or large numbers of objects. Some cleverness on disposing unneeded objects may be called for too.

This problem shows up in all kinds of applications and it will show up in file system shells too.

http://www.vikk.org/ms_cli/chuba79_slideshow/

Having listened to Dan's speech on boundaries yesterday, it does stick me that the types of boundaries between programs has been stuck for the last 25 years. While languages have welcomed all sorts of boundaries within a program, the talk between programs is stuck on text streams, forks and signals. Yes, you can get a lot done with 3 such simple concepts - witness the Unix Shell utilities. Even the lowly System 36 had Indicators that could be passed from program to program. And you could manipulate the environment within which the RPG programs could run.

Will this make shell programming less accessible. Well, shell programming is becoming less and less accessible to many computer users. SysAdmins and DBAs are about the only group that I can think of that use shells on a regular basis, and more and more they are taking on programming tasks (Perl, Python, Ruby).

Instead of asking whether inter-program communication and coordination should be open for innovation, the real question is whether objects are really a satisfactory answer. In my mind, the question of how data and behavior crosses program boundaries is less important than the question of events, signals, and queues (similar in scope to distributed processing across platforms - as the program should not necessary be chained/synchronized on a single cpu).

As for content, I very much like the idea of being able to communicate more structure than flat text at the ... boundary (ouch, I said it) between programs, but I share Ehud's skepticism: it seems a common trap to make automation available at too low a level (case in point: VBA for Excel -- see Peyton-Jones's Improving the World's Most Popular Functional Language). To make automation as useful as possible you have to get the abstraction level high enough. First of all, if sysadmins have to learn C# to write shell scripts they won't do it nearly as often as they do in Unix. Second of all, if you have to wrap a simple script in 25 lines of boilerplate just to get it to run, automation isn't lightweight enough.

(Wow, one day at LL3 and I'm cramming in the buzzwords all over...)

carl

This leads us to another perspective on the language issuse: Programming languages are very good at hiding boilerplate and/or making it unnecessary.

This new MSH seems at the first look very over-sophisticated; carl

I currently work in a loose group that includes two projects that are solving similar problems (distributed computing) in very different ways. One group is doing the whole XML JAVA SQL (and UML) thing; the other is using a Unix directory structure as a database, sending simple text/csv messages directly through sockets, etc etc. "Everyone" "knows" that the XML/Java/SQL/UML way is right, and the other group is old fashioned and going to have problems (scaling, deadlocks, reliance on NFS, etc). But the old-fashioned solution is already up and running, while the design for the [prod TLA lim n->inf] version isn't yet through its PDR (prelim design review)...

There have been a few attempts to turn Applescript into a shell language (I was responsible for one, back in my MacOS8 days). I wasn't very happy with the results, because it turned out to be too difficult to use spontaneously. But it certainly has some interesting features, rather similar to the ones mentioned in the Longhorn writeup (and perhaps some features not yet in Longhorn, for example persistent properties).

As a command shell, though, it has a number of problems. First, it is somewhat wordy, although a good tab completer would go a long way towards solving that. Second, although it allows you to target any object in any application, it often turns out that successive commands typed into a command shell do not have the same target. Consequently, a simple-minded implementation of "cd" (taken as setting a default root) is inadequate to the task. Actually, I think the same is true of ordinary Unix shells; you end up compensating by having a variety of "search paths" stored in environment variables.

Many of these same issues reappear in scsh: it is a wonderful language for writing shell scripts, but actually day-to-day use as a command-line can be a bit of a pain.

I wonder if the properties that make bash, for example, a comfortable command-line environment are precisely the properties that make it an awkward scripting language, not the least of which being the security aspects of passing a random string to bash to execute.

It wasn't discussed at length, that's for sure.

It seems to me that people are conflating application scripting (e.g., exposing application objects) and shell programing,, that I prefer be restricted to combining well defined independent components.

Maybe this is the right way to go. Maybe not. I think this decision should be made explicit and discussed.

Rexx is a prime example of a lgnauge designed to communicate with applications (you simple ADDRESS them). It's not that great for shell type things.

These models are obviously related, but it seems to me that they are distinct and combining them together isn't all that easy. Does the MSH try to address this need, or is this sort of thing supposed to be done using scripting languages (and the scripting host), VBA etc? I am not sure I know what the Microsoft vision is on this one.