함수형 프로그래밍이 아직 인수되지 않은 이유는 무엇입니까?


197

선언적 / 기능적 프로그래밍 (언어)에 대한 텍스트를 읽었으며 Haskell을 사용해 보았고 직접 작성했습니다. 내가 본 것에서 함수형 프로그래밍은 고전적인 명령형 스타일에 비해 몇 가지 장점이 있습니다.

  • 무국적 프로그램; 부작용 없음
  • 동시성; 떠오르는 멀티 코어 기술로 매우 훌륭하게 재생
  • 프로그램은 일반적으로 더 짧고 경우에 따라 읽기가 더 쉽습니다
  • 생산성 향상 (예 : Erlang)

  • 명령형 프로그래밍은 매우 오래된 패러다임 (내가 아는 한)이며 21 세기에는 적합하지 않을 수 있습니다.

기능 언어로 작성된 프로그램이나 프로그램을 사용하는 회사가 여전히 "희귀"한 이유는 무엇입니까?

함수형 프로그래밍의 장점을 볼 때 왜 여전히 명령형 프로그래밍 언어를 사용하고 있습니까?

어쩌면 1990 년에는 너무 이르지만 오늘은 어땠을까요?


1
참고 : 이 질문은 두 번 적어도 메타 논의하고 있으며, 합의가이 있다는 것입니다 해야한다 위에서 언급 한 "역사적 의미"잠금을 통해 보관 불구하고, 유지. 이 질문에 대한 또 다른 지루한 토론에 참여하지 않고 답변을 그대로 즐기고 비즈니스에 대해 계속할 필요가 없기 때문에 잠금을 해제하기 위해 이것을 보는 모든 사람에게 강력히 권장합니다.
Shog9

답변:


530

이러한 모든 장점도 단점이기 때문입니다.

무국적 프로그램; 부작용 없음

실제 프로그램은 모두 부작용과 돌연변이에 관한 것입니다. 사용자가 버튼을 누르면 무언가 일어나기를 원하기 때문입니다. 그들은 무언가를 입력 할 때, 그 상태가 이전에 있던 상태를 대체하기를 원합니다. 회계에서 Jane Smith가 결혼하고 이름을 Jane Jones로 변경하면 급여 체계를 인쇄하는 비즈니스 프로세스를 뒷받침하는 데이터베이스가 그러한 종류의 돌연변이를 처리하는 것이 더 좋습니다. 외계인에서 기관총을 발사 할 때, 대부분의 사람들은 적중률이 더 낮은 새로운 외계인의 건설로 정신적으로 그것을 모델링하지 않습니다. 그들은 기존의 외계인 속성의 변이로 모델링합니다.

프로그래밍 언어 개념이 모델링되는 도메인에 대해 근본적으로 작동하는 경우 해당 언어를 사용하여 정당화하기는 어렵습니다.

동시성; 떠오르는 멀티 코어 기술로 매우 훌륭하게 재생

문제는 방금 추진되었습니다. 불변의 데이터 구조를 사용하면 오래된 데이터로 작업 할 수있는 비용으로 저렴한 스레드 안전성을 얻을 수 있습니다. 변경 가능한 데이터 구조를 사용하면 데이터를 일관성있게 유지하기 위해 복잡한 논리를 작성해야하는 비용으로 항상 새로운 데이터를 처리 할 수 ​​있다는 이점이 있습니다. 그중 하나가 다른 것보다 낫다는 것은 아닙니다.

프로그램은 일반적으로 더 짧고 경우에 따라 읽기가 더 쉽습니다

더 길고 읽기 어려운 경우를 제외하고. 기능적 스타일로 작성된 프로그램을 읽는 방법을 배우는 것은 어려운 기술입니다. 사람들은 일련의 계산을 수행하는 것이 아니라 레시피처럼 수행해야 할 일련의 단계로 프로그램을 생각하는 것이 훨씬 더 나은 것처럼 보입니다.

생산성 향상 (예 : Erlang)

기능적 스타일로 프로그래밍하는 방법을 알고있는 프로그래머를 고용하는 데 드는 막대한 비용을 정당화하려면 생산성이 크게 높아져야합니다.

그리고 작업 시스템을 버리고 싶지 않다는 것을 기억하십시오. 대부분의 프로그래머는 새로운 시스템을 처음부터 구축하지 않고 기존 시스템을 유지 관리합니다. 대부분 기존 시스템은 작동하지 않는 언어로 작성되었습니다. 이를 주주들에게 정당화하려고한다고 상상해보십시오. 기존 작업 급여 시스템을 폐기하여 수백만 달러의 비용으로 새로운 시스템을 구축 한 이유는 무엇입니까? "기능 프로그래밍이 훌륭하기 때문에"주주들을 기쁘게 할 것 같지 않습니다.

명령형 프로그래밍은 매우 오래된 패러다임 (내가 아는 한)이며 21 세기에는 적합하지 않을 수 있습니다.

함수형 프로그래밍도 매우 오래되었습니다. 나는 개념의 나이가 어떻게 관련되어 있는지 알지 못한다.

나를 잘못 이해하지 마십시오. 함수형 프로그래밍을 좋아합니다. 함수형 프로그래밍의 개념을 C #으로 가져 오기를 원했기 때문에이 팀에 합류했습니다. 불변 스타일로 프로그래밍하는 것이 미래의 방식이라고 생각합니다. 그러나 단순히 원치 않는 기능적 스타일의 프로그래밍 에는 막대한 비용이 듭니다 . 보다 기능적인 스타일로의 전환은 수십 년에 걸쳐 천천히 그리고 점차적으로 일어날 것입니다. 이것이 바로 기능입니다. 더 기능적인 스타일로의 전환입니다. Haskell의 순도와 아름다움을 포용하지 않고 C ++을 포기한 것이 아닙니다.

나는 생계를 위해 컴파일러를 만들고 차세대 컴파일러 도구에 대한 기능적 스타일을 확실히 수용하고 있습니다. 함수형 프로그래밍은 근본적으로 우리가 직면 한 여러 종류의 문제에 적합하기 때문입니다. 우리의 문제는 문자열과 메타 데이터와 같은 원시 정보를 다른 문자열과 메타 데이터로 변환하는 것입니다. 누군가 IDE에서 타이핑하는 것처럼 돌연변이가 발생하는 상황에서 문제 공간은 본질적으로 변경된 트리 부분 만 점진적으로 재구성하는 것과 같은 기능적 기술에 적합합니다. 많은 도메인에는 기능적 스타일을 적용 할 수있는 훌륭한 속성이 없습니다 .


41
"회계에서 Jane Smith가 결혼하여 그녀의 이름을 Jane Jones로 변경했을 때 급여 체계를 인쇄하는 비즈니스 프로세스를 뒷받침하는 데이터베이스는 이러한 종류의 돌연변이를 처리하는 것이 더 좋았습니다." Jane Smith의 이전 이름이 기록 될 것입니다. Jane의 이전 이름을 모두 새 이름으로 소급해서 업데이트하지는 않습니다.)
Juliet

40
@ 줄리엣 : 물론입니다. 요점은 직원을 나타내는 객체가있는 경우 "직원 이름 변경"작업이 객체 ID를 변경하지 않는 직원 나타내는 객체의 변형이라고 생각하는 것이 좋습니다 . Jane Smith가 이름을 변경하면 Jane Jones라는 다른 직원을 만들지 않습니다 . 이름이 다른 두 명의 직원이 없습니다. 이 과정을 새로운 대상의 구성이 아닌 대상의 돌연변이로 모델링하는 것이 당연합니다.
Eric Lippert

24
이것은 좋은 답변이지만 때때로 귀하의 사례를 과장한다고 생각합니다. Juliet가 말했듯이 사람들은 이름 변경으로 생각할 수도 있지만 실제로는 더 깊은 수준의 이름 대체입니다. 기능 프로그램 (이 때문에 사람들이 읽을 어렵게 될 수도 있지만 그리고 있다 배운 스킬)가 더 이상이기 때문에, 그것은 일반적으로하지 않습니다. Haskell 프로그램은 Java 프로그램보다 훨씬 간결합니다. 심지어 고유 한 상태가 많은 "나쁜"도메인에도 있습니다.

29
+1이 답변을 읽는 것은 신선한 공기의 숨결이었습니다. 당신의 위치에있는 누군가로부터 그러한 실용주의 (기능 프로그래밍에 대한 기본 열정을 가지고)를 듣는 것은 환상적입니다.
Dhaust

11
"이러한 모든 장점은 단점이기도하기 때문에 무국적 프로그램; 부작용 없음": 내가 (FP에 대해 정식 답변을 작성하기에 충분하지 않음) 이해하는 한 이것은 정확하지 않습니다 . 함수형 프로그래밍은 상태를 피하는 것이 아니라 참조 투명성에 관한 것입니다. 하스켈 상태와 돌연변이를 허용 합니다. 그것은 단지 그것에 대해 추론하기 위해 다른 도구를 제공합니다.
Giorgio

38

프로그래밍의 대가 : 주요 프로그래밍 언어의 제작자와의 대화

[하스켈]

함수형 프로그래밍 언어가 주류에 들어 가지 않았다고 생각하는 이유는 무엇입니까?

존 휴즈 : 불쌍한 마케팅! 나는 선전을 의미하지는 않는다. 우리는 그것을 많이했습니다. 필자는 목표 시장 틈새 시장을 신중하게 선택하고 그 틈새 시장을 해결하는 가장 효과적인 방법으로 기능적 프로그래밍을 만들기위한 노력을 기울였다. 80 년대의 행복한 시절, 우리는 함수형 프로그래밍이 모든 것에 유익하다고 생각했습니다. 그러나 새로운 기술을 "모든 것에 대해 좋은 것"이라고 부르는 것은 "특히 아무것도 아닌 것"이라고 부르는 것과 같습니다. 브랜드는 무엇입니까? 이것은 John Launchbury가 ICFP에서 초대 한 연설에서 매우 명확하게 설명한 문제입니다. Galois Connections는 브랜드가 "기능 언어의 소프트웨어"였을 때 거의 이어졌지만 "고 확보 소프트웨어"에 중점을 둔 이후 강점에서 강점으로 바뀌 었습니다.

많은 사람들이 기술 혁신이 어떻게 진행되고 있는지 전혀 모릅니다. 더 나은 기술이 그 자체만으로도 우세 해 지길 기대하지만 ( "더 나은 쥐덫" 효과) 세상은 그렇지 않습니다.


36
하스켈 : 20 년 후, 밤새 성공했습니다!
Juliet

링크를 따라 Grady Booch의 다소 재미있는 dis에 대한 리뷰를 읽으십시오. Booch가 누군지 몰랐지만 어쨌든 나를 즐겁게 만들었습니다.
fearofawhackplanet

4
Grady Booch는 궁극적으로 Jacobl 및 Rumbaugh와 함께 UML의 가증을 책임집니다.
저의 올바른 의견 그냥

27

주된 대답은 다른 것을 바꾸거나 대체하지 않아야한다는 것입니다. 도구는 장단점이 서로 다른 도구이며 프로젝트와 가용 한 인재 풀과 같은 기타 "부드러운"문제에 따라 다른 접근 방식이 달라집니다.

멀티 코어로 인한 동시성 증가는 다른 스타일보다 함수형 프로그래밍을 선택할 때 (전 세계 개발 프로젝트 세트의 비율)이 증가 할 것입니다.

오늘날의 전문 인재 풀의 대부분이 명령적이고 객체 지향적 인 기술에 가장 편안하기 때문에 오늘날에는 드물다고 생각합니다. 예를 들어, 상용 프로젝트의 언어로 Java를 두 번 이상 선택했는데 논란의 여지가 적기 때문에 프로그래밍을 할 수있는 사람들이 부족하지 않을 것입니다.


이것은 매우 통찰력 있고 유쾌하게 실용적입니다. 확실히이 질문에 대한 모든 대답에서 본 최고의 답변입니다.
벤슨

어쩌면 둘 다 일류 시민 인 언어에 의해 인기가있을 것입니다.
Kevin Kostlan

1
110 %에 동의하십시오. 여러 차례에 걸쳐 FP에 들어 가려고했지만 몇 주 후에도 계속하겠다는 의지를 잃었습니다. 저는 30 년 이상 절차 적으로 프로그래밍을 해왔으며 명령형 프로그래밍에도 너무 익숙합니다. 이것은 IT 산업 전반에 해당됩니다. 변화는 쉽게 또는 빨리 오지 않을 것입니다.
Richard Eng

26

함수형 프로그래밍의 장점에도 불구하고 명령형 및 객체 지향형 프로그래밍은 완전히 사라지지 않을 것입니다.

명령형 및 객체 지향 프로그래밍은 문제와 솔루션에 대한 단계별 설명입니다. 따라서 이해하기가 더 쉬울 수 있습니다. 함수형 프로그래밍은 다소 모호 할 수 있습니다.

궁극적으로 유용한 프로그램은 항상 부작용 (예 : 사용자에게 실제 출력을 제공하는 것과 같이)을 가지므로, 가장 순수한 기능적 언어는 여전히 명령형 세계로 나아가는 방법이 필요합니다.

현재의 최신 기술은 명령형 언어 (예 : C #)가 기능적 세계 (예 : 람다 문)에서 기능을 차용하고 그 반대도 마찬가지입니다.


3
OOP가 일종의 명령형 프로그래밍의 하위 집합이 아닙니까?
pankrax

9
OOP는 슈퍼 세트입니다. C ++가 C와 마찬가지로 OOP가 필수적입니다.
Robert Harvey

10
OOP가 반드시 명령형 프로그래밍에 의존한다고 생각하지 않습니다. Clojure 또는 CLOS를 살펴보십시오. 둘 다 기능적이지만 객체 지향적입니다.
Gabe

9
OO 언어는 필수적이지만 반드시 그럴 필요는 없습니다. OCaml은 강력한 (순수하지는 않지만) 기능 언어로 전체 영역이 OO입니다.

7
왜 OOP가 명령형 프로그래밍의 상위 세트인지 이해하지 못했습니다. 모든 명령 코드가 OOP는 아니며 모든 기능 코드가 OOO가 아닙니다. 차라리 OOP는 공기 역학적 날개가 자동차, 비행기, 로켓, 냉각 팬 또는 풍차와 같은 공기 역학적 날개와 같은 명령형 프로그래밍 및 기능적 프로그래밍에 대한 것이라고 말하고 싶습니다. 일대일 연결.
Sebastian Mach

21

그렇지 않습니까?

스몰 토크는 당시의 훌륭한 객체 지향 시스템이었습니다. 왜 객체 지향 프로그래밍이 인수되지 않았습니까? 글쎄요. 스몰 토크처럼 보이지 않습니다. 주류 언어는 C ++, Java, C # 등으로 스몰 토크와 유사 해집니다. 패션과 스타일이 다른 것보다 느리게 변하기 때문에 OO가 주류가되었을 때 OO의 일부를 오래된 언어로 붙이면 C처럼 삼키기에 충분했습니다. .

기능도 마찬가지입니다. 하스켈은 훌륭한 기능적 언어였습니다. 그러나 우리는 20 년 전에 오늘날 C와 같은 구문을 사용하는 훨씬 더 많은 주류 프로그래머를 보유하고 있습니다. 따라서 C와 같아야합니다. 완료 : LINQ 표현식을보고 작동하지 않는다고 말합니다.


2
흥미로운 점이지만, 주류 언어가 어떻게 스몰 토크와 비슷 해졌습니까? 예를 들어 C ++, Java 및 C #은 메시지 전송을 기반으로하지 않으며, 이는 스몰 토크 패러다임의 가장 중요한 부분입니다.
Jonathan Sterling

4
Jonathan : 스몰 토크 기능을 선택하고 C ++ (가장 오래된 것)에서 가장 약한 점, Java에서 OK, C #에서 더 나은 점을 관찰하십시오. 예를 들어, GC (Java / C #에만 해당), 오토 박싱 (나중에 Java / C #에만 해당), 클로저 (C #에만 해당) 및 리플렉션 (Java에는 존재하고 C #에는 우수함)이 있습니다. 메시지 전달을 원한다면 C # 4를보십시오 dynamic. 이것이이 기능들 중 가장 스몰 토크이므로,이 세 언어 중 가장 현대적인 최신 버전에만 존재한다는 것은 놀라운 일이 아닙니다. :-)
Ken

Javascript, python 및 ruby는 실제로 그 기능을 잘 보여줍니다.
nafg

15

나는 명령형 언어가 더 널리 퍼져 있다고 생각합니다. 왜냐하면 그것은 더 많은 사람들이 익숙하기 때문입니다. 함수형 프로그래밍이나 명령형 프로그래밍 모델은 다른 것보다 더 모호하거나 학문적이지 않습니다. 실제로, 그들은 보완입니다.

한 포스터는 명령형 코드가 함수형 프로그래밍 코드보다 이해하기 쉽다고 말했다. 독자가 명령형 코드를 이미 본 경우, 특히 이전 예제가 동일한 "패밀리"(예 : C / C ++, Perl, PHP 및 Java)의 일부인 경우에만 해당됩니다. 나는 어떤 명령형 언어 에 대해서도 이것이 사실이라고 주장하지 않을 것이다 . 극단적 인 예를 만들기 위해 Java와 Forth를 비교해보십시오.

평범한 사람에게는 Hypertalk 및 SQL과 같은 장황한 언어를 제외한 모든 프로그래밍 언어가 해독 할 수없는 횡설수설입니다. 참고로, SQL은 선언적 및 / 또는 기능적 언어이며 엄청난 인기를 누리고 있습니다.

처음부터 Lisp-y 또는 Haskell-y 언어에 대해 교육을 받았다면 기능 프로그래밍 언어가 모두 정상이라고 생각할 것입니다.


"한 포스터는 명령형 코드가 함수형 프로그래밍 코드보다 이해하기 쉽다고 말했다. 독자가 명령형 코드를 이미 본 경우, 특히 이전 예제가 동일한"패밀리 "의 일부인 경우에만 해당됩니다 (예 : C / C ++, Perl, PHP and Java). ": 매우 사실 (+1) : 프로그래밍을 시작할 때 Pascal과 C를 배우는 데 얼마나 많은 노력을 기울 였는지 기억합니다. 스칼라, 하스켈 또는 구성표를 읽는 것이 얼마나 쉬운 지 이제이 언어들에 대한 경험이 있습니다.
Giorgio

2
여전히 변경 가능한 상태를 유용하게 생각하는 유일한 이유는 빠른 코드를 작성하는 쉬운 방법을 제공하기 때문입니다 (복사 없음). 그러나 그 이유는 충분한 함수형 프로그래밍을 모르고 90 %의 상황에서 가변 상태를 사용하지 않고 빠른 함수형 코드를 작성할 수 있기 때문일 수 있습니다.
Giorgio

3
가장 널리 사용되고 오래 사용되는 계산 구성 환경 중 하나는 스프레드 시트입니다. 본질적으로 명명 된 변수가 아닌 셀이있는 기능적 프로그래밍 환경. 나는 일반적으로 사람들이 본질적으로 프로그램을 일련의 단계로 생각한다고 생각하지 않습니다. 프로그래머들은 아마도 광범위한 명령형 언어로 가파르게되었을 것입니다.
jpnp

14

이미 언급하지 않은 몇 가지 사항 만 언급 할만큼 충분한 답변을 얻었습니다.

첫째로 (내 마음에) 절차 언어는 공통성의 정도에서 큰 이점을 얻었습니다. 예를 들어, 거의 모든 주류 절차 (또는 OO) 언어를 거의 어느 정도 알고있는 사람은 대부분 다른 사람을 합리적으로 잘 읽을 수 있습니다. Java, C #, Cobol, Fortran 또는 Basic (일부 예제)에서는 적극적으로 작업하지 않지만 거의 매일 실제로 사용하는 사람들처럼 합리적으로 읽을 수 있습니다.

기능적인 측면에서, 그건 훨씬 적은 사실. 예를 들어 Scheme을 상당히 합리적으로 작성할 수는 있지만 Ocaml 또는 Haskell을 읽는 데 거의 사용되지 않습니다 (두 개의 예제 만 해당). 단일 가족 내에서도 (예 : Scheme vs., Common Lisp) 친숙 함이 다른 사람에게는 거의 잘 맞지 않는 것 같습니다.

기능 코드가 더 읽기 쉽다는 주장은 좁은 범위의 조건에서만 적용되는 경향이 있습니다. 언어에 매우 익숙한 사람들에게는 가독성이 실제로 뛰어나지 만 다른 사람들에게는 종종 존재하지 않습니다. 설상가상으로 절차 적 언어의 차이점은 대부분 구문에 따라 상대적으로 쉽게 배울 수 있지만, 기능적 언어의 차이점은 종종 훨씬 더 근본적이기 때문에 실제로 이해하기 위해서는 상당한 연구가 필요합니다 (예 : Lisp가 Monads를 이해하는 데 거의 도움이되지 않음).

다른 주요 요점은 기능적 프로그램이 절차 적 프로그램보다 짧다는 생각은 종종 시맨틱보다 구문에 기반한다는 것입니다. Haskell로 작성된 프로그램 (예를 들어)은 종종 짧지 만 그 기능은 그 일부가 아닙니다. 단순히 Haskell이 비교적 간결한 구문을 가지고 있다면 큰 문제입니다.

간결한 소스 코드를 위해 APL과 경쟁 할 수있는 순전히 기능적인 언어는 거의 없습니다 (공평하게도 APL은 더 높은 수준의 함수 생성도 지원하므로 다른 경우와 크게 다르지 않습니다). 반대로 Ada와 C ++ (몇 가지 예만 해당)는 주어진 작업을 수행하는 데 필요한 작업 수 측면에서 상당히 경쟁적 일 수 있지만 구문은 (적어도 일반적으로) 훨씬 더 장황합니다.


훌륭한 의견! 나는 전적으로 동의합니다. 나는 비록 두 언어의 진정한 전문가 일지라도 대부분의 절차 적 언어는 읽고 이해하기가 쉽다는 것을 안다. FP 언어에 대해 똑같이 말할 수 없습니다.
Richard Eng

1
또 다른 중요한 점은 주어진 패러다임에서 초보자부터 전문가까지 다양한 전문 지식을 찾을 수 있다는 것입니다. FP 코드는 전문가가 쉽게 읽을 수 있고 이해하기 쉽지만 중간 정도의 프로그래머는 여전히 어려움을 겪을 수 있습니다. 전문가들은 대개 FP 커뮤니티의 아주 작은 부분을 구성합니다.
Richard Eng

11

인식 된 필요 없음

폰 노이만 스타일에서 Can Programming Be Liberated 라는 제목의 John Backus의 Turing Award 강의 사본을 보냈을 때 나의 오래된 릭 클라인 상사의 대답을 기억합니다 .

그의 대답 : "아마도 우리 중 일부 는 폰 노이만 스타일에서 해방되고 싶지 않을 것 입니다!"


10

함수형 프로그래밍이 아직 인수되지 않은 이유는 무엇입니까?

기능은 어떤 것에는 좋고 다른 것에는 더 나쁘기 때문에 "인계하지"않을 것입니다. 그러나 실제 세계에서는 이미 어디에나 있습니다.

무국적 프로그램; 부작용 없음

상태 비 저장 프로그램은 테스트하기가 더 쉽습니다. 이것은 현재 업계에서 널리 인정 받고 있으며 종종 악용되고 있습니다.

동시성; 상승하는 멀티 코어 기술로 매우 훌륭하게 재생됩니다. 프로그램은 일반적으로 짧으며 경우에 따라 읽기 쉽습니다. 생산성이 향상됩니다 (예 : Erlang)

동시성과 병렬 처리를 병행하고 있습니다.

순차 프로세스 (CSP) 통신을 사용하여 동시성을 효과적으로 수행 할 수 있습니다. CSP 내부의 코드는 로컬 상태를 변경시킬 수 있지만 그 사이에 전송 된 메시지는 항상 변경할 수 없습니다.

순전히 기능적인 프로그래밍은 캐시가 비우호적이기 때문에 멀티 코어에서 매우 나쁘게 재생됩니다. 코어는 공유 메모리에 대한 경쟁으로 끝나고 병렬 프로그램은 확장되지 않습니다.

기능 언어로 작성된 프로그램이나 프로그램을 사용하는 회사가 여전히 "희귀"한 이유는 무엇입니까?

스칼라는 종종 기능적 언어로 여겨지지만 오늘날 세계에서 가장 인기있는 언어 중 하나 인 C #보다 기능적이지 않습니다.

함수형 프로그래밍의 장점을 볼 때 왜 여전히 명령형 프로그래밍 언어를 사용하고 있습니까?

순전히 기능적인 프로그래밍에는 심각한 단점이 많으므로 Lisp, Scheme, SML, OCaml, Scala 및 C #과 같은 불완전한 기능 언어를 사용합니다.


7

직장에서 어떤 기능적 프로그래밍이 프로젝트에 가져올 수 있을지 생각할 때 항상 같은 생각을하게되었습니다.

  1. 함수형 프로그래밍의 이점을 최대한 활용하려면 게으름이 필요합니다. 예, 엄격한 기능적 언어가 있지만 기능적 프로그래밍의 실제 이점은 엄격한 코드에서도 잘 드러나지 않습니다. 예를 들어, Haskell에서는 목록에서 일련의 게으른 작업을 쉽게 만들고 연결하여 목록에 적용 할 수 있습니다. 예 : op1 $ op2 $ op3 $ op4 $ someList. 전체 목록을 작성하지는 않으며 내부적으로 요소를 한 번에 하나씩 안내하는 멋진 루프를 얻습니다. 이를 통해 실제로 모듈 식 코드를 작성할 수 있습니다. 두 모듈 사이의 인터페이스에는 잠재적으로 방대한 데이터 구조를 넘겨 줄 수 있지만 구조를 상주 할 필요는 없습니다.

  2. 그러나 게으름이 있으면 메모리 사용에 대해 추론하기가 어렵습니다. Haskell 컴파일러 플래그를 변경하면 알고리즘이 사용하는 메모리의 양이 O (N)에서 O (1)로 변경되는 경우가 종종 있습니다. 사용 가능한 모든 메모리를 최대한 활용해야하는 응용 프로그램이있는 경우 실제로 허용되지 않으며 모든 메모리가 필요하지 않은 응용 프로그램에도 적합하지 않습니다.


게으름은 디버깅과도 덜 상호 작용합니다.
Brian

3
다른 언어로 추적하는 많은 버그가 참조 투명성 부족과 관련이 있다는 것을 알았을 때 디버깅 문제에 대해 걱정할 필요가 없지만 때로는 고통 스럽습니다.
sigfpe

6

두가지:

  1. 기술이 아무리 우수하더라도 시간이 걸립니다. FP의 아이디어는 약 70 세입니다. 그러나 소프트웨어 엔지니어링 (업계의 참호에서)의 주류 사용은 아마도 10 년 미만일 것입니다. 개발자에게 인종적으로 새로운 사고 방식을 채택하도록 요구하는 것은 가능하지만 시간이 많이 걸립니다 (수년, 수년). 예를 들어, OOP는 1980 년대 초에 주류 사용량을 실제로 얻었습니다. 그러나 1990 년대 후반까지는 지배력을 얻지 못했습니다.
  2. 사람들이 기술을 강타하기 전에 기술의 힘에 맞서야합니다 . 현재 사람들은 병렬 처리를 사용하지 않는 도구를 사용하고 있습니다. 병렬 처리를 사용하지 않는 앱이 참으로 느려질 때 많은 사람들이 병렬 도구를 사용해야하고 FP가 인기를 얻습니다. 이것은 FP의 다른 강점에도 적용될 수 있습니다.

3
FP는 코드 재사용에 매우 능숙합니다. 아마도 OO보다 낫습니다. 나는 직장에서 몇 번이나 처리해야했고, 다른 유형으로 마이그레이션하고 새로운 시스템을 만들었습니다.
nlucaroni

@ 프레디 리오스와 @nlucaroni. 나는 오해를 정리하기 위해 그 의견을 바꾸었다.
Phil
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.