왜 Lisp가 더 널리 퍼지지 않습니까? [닫은]

SICP 비디오로 Scheme을 배우기 시작했고 다음으로 Common Lisp로 이동하고 싶습니다.

이 언어는 매우 흥미로워 보이며 대부분의 사람들은 그 언어로 표현력이 다르다고 주장합니다. CL은 적절한 표준 라이브러리를 가지고있는 것 같습니다.

왜 Lisp가 더 널리 퍼지지 않습니까? 그것이 정말로 강력하다면 사람들은 그것을 온전히 사용해야하지만 대신 Lisp 구인 광고를 찾는 것은 거의 불가능합니다.

잠시 후 큰 문제가 아니기 때문에 괄호가 아니기를 바랍니다.

표현력이 기업 환경에서 항상 긍정적 인 언어 특성 인 것은 아닙니다 . Java는 배우기 쉽고 쓰기가 쉽고 읽기 쉽기 때문에 부분적으로 매우 인기가 있습니다. 평범한 프로그래머는 코드가 훌륭하고 우아하지 않더라도 Java에서 여전히 매우 생산적 일 수 있습니다.

또한 표현 언어를 쉽게 남용 할 수 있습니다. 전문적인 자바 프로그래머는 잘못 작성된 코드를 빠르게 리팩토링 할 수 있습니다. 표현력이 높을수록 끔찍한 코드를 이해하고 리팩토링하기가 더 어려워집니다. LISP 매크로가 좋은 예입니다. 매크로는 오른손에 강력한 도구입니다. 손이 잘못되면 혼란스럽고 디버그가 어려울 수 있습니다.

LISP는 고위 경영진 에게 위험한 선택 입니다. 일이 잘못되면 아무도 오라클이나 Microsoft와 같은 대기업이 지원하는 대중적인 객체 지향 언어를 고르는 것에 대해 관리를 비난하지 않을 것입니다. 인기 있고 배우기 쉬운 언어 경험이있는 프로그래머를 고용하는 것이 훨씬 쉽습니다.

보다 강력한 언어를 사용하려는 진보적 인 회사조차도 일반적으로 LISP를 선택하지 않습니다. 많은 새로운 언어가 LISP의 강력한 기능을 빌려서 대중에게 쉽게 배울 수 있기 때문에 시도하고 타협하기 때문입니다. 스칼라와 루비는이 모델을 따릅니다. 나쁜 프로그래머는 빠르게 그것들을 집어 들고 자바에서했던 것과 같은 평범한 코드를 계속 작성할 수 있습니다. 좋은 프로그래머는 고급 코드를 작성하기 위해 고급 기능을 활용할 수 있습니다.

괄호는 문제가되지 않습니다. 하스켈은 파이썬이나 루비와 비슷한 문법을 ​​가진 매우 강력하고 표현적인 언어이며 LISP와 같은 이유로 널리 채택되지 않았습니다.

이 모든 것에도 불구하고, 나는 기대하고 있습니다 ...

Clojure는 인기를 끌 기회가 있습니다. JVM에서 실행되며 Java와 큰 상호 운용성이 있으며 동시 프로그래밍이 훨씬 간단 해집니다. 이것들은 많은 회사에서 중요한 것입니다.

* 이것은 Java, Clojure, JRuby 및 Scala에 경험이있는 전문 JVM 프로그래머로서의 관점입니다.

왜 Lisp가 더 널리 퍼지지 않습니까? 그것이 정말로 강력하다면 사람들은 그것을 온전히 사용해야합니다.

언어가 기술적 인 장점을 위해 선택되었다고 생각한다면, 당신은 영혼을 아프게하는 실망에 빠집니다.

이러한 결정은 Strippers And Steaks를 기반으로 합니다. Microsoft는이를 감당할 수 있습니다. 오라클은 할 수 있습니다. 썬은 자바를 부풀리기 위해 많은 돈을 썼다. 두번. 분산되고 이질적인 자원 봉사 커뮤니티는 그와 경쟁 할 수 없습니다.

그러나 대신 Lisp 구인 광고를 찾는 것은 거의 불가능합니다.

재미있게도, Lisp 회사는 정반대라고 말합니다. 그들은 지속적으로 일자리가 있지만 충분한 인력을 찾을 수는 없습니다. (하스켈, ML, 오캄, 포스, 스몰 토크에도 동일하게 적용됩니다.)

실제 회사에서 일한 경험이 없지만 LISP를 사용하기 어려운 이유를 알고 있습니다.

우선, 이것은 나 에게이 블로그 게시물을 상기시킵니다 : http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

내가 Lisp에서 갖는 주요 문제는 "어떤 Lisp"질문이다. 나는 보통 리눅스에서 주 플랫폼으로 일하지만, 내가 만든 것들은 Windows와 호환되어야합니다. 즉, 사용할 기술을 평가할 때 완전히 다른 두 운영 체제에서 작업 할 때 내 삶을 편하게 만들어야합니다. 이 요구 사항이 마음에 들지 않지만 요구 사항 인 실제 프로젝트에서 사용하는 것이 좋습니다. 이제 개인 프로젝트를 위해 Windows를 잘 지원하지 않는 언어를 사용하지만 큰 소프트웨어 프로젝트를 작성할 기회가 없기 때문에 필요한 경험이 없습니다.

이제 기능 언어를 배우려고 할 때, 저는 Common Lisp를 배우고 싶었습니다. 그것은 옳은 일처럼 보였다. 실제로 내장 함수를 알지 못하고 Lisp에서 작업 할 프로젝트가 필요했기 때문에 Practical Common Lisp를 뛰어 넘기 시작했습니다. S- 표현은 아름답고 쉬웠습니다. 코드에서 무슨 일이 일어 났는지 정확히 알았 기 때문에 모든 괄호는 엄청나게 아름답습니다.

그래서 나는 책 밖에서 Lisp에 첫 번째 프로그램을 작성하려고합니다. 코드 줄을 세고 코드 줄에서 사소한 줄을 제거하는 명령 줄 도구를 원했습니다. 가장 유용한 도구는 아니지만 재미있게 할 수 있습니다. 파일 액세스, 약간의 구문 분석 및 계산이 포함됩니다. 약 일주일 전에 파이썬에서 동일한 도구를 구현했습니다.

명령 줄 인수에 액세스해야합니다. 그런 다음 명령 줄 인수를 얻는 표준 방법이 없다는 것을 배웁니다. 그것들은 모두 비표준 기능입니다. 전혀 크로스 플랫폼이 아닙니다. 언어에는 많은 라이브러리가 내장되어 있지 않기 때문에 주로 더 악화됩니다. 나는 Haskell로 전환하고 커먼 리스프에 그리 멀지 않았습니다 (따라서 불만이 유효하지 않을 수도 있습니다).

과거에는 이런 종류의 비표준적인 것이 항상 고통 스러웠습니다. C ++도 같은 문제가 있지만 Boost와 같은 라이브러리를 사용하면 이러한 약점을 해결할 수 있습니다.

또한 S- 표현 이외의 모든 것에 대한 Lisp 구문이 약간 추악하다는 것을 도움이되지 않습니다.

IMO는 주로 다음으로 인한 것입니다.

• 열악한 라이브러리 지원. 물론 Quicklisp이있어 라이브러리를 쉽게 설치할 수 있지만 라이브러리가 여전히 적다는 것을 보상하지 않으며 문서화가 잘 이루어지지 않았거나 유지 관리가 잘되지 않은 것도 있습니다. 파이썬과 비교할 때 (특정한 방언에 관계없이) 사소한 Lisp 응용 프로그램을 작성하면 아마도 휠의 적어도 일부를 재발 명할 가능성이 큽니다.
• 개발 도구에서 채택한 모델에 익숙하지 않습니다. 내가 아는 대부분의 사람들은 Eclipse와 Visual Studio에 익숙한 사람들이 이해할 수있는 SLIME과 Emacs를 사용해야하므로 상당히 협박 당한다. 두 가지 Eclipse 플러그인이 있다고 생각합니다. 몇 년 전에 하나만 사용해 보았지만 꽤 버그가있었습니다. 전체 Lisp 생태계는 본격적인 Lisp 실행 시스템의 일부였던 시절과 또 다른 언어의 현대 표준의 중간에 갇힌 것처럼 보입니다. 리스프를 배우는 것은 새로운 언어를 배우는 것에 만 국한되지 않습니다. 완전히 다른 일과 사고 방식을 배워야합니다. 취미로하는 것이 괜찮다면, 리스프를 배우는 것이 가치가 있는지는 의문입니다. 사업.

Clojure가 주변에있을 때 상황이 약간 좋아지기 시작합니다.

저는 10 억년 전에 대학에서 LISP를 배웠습니다.

FORTH와 마찬가지로 LISP는 논리에 좋습니다. 그러나 대부분의 프로그래밍은 논리가 아니라 지루한 기계적 방식으로 데이터를 조작하는 것입니다. 예를 들어 당시에는 숫자 출력을 오른쪽으로 정렬 할 수있는 방법이 없습니다.

LISP는 중첩 된 기능에 관한 것이며 사람들은 그렇게 생각하지 않습니다. 그들은 DO A, B, C, D, 그리고 E에 대해 생각합니다. "소득세 신고서 제출"과 같은 사전 정의 된 작업을 제외하고 사람들은 동시에 생각하지 않고 순차적으로 생각합니다. 이것이 오늘날 절차 언어가 지배적 인 이유입니다.

결과적으로 Java 및 C의 produral 코드는 영어로 쉽게 번역 될 수 있습니다. LISP 코드는 할 수 없습니다. 인간 언어는 그런 식으로 구성되지 않습니다.

따라서 문제 해결에는 유용하지만 프로그래밍에서 문제 해결은 그다지 중요하지 않습니다. LISP가 매우 약한 데이터 입력, 유효성 검사, 출력 형식.

아직 언급되지 않은 Lisp의 한 가지 문제는 평범한 초보자 프로그래머 (자신과 같이 자유롭게 인정합니다)가 Lisp 코드를 큰 프로그램으로 바꾸는 방법을 보는 것이 어려울 수 있다고 생각합니다. 작성하기는 쉽지만 설계하기는 어렵습니다. 나는 어떤 개념도 특별히 어렵다고 생각하지는 않지만 DIY 사고 방식은 너무 강해서 시작해야 할 부분을 종종 느끼지 못합니다.

Java 또는 C #과 같은 OOP 언어를 사용하면 유형 시스템을 사용하여 작업 모델을 향해 자신을 향상시킬 수 있습니다. Lisp (또는 Lua 또는 Javascript)를 사용하면 원하는 방식으로 나가서 할 수 있다는 개념이 있습니다. OOP를 원한다면 자신 만의 OOP 시스템을 만드십시오! 자신 만의 OOP를 만들거나 다른 사람을 배우는 것 외에는 사용 가능한 프로그램을 얻기 전에 언어 위에 새로운 장벽이 있습니다. 또한 항상 Lisp에 OOP가 있다고 생각하거나 Lua가 실제로 존재하지 않습니다. 실제로 원한다면 무시할 수 있기 때문에 요점은 무엇입니까?

요컨대, Lisp에서의 프로그래밍에는 많은 훈련이 필요하다고 생각합니다. 강력한 형식의 언어와 OOP 언어는 모두 일종의 기본 원칙을 제공하므로 프로그래머는 언어를 조정하는 대신 한정된 준비금을 프로젝트 마무리에 집중할 수 있습니다.

편집 : 나에게 놀란 비유로서, 목재 작업을해야하고 두 사람이 도구 상자를 제공하는 것과 같습니다. 한 사람의 도구는 일종의 엉뚱하지만 기본적으로 약간의 노력으로 작업을 수행합니다. 다른 사람에게는 큰 부품 모음이 있지만 그 부품을 결합하여 그립과 최고의 품질에 완벽하게 적합한 도구를 만들 수 있다고 약속합니다. 먼저 빌드해야합니다.

나는 오랫동안 똑같이 궁금해했으며, Lisp 회의에 참석하여 모든 사람들이 그것을 채택하지 못하게하는이 Lisp "어두운 측면"이 무엇인지 이해하려고 노력했습니다.

완벽한 답변을 찾지 못했습니다.

무지가 인기를 잃어버린 이유 일 수 있지만 더 당황스러운 것은 Lisp (예 : Google-Peter Norvig)가 Lisp에 대해 잘 아는 사람이라도 사용하지 않기 때문입니다.

내가 생각해 낸 유일한 부분 설명은 Lisp의 훌륭한 아이디어의 대부분이 이제는 평범하다는 것입니다. 실제로 중요한 누락 된 것 (매우 중요한 것)은 메타 프로그래밍의 용이성입니다.

불행히도 메타 프로그래밍을 훌륭하게하기 위해서는 호모 닉과 규칙적인 언어가 필요하기 때문에 다른 언어에도이 개념을 쉽게 적용 할 수있는 방법이 없습니다 (저는 템플릿 전용 버전이 아니라 일반적인 메타 프로그래밍에 대해 이야기하고 있습니다). 다시 말해, 기본적으로 구문에 대한 Lisp 접근 방식이 필요합니다. 코드는 데이터이고 데이터는 코드입니다. AST를 조작하는 구문이 풍부한 언어로 코드를 작성하는 것은 코드 작성 방법과 AST 작성 방법의 두 가지 언어를 알아야하기 때문에 더 어렵습니다. AST가 고정되어 있고 다양한 노드 유형으로 인해 복잡하고 불규칙한 경우 특히 어렵습니다. 대신 Lisp는 합리적으로 규칙적이고 확장 가능한 AST를 가지고 있으며 일반적으로 AST를 직접 작성하여 코딩합니다.

메타 프로그래밍은 본질적으로 더 어렵고 메타 메타 프로그래밍은 훨씬 더 어렵습니다. 대부분의 프로그래머와 관리자는 "아무도 그럴 필요가 없습니다"라는 대답을 선호합니다.

필자 go가 필요할 때 텍스트 기반 메타 프로그래밍 (텍스트 파일을 작성하는 외부 코드 생성기)과 "매직"(예 : 컴파일러가 프로그래머가 할 수없는 것을 수행 할 수 있음)을 사용하는 것과 같은 "새로운"언어가 특히 슬프다는 것을 안다 .

복잡성 문제에 대한 해결책은 강력한 도구와 교육이라고 생각합니다. 추세는 명백히 무딘 도구이며 문제를 제기하는 것은 없습니다.

CL조차도 아주 좋은 라이브러리 지원을 가지고 있지 않은 것 같습니다. 적어도 Lisp에서 Python으로 전환 한 사람들에 따르면 :

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

개인적으로, 나는 어떤 계획을 알고 그것을 가지고 노는 것을 좋아하지만 그 언어로 사소한 프로젝트를 상상할 수는 없습니다.

강력하다는 것이 반드시 널리 사용되는 것은 아닙니다. '일반적인 경우에 최적화'라는 용어를 들어 보셨습니까? 불행히도 많은 사람들이 평범한 태도를 보인다면, 그들 사이에서 많은 실패로 큰 타격을 입는 것보다 꾸준히 보장하는 것이 사람들에게 훨씬 낫다고 말합니다.

이것은 lisp의 경우뿐만 아니라 많은 기술에서도 마찬가지입니다. 유닉스 텍스트 처리 도구, awk, sed, perl을 잘 다루면 며칠의 프로그래밍 시간을 절약 할 수 있습니다. 불행히도 사람들은 다른 도구에서 이러한 종류의 작업을 몇 분 안에 더 효율적으로 수행 할 수있는 일을하는 데 며칠이 걸렸습니다. 그러나 평생을 일식으로 보내면 결코 이런 것들의 가치에 감사하지 않을 것입니다. 가독성과 유지 관리 성이 뛰어난 거대한 프로그램을 작성할 수는 있지만 작성하지 않은 상태에서 이러한 프로그램을 작성하는 요점은 쉽게 수행 할 수 있습니다.

요즘 도구를 디자인하는 또 다른 측면은 도구를 직접 사용하여 문제를 해결하는 데 얼마나 유용한 지입니다. 너무 일반적인 것을 만들 수 없으며 라이브러리와 프레임 워크를 통해 모든 것을 헤지한다고 말하십시오. 좋은 도구는 주변 환경과 문제에 잘 맞습니다. php, perl 및 awk와 같은 도구는 끝없는 트롤링 및 bashing에도 불구하고 계속 관련이 있습니다. 왜냐하면 도구를 버리는 데 너무 유용하고 많은 라이브러리와 프레임 워크가있는 일반 언어보다 많은 작업을 수행하기 때문입니다.

마찬가지로 Java / Python과 같은 언어가 매우 우수하며 특정 작업에 가장 적합하다고 말할 것입니다. 파이썬은 특히 매우 좋고 배우고 쓰기 쉽습니다. 또한 데이터 엔드 포인트가 표준 인 경우 이러한 언어가 실제로 유용합니다. 일종의 데이터베이스 또는 XML 또는 그러한 종류의 데이터. 기본적으로 구조화 된 데이터.

Lisp는 오랫동안 주변에있을 것이지만 반드시 널리 퍼져있는 것은 아닙니다. 보시다시피 각 도구에는 틈새가 있습니다. 그리고 그들은 즉시 특정 문제를 해결합니다. 저는 생각하기에 lisp가 잘 해결하기 위해 설계된 영역과 문제에서 잘하고 있다고 생각합니다.

Lisp 언어를 사용한 웹 개발의 경우 약간의 닭과 계란 문제가있을 수 있습니다. Lisp를 사용하는 사람이 거의 없기 때문에 호스트가 허용하지 않거나 쉽게 만들지 못하고 쉽지 않기 때문에 소수의 사람도 있습니다 그걸 써. 그러나 실제로 Lisp를 호스트에서 실행하는 것은 기본 PHP 서비스보다 약간 더 많은 작업이 필요한 경우에도 생각보다 쉽습니다. 나는 최근에 가지고 교활 작업 계획 애플 리케이션 여기에 조금의 노력으로합니다.

IMO, 그것은 대부분 타이밍이 좋지 않은 문제입니다. Lisp는 대부분의 사람들이나 사용에 실용되기 오래 전에 오래되었습니다. Clojure (예를 들어)는 훨씬 좋은 기회입니다. 그 성공은 Java (및 JVM에서 실행되는 다른 모든 것)와의 상호 운용만큼 실용적인 것보다 새롭고 세련되고 시원하게 인식되는 데 훨씬 더 의존 할 것입니다.