유닉스 철학에서의 프로그래밍은 기능적 프로그래밍과 동일합니까?


30

UNIX 프로그래밍 환경 (일반 텍스트)에 따르면 프로그래밍에 대한 UNIX 접근 방식은보다 복잡한 문제를 해결하기 위해 결합 할 수있는 작고 정의 된 도구를 작성하는 것입니다. C와 Bash 셸을 배우면서 이것은 광범위한 프로그래밍 문제를 처리하는 데 사용할 수있는 강력한 개념이라는 것을 알았습니다.

Linux 플랫폼을 사용하는 것만으로도 개념이 명확하고 항상 사용됩니다. ls, grep 등과 같은 시스템 도구를 연결하는 등 I / O를 재지 정하는 명령 행에서 작성된 모든 표현은이 개념이 얼마나 강력한지를 보여줍니다.

나를 혼란스럽게하는 것은 이러한 프로그램 중 많은 것들이 명령형 / 절차 적 프로그래밍 스타일을 사용하여 C로 작성되었지만 명령 줄에서 사용 및 결합 된 방식은 기능 프로그래밍과 비슷해 보입니다. 각 프로그램은 다른 프로그램의 상태에 의존하지 않는 분리 된 함수

UNIX 프로그래밍 철학을 이해하는 것이 정확합니까, 기본적으로 명령형 프로그래밍 스타일을 사용하여 작성된 도구를 사용한 기능적 프로그래밍입니까?


5
나는 그 비유가 정확한지 아닌지는 중요하지 않다고 생각합니다. 문제는 당신에게 유용한 비유입니까? 그러한 용어로 생각하면 프로그램을 작성하고 작업을 수행하는 데 도움이됩니까?

답변:


19

난 당신이 거기에 지점을 가지고 있다고 생각하지만 cp, rm, cd그들은 정말 기능되지 않도록 다른 사람과 많은 상태를 변경합니다. 유닉스 철학은 한 가지 일만하는 것이 아니라 잘하는 일에 관한 것입니다. 종종 잘하는 것은 기능적 사용을 허용하는 것을 의미하지만 항상 그런 것은 아닙니다.


9

대답은 Oleg Kiselyov 의 "Monadic i / o 및 UNIX 쉘 프로그래밍" 에 있습니다.

필립와 들러 (Philip Wadler)의 논문 "명령을 선언하는 방법"[ Wadler97 ] 에서 영감을 얻은 에세이 입니다. Haskell의 monadic i / o와 파이프 및 방향 재 지정을 기반으로하는 UNIX 필터 컴포지션 간의 유사하지 않은 유사성을 보여줍니다. UNIX 파이프 (임시 파일에 쓰는 것으로 의미 적으로 처리됨)는 모나드와 매우 유사합니다. 또한 UNIX 프로그래밍 수준에서 모든 I / O는 모나 딕으로 간주 될 수 있습니다.


6

글쎄, 전체 부작용 문제를 무시하면 그런 식으로 볼 수 있다고 생각합니다. 유닉스 명령은 종종 같은 입력으로 항상 같은 데이터 세트를 반환하는 것과 관련하여 기능하지 않습니다. 그러나 언급했듯이 배관 측면은 기능적 프로그래밍을 수행하는 방법과 유사합니다.


1
비행기가 정말 있니? ;) (
주제

@BlackBear 내 자신의 개인이 아닙니다. 저는 우리 중 약 50 명이 공동으로 4 대의 비행기를 소유하고있는 클럽에 있습니다. 그런 식으로 조금 더 저렴합니다. :-)
Brian Knoblauch

@Brian Knoblauch : 미래에 비행기를 갖고 싶습니다 .. 돈 허용 : P
BlackBear

5
함수형 프로그래밍은 "부작용 없음"을 의미하지 않습니다. 동일한 기능이 항상 동일한 결과를 생성하는 개념을 "등전위 (idempotence)"라고하며 프로그램이 작동하는 데 필요한 조건은 아닙니다. "순수 기능"이라고도합니다.

2

어느 정도까지는 말할 수 있습니다. 그러나 반드시 그런 것은 아닙니다. 단순한 디자인 접근 방식으로 더 많은 것을 달성 할 수있는 능력으로 더 읽어야한다고 생각합니다. 그리고 간단하기 위해서는 작업을 쉽게 이해할 수 있고 조립하기 쉬운 부분으로 나눠야합니다. 솔직한 유닉스 철학은 다음 예제에서 설명 할 수 있습니다.

모든 프로그래밍은 일종의 데이터 조작입니다! 어떤 경우에는 프로그래밍도 프로그램 조작 자체 (메타 프로그래밍)입니다. 이제 UNIX 철학이 작동하는 방식은 텍스트 처리를 상상해보십시오. 텍스트 란 무엇입니까? 텍스트는 결국 일종의 데이터입니다. 체계적인 정의로 어셈블 할 때 텍스트도 XML과 JSON이됩니다. 텍스트는 숫자의 목록이 될 수 있으며 텍스트는 csv, tsv 및 기타가 될 수 있습니다! 다른 텍스트 나 문자열은 문맥이 뒤틀리고 우리가 원하는 것으로 바뀔 수 있기 때문에 프로그래밍 데이터의 실제 영역을 나타낼 수 있습니다!

모든 프로그래밍에는 일종의 데이터 구성이 필요합니다. 구성하려면 검색이 필요합니다 ...

에이. 거기에 'grep', 'fgrep'및 그 가족이 있습니다.

일단 검색하면 정렬이 필요합니다 ..

비. 이제 우리는 '정렬'명령을 내 렸습니다.

방금 두 파일을 정렬했습니다. 이제 파일을 비교하려고합니다.

기음. 이제 'diff', 'cmp'등이 있습니다.

방금 파일간에 차이가 없음을 발견했습니다. 이제보다 체계적인 데이터가 필요합니다.

디. 파일에 쓸 'cat', 파이프 및 리디렉션 연산자가 있습니다.

보다 구체적인 구문 분석이 필요합니다.

이자형. 당신은 머리, 꼬리, 더 많이, 덜, 잘라 등을 가지고 있습니다 ...

이 모든 것은 '|' 코드를 전혀 쓰지 않고 실제로 강력한 물건을 생성합니다. 더 많은 검색과 봉제를 위해 ..

에프. awk, shell 및 sed.

awk, shell 및 sed는 잘라 내기보다 텍스트를 더 잘 제어 할 수있게합니다. 당신은 그 command1 궁금해 | command2 | command3 ... series는 일종의 워크 플로 메커니즘입니다. If와 결합하면 더욱 강력 해집니다.

이제 더 재미있게옵니다.

'Perl' 이라는 유틸리티에 대해 들어 본 적이 있습니까? 이 작업은 상상력이 거의없는 거의 모든 작업을 사실상 수행 할 수있는 강력한 기능입니다. DBM과 같은 유틸리티와 함께 ​​사용하면 애플리케이션에 대한 작은 시간 지속성 요구도 수행 할 수 있습니다. 우리는 텍스트 세계를 벗어나지 않았지만 프로그래밍 환경의 대부분을 다루었습니다.

그래서 유닉스는 단순한 운영체제가 아니라고 생각합니다. 가장 간단한 방법으로 문제를 해결하도록 설계된 도구 및 환경 모음입니다. 간단한 방법이 솔루션 구현의 단순성을 의미하지는 않습니다. 그러나 단순성 자체는 그리 멀지 않습니다.

나는 레딧에서 이것을 읽었습니다.

"유일한 설계 목표가 단순하다면 Plan9만큼 많은 사용자를 확보 할 수 있습니다."


1

명령 줄에서 서로 연결되고 상호 작용하는 방식은 매우 기능적입니다. 그러나 이것은 쉘 디자인과 더 관련이 있으며 기본 프로그램이 명령형 또는 기능적으로 작성되는지 여부와는 관련이 없다고 말하고 싶습니다. 대부분의 우수한 기능적 언어는 전체 디자인이 기능적 프로그래밍에 적합하더라도 명령형 / 절차 적 개념을 지원합니다. 그렇습니다. 많은 UNIX 셸 기능은 기능적인 개념을 사용하지만 기본 프로그램의 특정 구현보다 셸 디자인으로 인한 것입니다.

이것이 도움이되기를 바랍니다.

-tjw

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.