[necovek]

Homepage is enough to convince me not to care even regardless of it being JavaScript: no simple piping support with the explanation that you should work on smaller sets of structured data.

Except when you don't and then have to decide which hoops to jump through to get reasonable stream processing in the shell.

[Ninroot]

Shell can be invoked using `$` if your use cases requires stream processing. This might be handful if you still want to benefit from traditional shell features while being in Nacre.

[necovek]

Thanks: that kinda defeats the purpose for me. If every week I have to drop out once or twice into regular shell since I'd be more efficient, I have to keep both syntaxes fresh, which is harder if you only use one occasionally.

[Ninroot]

I think this is already the case for a lot of people who code in JS all day. Once in a while, they need to do something simple in a shell that requires to have a look at the syntax.

I bet someone coming from JS background wouldn't have to check how to do `ls().map(whatever)`

But they will definitely need it to do `for d in */ ; do whatever(); done`

[necovek]

I get the desire to implement loops with JS in a new shell.

What I don't get is why not include piping support in it natively, instead of suggesting to go through JS-native stream processing which most are likely unfamiliar with (I am not, but I am not a full time JS dev either)?

[Ninroot]

Adding piping to the language involves a lot of breaking changes. Vanilla node would no longer be able to run nacre scripts without going through nacre binary, making it less portable. Highlighter would need to be updated given the new syntax. Typescript would not be happy either. The tools we seek to create "smart" completions that rely on type inference would also be broken. In short, the work of thousands of smart people would suddenly become incompatible.

This might clarify "I get the desire to implement loops with JS in a new shell." => no implementation has been done, everything is already provided by Node. Instead, we focus our energy on making vanilla JS as intuitive as possible.