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

171–180 of 202 posts

Re: Making Hard Things Easy

#171

Post by Too »

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.

Yes. While I’m a huge fan of shellcheck and am one who actually have used and know bash deeply. No amount of linters or other tooling on top of bash can fix it.

Best solution is to just stay away.

For real. Just stop. Don’t try to be macho. The whole model of the language is fundamentally broken. I mean, stringly typed, global mode switches, one-character flags for fundamental comparison operators, defaulting to ignoring errors at every corner you look, functions especially. Each such idiosyncrasy on its own is enough to dismiss such a language, bash has them all plus more.

Re: Making Hard Things Easy

#172

Post by chubot »

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

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 By the way OSH runs existing shell scripts and ALSO fixes those 3 pitfalls, and more. Just add shopt --set ysh:upgrade to the top of your script, and those 3 things will go away. If anyone wants to help the project, download a tarball, test our claims, and write a blog…

Slight correction: bin/ysh has a few things that ysh:upgrade doesn't catch

https://lobste.rs/s/6gycoi/making_hard_things_easy#c_sjfxif

Feedback is welcome (especially based on upgrading real scripts)

Re: Making Hard Things Easy

#173

Post by _TwoFinger »

jezzamon wrote: post #170
_TwoFinger wrote: post #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 argumen…

In practice, it's also a programming language :)

Emphasis on "also".

If you optimize a shell feature for general-purpose programming, interactivity will suffer (increased verboseness, usually), and vice versa.

If we try to bring shells closer to the real PLs, instead of just using those PLs when it matters, we'll lose some of things that made shells attractive in the first place.

Re: Making Hard Things Easy

#174

Post by agent281 »

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…

This is what I like about SQL databases. They frequently have tables that you can query to find system information. This makes it easy to explore the system within the system.

The proc filesystem on Linux is philosophically similar. It allows you to understand processes by working with files.

Re: Making Hard Things Easy

#175

Post by TeMPOraL »

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

This is one thing I love about Magit for Emacs. The UI is really clever and slick—maybe the best Git frontend that I've ever used—but the way you interact with UI is by toggling flags and options that actually map to the underlying command line Git arguments. I can seamlessly hop into the command line and feel right at home using it directly.

On top of the UI having very tight and visible relationship to git CLI commands, there's also a log buffer showing you exact commands executed and their outputs, and it's only a single $ press away.

Re: Making Hard Things Easy

#176

Post by Izkata »

justinpombrio wrote: post #117
karmakaze wrote: post #39

Earlier quoted context omitted.

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…

If there's an index on the ORDER BY fields, it can even be first.

Re: Making Hard Things Easy

#177

Post by Izkata »

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

You can get code formatting by indenting it all with 2 spaces.

Re: Making Hard Things Easy

#178

Post by bsaul »

I wonder if the speaker manages to keep their good personality and optimism when shits hits the fan and customers get angry (it’s a sincere question, i’m not being snarky).

Re: Making Hard Things Easy

#179

Post by thelittleone »

AceJohnny2 wrote: post #147
jzwinck wrote: 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?

Wireshark works at the data link layer (L2).
Post reply on HN