Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Hard Things Easy

jvns.ca

Post reply on HN
Print view View original

41–50 of 202 posts

Re: Making Hard Things Easy

#41

Post by zoogeny »

minroot wrote: post #33

Is it better to set -e or check return code of processes and decide to exit?

Better/worse is one of those subjective things that comes with experience. No one can definitively answer such a question in a way that will apply to every circumstance.

But as someone who rarely writes bash scripts but just enough to be dangerous ... I use `set -xe` at the top of every single shell script I write. The -x flag causes the script to echo every command that is executed to stdout which can be very valuable if I am debugging a shell script that is running on an external environment (like a CI). I've seen this habit suggested many times and it has served me well.

Re: Making Hard Things Easy

#42

Post by cole-k »

mmcdermott wrote: post #24
redlohr wrote: post #6

Earlier quoted context omitted.

Oh, that's a great idea. I have a doc that I maintain by hand, either via ">>" or editing directly. Time to go and make a shortcut. Do you do any annotation to help with the search?

A large Justfile ( https://just.systems/ ) of random recipes might be a way to make it both executable and searchable (at least on zsh, you can get an autocomplete list of completions from the command line).

Can you think of a single CLI tool that would let me commit a past incantation to a file and retrieve it later? Especially one that syncs well across devices.

The best I can think of is Atuin (https://github.com/atuinsh/atuin) but I wasn't super interested in using it - I kind of want something more lightweight.

Re: Making Hard Things Easy

#44

Post by cryptonector »

To make hard things easy you have to find the right way to abstract them so you hold only some bits of the hard things in your head and all the frequently-used details too (maybe), and everything else you have to look up as needed. That's what I do, and that's roughly what TFA says.

The problem is that people don't necessarily bother to form a cognitive compression of a large topic until they really have to. That's because they already carry other large cognitive burdens with them, so they (we!) tend to resist adding new ones. If you can rely on someone else knowing some topic X well, you might just do that and not bother getting to know topic X well-enough. For those who know topic X well the best way to reduce help demand is to help others understand a minimal amount of topic X.

> So, bash is a programming language, right? But it's one of the weirdest programming languages that I work with.

Yes, `set -e` is broken. The need to quote everything (default splitting on $IFS) is broken. Globbing should be something one has to explicitly ask for -- sure, on the command-line that would be annoying, but in scripts it's a different story, and then you have to disable globbing globally, and globbing where you want to gets hard. Lots of bad defaults like that.

It's not just Bash, but also Ksh, and really, all the shells with the Bourne shell in their cultural or actual lineage.

As for SQL, yes, lots of people want the order of clauses to be redone. There's no reason it couldn't be -- I think it'd be a relatively small change to existing SQL parsers to allow clauses to come in different orders. But I don't have this particular cognitive problem, and I think it's because I know to look at the table sources first, but I'm not sure.

Re: Making Hard Things Easy

#45

Post by strangesmells02 »

jks wrote: post #10
mfrw wrote: post #4

TiL: The shell does not exit if the command that fails is a part of any command executed in a && or || list except the command following the final && or ||. Reference: https://www.gnu.org/software/bash/manual/bash.html#index-set

This is because && and || are often used as conditionals: [ -e README ] && cat README avoids an error if the file README doesn't exist, and [ -e README ] || echo "You should write a README!" works the opposite way. What's more pernicious is that pipelines don't cause the shell to exit (assuming set -e) unless the last command fails: grep foo README | sort does not fail if README doesn't exist, unless you've also used…

so what happens?? it just hang up on the foo??

Re: Making Hard Things Easy

#46

Post by pcj-github »

Every time a jnvs.ca article goes popular on HN I have to relive the trauma of my Stripe interview with Julia where I just could not get that simple test to pass despite having years of programming experience. Ugh! She was nice though :)

Re: Making Hard Things Easy

#47

Post by esafak »

cryptonector wrote: post #44

To make hard things easy you have to find the right way to abstract them so you hold only some bits of the hard things in your head and all the frequently-used details too (maybe), and everything else you have to look up as needed. That's what I do, and that's roughly what TFA says. The problem is that people don't necessarily bother to form a cognitive compression of a large topic until they really have to. That's b…

The problem is that we're still using these ancient shells when we have better ones. Users shouldn't be wasting time memorizing arcana like "set -e". At least we have search engines now...

Re: Making Hard Things Easy

#48

Post by esafak »

Upvoter33 wrote: post #26
norir wrote: post #14

I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.

If you think this way, you will quickly stop using anything. Most computer things are pretty complex and have really intricate oddities.

No, you won't. There are numerous shells that are better. The path to improvement lies in being able to call drek by its name.

Re: Making Hard Things Easy

#49

Post by eviks »

zvmaz wrote: post #2

Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I comm…

It might be better to invest in something more general like better docs/cheatsheets (the bad old man pages which you could convert to a text editor friendly format, or something better like tldr, or something like Dash) so you don't depend on the internet, but also don't have to memorize bad designs (since find wouldn't be the only one)

Re: Making Hard Things Easy

#50

Post by dgb23 »

cryptonector wrote: post #44

To make hard things easy you have to find the right way to abstract them so you hold only some bits of the hard things in your head and all the frequently-used details too (maybe), and everything else you have to look up as needed. That's what I do, and that's roughly what TFA says. The problem is that people don't necessarily bother to form a cognitive compression of a large topic until they really have to. That's b…

A possibly radical way of fixing the SQL clause order would be to introduce "project" which behaves like "select" but can be put in the right place.
Post reply on HN