10
"웹의 여러 가지 이유로 설정 라이브러리 및 프로토콜이 다른 언어보다 LISP에서 개발 에 느린했다"라고
그리고 결과적으로 웹 커뮤니티 간의 리스프 (lisp) 채택이 줄어들고 사람들은 더 풍부한 라이브러리 세트로 언어를 따라 갔다.
LISP 커뮤니티가 웹 프레임 워크를 구축하는 데 느린 이유가 있을까요?
A
답변
11
Norvig의 발언은 나에게 현재 상황에 대한 평가보다 더 역사적인 것으로 보였다. 아마도 90 년대 중반에서 후반에 웹 관련 라이브러리는 Common Lisp에서 Java와 같은 다른 언어 에서처럼 빠르게 나타나지 않았습니다.
하지만 오늘은 그렇지 않습니다. 아파치의 mod-lisp는 말할 것도없고 5 개 이상의 CL 서버 (CL-HTTP, Hunchentoot, S-HTTP-Server, Araneida, AllegroServe)를 5 개 이상의 Common Lisp 웹 서버로 지정할 수 있습니다. 거의 12 개의 다른 웹 프레임 워크가 있어야합니다 (KPAX, Weblocks, UncommonWeb 등). SOAP, XML, XLST, FTP, XML-RPC, S3, AJAX .... 무한대 등 이름을 붙일 수있는 모든 웹 약어에 대한 공통 리스프 라이브러리가 있습니다. 그리고 불가사의 인 ParenScript와 같은 다른 언어로는 아날로그가없는 도구가 있습니다. http://www.cl-user.net, 나는 주요 이유 라이브러리가 다른 언어보다 리스프에서 개발 약간 느린 될 수 있다고 생각 http://www.common-lisp.net
5
나는 그가 무슨 뜻인지 모르겠다. 내 추측에 따르면 아마도 대부분의 경우 "Common Lisp libraries가 부족하다"고 불평하는 사례가 될 것이다. (나는 대부분 침대 일 것이라고 생각하지만 무엇이든).
그것은 흥미로운 note that에 :
첫 번째 HTTP 1.1 호환 서버와 HTTP 1.1 참조 구현
를 디버깅하기 위해 W3C 에서 사용하는 [한]이 리스프에 작성되었습니다.
2
8
로 유지된다 많은 것이 :
웹 라이브러리의 지방 목록은 커먼 리스프 디렉토리를 참조하십시오 그것은 너무 쉽다는 것입니다. Lisp로 작성된 라이브러리는 종종 그 이름에 걸맞지 않습니다. 그것들은 단지 몇 줄의 코드 일 뿐이며, 당면 과제에 특화되어 있습니다. 몇 분의 시간이 더 걸리면 범용 라이브러리가 생기 겠지만, 사소한 코드 라인 일 때 아무도 원하지 않는 것처럼 보입니다.
약 1 년 전에 Clojure에서 CSV를 읽고 써야했습니다. 표준 조언은 잘 알려진 여러 Java 라이브러리 중 하나를 사용하는 것이 었습니다. Clojure에서 단순히 write my own이었던 것보다 어떤 라이브러리가 가장 적합한 지 확인하고 API를 배우는 것이 더 어렵다는 것을 알게되었습니다. 그것은 50 행이며, 의도 한 유스 케이스를 아름답게 처리합니다.CSV 라이브러리가 아닙니다. 지원하지 않는 경우가 많으므로 도서관으로 포장하지 않았으므로 Clojars 또는 그와 비슷한 곳에 넣으십시오. 나는 내가 문제의 일부라고 생각한다.
오늘날 웹에 실용적인 Lisp 자습서 중 절반은 HTML 생성 매크로의 예제를 포함합니다. 그것들의 대부분은 프로덕션 수준의 품질이며 코드의 스크린 쿨 (screenfull)에 불과합니다. 그만큼 포장을하고 도서관을 소집 할 가치는없는 것 같습니다. 점잖은 Lisp 프로그래머가 몇 분 안에 쓸 수있는 것은 사소한 코드 다. 은 도서관으로 포장 할 가치가있는이고, Edi Weitz은 그 라인을 따라 많은 코드를 발표했습니다.
Hunchentoot은 훌륭하지만 TBNL을 기반으로하며 가장 초기의 changelog 항목이 1999 년인 Aserve에서 영감을 얻었습니다. 비교해 보면 AOLserver (nee NaviServer)는 1994 년 C/Tcl을 사용했습니다. Perl, Java 및 PHP 사용자도 1990 년대 중반 웹상의 것들. Clojure는 2007 년까지 현장에 도착하지 않았습니다. "느린 개발"기준을 충족한다고 생각합니다. :-) – Ken