6 ms·

> “I ranted at some of the architects when I was at Microsoft. They were constraining the sorts of things you could do,” Brown told us in 2012. “Microsoft likes

by Touche 12y ago

> “I ranted at some of the architects when I was at Microsoft. They were constraining the sorts of things you could do,” Brown told us in 2012. “Microsoft likes to do a really big up-front design, where they define the physics of a new universe. They birth this new universe, and they say: ‘This is how you do it’–instead of starting out with something simple and letting people show them how it should be done.” I really hope this advice is taken by others, particularly the Windows team. Powershell is a golden example of this. Great idea, piping around objects instead of text, but wait, they must be .NET objects. So the entirety of the language community cannot participate other than Microsoft languages. I'm hoping they revitalize the command line taking this advice, start with something simple and let others build on top of it.

stephengillie 12y ago
What would it take for a homebrew language to interact with the OS as a CLR language?
- ori_b 12y ago
  They tried it. It's called COM. http://en.wikipedia.org/wiki/Component_Object_Model http://en.wikipedia.org/wiki/Component_Object_Model
brudgers 12y ago
PowerShell's specification is publicly available. Has been for several years. http://www.powershellmagazine.com/tag/language-specification/ http://www.powershellmagazine.com/tag/language-specification...
- ygra 12y ago
  You don't even need the specification to implement cmdlets. Heck, you could extend PowerShell exclusively in PowerShell code (though performance makes that somewhat undesirable most of the time).
  - apalmer 12y ago
    The downsides to powershell are mostly around the fact that along with some good innovation they also threw out a lot of other standard conventions. Which makes it tedious to integrate powershell with other command line tools. Also another thing I have a problem with is the startup time, for a lot of quick hacks, I can start up, execute and close down the terminal (cygwin lets say) in the time i am still waiting for powershell to initialize. Not huge problem but for me it holds me back from using powershell somewhat.
    - ygra 12y ago
      As for command-line tools, the things that come to mind right now (that can be tedious) are 1. Result of a command-line tool is its output, not its exit code, so you have to use $LastExitCode when treating command-line invocations as boolean values 2. Stream behaviour other than stdout gets weird when redirecting one stream into another (e.g. 2>&1 causes every line that's output on stderr to be thrown as an exception. 3. Encodings are a mess, sadly. They mangle Unicode output from external programs. This was a compatibility decision, but it's unfortunate, especially because the appropriate .NET APIs are a bit clunky to use. 1 is just different from bash, 2 and 3 can be dealbreakers depending on what you do, and the workaround is the same, but annoying, admittedly. The one-second startup time has been awful, I know. Although for me at least since Windows 8 it has been instantaneous, making this a non-issue. (Pash is worse at about two seconds currently, though.) But from the time when Powershell was slow to start I still have a habit of just running cmd for things that can be done in cmd.
ygra 12y ago
PowerShell also plays nicely with COM and WMI. It's not all .NET objects you interact with. (Well, technically it is, due to PSObjects wrapping everything, but that's another matter.) How would you do it, though? Pipe around JSON or XML? Then you just have data structures, but not objects. They can't have methods and if they could, what language would they be written in?
- optimiz3 12y ago
  Well, if it was me... 1. Replace PowerShell with a .Net interpreter so you can "just run" a .cs_exe file or whatever. No one wants to learn/deal with yet another throwaway proprietary scripting language. 2. Replace all the PowerShell cmdlet garbage with .Net libraries. You'd also be able to then trivially automate any scripting from existing .Net programs/tests. 3. Have a JavaScript -> .Net compiler so people don't have to deal with C# or VB.Net if they don't want to. Scripts look something like (C# in this case): using Microsoft.Scripting void Main() { SQLServer.Configure(<SOME JSON>); var result = IIS.Start("MyWebPage"); if (!Installed(<some windows package>)) { File.Install() } if (!UserExists(server, user)) { CreateUser(user) } } You can't do all of this today (at least not easily or without installing many extraneous or 3rd part libs which create deployment headaches). EDIT: for clarity.
  - MichaelGG 12y ago
    Microsoft has had a JavaScript compiler for a while (JScript.NET). I don't think it gets much use. They also had a Java compiler. PowerShell is far better for scripting than C#. C# is terribly verbose and lacks scripting-ish stuff like string interpolation. I'm not sure it even had dynamic when PowerShell was made. It is pretty dumb that C# still hasn't shipped a proper REPL or script runtime though.
    - optimiz3 12y ago
      JScript.net has never been a first-class citizen, and Microsoft never really made an effort to make it viable in all of the domains C# is. JScript feels like an attempt to embrace/extend JavaScript that never took hold. The problem is that rather than adding libraries to improve .Net for scripting-ish stuff like string interpolation, you have to deal with an entirely different platform that shares little with the command line, and little with .Net.
acdha 12y ago
> Great idea, piping around objects instead of text, but wait, they must be .NET objects. So the entirety of the language community cannot participate other than Microsoft languages. Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about and probably have never looked at it again. This happens a lot where people who work on big projects just assume everyone else will look past the initial experience and grasp the cool vision.
- StillBored 12y ago
  "Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about" I think this depends on what component/system your trying to use. Recently I found myself using powershell (mostly via copy/paste) for what I consider simple one time system administration type duties. In the past I don't think microsoft would have shipped a product without a first class GUI to manage it (ignoring registry editing for "rare" tweaks). Now, it seems the prevalence of powershell allows some groups inside Microsoft to write a bunch of code without a functional UI, leaving the users to grub through what is effectively programming documentation to perform simple things like enabling/disabling a core feature of the product. I would expect from an architectural level, that microsoft would assure that the major functionality in their product is controllable both from the GUI as well as from the command line. That doesn't appear to be the case anymore than windows 8 can be used entirely from the metro/modern interface. Frankly, its yet another erosion of what I considered to be Microsoft's strong points against Linux.
  - commandar 12y ago
    It's somewhat ironic in that one of the Microsoft's aims has been to solve the problem of having some features that were only GUI-accessible, meaning they were difficult/impossible to automate. So PSh gets treated as the first-class interface with the GUI being a frontend to underlying PSh functionality. I've gotten away from Windows sysadmin work, but from what you're describing it sounds like they've swung the pendulum a bit too far in the other direction and no some of the GUI stuff isn't easily accessible. Having both would obviously be ideal, but if you were to put a gun to my head and make me choose, I'd take the current situation of a lacking GUI every time, personally. All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating.
arel 12y ago
Why MS never developed a truly powerful unix compatible terminal is beyond me (not cygwin). Developer buy-in and kudos alone should be incentive alone. The feeling of being restricted on windows as a developer always gets me running back to linux sharpish.
- UK-AL 12y ago
  Powershell is pretty powerful. You can do basically the same things as in bash. However because of its youth, some equivalent tools are missing.
  - GeneralMayhem 12y ago
    PowerShell is cool, but it requires learning PowerShell. Why should there be an entirely separate learning process to be able to work normally on just one OS?
    - cwyers 12y ago
      Well, because Windows is not Unix. It's not even "not Unix" the way Linux isn't Unix. Its heritage is mostly VMS and CP/M, if you want to compare it to anything. Trying to treat Windows as a Unix is a very leaky abstraction that is going to cause many more problems than it solves.
    - vertex-four 12y ago
      Why do you think all operating systems should follow one single architecture? Why should there be an entirely separate learning process from C to learn Lisp or Haskell?
  - astrodust 12y ago
    "Basically the same" and yet absolutely not the same. The world did not need PowerShell.
    - voltagex_ 12y ago
      The world didn't, but Windows admins did. It's allowed a lot of people to migrate away from legacy VBScript. You don't want to program in VBScript, trust me.
MattRogish 12y ago
Absolutely. MS is full of architecture astronauts (along with super smart people, who do useful things - but the arch people are in charge) that sit around and contemplate all these bizarre use cases for things that no one actually has. Then, since MSFT believes they have little/no competition in the space, they spend years developing this grand vision and dumping it on their customers, who then attempt to figure out what parts of this vision are useful and what parts are bunk. Microsoft then looks at what happens, sees the work arounds, and rewrites the whole thing again to accommodate not only those use cases, but a whole host of other imagined ones, too. Lather, rinse, repeat. Open source generally doesn't have this problem, as a) some developer was scratching their own itch, so the problem is real b) doesn't have unlimited time and budget, so they have to keep it small and evolve, and c) relies on developer's contributions, so it has to be marketable. Open source : Microsoft :: Lean startup : Waterfall
- raverbashing 12y ago
  SO much this MFC was bad, but there are even worse stuff Every time I have to check a new API (thankfully, not that often) it's a mess. They keep "re-solving" the same problems with new APIs that are a pain to use The .NET stuff is not too bad though (but yes, it has some warts)
- lstamour 12y ago
  Ironic since Microsoft is more agile now than it's ever been. Perhaps a backhanded compliment, but it's true. Release cycles are getting shorter and shorter throughout the company. They're playing catch-up, but they're still in the game, particularly for web services and hosted applications.

by Touche 12y ago

stephengillie 12y ago

What would it take for a homebrew language to interact with the OS as a CLR language?

ori_b 12y ago
They tried it. It's called COM. http://en.wikipedia.org/wiki/Component_Object_Model http://en.wikipedia.org/wiki/Component_Object_Model

brudgers 12y ago

PowerShell's specification is publicly available. Has been for several years. http://www.powershellmagazine.com/tag/language-specification/ http://www.powershellmagazine.com/tag/language-specification...

ygra 12y ago
You don't even need the specification to implement cmdlets. Heck, you could extend PowerShell exclusively in PowerShell code (though performance makes that somewhat undesirable most of the time).
- apalmer 12y ago
  The downsides to powershell are mostly around the fact that along with some good innovation they also threw out a lot of other standard conventions. Which makes it tedious to integrate powershell with other command line tools. Also another thing I have a problem with is the startup time, for a lot of quick hacks, I can start up, execute and close down the terminal (cygwin lets say) in the time i am still waiting for powershell to initialize. Not huge problem but for me it holds me back from using powershell somewhat.
  - ygra 12y ago
    As for command-line tools, the things that come to mind right now (that can be tedious) are 1. Result of a command-line tool is its output, not its exit code, so you have to use $LastExitCode when treating command-line invocations as boolean values 2. Stream behaviour other than stdout gets weird when redirecting one stream into another (e.g. 2>&1 causes every line that's output on stderr to be thrown as an exception. 3. Encodings are a mess, sadly. They mangle Unicode output from external programs. This was a compatibility decision, but it's unfortunate, especially because the appropriate .NET APIs are a bit clunky to use. 1 is just different from bash, 2 and 3 can be dealbreakers depending on what you do, and the workaround is the same, but annoying, admittedly. The one-second startup time has been awful, I know. Although for me at least since Windows 8 it has been instantaneous, making this a non-issue. (Pash is worse at about two seconds currently, though.) But from the time when Powershell was slow to start I still have a habit of just running cmd for things that can be done in cmd.

ygra 12y ago

PowerShell also plays nicely with COM and WMI. It's not all .NET objects you interact with. (Well, technically it is, due to PSObjects wrapping everything, but that's another matter.) How would you do it, though? Pipe around JSON or XML? Then you just have data structures, but not objects. They can't have methods and if they could, what language would they be written in?

optimiz3 12y ago
Well, if it was me... 1. Replace PowerShell with a .Net interpreter so you can "just run" a .cs_exe file or whatever. No one wants to learn/deal with yet another throwaway proprietary scripting language. 2. Replace all the PowerShell cmdlet garbage with .Net libraries. You'd also be able to then trivially automate any scripting from existing .Net programs/tests. 3. Have a JavaScript -> .Net compiler so people don't have to deal with C# or VB.Net if they don't want to. Scripts look something like (C# in this case): using Microsoft.Scripting void Main() { SQLServer.Configure(<SOME JSON>); var result = IIS.Start("MyWebPage"); if (!Installed(<some windows package>)) { File.Install() } if (!UserExists(server, user)) { CreateUser(user) } } You can't do all of this today (at least not easily or without installing many extraneous or 3rd part libs which create deployment headaches). EDIT: for clarity.
- MichaelGG 12y ago
  Microsoft has had a JavaScript compiler for a while (JScript.NET). I don't think it gets much use. They also had a Java compiler. PowerShell is far better for scripting than C#. C# is terribly verbose and lacks scripting-ish stuff like string interpolation. I'm not sure it even had dynamic when PowerShell was made. It is pretty dumb that C# still hasn't shipped a proper REPL or script runtime though.
  - optimiz3 12y ago
    JScript.net has never been a first-class citizen, and Microsoft never really made an effort to make it viable in all of the domains C# is. JScript feels like an attempt to embrace/extend JavaScript that never took hold. The problem is that rather than adding libraries to improve .Net for scripting-ish stuff like string interpolation, you have to deal with an entirely different platform that shares little with the command line, and little with .Net.

acdha 12y ago

> Great idea, piping around objects instead of text, but wait, they must be .NET objects. So the entirety of the language community cannot participate other than Microsoft languages. Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about and probably have never looked at it again. This happens a lot where people who work on big projects just assume everyone else will look past the initial experience and grasp the cool vision.

StillBored 12y ago
"Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about" I think this depends on what component/system your trying to use. Recently I found myself using powershell (mostly via copy/paste) for what I consider simple one time system administration type duties. In the past I don't think microsoft would have shipped a product without a first class GUI to manage it (ignoring registry editing for "rare" tweaks). Now, it seems the prevalence of powershell allows some groups inside Microsoft to write a bunch of code without a functional UI, leaving the users to grub through what is effectively programming documentation to perform simple things like enabling/disabling a core feature of the product. I would expect from an architectural level, that microsoft would assure that the major functionality in their product is controllable both from the GUI as well as from the command line. That doesn't appear to be the case anymore than windows 8 can be used entirely from the metro/modern interface. Frankly, its yet another erosion of what I considered to be Microsoft's strong points against Linux.
- commandar 12y ago
  It's somewhat ironic in that one of the Microsoft's aims has been to solve the problem of having some features that were only GUI-accessible, meaning they were difficult/impossible to automate. So PSh gets treated as the first-class interface with the GUI being a frontend to underlying PSh functionality. I've gotten away from Windows sysadmin work, but from what you're describing it sounds like they've swung the pendulum a bit too far in the other direction and no some of the GUI stuff isn't easily accessible. Having both would obviously be ideal, but if you were to put a gun to my head and make me choose, I'd take the current situation of a lacking GUI every time, personally. All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating.

arel 12y ago

Why MS never developed a truly powerful unix compatible terminal is beyond me (not cygwin). Developer buy-in and kudos alone should be incentive alone. The feeling of being restricted on windows as a developer always gets me running back to linux sharpish.

UK-AL 12y ago
Powershell is pretty powerful. You can do basically the same things as in bash. However because of its youth, some equivalent tools are missing.
- GeneralMayhem 12y ago
  PowerShell is cool, but it requires learning PowerShell. Why should there be an entirely separate learning process to be able to work normally on just one OS?
  - cwyers 12y ago
    Well, because Windows is not Unix. It's not even "not Unix" the way Linux isn't Unix. Its heritage is mostly VMS and CP/M, if you want to compare it to anything. Trying to treat Windows as a Unix is a very leaky abstraction that is going to cause many more problems than it solves.
  - vertex-four 12y ago
    Why do you think all operating systems should follow one single architecture? Why should there be an entirely separate learning process from C to learn Lisp or Haskell?
- astrodust 12y ago
  "Basically the same" and yet absolutely not the same. The world did not need PowerShell.
  - voltagex_ 12y ago
    The world didn't, but Windows admins did. It's allowed a lot of people to migrate away from legacy VBScript. You don't want to program in VBScript, trust me.

MattRogish 12y ago

Absolutely. MS is full of architecture astronauts (along with super smart people, who do useful things - but the arch people are in charge) that sit around and contemplate all these bizarre use cases for things that no one actually has. Then, since MSFT believes they have little/no competition in the space, they spend years developing this grand vision and dumping it on their customers, who then attempt to figure out what parts of this vision are useful and what parts are bunk. Microsoft then looks at what happens, sees the work arounds, and rewrites the whole thing again to accommodate not only those use cases, but a whole host of other imagined ones, too. Lather, rinse, repeat. Open source generally doesn't have this problem, as a) some developer was scratching their own itch, so the problem is real b) doesn't have unlimited time and budget, so they have to keep it small and evolve, and c) relies on developer's contributions, so it has to be marketable. Open source : Microsoft :: Lean startup : Waterfall

raverbashing 12y ago
SO much this MFC was bad, but there are even worse stuff Every time I have to check a new API (thankfully, not that often) it's a mess. They keep "re-solving" the same problems with new APIs that are a pain to use The .NET stuff is not too bad though (but yes, it has some warts)
lstamour 12y ago
Ironic since Microsoft is more agile now than it's ever been. Perhaps a backhanded compliment, but it's true. Release cycles are getting shorter and shorter throughout the company. They're playing catch-up, but they're still in the game, particularly for web services and hosted applications.