The Unix Chainsaw - Gary Bernhardt

Gary Bernhardt[1] gave a great talk about practical problem solving with the unix shell: "The Unix Chainsaw"[2]. "Half-assed is OK when you only need half of an ass." In the talk, he gives several demonstrations a key aspect of why unix pipelines are so practically useful: you build them interactively . A complicated 4 line pipeline started as a single command that was gradually refined into something that actually solves a complicated problem. This talk demonstrates the part that isn't included in the the usual tutorials or "cool 1-line command" lists: the cycle of "Try something. Hit up to get the command back. Make one iterative change and try again." [1] You might know him from his other hilarious talks like "The Birth & Death of JavaScript" or "Wat". [2] [this video]

As others have already menti9oned, running 'bc' isn't actually that expensive. Comparing it to Bitcoin is ridiculous. Let's investigate the actual cost of that sum: $ cat foo.sh #!/bin/bash a="1.5" b="0.5" sum="$(echo "${a} + ${b}" | bc)" echo "The sum of ${a} and ${b} is ${sum}" $ /usr/bin/strace -q -D -w -c ./foo.sh The sum of 1.5 and 0.5 is 2.0 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 55.53 0.001225 123 10 read 9.75 0.000215 215 1 execve 5.53 0.000122 7 18 mmap 4.03 0.000089 8 11 3 open 3.04 0.000067 7 10 mprotect 2.99 0.000066 5 13 rt_sigprocmask 2.54 0.000056 56 1 clone 2.45 0.000054 5 10 close 2.40 0.000053 5 11 rt_sigaction 1.81 0.000040 5 8 fstat 1.41 0.000031 8 4 lseek 1.22 0.000027 5 5 3 stat 0.91 0.000020 20 1 write That was 56us to clone(2) the process and 215us to execve(2) 'bc'. All together just 12.74% of the time spent running syscalls , and an even smaller portion of the total time to launch and execute this simple example. Most of the time is sent launching bash itself at the beginning. Using a language such as python or launching a custom binary will have similar costs to to launch the program. If we're talking about a single persistent process (e.g. an interactive shell), then we're still talking about paying just 0.25ms of CPU time to perform a useful calculation . Compared to intentionally wasting time by design maximizing hash prefix guesses to "mine" Bitcoin "ain't the same fucki

1.) Be curious. Stay curious. Experiment, play with things. Your time during university is likely the best time for this and it will likely get harder later on when you're on the job and there's much more emphasis on finished work than on learning experiences. Also, I'm quite sure that it will be beneficial for you if you familiarize yourself with different ways of thinking (obviously programming languages, environments and paradigms, but that will likely apply to anything non-technical, as well). I gained this perspective from dealing with people who didn't really do that, but also from knowing that I personally also did this way too late (and from the benefits it brought me nonetheless). If you're only familiar with Windows, try Linux. Try BSD. Try OS X, if you want to. Try working in the terminal. Familiarize yourself with different editors (especially Vim and Emacs, maybe also newer ones like Kakoune). Learn bash, have a look at AWK and sed. Maybe learn Perl. Try out functional programming, logic programming (like Prolog) and so on and so forth. If you're feeling adventurous, play with niche systems like Haiku[1] or TempleOS[2], just to gain new insights on how things could work. Maybe try the ACME editor[3]. [1]: [link] [2]: [link] [3]: [link] Of course, there might be courses that will nudge towards some of those tools. If you visit some of those: Cool! But if there are no such courses (I didn't encounter many of them myself), try to explore these things nonetheless. Ev