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

61–70 of 182 posts

Re: The most surprising Unix programs

#61

Post by ivansavz »

mci wrote: post #26

> Hidden inside WWB (writer's workbench), Lorinda Cherry's Parts annotated English text with parts of speech, based on only a smidgen of English vocabulary, orthography, and grammar. Writer's Workbench was indeed a marvel of 1970's limited-space engineering. You can see it for yourself [1]: the generic part-of-speech rules are in end.l, the exceptions in edict.c and ydict.c, and the part-of-speech disambiguator in ps…

This Writer's Workbench seems really cool. The wikipedia page indicates there were quite a few more programs in the suite: https://en.wikipedia.org/wiki/Writer%27s_Workbench#Package_c...

Do you know where I could be able to find the source for all of these?

I'd be interested to "revive" these utils, possibly rewriting as python or bash for easy hacking. I have some basic scrips for that, and they are already proving to be useful even though they simply call grep https://github.com/ivanistheone/writing_scripts

Re: The most surprising Unix programs

#62

Post by ahoka »

mci wrote: post #26

> Hidden inside WWB (writer's workbench), Lorinda Cherry's Parts annotated English text with parts of speech, based on only a smidgen of English vocabulary, orthography, and grammar. Writer's Workbench was indeed a marvel of 1970's limited-space engineering. You can see it for yourself [1]: the generic part-of-speech rules are in end.l, the exceptions in edict.c and ydict.c, and the part-of-speech disambiguator in ps…

It's very interesting that the readme calls shell scripts "runcom", an archaic name coming from the Compatible Time Sharing System. This is also the origin for rc files.

Re: The most surprising Unix programs

#63

Post by morelisp »

mhd wrote: post #46
morelisp wrote: 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.

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 warnings, lint, and a few other tools to also get warnings about legacy interfaces (gets), dangerous practices (ignoring error codes), and unusual structure (shadowed variables, loop conditions that seemed impossible). Today we finally have considerably better tools that don't just check if you match a style guide but do a full reformat (not nitpicking, but doing it for you) and linters that can enforce 'deeper' structural demands, sometimes with automatic fixes.

But 40 years ago we had tools to completely restructure programs to a normalized form, and the practical experience to know programmers found this form preferable! And like so many things in our field, 10-20 years later we had to rediscover it, painfully, all over again. Probably because today's programmers think source-to-source Fortran/Ratfor translation has "almost nothing to do" with the challenges facing them today.

Re: The most surprising Unix programs

#64

Post by sitkack »

Someone wrote: post #51
saagarjha wrote: post #7

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…

I would guess the most useful part of that is that would allow parsing to proceed further . I used an Algol compiler that had messages such as: Semicolon missing after end (inserted) Undeclared identifier ‘foo’ (assumed integer) Both of these hugely improved the compiler output, as far fewer utterly useless error messages would be produced (yes, I know I didn’t declare ‘foo’. You told me so the previous 12 times I us…

Couple this with ast and source similarity search (how this is enabled is tbd) would allow one to not only suggest how to complete the program via the compiler's analysis, but then also find code that was similar to your program across all source say in crates.io or on github.

Great learning tool, but also the ability to copy-pasta from terabytes of code ... (scurries off to do some analysis).

Re: The most surprising Unix programs

#65

Post by burntsushi »

tannhaeuser wrote: post #21
Mediterraneo10 wrote: post #13

Earlier quoted context omitted.

I had never heard of eqn and was surprised to find that the binary is still there on my Linux box. With regard to roff in general, when I got into Linux-based typesetting around the turn of the millennium, that was already seen as antiquated tech, superseded by LaTeX which was undergoing a frenzy of development and improvement around that time. So, anyone under the age of 30 will probably be hearing of such *roff stu…

Ok I'm probably showing my age here then :) Back in the 1980 and 1990s, the roff suite, and most definitely egrep and classic Thompson DFA construction and DFA->NFA conversion was definitely Unix folklore/taught in Uni. Manpages are still rendered using roff/groff today, so probably many of us are using it regularly. Whereas GNU's texinfo has matured less well I'd say, or wasn't even very useful in practice to begin…

> and most definitely egrep and classic Thompson DFA construction and DFA->NFA conversion was definitely Unix folklore/taught in Uni

I think you mean "Thompson NFA construction" and "NFA->DFA."

Regardless though, this is not what the OP is pointing out. 'egrep' (or just GNU grep these days) is doing something more clever (emphasis mine):

> Al Aho expected his deterministic regular-expression recognizer would beat Ken's classic nondeterministic recognizer. Unfortunately, for single-shot use on complex regular expressions, Ken's could finish while egrep was still busy building a deterministic automaton. To finally gain the prize, Al sidestepped the curse of the automaton's exponentially big state table by inventing a way to build on the fly only the table entries that are actually visited during recognition.

Russ Cox talks about this a bit in part 3 of his articles on regex matching[1]. Its implementation in RE2 is here: https://github.com/google/re2/blob/master/re2/dfa.cc

[1] - https://swtch.com/~rsc/regexp/regexp3.html

Re: The most surprising Unix programs

#66

Post by perl4ever »

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 )

In the 40s, I don't think computing was a thing like you're implying, kind of like nuclear reactors were a very very tiny area. The explosion of computer usage and programming was more like the late 50s, when Fortran came out. Even then, I don't think people even thought in terms of a "computing workforce". Nobody majored in computers, a programmer might be a math major or might not. Male engineers had female assistants that were more than typists, but not the same as a Google SWE today either. Nor the same personalities.

My source is my own family history and it makes me annoyed at the anachronistic assumptions and framework that people shoehorn historical tidbits into when discussing this topic.

By the way, how can you have 50% in the 60s and then a peak at 37% later?

Re: The most surprising Unix programs

#67

Post by TomNomNom »

pimlottc wrote: post #39
nunoferreira wrote: post #35

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…

My advice is to sort the files just-in-time using the shell:

    comm

Re: The most surprising Unix programs

#68

Post by chris_st »

saagarjha wrote: post #7

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…

I played around with it a bit in college; in my experience, the "help" wasn't very helpful, although it was suggesting keywords and not semi-colons (though I might not have left any out). I don't remember any specific examples, but I think the thing was that it was suggesting syntactically correct things, but they seemed irrelevant compared to the semantics of what I was trying to do.

I think it's interesting that McIlroy was able to learn Pascal from it!

Re: The most surprising Unix programs

#69

Post by tjalfi »

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?

Typo was added in Research Unix V5[0] and also present in V6[1]. It isn't in V7, my guess is that it was replaced by spell. I don't think it would be difficult to get it compile on a modern system.

[0] https://github.com/dspinellis/unix-history-repo/blob/Researc...

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

Re: The most surprising Unix programs

#70

Post by zamadatix »

nunoferreira wrote: post #35

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 perfect for scripting usage but you might find diff better for human usage. Added bonus diff also does binary.

Plus diff was in part written by the author of the linked content :).

Post reply on HN