Why did you do that? $VAR/ {} / Weak Intellisense
I strongly encourage people to let us know where we could be doing better and to let us know if we are getting into the weeds. I believe that being open to such bad news is core to the the virtuous cycle of self improvement so such feedback provides opportunities to reflect and make changes when appropriate. Other times we'll just agree to disagree. Occassionally I'll take some of that feedback and use it to explain what or why we do things.
Recently Raul from Switzerland took some time to document some of the things he thought we should be doing better. I thought I would discuss some of these here so that everyone could understand how we think about things. I asked Raul what 3 things he would change. He replied:
- OK, first get rid of the $-sign to denominate variables. We have come much further than that in the meantime. Low level programming languages like Visual Dialog Script (www.dialogscript.com), Kix, Pearl, or PHP need these parsing aids. We should not go back to that.
- Next, get rid of the horrific {$._} construct, not only because the curly braces are available only together with ALT-GR on most non-US keyboards. Furthermore, it is impossible to read (for non-programmers). Programmers are accustomed to such constructs and worse ones. But if you want to gain heart and mind of the administrators, that is not the way.
- Provide some kind of assistance when typing the dot after an object, simlar to Intellisense. If you want administrators NOT to read tons and tons of books, well, the only way is to provide online assistance, like Intellisense. Your presentation started gearing towards administrators but very shortly thereafter, there were hardcore programmers speaking to other hardcore programmers, in the most pure tech-talk. I assume, that you would have lost your non-hardcore programmers audience after 20-30 minutes.
The $ in front of variables comes from our design center of being an interactive command oriented shell. Interactive shells are NOT the same thing as Scripting languages with command interpretors. Interactive shells are case studies in engineering tradeoffs (another way of saying that is that they tend to be a little quirky). There is a tension between the needs of a great interactive experience and a great scripting/programming experience. Time and time again during the course of the project, people would try to make us "choose" between one or the other. We refused.
We believe that if you work hard enough at it, you can solve the puzzle and provide a great solution for both. We were absolutely subborn on this point. Time and time again, we were able to succeed with this approach if we travailed long enough. There has only been one issue where we could not optimize for both goals and had make a choice (using ">" to mean file redirection instead of "-gt").
Anyway, that is the reason why we use "$"s in front of variables. Bruce Payette is writting a book about Monad and goes into significantly more detail about the specifics of our decisions and why we made them (your going to love it).
"{}" vs BEGIN/END IF/FI WHILE/WEND DO/OD etc etc. This was resolved pretty quickly for us based upon 2 factors.
- We looked at the all the mechanisms shells/scripts use and thought that most of the shell and script ones were .... well .... ummm .... inconsistent and not the strongest features of these environments.
- We wanted to provide a smooth glide path between GUI, CLI, and C#.
As such, use of {} was an easy choice for us. Now let me say a couple more words about #2. Monad is NOT C#Script. It is a distinct environment focused on distinct user scenarios that are quite different than C#. The language and environment reflect that. When we designed the language we looked at a number of different environments (SH, PERL, RUBY, VMS/DCL, AS400/CL, and C#) and took inspiration from elements of many of these. We also wanted Monad to have the widest dynamic range possible. It should be easy to start using, easy to start scripting, easy to do sophisticated scripting and you should be able to use Monad to do most everything you want to do. That said, we know that at some point Monad will not meet your needs and you'll need to do systems programming (typically for perf reasons). When this occurs, we want to minimize your switching costs. This is why we use choose to use C# for many basic elements that do not conflict with our interactive scenarios. {} is just one of many. We think that this has worked out pretty well. Monad is a fantastic environment to explore .NET and while most of Monad is written using C#, a number of our devs do prototyping work in Monad itself and then translate it into C#.
Intellisense. I totally concur. The current system is relies too much on .NET objects and our tab completion is too weak. It is going to take a while before you can do everything using cmdlets (instead of .NET objects) however in the next drop (Next week), you'll see that tab completion gets much better. We'll provide tab completion for filenames, command names, command parameters, object properties and methods. Tab completion is actually a callout to a user-definable function so that the community can get as sophisticated as they'd like to. This feature has lagged because we have strongly focused on the command line experience and invested there instead of spending time on things like IDEs. We are relying on the community and third parties to fullfill this need in the V1 timeframe. That said, user feedback was strong enough on this point that we knew that we had do improve things for V1. We hope you like what you get next week.
As always, please let me know if this is not the case or if you think that there are things we should be doing better.
Raul - thanks for taking the time to organize and send me your feedback. I hope this blog provides some more context around why we made the decisions that we did.
Enjoy!
Jeffrey Snover
Monad Architect
Comments
- Anonymous
April 16, 2006
The real thing that gets me is lack of a decent terminal app hosting the shell. The basic terminal now is ugly, hard to read, impossible to resize, and doesn't support copy/paste correctly. - Anonymous
April 17, 2006
(SH, PERL, RUBY, VMS/DCL, AS400/CL, and C#)
Might have done well to have included some consideration of REXX in that mix. - Anonymous
April 17, 2006
$ - is fine and does help to separate out the variables visually
{} - as stated relieves us of the kind of confusion evident in VB languages. Never can get the closing right the first time. Using braces for everything as in "C" is much easier to deal with once we can accept it.
<>| Folows through from other shells so should be quite natural.
The terminal interface works well. I customize it like any other console with good colors the task at hand. Using a custom console with the GUI hooks from C# or VB can create very nice custom user interfaces for tools and utilities. - Anonymous
April 17, 2006
> Might have done well to have included some consideration of REXX in that mix.
Funny you should mention that. We met with lots of customers getting feedback about what they liked and didn't like. We met this great guy in Portland Oregon who went on and on about how wonderful REXX was. That night I went out and bought a couple of REXX books to study the language. There were some very nice things in there and I think that we did do something with it but in all honesty it wasn't a large influence on Monad. Their text parsing was very attractive and I weighed whether to support it or not but in the end, I decided that our current text parsing was very strong and would leverage the UNIX skill base out there and that providing an alternative way to do the same tasks would just confuse the learning curve.
Jeffrey Snover - Anonymous
April 17, 2006
> The real thing that gets me is lack of a decent terminal app hosting the shell. The
> basic terminal now is ugly, hard to read, impossible to resize, and doesn't support copy/paste correctly.
We all share your frustration with the existing console. Remember that MSH.EXE is just our implementation of a UI for MONAD and that other people can provide them as well. I refer you to Karl Prosser's http://www.karlprosser.com/coder/?cat=8 for a very cool UI.
Jeffrey Snover - Anonymous
April 17, 2006
There is a lack of opportunity to launch msh-scripts by a double click from the Explorer as well as without opening a black window of the interpreter. - Anonymous
April 25, 2006
I think you guys have done a fabulous job!
Although, for my less .net savvy friends and sysadmins some sort of intellisense is important or even crucial. If it weren't for my knowledge of .net types and their methods I'm sure I would have gotten tired/frustrated pretty quickly. Furthermore, it's only because I'm aware of the breadth and depth of .net that I can see the potential of what you guys are offering. A sysadmin who doesn't program in .net might be a little clueless.
You guys have a way to look up the methods available with the "get-member -input" stuff, but intellisense is like lazy discovery which i love.
Also, as far as the curly braces go, I think you've made the right choice again.
Criticism... I started writing some things down, but I soon realized I basically just wanted a more rich UI/IDE to write and run this stuff with. - Anonymous
April 26, 2006
Download RC1 and try out the new tab-completion. It gives you quite a bit of intellisense. If it doesn't give you enough, write your own - it is a user-definable function. We fully expect to see people sharing there implementations of tab complete and I'm looking forward to trying them out!
RE: UI/IDE - give Karl Prosser's PowerShell Analyzer a try - it is awesome! http://www.karlprosser.com/coder/?cat=8 .
Also - at today's talk at MMS, I'll be showing an Alpha version of Sapien's PrimalScript IDE with PowerShell support.
Jeffrey Snover - Anonymous
April 26, 2006
Indeed. Please find a better default variable!
$ for variables is OK, but there must be free chars for the default variable less ugly than $
not only will "$" horrify >10% of the possible PowerShell users. It is also really hard to type. - Anonymous
April 26, 2006
> there must be free chars for the default variable less ugly than $_
I keep telling Jim Truher and Bruce Payette to find a way to use "^" but they keep ignoring me. :-)
Seriously though - We needed a symbol for this concept and $_ is the symbol for the same concept in PERL. While some people like to throw rocks at PERL - none of those people work on the team. PERL is amazingly successful. We took that as prima facia evidence that $_ was a reasonable choice.
Give it a chance and you'll find that this will irriate you for a while and then fade into the background.
Jeffrey Snover