3 ms·

This makes a terrible case for Nushell as a shell. It makes a reasonable case for Nuhsell as a programming language. If I want a programming language I use a p

This makes a terrible case for Nushell as a shell. It makes a reasonable case for Nuhsell as a programming language. If I want a programming language I use a programming language. A shell is an interactive environment and only a programming language by way of the Turing-complete nature of its grammar. However, if I am stringing more than a couple commands together something has gone terribly wrong. The features I care about are features that make that interactivity better, not a type system.

eecc 3y ago
Uhm, so what about REPLs? Jupyter notebooks? Are they wrong? What if the typedness of the shell made the interaction better? Can you make an argument that this does not hold? The article does make a good argument in favor
- nickelpro 3y ago
  REPLs and notebooks and all the rest are great. NuShell might be a great REPL, I don't know, don't really care. The fact no one uses a REPL as a shell, and there's no demand to add direct exec() to REPLs, demonstrate they're different categories. Let programming languages do what programming languages are good at. Let shells do what shells are good at. Please do not write programs in a shell. Do not create a half-assed programming language in a shell to encourage people to write programs in said shell.
  - Per_Bothner 3y ago
    Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt. But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt. Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.
Eji1700 3y ago
The article admits basically exactly this, but also makes arguments as to why? ``` He proceeded to explain that if he could recreate many of the techniques we showed all as part of a C++ library that people could use. At this time, I wasn't sure how to respond other than "but you don't have to, we already built this language" but he couldn't be swayed. If it wasn't C++, he didn't want it. Fast forward a couple years, and I'm standing in front of a JavaScript audience giving a similar talk, this time promoting TypeScript. I remember the kind of politely confused looks on people's faces as I showed off the features TypeScript offered. There was a similar sense of "why do we need to leave JavaScript?". To answer whether Nushell can overcome this kind of inertia, I'll pose two questions: Is Nushell compelling enough for a single person to adopt it? Would adopting Nushell broadly as a community move the needle? Let's tackle the first question. Time and again, as people try Nushell, they come back with quotes like "this is the most excited I've been about tech in 15 years". It has a fanbase that loves it, and that fanbase is growing. It reminds me of the early days of Rust, just after hitting 1.0. To the second question: would adopting Nushell broadly actually improve things noticeably? Without a doubt. I say this without any reservation. Thinking of our shells as structured, interactive processing engines opens up the doors to a much wider array of things you can do with them. The commands would be far simpler than their POSIX equivalents and would compose far better. They'd benefit from the full knowledge of the data being shared between them. Adaptors could be made to connect to all parts of the system, allowing you full, structured interaction with everything you have access to. ``` I enjoy nushell, but I am far far far from the average user/target audience. I do not sys admin or anything like it, I mostly use it to quickly navigate the filesystem and, with nushell specifically, occasionally to work with data i've gotten from other things. I haven't gotten quite to the point I would write scripts in it yet, but at the point i'm considering throwing up an FSX file or going into a repl, I like that I might just be able to use nushell instead for the smaller tasks. Is this useful? To me, sure, to everyone else, hell if I know. edit- Article even touches on this mindset: > I don't need to do heavy data processing everyday, but it's nice to not have to shift what I'm doing at all when I need to do it. I don't have to download new utilities or switch languages. It's all right there. Need to write a script to load some files and handle some directory processing? Still right there. Need to throw together some web query that outputs the top download results for a github repo? You guessed it, all still right there.
coldtea 3y ago
>If I want a programming language I use a programming language. A shell is an interactive environment That's the mindset behind us still having crappy shells...
- nickelpro 3y ago
  If being a good programming language is what makes a shell good, use the Python repl
  - coldtea 3y ago
    The false dichotomy is the issue. There's no reason (compatibility aside) a shell can't be both a great interactive environment and offer a great language (one 10x more well designed and consistent than what it offers now).
    - em-bee 3y ago
      you just made the claim that people who prefer real programming languages are the reason for bad shells. if there is a false dichotomy, that would be it. sure it is possible to have both, but the focus of the shell needs to be on interactivity. i don't at all care if the shell has a good programming language. i only care about good interactive features. there is a lot of overlap though, as a good interactive shell does benefit from a better language syntax and from things like types, arrays, etc.
      - coldtea 3y ago
        >you just made the claim that people who prefer real programming languages are the reason for bad shells No, I made the claim that people who think shells and "real (sic) programming languages" are distinct categories, and can't be otherwise, and use it support the idea that current shells are fine, are the reason for bad shells. >sure it is possible to have both, but the focus of the shell needs to be on interactivity As if those are contradictory goals? A shell can have a much much better real programming language AND BE interactive. >i don't at all care if the shell has a good programming language. i only care about good interactive features. Hence my false dichotomy complaint.

eecc 3y ago

Uhm, so what about REPLs? Jupyter notebooks? Are they wrong? What if the typedness of the shell made the interaction better? Can you make an argument that this does not hold? The article does make a good argument in favor

nickelpro 3y ago
REPLs and notebooks and all the rest are great. NuShell might be a great REPL, I don't know, don't really care. The fact no one uses a REPL as a shell, and there's no demand to add direct exec() to REPLs, demonstrate they're different categories. Let programming languages do what programming languages are good at. Let shells do what shells are good at. Please do not write programs in a shell. Do not create a half-assed programming language in a shell to encourage people to write programs in said shell.
- Per_Bothner 3y ago
  Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt. But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt. Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.

Eji1700 3y ago

The article admits basically exactly this, but also makes arguments as to why? ``` He proceeded to explain that if he could recreate many of the techniques we showed all as part of a C++ library that people could use. At this time, I wasn't sure how to respond other than "but you don't have to, we already built this language" but he couldn't be swayed. If it wasn't C++, he didn't want it. Fast forward a couple years, and I'm standing in front of a JavaScript audience giving a similar talk, this time promoting TypeScript. I remember the kind of politely confused looks on people's faces as I showed off the features TypeScript offered. There was a similar sense of "why do we need to leave JavaScript?". To answer whether Nushell can overcome this kind of inertia, I'll pose two questions: Is Nushell compelling enough for a single person to adopt it? Would adopting Nushell broadly as a community move the needle? Let's tackle the first question. Time and again, as people try Nushell, they come back with quotes like "this is the most excited I've been about tech in 15 years". It has a fanbase that loves it, and that fanbase is growing. It reminds me of the early days of Rust, just after hitting 1.0. To the second question: would adopting Nushell broadly actually improve things noticeably? Without a doubt. I say this without any reservation. Thinking of our shells as structured, interactive processing engines opens up the doors to a much wider array of things you can do with them. The commands would be far simpler than their POSIX equivalents and would compose far better. They'd benefit from the full knowledge of the data being shared between them. Adaptors could be made to connect to all parts of the system, allowing you full, structured interaction with everything you have access to. ``` I enjoy nushell, but I am far far far from the average user/target audience. I do not sys admin or anything like it, I mostly use it to quickly navigate the filesystem and, with nushell specifically, occasionally to work with data i've gotten from other things. I haven't gotten quite to the point I would write scripts in it yet, but at the point i'm considering throwing up an FSX file or going into a repl, I like that I might just be able to use nushell instead for the smaller tasks. Is this useful? To me, sure, to everyone else, hell if I know. edit- Article even touches on this mindset: > I don't need to do heavy data processing everyday, but it's nice to not have to shift what I'm doing at all when I need to do it. I don't have to download new utilities or switch languages. It's all right there. Need to write a script to load some files and handle some directory processing? Still right there. Need to throw together some web query that outputs the top download results for a github repo? You guessed it, all still right there.

coldtea 3y ago

>If I want a programming language I use a programming language. A shell is an interactive environment That's the mindset behind us still having crappy shells...

nickelpro 3y ago
If being a good programming language is what makes a shell good, use the Python repl
- coldtea 3y ago
  The false dichotomy is the issue. There's no reason (compatibility aside) a shell can't be both a great interactive environment and offer a great language (one 10x more well designed and consistent than what it offers now).
  - em-bee 3y ago
    you just made the claim that people who prefer real programming languages are the reason for bad shells. if there is a false dichotomy, that would be it. sure it is possible to have both, but the focus of the shell needs to be on interactivity. i don't at all care if the shell has a good programming language. i only care about good interactive features. there is a lot of overlap though, as a good interactive shell does benefit from a better language syntax and from things like types, arrays, etc.
    - coldtea 3y ago
      >you just made the claim that people who prefer real programming languages are the reason for bad shells No, I made the claim that people who think shells and "real (sic) programming languages" are distinct categories, and can't be otherwise, and use it support the idea that current shells are fine, are the reason for bad shells. >sure it is possible to have both, but the focus of the shell needs to be on interactivity As if those are contradictory goals? A shell can have a much much better real programming language AND BE interactive. >i don't at all care if the shell has a good programming language. i only care about good interactive features. Hence my false dichotomy complaint.