나는 항상 C가 임베디드 시스템에 사용 되는 언어 또는 최대 속도로 실행 해야하는 언어 라고 들었습니다 . 나는 포인터 산술을 좋아하지 않고 언어가 어셈블러보다 약간 렁이기 때문에 C에 대한 애정을 개발하지 못했습니다.
반면에 ML 언어는 기능적이고 가비지 수집 언어이며 OCaml도 객체 모델을 가지고 있지만 C만큼 빠른 것으로 유명합니다. 코드는 고성능 응용 프로그램을 작성하는 데 필요한 속도를 유지합니다.
특히 OCaml은 임베디드 장치, 그래픽 드라이버, 운영 체제 등과 같이 C가 일반적으로 사용되는 모든 곳에서 사용할 수 있습니다. 사용했습니다.
이것은 주관적인 질문이지만 왜 OCaml과 ML의 다른 언어가 그토록 모호한 반면 C와 다른 언어가 인기를 얻었습니까?
답변:
첫 번째 대답은 언어가 왜 대중화되는지 아무도 모른다는 것이며, 다른 말을하는 사람은 대담하거나 의제를 가지고 있습니다. (언어 가 인기를 얻지 못하는 이유를 쉽게 식별 할 수는 있지만 또 다른 질문입니다.)
그 면책과 함께, 다음은 가장 암시적인 요점입니다.
최초의 성숙한 C 컴파일러는 1974 년에 등장했습니다. 최초의 성숙한 OCaml 컴파일러는 1990 년대 후반에 등장했습니다. C의 헤드 스타트는 25 년이다.
C는 가장 큰 "킬러 앱"인 Unix와 함께 제공되었습니다. 오랫동안 전 세계의 모든 CS 부서에는 Unix가 있어야했으며, 이는 모든 강사와 CS 과정을 수강하는 모든 사람들이 C에 노출 될 기회를 가졌음을 의미합니다. OCaml과 ML은 여전히 첫 킬러 앱을 기다리고 있습니다. (MLdonkey는 멋지지만 Unix는 아닙니다.)
C는 틈새 시장을 잘 채우므로 시스템 프로그래밍 에만 사용 되는 다른 저수준 언어가 절대 없을 것 입니다. HOPL II의 C 역사에 대한 Dennis Ritchie의 논문을 읽어보십시오. OCaml의 틈새 시장이 무엇인지 명확하지 않으며 Standard ML의 틈새 시장이 조금 더 명확합니다. 따라서 Caml과 ML에는 경쟁자가 거의없는 반면 C는 유일한 경쟁사 (BLISS)를 죽였습니다.
C의 가장 큰 장점 중 하나는 비용 모델 이 매우 예측 가능하다는 것입니다. C 코드의 작은 조각을 쉽게 볼 수 있으므로 해당 코드를 실행하기 위해 수행 할 기계 작업에 대한 정확한 아이디어를 즉시 얻을 수 있습니다. 특히 메모리 할당 때문에 OCaml의 비용 모델이 훨씬 명확하지 않습니다.훨씬 덜 명시 적이며 전체 메모리 할당 비용 (가비지 수집 중에 발생하는 할당 비용 + 비용과 동일)은 객체의 수명 및 다른 객체를 참조하는 객체와 같은 응급 속성에 따라 달라집니다. 결과적으로 성능을 예측하기가 어렵고 사실 이후에도 분석하기가 어렵습니다. (OCaml의 메모리 프로파일 링 도구는 꼭 필요한 도구가 아닙니다.) 결과적으로 OCaml은 임베디드 시스템과 같이 성능을 예측할 수 있어야하는 응용 프로그램에는 적합하지 않습니다.
C는 표준 및 많은 컴파일러가있는 언어입니다. OCaml은 소프트웨어 아티팩트입니다. 유일한 컴파일러는 단일 소스에서 온 것이며 컴파일러 는 표준입니다. 그리고 그 표준은 모든 릴리스마다 바뀝니다. 안정성과 이전 버전과의 호환성을 중시하는 사람들에게 단일 소스 언어는 용납 할 수없는 위험을 나타낼 수 있습니다.
중간 정도의 학부생 컴파일러 과정과 많은 지속성을 가진 사람은 어느 정도 작동하고 적절한 성능을 가진 C 컴파일러를 작성할 수 있습니다. OCaml 또는 ML의 구현을 시작하려면 훨씬 더 많은 교육이 필요하고 순진한 C 컴파일러에 필적하는 성능을 얻으려면 훨씬 더 많은 작업이 필요합니다. 즉, OCaml과 같은 언어를 사용하는 애호가가 훨씬 적으므로 커뮤니티를 악용하는 방법에 대한 깊은 이해가 어렵습니다.
OCaml의 문제점은 "즉시 사용하기에는"너무 유용하지 않다는 것입니다. 사람들이 언어를 사용하는 최종 이유는 필요한 라이브러리가 있기 때문입니다. 그러나 "즉시 사용 가능한 것"이 없으면 아무도 라이브러리를 작성해야한다는 것을 깨닫기 위해 프로젝트에 충분히 들어 가지 않습니다. 결과적으로 라이브러리가없는 언어가되어 "실제 앱"을 작성하기가 어렵습니다.
나는 이것이 OCaml이 겪는 문제라고 생각합니다. 프로그래밍 언어가 있기 때문에 아무도 "실제 프로젝트"를 시작하지 않아도됩니다. 예, 2와 2를 더하고 결과를 인쇄 할 수 있습니다. 그 결과 대부분 학계 이탈자 (저자가 박사 학위를 받았고 이동) 인 라이브러리의 모음으로 프로그래머를 연습하는 데 너무 도움이되지 않습니다.
( "배터리 포함"과 같은 프로젝트를 통해이를 변경하는 작업이 진행되고 있음을 알고 있습니다. 5 년 후에 다시 오면 OCaml이 더 인기가있을 것입니다.)
이 규칙에는 몇 가지 예외가 있습니다. 자바는 도서관없이 시작했지만 썬은 사람들에게 모두 집안으로 쓰라고 돈을 지불 한 다음 그 책을 내놓았다. Java 인증, Java 전용 하드웨어, Java 서적, Java 클래스 등. 심지어 프로그래밍 학습에 사용하기에 매우 좋은 언어는 아니지만 대부분의 대학에서 독점적으로 가르치도록 설득했습니다.
결과는 인기였습니다. 돈은 많은 문제를 해결할 수 있습니다.
기능적 언어 영역에서 Haskell이 인기를 얻고 있음을 알 수 있습니다. 나는 대부분의 인기는 유용한 도서관을 쓰는 돈과 같은 사람들에 의한 것이라고 생각하며, 언어를 마케팅하는 것을 멈추지 않습니다. 매일 Reddit 프로그래밍에 관한 Haskell 기사가 몇 개 있습니다. 이것은 사람들이 "하스켈을 시도 할 것"이라고 최종적으로 결정할 때까지 사람들의 마음에 붙어 있습니다. 그렇게하면 웹 프레임 워크, 객체 데이터베이스, OpenGL 라이브러리 및 XML 처리 라이브러리와 같은 유용한 것들을 보게됩니다. 이것은 그들이 실제로 "지금 바로"유용한 것을 할 수 있다는 것을 의미합니다. 따라서 생산성과 생산성에 대한 가능성 사이에서 Haskell은 많은 인기를 얻었습니다.
CL은 Haskell과 동일한 라이브러리를 많이 가지고 있으며 거의 빠르지 만 아무도 그것에 대해 이야기하지 않으므로 "죽은 느낌"입니다. 실제로 #lisp는 #haskell보다 훨씬 조용하지만 Lisp는 여전히 많은 라이브러리가있는 매우 생산적인 언어입니다. 다른 언어에는 SLIME이 없습니다. 그러나 마케팅은 매우 중요하며 Haskell은 Lisp 또는 OCaml보다 더 잘 수행하며 동일한 사용자 기반을두고 경쟁합니다.
마지막으로, 어떤 사람들은 프로그래밍을 "받지"않을 것이므로 그들의 정신 모델을 깨는 것 (변수는 값을 가진 상자, 코드는 위에서 아래로 실행)은 언어를 사용하지 않도록합니다. 이 유형의 프로그래머는 프로그래밍 인구의 비율이 높기 때문에 Lisp, Haskell 및 OCaml과 같은 추상 언어의 사용자 기반을 더욱 제한합니다.
나는 언어로서 OCaml 을 많이 좋아 합니다. 그러나...
도구 지원은 존재하지 않습니다. 디버거는 정상적으로 작동하지만 Windows에서는 작동하지 않으며 (마지막으로 확인한) 사용할 수있는 개발 도구가 많지 않습니다.
타입 시스템이 때때로 너무 강하다. 타입 추론이 어떻게 작동하는지 또는 일반적으로 ML 타입 시스템을 이해하지 못하는 사람에게, 부동 소수점에 정수를 추가 할 수 없다는 사실은 바로 큰 손실입니다.
표준 라이브러리는 때때로 일관성이없는 느낌을 가질 수 있습니다.
객체 모델은 다소 고정되어있는 것으로 보이며 표준 라이브러리는 거의 사용하지 않고 모듈 기반 라이브러리를 선택합니다.
기본적으로 "광택 된"느낌이 들지 않는 언어에 상당하고 언어를 집어 들고 마음에 드는지를 결정하려고 할 때 매우 중요한시기에 사람들을 멀어지게하는 다른 많은 것들이 있습니다.
가장 중요한 유산은 다른 ML 방언과 함께 다른 기능적 언어에 매우 큰 영향을 미쳤다는 것입니다. 현재 세대 기능 언어의 대부분은 ML 방언에서 최고의 요소를 취하고 일부 성가심을 개선합니다.
임베디드 시스템에는 종종 속도와 결정 성이라는 두 가지가 필요합니다. OCaml은 속도를 제공 할 수 있지만 가비지 컬렉터가 있다는 사실은 본질적으로 비 결정적이며 간단한 시스템으로는 불가능합니다.
이것은 약간의 사과 대 오렌지 비교입니다. OCaml은 상당히 젊은 언어이며 [1] 주류로 밀어 넣기위한 진지하고 지속적인 노력은 없었습니다 (Microsoft의 현재 F # 작업 제외). C와는 달리 가장 널리 지원되고 모방 된 엔터프라이즈 운영 체제 (예 : UNIX) 의 언어 가 아닙니다 . Java와 달리, 차세대 컴퓨팅 플랫폼으로 추진하고있는 주요 기업은 없었습니다. Perl, Python 및 Ruby와 달리, 영향력이 큰 영향력을 행사하는 틈새 시장에는 적용되지 않았습니다. 즉, 틈새 시장은 프로그래밍 언어이며 자동화 된 추론 연구 (웹 개발과 비교할 때 매우 유명하지는 않습니다)입니다. 따라서 그것은 인기가 없습니다.
[1] 공평하게, 원래 ML 언어는 70 년대 이래로 존재 해 왔습니다. 그러나 OCaml은 1996 년까지 나타나지 않았으며 표준 ML 라이브러리를 상속하지 않았습니다. 실제로 C, C ++, Java, Python, Haskell 또는 Ruby보다 더 어린 언어입니다.
OCaml 커뮤니티는 응용 프로그램 개발을 용이하게하는 크고 안정적인 표준 라이브러리 (오늘 OCaml과 함께 제공되는)를 개발하지 못했습니다. 문제를 해결하기위한 몇 가지 시도가 있지만 누락 된 사항을 보려면 Python 또는 Ruby를 살펴보십시오. OCaml은 XML, 네트워킹, 데이터 계산 등과 같은 고급 표준 모듈과 상호 작용 해야하는 알고리즘 문제를 해결하려는 경우 훌륭한 언어입니다.
문제의 일부는 모듈이 OCaml에 의해 파일에 매핑되는 방식입니다. 개념적으로 모든 * .ml 파일은 동일한 네임 스페이스에 있으며 디렉토리는 의미가 없습니다. 이것은 공동체가 도서관을 발전시키기 어렵게 만든다. 컴파일러가 디렉토리 계층을 모듈 계층으로 매핑하면 표준 라이브러리가 발전 할 가능성이 높아집니다. 그러나 핵심 컴파일러 개발자는 상당한 노력을 기울여야합니다. (모듈 포장에 대해 알고 있지만 이것이 문제라고 생각합니다.)
또 다른 라이브러리 문제는 컴파일러 릴리스 간의 이진 호환성입니다. 컴파일러 업그레이드 후에 모든 라이브러리 코드를 다시 컴파일해야한다고 말하는 것이 안전합니다. 이로 인해 모듈 또는 라이브러리의 이진 릴리스를 제공하기가 어렵습니다.
아마도 너무 많은 사람들이 유형에 대한 이상하고 혼란스러운 이론적 인 것들에 대한 소개의 일부로 ML을 배웠기 때문일 것입니다. 그것이 저에게 일어난 일입니다.
ML과 스몰 토크가 같은 시간에 나타났습니다. 스몰 토크 는 차갑게 보였고 , OO의 목적과이 환경에서 예쁘고 인터랙티브 한 물건을 만드는 방법을 즉시 이해할 수있었습니다. ML은 내가하고 싶었던 것과 관련이없는 추상적 수학적 일에 관한 것이었다. 그리고 C와는 달리 16 비트 마이크로에서 빠른 게임을 만들 수 있다고 약속하지 않았습니다.
물론 이것은 매우 불공평하고 주관적입니다. 그러나 그것은 대부분의 사람들에게 진정한 이야기 일 것입니다.
요즘 나는 그 질문이 될 것이라고 생각합니다. 이제 유형에 대해 이상하고 혼란스러운 이론적 인 것들을 알아야한다고 생각합니다. 왜 Haskell 또는 Erlang보다 ML을 선택해야합니까?
주요 문제는 실제 표준 라이브러리가 없다는 것입니다. 따라서 OCaml Batteries Included 프로젝트 는 상황을 크게 개선 할 것으로 예상됩니다. 며칠 내에 베타 단계에 들어가기로되어 있으므로 1 년 정도 후에 다시 질문해야합니다.
나는 Windows 지원이 열악하고 학습 곡선이 가파르고 슬림 한 표준 라이브러리가 과거 OCaml의 채택을 방해했지만 OCaml에 대한 튜토리얼 정보 (예 : 서적)가 Java와 같은 주류 언어와 비교할 때 상당히 부족했다는 데 동의합니다.
또한 OCaml과 같은 언어를 아는 사람들은 매우 이질적입니다. 웹 프로그래머들 중 1,000 명 중 1 명이 OCaml에 대해 들어봤을 것입니다. 케임브리지 대학교에서 과학 컴퓨팅을하는 사람들 중 내가 아는 사람들의 약 90 %가 OCaml에 유창했습니다. 사실, 나는 친구들 사이에서 OCaml을 배우는 마지막 사람 중 하나였습니다. 심지어 256 CPU 슈퍼 컴퓨터에서 OCaml을 실행했습니다 ...
또한 이러한 문제가 빠르게 해결되고 있다고 언급해야합니다. OCaml은 최근 Ocsigen과 같은 프로젝트를 통해 웹 프로그래밍을 위해 새롭게 발명했으며 이미 그 맥락에서 적어도 두 가지 주요 산업 성공 사례를 가지고 있습니다. OCaml에 대한 또 다른 새로운 책이 있습니다. 이 커뮤니티는 베타 버전으로 출시되어 환상적으로 보이는 "배터리 포함"이라는 포괄적 인 표준 라이브러리를 공동 작업하고 있습니다. 멀티 코어 친화적 인 OCaml 버전이 출시 될 예정입니다. 최신 버전의 OCaml에는 게으른 패턴 및 동적으로로드 된 기본 코드 OCaml 라이브러리와 같은 많은 새로운 기능이 포함되어 있습니다.
문제의 일부는 함수형 프로그래밍이 대부분의 사람들이 생각할 수있는 자연스러운 방법이 아니라는 것입니다 (그리고 저는 이것을 함수형 프로그래밍에 큰 관심을 갖고 감사하는 사람이라고 말합니다). 오늘날 대다수의 프로그래머가 절차 적 프로그래밍을 배우기 시작했기 때문에 (대부분의 인기있는 OOP 언어는 여전히 절차 적이라는 점에서) 기능적 언어는 처음에 적응하기가 어렵다는 사실에 의해 더욱 복잡해집니다.
대학을 시작할 때 이미 합리적인 양의 BASIC, C ++ 및 Java와 약간의 파스칼 및 x86 어셈블리 언어를 알고있었습니다. 나는 전문가가 아니었지만 모든 프로그래밍 언어가 기본적으로 약간 다른 구문으로 동일하다는 (약간 순진한) 결론에 도달했습니다. 프로그래밍 과정에 대한 소개는 ML을 사용하여 그 개념을 신속하게 비난했습니다. 프로그래밍 경력의 그 단계에서 ML을 둘러 보는 데 어려움을 겪었고 실제로 기능적 프로그래밍의 요점을 보지 못했습니다. 기능적 접근 방식의 이점을 실제로 이해하려면 절차 적 프로그래밍의 일부 문제에 대해 약간의 경험이 필요하다고 생각합니다.
ML 강사는 종종 문제를 재귀 적으로 표현하는 것이 루프 나 다른 절차 적 개념을 사용하는 것보다 '자연스럽고 쉽다'고 주장했습니다. 나는 그 주장에 확신을 가지지 않았으며 여전히 그것을 사지 않았다. 재귀 함수는 문제에 대해 특히 우아하고 간결한 솔루션을 제공 할 수 있지만 여전히 문제에 대해 생각하는 것은 부 자연스러운 방법입니다. 아마도 당신이 매우 강한 수학적 배경을 가지고 있다면 더 직관적 인 것처럼 보이지만 대부분의 사람들이 재귀 적으로 생각하기가 쉽지 않다고 생각합니다. 함수형 프로그래밍 패러다임에 대한 재귀 함수의 중심성을 고려할 때 이것이 함수형 언어의 인기가 떨어지는 이유라고 생각합니다.
언어 인기에 대한 피드백 효과도 있습니다. 프로그래밍을 시작할 때 그래픽 효과와 게임을 프로그래밍하는 방법을 알고 싶었습니다. 약간의 BBC BASIC과 그 이후의 QBASIC을 배우고 난 후에 데모 장면과 게임 프로그래머가 사용하는 가장 일반적인 언어가 무엇인지 자연스럽게 조사하고 C ++ 및 x86 어셈블리 학습에 대해 설정했습니다. 오늘날 일부 새로운 프로그래머는 웹 응용 프로그램을 생성하는 방법을 알고 싶어하므로 PHP, Ruby 또는 C #을 배우는 데 중점을 둘 것입니다. 자발적인 초보자 프로그래머에게는 'X와 같은 프로그램을 배우는 가장 좋은 언어는 무엇인가'에 대한 대답이 'Ocaml'인 응용 분야가 거의 없습니다.
Ocaml의 제한된 인기 (성숙한 라이브러리, 디버거, IDE 등 부족)에 대한 여러 가지 실질적인 이유는 Microsoft의 F #을 일급 .NET 언어로 공식적으로 지원함으로써 해결됩니다. F #이 함수형 프로그래밍에서 더 높은 수준의 인기를 얻는 데 도움이되는지 확인하는 것이 흥미로울 것입니다.
문제의 핵심은 정치라고 생각합니다. Ocaml 개발자는 주로 연구에 관심이 있으며 풍부한 라이브러리를 제공하고 유지할 수있는 리소스가 없습니다. 그러나 이들은 또한 이러한 리소스를 보유한 커뮤니티에 제품에 대한 제어 권한을 공개하지 않으려하는데,이 문제를 해결하기위한 여러 가지 시도는 존재하지 않는 협력 및 타사 라이브러리의 자금 지원에 의존했으며 이러한 시도는 실패했습니다. Ocaml 개발자가 태도를 바꾸지 않으면 같은 이유로 배터리가 고장납니다.
Ocaml을 사용하여 제품을 개발하고 간단한 규칙이 있습니다. 타사 코드에 대한 의존성을 최소화하십시오. 타사 항목이 유용한 경우 가능하면 소스 코드를 패키지에 직접 통합하십시오. 예를 들어 OCS Scheme과 Dypgen은 Felix 파서의 필수 부분이므로 소스에 복사되어 일부를 제어 할 수 있습니다. 제어는 다소 환상적입니다 (Dypgen은 너무 복잡하기 때문에 유지할 수는 없지만 적어도 우리는 효과가 있다고 생각되는 사본을 가지고 있습니다 :)
라이센스가 제한적이므로 배터리를 사용하지 않으므로 소스를 복사 할 수 없으며, 독립형 제품으로서 장기적으로 사용하기 어렵다는 확신이 없습니다. Ocaml의 표준 배포판에 직접 통합됩니다.
C ++ 세계에서는 Boost를 사용하는 것이 좋습니다.이 라이브러리는 표준의 일부가 아닌 타사 라이브러리이지만 커뮤니티가 많이 지원되며 실제로 표준 개발 프로세스와 완벽하게 동기화됩니다. Boost에서 개발하고 테스트 한 아이디어는 표준화 될 수있는 기존의 관행이되었으며 표준 프로세스는 커뮤니티 참여가 가능할 정도로 개방적입니다.
Ocaml은 훌륭한 제품이기 때문에 실제로 인기를 얻었지만 주류 언어가 되기에는 충분하지 않습니다. 자바는 성가시다. 수십억 달러의 마케팅 및 라이브러리 개발로 인기를 얻었지만 결국 생존하려면 커뮤니티에 공개해야했다.
IMHO, 나는 OCaml의 큰 문제는 언어 (대단한)가 아니라 그것을 개발하는 사람들과 결과적으로 그의 라이센스에 있다고 생각합니다.
http://caml.inria.fr/ocaml/license.en.html
그들은 컴파일러에 Q Public 라이센스를 사용합니다! 예, Qt 라이브러리에 사용 된 ex-Trolltech 라이센스! 그러한 라이센스로 공헌하는 것을 잊어라.
7-8 년 전에 Language Shootout ( http://shootout.alioth.debian.org/ ) 을 확인했다면 OCaml은 실행 속도 측면에서 C 및 C ++보다 낫습니다. 그 동안 다른 언어 (하스켈과 같은)는 더 나은 컴파일러를 얻었고 (다른 커뮤니티 접근 방식으로 인해) OCaml 실행 속도는 과거처럼 그리 좋지 않습니다.
머지 않아 OCaml을 사용하지 않을 것입니다. 정말 훌륭한 해커가 REALLY 오픈 소스 라이센스가있는 OCaml 컴파일러와 REALLY 오픈 소스 동작이있는 커뮤니티를 만들지 않고서도 더 나아지는 것을 볼 수 없기 때문입니다.
@jrockway가 말한 것처럼 돈에 관한 것이면 F #이 java 또는 C #과 같은 인기를 얻을 수 있는지 알 수 있습니다.
필자는 개발자가 기능적인 방식으로 일하는 데 불편 함을 느끼지 않는다고 생각합니다 (2009 년 F # 세션에서 약 10 명이 거의 100 명 사이에서 기능적 프로그래밍을 알고 있다고 말한 F # 세션).
나는 올해 OCAML을 시작했는데 함수형 프로그래밍으로 손을 더럽 히지 않았지만 이제는 항상 OCAML과 문제를 해결하는 기능적 방법에서 항상 새로운 것을 배웁니다 (그러나 C #을 포기한다고 말할 수는 없습니다. OCAML을 사용하려면 :)).
아마도 F #이 인기를 얻게 될 것입니다.
c-> ocaml이 c-> lisp보다 더 큰 정신적 전환이라는 것은 도움이되지 않습니다. 나는 두 번 ocaml을 고려했으며 항상 비용 / 이점이 저에게 없다는 것을 알았습니다. 따라서 다시 따로 설정하십시오. 그것은 어려워 보이게 만드는 구조물이 아니 었습니다. 실제로는 깔끔하게 보입니다. '!'에 대해 완전히 다른 의미를 배우려고했습니다. Lisp는 c와 같이 작은 조각을 잘못 해석하는 것을 피하기 쉽도록 최소한 다르게 보입니다.
실시간 임베디드 시스템에서 언어를 사용하려면 포인터가 필요하며 GC를 감당할 수 없습니다.
OCaml을 아는 개발자가 너무 적기 때문이라고 생각합니다.
그리고 다른 개발자들 (Ocaml에 대해 들었던 사람들)과 이야기 할 때 나는 항상 OCaml을 "교육 전용"언어라고 생각합니다. 슬프지만 사실입니다