a**y
发帖数: 335 | 1 嗯..., 他说的csc应该是编译器吧，把C#编译成
Intermediate Language.
解释器在.NET里是不是应该叫做Common Language Runtime?
就是用来Just In Time 编译 IL成机器代码的
所以严格来说，.NET并没有解释器.
|
|
p*******p
发帖数: 13670 | 2 刚刚意识到frame sdk里面自带了csc解释器地, //blush |
|
L*******r
发帖数: 1011 | 3 en. MS 的JIT是ahead compile. JIT还是compiler. compile to native code.
我可能弄错了，我记得Framework中有个源码级的解释器，有点像lisp的eval. |
|
h*h
发帖数: 27852 | 4 http://www.yinwang.org/blog-cn/2015/10/18/turing
图灵的光环
仿佛全世界的人都知道，图灵（Alan Turing）是个天才，是他创造了计算机科学，是
他破解了德国纳粹的Enigma密码。由于他的杰出贡献，计算机科学的最高荣誉，被叫做
“图灵奖”。然而根据自己一直以来对图灵机等计算模型的看法，加上一些历史资料，
我发现图灵本人的实际成就，相对于他所受到的崇拜，其实相差甚远。
由于二战以来各国政府对于当时谍报工作的保密措施造成的事实混淆，再加上图灵的不
幸生世所引来的同情，图灵这个名字似乎拥有了一种扑朔迷离的光环。人们把很多本来
不是图灵作出的贡献归结在他身上，把本来很平常的贡献过分地夸大。图灵的光环，掩
盖了许多对这些领域做出过更加重要贡献的人。
图灵传
2012年，在图灵诞辰一百周年的时候，人们风风火火的召开各种大会，纪念这位“计算
机之父”，很多媒体也添油加醋地宣传他的丰功伟绩。还有个叫Andrew Hodges的人，
抓住这个时机推销自己写的一本传记，叫做《Alan Turing: The Enigma》。这本书红
极一时，后来还被改... 阅读全帖 |
|
H********g
发帖数: 43926 | 5 【 以下文字转载自 Military 讨论区 】
发信人: hsh (nidaye), 信区: Military
标 题: 王垠： 图灵的光环
发信站: BBS 未名空间站 (Mon May 9 12:34:11 2016, 美东)
http://www.yinwang.org/blog-cn/2015/10/18/turing
图灵的光环
仿佛全世界的人都知道，图灵（Alan Turing）是个天才，是他创造了计算机科学，是
他破解了德国纳粹的Enigma密码。由于他的杰出贡献，计算机科学的最高荣誉，被叫做
“图灵奖”。然而根据自己一直以来对图灵机等计算模型的看法，加上一些历史资料，
我发现图灵本人的实际成就，相对于他所受到的崇拜，其实相差甚远。
由于二战以来各国政府对于当时谍报工作的保密措施造成的事实混淆，再加上图灵的不
幸生世所引来的同情，图灵这个名字似乎拥有了一种扑朔迷离的光环。人们把很多本来
不是图灵作出的贡献归结在他身上，把本来很平常的贡献过分地夸大。图灵的光环，掩
盖了许多对这些领域做出过更加重要贡献的人。
图灵传
2012年，在图灵诞辰一百周年的时候，人们风风火火的... 阅读全帖 |
|
h*h
发帖数: 27852 | 6 【 以下文字转载自 Military 讨论区 】
发信人: hsh (nidaye), 信区: Military
标 题: 王垠： 图灵的光环
发信站: BBS 未名空间站 (Mon May 9 12:34:11 2016, 美东)
http://www.yinwang.org/blog-cn/2015/10/18/turing
图灵的光环
仿佛全世界的人都知道，图灵（Alan Turing）是个天才，是他创造了计算机科学，是
他破解了德国纳粹的Enigma密码。由于他的杰出贡献，计算机科学的最高荣誉，被叫做
“图灵奖”。然而根据自己一直以来对图灵机等计算模型的看法，加上一些历史资料，
我发现图灵本人的实际成就，相对于他所受到的崇拜，其实相差甚远。
由于二战以来各国政府对于当时谍报工作的保密措施造成的事实混淆，再加上图灵的不
幸生世所引来的同情，图灵这个名字似乎拥有了一种扑朔迷离的光环。人们把很多本来
不是图灵作出的贡献归结在他身上，把本来很平常的贡献过分地夸大。图灵的光环，掩
盖了许多对这些领域做出过更加重要贡献的人。
图灵传
2012年，在图灵诞辰一百周年的时候，人们风风火火的... 阅读全帖 |
|
h*h
发帖数: 27852 | 7 http://www.yinwang.org/blog-cn/2014/12/31/google-story
我和 Google 的故事（2015 修订版）
2009 和 2010 年，两年的夏天我都在 Google 实习，然而最后毕业的时候我却没有为
Google 工作。虽然我心里很清楚这里面的原因，可总有些人觉得不解，为什么居然有
人不想为 Google 工作？如果你是这些人其中之一，那你可能想知道我在 Google 时的
切身感受。
直到将近 2015 年新年的今天，我发现这篇文章仍然具有普遍的意义。面对 Google 的
员工，我仍然是同样的感觉。他们很多人太拿自己的公司当回事了，自高自大，放弃自
己的尊严来舔这个公司的屁股。这些人总觉得好像所有人都希望为 Google 工作，即使
进不了 Google，都想去 Google “蹭饭”似的。如果一个人说“我很厉害”，我也许
会尊敬他，可是如果他说“我为 Google 工作”，以此来显得厉害，我就会鄙视他。我
只尊敬那些尊敬他们自己的人。以自己的公司名声来抬高自己的人，是最被我瞧不起的
，因为他们跟仗着人势的狗没什么区别。
进 G... 阅读全帖 |
|
c*****e
发帖数: 3226 | 8 【 以下文字转载自 CS 讨论区 】
发信人: biochemputer (Pandora Box), 信区: CS
标 题: orz, 王垠骂完了五道口伊萨卡现在开始骂Google了
发信站: BBS 未名空间站 (Fri Aug 10 17:53:39 2012, 美东)
纯转载
---
http://blog.sina.com.cn/s/blog_5d90e82f010191rh.html
---
我和Google的故事 (2012-08-10 02:58:52)转载▼
分类： 杂谈
也许有人看见过我批判 Google 的那篇英文文章。它有一部分片面性，所以被我从英文
博客上拿下来了。我一直在反思自己在 Google 的经历，也许现在用自己的母语，我可
以得出一个准确一点的结论吧。
也许有人觉得作为一个读了这么多年的 PhD 去给别人做实习生（intern）是一种耻辱
，但是我亲眼看到，从一些名校比如 Yale 毕业的 PhD，在 Google 混了好几年，也不
过是过着差不多的生活。只不过做了 intern 之后我长了经验，知道了自己的价值，以
后不至于落到同样的位置。
这里... 阅读全帖 |
|
c*******h
发帖数: 1467 | 9 也许有人看见过我批判 Google 的那篇英文文章。它好像有一部分片面性，所以被我从
英文博客上拿下来了。我一直在反思自己在 Google 的经历，因为在这个公司工作总是
感觉不对劲，但是却总也说不清楚为什么。也许现在用自己的母语，我可以得出一个准
确一点的结论吧。
受命于危难
先说说我的项目是怎么开始的吧。当我加入的时候，我的老板 Steve Yegge 的小组试
图制造一个跨语言的“服务式”编程工具，叫做 Grok。你可以把它想象成 Eclipse 和
Visual Studio, 但是 Grok 的设计目标不只是检索和分析本机的某一种语言的代码，
而是大规模的检索和分析 Google 的所有项目，所有语言，所有代码。这包括 Google
的“四大语言”：C++, Java, JavaScript, Python，一些工具性的语言：Sawzall，
protobuf 等，还有一些“build file”和所有第三方的库。Grok 的初期设计目标是一
个静态的代码索引服务，只要程序员点击任何一个变量或者函数名，就能“准确”的跳
转到它定义的位置。动态的编辑功能稍后也在陆续加入。
这种... 阅读全帖 |
|
b**********r
发帖数: 91 | 10 纯转载
---
http://blog.sina.com.cn/s/blog_5d90e82f010191rh.html
---
我和Google的故事 (2012-08-10 02:58:52)转载▼
分类： 杂谈
也许有人看见过我批判 Google 的那篇英文文章。它有一部分片面性，所以被我从英文
博客上拿下来了。我一直在反思自己在 Google 的经历，也许现在用自己的母语，我可
以得出一个准确一点的结论吧。
也许有人觉得作为一个读了这么多年的 PhD 去给别人做实习生（intern）是一种耻辱
，但是我亲眼看到，从一些名校比如 Yale 毕业的 PhD，在 Google 混了好几年，也不
过是过着差不多的生活。只不过做了 intern 之后我长了经验，知道了自己的价值，以
后不至于落到同样的位置。
这里我就讲述一下我在 Google 的实习经历吧，也许对人有参考作用。
受命于危难
先说说我的项目是怎么开始的吧。当我加入的时候，我的老板 Steve Yegge 的小组试
图制造一个跨语言的“服务式”的编程工具，叫做 Grok。你可以把它想象成 Eclipse,
但是 Grok 的... 阅读全帖 |
|
b**********r
发帖数: 91 | 11 纯转载
---
http://blog.sina.com.cn/s/blog_5d90e82f010191rh.html
---
我和Google的故事 (2012-08-10 02:58:52)转载▼
分类： 杂谈
也许有人看见过我批判 Google 的那篇英文文章。它有一部分片面性，所以被我从英文
博客上拿下来了。我一直在反思自己在 Google 的经历，也许现在用自己的母语，我可
以得出一个准确一点的结论吧。
也许有人觉得作为一个读了这么多年的 PhD 去给别人做实习生（intern）是一种耻辱
，但是我亲眼看到，从一些名校比如 Yale 毕业的 PhD，在 Google 混了好几年，也不
过是过着差不多的生活。只不过做了 intern 之后我长了经验，知道了自己的价值，以
后不至于落到同样的位置。
这里我就讲述一下我在 Google 的实习经历吧，也许对人有参考作用。
受命于危难
先说说我的项目是怎么开始的吧。当我加入的时候，我的老板 Steve Yegge 的小组试
图制造一个跨语言的“服务式”的编程工具，叫做 Grok。你可以把它想象成 Eclipse,
但是 Grok 的... 阅读全帖 |
|
x****o
发帖数: 21566 | 12 来源：王垠的博客
有些人问我，你说学习操作系统的最好办法是学习程序设计。那我们是不是应该学习一
些“设计模式”（design patterns）。这是一个我很早就有定论，而且经过实践检验
的问题，所以想在这里做一个总结。
总的来说，如果光从字面上讲，程序里确实是有一些“模式”可以发掘的。因为你总是
可以借鉴以前的经验，用来构造新的程序。你可以把这种经验叫做“模式”。可是自从
《设计模式》（通常叫做 GoF，“Gang of Four”，“四人帮”）这本书在 1994 年发
表以来，“设计模式”这个词有了新的，扭曲的含义。它变成了一种教条，带来了公司
里程序的严重复杂化以及效率低下。
GoF 借鉴的是一个叫 Christopher Alexander 的建筑师的做法。Alexander 给一些建
筑学里的“设计模式”起了名字，试图让建筑师们有一些“共同语言”。可惜的是，
Alexander 后来自己都承认，他的实验失败了。因为这些固定的模式，并没能有效地传
递精髓的知识，没能让新手成长为出色的建筑师。
照搬模式东拼西凑，而不能抓住事物的本质，没有“灵感”，其实是设计不出好东西的
。这就像... 阅读全帖 |
|
|
h*h
发帖数: 27852 | 14 【 以下文字转载自 Military 讨论区 】
发信人: hsh (nidaye), 信区: Military
标 题: 王垠：我和 Google 的故事（2015 修订版）
发信站: BBS 未名空间站 (Mon May 9 18:09:22 2016, 美东)
http://www.yinwang.org/blog-cn/2014/12/31/google-story
我和 Google 的故事（2015 修订版）
2009 和 2010 年，两年的夏天我都在 Google 实习，然而最后毕业的时候我却没有为
Google 工作。虽然我心里很清楚这里面的原因，可总有些人觉得不解，为什么居然有
人不想为 Google 工作？如果你是这些人其中之一，那你可能想知道我在 Google 时的
切身感受。
直到将近 2015 年新年的今天，我发现这篇文章仍然具有普遍的意义。面对 Google 的
员工，我仍然是同样的感觉。他们很多人太拿自己的公司当回事了，自高自大，放弃自
己的尊严来舔这个公司的屁股。这些人总觉得好像所有人都希望为 Google 工作，即使
进不了 Google，都想去... 阅读全帖 |
|
j**y
发帖数: 462 | 15 实际上pker说的不错 不知道为啥生气了
你要的核心就是一个解释器
最复杂的情况
解释器可以直接解读税法。哈哈
中间情况
你解读税法 总结 然后解释器再解读你的总结
最简单的情况
你直接写code 或xml yml json
解释器（现成的）解读
总之。嘿嘿 |
|
g****t
发帖数: 31659 | 16 Pker言之有物这点我同意。
但是pker对问题的难度可能估计过低了。
最简单的算账问题。
有个问题我以前做过，例如几十张表，按元统
计和按万元统计的不同口径，会破坏A B=C
这样的关系。那么就会出乱子。
这种问题最后只能问用户如何trade off。
你问任何一个炒股的，都会对TD这种大
券商的统计有个人意见。这里不好，那里不好。
这是因为大券商出的东西是平均需求的。
就是说对一个需求的开发，会产生新的需求。
会一拖再拖。
: 实际上pker说的不错 不知道为啥生气了
: 你要的核心就是一个解释器
: 最复杂的情况
: 解释器可以直接解读税法。哈哈
: 中间情况
: 你解读税法 总结 然后解释器再解读你的总结
: 最简单的情况
: 你直接写code 或xml yml json
: 解释器（现成的）解读
: 总之。嘿嘿
|
|
C********s
发帖数: 120 | 17 emacs 很适合用来写 perl/python/ruby/javascript，但是 emacs 没有内嵌的 python
解释器，只有一个内嵌的 elisp 解释器。vimfull 倒是要求安装 python，因为它自
带的脚本解释器太弱智。 |
|
|
n******7
发帖数: 12463 | 19 说的似乎很nb，但是鉴于他吹nb的历史，不知道多大水
另外他一直吹的pysonar好像github还是挺流行的，这是他唯一拿得出来的东西吧
-----
这种思维方式最近的成功实例，是给 Shape Security 做的一个先进的 JavaScript 混
淆器（obfuscator）和对集群（cluster）管理系统的改进。不要小看了这个 JS 混淆
器，它的强度跟 uglify 之类的开源工具比，是天上地下的。它不但包含了 uglify 的
变量换名等基本功能，而且含有专门针对人类和编译器的复杂化，使得没有人能看出一
点线索这个程序到底要干什么，让最先进的 JS 编译器也无法把它简化，从而让人有可
以理解它的机会。
其实这个混淆器也是一种编译器，只不过它把 JavaScript 翻译成更加难读的形式。在
这个项目中，由于失之毫厘就可以差之千里，我采用了从 Chez Scheme 编译器学过来
的，非常严密的测试方法。对每一个编译器的步骤（pass），我都给它设计一些正好可
以测到这个步骤的输入代码（比如，具有函数定义的，for循环，try-catch的，等等）
。Pass 输出的代... 阅读全帖 |
|
h*i
发帖数: 3446 | 20 函数式是啥词都有啊。函数是动词，数据其实可以是任何词，因为解释器是在人脑子里
面。
OOP以为Object能搞定解释器，Haskell人们以为type checker能搞定解释器，其实都是
大谬，自以为给数据加些条条框框似乎就给数据赋予了意义了，其实唯一的功能是他们
说的“整人”。 |
|
a**a
发帖数: 416 | 21 ML标记语言本身是被动的，passive. 就是说它本身并不真的会产生你所希望
的效果。它需要解释器来解释。ML的解释器现在一般称为浏览器。比如现在
Windows都带的Internet Explorer就是一个HTML/XML的解释器。当浏览器解释
ML文件的时候，它分析标记并且忠实地按照标记的指导显示相应的文字和图片
信息。而如果你用普通的编辑器打开一个ML文件，就看到一些“乱七八糟”的
东西，和浏览器看到的东西大相径庭。在这方面，ML语言类似于那些需要解释
运行的编程语言，比如BASIC. 区别是ML语言在空间上偏向于动态，而时间上
偏向于静态，BASIC在空间上偏向于静态，而时间上偏向于动态。 |
|
G****e
发帖数: 1912 | 22 1. javascript, 或者说是ECMAScript, 是我见过设计最优雅的脚本语言. 因为历史原
因有一些恶心的东西, 但并不是语言本身的问题. 在我看来Javascript可以和编译型的
pascal,以及functional的haskell媲美.
2. javascript基本上是平台无关的. 不需要什么开发环境, 只要有浏览器的地方就可
以编程序. 你能随身带着C++编译器或者python解释器到处跑吗?
3. 就业机会丰富. 当今这世道有那个网站不用javascript的? 虽然很多都是低层次的
客户端编程, 但是...
4. javascript的事件驱动机制为多核系统提供了另一种并行化的可能. 这一点是别的
语言不具备的. javascript在server端和高性能计算的应用已经初见端倪. 关于事件和
线程这两种编程模式的讨论由来已久. 一般认为事件能提供更高的性能, 但是基于事件
的编程在传统的C/C++中相对困难, 以致线程一直占据了统治地位. Javascript的二次
兴起将在近几年打开一个全新的局面.
5. 解释器支持强劲. 目前各大浏览器都在拼命提升j... 阅读全帖 |
|
c****x
发帖数: 6601 | 23 发信人: MoneyPort (MoneyPort), 信区: Programming
标 题: 王垠：我为什么不在乎人工智能
发信站: BBS 未名空间站 (Thu Apr 27 18:20:23 2017, 美东)
来源：王垠
www.yinwang.org/blog-cn/2017/04/23/ai
如有好文章投稿，请点击 → 这里了解详情
有人听说我想创业，给我提出了一些“忽悠”的办法。他们说，既然你是程序语言专家
，而现在人工智能（AI）又非常热，那你其实可以搞一个“自动编程系统”，号称可以
自动生成程序，取代程序员的工作，节省许许多多的人力支出，这样就可以趁着“AI
热”拉到投资。
有人甚至把名字都给我想好了，叫“深度程序员”（DeepCoder = Deep Learning +
Coder）。口号是：“有了 DeepCoder，不用 Top Coder！” 还有人给我指出了这方向
最新的，吹得神乎其神的研究，比如微软的 Robust Fill……
我谢谢这些人的关心，然而其实我并不在乎，也不看好人工智能。现在我简单的讲一下
我的看法。
机器一样的心
很多人喜欢鼓吹人工... 阅读全帖 |
|
g***n
发帖数: 14250 | 24 写个解释器那不是浪费生命吗
: 王垠说cs功夫深就一定要学一下编程语言，写个解释器啥的，我觉得他说的很对。
|
|
n****Z
发帖数: 1069 | 25 统计版讨论的编程问题，其实是许多CS出身码工在做的东西，但是现在编程工具的发展
，使得非C的人也可以很容易编程实现idea，所以coding方面，CS出身已经没啥优势了
，反而统计这些专业知识是CSer们欠缺的。
本来CSer们的本分工作是开发编程工具给非CSer们编程用，比如写编译器/解释器，或
者实现底层的协议/OS，但大部分CS码工根本写不出工业级的编译器/解释器，而且业界
也不需要这么多人搞这些东西，底层协议/OS该有的东西也做得差不多了，很难有突破
。等现有编程工具进一步发展，CS就是下一个生物专业，码工白菜价不是梦 |
|
a********5
发帖数: 1631 | 26 动态类型语言最大的问题不是性能（性能已经很少成为一个瓶颈了），而是动态类型带
来的维护、重构、重写困难。
弱类型语言的可读性是一个天然的问题。另外弱类型语言的编译器、解释器能抓到的错
比强类型少。
强类型：开发累，语法冗余，框架冗余，编译过了就解决很多问题，RUNTIME问题少，
容易定位，可读性强。
弱类型：开发爽，编译、解释器基本不干啥事，问题全是RUNTIME问题，DEBUG蛋疼，可
读性弱，而且不同人写出来的代码差别太大导致难以维护。
SCALA是强类型。但是语法糖太多，加之是OO和FP的混合体，导致同样的逻辑有若干种
完全不同的写法。。也是难读难维护，不过只是自己玩玩其实还不错 |
|
s****c
发帖数: 11300 | 27 什么叫外设全部支持64位？ 除了cpu之外64位操作系统难道对其他的设备还有要求？
你说的某个关键硬件指的是啥？硬盘还是显卡还是主板？ laf
至于你后面提到的，64位程序跟32位程序在现在的执行效率问题，我以前已经说过了，
通俗点说，现在的windows based X64操作系统都是混合操作系统，32位和64位有各自
的的程序解释器和运行空间，从这个角度来看，运行32bit程序并不会比纯32bit系统慢
，而64bit程序更没有可比性，因为32bit系统根本就运行不了。你非得用同一套源代码
用不同的编译器编译后来比较耗内存量，我不得不说这个比较无聊。如果有这种可能的
话我用16bit的操作系统可能会更节省内存，你为什么不返回去继续用windows 3.2呢？
64bit系统是会占用更多的内存，这并不是单纯由你说的地址空间带来的改变造成的。
实际上更多的是由于上面双解释器系统的存在造成的，是为了照顾兼容性而造成的。比
较一下各个windows based操作系统的大小，你可以很明显看到光盘容量的差距。
现在看来，64bit系统唯一的缺点是所有的驱动都需要64bit的版本，这个不能使用 |
|
|
kx
发帖数: 16384 | 29 【 以下文字转载自 TopArticle 讨论区 】
发信人: wdong (cybra), 信区: Programming
标 题: javascript才是未来发展的方向
发信站: BBS 未名空间站 (Wed Nov 24 10:11:23 2010, 美东)
我老给你们正在纠结学哪种语言的人指条明路吧. 理由如下.
1. javascript, 或者说是ECMAScript, 是我见过设计最优雅的脚本语言. 因为历史原因
有一些恶心的东西, 但并不是语言本身的问题. 在我看来Javascript可以和编译型的pa
scal,以及functional的haskell媲美.
2. javascript基本上是平台无关的. 不需要什么开发环境, 只要有浏览器的地方就可以
编程序. 你能随身带着C++编译器或者python解释器到处跑吗?
3. 就业机会丰富. 当今这世道有那个网站不用javascript的? 虽然很多都是低层次的
客户端编程, 但是...
4. javascript的事件驱动机制为多核系统提供了另一种并行化的可能. 这一点是别的语
言不具备的. javascri... 阅读全帖 |
|
X***y
发帖数: 3947 | 30 苹果II都是内置的basic解释器。II的时候已经彩色了。
俺的启蒙机是HK产的pc8300，后来咱北京计算机三厂出了个PC 81相当。都是z80的板子
。这玩意儿一共2k内存，内置的basic解释器还占去200多Byte.剩下的编游戏，得一
byte一byte地往回找巴。俺还凭它得过儿童计算机世界报3等奖。奖品是一科学计算器
。上面一堆按钮，设计得非常tm的不科学。这机器有个压电陶瓷片作喇叭，还能很容易
地输入乐谱。好多不会的流行歌曲，我都是把小摊上买的照相复制的歌篇上的简谱输入
这玩意儿学的。其实就一midi。 |
|
C********s
发帖数: 120 | 31 从本质上说，就是emacs本身就是elisp的解释器。你写的任何对
emacs的外挂都可以即时在emacs里编辑、修改、运行、查错、成为
emacs的一部分而~无需重启~。emacs的任何功能都是elisp函数，
对用户开放，可以修改、重写。elisp本身是lisp的一个变种，继承
了lisp简洁优雅的语法和强大的表现力，而且有着多年积累的丰富
的各类文本处理API。
不服气的用vimscript实现一下emacs calc。我觉得python binding
也没法和emacs比，如果起一个vim就要起一个python解释器vim本来
相对emacs的轻便也就不存在了，而且还要面对python的版本升级、
可移植性、库函数的升级维护问题。
从使用习惯上来说，vim用户的习惯大概都差不多，而emacs用户很
少能找到两个使用方法完全一样的。从功能上来说，emacs里集成
其它功能很普遍很常见，谁在vim里读邮件听mp3发tweet上IRC? |
|
w***g
发帖数: 5958 | 32 【 以下文字转载自 Programming 讨论区 】
发信人: wdong (cybra), 信区: Programming
标 题: javascript才是未来发展的方向
发信站: BBS 未名空间站 (Wed Nov 24 10:11:23 2010, 美东)
我老给你们正在纠结学哪种语言的人指条明路吧. 理由如下.
1. javascript, 或者说是ECMAScript, 是我见过设计最优雅的脚本语言. 因为历史原因
有一些恶心的东西, 但并不是语言本身的问题. 在我看来Javascript可以和编译型的pa
scal,以及functional的haskell媲美.
2. javascript基本上是平台无关的. 不需要什么开发环境, 只要有浏览器的地方就可以
编程序. 你能随身带着C++编译器或者python解释器到处跑吗?
3. 就业机会丰富. 当今这世道有那个网站不用javascript的? 虽然很多都是低层次的
客户端编程, 但是...
4. javascript的事件驱动机制为多核系统提供了另一种并行化的可能. 这一点是别的语
言不具备的. javascr... 阅读全帖 |
|
wy
发帖数: 14511 | 33 也不是，你当然可以自己写一个js的解释器。不过用楼主的话
说：说没事带着一个js的解释器乱跑？ |
|
m********5
发帖数: 17667 | 34 没有用，和matlab p-code不同的，这个加密需要解释器支持，所以python是不可能闭
源的。你的程序最终是要在解释器运行，所以可以直接完美反编译出来。
另外建议开源，这年头搞封闭没有意义，除非你完全基于非开源库，不然就算你真封闭
了，真到了必要的时候，别人还是能逼你开源
还不如一开始就主动开源，让用户群丰满起来，靠捐赠和收费feature request都比你
闭源更有效更早更持久地赚到钱。
最近发现有些领域太恶心了，发文章的code都闭源，很多reviewer抗议后居然拿个埋了
大量p-code的源出来, 我已经写信直接去编辑部和他学校投诉了，他们当时用公共经费
做得项目，资助要求就是要开源，真不像话。 |
|
w***g
发帖数: 5958 | 35 我不喜欢python的理由是python那批人打着反对premature optimization为理由编写劣
质代码，并且到处reimplement wheels。其中最典型的就是python解释器。同为解释型
或半解释型语言，python在速度上要比perl或者java慢一个数量级。我不知道除了不做
"premature optimization"以外还有别的任何理由能把一个解释器做的如此之慢。 |
|
w***g
发帖数: 5958 | 36 我老给你们正在纠结学哪种语言的人指条明路吧. 理由如下.
1. javascript, 或者说是ECMAScript, 是我见过设计最优雅的脚本语言. 因为历史原因
有一些恶心的东西, 但并不是语言本身的问题. 在我看来Javascript可以和编译型的pa
scal,以及functional的haskell媲美.
2. javascript基本上是平台无关的. 不需要什么开发环境, 只要有浏览器的地方就可以
编程序. 你能随身带着C++编译器或者python解释器到处跑吗?
3. 就业机会丰富. 当今这世道有那个网站不用javascript的? 虽然很多都是低层次的
客户端编程, 但是...
4. javascript的事件驱动机制为多核系统提供了另一种并行化的可能. 这一点是别的语
言不具备的. javascript在server端和高性能计算的应用已经初见端倪. 关于事件和线
程这两种编程模式的讨论由来已久. 一般认为事件能提供更高的性能, 但是基于事件的
编程在传统的C/C++中相对困难, 以致线程一直占据了统治地位. Javascript的二次兴起
将在近几年打开一个全... 阅读全帖 |
|
w***g
发帖数: 5958 | 37 我老给你们正在纠结学哪种语言的人指条明路吧. 理由如下.
1. javascript, 或者说是ECMAScript, 是我见过设计最优雅的脚本语言. 因为历史原因
有一些恶心的东西, 但并不是语言本身的问题. 在我看来Javascript可以和编译型的pa
scal,以及functional的haskell媲美.
2. javascript基本上是平台无关的. 不需要什么开发环境, 只要有浏览器的地方就可以
编程序. 你能随身带着C++编译器或者python解释器到处跑吗?
3. 就业机会丰富. 当今这世道有那个网站不用javascript的? 虽然很多都是低层次的
客户端编程, 但是...
4. javascript的事件驱动机制为多核系统提供了另一种并行化的可能. 这一点是别的语
言不具备的. javascript在server端和高性能计算的应用已经初见端倪. 关于事件和线
程这两种编程模式的讨论由来已久. 一般认为事件能提供更高的性能, 但是基于事件的
编程在传统的C/C++中相对困难, 以致线程一直占据了统治地位. Javascript的二次兴起
将在近几年打开一个全... 阅读全帖 |
|
a*****e
发帖数: 1700 | 38 如果你说的高效是指快速实现一个DSL的解释器，那么上面我给的那个blog链接是个很
好的例子。
首先，它绕过了 parser，因为程序本身虽然看起来象 BASIC，但实际上都是 Haskell
，直接代表 AST，所以省去很多前期的麻烦。这就叫做 embeded DSL。只需要定义
合适的 AST，然后对之进行 pattern match 解释执行就好了。
其次，embedded DSL 可以直接使用 host language 里面的值和函数，比如数字表达式
什么的，直接用，无须单独处理。你要做的工作可以完全放在你所定义的 DSL 的核心语
义上面。
最后，如果你追求 DSL 本身运行起来的效率，那么可以采取 finally taggless 的方
式，定义 combinator 来组建 DSL，它们本身就是 host language 里的函数，由
host language 的编译器直接编译，无须另写 AST 和解释器。我上面给的 Oleg 的链
接里有这个 paper。
所以从 embedded DSL 入手，实现一个新的 DSL 过程被大大简化，应该是相当有效率
的。
如果你... 阅读全帖 |
|
a*****e
发帖数: 1700 | 39 你说的这个是经典的解释器，用户并不直接接触到实际的编译器，而是通过网站或什么
别的途径输入写好的脚本，你在后台来执行它。我这样理解没错吧？
你可以分两步走，第一步，先把 DSL AST 所需要的 data type 定义出来，然后对此写
一个解释器。调试过程中，可以直接用 datatype 写 AST，省去写 parser 的麻烦。
第一步做好了，然后就可以用 haskell parsec 之类的库把程序输入的字串转换为 AST
，略为学习一下 parsec 的用法就好了，简单的 recursive descent。
做 embeded DSL 可以省去第二步，但的确，在你的情况中，还是需要一个 parser 的
部分。 |
|
a*****e
发帖数: 1700 | 40 如果你说的高效是指快速实现一个DSL的解释器，那么上面我给的那个blog链接是个很
好的例子。
首先，它绕过了 parser，因为程序本身虽然看起来象 BASIC，但实际上都是 Haskell
，直接代表 AST，所以省去很多前期的麻烦。这就叫做 embeded DSL。只需要定义
合适的 AST，然后对之进行 pattern match 解释执行就好了。
其次，embedded DSL 可以直接使用 host language 里面的值和函数，比如数字表达式
什么的，直接用，无须单独处理。你要做的工作可以完全放在你所定义的 DSL 的核心语
义上面。
最后，如果你追求 DSL 本身运行起来的效率，那么可以采取 finally taggless 的方
式，定义 combinator 来组建 DSL，它们本身就是 host language 里的函数，由
host language 的编译器直接编译，无须另写 AST 和解释器。我上面给的 Oleg 的链
接里有这个 paper。
所以从 embedded DSL 入手，实现一个新的 DSL 过程被大大简化，应该是相当有效率
的。
如果你... 阅读全帖 |
|
a*****e
发帖数: 1700 | 41 你说的这个是经典的解释器，用户并不直接接触到实际的编译器，而是通过网站或什么
别的途径输入写好的脚本，你在后台来执行它。我这样理解没错吧？
你可以分两步走，第一步，先把 DSL AST 所需要的 data type 定义出来，然后对此写
一个解释器。调试过程中，可以直接用 datatype 写 AST，省去写 parser 的麻烦。
第一步做好了，然后就可以用 haskell parsec 之类的库把程序输入的字串转换为 AST
，略为学习一下 parsec 的用法就好了，简单的 recursive descent。
做 embeded DSL 可以省去第二步，但的确，在你的情况中，还是需要一个 parser 的
部分。 |
|
N*******t
发帖数: 66 | 42 解释器的实现差不多60K行C代码，比Perl, Python和Ruby等的解释器小很多，但语言特
性的丰富程度差不多接近他们了。
当然和Lua比，算比较大了。 |
|
z****e
发帖数: 54598 | 43 他说的批评就是这个啦
“所以我认为脚本语言是一个祸害，它几乎永远是错误的决定。”
什么是“脚本语言”
很多人都会用一些“脚本语言”（scripting language），却很少有人真正的知道到底
什么是脚本语言。很多人用 shell 写一些“脚本”来完成日常的任务，用 Perl 或者
sed 来处理一些文本文件，很多公司用“脚本”来跑它们的“build”（叫做 build
script）。那么，到底什么是“脚本语言”与“非脚本语言”的区别呢？
其实“脚本语言”与“非脚本语言”并没有语义上，或者执行方式上的区别。它们的区
别只在于它们设计的初衷：脚本语言的设计，往往是作为一种临时的“补丁”。它的设
计者并没有考虑把它作为一种“通用程序语言”，没有考虑用它构建大型的软件。这些
设计者往往没有经过系统的训练，有些甚至连最基本的程序语言概念都没搞清楚。相反
，“非脚本”的通用程序语言，往往由经过严格训练的专家甚至一个小组的专家设计，
它们从一开头就考虑到了“通用性”，以及在大型工程中的可靠性和可扩展性。
首先我们来看看“脚本”这个概念是如何产生的。使用 Unix 系统的人都会敲入一些命
令，... 阅读全帖 |
|
c*******9
发帖数: 9032 | 44 解释器没有优化，是为了使用直观方便，haskell有其他解释器可用，只不过复杂一些
，java要实现高性能解机器也要费一番周折。 |
|
c*******9
发帖数: 9032 | 45 解释器没有优化，是为了使用直观方便，haskell有其他解释器可用，只不过复杂一些
，java要实现高性能解机器也要费一番周折。 |
|
h*i
发帖数: 3446 | 46 R我用的很多，这不是一个程序员的语言。
搞Clojure的人不可能来写个R的解释器的，因为R的作者自己都后悔没把R搞成Lisp(见
此文：Back to the Future: Lisp as a Base for a Statistical Computing System
。 https://www.stat.auckland.ac.nz/~ihaka/downloads/Compstat-2008.pdf)。所以
搞Clojure的人很早就搞了个叫incanterhttp://incanter.org/的东东，试图来实现R的原作者的这个Lisp型的R的愿望。
不过R在统计界的地位已经不可动摇了，所以我觉得incanter不会成功。renjin这种也
不行，光有R的解释器没用，因为R不是一个语言，而是一个生态环境。这些JVM上的R模
拟器只要不能直接用R的库，就没有用处，因为用R的一个原因，就是库应有尽有，而且
新的统计文章出来，必然配有相应的R代码，这个没法比。 |
|
w***g
发帖数: 5958 | 47 都不是。javascript的解释器做得快。python和ruby啥的，语言上没本质差别，
慢就慢在解释器太烂。 |
|
s*****r
发帖数: 550 | 48 还是没有解决我的疑问
vertx是如何实现polyglot的？
是他有不同语言的基于JVM的解释器么？
例如它自带Jython解释器解释python？
还是他提供了python的接口？？？
不好意思，比较弱，希望大侠们能帮我解惑 |
|
n******7
发帖数: 12463 | 49 我大致知道他做了个啥
问题是他claim了三点：
1. 这个东西比uglify功能更全：
“不要小看了这个 JS 混淆器，它的强度跟 uglify 之类的开源工具比，是天上地下的
。它不但包含了 uglify 的变量换名等基本功能，而且含有专门针对人类和编译器的复
杂化，使得没有人能看出一点线索这个程序到底要干什么，让最先进的 JS 编译器也无
法把它简化，从而让人有可以理解它的机会。”
我看了一下UglifyJS 和 UglifyJS2 都是5K+ star的nb项目。他做的要是比这个功能更
多，我看可以一战成名，也不用老提pysonar了
2.bug free：
“我不知道他们怎么好意思说出这样的话来，因为事实是，他们花了这么多个月，耗费
这么多人力，写了这么多的测试，做出来的换名器却仍然有 bug，没法用。当我把我写
的测试和几个大点的 open source 项目（AngularJS, Backbone 等）放进他们的换名
器之后，就发现有些地方出问题了，而所有的测试和 open source 项目通过我的换名
器，却得到完全正确的代码。另外经过性能测试，我的换名器速度要快四倍... 阅读全帖 |
|
d***a
发帖数: 13752 | 50 他"claim"了三点。大家不知道别的当事人是如何说的。就算他做到了又如何？这就象
一个拿A-的学生做出了一道题，而拿B/C的学生觉得那题很难，那学生就觉得自己很牛
了。
“不要小看了这个 JS 混淆器，它的强度跟 uglify 之类的开源工具比，是天上地下的
。它不但包含了 uglify 的变量换名等基本功能，而且含有专门针对人类和编译器的复
杂化，使得没有人能看出一点线索这个程序到底要干什么，让最先进的 JS 编译器也无
法把它简化”
这听起来非常不靠谱，除非王垠在理论上证明了这一点。黑客难道是吃素的?
"我采用了从 Chez Scheme 编译器学过来的，非常严密的测试方法。对每一个编译器的
步骤（pass），我都给它设计一些正好可以测到这个步骤的输入代码（比如，具有函数
定义的，for循环，try-catch的，等等）。Pass 输出的代码，经过 JavaScript 解释
器执行，把结果跟原来程序的执行结果对比。"
这一段听起来靠谱，王垠是用了比较规范，有针对性的测试方法。
“由于轻车熟路，我只花了一下午的时间，不费吹灰之力，就完成了一个正确的换名器
，它完全符合JavaSc... 阅读全帖 |
|
