[HN Gopher] The Dune Shell
___________________________________________________________________
The Dune Shell
Author : thunderbong
Score : 148 points
Date : 2024-09-16 12:12 UTC (2 days ago)
(HTM) web link (adam-mcdaniel.github.io)
(TXT) w3m dump (adam-mcdaniel.github.io)
| hi-v-rocknroll wrote:
| I like the ideas of Dune and Nu, which I think were trailblazed
| by powershell to a degree. The problems of pure *NIX pipe
| philosophy with text as the lingua franca were persistent parsing
| problems and escaping. However, the problems of going to far in
| the way powershell went was it was too radical having to
| reimagine/replace/relearn almost everything, and generally more
| difficult to accomplish simple text manipulation. Nu at least
| maintains most of the *NIX shell UX. Maybe at some point in the
| future, we will reach parity to where there will fusion of the
| main DSLs, shells, and programming languages into a runtime
| interaction system that is somewhere between psql, Erlang shell,
| nu, and Squeak where there is programming language-OS parity
| obliterating the distinctions between programming languages,
| command shells, and DBMS shells. One can dream of a future where
| perhaps it will be possible to write a function, library, or
| program in any language one chooses and call it from any other
| shell or language without swig or ceremony.
| wodenokoto wrote:
| > too radical having to reimagine/replace/relearn almost
| everything
|
| I switched to zsh because at the time I thought it had better
| autocomplete, but honestly I use it as I would bash. And I
| don't think it was worth it to change a little bit.
|
| To change shell I think the change _should_ be radical.
| idunnoman1222 wrote:
| But it is bash...
| kitd wrote:
| A day or so there was this:
| https://news.ycombinator.com/item?id=41558081
|
| Imagine your shell's model not being a command line console but
| a spreadsheet!
| actionfromafar wrote:
| Shades of Q, APL and other array languages, but visual by
| default. Maybe an APL spreadsheet-shell would fit the bill?
| :-D
| ghayes wrote:
| I wonder if there's a good middle ground where unix commands
| could opt into a structured output, and until they exist, you
| could shim via `ls -la | shim "ls -la" |> ".modified_time"`.
| Then one day it could be `ls -la |> ".modified_time"` when
| structured data is supported natively by the program or
| command. I feel every project ends up dying since it needs to
| support every command all at once to be useful.
| actionfromafar wrote:
| To me the silly hang-up for PowerShell is none of that, but the
| strange syntax. I'd taken (even!) JavaScript-ish syntax over
| that.
| packetlost wrote:
| > One can dream of a future where perhaps it will be possible
| to write a function, library, or program in any language one
| chooses and call it from any other shell or language without
| swig or ceremony
|
| I mean, there's a reason text was selected, it's the lowest
| common denominator. What you're asking for is universal FFI,
| which we already have that for the most part: C. The problem
| ultimately turns into runtime and resource management issues
| when crossing language boundaries, that is, unless you use OS
| primatives (pipes, sockets, shared memory, processes, etc.) and
| use message passing/pipelines exclusively. Then we're back to
| plaintext.
|
| There's a ton of non-printable characters in ASCII that are
| useful as delimiters for non-keyboard interactive programs that
| are largely vestigial. One could at least consider reusing them
| for delimiters and special control sequences for message
| passing, but without some sort of standardization it's limited
| in practical use.
| Brian_K_White wrote:
| The problem with those ascii values is editors don't display
| them and there are no keyboard keys to type them.
|
| The reason csv exists is because you can actually see and
| type all parts of it, on anything, any platform, any
| hardware, any software, any age, even a mechanical
| typewriter, even a pencil. That is not merely nice, it's
| essntially priceless, infinitely, incalculably valuable. The
| utility outweighs the problems as big as they absolutely are.
| Actually the same is true for json, yaml, xml...
| packetlost wrote:
| > The problem with those ascii values is editors don't
| display them and there are no keyboard keys to type them.
|
| Did you read my post? Like, every word of it? Being able to
| type a control sequence is not particularly useful for
| ephemeral data in a message-passing between programs
| context. It's absolutely important for persistent, editable
| data. It seems like more of a feature to me to use these
| special characters for special contexts and not have
| escaping typeable characters be load-bearing.
|
| Further, my editor seems to print control characters just
| fine, though entering them would be a bit of a pain and the
| behavior is likely configurable.
| WorldMaker wrote:
| Instead of inventing some new delimited formats, we also
| already have nearly ubiquitous interchange formats like JSON.
| If you wanted to reduce the in memory footprint versus
| plaintext encoding the JSON there are good options like BSON
| and CBOR.
| chrisweekly wrote:
| Interesting thought experiment. Reminds me of my cousin's
| project Xonsh https://xon.sh/
| BeetleB wrote:
| Happily been using xonsh for the last 6 years. Strongly
| recommend.
| Brian_K_White wrote:
| The problem of powershell is not merely thet it's new and
| different, and not merely that you have to learn a new and
| different way to get a given task done.
|
| Powershell makes some things possible or easier that weren't
| possible or easy, but only at the expense of making other
| things either impossible or at least vastly less practical, and
| all in all it's a bad trade off and a wrong set of priorities
| for the job it claims to fill, or at least for the job bash
| currently fills. It's not that bash is a gold standard, just
| that it's not _fundamentally wrong_.
| xelamonster wrote:
| It's also just absurdly verbose for a language intended
| mainly for manual input. I get annoyed having to type out
| `sudo systemctl` multiple times in a row, in Powershell every
| single command is at minimum that long. Which makes it way
| more difficult to memorize the commands too.
| Vegenoid wrote:
| IMO, getting comfortable with and tuning autocomplete makes
| this a non-issue, and the benefit of the verbose commands
| is that they are very discoverable.
| rustyminnow wrote:
| Any tips or links for tuning? zsh has a powerful engine
| and lots of great work out there, but when I've tried
| cooking my own it's all just too dense to get
| "comfortable" for long.
| WorldMaker wrote:
| For VS Code there is a good first-party PowerShell
| extension which helps a lot at writing scripts in the
| verbose style.
|
| There's experimental new IntelliSense available in the VS
| Code terminal:
| https://code.visualstudio.com/docs/terminal/shell-
| integratio...
| WorldMaker wrote:
| There are ton of aliases. It's "impolite" [0] to use
| aliases in scripts and documentation so looking at
| PowerShell examples is way more verbose than actually using
| it day to day in a REPL. Sure I could write `Set-Location`
| a million times a day, but I just use `cd` in the old ways.
| Same with `Get-ChildItem`, I tend to just use `ls` myself
| because of ancient habits. (I find it interesting how many
| have been moving to `gci` instead as the more PowerShell-
| native `ls` alias. I've not been convinced to do that
| myself, but I think it has to do with `gci` is way more
| powerful than most shells' `ls` and is used to navigate
| everything from folder structures to object structures
| including that its not a bad `jq` if you convert JSON files
| to PowerShell objects.)
|
| [0] It's from a version of the Python ethos that code is
| read way more often than it is written, so when you are
| polishing PowerShell code to share with others you expand
| all the aliases so that it is easier to read.
| frenchyatwork wrote:
| What about the part of the Python ethos where "There
| should be one-- and preferably only one --obvious way to
| do it"
| WorldMaker wrote:
| A) PowerShell isn't Python, it doesn't have to (and
| doesn't) import the whole Python ethos, just the parts
| that make sense for a Shell and Shell language with
| different end goals.
|
| B) PowerShell doesn't care as much about the first part
| because shells have always had aliases and macros, but it
| does care about the second half "obvious way to do it".
| The other reason for starting with verbose names and
| aliasing them for day to day REPL use is to aid
| discovery. It's often very easy to discover which command
| or cmdlet does the thing you need simply because it is
| right there in the name. Sometimes you can just guess the
| name because there are only so many "allowed" verbs and
| you just need the noun you want to "verb". `Get-Help` can
| be quite powerful, `Get-Verb` can help explain some bits
| about what the verbosity is meant to mean. You can search
| for commands with `Get-Command`.
| nerdponx wrote:
| Python itself doesn't follow that at all, ignore it.
| xelamonster wrote:
| Using a different set of commands in the terminal versus
| scripts and documentation makes no sense to me, why would
| I want to learn two different ways do the same thing?
| Python does not expect me to use `open` in the REPL but
| prefer `get_file_handle` in published scripts, their
| ethos works because the entire language has an emphasis
| on relatively concise readability.
|
| Every single command starting with `Get-` or `Set-` adds
| so much noise and makes things really hard to visually
| distinguish too. I don't want overly verbose commands in
| scripts for the same reason I don't want them in the
| terminal, it's still a pain to write and even if you have
| some autocomplete it makes editing harder. I don't think
| `ls` is any less clear or harder to learn than `Get-
| ChildItem` really, that name doesn't even actually give
| me any clue what the command does.
| emmelaich wrote:
| Do you know that there are short versions? e.g. gc for Get-
| Content
| TristanBall wrote:
| Curious as to what's "vastly less practical" in powershell?
| hnlmorg wrote:
| There are shells out there that sit between PowerShell / Nu and
| the old guards like Bash / Zsh.
|
| Ones that support data structures out-of-the-box (like any et
| al) but also work perfectly fine with existing UNIX commands
| (like Bash).
| sea-gold wrote:
| Here is a nice list: https://github.com/oils-for-
| unix/oils/wiki/Alternative-Shell...
| kseistrup wrote:
| Hm, even if I download the sample .dune-prelude, dunesh keeps
| asking me if this is my first time.
|
| Also, can I make it use a 24h clock and non-US date formatting?
| kickingvegas wrote:
| Obligatory mention of Emacs Eshell.
| https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...
| ssivark wrote:
| The advertisement promises a combination of bash and lisp. So it
| makes me wonder -- why couldn't we just use lisp?
|
| What are the affordances needed for a "scripting" language (or
| for interactive use) vis-a-vis more "production use? Is it just
| about having minimal boilerplate, and a large corpus of ready-to-
| use functions in the namespace?
| Kinrany wrote:
| Process composition is one thing that shell languages do better
| than traditional programming languages
| hnlmorg wrote:
| There's plenty of LISP packages that support process
| composition. Also LISPs syntax better suits write once type
| environments like REPL shells than your average C-derived
| syntax.
| slowmovintarget wrote:
| https://github.com/babashka/babashka
|
| Granted, if you're saying why can't we have the shell also...
| well, now you're talking about Emacs.
| jimbokun wrote:
| Maybe the ultimate would be default to bash but if you start a
| command with a prefix everything following is parsed and
| evaluated as an s-expression.
| toolslive wrote:
| ipython is the complete opposite: python but enhanced with
| bash. For example: x = !ls # capture the
| output of `ls` into x x[0] # the first filename
| ...
| jerf wrote:
| "Is it just about having minimal boilerplate"
|
| That's a lot of it, but I think people don't realize how every
| _keystroke_ counts with shell.
|
| There's only a handful of languages where the "apply function"
| operator is _space_. Shell is one of them. (Haskell & Forth
| are the other two I know off the top of my head, possibly
| Factor (concatenative in general tends this way).) Most new
| shells that are successful copy this. I don't think that's a
| coincidence. Lisp's abundance of parens is something that
| people will have trouble with, even Lisp programmers, because
| this is not the usual whining about a foreign language paradigm
| and not being used to reading parens... this is literally about
| the effort required to physically enter them with a keyboard.
| tempodox wrote:
| Nice, it even has Muad'Dib (the desert mouse from the "Dune"
| movies) as its mascot. The question "but does it have Muad'Dib?!"
| was the first thing I thought of when I saw the title.
| beardedwizard wrote:
| More white rat than desert mouse, I was disappointed. The mouse
| is also featured in the source material - the books :)
| globular-toast wrote:
| Also the one in the film looked more like a jerboa.
| herodoturtle wrote:
| Don't know what a jerboa is but I quite liked the depiction
| in the film.
|
| In particular the attention to detail, when they showed a
| bead of sweat running down its optimally shaped ear,
| whereupon it was pawed into its mouth.
|
| I loved that little scene so much.
| mmastrac wrote:
| I like the ideas behind Powershell, but the DX has always felt
| ugly and clunky compared to standard shell. Unix/Posix are full
| of great tools, but they are all extremely painful for newbies
| and take years to master. There's got to be a middle ground where
| we can have the power and approachability of SQL with the
| beautiful elegance of standard Unix pipes.
|
| Dune seems to take a step in that direction which is great.
| mattmight wrote:
| "Think of it as an unholy combination of bash and Lisp" reminded
| me of Scheme Shell: https://scsh.net/
|
| My Ph.D. advisor Olin Shivers created this. It's more pulling
| bash into Lisp than Lisp into bash.
|
| It doesn't seem to be maintained anymore, but some of its ideas
| live on in Racket.
| michaelsbradley wrote:
| And now there's _Rash: The Reckless Racket Shell_
|
| http://rash-lang.org/
|
| https://github.com/willghatch/racket-rash
| esafak wrote:
| Looks like it needs some contributors; no releases in almost a
| year.
| delichon wrote:
| The shell avatar is a rodent but not a desert mouse, not a
| muad'dib. It's "a shell by the beach", not inspired by any
| intellectual property you might be thinking of. Yet memorable.
| Well played.
| CMCDragonkai wrote:
| It kind of sucks that the default shell language is so clunky on
| Linux O/Ses. Bash marginally better than POSIX sh, and Zsh
| marginally better.
___________________________________________________________________
(page generated 2024-09-18 23:01 UTC)