여기서는 기능적 언어와 내용에 대해 많은 이야기를합니다. 왜 "전통적인"언어를 사용합니까? 그들은 무엇을 더 잘합니까? 그들은 무엇에 더 나쁜가? 이상적인 기능적 프로그래밍 응용 프로그램은 무엇입니까?
답변:
기능적 언어는 명령형 및 객체 지향 언어와 다른 패러다임을 사용합니다. 그들은 부작용없는 기능을 언어의 기본 구성 요소로 사용합니다. 이것은 많은 것들을 가능하게하고 많은 것들을 더 어렵게 만듭니다 (또는 대부분의 경우 사람들이 익숙한 것과 다릅니다).
함수형 프로그래밍의 가장 큰 장점 중 하나는 부작용없는 함수의 실행 순서가 중요하지 않다는 것입니다. 예를 들어, Erlang에서는 매우 투명한 방식으로 동시성을 활성화하는 데 사용됩니다. 함수형 언어의 함수는 수학 함수와 매우 유사하게 동작하므로 함수형 함수로 쉽게 번역 할 수 있습니다. 경우에 따라 코드를 더 읽기 쉽게 만들 수 있습니다.
전통적으로 함수형 프로그래밍의 가장 큰 단점 중 하나는 부작용이 없다는 것입니다. IO없이 유용한 소프트웨어를 작성하는 것은 매우 어렵지만, 기능에 부작용없이 IO를 구현하기는 어렵습니다. 따라서 대부분의 사람들은 단일 입력에서 단일 출력을 계산하는 것보다 기능 프로그래밍을 최대한 활용하지 못했습니다. F # 또는 Scala와 같은 현대 혼합 패러다임 언어에서는 이것이 더 쉽습니다.
많은 현대 언어에는 기능적 프로그래밍 언어의 요소가 있습니다. C # 3.0에는 많은 함수형 프로그래밍 기능이 있으며 Python에서도 함수형 프로그래밍을 수행 할 수 있습니다. 함수형 프로그래밍의 인기 이유는 대부분 두 가지 이유 때문이라고 생각합니다. 동시성 (concurrency)은 점점 더 많은 멀티 프로세서 컴퓨터를 사용하기 때문에 일반 프로그래밍에서 실제 문제가되고 있습니다. 언어에 대한 접근성이 높아지고 있습니다.
나는 약 40 년 동안 (프로그래밍 스타일로) 사용되어 왔기 때문에 "캐치 온"프로그래밍에 대한 기능적 접근 방식에 대해서는 의문이 없다고 생각합니다. OO 프로그래머가 변경 불가능한 객체를 선호하는 깨끗한 코드를 작성할 때마다 해당 코드는 기능적인 개념을 차용합니다.
그러나 기능적 스타일 을 적용 하는 언어는 요즘 많은 가상 잉크를 사용하고 있으며 앞으로 이러한 언어가 지배적 일지 여부는 명백한 질문입니다. 내 자신의 의심은 스칼라 나 오캄 과 같은 하이브리드, 다중 패러다임 언어 가 순수한 OO 언어 (Smalltalk, Beta 등)가 주류 프로그래밍에 영향을 주었지만 끝나지 않은 것과 같은 방식으로 "순수한"기능 언어를 능가 할 가능성이 높다는 것이다 가장 널리 사용되는 표기법으로
마지막으로, 나는 FP에 대한 귀하의 의견이 몇 년 전과는 다른 절차 적 프로그래머로부터 들었던 의견과 매우 유사하다는 점을 지적 할 수 없습니다.
그래픽 사용자 인터페이스와 "비즈니스 모델로서의 코드"가 OO를보다 널리 인식하는 데 도움이되는 개념 인 것처럼, 불변성과 더 단순한 (대규모) 병렬 처리의 사용 증가는 더 많은 프로그래머가 기능적 접근 방식이 제공하는 이점을 보는 데 도움이 될 것이라고 생각합니다 . 그러나 지난 50 년 동안 디지털 컴퓨터 프로그래밍의 전체 역사를 구성하는 많은 것들을 배운만큼 여전히 배울 것이 많다고 생각합니다. 20 년이 지난 지금 프로그래머들은 현재 인기있는 OO 및 FP 언어를 포함 하여 현재 사용하고있는 도구의 기본 특성에 놀랄 것입니다.
저에게있어 가장 큰 장점은 고유 병렬 처리입니다. 특히 우리는 더 많은 MHz에서 멀어지고 점점 더 많은 코어로 이동하고 있습니다.
나는 그것이 다음 프로그래밍 패러다임이 될 것이라고 생각하지 않으며 OO 유형 메소드를 완전히 대체 할 것이라고 생각하지만 기능적 언어로 코드를 작성해야하거나 범용 언어는 더 기능적인 구성을 포함하도록 성장하십시오.
함수형 언어로 전문적으로 작업하지 않아도 함수형 프로그래밍을 이해하면 더 나은 개발자가 될 수 있습니다. 일반적으로 코드와 프로그래밍에 대한 새로운 관점을 제공합니다.
나는 그것을 배울 이유가 없다고 말합니다.
기능적 스타일과 명령형 스타일을 잘 혼합 한 언어가 가장 흥미롭고 성공할 가능성이 높다고 생각합니다.
나는 항상 다음 큰 것에 대해 회의적입니다. 많은 경우 Next Big Thing은 기술의 유무에 관계없이 적시에 적절한 장소에 존재하는 순수한 역사의 사고입니다. 예 : C ++, Tcl / Tk, Perl. 모든 결함이있는 기술은 모두 오늘날의 문제를 해결하거나 확고한 표준과 거의 동일하거나 둘 다에 대해 인식 되었기 때문에 크게 성공했습니다. 함수형 프로그래밍은 실제로 훌륭 할 수 있지만 이것이 채택 될 것을 의미하지는 않습니다.
하지만 난 수 의 사람들이 왜 당신에게 흥분 함수형 프로그래밍에 대해 . 많은 프로그래머들이 함수형 언어를 사용하면 생산하는 동안 두 배의 생산성 (또는 아마도 10 배의 생산성)을 얻는 일종의 "변환 경험"을 경험했습니다. 변경하기에 더 탄력적이고 버그가 적은 코드. 이 사람들은 기능 프로그래밍을 비밀 무기로 생각합니다. 이 사고 방식의 좋은 예는 Paul Graham의 평균을 치는 것입니다. 입니다. 아, 그리고 그의 신청? 전자 상거래 웹 앱.
2006 년 초 이래로 함수형 프로그래밍과 병렬 처리에 대한 논쟁이있었습니다. 사람들이 좋아하기 때문에Simon Peyton Jones 은 적어도 1984 년 이후로 병렬 처리에 대해 걱정하고 있기 때문에 기능적 언어가 멀티 코어 문제를 해결할 때까지 숨을 쉬지 않습니다. 그러나 지금은 몇 가지 추가 버즈에 대해 설명합니다.
일반적으로 미국 대학은 기능 프로그래밍을 가르치는 일을 잘 못하고 있습니다. Scheme을 사용한 인트로 프로그래밍 교육에 대한 강력한 지원이 있으며 Haskell도 그에 대한 지원을 받고 있지만 기능 프로그래머를위한 고급 기술을 가르치는 방법은 거의 없습니다. 저는 하버드에서 그러한 과정을 가르쳤으며 올 봄 터프 츠에서 다시 할 것입니다. Benjamin Pierce는 Penn에서 그러한 과정을 가르쳤습니다. 폴 휴닥이 예일에서 무슨 짓을했는지 모르겠습니다. 유럽의 대학들은 훨씬 더 나은 일을하고 있습니다. 예를 들어 덴마크, 네덜란드, 스웨덴 및 영국의 중요한 장소에서는 기능 프로그래밍이 강조됩니다. 나는 호주에서 무슨 일이 일어나고 있는지에 대한 감각이 적습니다.
나는 여기 방에서 코끼리를 언급하는 사람을 보지 못하므로 그것이 나에게 달려 있다고 생각합니다. :)
JavaScript는 기능적인 언어입니다. 점점 더 많은 사람들이 jQuery, Dojo 및 기타 프레임 워크의 미세한 지점을 활용하여 JS로 더 발전된 작업을 수행함에 따라 FP는 웹 개발자의 백도어에 의해 도입 될 것입니다.
클로저와 함께 FP는 JS 코드를 실제로 가벼우면서도 읽을 수있게 만듭니다.
건배, PS
대부분의 응용 프로그램은 일반적인 OO 방식으로 해결할 수있을 정도로 간단합니다.
OO 방식이 항상 "정상적인"것은 아닙니다. 이 10 년 표준은 지난 10 년간 소외된 개념이었습니다.
함수형 프로그래밍은 수학입니다. Lisp의 Paul Graham ( Lisp의 대체 기능 프로그래밍) :
따라서이 1950 년대 언어가 왜 구식이 아닌지에 대한 간단한 설명은 기술이 아니라 수학이며 수학이 부실하지 않다는 것입니다. Lisp를 비교하는 올바른 방법은 1950 년대 하드웨어가 아니라 1960 년에 발견 된 Quicksort 알고리즘인데, 여전히 가장 빠른 범용 정렬입니다.
나는 당신이 사용할 때 함수형 프로그래밍인지 몰랐다.
평범한 회사 프로그래머, 예를 들어 내가 일하는 대부분의 사람들은 그것을 이해하지 못하고 대부분의 작업 환경에서 프로그래밍을 할 수 없습니다
그래도 시간 문제 일뿐입니다. 평범한 기업 프로그래머는 현재 Big Thing이 무엇이든 학습합니다. 15 년 전에는 OOP를 이해하지 못했습니다. IF FP는 "평균 기업의 프로그래머는"따를에 잡는다.
그것은 실제로 대학에서 가르치지 않습니다 (또는 요즘입니까?)
많이 다릅니다. 우리 대학에서 SML은 학생들이 처음 접하는 언어입니다. 저는 MIT가 LISP를 1 년 과정으로 가르치고 있다고 생각합니다. 물론이 두 가지 사례는 대표적 일 수는 없지만 대부분의 대학은 교육 과정의 필수 부분이 아니더라도 FP에 대한 일부 선택 과목을 제공한다고 생각합니다.
대부분의 응용 프로그램은 일반적인 OO 방식으로 해결할 수있을 정도로 간단합니다.
그래도 "간단한"문제는 아닙니다. 해결책이 더 간단할까요?FP에서 하거나 읽기 쉽고 강력하고 우아하며 성능이 좋을까요? 많은 것들이 "자바로 풀기에 충분히 간단하다"지만 여전히 엄청난 양의 코드가 필요하다.
어쨌든 FP 지지자들은 그것이 수십 년 동안 그 다음 큰 일이라고 주장했다는 것을 명심하십시오. 아마도 그들이 옳을 지 모르지만 5, 10 또는 15 년 전에 같은 주장을 할 때가 아니라는 것을 명심하십시오.
하지만 C #이 최근에 프로그래머를 눈에 띄지 않고 실제로 FP 프로그래머로 전환하는 정도까지 FP를 향해 급격한 변화를 겪었다는 점에서 분명히 유리 합니다 . 그것은 FP "혁명"을위한 길을 열어 줄 것입니다. 아마도. ;)
사람이 다른 예술의 가치를 볼 수 없다면, 자신이 선택한 예술의 완벽과 불완전 성을 이해할 수 없습니다. 규칙을 준수하면 기술의 특정 지점까지만 개발할 수 있으며 학생과 아티스트는 더 많은 것을 배우고 더 추구해야합니다. 전략뿐만 아니라 다른 예술도 공부하는 것이 합리적입니다.
다른 사람의 활동을보고 자신에 대해 더 배우지 않은 사람은 누구입니까? 칼을 배우려면 기타를 연구하십시오. 주먹 연구 상거래를 배우기 위해. 칼을 연구하는 것만으로도 마음이 좁아지고 바깥으로 자라지 못하게됩니다.
-미야모토 무사시, "5 개의 반지의 책"
기능적 언어의 주요 기능 중 하나는 일류 기능의 개념입니다. 아이디어는 함수를 다른 함수에 매개 변수로 전달하여 값으로 리턴 할 수 있다는 것입니다.
함수형 프로그래밍에는 상태를 변경하지 않는 코드 작성이 포함됩니다. 이렇게하는 주된 이유는 함수를 연속적으로 호출하면 같은 결과를 얻을 수 있기 때문입니다. 일급 함수를 지원하는 모든 언어로 기능 코드를 작성할 수 있지만 Haskell과 같은 일부 언어는 상태를 변경할 수 없습니다. 실제로, 텍스트 인쇄와 같은 부작용은 전혀 없어야합니다. 완전히 쓸모없는 것처럼 들립니다.
Haskell은 IO에 대한 다른 접근 방식 인 모나드를 사용합니다. 인터프리터의 최상위 레벨에서 실행할 원하는 IO 작업이 포함 된 객체입니다. 다른 수준에서는 시스템의 객체 일뿐입니다.
기능적 프로그래밍은 어떤 이점을 제공합니까? 함수형 프로그래밍은 각 구성 요소가 완전히 분리되어 있기 때문에 버그 발생 가능성이 적은 코딩이 가능합니다. 또한 재귀 및 일류 함수를 사용하면 일반적으로 코드 구조를 반영하는 간단한 정확성 증명이 가능합니다.
대부분의 현실적인 사람들은 함수형 프로그래밍이 따라 잡을 것이라고 생각하지 않습니다 (OO와 같은 주요 패러다임이 됨). 결국 대부분의 비즈니스 문제는 수학 문제가 아니라 데이터를 이동하고 다양한 방식으로 표시하는 털이 많은 규칙입니다. 따라서 순수한 기능 프로그래밍 패러다임에 적합하지 않습니다 (모나드의 학습 곡선이 OO를 훨씬 초과 함).
OTOH, 함수형 프로그래밍은 프로그래밍을 즐겁게 만듭니다. 그것은 우주의 기초 수학의 간결한 표현의 본질적이고 영원한 아름다움을 높이 평가합니다. 사람들은 함수형 프로그래밍을 배우면 더 나은 프로그래머가 될 것이라고 말합니다. 이것은 물론 매우 주관적입니다. 나는 개인적으로 그것이 완전히 사실이라고 생각하지 않습니다.
그것은 당신에게 더 나은 지각력을줍니다.
나는 조밀해야하지만 여전히 얻지 못합니다. F #과 같은 기능적 언어로 작성된 작은 앱의 실제 예제가 있습니까? 여기서 소스 코드를보고 C #보다 그러한 접근 방식을 사용하는 것이 어떻게, 왜 더 나은지 알 수 있습니까?
함수형 언어에 대해 말한 모든 것, 대부분의 사람들은 약 20 년 전에 객체 지향 언어에 대해 말하고있었습니다. 당시에는 OO에 대해 듣는 것이 매우 일반적이었습니다.
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
어딘가에서 변화가 이루어져야합니다. 의미 있고 중요한 변화는 초기 기술 훈련을받은 사람들이 변화가 필요하지 않다는 의견을 가지고 있는지 여부에 관계없이 발생합니다. 당시에 반대했던 모든 사람들에도 불구하고 OO 로의 변경이 좋았다고 생각하십니까?
Microsoft가 추진하고 있기 때문에 F #은 따라 잡을 수 있습니다.
찬성:
대조 :
그래서 저는 F #에게 50:50의 기회를주었습니다. 다른 기능적 언어는 가까운 장래에 그것을 만들지 않을 것입니다.
한 가지 이유는 어떤 사람들은 언어를 받아 들일 것인지의 가장 중요한 부분이 언어가 얼마나 좋은지 생각한다고 생각하기 때문 입니다 . 불행히도 상황이 그렇게 간단하지는 않습니다. 예를 들어, 나는 (즉하지만 파이썬의 수용 뒤에 가장 큰 요인은 언어 자체 아니라고 주장 이다 매우 중요합니다). 파이썬이 인기있는 가장 큰 이유는 거대한 표준 라이브러리와 더 큰 타사 라이브러리 커뮤니티입니다.
Clojure 또는 F #과 같은 언어는 JVM / CLR을 기반으로한다는 점을 고려할 때 예외가 될 수 있습니다. 결과적으로 나는 그들에 대한 대답이 없습니다.
학부 시절 Lisp 또는 Scheme을 배우지 않은 사람들이 지금 그것을 발견하고있는 것 같습니다. 이 분야의 많은 것들과 마찬가지로 과대 기대와 높은 기대를 만드는 경향이 있습니다 ...
통과 할 것이다.
함수형 프로그래밍은 훌륭합니다. 그러나 세계를 인수하지는 않습니다. C, C ++, Java, C # 등은 계속 남아 있습니다.
이 기능은 기능 언어로 사물을 구현 한 다음 다른 언어로 그 사물에 액세스하는 등 언어 간 능력이 더 중요하다고 생각합니다.
에픽 게임스 팀 스위니 (Epic Games)의 "다음 주류 프로그래밍 언어 : 게임 개발자의 관점"을 읽을 때, 나의 첫 생각은-Haskell을 배우게되었습니다.
최근 프로그래밍 언어의 진화를 따르고 있습니까? 모든 주류 프로그래밍 언어의 모든 새로운 릴리스는 함수형 프로그래밍에서 점점 더 많은 기능을 빌리는 것 같습니다.
클로저, 익명 함수, 전달 및 반환 함수는 Lisp 및 ML 해커에게만 알려진 이국적인 기능이었습니다. 그러나 점차 C #, Delphi, Python, Perl, Javascript는 클로저에 대한 지원을 추가했습니다. 다가오는 언어를 폐쇄하지 않고 진지하게 받아 들일 수는 없습니다.
Python, C # 및 Ruby와 같은 여러 언어는 목록 이해 및 목록 생성기를 기본적으로 지원합니다.
ML은 1973 년에 제네릭 프로그래밍을 개척했지만 제네릭 ( "파라 메트릭 다형성")에 대한 지원은 지난 5 년 동안 업계 표준이되었습니다. 올바르게 기억한다면 Fortran은 2003 년에 제네릭을 지원했고, Java 2004, 2005 년에 C #, 2008 년에 Delphi를 지원했습니다. (C ++은 1979 년부터 템플릿을 지원했지만 C ++의 STL에 대한 토론의 90 %는 "여기에는 악마가 있습니다" .)
이러한 기능이 프로그래머에게 매력적인 이유는 무엇입니까? 그것은 분명 명백해야한다 : 그것은 프로그래머가 짧은 코드를 작성하는 데 도움이 . 앞으로 모든 언어는 경쟁력을 유지하려는 경우 최소한 폐쇄를 지원할 것입니다. 이와 관련하여 기능 프로그래밍은 이미 주류에 있습니다.
대부분의 응용 프로그램은 일반적인 OO 방식으로 해결할 수있을 정도로 간단합니다.
간단한 것에는 함수형 프로그래밍을 사용할 수 없다고 누가 말합니까? 모든 기능 프로그램이 컴파일러, 정리 증명 자 또는 대규모 병렬 통신 스위치 일 필요는 없습니다. 나는 더 복잡한 프로젝트 외에 임시 스크립트를 위해 정기적으로 F #을 사용합니다.
복잡성을 제어하는 데 가장 적합한 도구이기 때문에 따라 잡고 있습니다. 참조 :
-Simon Peyton-Jones의 슬라이드 109-116에서 "Hastell의 맛"
- "다음 주류 프로그래밍 언어 : 게임 개발자의 관점", Tim Sweeney
체크 아웃 왜 함수형 프로그래밍 사항
첫 번째 요점에 동의하지만 시간이 바뀝니다. 기업은 채택자가 늦어도 이점이 있다고 판단되면 이에 대응할 것입니다. 인생은 역동적입니다.
그들은 90 년대 후반 스탠포드에서 하스켈과 ML을 가르치고있었습니다. Carnegie Mellon, MIT, Stanford 및 기타 좋은 학교와 같은 곳에서 학생들에게 제공하고 있습니다.
나는 대부분의 "웹에 관계형 데이터베이스 노출"앱이 오랫동안 그 맥락에서 계속 될 것이라는 데 동의합니다. Java EE, .NET, RoR 및 PHP는이 문제에 대한 훌륭한 솔루션을 발전 시켰습니다.
중요한 것을 발견했습니다. 기능 프로그래밍을 향상시키는 다른 방법으로는 쉽게 해결할 수없는 문제 일 수 있습니다. 그게 뭐야?
대규모 멀티 코어 하드웨어 및 클라우드 컴퓨팅이이를 지원할까요?
FP는 생산성, 안정성 및 유지 관리 측면에서 상당한 이점을 갖습니다. 많은 코어는 많은 양의 레거시 코드에도 불구하고 대기업이 마침내 전환하게하는 킬러 앱일 수도 있습니다. 동시성 및 병렬 처리에 적합하지 않습니다.
나는 "정상적인"프로그래머들이 그것을 이해하지 못한다는 것에 동의하지 않습니다. 그들은 결국 OOP를 이해하는 것처럼 (이상하지는 않지만 신비 롭고 이상합니다).
또한 대부분의 대학은 FP를 가르치고 있으며, 많은 사람들이 FP를 첫 번째 프로그래밍 과정으로 가르칩니다.
나는 그것이 붙잡을 지 모르겠지만, 내 조사에서 기능적 언어는 거의 확실히 배울 가치가 있으며, 더 나은 프로그래머가 될 것입니다. 참조 투명성을 이해하는 것만으로도 많은 디자인 결정이 훨씬 쉬워지고 결과 프로그램이 추론하기가 훨씬 쉬워집니다. 기본적으로 문제가 발생하면 수백 가지 클래스 / 메소드 / 함수 중 하나로 인해 발생할 수있는 불일치 상태의 문제가 아닌 단일 함수의 출력에만 문제가되는 경향이 있습니다. 부작용이있는 비대칭 언어로.
FP의 Stateless 특성은 웹의 Stateless 특성에보다 자연스럽게 매핑되므로 기능적 언어는보다 우아하고 편안한 웹앱에보다 쉽게 적합합니다. VIEWSTATE 및 SESSION 키와 같이 엄청나게 추악한 HACKS를 사용하여 애플리케이션 상태를 유지하고 웹과 같이 기본적으로 상태가없는 기능적 플랫폼에서 상태 기반 명령 언어의 (종종 누출이 많은) 추상화를 유지해야하는 JAVA 및 .NET 프레임 워크와 대조하십시오.
또한 상태 비 저장 응용 프로그램이 많을수록 병렬 처리에 더 쉽게 빌려줄 수 있습니다. 귀하의 웹 사이트가 인기를 얻는 경우 웹에 매우 중요합니다. 더 나은 성능을 얻기 위해 사이트에 더 많은 하드웨어를 추가하는 것이 항상 쉬운 것은 아닙니다.