Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The most surprising Unix programs

minnie.tuhs.org

Post reply on HN
Print view View original

111–120 of 182 posts

Re: The most surprising Unix programs

#111

Post by TheDesolate0 »

kps wrote: post #81
saati wrote: post #78

Earlier quoted context omitted.

I actually did, it did not answer my question, that's why I asked here.

> pascal > > The syntax diagnostics from the compiler made by Sue Graham's group at > Berkeley were the mmost helpful I have ever seen--and they were generated > automatically. At a syntax error the compiler would suggest a token that > could be inserted that would allow parsing to proceed further. No attempt > was made to explain what was wrong. The compiler taught me Pascal in > an evening, with no manual at hand.

I'm scrapping off some old brain cells here but I believe it's before the language (Pascal) and it was like a linter, but more like rustc's behavior.

Re: The most surprising Unix programs

#112

Post by pavlov »

londons_explore wrote: post #76
pavlov wrote: post #58

Earlier quoted context omitted.

Replacing floats with fixed point isn’t usually a meaningful optimization on modern CPUs. The FPU runs in parallel to the integer units, so you can easily end up idling the FPU while the integer units are too busy doing both the math and the necessary state management (counters, pointer arithmetic etc.) This could make sense for SIMD however, but then the problem is getting the array data in the right format before t…

Fixed point uses a lot less power though, and many use cases are effectively power limited rather than functional-unit limited, since if you really do fill all functional units on every cycle you'll soon need to throttle back your clock speed... Perhaps a good example of that is video encoding, which is mostly fixed point, despite it looking like a pretty close fit for floating point maths.

A very good point. My worldview of performance is highly biased towards “full steam ahead” desktop graphics.

Video encoding is a bit of a special case though because the common algorithms are carefully designed for hardware acceleration. For most rendering, it doesn’t make sense to go out of your way to avoid the FPU.

Re: The most surprising Unix programs

#113

Post by TheDesolate0 »

saagarjha wrote: post #12
ur-whale wrote: post #11

First time I hear of typo ... it's not on my standard Linux install ... where can I find the source code?

It’s not quite the original, but Rob Pike wrote an implementation in Go: https://github.com/robpike/typo

In go? This is a job for rust!

...there goes my weekend.

Re: The most surprising Unix programs

#114

Post by jerf »

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...

Recently I found myself wanting to stop a program after a certain timeout. I found myself thinking "sure there's a UNIX program to do this in shell?" There is. And it's called... brace yourself... "timeout".

20+ years in UNIX, never encountered it. Part of GNU coreutils.

Re: The most surprising Unix programs

#115

Post by TheDesolate0 »

morelisp wrote: post #63
mhd wrote: post #46

Earlier quoted context omitted.

As usual, the original paper is paywalled, but it appears that this is about transforming ancient Fortran from GOTOs to structured control-flow (if-then, loops etc.). That has almost nothing to do with the spaces-and-braces nitpicking of prettier/gofmt etc.

Not "almost nothing to do" - putting programs into a readable normal form seems the natural evolution of these tools. When I started programming in the 90s, "spaces-and-braces" checking - as you say, nitpicking - was basically all we had, along with limited automatic tools to fix them (all more or less as good as `M-x indent-region`). If you were lucky and in a widely-used language you could cobble together compiler…

I _still_ do this today with new (to me) code bases!

By doing this I really read the code, and really get to understand what the previous programmer was doing.

Also something I took from Asimov's foundation series, code that doesn't look right, doesn't run right.

I know, not really; compiler gives no fucks, but I'm not a compiler however, and GCC error messages (Clang too!) are still about as useful as a hot bikini wax is to a walrus.

This was one of the features that made me really fall in love with Emacs back in the day! I could set it up to force my style requirements, then even yanked (pasted) code would be proper (mostly) and I couldn't fat finger my code to death.

My only emacs complaint is lisp. I get it, I just don't like it. I'll take fortran 77 over lisp any day (not 66 or before, tho. I'm not that crazy). So, sorry mr(s) moar lisp.

Re: The most surprising Unix programs

#116

Post by reaperducer »

indigochill wrote: post #31
cmroanirgo wrote: post #18

Earlier quoted context omitted.

Also interesting: > Originators of nearly half the list--pascal, struct, parts, eqn--were women, well beyond women's demographic share of computer science.

In the 40s, computing was seen as primarily women's work (similar to the stereotype of switchboard operators). Into the 60s, women still comprised up to half of the computing workforce. In 84, they peaked at 37%. So demographically speaking, the ratio was not as bad as it is today. (Source: https://en.wikipedia.org/wiki/Women_in_computing )

Into the 60s, women still comprised up to half of the computing workforce.

My life experience corroborates this.

When I was in school, girls were taught to type, and boys weren't. Because of that, many of the girls from my school went into computing, while the boys went to more "manly" pursuits. It's also why Catholic nuns were over-represented in early computing.

Re: The most surprising Unix programs

#117

Post by saagarjha »

jerf wrote: post #114
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...

Recently I found myself wanting to stop a program after a certain timeout. I found myself thinking "sure there's a UNIX program to do this in shell?" There is. And it's called... brace yourself... "timeout". 20+ years in UNIX, never encountered it. Part of GNU coreutils.

It’s unfortunately not part of POSIX, which means that BusyBox can’t get the options right or even stay consistently wrong :(

Re: The most surprising Unix programs

#118

Post by saagarjha »

loeg wrote: post #101
nicoburns wrote: post #38

Earlier quoted context omitted.

Once you've used a compiler like Rust or Elm that actually provides suggestions for common solutions to these errors (effectively building the tribal knowledge of what the error "really means" into the compiler itself), it's hard to tolerate these cryptic errors that only really make sense to machines.

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.

Re: The most surprising Unix programs

#120

Post by saagarjha »

yegle wrote: post #110

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

killall5 was our favorite way to log off the machine in high school, at least until the (clearly incompetent) lab administrator removed its execute permissions because it had “kill” in its name.
Post reply on HN