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

31–40 of 202 posts

Re: Making Hard Things Easy

#31

Post by t43562 »

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.

It has idiosyncracies because it's not a general purpose language. Even the things that she mentions are happening for good reasons - like the fact that set -x would break the expected behavior of || and &&.

Actually what language does crash when a function returns false? I mean some throw exceptions but isn't "false" a valid thing to return?

I find the same thing with makefiles - people don't understand what they're doing and expect them to work in a certain way because they haven't ever thought about build systems very deeply. Recursive assignment in Make catches almost everyone out e.g.

FLAGS=-b

COMPILE=compile $(FLAGS)

$(info compile command=$(COMPILE))

FLAGS=-a

myfile:

echo $(COMPILE) $? -o $@

outputs:

t43562@rhodes:~ make -f t.mk

compile command=compile -b

echo compile -a -o myfile

compile -a -o myfile

Despite this, making all assignments immediate to match other programming languages would take a VERY useful tool away. The more you understand these tools the more you know where to bother using them and how much effort to put into it.

Re: Making Hard Things Easy

#32

Post by layer8 »

thwarted wrote: post #7
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…

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…

For find, I think the Info pages are (even) more comprehensive (info find), and you get more structural navigation.

Re: Making Hard Things Easy

#34

Post by zoogeny »

I have no idea why but I wanted to hate this article. Maybe jvns shows up on HN too often and I was in a bad mood. But this is a great article and as someone with 20 years of development experience is about as true as any meta-level discussion on programming could be.

The selective vision thing is so true, both for `dig` and for `man` pages. I can't count the number of times have I `man ` and just felt overwhelmed by the seemingly endless pages of configuration options and command line flags. One tip I use for `man` is use vim style search functions triggered with `/`. For example, if I want to find how to output the line number of each match in grep and I can't remember how - I'll just `man grep` then type `/line` and hit enter and it will search for any occurrence of the word "line" in the man page. Next match is just `/`.

I'm also a bit sad to hear that Strange Loop is now finished? I only found them last year or so and it seemed like so many of the talks were exceptional quality.

Re: Making Hard Things Easy

#35

Post by jstimpfle »

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

There are more arcane things to learn about shell, at some point one has to go shrug, it's a fine tool for getting quick results but not for writing robust programs.

Re: Making Hard Things Easy

#36

Post by fiddlerwoaroof »

asicsp wrote: post #3
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…

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.

If you’re already putting them in a file, you might as well put them in a shell script on $PATH: at a certain point I started writing shell scripts and little utilities for relatively infrequently used commands and other tasks (e.g. clone this repo from GitHub to a well-known location and cd to it)

Re: Making Hard Things Easy

#38

Post by jvns »

LeifCarrotson wrote: post #5

Well said! I'm in manufacturing, not web tech, so the hard things I work with are very different (RS-274 G-code, servo motion systems, PLC/SCADA network connections are a few examples), but it's interesting to see the overlap in causes of difficulty like trivia, gotchas, frequency of use, and visibility. And disheartening to see that the web tech community is so open and friendly and communicative, while controls eng…

fixed, thanks!

Re: Making Hard Things Easy

#39

Post by karmakaze »

zvmaz wrote: post #16
karmakaze wrote: post #15

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…

> The SQL part seems to double-down on a conceptual failure rather than demystifying it though. She talked about a mental model to help her understand the query (it can be useful), and mentioned that it probably is not how the database actually processes the query.

My point is that there should be two mental models. One for getting the correct results. Then another for doing so performantly. Being able to write many different forms of obtaining the same correct results is where this leads to combined understanding and proficiency.

An example of where muddling these ends up with real questions like "how does the db know what the select terms are when those sources aren't even defined yet?" By 'yet' they mean lexically but also procedurally.

Re: Making Hard Things Easy

#40

Post by cole-k »

asicsp wrote: post #3
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…

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.

If you don't mind, it would be awesome to see your cheatsheet. I think this would be a great thing for people to share - like their dotfiles. But maybe they already do and I don't pay much attention to it because I'm lazy - like their dotfiles.
Post reply on HN