Hacker News Reader

Comment by Touche | Hacker News Reader

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

View on HN

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

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.

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)

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?

I don't think we can design this in HN comments... all I'm saying is that it should have been a Day 1 requirement that it is low-level enough to work with any modern widely-used programming language, on a first-class basis.

That's what the comment I quoted is saying, Microsoft likes to do big up-front designs that restrict their platform to uses that they have already thought about.

Powershell was an internal grass roots product, I think. I read it somewhere so may or may not be true.

Snover specifically set out to design "the next generation platform for administrative automation" in 2002. See the Monad Manifesto:

http://www.jsnover.com/Docs/MonadManifesto.pdf

And Snover's description of the process almost a decade later:

http://www.jsnover.com/blog/2011/10/01/monad-manifesto/

Was there a connection to the math/CS concept of "monad", or did Snover intentionally pick a name that would guarantee eveyone would be afraid of it?

from http://www.jsnover.com/blog/2011/10/01/monad-manifesto/ > I had had a number of conversations with our team in India where everyone shook their heads and smiled and seemed to get it but then the code clearly demonstrated that they had absolutely no clue what I was saying but weren’t telling me that. > We tried a number of times to get very precise in our documentation but time and time again, it was clear that they just weren’t getting the concept

Wow, Microsoft Architechture Astronaut in a nutshell. He handwaves an idea, and then complains when someone actually writes some code and it doesn't match his imagination.

It's explained in Windows PowerShell in Action that is written by Bruce Payette, one of the PowerShell designers:

"before the first public release in 2006, the codename for this project was Monad. The name Monad comes from The Monadology by Gottfried Wilhelm Leibniz, one of the inventors of calculus. Here’s how Leibniz defined the Monad:

The Monad, of which we shall here speak, is nothing but a simple substance, which enters into compounds. By “simple” is meant “without parts.” —From The Monadology by Gottfried Wilhelm Leibniz (translated by Robert Latta)

In The Monadology, Leibniz described a world of irreducible components from which all things could be composed. This captures the spirit of the project: to create a toolkit of simple pieces that you compose to create complex solutions."

I'm having trouble understanding what is needed. The 'shell' in PowerShell is an interface to an operating system interface, .NET. While Microsoft's implementations of C#, &rest can call PowerShell scripts and cmdlets, it's a bit kludgey compared to calling the API directly. Other than effort, there is nothing preventing creation of a library with equivalent function in any language, and the effort is what killed IronRuby and IronPython as continuously developed projects...and they didn't use powershell.

Can you provide an example?

You can write cmdlets in C# and VB, not just call Powershell cmdlets/scripts. You should be able to write cmdlets in Ruby, or Node.js or Brainfuck.

OK, I get what you want. My understanding is that the reason you can write a cmdlet in C# is because C# provides a facility to return .NET objects [more or less] and that's only in so far as it interops with the .NET API.

Ruby implementations will tend to return a byte stream rather than a value a value against the .NET API. Even if Microsoft provided another API on top of the .NET API, the same situation would exist because Ruby implementations usually don't write to that API by default. It's turtles all the way down on the .NET side.

Programming .NET in Ruby requires writing to the .NET interface from the Ruby program. If one wants to program to the .NET interface through Powershell from Ruby, a Ruby program can always output text that can be interpreted as a Powershell script. One way or another, the responsibility is on the program to write to an API.

What would be the output of a Brainfuck program that should operate as a PowerShell cmdlet? Would it ever be more than text which can be interpreted as a PowerShell command or script?

You're entirely missing my point. Powershell shouldn't have been written to require .NET. Full-stop. That's a deal-breaker and highlights the quote I original referenced. Stop building high-level stuff on top of other high-level stuff where it's uses are restricted to only a small subset of potential developers.

i think you can write cmdlets in anything that compiles down to IL. So i am guessing you could write them in IronRuby or IronPython. Might be mistaken about that though.

also you can use the '&' operator to call anything executable, so you could take an exe and call it from powershell without issue

It's still a shell. No need to use

    & 'externalProgram.exe'

when you can just use

    externalProgram.exe

just as well. I see a lot of weird things on Stack Overflow with & or even Invoke-Expression, especially when it involves passing parameters to programs and the lack of understanding how parameter passing works. The results usually aren't pretty, then.

Pretty sure you need & to call a variable, like & $git if you've a var pointing to git instead of having in the path.

> How would you do it, though? Pipe around JSON or XML? Then you just have data structures, but not objects

"just data structures" is a subset of objects - they are objects with data but no methods. i.e. DTOs. They're not always useful, but to say that they can't be accommodated in a pipeline because they "aren't objects" is not quite right.

Granted, but a lot of niceness in PowerShell comes from the fact that you're not just piping around objects. As in, you don't need special commands to handle certain sorts of output (though there are things liks Stop-Service, Stop-Process, etc.) because you can just as well call the appropriate methods.

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

You could pipe around DTOs like that, and as long as they had a structure that attached typing information to them, you could use something like intents (similar to those in Android or Web Intents) to attach "methods" to them. The executables implementing behavior could be written in any language that the platform could run.

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.

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.

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.

It is pretty dumb that C# still hasn't shipped a proper REPL or script runtime though.

Workin' on it.

This is an amazing repl recently released:

http://channel9.msdn.com/coding4fun/blog/REPL-for-the-masses...

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

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

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.

"All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating."

BTW: In the past (because I don't do a lot of this anymore either), GUI operations were automatable with one of the dozens of clones of the windows macro recorder. The ones I remember using had their own little scripting languages (which could be automatically generated/recorded) with simple variable substitution and control flows. The resulting scripts were callable from the command line/batch files. Those products overwhelmingly relied on the ability to walk the GUI resource trees and find things by id/name/some attribute and then send messages like clicking or typing to them. How well applications like this still work in a metro/modern environment I don't know. Although a google search indicates a number that are still available.

BTW: For the linux/X users out there, check out http://www.gnu.org/software/xnee/

PowerShell's specification is publicly available. Has been for several years.

http://www.powershellmagazine.com/tag/language-specification...

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

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.

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.

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.

Powershell is pretty powerful. You can do basically the same things as in bash.

However because of its youth, some equivalent tools are missing.

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?

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.

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?

"Basically the same" and yet absolutely not the same.

The world did not need PowerShell.

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.

(I'm assuming you don't mean a terminal emulator, but a command-line shell when you say »unix compatible terminal«.)

The team that developed PowerShell actually wanted to do just that. They didn't, because Unix was built mostly around text files, so tools that work with text files are a good way to manage such a system. Windows however, is not, so Unix tools are a particularly poor way of managing Windows.

That's also why PowerShell treats file system, registry, WMI, etc. as first-class constructs, because it has to to be effective.

> That's also why PowerShell treats file system, registry, WMI, etc. as first-class constructs, because it has to to be effective.

Also- it exposes them as filesystems & files.

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

They tried it. It's called COM.

http://en.wikipedia.org/wiki/Component_Object_Model

Reply on news.ycombinator.com