대학에서 4 년 동안 우리는 여러 기능 프로그래밍 언어로 많은 기능 프로그래밍을 사용하고 있습니다. 그러나 나는 또한 객체 지향 프로그래밍을 많이 사용했으며 실제로 작은 프로젝트를 수행 할 때 객체 지향 언어를 더 많이 사용하여 첫 번째 직업을 준비합니다. 그러나 나는 종종 이러한 프로젝트를 수행 할 때 함수형 프로그래밍 언어로 코딩하기를 원합니다.

그러나 직업을 찾을 때 기능적 프로그래밍 언어에 대한 지식이 필요한 직업을 보는 것은 매우 드 rare니다.

업계에서 기능적 프로그래밍 언어가 더 많이 사용되지 않는 이유는 무엇입니까? 요즘에는 함수형 프로그래밍 언어에 대한 뉴스가 상당히 많으므로, 현재 업계에서 함수형 프로그래밍이 현재 사용되고 있는지 궁금합니다.

함수형 프로그래밍이 널리 보급되지 않은 이유 중 하나는 지식 기반이 없기 때문입니다. 저의 경험은 기업이 주류가 아닌 기술을 구현하는 측면에서 매우 위험하다는 것입니다. 새로운 패러다임을 고려할 필요가있는 것은 (Ericsson과 같은) 비즈니스 요구가있는 경우에만 가능합니다. 그러나 Ericsson의 경우에도 경영진이 c ++을 사용해야하고 Joe Armstrong이 erlang 호출을 C ++로 코딩해야한다고 들었습니다! 이것은 회사가 새로운 기술을 구현하는 것을 꺼려하는 것을 보여 주어야합니다!

저는 교수였으며 프로그래머와 마찬가지로 교수는 항상 다음 큰 것을 찾고 있습니다. 그들이 찾은 것으로 생각할 때, 그들은 그것을 수레로 만들고 모든 사람들이 쌓입니다. 그들은 교수가 정말로 똑똑해야한다고 생각하는 학생들에게 전파하고 있기 때문에 왜 교수가 되더라도 저항을받지 못합니다.

함수형 프로그래밍은 그런 악몽이다. 확실히 조사해야 할 흥미로운 질문이 많고 흥미로운 회의 기사가 많이 있습니다. 특히 새로운 아이디어는 아니며 현대 언어로도 할 수 있으며 아이디어가 흥미로워 질 필요는 없습니다. 또한 좋은 기술입니다.

이를 감안할 때 기능 프로그래밍은 OOP가 유일한 것이 아닌 것처럼 화살통에있는 화살표 일뿐입니다.

컴퓨터 과학 학계를 가진 나의 소고기는 실제로 실제적인 의미, 즉 품질 관리를 결정하기 위해 산업과의 실질적인 상호 작용이 부족합니다. 만약 그 품질 관리가 있었다면, 최신 밴드 왜건이 아니라 트레이드 오프 (trade-off)로 문제와 솔루션의 범위를 분류하는 데 다른 강조점이있을 수 있습니다.

요즘 소프트웨어 개발에서 가장 큰 문제는 복잡성을 관리하는 능력입니다. 이것은 대부분의 기능적 프로그래밍 언어의 초점이 아닙니다. 따라서, 언어 수행은 우선 순위 (즉, 더 많은 인기를 OOP 언어)이 단지 더 많은 학술 함수형 언어에서 나오는 등 최상단에 쿨러 기능의 일부를 도용하는 경향이 있음을 확인합니다.

함수형 프로그래밍은 확실히 느리지 만 확실하게 시작되고 있습니다.

예를 들어, 내가 구축하고있는 신생 기업은 다음과 같은 이유로 기능 언어 (Clojure)를 기본 개발 언어로 사용하고 있습니다.

• 생산성 -FP를 배우는 것은 어렵지만 일단 익히면 힘과 표현력면에서 이기기가 매우 어렵습니다. 아마도 C # 또는 Java에서 필요했던 것과 비교하여 주어진 기능을 구현하기 위해 줄 수의 약 1/10 줄을 쓰고 있습니다.

• 신뢰성 -순수한 함수는 상태 저장 객체보다 추론 및 테스트하기가 훨씬 쉽습니다. 따라서 더 나은 테스트를 작성하고 코드의 정확성을 훨씬 쉽게 검증 할 수 있습니다.

• 동시성 -기능적 언어는 불변성을 강조하므로 여러 코어에서 효과적으로 실행해야하는 것보다 동시 응용 프로그램에 막대한 이점이 있습니다. 그리고 여러 개의 코어에서 실행하는 것이 미래입니다. 이것이 왜 중요한지에 대한 간단한 설명은 http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey 를 참조하십시오 .

• 구성 성 / 모듈성 -기능성 언어는 복잡한 OO 시스템보다 구성 요소를 더 쉽게 연결하는 것처럼 보입니다. 나는 여전히 이것에 대한 모든 이유를 알아 내지 못했지만 그 중 일부는 OO 모델이 그들과 함께 드래그하는 "사고 복잡성"이 모두 없다는 사실에서 비롯됩니다. 스튜어트 할로 웨이 (Stuart Halloway)의 래디컬 단순 (Radical Simplicity)에 대한 이야기 는 이러한 아이디어를 훨씬 더 깊이 탐구합니다.

편집 : Despertar의 의견에 대한 응답으로, 모듈성을 제한하는 OOP 시스템의 "부수적 복잡성"의 예는 딥 클로닝과 얕은 클로닝의 문제입니다. 클로닝 및 돌연변이 의미론의 신중한 분석. 작은 경우에는 관리가 가능하지만 복잡한 시스템에서는 심각한 문제가됩니다. 순수한 기능적 데이터 구조에 의존하는 경우이 문제는 처음에는 존재하지 않습니다.

킬러 앱 부족

이봐, 여기 이거 신선 해 보인다. (발굴 발굴 발굴)

저는 대부분의 프로그래밍 언어가 "킬러 앱"을 통해 번성했다고 생각합니다. 언어에 독점적 인 (혹은 그런 방식으로 본) 강력한 것입니다. 이것은 모든 흡수가 그 적용 이라고 말한 것이 아니라, 언어를 더 큰 수용으로 이끌었다는 것입니다.

틈새 시장이 오늘날 우리가 가지고있는 일부 언어의 채택을 이끌어 낸 것에 대한 굉장히 정확한 견해는 다음과 같습니다.

• C : 모든 곳에서 작동 (70 년대 후반과 80 년대)
• C ++ : GUI 프레임 워크 (90 년대 초)
• 자바 : 애플릿과 서블릿 (90 년대 후반)
• Objective-C : iOS 앱 (이전에는 OS X 앱)
• 루비 : 레일
• C # : ASP.NET, WinForms
• PHP : 워드 프레스 등
• 자바 스크립트 : AJAX, 특히 프레임 워크를 통한
• 루아 : 게임 스크립팅, 특히 와우

그 외에도 많은 독점 언어가 강력한 영업 조직 (Oracle 및 그보다 낮은 수준의 Microsoft 언어)을 통해 효과적으로 도입되어 자체 틈새 시장을 만들었습니다.

이 목록에 대한 매우 중요한 참고 사항 : 킬러 앱이 나타내는 언어의 "틈새"는 수십 년이지나면서 점점 더 구체적이되었습니다. 게임 스크립팅 목록에서 마지막에 주목하십시오 . 다른 언어로 이미 충분히 잘 해낸 것들의 목록으로 인해 언어에 대한 관심이 점점 더 어려워지고 있습니다.

따라서 모든 기능 언어가 실제로 이륙해야하는 것은 틈새입니다. 실제로는 아직 거대한 기능적 언어가 없지만 작은 틈새에는 많은 것이 있습니다.

• 이맥스 리스프 (Emacs Lisp) : 개발자들이 이맥스에서 80 년대부터 계속 사용했습니다. ( 다른 곳에서는 거의 사용하지 않았습니다 .)
• 얼랭 : 어디서나 많은 동시 에이전트를 원합니다.
• 계획 : 교육
• APL / J / K : 재무 (논쟁을 위해 이러한 기능을 호출하자)
• 일반적인 리스프 : "AI"-사람들이 그것을 사용하는 경향이 있습니다. 이것은 축복과 저주입니다.

자, 제가이 토론에서 빠뜨렸다 고 생각하는 유일한 주요 언어는 파이썬입니다. 파이썬은 매우 흥미로운 일을했습니다. 그것은 어떤 주요 틈새 시장에서 승자로 보이지 않고 성공했습니다. 이 수 내가 이런 식으로 언어 인기를보기위한 잘못된 플랫 아웃이야 것을 의미한다. 또한 킬러 앱이 없어도 채택과 수용을 유도 하기에 충분한 언어 가 대중화 될 수 있지만 매우 어렵고 시간이 오래 걸릴 수 있습니다. (펄은 비슷한 이야기를 가지고 있지만 몇 년 전에 왔으며 이제는 덜 흡수되고 있습니다.)

이로부터, 나는 생각 기능적 언어를 말할 수 있습니다 증가 :

• Clojure : 웹 프로그래밍, esp. 헤 로쿠를 통해
• 스칼라 : 리프트 (또는 요즘 플레이)-Java가없는 JVM

인기있는 기능적 언어를 어디에서 다음으로 볼 것인지 물었다면 턴키 클라우드 개발 (La Heroku 또는 GAE) 또는 턴키 모바일 앱 개발을 통해 기능적 언어를 찾아야합니다.

리스프가 절대로 붙 잡지 않은 것과 같은 이유로 (화염 전이 시작되게하십시오!) 함수형 프로그래밍은 명령형 및 객체 지향 프로그래밍과 비교할 때 매우 외계인 패러다임입니다. 대다수의 CS 학생들과 마찬가지로 C로 시작하여 C ++ / Java로 발전한 경우, 평상시 생각하는 방식과 완전히 직교하는 방식으로 사고하는 것을 배우고 싶지는 않습니다.

비즈니스와 프로그래밍을 고려해 봅시다.

소프트웨어를 전략적 자산으로 사용하는 비즈니스가 있습니다. 이것은 일반적이지 않습니다. 대부분의 비즈니스에서 IT는 회사의 실제 비즈니스를 지원하는 것입니다. 필요한 비용입니다. 그들은 $ X에 대해 필요한 IT를 얻을 수 있다는 것을 알고 있기 때문에 보수적입니다. 다른 것으로 전환하면 모든 것이 잘되면 $ X 미만을 절약하고 모든 것이 잘못되면 실제로 크게 잃을 것입니다.

또한 기업에서 가장 저렴한 것은 일반적으로 어제 수행 한 것입니다. 그러나 변화는 바람직하지만 비싸다. 회사가 C # /. NET 솔루션에서 F #으로 변경하려는 경우 문제가 있습니다. 그들의 프로그래머 (가장 날카로운 프로그래머는 아닐 것입니다)는 새로운 언어를 배우고 둘 다 능숙해야하며 자주 사용합니다. 오랜 시간 동안 둘 다 쓰는 루틴이있을 것입니다. 그들이 Haskell과 같은 것으로 이동하거나 처음에 C ++ / MFC를 사용하고 있다면 훨씬 더 많이 변하고 훨씬 비쌉니다.

또한 앞으로도 오랫동안 C # 프로그래머가 공급되고 Microsoft 지원이 계속 제공 될 것입니다. 현재의 IT 관행은 신뢰할 수 있습니다. 프로그래머의 지속적인 가용성에 대한 동일한 수준의 제도적 지원이나 보증은 없습니다.

따라서 대부분의 비즈니스에서 함수형 프로그래밍을 변경하는 것은 초기 비용이 많이 들며 장기적으로 잠재적 인 iffy를 제외하고 IT 비용 절감이 장기적으로 충분할 경우에만 비용을 지불합니다.

이미 기능적 스타일로 코드를 작성하고 있습니다.

코드에 대한 단위 테스트를 수행해야하는 경우 테스트 가능한 함수를 작성하는 경향이 있는데,이 함수는 부작용을 만들거나 의존하지 않으며 항상 동일한 인수 (순수 함수)에서 동일한 결과를 반환합니다. 이것이 기능적 프로그램의 주요 이점입니다.

기능적 언어가 너무 제한적이라고 생각합니다. 따라서 명령형 언어를 기능적 언어로 바꾸는 대신 명령형 언어는 기능적 기능을 갖습니다. 오늘날 거의 모든 프로그래밍 언어에는 클로저와 람다가 있습니다.

귀하의 질문에 대한 답변은 하나 뿐이라고 생각합니다. 이 답변이 필요한 여러 가지 관련 이유를 알 수 있지만 다른 질문입니다.

여기있어:

• 소프트웨어 아키텍트는 그들이 확신하는 솔루션을 제공합니다.
• 대부분의 건축가는 기능적 언어로 작업하지 않습니다.
• 일단 기술과 언어가 선택되면, 기업은 그들과 함께 일할 수있는 사람들을 찾습니다.

따라 잡는가? 기능 언어를 사용하는 데 자신감이있는 사람들이 건축가가되어 작업중인 프로젝트에 사용하기로 선택했는지 여부에 따라 달라집니다.

실제 문제는 상태입니다.

기능적 언어에는 전역 상태가 없습니다. 대부분의 산업 문제는 소규모의 일부 기능이 실제로 필요하지 않더라도 (원장 처리) 대규모 상태를 요구합니다 (원장 또는 일련의 거래를 어떻게 표현합니까).

그러나 우리는 본질적으로 상태가 가득 찬 Von-Neuman 아키텍처 시스템에서 코드를 실행하고 있습니다. 따라서 우리는 실제로 상태를 제거하지 않았으며 기능적 언어는 개발자의 상태 복잡성을 숨길뿐입니다. 이는 언어 / 컴파일러가 배후의 상태를 처리하고 관리해야 함을 의미합니다.

따라서 기능적 언어에는 전역 상태가 없지만 해당 상태 정보는 매개 변수 및 결과로 전달됩니다.

그렇다면 문제는 언어가 감각 뒤에있는 상태를 효율적으로 처리 할 수 ​​있을까요? 특히 데이터 크기가 아키텍처의 크기를 훨씬 초과하는 경우.

하드웨어 측면에서 보면

OS는 지난 몇 년 동안 주소 공간을 시각화하는 데 많은 도움을 주었으므로 응용 프로그램은 공식적으로 걱정할 필요가 없습니다. 그러나 메모리 부족이 심해지면 하드웨어를 쓰러 뜨리는 것에 대해 걱정하지 않는 응용 프로그램은 하드웨어를 쓰러 뜨리면 프로세스가 크롤링되는 속도가 느려집니다.

프로그래머가 기능 언어의 상태를 직접 제어하지 않기 때문에이를 처리하기 위해 컴파일러에 의존해야하며 이것을 잘 처리하는 기능 언어를 보지 못했습니다.

코인의 반대편에서 상태 전체 프로그래머는 상태를 직접 제어 할 수 있으므로 메모리 부족 상태를 보상 할 수 있습니다. 비록 실제로 그렇게 똑똑한 프로그래머를 많이 보지는 못했지만.

업계 측면에서 보면 :

업계에는 비효율적 인 스테이트 풀 프로그래머가 많이 있습니다.

그러나 시간이 지남에 따라 이러한 프로그램의 개선을 측정하는 것은 쉽습니다. 프로그램이 상태를 처리하는 방법을 개선하여 코드를 개선 할 수있는 문제에 개발자 팀을 던집니다.

기능적 프로그램의 경우 프로그램 을 개선 할 도구를 개선해야하므로 개선 을 측정하기 가 더 어렵습니다 (프로그램의 전반적인 개선이 아니라 애플리케이션이 기본 상태를 효율적으로 처리하는 방법 만 살펴 봅니다).

따라서 업계에서는 코드 개선 사항을 측정하는 기능이 필요하다고 생각합니다.

채용 관점에서

스탯 가득한 프로그래머가 많이 있습니다. 기능적인 프로그래머는 찾기가 어렵습니다. 따라서 산업이 기능적 스타일의 프로그래밍으로 교체되고 그것이 원하는 것이 아닌 경우 (기본적으로 프로그래머는 비싸다) 기본 공급 및 수요 모델이 시작될 것입니다.

이 질문에는 약간 잘못된 전제가 있습니다. 다음과 같은 이유로 :

1. 함수형 프로그래밍은 실제로 업계에서 일반적입니다. 그러나 숙련 된 프로그래머가있는 경우에만 사용됩니다. 초보자도 알 수 없습니다. 거의 모든 대형 프로그래밍 프로젝트에서 사용하고 있지만 숙련 된 프로그래머가 처리하는 영역에만 유지하십시오. 초보자는 기능적 프로그래밍이 필요없는 쉬운 모듈을 다룰 것입니다.
2. 이러한 현실을 고려할 때 사람들을 고용하는 회사 (보통 대학교에서 온 젊은이)는 실제로 함수형 프로그래밍 경험을 요구할 수 없습니다. 기능적 프로그래밍이 필요한 프로젝트의 모든 사람은 이미 15 년 동안 같은 회사에있었습니다.
3. 기능성 프로그래밍 지식이 30 년 안에 매우 유용 할 것임을 이미 알고 있기 때문에 대학들은이를 가르치기 시작했습니다. 그들의 시간 범위는 회사 에서처럼 반년이 아닌 30 년입니다.
4. 이러한 점은 사람들이 노동력에 들어갔을 때 실망하고 대학에서 배운 것들이 사용되지 않는 것을 보는 이유입니다. 그러나 그들은 30 년의 기간 동안 설계되었으며, 결국 유용 할 것입니다. 회사가 사람들이 알고있는 단순한 것들을 사용하는 것입니다.
5. 또한 몇 년 동안 대학을 졸업 한 후에도 실제 소프트웨어 프로젝트에서 사용할 수있는 기능적 프로그래밍에 대해 잘 알고 있습니다. 간단한 것부터 시작하십시오. 작업을 시작할 때 가장 복잡한 소프트웨어를 첫 번째 작업으로 수행 할 필요는 없습니다. 결국 복잡한 것들에 도달하지만 시간이 걸립니다.

FP를 디버깅하기가 어렵 기 때문입니다.