The most surprising Unix programs • Hacker News Board

Re: The most surprising Unix programs

#121

Post by nullc » Sun, Mar 15, 2020, 6:52 PM UTC

bloomer wrote: post #91

londons_explore wrote: post #53

> The math library for Bob Morris's variable-precision desk calculator used backward error analysis to determine the precision necessary at each step to attain the user-specified precision of the result. I wonder if compilers could do this today? If you can bound values for floating point operations, you might be able to replace them with fixed point equivalents and get a big speedup. You might also be able to replac…

This isn’t a performance optimization but rather an accuracy optimization. Even if the requested output is a double (64-bits) the intermediate calculations often need to be done to higher precision to get fully accurate answers. Note that the desktop calculator on Android does the same analysis by using computable numbers. https://dl.acm.org/doi/10.1145/2911981 Is a nice overview.

It's also a performance optimization though, since otherwise would might instead just use 400 digits of precision (or whatever) all the time, and round just the output.

Re: The most surprising Unix programs

#122

Post by steveklabnik » Sun, Mar 15, 2020, 6:56 PM UTC

saagarjha wrote: post #118

loeg wrote: post #101

Earlier quoted context omitted.

I often found Rust's errors completely confusing, even after chasing down the '--explain CrypticNNNNN' follow-up explainer. This was in 2019 — not some ancient version of Rust.

Yeah, Rust’s compiler errors are decent if you make simple mistakes but degrade to being about as bad as any other modern compiler’s once you start doing complicated things. Which isn’t horrible, but --explain isn’t really useful so it’s just wasting space on my screen.

Please file bugs for any message that is confusing! We track them like any other bug, and there’s some folks actively working on them.

Re: The most surprising Unix programs

#123

Post by nullc » Sun, Mar 15, 2020, 6:59 PM UTC

yegle wrote: post #110

killall5 is the most bizarre command that I learned recently. Read manpage before trying it.

Sys5 killall: Bane of all regular linux administrators that also sometimes administered solaris boxes.

Once after blowing up an in production database server during the day, I suffered the unfortunate difficulty of having to explain why running a command "killall" on a critical server that killed everything was an innocent mistake and that I didn't have any reason to expect it to kill everything.

It's extremely difficult to not sound like a moron when explaining that you didn't expect "killall" to "kill all".

Re: The most surprising Unix programs

#124

Post by saagarjha » Sun, Mar 15, 2020, 7:08 PM UTC

steveklabnik wrote: post #122

saagarjha wrote: post #118

Earlier quoted context omitted.

Yeah, Rust’s compiler errors are decent if you make simple mistakes but degrade to being about as bad as any other modern compiler’s once you start doing complicated things. Which isn’t horrible, but --explain isn’t really useful so it’s just wasting space on my screen.

Please file bugs for any message that is confusing! We track them like any other bug, and there’s some folks actively working on them.

Hmm, I wouldn’t call them confusing per se, they’re just not useful, and I don’t think any compiler has really solved this problem (but then again, generation of compiler error messages is not something I’m an expert in). Let’s say I forgot to put a “*” in front of something: the compiler’s error might be something like “xyz does not implement SomeTrait, here is a page explaining what traits are”. I’d be more than happy to file bugs for things like these but I have generally refrained from doing so because I am unsure if this is something that is possible to fix. If you’d like, I could file issues for things like this, but I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area.

Re: The most surprising Unix programs

#125

Post by noisy_boy » Sun, Mar 15, 2020, 7:10 PM UTC

I didn't find egrep surprising - I use it quite often. The thing I didn't know about it was that it was Al Aho's creation. I only knew about him from awk.

Re: The most surprising Unix programs

#126

Post by steveklabnik » Sun, Mar 15, 2020, 7:12 PM UTC

saagarjha wrote: post #124

steveklabnik wrote: post #122

Earlier quoted context omitted.

Please file bugs for any message that is confusing! We track them like any other bug, and there’s some folks actively working on them.

Hmm, I wouldn’t call them confusing per se, they’re just not useful, and I don’t think any compiler has really solved this problem (but then again, generation of compiler error messages is not something I’m an expert in). Let’s say I forgot to put a “*” in front of something: the compiler’s error might be something like “xyz does not implement SomeTrait, here is a page explaining what traits are”. I’d be more than ha…

Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug.

> I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area.

It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then ship. And then look at the next error.

Re: The most surprising Unix programs

#127

Post by pvaldes » Sun, Mar 15, 2020, 7:45 PM UTC

both rename and mmv are pretty handy

Re: The most surprising Unix programs

#128

Post by thedance » Sun, Mar 15, 2020, 7:47 PM UTC

abetusk wrote: post #71

For me, the most surprising one was paste. paste allowed me to interleave to streams or to split out a single stream into two columns. I'd been writing custom scripting monstrosities before I discovered paste: $ paste I wonder what other unix gems I've been missing...

paste is an important part of the shell wizard's diet. paste with one input from `yes` is quite useful.

Re: The most surprising Unix programs

#129

Post by pvaldes » Sun, Mar 15, 2020, 7:47 PM UTC

tangue wrote: post #29

I didn't knew about typo. One surprising unix program I discovered this year is cal (or ncal). Having a calendar in your terminal is sometimes useful and I wish I knew earlier I could type things like ncal -w 2020

or cal -3 -m 3 2020

Re: The most surprising Unix programs

#130

Post by bloomer » Sun, Mar 15, 2020, 7:47 PM UTC

nullc wrote: post #121

bloomer wrote: post #91

Earlier quoted context omitted.

This isn’t a performance optimization but rather an accuracy optimization. Even if the requested output is a double (64-bits) the intermediate calculations often need to be done to higher precision to get fully accurate answers. Note that the desktop calculator on Android does the same analysis by using computable numbers. https://dl.acm.org/doi/10.1145/2911981 Is a nice overview.

It's also a performance optimization though, since otherwise would might instead just use 400 digits of precision (or whatever) all the time, and round just the output.

Somewhat, in that it doesn’t use more precision than needed, but the real issue is you can’t just pick some arbitrarily large precision and round at the end. For some calculations, even 400 digits during intermediate steps would not be enough due to catastrophic cancellation and you would need to go even higher precision to get the right answer. It really is about solving an accuracy issue and not an optimization. And determining that you are using sufficient precision to get an accurate answer is an extra cost, so it is always more expensive than just plowing ahead and calculating an inaccurate answer.