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

131–140 of 202 posts

Re: Making Hard Things Easy

#131

Post by dkarl »

> 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 our bash code or confidence that it will behave as we expect in untested scenarios. If anything out of the ordinary happens, we kind of expect that something will fail and we will learn something new about bash that will make us cringe and/or strike a nearby object hard enough to injure ourselves."

Bash is a complex language, and for most programmers, it is unlike any other language they use. Most companies have a little bit in production somewhere, and most of them don't have a single person who writes enough bash to know it well. I think it's no accident that build tools, CI tools, and cloud orchestration tools are evolving in the direction of minimizing the need for shell scripting.

Re: Making Hard Things Easy

#132

Post by Natsu »

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…

Man, having spent waaaay too long troubleshooting errors where it's not remotely clear what part of the config the program is even consulting makes this hit home.

Re: Making Hard Things Easy

#135

Post by jongjong »

On a related note, most software is over-engineered. I think it's partly because of centralization of the industry; it's pushing everyone towards a small number of tools for the benefit of a small number of people who control them and so many of these tools end up becoming 'everything tools' and cover more use cases than they should.

Companies want developers to all know the same tools; that way they are easily replaceable across projects and companies and have little bargaining power in the industry. This is why software has a single mainstream trunk and alternative approaches are shunned with no jobs available. The industry is not being allowed to decentralize despite the fact that it naturally 'wants' to.

On the bright side, I think that eventually, some new, far superior non-mainstream approaches are going to materialize and they will erode the mainstream approaches.

Tech is not like math and not even like science; it can support MANY different branches solving any given problem in many different ways.

Re: Making Hard Things Easy

#136

Post by corobo »

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

We should stop using Bash, and use TypeScript instead. Bash is terrible.

well this shell is just broken

  > ls -al
  .ts:4:1 - error TS2304: Cannot find name 'ls'.
  
  4 ls -al
    ~~
  .ts:4:5 - error TS2304: Cannot find name 'al'.
  
  4 ls -al
        ~~

Re: Making Hard Things Easy

#137

Post by xenodium »

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.

Oh, specially ffmpeg and imagemagick! I have a handful of incantations saved over time.

Just today I saved a new one for trimming borders on video screenshots https://xenodium.com/trimming-video-screenshots to https://github.com/xenodium/dwim-shell-command/blob/main/dwi... (that’s my cheat sheet).

I wrote an Emacs package that works fairly well for saving commands but also making them reusable from its file manager without the need to tweak input or output file paths https://github.com/xenodium/dwim-shell-command

While Emacs isn’t everyone’s cup of tea, I think the same concept can be applied elsewhere. Right click on file(s) from macOS Finder or Windows Explorer and apply any of those saved commands.

Edit: More examples…

- Stitching multiple images: https://xenodium.com/joining-images-from-the-comfort-of-dire...

- Batch apply on file selections: https://xenodium.com/emacs-dwim-shell-command

Re: Making Hard Things Easy

#138

Post by chrismarlow9 »

justin_oaks wrote: post #79
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.

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 love bash for anything that doesn't need to scale. The reason is reliability. I can't tell you how many times I've run into problems with python or similar on small library implementations. If I need to make an http request in my code and I'm using curl in bash and something fails, I can pretty much guarantee the problem is not curl itself. It's battle tested and deterministic. However the python script that forgets to wrap a try catch or configure proper tls auth or some other quirk? I have had those eat hours/days of my time and having to resort to tcpdump to sort out what's really happening. Same with SQL libraries/ORM vs SQL cli, same with Json/xml parsing libraries vs jq etc.

Re: Making Hard Things Easy

#139

Post by [deleted] »

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…

[deleted]

Re: Making Hard Things Easy

#140

Post by andrepd »

hiAndrewQuinn wrote: post #88

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.

Very much. I'm usually not a fan of the "omg awesomesauce"-style of overexcited blogposts or tutorials, (I much prefer the drier, high signal-to-noise ratio, concise, beautiful texts of the Landau&Lifschitz style), but her posts all make me feel that giddy rush of excitement you're talking about :)
Post reply on HN