Gabe/techWebsite
1
0
Fork 0
Code Issues 11 Pull requests Projects 1 Releases Wiki Activity

line breaks.

Browse source
This commit is contained in:
Gabe Venberg 2024-03-15 12:03:16 -05:00
parent 3017160c46
commit bc251f8790
2 changed files with 82 additions and 103 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

103
content/posts/clirenaissance/index.md
View file

@ -124,51 +124,45 @@ Ive noticed that people are rethinking and reinventing tools that have existed s
## The lessons learned from the past
A large amount of the innovation in the area, I think, can be attributed to
lessons that have been learned in 50 years of using software; sharp edges we
have repeatedly cut ourselves on, unintuitive interfaces that repeatedly trip us
up, and growing frustration at the limitations that maintaining decades of
backwards compatibility imposes on our tools.
A large amount of the innovation in the area, I think, can be attributed to lessons that have been learned in 50 years of using software;
sharp edges we have repeatedly cut ourselves on,
unintuitive interfaces that repeatedly trip us up,
and growing frustration at the limitations that maintaining decades of backwards compatibility imposes on our tools.
These lessons have been gathering in the collective conciousness, through
cheatsheets, guides, and FAQs; resources to guide us through esoteric error
messages, complex configurations, and dozens upon dozens of flags.
These lessons have been gathering in the collective conciousness;
through cheatsheets, guides, and FAQs;
resources to guide us through esoteric error messages, complex configurations, and dozens upon dozens of flags.
Id like to go over a couple of the more prominent lessons that I feel terminal
tools have learned in the past several decades.
Id like to go over a couple of the more prominent lessons that I feel terminal tools have learned in the past several decades.
### A good out of the box experience
While configurability is great, one should not need to learn a new configuration
language and dozens or hundreds of options to get a usable piece of software.
While configurability is great,
one should not need to learn a new configuration language and dozens or hundreds of options to get a usable piece of software.
Configuration should be for customization, not setup.
One of the earliest examples of this principle may be the fish shell.
Both zsh and fish have powerful prompt and autocompletion engines, but zsh
requires you to setup a custom prompt and enable completions in order to use the
features that set it apart from the competition. With no config file, zsh is no
better than bash. When starting fish for the first time, however, its powerful
autocompletion and information rich prompt are front and center with no
configuration required. Of course, fish still has the same level of
configurability as zsh, it just also has sensible defaults.
Both zsh and fish have powerful prompt and autocompletion engines,
but zsh requires you to setup a custom prompt and enable completions in order to use the features that set it apart from the competition.
With no config file, zsh is no better than bash.
When starting fish for the first time however,
its powerful autocompletion and information rich prompt are front and center with no configuration required.
Of course, fish still has the same level of configurability as zsh, it just also has sensible defaults.
To demonstrate my point, this is the default prompt for zsh with no
configuration. It *only* shows the hostname, none of the advanced featurs you
can get out of a zsh prompt even without plugins.
To demonstrate my point, this is the default prompt for zsh with no configuration.
It *only* shows the hostname, none of the advanced featurs you can get out of a zsh prompt even without plugins.
![zsh prompt, only shows hostname](zsh_prompt.png)
Here is bash's prompt. It actually gives more info than zsh's, even though zsh
can do more when properly configured.
Here is bash's prompt.
It actually gives more info than zsh's, even though zsh can do more when properly configured.
![bash prompt, shows hostname and current directory](bash_prompt.png)
And here is fish's default prompt. It has a few colours, shows everything the
bash prompt does, and additionally shows the git branch we are on.
![fish prompt, has colours, shows hostname, current directory, and git
info](fish_prompt.png)
And here is fish's default prompt.
It has a few colours, shows everything the bash prompt does, and additionally shows the git branch we are on.
![fish prompt, has colours, shows hostname, current directory, and git info](fish_prompt.png)
Text editors are another great example of the evolution of out of the box
defaults. Vim and Neovim both improved on their predecessors, but so much of
that improvement is locked behind extremely complex configuration experiences
and plugins. Heres four different terminal text editors with no configuration
applied:
Text editors are another great example of the evolution of out of the box defaults.
Vim and Neovim both improved on their predecessors,
but much of that improvement is locked behind extremely complex configuration experiences and plugins.
Heres four different terminal text editors with no configuration applied:
![vi, vim, neovim, and helix editors in their default
configuration](editors.png)
@ -177,33 +171,26 @@ Vi, (top left) is our baseline, and, as far as I can tell, doesnt actually
support much for configuration. What you see out of the box is more or less
whats there.
Vim (top right) greatly improved on Vi, adding things such as syntax highlighting, line
numbers, spellchecking, split windows, folding, and even basic autocompletion.
However, everything but syntax highligting is either extremely clunky or
outright disabled without configuration. (for example, the earliest things I did
when I first made a `.vimrc` was to enable indent folding, make some better
keybinds for navigating windows, and adding a line number ruler to the side)
Vim (top right) greatly improved on Vi, adding things such as syntax highlighting, line numbers, spellchecking, split windows, folding, and even basic autocompletion.
However, everything but syntax highligting is either extremely clunky or outright disabled without configuration.
(for example, the earliest things I did when I first made a `.vimrc` was to enable indent folding,
make some better keybinds for navigating windows, and adding a line number ruler to the side)
Neovim (bottom left) further improved on Vim, adding support for Treesitter and
the Language Server Protocoll, but the out of the box experience is the *exact*
same as vim! In order to take advantage of the LSP and Treesitter support, you
have to install plugins, which means learning a Nvim package manager, learning
how to configure LSPs, and configuring a new LSP for every language you want to
use it with. (Or finding out about Mason and being OK with having multiple
levels of package management in your Nvim install alone). Dont get me wrong,
Neovim is a great editor once you get over the hump, I still use it as my daily
driver, but so much of its functionality is simply hidden.
Neovim (bottom left) further improved on Vim, adding support for Treesitter and the Language Server Protocoll, but the out of the box experience is the *exact* same as vim!
In order to take advantage of the LSP and Treesitter support, you have to install plugins,
which means learning a Nvim package manager, learning how to configure LSPs, and configuring a new LSP for every language you want to use it with.
(Or finding out about Mason and being OK with having multiple levels of package management in your Nvim install alone).
Dont get me wrong, Neovim is a great editor once you get over the hump, I still use it as my daily driver, but so much of its functionality is simply hidden.
Then we have the Helix (bottom right) editor. Colour scheme aside, everything is
just there. Helix doesnt have plugin support
[yet](https://github.com/helix-editor/helix/discussions/3806), but it has so
much stuff in core that, looking through my neovim plugins, pretty much all of
them are in the core editor! (ironically, the one feature that I feel helix is
missing, [folding](https://github.com/helix-editor/helix/issues/1840), is a core
part of neovim, albiet one that requires some configuration to get good use out
of). Helix does have a config file where you can change a huge amount of
settings, but its an extremely usable IDE out of the box, thanks to having all
of its features enabled by default.
Then we have the Helix (bottom right) editor. Colour scheme aside, everything is just there.
Helix doesnt have plugin support [yet](https://github.com/helix-editor/helix/discussions/3806),
but it has so much stuff in core that,
looking through my neovim plugins,
pretty much all of them are in the core editor!
(ironically, the one feature that I feel helix is missing, [folding](https://github.com/helix-editor/helix/issues/1840),
is a core part of neovim, albiet one that requires some configuration to get good use out of).
Helix does have a config file where you can change a huge amount of settings,
but its an extremely usable IDE out of the box, thanks to having all of its features enabled by default.
### Friendly error messages

82
content/posts/nushell.md
View file

@ -54,8 +54,7 @@ You can sort, filter, and aggregate the data,
use a SQL style join statement between two tables,
and use functional programming patterns to manipulate tables.
Some examples of things that nushell enables with this structured data passing
through pipelines includes:
Some examples of things that nushell enables with this structured data passing through pipelines includes:
{{<highlight sh>}}
# show all files recursively that were modified in the last week
@ -123,26 +122,23 @@ update bytes_sent {into int}
{{</highlight>}}
(each line has a comment explaining what it does, for those unfamiliar with the nushell language)
Now that we have it in nushell tables, we can bring all of nushells tools to
bear on the data. For example, we could plot a histogram of the most common
ips, just by piping the whole thing into `histogram ip`. We could easily
calculate the average bytes sent per request. We could group the records by the
day or hour they happened, and analyze each of those groups independently. And
we can do all of that after arbitrarily filtering, sorting, or otherwise
transforming the table.
Now that we have it in nushell tables, we can bring all of nushells tools to bear on the data.
For example, we could plot a histogram of the most common ips, just by piping the whole thing into `histogram ip`.
We could easily calculate the average bytes sent per request.
We could group the records by the day or hour they happened, and analyze each of those groups independently.
And we can do all of that after arbitrarily filtering, sorting, or otherwise transforming the table.
While it would be a pretty long one liner if we decided to put it in a single
line, its still quite easy and straightforward to write.
While it would be a pretty long one liner if we decided to put it in a single line,
its still quite easy and straightforward to write.
Most log formats and command outputs are similarly straightforward.
## Defining custom commands, with built-in arg parsing
Nushell has a feature called Custom Commands, which fill the same purpose as
functions in other shells/programming languages, but are a bit more featurefull
than traditional POSIX shell functions.
Nushell has a feature called Custom Commands,
which fill the same purpose as functions in other shells/programming languages,
but are a bit more featurefull than traditional POSIX shell functions.
First of all, nushell custom commands specify the number of positional arguments
they take.
First of all, nushell custom commands specify the number of positional arguments they take.
{{<highlight sh>}}
def recently-modified [cutoff] {
@ -168,8 +164,8 @@ def recently-modified [cutoff: string] {
}
{{</highlight>}}
You can give the arguments a default value, making it optional, (can be combined
with a type specification)
You can give the arguments a default value, making it optional.
(can be combined with a type specification)
{{<highlight sh>}}
def recently-modified [cutoff = '1 week ago'] {
@ -181,9 +177,8 @@ def recently-modified [cutoff = '1 week ago'] {
}
{{</highlight>}}
You have flag parsing, complete with short flags, is included as well. (A
flag without a type will be taken as a boolean flag, set by its presence or
absence)
You have flag parsing, complete with short flags, is included as well.
(A flag without a type will be taken as a boolean flag, set by its presence or absence)
{{<highlight sh>}}
def recently-modified [cutoff: string = '1 week ago' --older-than (-o)] {
@ -203,8 +198,8 @@ def recently-modified [cutoff: string = '1 week ago' --older-than (-o)] {
}
{{</highlight>}}
And finally, you can add a rest command at the end, allowing you to take a variable number of
arguments.
And finally, you can add a rest command at the end, allowing you to take a variable number of arguments.
{{<highlight sh>}}
def recently-modified [--cutoff = '1 week ago' ...paths] {
for $path in $paths {
@ -217,8 +212,8 @@ def recently-modified [--cutoff = '1 week ago' ...paths] {
}
{{</highlight>}}
All of the specified parameters are automatically added to a generated `--help`
page, along with a documentation comments, so that the following code block:
All of the specified parameters are automatically added to a generated `--help` page,
along with a documentation comments, so that the following code block:
{{<highlight sh>}}
# display recently modified files
@ -260,13 +255,11 @@ Input/output types:
╰───┴───────┴────────╯
```
(the input/output table at the bottom has to do with how the command is used in
a pipeline, and is covered in more detail in the
[book](https://www.nushell.sh/book/command_signature.html))
(the input/output table at the bottom has to do with how the command is used in a pipeline,
and is covered in more detail in the [book](https://www.nushell.sh/book/command_signature.html))
This addition of easy argument parsing makes it incredibly convenient to add
command line arguments to your scripts and functions, something that is anything
but easy in POSIX shells.
This addition of easy argument parsing makes it incredibly convenient to add command line arguments to your scripts and functions,
something that is anything but easy in POSIX shells.
## Error messages
@ -296,8 +289,8 @@ done
(standard_in) 1: syntax error
{{</highlight>}}
This error tells you nothing about what went wrong, and your only option is to
start print debugging.
This error tells you nothing about what went wrong,
and your only option is to start print debugging.
The equivalent in nushell would be:
@ -305,8 +298,9 @@ The equivalent in nushell would be:
> ls | get size | each {|item| $item / 1000}
{{</highlight>}}
If we typo the size column, we get a nice error telling us exactly what we got
wrong, and where in the pipeline the error and value originated. Much better.
If we typo the size column, we get a nice error telling us exactly what we got wrong,
and where in the pipeline the error and value originated.
Much better.
{{<highlight sh "linenos=false">}}
> ls | get szie | each {|item| $item / 1000}
@ -325,8 +319,8 @@ Error: nu::shell::column_not_found
Now, nushell is not finished yet.
As I write, I am running version 0.91 of nu.
Similar to fish, it not being a POSIX shell means that you still need to drop
into bash or zsh in order to source env files in order to,
Similar to fish,
it not being a POSIX shell means that you still need to drop into bash or zsh in order to source env files in order to,
for example, use a cross-compiling c/c++ sdk.
(thankfully, python virtualenvs already come with a nu script for you to source,
so doing python dev will not require you to launch a POSIX shell)
@ -362,14 +356,12 @@ def recently-modified [
> recently-modified --cutoff '2 weeks ago' ./
{{</highlight>}}
Its certainly not the most ergonomic, but seems to be the best way at the moment
to make 'scripts' that are integrated with the rest of nushell.
Its certainly not the most ergonomic,
but seems to be the best way at the moment to make 'scripts' that are integrated with the rest of nushell.
## So, overall, is it worth it?
Nushell is certainly an promising project, and I will almost certainly be
continuing to use it as my daily shell. It cant do everything, but dropping into
zsh for a task or two every once in a while isnt that big a deal for me, and
having access to such a powerful shell by default has made other tasks much
easier for me. If you regularly use pipelines in your default shell, consider
giving Nushell a try.
Nushell is certainly an promising project, and I will almost certainly be continuing to use it as my daily shell.
It cant do everything, but dropping into zsh for a task or two every once in a while isnt that big a deal for me,
and having access to such a powerful shell by default has made other tasks much easier.
If you regularly use pipelines in your default shell, consider giving Nushell a try.