2 ms·
I worked with PowerShell in a past life, and found it quite useful and reasonably pleasant[1] (esp. when coming from standard Windows Shell), however it's this:
by angusgr 15y ago
I worked with PowerShell in a past life, and found it quite useful and reasonably pleasant[1] (esp. when coming from standard Windows Shell), however it's this:
In PowerShell you can directly instantiate .NET and COM objects
... that I think will keep it from being especially useful on non-Windows platforms.
Windows has COM objects for pretty much every language/app/platform feature pre-2003, and .NET objects for pretty much everything since. To be equivalently useful, then a ported version would need to find the equivalents on their new platform. That sounds hard to me, especially on platforms like Linux where you have a half-dozen different desktop API possibilities and where the historical focus is on text files, not APIs, for configuration & control.
Without object models to leverage, a PowerShell port will be limited to replicating everything with wrapper objects: starting from Bash functionality, then coreutils, and then slowly working up.
[1] TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life.
- Niten 15y ago> however it's this [...] that I think will keep it from being especially useful on non-Windows platforms. Sure, and I acknowledge as much in my post above, that PowerShell's object orientation is most appropriate for the Windows environment. But even if you aren't concerned with COM, I still think PowerShell is pretty nice, and I wouldn't mind seeing a port to Linux. So for that reason I welcome its addition to the Community Promise. > TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life. I don't think that would have worked well... You have to keep in mind that PowerShell is intended to be used interactively, and this has all sorts of implications for the language design. For instance when you type PS > foo at the PowerShell command line, "foo" may be a pure PowerShell function, but it could also be a cmdlet, or an external command somewhere else on the system. If this were a straight Python REPL instead, you'd have to do external calls differently from Python function calls, like so: Python > system("foo") and that gets old real fast. Likewise you need to allow bare strings and ditch parentheses for function calls so you don't wind up saying cd("C:\"). You'd also have to come up with a more succinct syntax for chaining Python generators assuming that's what you want to use as a substitute for PowerShell's cmdlets. Plus there are concerns like, hey, we can't use the backslash as a string escape operator, because suck as it may, that's the traditional path separator on Windows, so we've gotta make it something else. By the time you're done, it's not even Python any more. And on top of all that: in my opinion, as much as I love Python, significant whitespace really sucks for REPLs... So I don't think Python would have been an appropriate choice for a new Windows command line interface. But the great thing about PowerShell is that even if it isn't interactive Python, you can always implement cmdlets for it in IronPython (or pretty much any other .NET language)...
- angusgr 15y agoFair enough Re: differences between Python & PowerShell syntax. I don't entirely agree with you on the REPL point, because I use Python in a REPL all the time (esp. with ipython.) However, I agree with the rest. Although you could always define additional statements (ala print in Python 2.x), it could get messy very fast.