4 ms·
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
by cryptonector 3y ago
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 because they already carry other large cognitive burdens with them, so they (we!) tend to resist adding new ones. If you can rely on someone else knowing some topic X well, you might just do that and not bother getting to know topic X well-enough. For those who know topic X well the best way to reduce help demand is to help others understand a minimal amount of topic X.
> So, bash is a programming language, right? But it's one of the weirdest programming languages that I work with.
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 -- sure, on the command-line that would be annoying, but in scripts it's a different story, and then you have to disable globbing globally, and globbing where you want to gets hard. Lots of bad defaults like that.
It's not just Bash, but also Ksh, and really, all the shells with the Bourne shell in their cultural or actual lineage.
As for SQL, yes, lots of people want the order of clauses to be redone. There's no reason it couldn't be -- I think it'd be a relatively small change to existing SQL parsers to allow clauses to come in different orders. But I don't have this particular cognitive problem, and I think it's because I know to look at the table sources first, but I'm not sure.
- esafak 3y agoThe 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...
- hiAndrewQuinn 3y agoI'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/ https://betterdev.blog/minimal-safe-bash-script-template/
- theshrike79 3y agoWhen the shell script is that long, I reach for Python or Go instead pretty fast =)
- imp0cat 3y agoAu contraire, bash/sh is pretty much everywhere. Also, we have ChatGPT now. That helps a lot.
- dgb23 3y agoA possibly radical way of fixing the SQL clause order would be to introduce "project" which behaves like "select" but can be put in the right place.
- esafak 3y agohttps://malloydata.github.io/documentation/language/views https://malloydata.github.io/documentation/language/views
- hyperthesis 3y agoWhen 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.
- chubot 3y agoYes, `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 post about it :) Details: https://www.oilshell.org/release/latest/doc/error-handling.html https://www.oilshell.org/release/latest/doc/error-handling.h... https://www.oilshell.org/release/latest/doc/simple-word-eval.html https://www.oilshell.org/release/latest/doc/simple-word-eval... These docs are comprehensive, but most people don't want that level of detail, so having someone else test it and write something short would help! For awhile I didn't "push" Oils because it still had a Python dependency. But it's now in pure C++, and good news: as of this week, we're beating bash on some compute-bound benchmarks! (I/O bound scripts have always been the same speed, which is most shell scripts) (Also, we still need to rename Oil -> YSH in those docs, that will probably cause some confusion for awhile - https://www.oilshell.org/blog/2023/03/rename.html https://www.oilshell.org/blog/2023/03/rename.html )
- chubot 3y agoSlight correction: bin/ysh has a few things that ysh:upgrade doesn't catch https://lobste.rs/s/6gycoi/making_hard_things_easy#c_sjfxif https://lobste.rs/s/6gycoi/making_hard_things_easy#c_sjfxif Feedback is welcome (especially based on upgrading real scripts)
- vaughan 3y ago> As for SQL We should peel off SQL and get access to the underlying layers.
- code_biologist 3y agoWhat if my SQL engine is Presto, Trino [1], or a similar query engine? If it's federating multiple source databases we peel the SQL back and get... SQL? Or you peel the SQL back and get... S3 + Mongo + Hadoop? Junior analysts would work at 1/10th the speed if they had to use those raw. [1] https://trino.io/ https://trino.io/