La programmazione nella filosofia UNIX è uguale alla programmazione funzionale?

30

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

Usando solo una piattaforma Linux, il concetto è abbastanza chiaro e usato sempre. Qualsiasi espressione formata sulla riga di comando che reindirizza 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, tuttavia il modo in cui sono usati e uniti nella riga di comando sembra molto più simile a una programmazione funzionale per me, dove ogni programma è una funzione isolata che non dipende dallo stato di qualsiasi altro programma a cui potrebbe essere unito.

È accurato, la comprensione della filosofia di programmazione UNIX è fondamentalmente una programmazione funzionale che utilizza strumenti che potrebbero essere stati creati utilizzando uno stile di programmazione imperativo?

    
posta dvanaria 22.03.2011 - 14:41
fonte

5 risposte

19

Penso che tu abbia un punto lì, ma cp , rm , cd e molti altri cambiano stato, quindi non sono realmente funzioni. La filosofia UNIX è più di fare solo una cosa, ma farlo bene; spesso farlo bene significa consentire l'utilizzo funzionale, ma non sempre.

    
risposta data 22.03.2011 - 14:47
fonte
9

La risposta è nel "Monadic i / o e programmazione shell UNIX" di Oleg Kiselyov.

This is an essay inspired by Philip Wadler's paper "How to Declare an Imperative" [Wadler97]. We will show uncanny similarities between monadic i/o in Haskell, and UNIX filter compositions based on pipes and redirections. UNIX pipes (treated semantically as writing to temporary files) are quite similar to monads. Furthermore, at the level of UNIX programming, all i/o can be regarded monadic...

    
risposta data 22.03.2011 - 19:24
fonte
6

Bene, immagino che si possa guardare in questo modo se si ignora l'intero problema degli effetti collaterali. I comandi Unix spesso NON funzionano in modo funzionale per quanto riguarda il ritorno sempre dello stesso set di dati con gli stessi input. Tuttavia, come hai detto, l'aspetto delle tubazioni è simile a come può essere eseguita la programmazione funzionale.

    
risposta data 22.03.2011 - 14:44
fonte
1

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 a che fare con se quei programmi sottostanti sono scritti imperativamente o funzionalmente. I migliori linguaggi funzionali supportano concetti imperativi / procedurali, anche se il loro design generale si presta alla programmazione funzionale. Sì, molte delle funzioni della shell UNIX impiegano concetti funzionali, ma, ancora, questo è dovuto più al design della shell che alla particolare implementazione dei programmi sottostanti.

Spero che questo aiuti,

-tjw

    
risposta data 22.03.2011 - 19:24
fonte
1

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

Tutta la programmazione è una sorta di manipolazione dei dati! E in alcuni casi la programmazione è anche la stessa manipolazione del programma (programmazione Meta). Ora come funziona la filosofia UNIX, immagina l'elaborazione del testo. Cos'è il testo? Il testo è una sorta di dati dopo tutto. Quando si assemblano 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 vera enorme area di dati di programmazione, solo perché il suo contesto può essere distorto e trasformato in ciò che vogliamo!

Tutta la programmazione richiede un'organizzazione dei dati di qualche tipo. Organizzare richiede la ricerca ...

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

Una volta eseguita la ricerca, devi eseguire un ordinamento ..

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

Hai appena ordinato due file, ora desideri confrontarli.

c. Ora abbiamo "diff", "cmp" e così via.

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

d. Hai a disposizione "cat", pipe e operatori di reindirizzamento per scrivere su un file.

Hai bisogno di un'analisi più specifica ..

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

Tutto questo viene cucito insieme usando '|' per generare un po 'di roba potente e potente senza scrivere alcun codice. Per più ricerca e cucito hai ..

f. awk, shell e sed.

awk, shell e sed ti danno un maggiore controllo sul testo rispetto a quello che puoi tagliare, diff et al. Ti sei mai chiesto quel comando1 | comando2 | command3 ... series è una sorta di meccanismo del flusso di lavoro. Se combinato con If's, questo diventa più potente.

Ora diventa più divertente.

Hai mai sentito di un'utilità chiamata "Perl" , questa cosa è così potente che puoi virtualmente svolgere qualsiasi compito con il minimo lavoro immaginabile. Insieme a un'utilità come DBM, è possibile eseguire richieste di persistenza anche di piccole dimensioni per l'applicazione. Ricorda che non siamo nemmeno usciti dal mondo del testo, ma siamo riusciti a coprire la maggior parte degli aspetti di un ambiente di programmazione.

Quindi penso che UNIX sia più di un sistema operativo. È una collezione 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à in sé non ti porta molto lontano.

Ho letto questo su "reddit".

"Se il tuo unico obiettivo di progettazione è la semplicità, avrai tanti utenti quanti sono Plan9"

    
risposta data 25.03.2011 - 09:32
fonte

Leggi altre domande sui tag