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

71–80 of 202 posts

Re: Making Hard Things Easy

#71

Post by odysseus »

kristopolous wrote: post #59
zoogeny wrote: post #34

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…

https://cheat.sh is your lifeline Also I made https://github.com/kristopolous/mansnip

This looks like https://tldr.sh in a browser.

Re: Making Hard Things Easy

#72

Post by justin_oaks »

ustad wrote: post #64
fiddlerwoaroof wrote: post #36

Earlier quoted context omitted.

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)

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

You're right that you often can't modify your current environment by invoking a shell script. That's because it's executed in a sub-shell.

For cases where you need to modify your current environment (setting environment variables, changing directories, etc), you need to run the script using the "source" built-in. That will execute the script in the current shell rather than a sub-shell.

So instead of

    ./some-script.sh
you'd run

    source some-script.sh
or use the dot (".") shorthand

    . some-script.sh
In cases where I need to source a script, I generally create an alias or a shell function for it. Otherwise I may forget to source it.

Re: Making Hard Things Easy

#73

Post by jes5199 »

TheClassic wrote: post #27

I expected there to be an abstracted, general, repeatable tldr that can be reapplied as a mental model. I haven't digested the whole thing, but after skimming, I can't identify what it is.

it's kind of more like the beginning of a pattern language for why things seem hard to novices but simple to experts, and ways to mitigate those effects - a different mitigation is appropriate for each pattern

Re: Making Hard Things Easy

#74

Post by pierrebai »

Well, I'm going to disagree with her solution to bash. Bash is terrible, end of story. Just the *.txt is actually an endless pit of trap, badness and wrong behaviour.

I've not written a bash script in years. I always use Python and in my experience professionally, most people automating things nowaday use Python. I only use bash to write one-line to invoke the underlying Python script. For the record, I do the same for batch file on Windows, with a simply .bat file to invoke the underlying Python script.

Trying to improve the bash experience with tools and knowledge is throwing bad time at a problem that has a well-known solution.

Edit: to be clear, the presentation itself is awesome. I'm just disagreeing that bash needs to be better explained. I'm ready to admit that there are existing scripts out there, most of which are probably only working in the trivial, normal case and are just one snag away from exploding, and having a known source of help can help. But please, take you're bash scrip to the shed and upgrade them to Python.

Re: Making Hard Things Easy

#75

Post by sz4kerto »

These are the use cases where generative AI is great. I want to convert an mp4 to mov and resize it to 720p with ffmpeg, give me the command. I want a bash script to filter out the third column from a CSV and convert the result to a JSON.

These are not hard, but I won’t remember ffmpeg flags because I only use it once per year.

Re: Making Hard Things Easy

#76

Post by emi2k01 »

zoogeny wrote: post #34

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…

> Next match is just `/`.

You can also press `n`

Re: Making Hard Things Easy

#77

Post by ickyforce »

mparnisari wrote: post #69

> Everything is in the same order as you write it, except SELECT is fifth. been using SQL for years and didn't stop to think about that...

I don't think her conclusion is correct in this case (that it's all about chronological order). It's not about what happens first but about levels of abstraction. It doesn't make sense to say that we want to decide on the number of doors before specifying if we're building a LEGO car or a skyscraper in Manhattan.

The reasonable approach is to start from high-level concepts and only then deal with the details - without specifying high-level concepts the details have no particular meaning.

As a side note I have to say that I definitely prefer languages with `object.function` rather than `function(object)`, precisely because of this. Another example: `if(foo == 5)`, not `if(5 == foo)`

Re: Making Hard Things Easy

#78

Post by commandlinefan »

pcj-github wrote: post #46

Every time a jnvs.ca article goes popular on HN I have to relive the trauma of my Stripe interview with Julia where I just could not get that simple test to pass despite having years of programming experience. Ugh! She was nice though :)

What was the test?

Re: Making Hard Things Easy

#79

Post by justin_oaks »

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 only one maintaining the script, you're requiring others to learn the other shell to maintain the script.

The problem with using another programming language is that they rarely have good ergonomics for doing what bash does: stringing together commands, command input, command output, and files. If you try to do that in another programming language, things suddenly get a lot more complicate or at least more verbose.

So I still use bash, but I recognize that it's strength is in running other commands and dealing with I/O. If I'm doing complicated logic that doesn't involve that, then I'll offload my work to another language. Sometimes that just means calling a python script from bash, not avoiding bash completely.

If people found that they work better by taking other approaches, the please share them.

[0] https://www.oilshell.org

Re: Making Hard Things Easy

#80

Post by brezelgoring »

fiddlerwoaroof wrote: post #36
asicsp wrote: post #3

Earlier quoted context omitted.

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)

Nobody asked but I'd like to chime in with my method.

I have a lot of aliases, for example to start my QEMU VM with my development stuff in it, I make an alias for 'qemu-system-x86_64 [...]' with all the switches and devices and files required, called 'startvm'. I have another that takes me to my current project's folder and pulls the repo. And a third that creates a new folder called 'newproject', creates a small set of folders and empty files with specific names, and finally makes a git repo in it. I am a serial abandoner of projects so I use this more often than I care to admit.

It's not pretty, but functional; and since I always copy my dotfiles when I change computers, I've kept these small helpers with me for a while now.

Post reply on HN