Czy programowanie w filozofii UNIX jest takie samo jak programowanie funkcjonalne?

Środowisko programistyczne UNIX (tekst klasyczny) stwierdza, że ​​podejście UNIX do programowania polega na tworzeniu małych, dobrze zdefiniowanych narzędzi, które można łączyć w celu rozwiązywania bardziej złożonych problemów. Podczas nauki C i powłoki Bash odkryłem, że jest to potężna koncepcja, którą można wykorzystać do radzenia sobie z wieloma problemami programistycznymi.

Używając platformy Linux, koncepcja jest dość przejrzysta i używana przez cały czas. Każde wyrażenie utworzone w wierszu poleceń, które przekierowuje operacje we / wy, łącząc narzędzia systemowe, takie jak ls, grep, itd., Pokazuje, jak potężna jest ta koncepcja.

Problemem jest to, że wiele z tych programów jest napisanych w C, przy użyciu imperatywnego / proceduralnego stylu programowania, ale sposób, w jaki są one używane i łączone w wierszu poleceń, wydaje mi się bardziej podobny do programowania funkcjonalnego, gdzie każdy program jest izolowana funkcja, która nie zależy od stanu jakiegokolwiek innego programu, do którego mogłaby zostać dołączona.

Czy to dokładne zrozumienie filozofii programowania UNIX to zasadniczo funkcjonalne programowanie przy użyciu narzędzi, które mogły zostać zbudowane przy użyciu imperatywnego stylu programowania?

Myślę, że masz rację tam, ale cp, rm, cdi wiele innych, zmiana stanu, więc nie są one naprawdę funkcjonuje. Filozofia UNIX polega bardziej na robieniu tylko jednej rzeczy, ale robieniu tego dobrze; często robienie tego dobrze oznacza umożliwienie użycia funkcjonalnego, ale nie zawsze.

Odpowiedź znajduje się w „Monadycznym programowaniu powłoki we / wy i UNIX” autorstwa Olega Kiselyova.

To esej zainspirowany pracą Philipa Wadlera „How to Declam an Imperative” [ Wadler97 ]. Pokażemy niesamowite podobieństwa między monadycznymi wejściami i wyjściami w Haskell, a kompozycjami filtrów UNIX opartych na potokach i przekierowaniach. Potoki UNIX (traktowane semantycznie jako zapis do plików tymczasowych) są dość podobne do monad. Ponadto na poziomie programowania UNIX wszystkie wejścia / wyjścia można uznać za monadyczne ...

Myślę, że możesz spojrzeć na to w ten sposób, jeśli zignorujesz cały problem efektów ubocznych. Polecenia uniksowe często NIE działają funkcjonalnie w odniesieniu do zawsze zwracającego ten sam zestaw danych z tymi samymi danymi wejściowymi. Jednak, jak wspomniałeś, aspekt pipingu jest podobny do programowania funkcjonalnego.

Do pewnego stopnia możesz to powiedzieć. Ale to niekoniecznie prawda. Myślę, że powinieneś przeczytać to bardziej jako „zdolność do osiągnięcia więcej” przy uproszczonym podejściu do projektowania. Aby być prostym, musisz podzielić zadanie na łatwo zrozumiałe i łatwe w montażu części. Szczerze mówiąc, filozofię systemu UNIX można wyjaśnić za pomocą następującego przykładu.

Całe programowanie to pewnego rodzaju manipulacja danymi! W niektórych przypadkach programowanie jest również samą manipulacją programem (programowanie Meta). Obecnie działa filozofia UNIX: wyobraź sobie przetwarzanie tekstu. Co to jest tekst? W końcu tekst jest jakimś rodzajem danych. Po złożeniu w uporządkowaną definicję tekst staje się również plikiem XML i JSON. Tekst może być również listą liczb, Tekst może być również plikiem csv, tsv i co nie! W innym tekście lub ciągu może reprezentować naprawdę ogromny obszar danych programowych, tylko dlatego, że jego kontekst może się zmienić i zmienić w to, czego chcemy!

Całe programowanie wymaga pewnego rodzaju organizacji danych. Organizowanie wymaga wyszukiwania ...

za. Tam masz tylko „grep”, „fgrep” i jego rodzinę, aby to zrobić.

Po wyszukaniu musisz wykonać sortowanie ...

b. Teraz mamy do tego polecenie „sortuj”.

Właśnie posortowałeś dwa pliki, teraz chcesz je porównać.

do. Teraz mamy do tego „diff”, „cmp” i in.

Właśnie odkryłeś, że nie ma różnicy między plikami. Potrzebujesz teraz więcej uporządkowanych danych.

re. Masz operatora „cat”, potoki i przekierowania, aby zapisać do pliku.

Potrzebujesz bardziej szczegółowej analizy.

mi. Masz głowę, ogon, więcej, mniej, cięcie i tak dalej, aby to zrobić ...

Wszystko to zszywa się za pomocą „|” aby generować naprawdę potężne rzeczy przez jakiś czas bez pisania kodu. Więcej poszukiwań i szycia masz ...

fa. awk, muszla i sed.

awk, shell i sed dają ci większą kontrolę nad tekstem niż to, co może ci dać cięcie, diff i in. Czy zastanawiałeś się kiedyś nad tym poleceniem1 | polecenie2 | seria Command3 ... jest rodzajem mechanizmu przepływu pracy. W połączeniu z If's staje się to potężniejsze.

Teraz jest więcej zabawy.

Czy kiedykolwiek słyszałeś o narzędziu o nazwie „Perl” , ta rzecz jest tak potężna, że ​​możesz praktycznie wykonać każde zadanie przy tak niewielkiej ilości pracy, jaką można sobie wyobrazić. W połączeniu z narzędziem takim jak DBM możesz spełnić nawet niewielkie wymagania dotyczące trwałości aplikacji. Pamiętaj, że nawet nie wyszliśmy ze świata tekstów, ale udało nam się objąć większość aspektów środowiska programistycznego.

Myślę więc, że UNIX to coś więcej niż system operacyjny. Jest to zbiór narzędzi i środowiska zaprojektowanych w celu rozwiązania problemów w najprostszy sposób. Prosty sposób niekoniecznie oznacza prostotę implementacji rozwiązania. Ale sama prostota nie zaprowadzi cię daleko.

Przeczytałem to gdzieś na reddicie.

„Jeśli Twoim jedynym celem projektowym jest prostota, zyskasz tyle użytkowników, ile Plan9”

Sposób, w jaki są one łączone w wierszu poleceń i współdziałają ze sobą, jest bardzo funkcjonalny. Powiedziałbym jednak, że ma to więcej wspólnego z konstrukcją powłoki, a mniej z tym, czy te programy bazowe są napisane imperatywnie czy funkcjonalnie. Większość dobrych języków funkcjonalnych obsługuje koncepcje imperatywne / proceduralne, nawet jeśli ich ogólny wygląd nadaje się do programowania funkcjonalnego. Tak, wiele funkcji powłoki UNIX wykorzystuje koncepcje funkcjonalne, ale znowu jest to bardziej spowodowane projektowaniem powłoki niż konkretną implementacją programów bazowych.

Mam nadzieję że to pomoże,

-tjw