La programmazione secondo la filosofia UNIX è la stessa della programmazione funzionale?

L'ambiente di programmazione UNIX (il testo classico) afferma che l'approccio UNIX alla programmazione è quello di costruire piccoli strumenti ben definiti che possono essere combinati per risolvere problemi più complessi. Nell'apprendimento di C e della shell Bash, ho scoperto che questo è un concetto potente che può essere utilizzato per affrontare una vasta gamma di problemi di programmazione.

Solo usando una piattaforma Linux, il concetto è abbastanza chiaro e usato tutto il tempo. Qualsiasi espressione formata sulla riga di comando che reindirizza l'I / O, collegando strumenti di sistema come ls, grep, more e così via, mostra quanto sia potente questo concetto.

La cosa che mi confonde è che molti di questi programmi sono scritti in C, usando uno stile di programmazione imperativo / procedurale, ma il modo in cui sono usati e uniti sulla riga di comando mi sembra molto più simile alla programmazione funzionale, dove ogni programma è una funzione isolata che non dipende dallo stato di qualsiasi altro programma a cui potrebbe essere unita.

È accurato, comprendere la filosofia di programmazione UNIX è fondamentalmente una programmazione funzionale usando strumenti che potrebbero essere stati costruiti usando uno stile di programmazione imperativo?

Credo che hai un punto lì, ma cp, rm, cde un sacco di altri cambiamento di stato, quindi non sono in realtà funzioni. La filosofia UNIX riguarda più di fare solo una cosa, ma di farlo bene; spesso farlo bene significa consentire un uso funzionale, ma non sempre.

La risposta è nella "programmazione I / O Monadic e UNIX shell" di Oleg Kiselyov.

Questo è un saggio ispirato al documento di Philip Wadler "How to Declare an Imperative" [ Wadler97 ]. Mostreremo sorprendenti somiglianze tra I / O monadici in Haskell e composizioni di filtri UNIX basate su pipe e reindirizzamenti. Le pipe UNIX (trattate semanticamente come scrittura su file temporanei) sono abbastanza simili alle monadi. Inoltre, a livello di programmazione UNIX, tutti gli I / O possono essere considerati monadici ...

Beh, immagino che puoi guardarlo in quel modo se ignori l'intero problema degli effetti collaterali. I comandi Unix NON agiscono frequentemente per quanto riguarda la restituzione dello stesso set di dati con gli stessi input. Tuttavia, come hai detto, l'aspetto delle tubazioni è simile al modo in cui è possibile eseguire la programmazione funzionale.

In una certa misura puoi dirlo. Ma questo non è necessariamente vero. Penso che dovresti leggerlo di più come "capacità di ottenere di più" con un approccio progettuale semplicistico. E per essere semplice dovrai dividere il compito in parti facilmente comprensibili e facili da assemblare. La filosofia UNIX di essere sincero con te, può essere spiegata con il seguente esempio.

Tutta la programmazione è una sorta di manipolazione dei dati! E in alcuni casi la programmazione è anche la manipolazione del programma stesso (Metaprogrammazione). Ora funziona la filosofia UNIX: Immagina di elaborare il testo. Cos'è il testo? Dopotutto, il testo è una specie di dati. Quando assemblato in una definizione organizzata, il testo diventa anche XML e JSON. Il testo può anche essere un elenco di numeri, il testo può anche essere csv, tsv e cosa no! In altri testi o stringhe può rappresentare una vasta area di dati di programmazione, proprio perché il suo contesto può essere distorto e trasformato in ciò che vogliamo!

Tutta la programmazione richiede una certa organizzazione dei dati. L'organizzazione richiede la ricerca ...

un. Ecco, basta avere 'grep', 'fgrep' e la sua famiglia per farlo.

Una volta effettuata la ricerca, devi fare un po 'di ordinamento.

b. Ora abbiamo il comando 'sort' per farlo.

Hai appena ordinato due file, ora desideri confrontarli.

c. Ora abbiamo 'diff', 'cmp' et al per farlo.

Hai appena scoperto che non c'è differenza tra i file. Ora hai bisogno di più dati organizzati.

d. Hai operatori 'cat', pipe e reindirizzamenti da scrivere in un file.

Hai bisogno di analisi più specifiche.

e. Hai la testa, la coda, di più, di meno, taglia et al per farlo ...

Tutto questo cucito insieme usando '|' per generare cose davvero potenti qualche volta senza scrivere alcun codice. Per ulteriori ricerche e cuciture hai ..

f. awk, shell e sed.

awk, shell e sed ti danno un maggiore controllo sul testo di quello che ti offre Cut, Diff et al. Vi siete mai chiesti che command1 | comando2 | La serie command3 ... è una sorta di meccanismo del flusso di lavoro. Se combinato con If, questo diventa più potente.

Ora arriva più divertente.

Hai mai sentito parlare di un'utilità chiamata 'Perl' , questa cosa è così potente che puoi praticamente fare qualsiasi attività a portata di mano con il minimo lavoro immaginabile. Cucito insieme a un'utilità come DBM, è possibile eseguire anche richieste di persistenza di tempo ridotto per la propria applicazione. Ricorda che non siamo nemmeno usciti dal mondo del testo, ma siamo comunque riusciti a coprire la maggior parte degli aspetti di un ambiente di programmazione.

Quindi penso che UNIX sia più di un sistema operativo. È una raccolta di strumenti e ambienti progettati per risolvere i problemi nel modo più semplice. Un modo semplice non implica necessariamente la semplicità di implementazione della soluzione. Ma la semplicità stessa non ti porta molto lontano.

Ho letto questo dove su reddit.

"Se il tuo unico obiettivo di progettazione è la semplicità, otterrai tutti gli utenti di Plan9"

Il modo in cui sono uniti sulla riga di comando e interagiscono tra loro è molto funzionale. Tuttavia, direi che questo ha più a che fare con il design della shell, e meno con se quei programmi sottostanti sono scritti in modo imperativo o funzionale. La maggior parte dei buoni linguaggi funzionali supporta concetti imperativi / procedurali, anche se il loro design complessivo si presta alla programmazione funzionale. Sì, molte delle funzionalità della shell UNIX utilizzano concetti funzionali ma, ancora una volta, ciò è dovuto più alla progettazione della shell che alla particolare implementazione dei programmi sottostanti.

Spero che sia di aiuto,

-tjw