The case for Nushell, https://www.jntrnr.com/case-for-nushell/.
Relevant article about shells, and how Nushell pushes the boundaries further. I highly recommend reading it.
The case for Nushell, https://www.jntrnr.com/case-for-nushell/.
Relevant article about shells, and how Nushell pushes the boundaries further. I highly recommend reading it.
@hywan @Keltounet Question: "can the state of shells be improved enough to overcome the inertia of sticking to what you know?"
This is the wrong question. It presupposes zero cost of transition, while the cognitive workload of learning a new shell rises exponentially with age (hint: I'm nearly 60, shells are harder to adapt to than a new GUI). Stability and continuity are essential prerequisites to productivity!
@cstross @hywan I see your point 😁 I'm a lower level kind of guy anyway
@Keltounet @hywan Computing is not my job. It hasn't been my job for over two decades. Time spent learning a new shell or thinking about computers is time *wasted* from the non-compsci point of view.
Thing is, the question about the utility of switching to a new shell has embedded ideological assumptions that implicitly privilege computing over applications. To 99% of the world applications of computing are the priority; the machines and software are just an annoying drag on getting stuff done.
@cstross @hywan we could say the same for languages, both in real life and computing. I'm 56 and enjoying learning both Rust and Japanese 😅
And looking into nutshell too.
@hywan my issue with nushell (and powershell) is that as cool as passing typed objects between commands instead of plaintext streams is, it's simply less flexible. If everything takes and transforms text streams, absolutely anything that produces any kind of textual output is fair game for reaching into and manipulating and adding to the pipeline, as long as you know awk and regex sufficiently. With this, you're more limited to what the shell supports. Not only that, but this plus being a typed language makes nushell much more rigid. Which makes it a far better programming language, but a far worse shell — because the entire POINT of a shell is being a programming language that is *intentionally bad* in order to optimize for maximum flexibility and brevity and convenience for immediate tasks. Adding types and such actually de-optimizes the language for use as a shell. It's why no one wants to use like, Python or TypeScript as their shell!
@ncweaver one of the biggest failings in the field is the obsession with novelty, often for its own sake, as well as the constant reinventing the wheel. We never seem to learn much from mistakes as an industry either.
@cstross @Keltounet @hywan
Even as someone who's job IS computing I agree.
Heck, I still use csh/tcsh and emacs (no-window mode) because it works for me. Command line shells are really important for my workflow, but I'm not going to change to another shell unless there is some huge benefit in my workflow. And there isn't.
This is unlike, say, going to better languages like Golang where there is a benefit to me in productivity.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.