Live data from Hacker News

Making Hard Things Easy

jvns.ca

161–170 of 202 posts

Re: Making Hard Things Easy

#161
post #131

> One thing that I sometimes hear is -- a newcomer will say "this is hard", and someone more experienced will say "Oh, yeah, it's impossible to use bash. Nobody knows how to use it." > But I would say this is factually untrue. How many of you are using bash? I think the meaning of the statement is not that straightforwardly literal. I think what it means is, "We don't have strong confidence in our understanding of ou…

I think the question is whether a newcomer will understand the implicit meaning or if they might interpret it more literally than its meant. In particular, "for most programmers, it is unlike any other language they use" is not something someone new would necessarily be able to infer because that sentiment requires enough experience to tell the difference between "uncommon" and "extremely esoteric".

Re: Making Hard Things Easy

#162
post #95

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…

Wireshark is great but it does not show you every byte the network carried. For example it never shows Ethernet preambles, only sometimes shows Ethernet frame checksums, and never shows interpacket gaps (which are a required part of the Ethernet protocol). So yes it comes close but it just goes to show you, there is always more detail hiding somewhere!

It doesn’t show electrical signals either. That’s a pointless nitpick if you’re developing anything beyond an Ethernet implementation.

Re: Making Hard Things Easy

#163
post #95

Earlier quoted context omitted.

Wireshark is great but it does not show you every byte the network carried. For example it never shows Ethernet preambles, only sometimes shows Ethernet frame checksums, and never shows interpacket gaps (which are a required part of the Ethernet protocol). So yes it comes close but it just goes to show you, there is always more detail hiding somewhere!

Are the Ethernet frame checksums even visible to Wireshark, which hooks into the IP layer? would some of the ethernet stuff be only visible within the ethernet card itself, not to the software stack?

Sometimes they are. It depends on how the capture was generated. If you look in the options of Wireshark there is one to detect bad checksums, so clearly there is a way to capture them. Here is one such way: https://stackoverflow.com/questions/22101650/how-can-i-recei...

This can be used to detect partially-bad network cables, because there is no reason you should ever receive a bad FCS.

Re: Making Hard Things Easy

#164

Julia has to be one of the most likable people in tech! Every time I read one of her articles I feel that same bubbly rush of excitement I got when I was a kid, just starting to unfurl the secrets of reality through my own little experiments. Absolutely lovely.

Yes, it's rare to find someone who possesses deep technological know-how and is also a brilliant teacher and communicator. Andrej Karpathy is another who comes to mind. Fortunately, I've discovered that more people fit this mold recently.

Re: Making Hard Things Easy

#166
> So, bash is a programming language, right?

No, it's a shell that lets you interact with the OS. All the "clasical" UNIX shells were created with interactive use in mind and optimized for it, but happen to be good enough at batch processing[1] to be conflated with programming languages (mostly these days, like, 40+ years later).

The focus on interactive use is the reason you don't have to

- surround command argument lists with parentheses

- put commas between command arguments

- put semicolons at EOL

- surround string literals with quotes (unless the content interferes with the syntax, like, sigils or IFS chars, and you want to escape it).

- surround variable names in braces (unless you want to use some advanced substitution)

- call commands to manipulate I/O; it's baked in.

And these are just the things that existed 40 years ago. Bash gives you so much more stuff that makes interactive use a bliss, but I'm not going to dump the man page here.

[1]: https://en.wikipedia.org/wiki/Batch_processing

Re: Making Hard Things Easy

#168
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 came here to say Anki is my lifeline for grokking difficult things like DNS. It was in fact on jvns.ca's book recommendation that I got Michael W. Lucas's _Networking for System Administrators_, and strip mined it for Anki cards containing both technical know-how and more than a little sysadmin wisdom. It might be one of the highest ROI books I've ever read, considering I actually remember how to use things like ne…

[dead]

Re: Making Hard Things Easy

#169
post #145

Earlier quoted context omitted.

What?? What happened

Alex Miller (the organizer) decided to stop. Probably best to let him explain in his own words: https://www.youtube.com/watch?v=suv76aL0NrA

What an incredible talk, too! Thank you so much for sharing! So glad I scrolled down this far haha

Re: Making Hard Things Easy

#170

> So, bash is a programming language, right? No, it's a shell that lets you interact with the OS. All the "clasical" UNIX shells were created with interactive use in mind and optimized for it, but happen to be good enough at batch processing [1] to be conflated with programming languages (mostly these days, like, 40+ years later). The focus on interactive use is the reason you don't have to - surround command argumen…

In practice, it's also a programming language :)
Post reply on HN