发信人: CMUCL (binghe), 信区: FuncProgram
标 题: Re: 一些最近Scala在工业界应用的争论
发信站: 水木 ...
flw 发表于 2011-12-02 16:48
lisp与C就是阳春白雪与下里巴人之分。
http://www.gnu.org/gnu/rms-lisp.html
The original Emacs did not have Lisp in it.
...
The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp.
也许是受到俺的见识所限, 至少我不认为lisp有什么神秘的.
而且,lisp和数学物理等科目不同. 数学可能无法产生立即的效果,因为这是个纯理论性的科目;但是lisp本来就是为了应用而生,纯应用性的,却被应用所抛弃. 还好意思蹦达嘛呀.
lisp之所以NB,很大程度是因为炒做,就和山东的大蒜没什么区别.
塑料袋 发表于 2011-12-04 22:34
http://www.paulgraham.com/icad.html
Steve Russell said, look, why don't I program this eval..., and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing.
...
Suddenly, in a matter of weeks I think, McCarthy found his theoretical exercise transformed into an actual programming language-- and a more powerful one than he had intended.
So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn't get stale.
本坛子上几乎100%的人都是人云亦云. 某个白专教条的书上说lisp牛逼了,大家就都一窝蜂的认为它NB.
就算它不是炒做而是确实牛逼,那么坛子上也不见得就有人能够认识到它NB在那里.
塑料袋 发表于 2011-12-04 22:34
不对, lisp从一开始就是纯理论性研究, 一种思维体操而已。 原本就只打算作为一种图灵机定义。
甚至当McCarthy听说一个学生打算实现lisp时, 还告诉他不要将理论与实践混淆。
OwnWaterloo 发表于 2011-12-04 23:24
我还知道lisp有一个用处.
就是opengl shader language在经过前端处理后,输出的东西和lisp很相象.
mesa driver需要处理这个语法树,然后把这个shader交给GPU.
lisp隶属于语言,语言隶属于描述方式,描述方式是为思考服务的。
思考么,还和纯理论沾边。
语言么,任何一种语言都是实践,而不是理论。
lisp首先是一种语言,所以它是实践,而且是一种又被实践所抛弃的语言。
语言是工具而且仅只能是工具,这是放诸四海而皆准,颠扑不破的真理。
塑料袋 发表于 2011-12-05 14:28
我不明白C版那些坛头版霸怎么就那么大言不惭,颠倒黑白,指鹿为马:
一边又嘲笑讥讽着linus大神关于的C++观点。
一边又引用别的所谓“语言权威”的口水,来喷坛子上的众狼友。
这纯粹和借耶稣打到如来佛,借真主打败耶稣一样可笑。
而且,即使是那些别的“语言权威”,也从没敢说过“语言影响思想”,这个反动论调纯粹是那些坛头版霸鼓捣出来的,他们怎么就这么敢冒天下之大不讳?
塑料袋 发表于 2011-12-05 14:28
我一直用clisp做系统管理的,以前用perl,现在觉得perl语法不能随便自定义(为什么要说Larry always right? ...
wsw1wsw2 发表于 2011-12-06 09:33
欢迎光临 Chinaunix (http://bbs.chinaunix.net/) | Powered by Discuz! X3.2 |