dem*_*emi 15 lisp scheme common-lisp
我想学习Lisp家族的一些语言.它可能是CL或Scheme,并尝试将其用于Web编程.纯娱乐.我有很多C++经验(专业发展).
但我希望我的选择是没有遗产的现代语言(在语言本身和库中),因为我想从一开始就学习好的设计模式.
我无法决定什么是更好的:CL或Scheme.CL拥有更大更优质的库和框架(Weblocks),但我听说它在语法和库方面有很多遗产.Scheme是另一种:简单,简洁的语法但是库很差.如果它没有遗产,我更喜欢CL.
我不喜欢学习像C++这样的另一个怪物.CL是否像Lisp系列中的C++一样？而Scheme就像是C#或Java - "修订版"的C++.
编辑:我想写功能样式,OOP可能是,但可选.
Rai*_*wig 18
该计划是在70年代中期发明的.
CL从1982年开始开发.第一个定义发表于1984年:Common Lisp the Language.
该计划没有遗产或更现代是一个神话.Scheme已经在Common Lisp之前定义了近十年.Scheme仍然有s-expressions,cons单元格,符号,car,cdr,cons等遗留物.该方案有遗产使其成为Lisp语言家族的一员,其源于1958年的第一个Lisp语言.
Scheme的最初目标是成为一种比传统Lisp更接近lambda演算的小型语言.因此,词法绑定作为Lisp语言的默认是第一个.
不幸的是,它在许多其他方面都是一种玩具语言.它只有一小部分功能,你需要编写程序所需的功能,比如一种有用的错误处理方式.
十年之后Common Lisp的设计目标是不同的.它旨在编写商业软件,大型软件,高性能软件.另一个目标是它是Lisp方言主线(这里是Maclisp)的传统,因此已经拥有大型图书馆或程序的程序员不会从零开始.
Common Lisp从第一天开始就添加了很多被认为有用的功能:
以及更多.
在90年代中期,CL的修订版已经发布.它补充说:
由于CL作为Scheme开始变大,因此一些设计决策使得CL比Scheme更好用.例如,Scheme只有原始参数列表,仅此一点就使得库更难使用.
Scheme对其标准进行了更多的修订,但基本的设计决策仍然存在,社区正在努力解决错误处理,记录,对象系统等基础问题.R6RS被证明是有争议的,我同意批评者的看法.我认为R6RS的方向和内容都非常令人失望.
还有另外两种观点:半标准和个别实施.
Scheme社区产生了许多半标准扩展.这应该被视为成功.
OTOH的实现在Scheme中广泛分歧.对他们几乎没有共识.有许多非常小的实现和许多大型实现.
CL实现OTOH已经包含一个大型语言,因此它们不会从小开始.关键字参数就在那里.对象系统也是如此.随着时间的推移,一些应用程序确保它们可以在许多实现上大致保持不变.此外,个别实现增加了许多功能,如Unicode支持,线程,并发执行等.
因此,当前的Lisp实现可以具有很多功能.
Common Lisp和Scheme共享Lisp的遗产:符号,s表达式,汽车,cdr,cons,cons基于单元格的列表,......等等.
Common Lisp有一些不太好的部分,但在标准中定义.一个例子是CL符号名称在内部是大写的."序列"的概念在标准中是不可扩展的.和更多.各个实现处理CL标准的许多限制.因此,例如在大多数实现中,I/O系统使用CLOS编写,条件基于CLOS,存在可扩展的SBCL序列等.
CL可能是一种庞大的语言,但它不是C++.许多部件设计出色,易于使用.由于Common Lisp是一种可编程编程语言,因此用户也可以修复许多问题.你不喜欢内置的LOOP吗？使用ITERATE,如果你更喜欢或甚至自己编写.
per*_*erp 11
Common Lisp有许多特性,其中一些可能源于遗留(不知道我的Lisp历史是否足以肯定地说).有很多瑕疵,如功能命名和参数顺序的不一致.但实际语言本身虽然有点奇怪,但相当明智.不像C++ ......
Scheme也有瑕疵,但我认为程度较轻.另一方面,与CL相比,Scheme的标准库很小,因此疣的空间也较小.:-)
除了普通的CL和Scheme实现之外,你还有一些"下一代Lisps",比如Clojure(可能是它们中最"现代"的 - 从头开始设计用于重度并发)和newLISP,以及"下一代计划",球拍(以前称为PLT计划).
我个人对Racket印象非常深刻,我希望有一天能用它来做些什么.