Why did you do that? $VAR/ {} / Weak Intellisense

Why did you do that? $VAR/ {} / Weak Intellisense

Rate This
  • Comments 1
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. 
  1. 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.
  2. 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

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

PSMDTAG:FAQ: Why do variables start with "$" ?
PSMDTAG:FAQ: Why use "{}" vs IF/FI WHILE/WEND DO/OD etc?
PSMDTAG:FAQ: Why use -le -ge and -eq instead of < > and = ?
PSMDTAG:PHILOSOPHY: Don't tradeoff interactive and scripting experiences - optimize for both.
PSMDTAG:PHILOSOPHY: Provide a smooth glide path between GUI, CLI, and C#

Leave a Comment
  • Please add 3 and 4 and type the answer here:
  • Post
  • I fully agree with Raul!

    In every Powershell Documentation (Books and Whitepapers) it is Pointed out, that Powershell was never developed for Windows Administrators. Every second word is bash Perl, Phyton und so.

    This never comes with Windows and Windows Admins are not familiar with it!

    Even in this Post, there are mentioned only non Windows Techniques / Languages.

    Traditional Windows Users and Administrators use Basic Syntaxes! They use Kylix, VBscript, AutoIT !!

    All Basic Syntax Stuff!

    All Windows administrators have now high switching costs!

    Even many Studies Pointed out, that there are more .NET Developers with their first language on VB.NET and not on C#.

    You do the Revolution to create a new Language instead the evolution and bring VB.NET to the Console skill.

    Here i must learn a new language throw all my knowledge over board and learn the same thing again and again with new languages (there are too much out there).

    Like website where i must learn HTML, Javascript,  Phyton, and so on. Imust learn cmdlets, Powershellscript and .NET Framework. The learn curve is too high! And without good Intellisense it is even harder! This Patchwork does not fit in .NET World!

    I hate the braces (curly Brackets) because I am no keyboard monkey. To do the bracket stuff with words instead of braces is a better syntax for International people (I am a German guy).

    (Thank you for dropping the needless semicolon)

    I am MCSA and since 10 Years in the Admin job and an enthusiast in VB.NET programming since 3 Years.

    Now in Powershell V2 times the Powershell Script Language is still no .NET language I can't develop it in Visual Studio with good Intellisense.

    Intellisense can even help in Interactive mode! For example: imagine a Pop up of all Properties of an cmdlet and select it by Cursor keys (a dream). Forget Tab-expansion! (But is better then nothing)

    In the .NET world the credo is to write self explaining Code with long Variable names and speaking Functions. In Powershell (Perl) there is only Cryptic stuff hard to read and to harder to learn. Intellisense could prevent this and make learning by doing possible!

    I think two reasons why WSH and VBscript are failed was, you havened the ability to use the WIN32 API  like in VB6 and there was no GUI support. (Look there at AutoIT !)

    1. Intellisense in interactive mode

    2. Basic Syntax is best for Cosmopolitan Computer syntaxes

    3. Administrators are no developers! So keep it simple and stupid!

    4. For advanced topics you need to use the win32 API and Windows GUI

    5. Linux Admins never switch to Windows! And Windows admins are not familiar with all that Linux stuff in Powershell

    You made a better bash no better Windows tool !

Page 1 of 1 (1 items)