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