왜 함수형 언어인가?[닫은]

https://stackoverflow.com/questions/36504

09-06-2019
|

문제

나는 여기서 함수형 언어와 관련된 많은 이야기를 봅니다.왜 "전통적인" 언어 대신에 이를 사용하겠습니까?그들은 무엇을 더 잘합니까?그들이 더 나쁜 것은 무엇입니까?이상적인 함수형 프로그래밍 애플리케이션은 무엇입니까?

해결책

기능적 언어는 명령형 및 객체 지향 언어와는 다른 패러다임을 사용합니다.그들은 부작용이 없는 기능을 언어의 기본 구성 요소로 사용합니다.이는 많은 일을 가능하게 하고 많은 일을 더 어렵게 만듭니다(대부분의 경우 사람들이 익숙했던 것과는 다릅니다).

함수형 프로그래밍의 가장 큰 장점 중 하나는 부작용이 없는 함수의 실행 순서가 중요하지 않다는 것입니다.예를 들어 Erlang에서는 매우 투명한 방식으로 동시성을 활성화하는 데 사용됩니다.그리고 함수형 언어의 함수는 수학적 함수와 매우 유사하게 동작하기 때문에 이를 함수형 언어로 쉽게 번역할 수 있습니다.어떤 경우에는 이렇게 하면 코드를 더 읽기 쉽게 만들 수 있습니다.

전통적으로 함수형 프로그래밍의 가장 큰 단점 중 하나는 부작용이 없다는 점이었습니다.IO 없이 유용한 소프트웨어를 작성하는 것은 매우 어렵지만, IO는 기능상의 부작용 없이 구현하기 어렵습니다.따라서 대부분의 사람들은 단일 입력에서 단일 출력을 계산하는 것보다 함수형 프로그래밍에서 더 많은 것을 얻지 못했습니다.F# 또는 Scala와 같은 최신 혼합 패러다임 언어에서는 이것이 더 쉽습니다.

많은 현대 언어에는 함수형 프로그래밍 언어의 요소가 포함되어 있습니다.C# 3.0에는 많은 함수형 프로그래밍 기능이 있으며 Python에서도 함수형 프로그래밍을 수행할 수 있습니다.함수형 프로그래밍이 인기를 얻은 이유는 주로 다음 두 가지 이유 때문이라고 생각합니다.동시성은 점점 더 많은 다중 프로세서 컴퓨터를 사용하고 있기 때문에 일반 프로그래밍에서 실질적인 문제가 되고 있습니다.언어에 대한 접근성이 점점 더 높아지고 있습니다.

다른 팁

프로그래밍 "잡기"에 대한 기능적 접근 방식에 대해서는 의문의 여지가 없다고 생각합니다. 프로그래밍 스타일로 약 40년 동안 사용되어 왔기 때문입니다.OO 프로그래머가 불변 객체를 선호하는 깔끔한 코드를 작성할 때마다 해당 코드는 기능적 개념을 차용하고 있습니다.

그러나 해당 언어는 억지로 시키다 기능적 스타일은 요즘 많은 가상 잉크를 얻고 있으며 이러한 언어가 미래에 지배적이 될 것인지 여부는 공개된 질문입니다.내 자신의 의심은 다음과 같은 하이브리드, 다중 패러다임 언어입니다. 스칼라 또는 OCaml순수한 OO 언어(Smalltalk, Beta 등)가 주류 프로그래밍에 영향을 주었지만 가장 널리 사용되는 표기법으로 끝나지 않은 것과 같은 방식으로 "순수주의" 함수형 언어를 지배할 가능성이 높습니다.

마지막으로, FP에 대한 귀하의 의견이 몇 년 전 절차적 프로그래머로부터 들었던 의견과 매우 유사하다는 점을 지적하지 않을 수 없습니다.

(신화적인, IMHO) "보통" 프로그래머는 그것을 이해하지 못합니다.
널리 가르쳐지지는 않습니다.
이를 사용하여 작성할 수 있는 모든 프로그램은 현재 기술을 사용하여 다른 방식으로 작성할 수 있습니다.

그래픽 사용자 인터페이스와 "비즈니스 모델로서의 코드"가 OO가 더 널리 인식되는 데 도움이 된 개념인 것처럼, 불변성과 더 간단한(대량) 병렬 처리의 사용 증가는 더 많은 프로그래머가 기능적 접근 방식이 제공하는 이점을 이해하는 데 도움이 될 것이라고 믿습니다. .하지만 우리가 배운 만큼 지난 50여년 동안 디지털 컴퓨터 프로그래밍의 전체 역사를 구성하고 있는 이러한 기술들에 대해 우리는 아직 배워야 할 것이 많다고 생각합니다.지금으로부터 20년 후, 프로그래머들은 우리가 현재 사용하고 있는 도구의 원시적 특성에 놀라서 되돌아보게 될 것입니다. 포함 현재 인기 있는 OO 및 FP 언어.

저에게 가장 큰 장점은 고유한 병렬성입니다. 특히 현재 우리가 더 많은 MHz에서 점점 더 많은 코어로 이동하고 있기 때문에 더욱 그렇습니다.

나는 이것이 차세대 프로그래밍 패러다임이 되어 OO 유형 메서드를 완전히 대체할 것이라고 생각하지 않습니다. 그러나 우리 코드 중 일부를 함수형 언어로 작성해야 하는 지점에 도달할 것이라고 생각합니다. 그렇지 않으면 범용 언어가 그렇게 될 것입니다. 더 많은 기능적 구성을 포함하도록 성장합니다.

함수형 언어를 전문적으로 다루지 않더라도 함수형 프로그래밍을 이해하면 더 나은 개발자가 될 수 있습니다.이는 코드와 프로그래밍 전반에 대한 새로운 관점을 제공할 것입니다.

배우지 않을 이유가 없다고 하더군요.

나는 기능적 스타일과 명령형 스타일을 잘 혼합하는 언어가 가장 흥미롭고 성공할 가능성이 가장 높다고 생각합니다.

나는 항상 Next Big Thing에 대해 회의적입니다.많은 경우 Next Big Thing은 기술이 좋든 나쁘든 상관없이 적시 적소에 존재하는 순전한 우연입니다.예:C++, Tcl/Tk, 펄.결함이 있는 모든 기술은 모두 당시의 문제를 해결하거나 확고한 표준과 거의 동일하거나 둘 다로 인식되었기 때문에 큰 성공을 거두었습니다.함수형 프로그래밍은 실제로 훌륭할 수 있지만 이것이 채택될 것이라는 의미는 아닙니다.

하지만 나는 ~할 수 있다 사람들이 왜 있는지 말해줘 흥분한 함수형 프로그래밍에 대해:아주 많은 프로그래머가 일종의 "변환 경험"을 통해 함수형 언어를 사용하면 생산성이 두 배(또는 어쩌면 10배) 높아지는 동시에 변경에 더 탄력적이고 버그가 적은 코드를 생성할 수 있다는 사실을 발견했습니다.이 사람들은 함수형 프로그래밍을 비밀 무기로 생각합니다.이러한 사고방식의 좋은 예는 Paul Graham의 것입니다. 평균을 이기다.아, 그리고 그의 지원서는요?전자상거래 웹 앱.

2006년 초부터 함수형 프로그래밍과 병렬성에 대한 소문도 나돌았습니다.사람들이 좋아하니까 사이먼 페이튼 존스 나는 적어도 1984년부터 병렬성에 대해 계속해서 걱정해 왔으며, 기능적 언어가 멀티코어 문제를 해결할 때까지 숨을 멈추지 않을 것입니다.그러나 그것은 현재 추가적인 소문 중 일부를 설명합니다.

일반적으로 미국 대학들은 함수형 프로그래밍을 제대로 가르치지 못하고 있습니다.강력한 지원 핵심이 있습니다. Scheme을 이용한 입문 프로그래밍 교육, Haskell도 어느 정도 지원을 받고 있지만 함수형 프로그래머에게 고급 기술을 가르치는 방식은 거의 없습니다.나는 하버드에서 그런 강좌를 가르쳤고 이번 봄에도 터프츠에서 다시 가르칠 예정이다.Benjamin Pierce는 Penn에서 그러한 과정을 가르쳤습니다.Paul Hudak이 Yale에서 어떤 일을 했는지는 모르겠습니다.유럽의 대학들은 훨씬 더 나은 일을 하고 있습니다.예를 들어, 함수형 프로그래밍은 덴마크, 네덜란드, 스웨덴 및 영국의 중요한 곳에서 강조됩니다.나는 호주에서 무슨 일이 일어나고 있는지 잘 알지 못합니다.

여기 방에서는 코끼리에 대해 언급하는 사람이 아무도 없으니 그건 제 몫인 것 같아요 :)

자바스크립트는 함수형 언어입니다.점점 더 많은 사람들이 JS로 고급 작업을 수행함에 따라, 특히 jQuery, Dojo 및 기타 프레임워크의 미세한 점을 활용함에 따라 웹 개발자의 백도어를 통해 FP가 도입될 것입니다.

클로저와 함께 FP는 JS 코드를 정말 가벼우면서도 읽기 쉽게 만듭니다.

건배, ps

대부분의 응용 프로그램은 일반적인 OO 방식으로 해결할 수 있을 만큼 간단합니다.

OO 방식이 항상 "정상적인"것은 아닙니다. 이 10 년의 표준은 지난 10 년간의 소외된 개념이었습니다.
함수형 프로그래밍은 수학입니다. Lisp에 관한 폴 그레이엄 (Lisp를 함수형 프로그래밍으로 대체):

따라서이 1950 년대 언어가 쓸모없는 이유에 대한 짧은 설명은 그것이 기술이 아니라 수학이었고 수학은 부실하지 않다는 것입니다.LISP를 비교하는 것은 1950 년대 하드웨어가 아니라 1960 년에 발견되었으며 여전히 가장 빠른 일반적인 종류입니다.

다음을 사용할 때는 자신이 함수형 프로그래밍이라는 사실을 몰랐을 것입니다.

엑셀 수식
석영 작곡가
자바스크립트
로고(거북이 그래픽)
링크
SQL
alterscore.js (또는 lodash), d3

일반 기업 프로그래머.내가 함께 일하는 대부분의 사람들은 그것을 이해하지 못할 것이며 대부분의 작업 환경에서는 프로그램을 프로그래밍 할 수 없습니다.

하지만 그건 시간문제일 뿐입니다.일반 기업 프로그래머는 현재의 Big Thing이 무엇이든 배웁니다.15년 전에는 OOP를 이해하지 못했습니다.만약에 FP가 따라잡으면 "일반 기업 프로그래머"가 뒤따를 것입니다.

그것은 실제로 대학에서 가르치지 않습니다 (또는 요즘에는?)

많이 다릅니다.우리 대학에서 SML은 학생들이 처음으로 접하게 되는 언어입니다.나는 MIT가 1학년 과정으로 LISP를 가르친다고 생각합니다.물론 이 두 가지 예가 대표적인 것은 아닐 수도 있지만 대부분의 대학에서는 FP를 커리큘럼의 필수 부분으로 만들지는 않더라도 최소한 FP에 대한 일부 선택 과목을 제공한다고 생각합니다.

대부분의 응용 프로그램은 정상적인 OO 방식으로 해결하기에 충분히 간단합니다.

하지만 실제로 "충분히 단순하다"는 문제는 아닙니다.해결책이 될까요 더 간단하다 FP에서 (또는 더 읽기 쉽고, 강력하고, 우아하고, 성능이 좋나요)?많은 것들이 "Java로 해결될 만큼 간단"하지만, 여전히 엄청난 양의 코드가 필요합니다.

어쨌든, FP 지지자들은 이것이 수십 년 동안 Next Big Thing이라고 주장해 왔다는 점을 명심하십시오.아마도 그들이 옳을 수도 있지만, 5년, 10년, 15년 전에 같은 주장을 했을 때는 그렇지 않았다는 점을 명심하십시오.

하지만 확실히 유리한 점 중 하나는 최근 C#이 FP로 급격하게 전환하여 실제로 한 세대의 프로그래머를 FP 프로그래머로 전환하고 있다는 것입니다. 그들도 눈치 채지 못한 채.이는 FP "혁명"의 길을 열어줄 수도 있습니다.아마도.;)

인간이 다른 예술의 가치를 볼 수 없다면 자신이 선택한 예술의 완벽함과 불완전함을 이해할 수 없습니다.규칙을 따르면 기술의 어느 정도까지만 발전할 수 있으며 학생과 예술가는 더 많은 것을 배우고 더 많은 것을 추구해야 합니다.전략 분야뿐만 아니라 다른 분야도 공부하는 것이 좋습니다.

다른 사람의 활동을 관찰함으로써 자신에 대해 더 많은 것을 배우지 못한 사람이 어디 있겠습니까?검을 배우려면 기타를 공부하세요.첫 번째 연구 상업을 배우려면.단지 검을 연구하는 것은 당신을 편협하게 만들고 당신이 외적으로 성장하는 것을 허용하지 않을 것입니다.

-- 미야모토 무사시, '오륜서'

함수형 언어의 주요 특징 중 하나는 일급 함수 개념입니다.아이디어는 함수를 다른 함수에 매개변수로 전달하고 이를 값으로 반환할 수 있다는 것입니다.

함수형 프로그래밍에는 상태를 변경하지 않는 코드 작성이 포함됩니다.그렇게 하는 주된 이유는 함수를 연속적으로 호출하면 동일한 결과가 나오기 때문입니다.일급 함수를 지원하는 어떤 언어로든 함수 코드를 작성할 수 있지만 상태 변경을 허용하지 않는 Haskell과 같은 일부 언어도 있습니다.사실, 부작용(텍스트 인쇄 등)을 전혀 만들어서는 안 됩니다. 이는 전혀 쓸모가 없는 것처럼 들립니다.

대신 Haskell은 IO에 대해 다른 접근 방식을 사용합니다.모나드.이는 인터프리터의 최상위 수준에서 실행하기를 원하는 IO 작업이 포함된 개체입니다.다른 수준에서는 단순히 시스템의 개체일 뿐입니다.

함수형 프로그래밍은 어떤 이점을 제공합니까?함수형 프로그래밍을 사용하면 각 구성 요소가 완전히 격리되므로 버그 가능성이 적은 코딩이 가능합니다.또한 재귀 및 일류 함수를 사용하면 일반적으로 코드 구조를 반영하는 간단한 정확성 증명이 가능합니다.

나는 대부분의 현실적인 사람들이 함수형 프로그래밍이 인기를 끌 것이라고 생각하지 않는다고 생각합니다(OO와 같은 주요 패러다임이 됨).결국, 대부분의 비즈니스 문제는 수학 문제가 아니라 데이터를 이동하고 다양한 방식으로 표시하는 털이 많은 명령형 규칙입니다. 이는 순수 함수형 프로그래밍 패러다임에 적합하지 않음을 의미합니다(모나드의 학습 곡선은 OO를 훨씬 초과합니다).

OTOH, 함수형 프로그래밍은 프로그래밍을 재미있게 만드는 것입니다.우주의 기본 수학을 간결하게 표현한 고유하고 시대를 초월한 아름다움에 감사하게 됩니다.사람들은 함수형 프로그래밍을 배우면 더 나은 프로그래머가 될 수 있다고 말합니다.물론 이는 매우 주관적이다.나는 개인적으로 그것이 완전히 사실이라고 생각하지 않습니다.

그것은 당신을 더 나은 지각 있는 존재로 만듭니다.

나는 밀도가 있어야하지만 여전히 이해하지 못합니다.소스 코드를 보고 C#보다 이러한 접근 방식을 사용하는 것이 어떻게, 왜 더 나은지 확인할 수 있는 F#과 같은 기능적 언어로 작성된 작은 앱의 실제 예가 있습니까?

나는 당신이 기능적 언어에 관해 말한 모든 것, 대부분의 사람들이 약 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로의 변화는 좋았다고 생각하시나요?

F#은 Microsoft가 추진하고 있기 때문에 따라잡을 수 있습니다.

찬성:

F#은 다음 버전의 Visual Studio에 포함될 예정입니다.
Microsoft는 유명 고객과 협력하는 전도사, 서적, 컨설턴트, MS 컨퍼런스에서의 상당한 노출 등 한동안 커뮤니티를 구축하고 있습니다.
F#은 일류 .Net 언어이며 매우 큰 기반을 갖춘 최초의 기능적 언어입니다(Lisp, Haskell, Erlang, Scala, OCaml에 라이브러리가 많지 않고 .Net만큼 완전하지 않다는 뜻은 아닙니다). 이다)
병렬성에 대한 강력한 지원

대조:

F#은 C#과 .Net에 능숙하더라도 시작하기가 매우 어렵습니다. 적어도 저에게는 :(
아마도 좋은 F# 개발자를 찾기 어려울 것입니다.

그래서 저는 F#이 중요해질 기회를 50:50으로 줍니다.다른 기능적 언어는 가까운 미래에 성공하지 못할 것입니다.

제 생각에는 그 이유 중 하나가 어떤 사람들은 언어가 받아들여질지 여부의 가장 중요한 부분이 그 언어가 얼마나 좋은지라고 생각합니다..불행하게도 일이 그렇게 간단한 경우는 거의 없습니다.예를 들어, 나는 Python이 수용된 가장 큰 요인은 언어 자체가 아니라고 주장하고 싶습니다. ~이다 꽤 중요함).Python이 그토록 인기를 끄는 가장 큰 이유는 거대한 표준 라이브러리와 훨씬 더 큰 타사 라이브러리 커뮤니티 때문입니다.

Clojure 또는 F#과 같은 언어는 JVM/CLR을 기반으로 구축되었다는 점을 고려하면 이에 대한 규칙에서 예외일 수 있습니다.결과적으로 나는 그들에 대한 답을 가지고 있지 않습니다.

대부분의 응용 프로그램은 [좋아하는 언어, 패러다임 등을 삽입하십시오.여기].

이는 사실이지만 다양한 도구를 사용하여 다양한 문제를 해결할 수 있습니다.기능적은 올바르게 사용될 때 작업을 보다 효과적으로 수행할 수 있는 또 다른 높은(더 높은?) 수준의 추상화를 허용합니다.

제가 보기에는 학부 때 Lisp나 Scheme을 배운 적이 없는 사람들이 이제 그것을 발견하고 있는 것 같습니다.이 분야의 많은 것들이 그렇듯이 과대광고하고 높은 기대치를 만들어내는 경향이 있습니다...

그것은 지나갈 것이다.

함수형 프로그래밍은 훌륭합니다.그러나 그것이 세상을 장악하지는 못할 것이다.C, C++, Java, C# 등은 여전히 존재합니다.

이를 통해 더 많은 언어 간 능력이 나올 것이라고 생각합니다. 예를 들어 기능적 언어로 구현한 다음 다른 언어로 해당 항목에 대한 액세스를 제공하는 것입니다.

"차세대 주류 프로그래밍 언어:A Game Developer’s Perspective'(Epic Games의 Tim Sweeney 저)에서 제가 처음 생각한 것은 '하스켈을 배워야겠다'였습니다.

피피티

Google의 HTML 버전

한동안 상황은 기능적인 방향으로 움직이고 있었습니다.지난 몇 년간 두 명의 멋진 새 아이들인 Ruby와 Python은 둘 다 이전보다 기능적 언어에 근본적으로 더 가깝습니다. 그래서 일부 Lispers는 둘 중 하나를 "충분히 가깝다"고 지원하기 시작했습니다.

그리고 대규모 병렬 하드웨어가 모든 사람에게 진화적 압력을 가하고 있으며 함수형 언어가 변경 사항을 처리하기에 가장 적합한 위치에 있기 때문에 Haskell이나 F#이 차세대 대세가 될 것이라고 생각했던 것만큼 큰 도약은 아닙니다.

최근 프로그래밍 언어의 발전을 따라오셨나요?모든 주류 프로그래밍 언어의 새로운 릴리스가 나올 때마다 함수형 프로그래밍에서 점점 더 많은 기능을 차용하는 것 같습니다.

클로저, 익명 함수, 값 전달 및 반환 함수는 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의 "A Taste of Haskell" 강연의 슬라이드 109-116
- "차세대 주류 프로그래밍 언어:게임 개발자의 관점(Tim Sweeney 저)

점검 함수형 프로그래밍이 중요한 이유

첫 번째 요점에는 동의하지만 시대는 변합니다.기업은 늦게 채택하더라도 이점이 있다고 판단되면 대응할 것입니다.인생은 역동적입니다.

그들은 90년대 후반에 스탠포드에서 Haskell과 ML을 가르치고 있었습니다.Carnegie Mellon, MIT, Stanford 및 기타 좋은 학교와 같은 곳에서 학생들에게 이를 제시하고 있다고 확신합니다.

나는 대부분의 "웹에 관계형 데이터베이스를 노출하는" 앱이 오랫동안 그 맥락을 유지할 것이라는 점에 동의합니다.Java EE, .NET, RoR 및 PHP는 해당 문제에 대한 꽤 좋은 솔루션을 발전시켰습니다.

당신은 중요한 것을 발견했습니다:함수형 프로그래밍을 강화하는 다른 방법으로는 쉽게 해결할 수 없는 문제일 수 있습니다.그게 뭘까요?

대규모 멀티코어 하드웨어와 클라우드 컴퓨팅이 이를 추진할 것인가?

FP는 생산성, 신뢰성, 유지 관리 측면에서 상당한 이점을 갖고 있기 때문입니다.매니코어는 많은 양의 레거시 코드에도 불구하고 마침내 대기업을 전환하게 만드는 킬러 앱일 수 있습니다. 더욱이 C#과 같은 대형 상용 언어도 매니코어 문제로 인해 뚜렷한 기능적 특징을 취하고 있습니다. 동시성 및 병렬성과 잘 맞지 않습니다.

나는 "일반" 프로그래머가 그것을 이해하지 못할 것이라는 데 동의하지 않습니다.그들은 결국 OOP를 이해한 것처럼 그렇게 될 것입니다(이는 더 이상은 아니지만 신비롭고 이상합니다).

또한 대부분의 대학에서는 FP를 가르치며, 많은 대학에서는 이를 첫 번째 프로그래밍 과정으로 가르치기도 합니다.

와- 흥미로운 토론이군요.이에 대한 내 생각은 다음과 같다.

FP는 일부 작업을 상대적으로 단순하게 만듭니다(FP가 아닌 언어에 비해).None-FP 언어는 이미 FP에서 아이디어를 가져오기 시작했기 때문에 이러한 추세는 계속될 것이며 사람들이 FP로 더 쉽게 도약하는 데 도움이 되는 병합이 더 많이 나타날 것이라고 생각합니다.

그것이 인기를 끌지 아닐지는 모르겠지만 제가 조사한 바에 따르면 함수형 언어는 배울 가치가 거의 확실하며 여러분을 더 나은 프로그래머로 만들어 줄 것입니다.참조 투명성을 이해하는 것만으로도 많은 디자인 결정이 훨씬 쉬워지고 결과 프로그램에 대한 추론도 훨씬 쉬워집니다.기본적으로 문제가 발생하면 수백 개의 클래스/메서드/함수로 인해 발생할 수 있는 일관되지 않은 상태의 문제가 아니라 단일 함수의 출력에만 문제가 있는 경향이 있습니다. 부작용이 있는 비교언어로.

FP의 상태 비저장 특성은 웹의 상태 비저장 특성에 더 자연스럽게 매핑되므로 기능적 언어는 보다 우아하고 RESTFUL 웹앱에 더 쉽게 적합합니다.웹과 같은 본질적으로 상태가 없는 기능적 플랫폼에서 애플리케이션 상태를 유지하고 상태 저장 명령형 언어의 추상화(때때로 매우 누출됨)를 유지하기 위해 VIEWSTATE 및 SESSION 키와 같은 끔찍하게 추악한 해킹에 의존해야 하는 JAVA 및 .NET 프레임워크와 대조됩니다.

또한 애플리케이션의 상태 비저장이 많을수록 병렬 처리에 더 쉽게 적응할 수 있습니다.귀하의 웹 사이트가 인기를 얻으면 웹에 매우 중요합니다.더 나은 성능을 얻기 위해 사이트에 더 많은 하드웨어를 추가하는 것이 항상 간단한 것은 아닙니다.

내 견해로는 마이크로소프트가 이를 주류로 훨씬 더 밀어붙였기 때문에 이제 인기를 끌 것이라는 것이다.나에게 그것은 우리를 위해 할 수 있는 일, 새로운 도전, 그리고 미래에 대한 일자리 기회 때문에 매력적입니다.

일단 숙달되면 프로그래머로서 생산성을 더욱 높이는 데 도움이 되는 또 다른 도구가 될 것입니다.

토론에서 놓친 점은 최고의 유형 시스템이 현대 FP 언어에서 발견된다는 것입니다.게다가 컴파일러는 모든(또는 적어도 대부분) 유형을 자동으로 추론할 수 있습니다.

Java를 프로그래밍할 때 유형 이름을 작성하는 데 절반의 시간을 소비하지만 Java는 유형에 대해 안전하지 않다는 점이 흥미롭습니다.Haskell 프로그램에서 유형을 작성할 수는 없지만(컴파일러 검사 문서의 종류를 제외하고) 코드는 100% 유형 안전합니다.

다른 답변 외에도 순수한 기능적 용어로 솔루션을 캐스팅하면 문제를 더 잘 이해할 수 있습니다.반대로, 기능적인 스타일로 생각하는 것은 더 나은* 문제 해결 능력을 개발할 것입니다.

*기능적 패러다임이 더 좋거나 추가적인 공격 각도를 제공할 수 있기 때문입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow