현대의 주류 프로그래밍 언어에서 람다 함수의 인기를 유발 한 것은 무엇입니까?

지난 몇 년 동안 익명 함수 (AKA 람다 함수)는 매우 널리 사용되는 언어 구성이되었으며 거의 ​​모든 주요 / 주류 프로그래밍 언어에서이를 도입했거나 향후 표준 개정판에이를 도입 할 계획입니다.

그러나 익명 함수는 수학과 컴퓨터 과학에서 매우 오래되고 잘 알려진 개념입니다 (수학자 인 Alonzo Church가 1936 년경에 발명했으며 1958 년 이래 Lisp 프로그래밍 언어에서 사용되었습니다 (예 : 여기 참조 )).

그렇다면 오늘날의 주류 프로그래밍 언어 (대부분 15 ~ 20 년 전에 시작된 언어)가 처음부터 람다 함수를 지원하지 않고 나중에 소개 한 이유는 무엇입니까?

그리고 지난 몇 년간 익명 함수가 대량으로 채택 된 계기는 무엇입니까? 이 현상을 시작한 특정 이벤트, 새로운 요구 사항 또는 프로그래밍 기술이 있습니까?

중요 사항

이 질문의 초점은 현대의 주류 언어 에 익명 함수 를 도입하는 것입니다. 또한 익명 함수 (블록)는 기능 언어가 아닌 스몰 토크에 존재하며 C와 Pascal과 같은 절차 적 언어에도 오랫동안 명명 된 함수가 존재한다는 점에 유의하십시오.

"기능적 패러다임의 채택 및 장점"에 대해 말함으로써 답변을 지나치게 일반화하지 마십시오. 이는 주제의 주제가 아니기 때문입니다.

함수형 프로그래밍에 대한 눈에 띄는 경향이 있거나 최소한 특정 측면이 있습니다. 익명 함수를 채택한 인기있는 언어 중 일부는 C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (2009 년 이후), Objective C ( blocks ) 동안 Java입니다. 8 언어에 람다 지원을 제공 합니다. 그리고 일반적으로 기능적으로 간주되지는 않지만 시작부터 또는 최소한 초기에 익명 함수를 지원하는 인기있는 언어가 있습니다.

모든 트렌드와 마찬가지로 이벤트를 발생시키는 단일 이벤트를 찾는 것은 아마도 시간 낭비 일 것입니다. 일반적으로 정량화 할 수없는 요소의 조합입니다. 2005 년에 출판 된 Practical Common Lisp 는 실제 언어 로서 Lisp에 새로운 관심을 불러 일으키는 데 중요한 역할 을했을 것입니다. Lisp는 대부분 학업 환경이나 매우 특정한 틈새 시장에서 만나는 언어 였습니다 . munificent가 그의 답변 에서 설명했듯이 JavaScript의 인기는 익명 함수에 새로운 관심을 가져 오는 데 중요한 역할을 했을 것 입니다.

다목적 언어에서 기능 개념을 채택하는 것 외에도 기능적 언어 (또는 대부분 기능적 언어)로 눈에 띄는 변화가 있습니다. Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007), 심지어 R (1993)과 같은 도메인 특정 언어는 강하게 따라온 것으로 보입니다. 그들이 소개 된 후. 일반적인 추세는 Scheme (1975)과 같은 구식 기능 언어와 명백히 Common Lisp에 새로운 관심을 불러 일으켰습니다.

더 중요한 하나의 사건은 업계에서 기능적 프로그래밍의 채택이라고 생각합니다. 나는 그것이 왜 그렇게 사용되지 않았는지 전혀 모른다. 그러나 90 년대 초 중반 중반에 기능 프로그래밍이 Erlang의 확산으로 시작하여 업계에서 위치를 찾기 시작한 것으로 보인다 . 항공 우주 및 하드웨어 설계에서 통신 및 Haskell의 채택 .

Joel Spolsky는 매우 흥미로운 블로그 게시물 인 The Perils of JavaSchools 를 작성했습니다. 그는 대학의 경향에 반대하여 언어를 배우기 어려운 다른 언어보다 Java를 선호한다고 주장합니다. 블로그 게시물은 기능적 프로그래밍과 관련이 없지만 주요 문제를 식별합니다.

거기에 논쟁이 있습니다. 지난 몇 년간 게으른 CS가 저학년 학자들과 함께 미국 대학에서 졸업 한 CS 전공이 얼마나 적 었는지에 대한 업계의 불만과 함께 비용이 많이 들었습니다. 엉덩이는 이력서를 평가하기 위해 "grep"을 사용하는 모집 자들이 좋아하는 것처럼 보이고, 무엇보다도 포인터 나 재귀를하는 두뇌의 일부없이 프로그래머를 진정으로 풀기에는 Java에 대해 충분히 어려운 것은 없습니다. 탈락률이 낮아지고 컴퓨터 과학 부서에는 더 많은 학생이 있고 더 많은 예산이 있으며 모든 것이 좋습니다.

나는 대학 시절에 그녀를 처음 만났을 때 Lisp를 얼마나 미워했는지 아직도 기억합니다. 그것은 확실히 거친 여주인이며, 즉시 생산성을 높일 수있는 언어는 아닙니다 (적어도 나는 할 수 없었습니다). Haskell (예 :)은 Lisp와 비교할 때 훨씬 친숙합니다. 많은 노력 없이도 완전한 바보처럼 느끼지 않고도 생산성을 높일 수 있으며 기능 프로그래밍으로 전환하는 데 중요한 요소가 될 수도 있습니다.

대체로 이것은 좋은 것입니다. 몇몇 다용도 언어는 이전에 대부분의 사용자에게 비 전적으로 보일 수있는 패러다임 개념을 채택하고 있으며 주요 패러다임 사이의 격차는 좁아지고 있습니다.

관련 질문 :

• 기능적 프로그래밍이 증가하고 있습니까?
• 업계에서 기능 프로그래밍이 더 인기가없는 이유는 무엇입니까? 지금 잡을까요?
• 함수형 프로그래밍이 아직 인수되지 않은 이유는 무엇입니까?

더 읽을 거리 :

• 기능 프로그래밍 언어, 특히 Common Lisp 및 Lisp Dialect Clojure가 인기를 되 찾는 이유는 무엇입니까?
• 함수형 프로그래밍 : 함수형 프로그래밍의 인기가 상승한 원인은 무엇입니까?
• 프로그래밍 언어가이를 수행 할 수 있습니까?
• 함수형 프로그래밍이 필요한 이유 왜 하스켈인가?

함수형 프로그래밍의 인기가 Javascript의 성장과 확산과 얼마나 비슷한 지에 대한 흥미로운 생각입니다. Javascript는 기능적 프로그래밍 스펙트럼에 따라 많은 급진적 인 기능을 가지고 있는데, 그 당시 (1995)는 주류 프로그래밍 언어 (C ++ / Java)에서 그다지 인기가 없었습니다. 유일하게 클라이언트 측 웹 프로그래밍 언어로 주류에 주입되었습니다. 갑자기 많은 프로그래머가 단순히 Javascript를 알아야했기 때문에 함수형 프로그래밍 언어 기능에 대해 알아야했습니다.

Javascript가 갑자기 등장하지 않았다면 인기있는 기능 언어 / 기능이 얼마나 될지 궁금합니다.

자바 스크립트와 DOM 이벤트 핸들러는 프로그래머의 수백만 것을 의미 했다 수행하려면 적어도 첫 번째 클래스 함수에 대해 조금 배울 수 있는 웹 상호 작용을.

거기에서 익명 함수로 의 비교적 짧은 단계 입니다. JavaScript는 가까이에 있지 않기 때문에 this클로저에 대해서도 배울 것을 강력히 권장합니다. 그리고 당신은 황금입니다. 당신은 어휘 범위를 둘러싸는 익명의 일급 함수를 이해합니다.

편한 후에는 사용하는 모든 언어로 원합니다.

확실히 유일한 요소는 아니지만 Ruby의 인기를 지적하겠습니다. 이것은 이미 보드에있는 6 가지 답변 중 더 중요하다고 말하지는 않지만 많은 일이 한 번에 발생했으며 모두 열거하는 것이 유용하다고 생각합니다.

루비는 기능적 언어가 아니며 ML과 같은 것을 사용할 때 람다, 찌르기 및 블록이 어색해 보이지만 사실은 히퍼를 위해 Java 및 PHP를 피하는 젊은 프로그래머 세대에게 매핑 및 축소 개념을 대중화했습니다. 목초지. 여러 언어로 된 람다는 다른 무엇보다 방어적인 움직임으로 보입니다 ( "Stick around! We 've have them !!

그러나 블록 구문과 .each, .map, .reduce 등과 통합 된 방식은 실제로 코 루틴처럼 행동하는 구문 구조 인 경우에도 익명 함수의 아이디어를 대중화했습니다. 또한 proc을 통해 proc로 쉽게 변환하여 기능 프로그래밍을위한 게이트웨이 약물로 만들 수 있습니다.

JavaScript를 작성하는 Ruby on Rails 프로그래머는 이미 가벼운 기능적 스타일로 작업을 시작했다고 주장합니다. 프로그래머 블로깅, Reddit, 해커 뉴스 및 스택 오버플로의 발명과 동시에 아이디어가 뉴스 그룹 시대보다 인터넷을 통해 빠르게 퍼졌습니다.

TL : DR : Ruby, Rails, JavaScript, 블로그 및 Reddit / Hacker News / Stack Overflow는 기능적 아이디어를 대중 시장에 내놓았 기 때문에 모든 사람들이 기존 언어로 추가 결함을 방지하기를 원했습니다.

으로 야 니스는 지적하지 않고 이전했다 언어로 상위 기능의 채택을 영향을 미친 요인은 여러 가지가있을 수 있습니다. 그가 가볍게 만지는 중요한 항목 중 하나는 멀티 코어 프로세서의 확산과 함께 더 많은 병렬 및 동시 처리에 대한 요구입니다.

기능 프로그래밍의 맵 / 필터 / 축소 스타일은 병렬 처리에 매우 친숙하므로 프로그래머가 명시 적 스레딩 코드를 작성하지 않고도 여러 코어를 쉽게 사용할 수 있습니다.

조르지오 (Giorgio)가 지적한 바와 같이, 함수형 프로그래밍은 고급 함수보다 더 많은 기능이있다. 함수, 맵 / 필터 / 감소 프로그래밍 패턴 및 불변성은 함수형 프로그래밍의 핵심입니다. 이러한 것들이 함께 있으면 병렬 및 동시 프로그래밍의 강력한 도구가 만들어집니다. 고맙게도 많은 언어는 이미 불변성의 개념을 지원하고 있으며, 그렇지 않은 경우에도 프로그래머는 불변으로 간주하여 라이브러리와 컴파일러가 비동기 또는 병렬 작업을 생성하고 관리 할 수 ​​있습니다.

언어에 고차 함수를 추가하는 것은 동시 프로그래밍을 단순화하는 중요한 단계입니다.

최신 정보

Loki가 지적한 문제를 해결하기 위해 몇 가지 더 자세한 예를 추가하겠습니다.

위젯 콜렉션을 순회하여 새 위젯 가격 목록을 작성하는 다음 C # 코드를 고려하십시오.

List<float> widgetPrices;
    float salesTax = RetrieveLocalSalesTax();
foreach( Widget w in widgets ) {
    widgetPrices.Add( CalculateWidgetPrice( w, salesTax ) );
}

대규모 위젯 모음이나 계산 집약적 인 CalculateWidgetPrice (Widget) 메소드의 경우이 루프는 사용 가능한 코어를 잘 활용하지 못합니다. 다른 코어에서 가격 계산을 수행하려면 프로그래머가 스레드를 명시 적으로 작성 및 관리하고, 문제를 해결하고, 결과를 함께 수집해야합니다.

일단 고차 함수가 C #에 추가되면 해결책을 고려하십시오.

var widgetPrices = widgets.Select( w=> CalculateWidgetPrice( w, salesTax ) );

foreach 루프가 구현 방법을 숨기고 Select 메서드로 이동되었습니다. 프로그래머에게 남아있는 것은 각 요소에 적용 할 기능을 선택하도록 알려주는 것입니다. 이를 통해 Select 구현은 프로그래머의 개입없이 모든 동기화 및 스레드 관리 문제를 처리하면서 병렬로 계산을 실행할 수 있습니다.

그러나 물론 Select는 병렬로 작동하지 않습니다. 그것이 불변성이 생긴 곳입니다. Select 구현은 제공된 함수 (위의 CalculateWidgets)에 부작용이 없음을 알지 못합니다. 이 기능은 Select 및보기 동기화 외부에서 프로그램 상태를 변경하여 모든 것을 차단할 수 있습니다. 예를 들어,이 경우 salesTax의 값이 잘못 변경 될 수 있습니다. 순수 기능 언어는 불변성을 제공하므로 선택 (맵) 기능은 상태가 변경되지 않음을 확인할 수 있습니다.

C #은 Linq의 대안으로 PLINQ를 제공하여이를 해결합니다. 그것은 다음과 같습니다

var widgetPrices = widgets.AsParallel().Select(w => CalculateWidgetPrice( w, salesTax) );

어떤 코어를 명시 적으로 관리하지 않고도 시스템의 모든 코어를 최대한 활용할 수 있습니다.

나는 많은 답변에 동의하지만 흥미로운 것은 람다에 대해 배우고 뛰어 들었을 때 다른 사람들이 언급 한 이유가 아니라는 것입니다.

대부분의 경우 람다 함수는 코드의 가독성을 향상시킵니다. 함수 포인터 (또는 함수 또는 대리자)를 허용하는 메서드를 호출 할 때 람다 전에 해당 함수의 본문을 다른 곳에 정의해야하므로 "foreach"구문이있을 때는 독자가 다른 곳으로 이동해야합니다 코드의 일부로 각 요소로 정확히 무엇을하려고했는지 확인하십시오.

요소를 처리하는 함수의 본문이 몇 줄에 불과하면 코드를 읽을 때 기능이 변경되지 않지만 독자가 앞뒤로 이동할 필요가 없기 때문에 익명 함수를 사용합니다. 전체 구현은 다음과 같습니다. 바로 그 앞에서.

많은 기능 프로그래밍 기술과 병렬화는 익명 함수없이 달성 될 수 있습니다. 그냥 정기적으로 선언하고 필요할 때마다 참조를 전달하십시오. 그러나 람다 코드 작성의 용이성과 코드 판독 용이성이 크게 향상되었습니다.

여기에서 최근의 역사에 약간 관여 한 한 가지 요소는 Java와 .NET에 제네릭을 추가 한 것이라고 생각합니다. 이는 자연스럽게 Func < , > 및 기타 강력한 형식의 계산 추상화 (작업 < >, 비동기 < > 등)로 이어집니다.

.NET 세계에서는 FP를 지원하기 위해 이러한 기능을 정확하게 추가했습니다. 이로 인해 함수형 프로그래밍, 특히 C # 3.0, LINQ, Rx 및 F #과 관련된 일련의 언어 작업이 시작되었습니다. 이러한 발전은 다른 생태계에도 영향을 미쳤으며 오늘날에도 C #, F # 및 TypeScript에서 계속되고 있습니다.

그것은 물론 MSR에서 Haskell이 일하는 것을 돕는다. :)

물론 다른 많은 영향도 있었으며 (JS는 분명히)이 단계는 다른 많은 영향을 받았지만, 이러한 언어에 제네릭을 추가하면 소프트웨어 세계의 많은 부분에서 90 년대 후반의 엄격한 OO 정통성을 깨뜨리는 데 도움이되었고 개방에 도움이되었습니다. FP의 문.

돈 심

ps F #은 2005 년이 아니라 2003 년이었습니다. 2005 년까지 1.0에 도달하지 않았다고 말할 수 있습니다. 또한 2001-02 년에 Haskell.NET 프로토 타입도 만들었습니다.

이것은 심각한 답변이 아닙니다. 그러나이 질문은 제임스 이리 (James Iry) 의 다음과 같은 문구를 포함 하는 간단하고 불완전하며 대부분 잘못된 프로그래밍 언어의 역사에 관한 멋진 유머러스 한 글을 상기시켜주었습니다 .

"Lambdas는 Java가 없어서 인기를 얻을 때까지 상대적인 모호함으로 강등됩니다."

내가 본 것에서 대부분의 답변은 왜 함수형 프로그래밍이 일반적으로 다시 돌아 왔고 그것이 주류가되게했는지 설명하는 데 집중합니다. 그러나 이것이 실제로 익명 함수에 관한 질문에 답하지 않는 이유와 왜 갑자기 인기를 얻었는지 느꼈습니다.

실제로 인기를 얻은 것은 폐쇄 입니다. 대부분의 경우 클로저는 변수를 전달하는 throw-away 함수이므로 익명 함수 구문을 사용하는 것이 좋습니다. 실제로 일부 언어에서는 클로저를 만드는 유일한 방법입니다.

폐쇄가 인기를 얻은 이유는 무엇입니까? 그들은 때문에 콜백 함수를 만들 때 이벤트 기반 프로그래밍에 유용 . 현재 JavaScript 클라이언트 코드를 작성하는 방법입니다 (실제로 GUI 코드를 작성하는 방법 임). 이벤트 중심 패러다임으로 작성된 코드는 일반적으로 비동기식이며 블로킹하지 않기 때문에 현재는 시스템 코드뿐만 아니라 매우 효율적인 백엔드 코드를 작성하는 방법이기도합니다 . 백엔드의 경우 C10K 문제에 대한 솔루션으로 인기를 얻었습니다 .

그 이유는 객체 지향 프로그래밍의 핵심 (객체로 변경 상태 캡슐화)이 더 이상 적용되지 않는 동시 및 분산 프로그래밍의 보급이 증가하고 있기 때문입니다. 분산 시스템의 경우 공유 상태 가 없고 (해당 개념의 소프트웨어 추상화가 누출 됨) 동시 시스템의 경우 공유 상태에 대한 액세스를 올바르게 동기화하는 것이 번거롭고 오류가 발생하기 쉬운 것으로 입증되었습니다. 즉, 객체 지향 프로그래밍의 주요 이점 중 하나는 더 이상 많은 프로그램에 적용되지 않으므로 객체 지향 패러다임이 이전보다 훨씬 덜 유용합니다.

반대로 기능적 패러다임은 변경 가능한 상태를 사용하지 않습니다. 따라서 기능적 패러다임과 패턴을 통해 얻은 경험은 동시 및 분산 계산으로보다 즉각적으로 이전 할 수 있습니다. 그리고 업계는 이제 바퀴를 재창조하기보다는 이러한 요구 사항을 해결하기 위해 이러한 패턴과 언어 기능을 차용합니다.

내 € 0.02를 추가 할 수 있지만, 개념을 소개하는 JavaScript의 중요성에 동의하지만 동시 프로그래밍보다 현재 비동기식 프로그래밍 방식을 탓할 것이라고 생각합니다. 비동기 호출 (웹 페이지에 필요)을 수행 할 때 간단한 익명 함수가 매우 유용하여 모든 웹 프로그래머 (즉, 모든 프로그래머)가이 개념에 매우 익숙해 져야했습니다.

익명 함수 / 람다와 비슷한 또 다른 오래된 예는 Algol 60의 이름 별 호출입니다 . 그러나 이름 별 호출은 실제 기능을 전달하는 것보다 매크로를 매개 변수로 전달하는 것에 더 가깝습니다. 결과적으로 이해하십시오.

내가 아는 한, 최고의 조상.

• 2005 : Javascript는 가장 최근에 람다가 포함 된 고차 프로그래밍을 주류로 가져 왔습니다. underscore.js 및 jquery 와 같은 특히 라이브러리 . 이 라이브러리 중 첫 번째 라이브러리 중 하나는 jquery보다 약 1 년 앞서서 prototype.js 입니다. 프로토 타입은 Ruby의 Enumerable 모듈을 기반으로합니다.
• 1996 : Ruby의 Enumerable 모듈 은 스몰 토크의 수집 프레임 워크에서 영감을 얻었습니다. 많은 인터뷰에서 Matz가 언급 한 바와 같이
• 1980 : 스몰 토크는 많은 고차 프로그래밍을 사용하고 고차 프로그래밍 (예 : GNU 스몰 토크의 이터 러블 클래스 ) 을 많이 사용하는 콜렉션 API를 제공합니다 . 관용적 스몰 토크 코드에서는 for 루프는없고 고차원 열거 만 찾을 수 있습니다. 불행히도 1998 년 Smalltalk의 수집 프레임 워크가 Java로 포팅 될 때 Java는 고차원 열거가 생략되었습니다. 그것이 앞으로 10 년 동안 주류에서 고차 프로그래밍이 단계적으로 폐지 된 방식입니다! 스몰 토크에는 많은 조상들이 있지만 OP의 질문과 관련이있는 LISP는 우리를…
• 1958 : LISP의 핵심은 고차 프로그래밍입니다.

익명의 함수는 이름을 지정하는 것이 어렵 기 때문에 좋으며 한 번에 함수를 사용하는 경우 이름이 필요하지 않습니다.

Lambda 함수는 최근까지만 대부분의 언어가 클로저를 지원하지 않았기 때문에 주류가되었습니다.

Javascript 가이 주류를 밀 었다고 제안합니다. 병렬 처리를 표현할 방법이없는 범용 언어이며 익명 함수는 콜백 모델을 쉽게 사용할 수 있습니다. Ruby와 Haskell과 같은 인기있는 언어가 기여했습니다.