Então eu tentei fazer uma pequena pesquisa sobre isso procurando por manuais do PDP-10 / TOPS-10 para descobrir o que era o estado da arte antes dos tubos. Eu encontrei isso , mas TOPS-10 é incrivelmente difícil de pesquisar no google. Existem algumas boas referências sobre a invenção do cachimbo: uma entrevista com McIlroy < href="http://people.fas.harvard.edu/~lib113/reference/unix/unix2.html"> no histórico e impacto do UNIX .
Você tem que colocar isso no contexto histórico. Poucas das ferramentas e conveniências modernas que tomamos como garantidas existiam.
"At the start, Thompson did not even program on the PDP itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine."(29) A paper tape was generated on the GE 635 and then tested on the PDP-7 until, according to Ritchie, "a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few utilities (like the Unix rm, cat, cp commands) were completed. At this point, the operating system was self-supporting, programs could be written and tested without resort to paper tape, and development continued on the PDP-7 itself."
Um PDP-7 se parece com isso . Observe a falta de um display interativo ou disco rígido. O "sistema de arquivos" seria armazenado na fita magnética. Houve até 64kB de memória para programas e dados.
Nesse ambiente, os programadores tendiam a abordar o hardware diretamente, por exemplo, emitindo comandos para girar a fita e processar os caracteres, um de cada vez, lidos diretamente da interface de fita. O UNIX forneceu abstrações sobre isso, de modo que, em vez de "ler do teletipo" e "ler da fita" serem interfaces separadas, elas foram combinadas em uma, com a adição crucial de "leitura da saída de outro programa sem armazenar uma cópia temporária no disco". ou fita ".
Aqui está McIlroy sobre a invenção de grep
. Acho que isso faz um bom trabalho resumindo a quantidade de trabalho necessária no ambiente pré-UNIX.
"Grep was invented for me. I was making a program to read text aloud through a voice synthesizer. As I invented phonetic rules I would check Webster's dictionary for words on which they might fail. For example, how do you cope with the digraph 'ui', which is pronounced many different ways: 'fruit', 'guile', 'guilty', 'anguish', 'intuit', 'beguine'? I would break the dictionary up into pieces that fit in ed's limited buffer and use a global command to select a list. I would whittle this list down by repeated scannings with ed to see how each proposed rule worked."
"The process was tedious, and terribly wasteful, since the dictionary had to be split (one couldn't afford to leave a split copy on line). Then ed copied each part into /tmp, scanned it twice to accomplish the g command, and finally threw it away, which takes time too."
"One afternoon I asked Ken Thompson if he could lift the regular expression recognizer out of the editor and make a one-pass program to do it. He said yes. The next morning I found a note in my mail announcing a program named grep. It worked like a charm. When asked what that funny name meant, Ken said it was obvious. It stood for the editor command that it simulated, g/re/p (global regular expression print)."
Compare a primeira parte disso com o exemplo cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100
. Se suas opções são "construir uma linha de comando" versus "escrever um programa especificamente para o propósito, manualmente, em assembler", então vale a pena construir a linha de comando. Mesmo que leve algumas horas lendo os manuais (de papel) para fazer isso. Você pode então escrevê-lo para referência futura.