A programação na filosofia UNIX é a mesma que a programação funcional?

O ambiente de programação UNIX (o texto clássico) afirma que a abordagem UNIX à programação é criar ferramentas pequenas e bem definidas que podem ser combinadas para resolver problemas mais complexos. Ao aprender C e o shell Bash, descobri que esse é um conceito poderoso que pode ser usado para lidar com uma ampla gama de problemas de programação.

Apenas usando uma plataforma Linux, o conceito é bastante claro e usado o tempo todo. Qualquer expressão formada na linha de comando que redireciona a E / S, vinculando ferramentas do sistema como ls, grep e muito mais, mostra o quão poderoso esse conceito é.

O que me confunde é que muitos desses programas são escritos em C, usando um estilo de programação imperativa / procedural, mas a maneira como são usados ​​e unidos na linha de comando parece muito mais com a programação funcional para mim, onde cada programa é uma função isolada que não depende do estado de qualquer outro programa ao qual possa estar associado.

É preciso entender que a filosofia de programação UNIX é basicamente programação funcional usando ferramentas que podem ter sido construídas usando um estilo de programação imperativo?

Eu acho que você tem um ponto lá, mas cp, rm, cde um monte de outros mudar de estado, para que eles não são realmente funções. A filosofia do UNIX é mais sobre fazer apenas uma coisa, mas fazer bem; fazer isso bem significa permitir o uso funcional, mas nem sempre.

A resposta está na "programação de shell Monadic i / o e UNIX", de Oleg Kiselyov.

Este é um ensaio inspirado no artigo de Philip Wadler "Como declarar um imperativo" [ Wadler97 ]. Mostraremos semelhanças estranhas entre E / S monádica em Haskell e composições de filtro UNIX com base em pipes e redirecionamentos. Os pipes UNIX (tratados semanticamente como gravação em arquivos temporários) são bastante semelhantes às mônadas. Além disso, no nível da programação UNIX, todas as E / S podem ser consideradas monádicas ...

Bem, acho que você pode olhar dessa maneira se ignorar toda a questão dos efeitos colaterais. Os comandos Unix freqüentemente NÃO agem em função de sempre retornar o mesmo conjunto de dados com as mesmas entradas. No entanto, como você mencionou, o aspecto da tubulação é semelhante ao modo como a programação funcional pode ser feita.

Até certo ponto, você pode dizer isso. Mas isso não é necessariamente verdade. Eu acho que você deveria ler isso mais como 'capacidade de conseguir mais' com uma abordagem de design simplista. E, para ser simples, você terá que dividir a tarefa em partes facilmente compreensíveis e fáceis de montar. A filosofia do UNIX de ser franco com você pode ser explicada com o seguinte exemplo.

Toda a programação é algum tipo de manipulação de dados! E, em alguns casos, a programação também é a própria manipulação do programa (meta-programação). Agora, a maneira como a filosofia do UNIX funciona é: Imagine processando texto. O que é texto? O texto é algum tipo de dado, afinal. Quando montado na definição organizada, o texto também se torna XML e JSON. O texto também pode ser uma lista de números, o texto também pode ser csv, tsv e o que não! Em outro texto ou string, pode representar uma enorme área real de dados de programação, apenas porque seu contexto pode se distorcer e se transformar no que queremos!

Toda a programação requer algum tipo de organização de dados. A organização requer pesquisa ...

uma. Lá você vai com apenas 'grep', 'fgrep' e sua família para fazer isso.

Depois de pesquisar, é necessário fazer uma classificação.

b. Agora temos o comando 'sort' para fazer isso.

Você acabou de classificar dois arquivos, agora deseja compará-los.

c. Agora temos 'diff', 'cmp' et al para fazer isso.

Você acabou de descobrir que não há diferença entre os arquivos. Você precisa de mais dados organizados agora.

d. Você tem operadores de 'gato', pipes e redirecionamentos para gravar em um arquivo.

Você precisa de uma análise mais específica.

e Você tem cabeça, cauda, ​​mais, menos, corta e faz isso ...

Tudo isso é costurado usando o '|' para gerar coisas realmente poderosas por algum tempo sem escrever nenhum código. Para mais pesquisas e costura, você tem ..

f. awk, shell e sed.

awk, shell e sed oferecem a você mais controle sobre o texto do que o que cut, diff et al podem oferecer. Você já se perguntou esse command1 | command2 | command3 ... series é uma espécie de mecanismo de fluxo de trabalho. Quando combinado com o If, isso se torna mais poderoso.

Agora vem mais divertido.

Você já ouviu falar de um utilitário chamado 'Perl' , que é tão poderoso que você pode virtualmente executar qualquer tarefa com o mínimo de trabalho possível. Reunidos com um utilitário como o DBM, você pode fazer demandas de persistência de tempo ainda menores para seu aplicativo. Lembre-se de que nem sequer saímos do mundo do texto, mas ainda conseguimos cobrir a maioria dos aspectos de um ambiente de programação.

Então, acho que o UNIX é mais do que um sistema operacional. É uma coleção de ferramentas e ambiente projetados para resolver os problemas da maneira mais simples. Uma maneira simples não implica necessariamente simplicidade de implementação da solução. Mas a simplicidade em si não leva muito longe.

Eu li isso em algum lugar no reddit.

"Se seu único objetivo de design é a simplicidade, você terá tantos usuários quanto o Plan9"

A maneira como eles são unidos na linha de comando e interagem entre si é muito funcional. No entanto, eu diria que isso tem mais a ver com o design do shell e menos com a questão de saber se esses programas subjacentes são escritos imperativamente ou funcionalmente. A maioria das boas linguagens funcionais suporta conceitos imperativos / procedimentais, mesmo que seu design geral se dedique à programação funcional. Sim, muitos dos recursos do shell UNIX empregam conceitos funcionais, mas, novamente, isso se deve mais ao design do shell do que à implementação específica dos programas subjacentes.

Espero que isto ajude,

-tjw