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

111–120 of 202 posts

Re: Making Hard Things Easy

#111

Post by theshrike79 »

hiAndrewQuinn wrote: post #86
esafak wrote: post #47

Earlier quoted context omitted.

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

I'm quite partial to the fish shell myself for this reason. But I SSH into a lot of embedded systems these days, where you don't exactly have the luxury of installing your own shell all the time. For those times I like to whip out the "minimal safe Bash template" and `sftp` it to the server. https://betterdev.blog/minimal-safe-bash-script-template/

When the shell script is that long, I reach for Python or Go instead pretty fast =)

Re: Making Hard Things Easy

#112

Post by tripleo1 »

fiddlerwoaroof wrote: post #91
ustad wrote: post #64

Earlier quoted context omitted.

Wait, how do you “cd to it” from within the script? Doesn’t exiting the script take you back to where you were?

For this I use shell functions in my .zshrc and I wrote a loader to source a bunch of files in a .zsh.d directory.

Rolled your own direnv?

Re: Making Hard Things Easy

#113

Post by tripleo1 »

lazide wrote: post #106
imp0cat wrote: post #17

Earlier quoted context omitted.

Right. I don't think you're supposed to read them top-to-bottom. Use `/` and search for the things of interest (keywords, arguments, options, etc...). Use n/N to quickly jump forward/back.

Find has a particularly bad man page to find things that way.

FWIW it's `-maxdepth 1` not `-depth 1`.

But yeah, you're right.

Re: Making Hard Things Easy

#114

Post by swayvil »

justin_oaks wrote: post #83

The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…

Sector editor!

(Or back in the day, looking at the source code because we ran uncompiled stuff in Basic and whatever and that was pretty cool)

Re: Making Hard Things Easy

#115

Post by abdusco »

ff317 wrote: post #99
justin_oaks wrote: post #79

Earlier quoted context omitted.

I have yet to find a proper replacement for bash. Especially for scripts. The two most common alternatives are 1) using some of the newer shells people have created, like Oil shell [0], or 2) using programming language like Python, JavaScript, or PHP. The problem with using a newer shell is that you'll have to install the new shell anywhere you want to use the script. Meanwhile bash is ubiquitous. Unless you're the o…

I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead…

I usually resort to running inline scripts using python3 or node (using only the standard library) if I need to do something that I can't express in bash easily. That means avoiding stuff that have to look up and I won't remember or be able to debug in a month.

Re: Making Hard Things Easy

#117

Post by justinpombrio »

karmakaze wrote: post #39
zvmaz wrote: post #16

Earlier quoted context omitted.

> 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 de…

I suspect that Julia is solely using the first kind of mental model (getting the correct result), and completely ignoring query planning. But even this model has an order to it! Three examples of how this order can manifest, that should all agree with each other:

1. The explanatory diagrams that Julia drew for the talk. These wouldn't make sense if they were in a different order.

2. The order of operations you would perform if you developed a proof of concept SQL implementation that completely ignored performance. In this example the order would be: "cats, filter, group, filter, map, sort". This is exactly the order that Julia's explanation showed.

3. The relational logic expression for this query. There should be a correspondence between this expression and this ordered list of operations, though it's somewhat annoying to state. I think it's that, assuming all the operators in the relational logic expression are binary, if you reverse the order that a subset of the operators are written in, then the operators in the tree occur in the same order as the ordered list of operations. (I don't actually know relational logic, so I'm making a prediction here. This prediction is falsifiable: you can't put the operators in the tree in an arbitrary order.)

(Side note: the order isn't completely fixed. The last two steps --- SELECT and ORDER BY --- could happen in either order.)

Re: Making Hard Things Easy

#118

Post by justin_oaks »

abdusco wrote: post #115
ff317 wrote: post #99

Earlier quoted context omitted.

I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead…

I usually resort to running inline scripts using python3 or node (using only the standard library) if I need to do something that I can't express in bash easily. That means avoiding stuff that have to look up and I won't remember or be able to debug in a month.

I like the idea of running inline scripts. This means that all the logic is in a single file so you don't have multiple files to copy around (e.g. a .sh file and a .py file).

I've done this with awk and jq, but haven't done it with node or python. But why not? It sounds like a good approach for some cases.

Re: Making Hard Things Easy

#119

Post by hyperthesis »

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…

When explanations include superfluous detail, I find it very confusing. Like Chekhov's gun, I keep trying to fit it into the plot but it doesn't fit.

My super power is a terrible memory. So I have to understand things in order to remember them (aka a cognitive compression). I can't just learn things like normal people.

Re: Making Hard Things Easy

#120

Post by justin_oaks »

swayvil wrote: post #114
justin_oaks wrote: post #83

The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…

Sector editor! (Or back in the day, looking at the source code because we ran uncompiled stuff in Basic and whatever and that was pretty cool)

That's one of the advantages of using programming languages where source code is distributed (e.g. Python, JavaScript, PHP), not compiled binary artifacts (C/C++, Java). You can see the source. You can even modify it and run the modified version without compilation.

It's also awesome to use Java IDEs that can show both the bytecode of .class files and also perform decompilation.

Post reply on HN