Live data from Hacker News

The most surprising Unix programs

minnie.tuhs.org

41–50 of 182 posts

Re: The most surprising Unix programs

#41

And people say theoretical computer science isn’t useful in “the real world”… I am curious about this one, though, has anyone used it? > 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…

Probably the majority of input validation (compilers or otherwise) errors I see today are still "unexpected x", and I would still often prefer "expected y".

Compilers have gotten significantly better in the past couple years. But in the browser I'm using to write this comment is even worse than "unexpected x", since it gives me the type and not even the token:

    var x = 1 console.log(x + 1)
    SyntaxError: unexpected token: identifier

Re: The most surprising Unix programs

#42

What's surprising about eqn, dc, and egrep? I'm using the latter two all the time, and have used eqn (+troff/groff and even tbl and pic) in the 1990's for manuals and as late as (early) 2000's to typeset math-heavy course material. Not nearly as feature-rich as TeX/LaTeX, but much more approachable for casual math, with DSLs for typesetting equations, tables, and diagrams/graphs. I was delighted to see that GNU had a…

You know who the author of the email is, right? He’s not using “surprising” in the sense of “I didn’t know this existed” but rather “these are quite amazing tools”.

Re: The most surprising Unix programs

#43
post #37
post #33

One of the useful applications of trigram-based analysis I have done is the following: for a large web-based application form where about 200000 online applications were made, we had to filter out the dummy applications - often, people would try out the interface using "aaa" as a name, for example. Since the names were mostly Indian, we did not even have a standard database of names to test against. What we did was t…

The problem with these methods is that you exclude everybody that deviates from the norm. Yes, it might make your life (as a developer) a little bit easier, but it makes the lives of some of the applicants a lot harder.

I think the "manual review" phase makes this OK, in a way that simply autobanning Mr Null from your system isn't.

Re: The most surprising Unix programs

#45
post #24

« Typo was as surprising inside as it was outside. Its similarity measure was based on trigram frequencies, which it counted in a 26x26x26 array. The small memory, which had barely room enough for 1-byte counters, spurred a scheme for squeezing large numbers into small counters. To avoid overflow, counters were updated probabilistically to maintain an estimate of the logarithm of the count. » This sounds like somethi…

Seems to me like a variant of a counting Bloom filter.

Re: The most surprising Unix programs

#46
post #3

> struct - Brenda Baker undertook her Fortan-to-Ratfor converter against the advice of her department head--me. I thought it would likely produce an ad hoc reordering of the orginal, freed of statement numbers, but otherwise no more readable than a properly indented Fortran program. Brenda proved me wrong. She discovered that every Fortran program has a canonically structured form. Programmers preferred the canonical…

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.

Re: The most surprising Unix programs

#47

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 )

"Workforce" can be a bit misleading though. If you look at Mad Men, the women were the majority of the ad agency workforce -- in the secretary pool.

An interesting statistic would be the gender ratio for people who published papers.

Re: The most surprising Unix programs

#48
post #43
post #37

Earlier quoted context omitted.

The problem with these methods is that you exclude everybody that deviates from the norm. Yes, it might make your life (as a developer) a little bit easier, but it makes the lives of some of the applicants a lot harder.

I think the "manual review" phase makes this OK, in a way that simply autobanning Mr Null from your system isn't.

I'm not sure if that would work either.

Why not send them an email to verify? Or use captcha tech developed by big companies that actually has some science behind it.

Re: The most surprising Unix programs

#49
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

Personally I prefer using the Mac app Alfred for things like that—basically a graphical one-shot terminal with autocompletion for a bunch of frequently-used stuff, in the vein of Spotlight. I whipped me up a script in Lua just so the calendar is faster than a readymade one in Python. However, Alfred needs to be bent somewhat to output content like a calendar in its suggestions.

Re: The most surprising Unix programs

#50

What about "comm" - compare two sorted files line by line. You can easily get occurrences only in file 1, in both files, only in file 2. Super powerful and saved me hours of work.

comm is a really useful tool, with one big caveat — you must make sure your input files are all sorted the exact same way. If not, you can get unexpected results, and worse, might not even realize it. This may seem obvious, but there are many tiny ways that sorts can differ between locales, operating systems and programs (e.g. Excel), especially when dealing with Unicode. It may look the same 99% of the time, and you…

Absolutely! From my experience I only use with listings from the same source with the same sort tool (mostly unix sort).
Post reply on HN