Live data from Hacker News

Making Hard Things Easy

jvns.ca

21–30 of 202 posts

Re: Making Hard Things Easy

#21

This is a great description of things that seem like they shouldn't be so difficult but can have many complications. The SQL part seems to double-down on a conceptual failure rather than demystifying it though. A query's logic is declarative which defines the output. It's the query plan that has any sense of execution order or procedural nature to it. That's the first thing to learn. Then one can learn the fuzzy area…

Topical recent episode about Postgres - but can be extrapolated in many cases to other databases: https://www.se-radio.net/2023/09/se-radio-583-lukas-fittl-on...

Re: Making Hard Things Easy

#23
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

"Fails" is a higher-level concept than the shell is concerned with. Failure conditions and reactions are entirely at the discretion of the programmer and are not built as an assumption into the shell.

The only thing /bin/false does is return 1. Is that a failure? No, that's how it was designed to work and literally what it is for. I have written hundreds of shell scripts and lots of them contain commands which quite normally return non-zero in order to do their job of checking a string for a certain pattern or whatever.

Programs are free to return whatever exit codes they want in any circumstance they want, and common convention is to return 0 upon success and non-zero upon failure. But the only thing that the shell is concerned with is that 0 evaluates to "true" and non-zero evaluates to "false" in the language.

It would be pretty inconvenient if the shell exited any time any program returned non-zero, otherwise if statements and loops would be impossible.

If a script should care about the return code of a particular program it runs, then it should check explicitly and do something about it. As you linked to, there are options you can set to make the shell exit if any command within it returns non-zero, and lots of beginner to intermediate shell script writers will _dogmatically_ insist that they be used for every script. But I have found these to be somewhat hacky and full of weird hard-to-handle edge cases in non-trivial scripts. My opinion is that if you find yourself needing those options in every script you write, maybe you should be writing Makefiles instead.

Re: Making Hard Things Easy

#24
post #6
post #3

Earlier quoted context omitted.

I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.

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).

Re: Making Hard Things Easy

#26
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.

Re: Making Hard Things Easy

#28
And that is why I like the book Accelerated C++. Instead of explaining each and everything. It helps just the right things, thus preparing you for further adventures. Another literature that comes closer is Designing Data Intensive Applications and SICP.

Re: Making Hard Things Easy

#29
post #9
post #7

Earlier quoted context omitted.

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. The man pages are readily available. The bash man page is huge and hairy, but comprehensive, I've found it pretty valuable to be familiar with the major sections and the visual shape of the text in the man page so I can pag…

> The man pages are readily available. True, but I find the man pages not easy and quick to parse.

I'm not a fan of man pages. Or any documentation that focuses on textual explanations rather than examples in code (looking at you aws).

I recently found https://tldr.sh/ and found it more convenient. I ended up writing myself a vscode extension to have a quick lookup at my fingertips, since I am at least 60% of the time looking at a terminal in vscode

Re: Making Hard Things Easy

#30
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.

I think this is a valid point. bash is an overly complicated tool...so I'll write another tool on top of that (with none of the decades of debugging that bash itself has undergone) to make bash...LESS complex?

The problem is with bash itself.

We tend to undervalue ease of use and overvalue "cleverness."

Case in point: git. Very clever tool. Ease of use: terrible. But Linus wrote it and Linus is clever, so it must be us that's the problem.

We get what we value. Let's value ease of use more.

Post reply on HN