Hacker News Reader

Comment by sz4kerto | Hacker News Reader

> The script was 11 lines long (vs 3 lines in Python), it was harder to read and understand.

Note that this might be true for one script, and the opposite might be true for another script. Something is saner in bash, something is better in PS. They have fundamental differences (text- vs. object-based), and neither of them is better than the other in all scenarios. (At least that's my experience.)

View on HN

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem.

With Bash you get a wealth of tools because everything can handle text.

> With Bash you get a wealth of tools because everything can handle text.

I think technically it should be no problem to write some package for most programming languages for interopting with .net objects. In this sense about everything could also handle .net objects.

> With Bash you get a wealth of tools because everything can handle text.

And no autocomplete.

Unix command line autocomplete is fairly good, but it's not useful for discovery of new features or for helping you figure out a CLI without reading anything. It is quite effective at helping a user who knows what they're avoid keystrokes, though.

Bash completion is inferior. It doesn't understand types.

I didn't get this, could you elaborate? Does powershell autocomplete objects it is about to ingest, and before you run the command?

PowerShell v3+ can autocomplete command names, command switches and switch values (if they're a strict set). It can also autocomplete object properties yes.

    $dir = gci
    $dir.<tab> -> $dir.Count

> command names, command switches and switch values (if they're a strict set).

So can bash. How is this different from bash's autocompletion?

> also ... object properties

Well, there aren't objects in bash, so I can't translate this.

Yes, but the downside of that is you have to munge the text to do things with it, while with .NET objects you often don't have to do that. And PowerShell certainly does provide facilities for dealing with text, so you can use other languages' tools within PowerShell (and I think with some use of Out-String and similar you could go the other way well enough).

PowerShell objects are actually a superset of . Net objects. They can also represent COM objects, WMI objects, XML nodes, etc. You can also export them to CSV, XML, JSON, and yes, even text. If you have cygwin installed you can pipe to and from the cygwin commands from PowerShell and pipe to and from powershell.exe from your cygwin shell.

Languages are not the same, you'll never have interoperability; try exporting a .NET object with a 64-bit integer to be consumed by JavaScript, for example. Text wins.

You would serialise it?

$obj = [PSCustomObject]@{ Number = [long]2 }

$obj | ConvertTo-Json

Try with the number 9223372036854775807. Then try consuming this JSON in Node.

$obj = [PSCustomObject]@{ Number = [string]9223372036854775807 } $obj | ConvertTo-Json

The lack of decent types, is surely a weakness of js?

You can have interoperability, COM does it well on Windows. JavaScript, .net, Python, ruby, C, C++ can all access COM methods and attributes.

PS C:\> 0x1234567812345678

1311768465173141112

PS C:\> 0x1234567812345678 >.\foo.txt ; cat .\foo.txt

1311768465173141112

PS C:\> "WScript.Echo('$(0x1234567812345678)')" >.\foo.js ; cat .\foo.js ; cscript //nologo .\foo.js

WScript.Echo(1311768465173141112)

1.31176846517314E+18

...

I'm not seeing your point.

> I'm not seeing your point.

JavaScript does not have 64-bit integers. So if you exported an object with 64-bit integers to XML, for example, a JavaScript program could not (correctly) deserialize that XML.

Javascript doesn't really have integers, at all, so...

Googled "powershell ironpython" and got this[0] as first result. Before that, I was going to point out that IronPython, despite it's performance issues and nitpicky differences (there's no 'struct' module, but there's '_struct', which is... struct and they somehow forgot to rename) is still considered a .NET language.

If there's anything wrong with the article (for one thing, it's 4 yo), please point it out. I just brought this up because the IronPython part of .NET is usually forgotten, though still there and has some interesting uses.

[0] http://www.pythondiary.com/blog/Jun.26,2012/ironpython-and-m...

You're missing my point.

Could you please be more explicit about it then?

The part about the .NET objects has already been addressed by others, and I actually like that -- right now at work we're wrestling with a few command line applications that output text (in full UNIX-style) and it's a mess to parse the thing, because it's so badly documented. If we had objects as a result it'd be glorious (not that PS would help, this isn't a bash script we're working with/against).

> Could you please be more explicit about it then?

Sure, it doesn't work with CPython. I shouldn't need to be that explicit though, bring up IronPython is one hell of a nit.

> With Bash you get a wealth of tools because everything can handle text.

... and all those tools work seamlessly in Powershell, too. .NET objects are passed around within Powershell, but traditional dumb text is used for out-of-proc stuff. Where is the "fatal flaw?"

I don't understand where the perceived downside is - you wish Powershell was implemented in Python, not .NET?

> Where is the "fatal flaw?"

The fatal flaw is that I have to distinguish between "within Powershell" and "out-of-proc". I simply don't have this issue with plain text; I don't know or care what language/runtime the programs I use are written in/for because they all use the same interface.

Reply on news.ycombinator.com