Lambda the Ultimate

inactiveTopic Longhorn Command Shell ("Monad")
started 11/8/2003; 1:10:02 PM - last post 11/10/2003; 4:56:13 AM
Ehud Lamm - Longhorn Command Shell ("Monad")  blueArrow
11/8/2003; 1:10:02 PM (reads: 9455, responses: 17)
Longhorn Command Shell ("Monad")
Some people are quite excited about the new command shell Microsoft is planning for Longhorn. It sure looks like an improvement over cmd.exe.

That command shells are micro-languages is not a new observation, so the new shell -- code named Monad -- is on topic for LtU.

It is quite amusing to see the speculation going on about the name. I guess not everyone knows that monads are used in functional programming for stringing operations together. People are actually trying to figure out what Leibniz has to do with Longhorn

Be that as it may, you may be itnerested in the PDC slide deck (PPT), which contains some useful examples.

It seems that the main innovations are the use of structured date (i.e., objects) instead of text streams, standardized error handling, and support for naviagting multiple hierarchical name spaces in addition to the file system.

Not only are shells DSLs, they are also one of the more successful examples of end user programming. Many so-called super users know how to concatenate and filter the standard shell utilities (e.g., more, sort etc.), even though they lack programming knowledge. This is due to the simplicity of the model.

From what I've seen of Monad, I am not sure if it's going to empower end users, or make the shell less accessible than it is today.

Posted to DSL by Ehud Lamm on 11/8/03; 1:13:22 PM

Patrick Logan - Re: Longhorn Command Shell (  blueArrow
11/8/2003; 2:08:12 PM (reads: 1491, responses: 0)
msh definitely seems aimed at the programmer. Even so, there are probably (hopefully) improvements for the general user.

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.

Dave Herman - Re: Longhorn Command Shell (  blueArrow
11/8/2003; 9:18:12 PM (reads: 1431, responses: 1)
Could anyone convert this to another format, perhaps PDF? PowerPoint viewer for MacOS is having trouble with it. Thanks...

Sergey Goldgaber - Re: Longhorn Command Shell (  blueArrow
11/8/2003; 9:59:11 PM (reads: 1427, responses: 0)
More people that are excited about MSHell

Ehud Lamm - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 2:46:53 AM (reads: 1405, responses: 0)
PowerPoint viewer for MacOS is having trouble with it.

Now how amusing is that, ah?

Keith Devens - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 12:39:58 PM (reads: 1311, responses: 1)
The PPT seems to work fine in OpenOffice :)

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?

Ehud Lamm - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 2:42:01 PM (reads: 1296, responses: 0)
Some observations:

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

Patrick Logan - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 2:44:27 PM (reads: 1287, responses: 0)
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 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.

Sean Levin - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 5:41:51 PM (reads: 1251, responses: 0)
I've converted the ppt to html. You can see it here if you like.

Chris Rathman - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 6:50:22 PM (reads: 1235, responses: 3)
Well, if you do it right, a text stream should still be available as a one form of input to a program.

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

Dave Herman - Re: Longhorn Command Shell (  blueArrow
11/9/2003; 7:28:50 PM (reads: 1235, responses: 1)
Thanks for the HTML version! I also downloaded OpenOffice (I've been meaning to do that for a while anyway).

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

Karl Reitschuster - Re: Longhorn Command Shell (  blueArrow
11/10/2003; 12:14:08 AM (reads: 1177, responses: 0)
Wow! Microsoft needs a lot of relaeases to achknowledge what the benifit of a non-mouse driven shell is? i am excited;


Ehud Lamm - Re: Longhorn Command Shell (  blueArrow
11/10/2003; 3:19:36 AM (reads: 1150, responses: 0)
if you have to wrap a simple script in 25 lines of boilerplate just to get it to run, automation isn't lightweight enough.

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

Karl Reitschuster - Re: Longhorn Command Shell (  blueArrow
11/10/2003; 4:55:51 AM (reads: 1138, responses: 0)
I am not sure what you mean ( my english is easy going) but eevery aproach to script-language should be as simple as possible. So iam really a fan of bash(Linux) or ksh(Unix);

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

andrew cooke - Re: Longhorn Command Shell (  blueArrow
11/10/2003; 7:18:33 AM (reads: 1109, responses: 2)
Hmmm. I'm torn between the advantages (you presumably get methods as well as data; the information is more strongly typed) and the disadvantages. It's an old link, but I re-read ESR's defense of Unix programming not long ago, and found it refreshing to have the advantages of The Unix Way spelt out in letters ten feet high.

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

Rici Lake - Re: Longhorn Shell vs. Applescript  blueArrow
11/10/2003; 10:20:32 AM (reads: 1125, responses: 1)
I did a site search on Applescript, to no avail. Am I to assume that this interesting little language has never appeared on LtU?

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.

Ehud Lamm - Re: Longhorn Shell vs. Applescript  blueArrow
11/11/2003; 4:03:15 AM (reads: 1010, responses: 0)
Am I to assume that this interesting little language has never appeared on LtU?

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.