Hacker News Reader

Comment by felixfbecker | Hacker News Reader

This looks great, but what exactly are the benefits over PowerShell? The article mentions PowerShell, then says:

> What if we could take the ideas of a structured shell and make it more functional? What if it worked on Windows, Linux, and macOS? What if it had great error messages?

- Any shell with piping is already very functional, and PowerShell has script blocks (higher-order functions). Or does this mean "functional" in the literal sense? What functionality is missing? - PowerShell works on macOS, Linux and Windows - The examples of error messages further down look almost exactly like PowerShells error messages (underlining the command in the pipeline that failed)

It is not clear to me what exactly the authors sought out to do different

View on HN

I wanted to like PowerShell but I find the syntax choices absolutely exhausting. This looks far more comfortable to me even as someone who mostly uses Windows but also knows Unix shell.

That's why I wish this shell could replace both bash and PowerShell in the real life. That's a pity this is highly improbable.

Why not? On your own system you can use whatever shell you want and if you develop shell scripts that you plan to distribute you can just list it as a dependency.

I know the long cased commands like Foo-Bar can be alienating to Unix folks at first, but have you tried just using aliases and not caring about casing? PowerShell will accept any unambiguous case-insensitive abbreviation of commands and parameters, and has almost all frequently used commands aliased (see this thread, it's literally the same as nushell).

I often wonder if people just don't like it because all they see is PowerShell scripts, where people like to spell out commands so it's clearer what they do. Imo it's a nightmare that we write bash scripts with all these 2-3 letter commands and flags that no beginner could ever understand. (but if you want to write that way even in scripts, nothing is stopping you)

> I know the long cased commands like Foo-Bar can be alienating to Unix folks at first, but have you tried just using aliases and not caring about casing.

You'd have to alias every command and every option to make it enjoyable for interactive use.

And of course those aliases would need to be part of the standards powershell.

"PowerShell will accept any unambiguous case-insensitive abbreviation of commands and parameters, and has almost all frequently used commands aliased"

> PowerShell will accept any unambiguous case-insensitive abbreviation of commands and parameters.

Which due to the naming conventions are still too verbose.

I'm more of a Windows and C# guy, and even I just can't get along with the naming and syntax.

I tried using aliases instead, but there is a danger with this - some of the aliases are commands on Linux. For example, if I use the `ls` alias it will work as expected on Windows, but if you run the script on Linux, it will run the Linux `ls` command, rather than whatever the Powershell alias is for.

It's not the name of the commands that bother me; it's literally everything else from the operators, the sigils, to how functions are defined.

There is no excuse to make a new language that re-invents nearly every basic syntactic principle or borrows from the worst examples (bash, perl).

Although the naming isn't great either; the use of namespace prefixes rather than a flat namespace of long names might have been a better (and more logical) choice. It would have even allowed for better auto-complete.

They clearly know about PowerShell. They acknowledge it as an inspiration and the core concept is the same.

That doesn't mean there aren't ways to improve upon PowerShell.

As a light user of PowerShell I consider it a poor implementation of a great idea.

Commands are way too long, control structures have poor syntax etc.

To make this very concrete, take this example from nu:

    ls | where size > 4kb

Now give me an equivalent in PowerShell and then let's talk about how different Nu is from PowerShell.

  dir |where length -gt 4kb

Let's talk.

The equivalent, btw, is:

  ls | where length -gt 4kb

The only difference is powershell uses “>” and “<” for redirection, and so uses mnemonic operators for comparisons.

Nu doesn't seem to support redirection (or even have anything other than one input and one output stream, though metadata might serve the purposes otherwise served by additional streams; it's not how a program would return something Nu would treat as metadata, though.)

I guess that with a structured-data shell, error type of info could just be returned in-band under a different tag, in any case.

Complaining about command length when PS explicitly had full fledged named commands (for readability) and default aliases (for terseness) doesn't make sense imo.

Take your pick:

    # most common in script, vs at shell
    Get-ChildItem | Where-Object { $_.Length -gt 4kb }
    gci | where length -gt 4kb


    # longest most restrictive with namespaces, 
    # most stable over time, 
    # least risk of hitting the wrong command 
    # or wrong property as surroundings change
    Microsoft.PowerShell.Management\Get-ChildItem | Microsoft.PowerShell.Core\Where-Object -Property Length -gt 4kb


    # shortest(?)
    gci|? le* -gt 4kb


    # because you can
    switch(gci){{$_.length-gt4kb}{$_}}
    gci | & { process{ if($_.Length -gt 4kb) { $_ } } }
    $larges, $smalls = (gci).where({$_.length -gt 4kb}, 'split')
    [linq.enumerable]::where([string[]][io.directory]::EnumerateFiles($pwd), [func[string,bool]]{param($f) [io.fileinfo]::new($f).Length -in 0..4kb})

In Powershell you can tab complete "Length" in the filter, from the available properties of the objects coming out of gci, which is neat.

PowerShell has some great ideas, but I can think of quite a few things that can be improved in (or over) PowerShell: its abysmal speed, its verbose syntax, verb-noun structure which is much less useful than noun-verb would have been...

Is there any noun-verb shell?

Don't think there's a noun-verb shell, but in PowerShell the deficiency is obvious. Here's an example posted in a later link in this thread:

"Get-Process | Out-GridView -PassThru | Stop-Process"

Now, is it "Stop-Process" or "Set-Process -Status Stop"? "Out-GridView" or, say, "Show-GridView" or "Out-View -Grid"? The other examples are all technically legal, and other modules can and do have such inconsistencies.

With verb-noun, I can't meaningfully complete for the verb when I don't know it, I can complete for the noun if I know part of it. But I usually know the noun, so that's not so useful.

With noun-verb, I could get a meaningful verb completion and still be able to complete nouns - with some duplication of results, though I think there could be a way to have some semi-completion for the noun only. A semi-completion isn't useful in the verb-noun case, since the program can't guess the noun yet and different nouns may have different verb uses.

Last I tried Powershell (on Linux, that is) it was so slow that I simply gave up, frustrated.

I really like the concept, but the slowness ruined the user experience for me.

> This looks great, but what exactly are the benefits over PowerShell?

To my perspective, making parsing for a variety of text-based formats a default action is an advantage, because it means tools don't have to use a particular runtime (e.g., .NET) to feed objects into shell pipelines without the shell user doing explicit conversion.

Maybe I'm misunderstanding you, but isn't this what the ConvertFrom-{Json, Xml} etc are for?

For one Powershell isn't libre as in freedom am I right.

MIT

https://github.com/PowerShell/PowerShell/blob/master/LICENSE...

More than enough libre :)

Reply on news.ycombinator.com