惹了众怒，二比省长被暴是表哥 (转载)# Joke - 肚皮舞运动
a*n
1 楼
Kinson的账号已经清空了纪录。他明白你的钱肯定是捐款。所以不需要留notes。
PayPal发现就麻烦了。我们有三个人监督这个账户。每几个小时公布一次update.所以
请放心。
PayPal发现就麻烦了。我们有三个人监督这个账户。每几个小时公布一次update.所以
请放心。
e*a
2 楼
Ruby能做的，Java都能做。
与 Java 相比，Ruby 有啥优势？
与 Java 相比，Ruby 有啥优势？
l*t
3 楼
小面额的100,200的喂起来很麻烦，不知道有没有一个transaction 喂多张VGC的办法？
例如一次性add $1000,可以连续刷5张200的卡吗？还是必须一个transaction一张VGC呢？
听说红鸟有办法可以这么干，不知道蓝鸟能不能
例如一次性add $1000,可以连续刷5张200的卡吗？还是必须一个transaction一张VGC呢？
听说红鸟有办法可以这么干，不知道蓝鸟能不能
C*l
4 楼
【 以下文字转载自 Military 讨论区 】
发信人: G99991 (99991), 信区: Military
标 题: 惹了众怒，二比省长被暴是表哥
发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
二比省长不知道闷声发大财
发信人: G99991 (99991), 信区: Military
标 题: 惹了众怒，二比省长被暴是表哥
发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
二比省长不知道闷声发大财
m*r
5 楼
3-4个ip同时登陆一个paypal账户？
还有大批金额不等的款项汇入，还是近期。
这个如果你是paypal不review你，你觉得说的过去吗？
【在 a*******n 的大作中提到】
: Kinson的账号已经清空了纪录。他明白你的钱肯定是捐款。所以不需要留notes。
: PayPal发现就麻烦了。我们有三个人监督这个账户。每几个小时公布一次update.所以
: 请放心。
还有大批金额不等的款项汇入，还是近期。
这个如果你是paypal不review你，你觉得说的过去吗？
【在 a*******n 的大作中提到】
: Kinson的账号已经清空了纪录。他明白你的钱肯定是捐款。所以不需要留notes。
: PayPal发现就麻烦了。我们有三个人监督这个账户。每几个小时公布一次update.所以
: 请放心。
p*2
6 楼
rails
functional
dynamic
rapid development
more fun
but will lose to node.js.
functional
dynamic
rapid development
more fun
but will lose to node.js.
M*M
7 楼
试过一次共600，三张200的可以，据说最多可以一次四张。问题是很多客服不会操作，
很容易造成死机，要用钥匙解锁。有次拿钥匙的经理一时找不到，后面一下排了十几个
人，一个个唉声叹气显出不赖烦的样子，我只好说不LOAD了，转身走了。以后都是一张
张老老实实LOAD，可以用不同的CHECKOUT LANE，我一般一次LOAD两张，打一枪再换一
个地方。
很容易造成死机，要用钥匙解锁。有次拿钥匙的经理一时找不到，后面一下排了十几个
人，一个个唉声叹气显出不赖烦的样子，我只好说不LOAD了，转身走了。以后都是一张
张老老实实LOAD，可以用不同的CHECKOUT LANE，我一般一次LOAD两张，打一枪再换一
个地方。
t*t
8 楼
我就认出casio了。
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
P*K
9 楼
还是新的帐号？
那几乎肯定会被limit
【在 m*r 的大作中提到】
: 3-4个ip同时登陆一个paypal账户？
: 还有大批金额不等的款项汇入，还是近期。
: 这个如果你是paypal不review你，你觉得说的过去吗？
那几乎肯定会被limit
【在 m*r 的大作中提到】
: 3-4个ip同时登陆一个paypal账户？
: 还有大批金额不等的款项汇入，还是近期。
: 这个如果你是paypal不review你，你觉得说的过去吗？
b*e
10 楼
Man, you have a true enthusiasm in node, even crazier than me.
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
M*M
11 楼
一条CHECKOUT LANE LOAD 两张，但分两次，多了小二烦，后面其他顾客也排上队了。
p*p
12 楼
名牌
【在 t**t 的大作中提到】
: 我就认出casio了。
【在 t**t 的大作中提到】
: 我就认出casio了。
k*z
13 楼
it will be fine. paypal will hold it for a while and finally relese to you.
not big deal
【在 m*r 的大作中提到】
: 3-4个ip同时登陆一个paypal账户？
: 还有大批金额不等的款项汇入，还是近期。
: 这个如果你是paypal不review你，你觉得说的过去吗？
not big deal
【在 m*r 的大作中提到】
: 3-4个ip同时登陆一个paypal账户？
: 还有大批金额不等的款项汇入，还是近期。
: 这个如果你是paypal不review你，你觉得说的过去吗？
e*a
14 楼
how about sencha/html5?
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
y*i
15 楼
1 card 1 transaction at ATM
up to 3 cards 1 transaction at POS
呢？
【在 l*********t 的大作中提到】
: 小面额的100,200的喂起来很麻烦，不知道有没有一个transaction 喂多张VGC的办法？
: 例如一次性add $1000,可以连续刷5张200的卡吗？还是必须一个transaction一张VGC呢？
: 听说红鸟有办法可以这么干，不知道蓝鸟能不能
up to 3 cards 1 transaction at POS
呢？
【在 l*********t 的大作中提到】
: 小面额的100,200的喂起来很麻烦，不知道有没有一个transaction 喂多张VGC的办法？
: 例如一次性add $1000,可以连续刷5张200的卡吗？还是必须一个transaction一张VGC呢？
: 听说红鸟有办法可以这么干，不知道蓝鸟能不能
l*y
16 楼
带块好表怎么了？抽棵好烟怎么了。没从你兜里拿钱，管得着么。
羡慕嫉妒恨。
羡慕嫉妒恨。
a*e
17 楼
hold个半年呢。。。。
【在 k*z 的大作中提到】
: it will be fine. paypal will hold it for a while and finally relese to you.
: not big deal
【在 k*z 的大作中提到】
: it will be fine. paypal will hold it for a while and finally relese to you.
: not big deal
c*a
18 楼
java code又长又臭.....最近用过java, node js写service，区别太大了
H*7
19 楼
脑袋看着别扭
k*z
20 楼
就几千的话，我替kision先给了。退回来给我。
【在 a******e 的大作中提到】
: hold个半年呢。。。。
【在 a******e 的大作中提到】
: hold个半年呢。。。。
z*3
21 楼
任何脚本语言跟高级语言相比
开发效率永远都是优势
无论这个脚本是python还是ruby还是php还是sql还是javascript还是shell script
也无论后面的高级语言是java还是c++
当你还在为java里面各种类型是不是对象而烦恼的时候
人家hello world已经出来了，但是作为trade off
脚本语言需要一个相对成熟的平台
比如os，比如db，比如browser，比如web server
所以比较局限在某一个领域里面
开发效率永远都是优势
无论这个脚本是python还是ruby还是php还是sql还是javascript还是shell script
也无论后面的高级语言是java还是c++
当你还在为java里面各种类型是不是对象而烦恼的时候
人家hello world已经出来了，但是作为trade off
脚本语言需要一个相对成熟的平台
比如os，比如db，比如browser，比如web server
所以比较局限在某一个领域里面
f*y
22 楼
我支持这位副省长，他说了真话实话。
至于说那些在微波上高潮了的2比，包括这位lz，我只想说：这么气急败坏，戳着你们
的痛处了吧？卖国加卖比的2比玩意儿！
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
至于说那些在微波上高潮了的2比，包括这位lz，我只想说：这么气急败坏，戳着你们
的痛处了吧？卖国加卖比的2比玩意儿！
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
a*n
23 楼
Kiz is a true man!
【在 k*z 的大作中提到】
: 就几千的话，我替kision先给了。退回来给我。
【在 k*z 的大作中提到】
: 就几千的话，我替kision先给了。退回来给我。
p*2
24 楼
大牛我现在再搞clojure.
【在 b***e 的大作中提到】
: Man, you have a true enthusiasm in node, even crazier than me.
g*n
25 楼
省长带这样的表明显是装B
n*l
26 楼
agree!!
【在 a*******n 的大作中提到】
: Kiz is a true man!
【在 a*******n 的大作中提到】
: Kiz is a true man!
w*z
27 楼
does node.js perform well under high load ?
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
H*7
28 楼
副省级还是老实点好。正省级以上中央才会考虑保不保
a*e
29 楼
赞
【在 k*z 的大作中提到】
: 就几千的话，我替kision先给了。退回来给我。
【在 k*z 的大作中提到】
: 就几千的话，我替kision先给了。退回来给我。
z*3
30 楼
开发人员还是不能仅局限在脚本语言里面
脚本语言就是司机
但是现实中需要开发人员做适当的创造
而不是只会用就好了
实际上各个脚本的trade off很明显
有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
还有就是各个脚本类型往往很自由
写js经常被jquery里面的${}到底指代的是哪个而烦恼
但是这些东西在小规模时候，都不是问题，但是一旦做大了
那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
想不了那么远，东西赶快做出来融资要紧，做大了再改
以前java程序猿经常用的是其它三种脚本和两个置标
三个脚本是sql, shell和javascript，两个置标是html和xml
加上java本身，这就六种语言了，要说难嘛
也不难，这些学过cs基础课，基本上都会
转行的往往短板在这几个地方
脚本语言就是司机
但是现实中需要开发人员做适当的创造
而不是只会用就好了
实际上各个脚本的trade off很明显
有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
还有就是各个脚本类型往往很自由
写js经常被jquery里面的${}到底指代的是哪个而烦恼
但是这些东西在小规模时候，都不是问题，但是一旦做大了
那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
想不了那么远，东西赶快做出来融资要紧，做大了再改
以前java程序猿经常用的是其它三种脚本和两个置标
三个脚本是sql, shell和javascript，两个置标是html和xml
加上java本身，这就六种语言了，要说难嘛
也不难，这些学过cs基础课，基本上都会
转行的往往短板在这几个地方
c*i
31 楼
叶公主啐你一脸狗屎
【在 f**********y 的大作中提到】
: 我支持这位副省长，他说了真话实话。
: 至于说那些在微波上高潮了的2比，包括这位lz，我只想说：这么气急败坏，戳着你们
: 的痛处了吧？卖国加卖比的2比玩意儿！
【在 f**********y 的大作中提到】
: 我支持这位副省长，他说了真话实话。
: 至于说那些在微波上高潮了的2比，包括这位lz，我只想说：这么气急败坏，戳着你们
: 的痛处了吧？卖国加卖比的2比玩意儿！
z*3
32 楼
你们打算换nodejs写web？
【在 w**z 的大作中提到】
: does node.js perform well under high load ?
【在 w**z 的大作中提到】
: does node.js perform well under high load ?
f*m
33 楼
哈哈，太逗了，sb狗粮们真是幽默
c*a
34 楼
node js更新太快了吧...
c*h
35 楼
一个副省级如果就这么几块表也不算啥事。懂行的来说说究竟多少钱？
p*2
36 楼
纯异步应该不差吧？
【在 w**z 的大作中提到】
: does node.js perform well under high load ?
h*g
37 楼
没几块值钱的。
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
【在 C*********l 的大作中提到】
: 【 以下文字转载自 Military 讨论区 】
: 发信人: G99991 (99991), 信区: Military
: 标 题: 惹了众怒，二比省长被暴是表哥
: 发信站: BBS 未名空间站 (Mon Jul 29 09:32:27 2013, 美东)
: 二比省长不知道闷声发大财
l*n
38 楼
反驳下gc的问题：不是个问题。
http://stackoverflow.com/questions/7347203/circular-references-
js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
http://stackoverflow.com/questions/7347203/circular-references-
js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
a*a
39 楼
戴电子表的能是什么表哥。
z*3
40 楼
当你把希望寄托在文档和注释的完整上的时候
你就已经失败了
就像你反驳的那个引用里面的“Most” garbage collectors don't do
这种most，也许，或者等各种不严谨可以让项目在做大之后华丽滴垮掉
千里之提
吗？
【在 l*n 的大作中提到】
: 反驳下gc的问题：不是个问题。
: http://stackoverflow.com/questions/7347203/circular-references-
: js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
: software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
: 需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
你就已经失败了
就像你反驳的那个引用里面的“Most” garbage collectors don't do
这种most，也许，或者等各种不严谨可以让项目在做大之后华丽滴垮掉
千里之提
吗？
【在 l*n 的大作中提到】
: 反驳下gc的问题：不是个问题。
: http://stackoverflow.com/questions/7347203/circular-references-
: js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
: software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
: 需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
t*t
41 楼
好了是表哥，差了装B，难啊。
【在 g******n 的大作中提到】
: 省长带这样的表明显是装B
【在 g******n 的大作中提到】
: 省长带这样的表明显是装B
b*e
42 楼
Google V8 uses full fledged incremental mark & copy technology for
garbage collection, which is, if not more, the same strong as
most JVM garbage collection.
The only language that I know who's stilling doing reference
counting is PHP . Objective C (IOS) sort of does reference
counting, but it's soft garbage collection as you can always use
explicit language primitives to deallocate memory.
I think you just lack basic experience in JS, in which case, I
really suggest you STFU.
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
garbage collection, which is, if not more, the same strong as
most JVM garbage collection.
The only language that I know who's stilling doing reference
counting is PHP . Objective C (IOS) sort of does reference
counting, but it's soft garbage collection as you can always use
explicit language primitives to deallocate memory.
I think you just lack basic experience in JS, in which case, I
really suggest you STFU.
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
M*e
43 楼
这是不配合起来的炒作？
z*3
44 楼
你应该意识到，v8!=all javascript engines，甚至连default engine都不是
就好比当你说sql的一些问题的时候，有人跳出来说
oracle db不会有这些问题，oracle db没有某些问题，并不代表其他db不会有这些问题
事实上这种差异更增加了问题的严重性，因为当你从一个平台换到另外一个平台上去的
时候
你有可能会遇到之前没有遇到的问题，那这个所带来的后果，往往是灾难性的
well，我不否认在某些领域，脚本做的的确不错
事实上这些脚本被发明出来，本身就是打算强化或者说简化某一个领域的开发的
如果这些都做不好，那完蛋了
脚本在特定领域，可以看作是高级语言的简化版
通过简化语法以及弱化内在概念性的东西
以达到让开发人员快速掌握上手并开发的目的
而且就脚本而言，javascript做得其实并不好
事实上人们已经在考虑用更为简化的脚本来替换javascript了
比如coffeescript
【在 b***e 的大作中提到】
: Google V8 uses full fledged incremental mark & copy technology for
: garbage collection, which is, if not more, the same strong as
: most JVM garbage collection.
: The only language that I know who's stilling doing reference
: counting is PHP . Objective C (IOS) sort of does reference
: counting, but it's soft garbage collection as you can always use
: explicit language primitives to deallocate memory.
: I think you just lack basic experience in JS, in which case, I
: really suggest you STFU.
就好比当你说sql的一些问题的时候，有人跳出来说
oracle db不会有这些问题，oracle db没有某些问题，并不代表其他db不会有这些问题
事实上这种差异更增加了问题的严重性，因为当你从一个平台换到另外一个平台上去的
时候
你有可能会遇到之前没有遇到的问题，那这个所带来的后果，往往是灾难性的
well，我不否认在某些领域，脚本做的的确不错
事实上这些脚本被发明出来，本身就是打算强化或者说简化某一个领域的开发的
如果这些都做不好，那完蛋了
脚本在特定领域，可以看作是高级语言的简化版
通过简化语法以及弱化内在概念性的东西
以达到让开发人员快速掌握上手并开发的目的
而且就脚本而言，javascript做得其实并不好
事实上人们已经在考虑用更为简化的脚本来替换javascript了
比如coffeescript
【在 b***e 的大作中提到】
: Google V8 uses full fledged incremental mark & copy technology for
: garbage collection, which is, if not more, the same strong as
: most JVM garbage collection.
: The only language that I know who's stilling doing reference
: counting is PHP . Objective C (IOS) sort of does reference
: counting, but it's soft garbage collection as you can always use
: explicit language primitives to deallocate memory.
: I think you just lack basic experience in JS, in which case, I
: really suggest you STFU.
w*z
45 楼
a small portion is already on node. js, but that is for web team, we are
still moving to Java from php.
【在 z*******3 的大作中提到】
: 你们打算换nodejs写web？
still moving to Java from php.
【在 z*******3 的大作中提到】
: 你们打算换nodejs写web？
p*n
46 楼
这个说得中恳贴切。
【在 z*******3 的大作中提到】
: 任何脚本语言跟高级语言相比
: 开发效率永远都是优势
: 无论这个脚本是python还是ruby还是php还是sql还是javascript还是shell script
: 也无论后面的高级语言是java还是c++
: 当你还在为java里面各种类型是不是对象而烦恼的时候
: 人家hello world已经出来了，但是作为trade off
: 脚本语言需要一个相对成熟的平台
: 比如os，比如db，比如browser，比如web server
: 所以比较局限在某一个领域里面
p*n
47 楼
FB 想改都改不了啦。
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
a*g
48 楼
这个（bash）shell语言用的是不是要吐血？
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
b*e
49 楼
第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
跟PHP一样，每个page都是short life cycle process/thread(depending on browser
implementation). 即使是single page architecture, 一般一个page也不会运行很长
时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
义上讲，v8 === JS engine。
第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
经被淘汰了，就像Java Applet和Java Swing这种垃圾一样。Ecmascript的语法和语义
非常的成熟，其运行环境的统一性和稳定性从来都没有比Java差过，如果不是比Java要
强的话。 之所以Javascript有众说纷纭的browser兼容的问题，主要是因为各个
browser对W3C Dom/Event的理解和实现不同。而且主要的不兼容性的问题也是出在低版
本的IE上。新版的IE与firefox和chrome相差无几。所以即便说广义上讲的JS，现在也
已经大统了。JS从语义的角度上讲，跨平台的问题已经不是网络应用开发的主要问题。
而且，所有的这些所谓跨平台的问题都是前台客户端的问题。用node.js做应用在实践
中没有跨平台的问题，就像Java在实践中没有跨平台的问题 一样。
第三，你对脚本语言的理解停留在shell和php上。我不否认这些语言的确是在设计上就
是为某些特定的任务量体裁衣。这些语言从诞生的第一天起就不是通用语言。但是，你
对其它的脚本语言，老一些的像perl, python, 新一些的像ruby, node.js缺乏最基本
的认识和了解，因为你根本就没有在实践的环境中体会过这些语言。这些语言本身就是
高级通用语言，其设计的思想和实践的目的和Java是一样的。从严格的意义上讲，它们
并不是特地为某种特定的工作设计的，即使在初期它们更多的被运用在某些工作上。你
要明白，第一，简洁的语法并不是简化的语法，就像中文并不比英文简化。 第二，对
语义(就是你所说的内在的概念性的东西)的封装和高层的解释是对语言的强化，不是弱
化，就像Java是对C的强化，C是对汇编的强化一样。
第四，相比静态类型检查的语言，动态类型检查的语言在表达能力(expressiveness)上
有着巨大的优势，因为没有静态类型检查可确定性(decidability)的羁绊和限制。有很
多语言的特性(feature)，例如多重继承(multiple inheritance), minxins, implicit
parameters, first class function closures, higher order functions, run-time
code generation, class group inheritance等等，在动态类型的语言里被支持的很
好，或者相比之下更容易被实现。而Java迟迟没有这些支持的原因是静态类型检查很困
难(intractable)。
第五，即便抛开node.js带来的event-based programming model, 纯粹的从语言的语义
角度上看，Javascript是我认为的最好的动态类型检查的语言。主要是因为它对高阶函
数的无缝支持和灵活的面相对象的继承。换句话说，它是函数式语言和面向对象语言的
完美结合。相较之下，Scala连门都没入。这极大地丰富的设计模式的可能性，其灵活
性经常远远超出了Java程序员的想象能力。唯一可以在表达性上可以和JS相比的是
Common Lisp。但是函数式语言毕竟是小众，并且Lisp本身的语法也过于奇葩。
Coffeescript就是JS的一个语法糖，根本连一个独立的语言都算不上。它和Javascript
的语义是一模一样的，没有任何简化或强化。事实上，我怀疑有任何人企图用
Coffeescript完全的替代Javascript。大多数人根本不用Coffeescript。有限的人用也
是在一些特定的情况下用。纯的Coffeescript程序员是极少的，如果存在的话。
第六，这么说吧，你做Java轮我是绝对没有问题的。Java是一个好语言，and I love
it (believe me, I do)。但是你不懂的东西甭乱喷。无知不是个性。
【在 z*******3 的大作中提到】
: 你应该意识到，v8!=all javascript engines，甚至连default engine都不是
: 就好比当你说sql的一些问题的时候，有人跳出来说
: oracle db不会有这些问题，oracle db没有某些问题，并不代表其他db不会有这些问题
: 事实上这种差异更增加了问题的严重性，因为当你从一个平台换到另外一个平台上去的
: 时候
: 你有可能会遇到之前没有遇到的问题，那这个所带来的后果，往往是灾难性的
: well，我不否认在某些领域，脚本做的的确不错
: 事实上这些脚本被发明出来，本身就是打算强化或者说简化某一个领域的开发的
: 如果这些都做不好，那完蛋了
: 脚本在特定领域，可以看作是高级语言的简化版
上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
跟PHP一样，每个page都是short life cycle process/thread(depending on browser
implementation). 即使是single page architecture, 一般一个page也不会运行很长
时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
义上讲，v8 === JS engine。
第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
经被淘汰了，就像Java Applet和Java Swing这种垃圾一样。Ecmascript的语法和语义
非常的成熟，其运行环境的统一性和稳定性从来都没有比Java差过，如果不是比Java要
强的话。 之所以Javascript有众说纷纭的browser兼容的问题，主要是因为各个
browser对W3C Dom/Event的理解和实现不同。而且主要的不兼容性的问题也是出在低版
本的IE上。新版的IE与firefox和chrome相差无几。所以即便说广义上讲的JS，现在也
已经大统了。JS从语义的角度上讲，跨平台的问题已经不是网络应用开发的主要问题。
而且，所有的这些所谓跨平台的问题都是前台客户端的问题。用node.js做应用在实践
中没有跨平台的问题，就像Java在实践中没有跨平台的问题 一样。
第三，你对脚本语言的理解停留在shell和php上。我不否认这些语言的确是在设计上就
是为某些特定的任务量体裁衣。这些语言从诞生的第一天起就不是通用语言。但是，你
对其它的脚本语言，老一些的像perl, python, 新一些的像ruby, node.js缺乏最基本
的认识和了解，因为你根本就没有在实践的环境中体会过这些语言。这些语言本身就是
高级通用语言，其设计的思想和实践的目的和Java是一样的。从严格的意义上讲，它们
并不是特地为某种特定的工作设计的，即使在初期它们更多的被运用在某些工作上。你
要明白，第一，简洁的语法并不是简化的语法，就像中文并不比英文简化。 第二，对
语义(就是你所说的内在的概念性的东西)的封装和高层的解释是对语言的强化，不是弱
化，就像Java是对C的强化，C是对汇编的强化一样。
第四，相比静态类型检查的语言，动态类型检查的语言在表达能力(expressiveness)上
有着巨大的优势，因为没有静态类型检查可确定性(decidability)的羁绊和限制。有很
多语言的特性(feature)，例如多重继承(multiple inheritance), minxins, implicit
parameters, first class function closures, higher order functions, run-time
code generation, class group inheritance等等，在动态类型的语言里被支持的很
好，或者相比之下更容易被实现。而Java迟迟没有这些支持的原因是静态类型检查很困
难(intractable)。
第五，即便抛开node.js带来的event-based programming model, 纯粹的从语言的语义
角度上看，Javascript是我认为的最好的动态类型检查的语言。主要是因为它对高阶函
数的无缝支持和灵活的面相对象的继承。换句话说，它是函数式语言和面向对象语言的
完美结合。相较之下，Scala连门都没入。这极大地丰富的设计模式的可能性，其灵活
性经常远远超出了Java程序员的想象能力。唯一可以在表达性上可以和JS相比的是
Common Lisp。但是函数式语言毕竟是小众，并且Lisp本身的语法也过于奇葩。
Coffeescript就是JS的一个语法糖，根本连一个独立的语言都算不上。它和Javascript
的语义是一模一样的，没有任何简化或强化。事实上，我怀疑有任何人企图用
Coffeescript完全的替代Javascript。大多数人根本不用Coffeescript。有限的人用也
是在一些特定的情况下用。纯的Coffeescript程序员是极少的，如果存在的话。
第六，这么说吧，你做Java轮我是绝对没有问题的。Java是一个好语言，and I love
it (believe me, I do)。但是你不懂的东西甭乱喷。无知不是个性。
【在 z*******3 的大作中提到】
: 你应该意识到，v8!=all javascript engines，甚至连default engine都不是
: 就好比当你说sql的一些问题的时候，有人跳出来说
: oracle db不会有这些问题，oracle db没有某些问题，并不代表其他db不会有这些问题
: 事实上这种差异更增加了问题的严重性，因为当你从一个平台换到另外一个平台上去的
: 时候
: 你有可能会遇到之前没有遇到的问题，那这个所带来的后果，往往是灾难性的
: well，我不否认在某些领域，脚本做的的确不错
: 事实上这些脚本被发明出来，本身就是打算强化或者说简化某一个领域的开发的
: 如果这些都做不好，那完蛋了
: 脚本在特定领域，可以看作是高级语言的简化版
p*2
50 楼
大牛的这段话完全暴露了强大内力。我跪服了。
这极大地丰富的设计模式的可能性，其灵活
性经常远远超出了Java程序员的想象能力。唯一可以在表达性上可以和JS相比的是
Common Lisp。
这极大地丰富的设计模式的可能性，其灵活
性经常远远超出了Java程序员的想象能力。唯一可以在表达性上可以和JS相比的是
Common Lisp。
e*a
51 楼
I really feel that I am lagging too far behind these young gurus
for new software technologies.^o^
for new software technologies.^o^
e*o
52 楼
长见识。谢谢。
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
c*o
53 楼
javascript 难debug， 难测试
用多了网页也很慢
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
用多了网页也很慢
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
w*z
54 楼
举个例子，让俺们用Java 的丰富一下想象力。
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
b*e
55 楼
Function closure。这个在JS里是built-in basic language feature。Java里原先是
encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
长蛋，现在再使劲也就是安个机关屌。
【在 w**z 的大作中提到】
: 举个例子，让俺们用Java 的丰富一下想象力。
:
: browser
encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
长蛋，现在再使劲也就是安个机关屌。
【在 w**z 的大作中提到】
: 举个例子，让俺们用Java 的丰富一下想象力。
:
: browser
g*g
56 楼
Java从来不以feature见长。Closure通常是用anonymous inner class实现的。
但同样是基于JVM的语言，Scala的实现就很干净。你前面提到OO跟FP的完美结合，
Scala跟JS相比，连门都没入，不如举几个JS有，Scala没有的比较有说服力。
跟Java比FP feature没啥意义，Java本意就是纯OO语言。你说的所谓因为静态语言本身
限制而没有的feature，我扫了一眼，貌似绝大部分如果不是全部都在Scala里存在，
而Scala是静态语言，跑在JVM上。所以你说的根本就是狗屁不通。Java是因为为了语言
简单而没有引入这些feature。
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
但同样是基于JVM的语言，Scala的实现就很干净。你前面提到OO跟FP的完美结合，
Scala跟JS相比，连门都没入，不如举几个JS有，Scala没有的比较有说服力。
跟Java比FP feature没啥意义，Java本意就是纯OO语言。你说的所谓因为静态语言本身
限制而没有的feature，我扫了一眼，貌似绝大部分如果不是全部都在Scala里存在，
而Scala是静态语言，跑在JVM上。所以你说的根本就是狗屁不通。Java是因为为了语言
简单而没有引入这些feature。
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
g*g
57 楼
blaze大牛说的东西，看看笑笑也就完了。10年前极力鼓吹Haskell，看不起俺们Java程
序员。一晃10年过去了，感情找到新最爱了。
序员。一晃10年过去了，感情找到新最爱了。
g*g
58 楼
再说说动态语言和静态语言的优势劣势。
我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
不换掉。
我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
不换掉。
s*h
59 楼
好贴
学习了
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
学习了
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
p*2
60 楼
perl,
感觉大牛漏了一个startup。
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
m*n
61 楼
好虫，请问怎么才能私下联系你？你站内邮箱满了。
【在 g*****g 的大作中提到】
: Java从来不以feature见长。Closure通常是用anonymous inner class实现的。
: 但同样是基于JVM的语言，Scala的实现就很干净。你前面提到OO跟FP的完美结合，
: Scala跟JS相比，连门都没入，不如举几个JS有，Scala没有的比较有说服力。
: 跟Java比FP feature没啥意义，Java本意就是纯OO语言。你说的所谓因为静态语言本身
: 限制而没有的feature，我扫了一眼，貌似绝大部分如果不是全部都在Scala里存在，
: 而Scala是静态语言，跑在JVM上。所以你说的根本就是狗屁不通。Java是因为为了语言
: 简单而没有引入这些feature。
【在 g*****g 的大作中提到】
: Java从来不以feature见长。Closure通常是用anonymous inner class实现的。
: 但同样是基于JVM的语言，Scala的实现就很干净。你前面提到OO跟FP的完美结合，
: Scala跟JS相比，连门都没入，不如举几个JS有，Scala没有的比较有说服力。
: 跟Java比FP feature没啥意义，Java本意就是纯OO语言。你说的所谓因为静态语言本身
: 限制而没有的feature，我扫了一眼，貌似绝大部分如果不是全部都在Scala里存在，
: 而Scala是静态语言，跑在JVM上。所以你说的根本就是狗屁不通。Java是因为为了语言
: 简单而没有引入这些feature。
p*n
62 楼
perl,
说得好。做过大系统的都会同意你说的。
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
f*t
63 楼
强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
test，能过就送上production的主。
不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
写得爽就行。
根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
脚本只能用来自动化简单的ops。
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
test，能过就送上production的主。
不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
写得爽就行。
根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
脚本只能用来自动化简单的ops。
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
p*2
64 楼
manual
storm就是clojure写的。
【在 f*******t 的大作中提到】
: 强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
: test，能过就送上production的主。
: 不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
: 写得爽就行。
: 根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
: 脚本只能用来自动化简单的ops。
:
: perl,
p*2
65 楼
manual
storm是clojure写的
openstack是python写的
cloudfoundry是ruby写的
脚本语言开发主要是TDD的模式。看来大牛对脚本语言有偏见呀。
【在 f*******t 的大作中提到】
: 强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
: test，能过就送上production的主。
: 不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
: 写得爽就行。
: 根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
: 脚本只能用来自动化简单的ops。
:
: perl,
z*3
66 楼
服务器端应用vendor lockin是非常大的一个考量
不是所有的服务器端都只是做一个web server那么简单
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
不是所有的服务器端都只是做一个web server那么简单
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
z*3
67 楼
fp有一个最简单的问题
拿你自己说的可维护性来说
你确定别人看得懂你在写什么？
看不懂就不要谈重用了
实际上不要说lambda，就是匿名类
我都主张直接废掉不用，因为影响代码重用
匿名类本身也很难重用
我本科就是学软件工程的
什么重用可维护这些东西听都听烂掉了
我只是说脚本的一些不足，脚本什么就牺牲了一些东西
以达到迅速便捷开发的目的，这就是脚本的本意
实际上脚本也就是做这些，你要真那么想争
来，用脚本写一个游戏就知道了，游戏的实现会让脚本的各种破绽暴露无遗
js用来写游戏不是没有过这么美好的幻想的那么一个年代
没少鼓吹用js来写游戏，只不过结果都很悲剧
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
拿你自己说的可维护性来说
你确定别人看得懂你在写什么？
看不懂就不要谈重用了
实际上不要说lambda，就是匿名类
我都主张直接废掉不用，因为影响代码重用
匿名类本身也很难重用
我本科就是学软件工程的
什么重用可维护这些东西听都听烂掉了
我只是说脚本的一些不足，脚本什么就牺牲了一些东西
以达到迅速便捷开发的目的，这就是脚本的本意
实际上脚本也就是做这些，你要真那么想争
来，用脚本写一个游戏就知道了，游戏的实现会让脚本的各种破绽暴露无遗
js用来写游戏不是没有过这么美好的幻想的那么一个年代
没少鼓吹用js来写游戏，只不过结果都很悲剧
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
z*3
68 楼
可维护，重用
和
灵活
这是一个天平的两端
你只要侧重任何一边，另外一边就会被traded off
写起来爽，看起来就很不爽
反过来
看起来爽，写起来就很不爽
唯一能做的就是在这中间取一个平衡点
而不是片面地侧重任何一边
我发现鼓吹fp的往往喜欢鼓吹脚本
当初用来装的各种灵活性在市场面前摔得粉身碎骨
终于意识到痛了，又开始鼓吹天平的另外一端？
当然想侧重两边也不是不可以
机器性能本身就会被tarded off
动态语言执行效率就是低，优化手段明显受限
fb为了优化php，甚至不惜把php编译成c++代码以达到优化的目的
这个过程中的产品就是hiphop
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
和
灵活
这是一个天平的两端
你只要侧重任何一边，另外一边就会被traded off
写起来爽，看起来就很不爽
反过来
看起来爽，写起来就很不爽
唯一能做的就是在这中间取一个平衡点
而不是片面地侧重任何一边
我发现鼓吹fp的往往喜欢鼓吹脚本
当初用来装的各种灵活性在市场面前摔得粉身碎骨
终于意识到痛了，又开始鼓吹天平的另外一端？
当然想侧重两边也不是不可以
机器性能本身就会被tarded off
动态语言执行效率就是低，优化手段明显受限
fb为了优化php，甚至不惜把php编译成c++代码以达到优化的目的
这个过程中的产品就是hiphop
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
z*3
69 楼
只要模式固定
你自己都可以定义和实现一个脚本语言
也不是很难的事，比实现一个编译器或者jvm之类的平台要简单太多了
何必用别人的？
天天被哪种不是数学也不是英语更不是汉语的语法折磨
动不动还需要深入了解其实现机制
不累么？
而且其实模式固定到一定程度
都不需要脚本，直接上置标语言，xml之类的
可读性直接秒掉所有脚本语言，你敢说不是？
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
你自己都可以定义和实现一个脚本语言
也不是很难的事，比实现一个编译器或者jvm之类的平台要简单太多了
何必用别人的？
天天被哪种不是数学也不是英语更不是汉语的语法折磨
动不动还需要深入了解其实现机制
不累么？
而且其实模式固定到一定程度
都不需要脚本，直接上置标语言，xml之类的
可读性直接秒掉所有脚本语言，你敢说不是？
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
c*d
70 楼
想起最近linked mobile用node.js的事，吹嘘说性能提高了10倍，然后有人指出，10倍
看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。
看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。
z*3
71 楼
脚本适合用来做黏合剂
把各种app给粘起来
各种cloud平台上其实用脚本做黏合剂还是很有市场的
不过这一块本来就是传统脚本的领域
很多时候开发就是用高级语言写核心程序
然后外面包一层脚本，在部署时候跑一下脚本就好了
cloud平台说白了就是一个大的集中的数据中心
所以有各种脚本横行也不奇怪
本来脚本就适合不讲究效率的领域
比如用来部署或者是测试之类的
就像军队里面的传令兵
从某一个程序拿到结果传递给另外一个程序
比如sql就是从一般应用程序里接过命令，交给db，然后返回结果
或者从程序员手里接过命令，传递给执行者
shell就是从用户手里接过命令，交给unix/linux去执行
云平台最大的好处就是，各种产品相对成熟
不需要他们自己去重新造一遍，但是如果要做dynamo db或者cassandra这种东西
显然不适合用脚本来写，大多数成熟的产品都有对应的脚本
比如unix/linux-shell，db-sql，game-lua，browser-javascript，web-php这些
很正常，但是说脚本要直接替换来写真正提供战斗力的产品
那还是不行，人生不应该只满足于写脚本
【在 p*****2 的大作中提到】
:
: manual
: storm是clojure写的
: openstack是python写的
: cloudfoundry是ruby写的
: 脚本语言开发主要是TDD的模式。看来大牛对脚本语言有偏见呀。
把各种app给粘起来
各种cloud平台上其实用脚本做黏合剂还是很有市场的
不过这一块本来就是传统脚本的领域
很多时候开发就是用高级语言写核心程序
然后外面包一层脚本，在部署时候跑一下脚本就好了
cloud平台说白了就是一个大的集中的数据中心
所以有各种脚本横行也不奇怪
本来脚本就适合不讲究效率的领域
比如用来部署或者是测试之类的
就像军队里面的传令兵
从某一个程序拿到结果传递给另外一个程序
比如sql就是从一般应用程序里接过命令，交给db，然后返回结果
或者从程序员手里接过命令，传递给执行者
shell就是从用户手里接过命令，交给unix/linux去执行
云平台最大的好处就是，各种产品相对成熟
不需要他们自己去重新造一遍，但是如果要做dynamo db或者cassandra这种东西
显然不适合用脚本来写，大多数成熟的产品都有对应的脚本
比如unix/linux-shell，db-sql，game-lua，browser-javascript，web-php这些
很正常，但是说脚本要直接替换来写真正提供战斗力的产品
那还是不行，人生不应该只满足于写脚本
【在 p*****2 的大作中提到】
:
: manual
: storm是clojure写的
: openstack是python写的
: cloudfoundry是ruby写的
: 脚本语言开发主要是TDD的模式。看来大牛对脚本语言有偏见呀。
p*2
72 楼
什么算直接提供战斗力？
你们大牛们怎么总是忽略startup呢？
【在 z*******3 的大作中提到】
: 脚本适合用来做黏合剂
: 把各种app给粘起来
: 各种cloud平台上其实用脚本做黏合剂还是很有市场的
: 不过这一块本来就是传统脚本的领域
: 很多时候开发就是用高级语言写核心程序
: 然后外面包一层脚本，在部署时候跑一下脚本就好了
: cloud平台说白了就是一个大的集中的数据中心
: 所以有各种脚本横行也不奇怪
: 本来脚本就适合不讲究效率的领域
: 比如用来部署或者是测试之类的
e*a
73 楼
why is RoR bad?
RoR developers earn bigger than Java developers.
【在 c**d 的大作中提到】
: 想起最近linked mobile用node.js的事，吹嘘说性能提高了10倍，然后有人指出，10倍
: 看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。
RoR developers earn bigger than Java developers.
【在 c**d 的大作中提到】
: 想起最近linked mobile用node.js的事，吹嘘说性能提高了10倍，然后有人指出，10倍
: 看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。
g*g
74 楼
Probably comparable with many less positions.
http://www.indeed.com/salary?q1=ruby&l1=&q2=java&l2=&tm=1
【在 e***a 的大作中提到】
: why is RoR bad?
: RoR developers earn bigger than Java developers.
http://www.indeed.com/salary?q1=ruby&l1=&q2=java&l2=&tm=1
【在 e***a 的大作中提到】
: why is RoR bad?
: RoR developers earn bigger than Java developers.
p*2
75 楼
RoR过时了。
【在 e***a 的大作中提到】
: why is RoR bad?
: RoR developers earn bigger than Java developers.
c*o
76 楼
你们都忽视了weak/string type?
http://architects.dzone.com/articles/should-your-static-go-stat
http://architects.dzone.com/articles/should-your-static-go-stat
m*k
77 楼
>>就像Java在实践中没有跨平台的问题 一样。
这个......
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
这个......
browser
【在 b***e 的大作中提到】
: 第一，你应该意识到，node.js是唯一值得在GC效率上值得考虑的，因为其后端服务器
: 上的应用。Browser side JS的Garbage collection效率本来也没什么关系。其道理就
: 跟PHP一样，每个page都是short life cycle process/thread(depending on browser
: implementation). 即使是single page architecture, 一般一个page也不会运行很长
: 时间。而且browser一般都是单机执行在个人的终端上，有独享的CPU和内存支持。以现
: 今个人计算机终端的硬件支持和运算能力，前台的JS所要考虑的根本就不在执行效率上
: ，而是主要在软件工程上，即生产效率，可维护性，可扩展性和可重用性。在实践的意
: 义上讲，v8 === JS engine。
: 第二，跨平台的问题总是有的。微软在这个问题上一向是做负贡献的。即使是Java也曾
: 经有过一个J++。对于Javascript，也曾有过一个JScript。不过这些在历史的洪流中已
相关阅读
问个问题 数学小姨子送了一只兔子上门后……这是我见过最深的套路，难道是因为我的英文不好吗？liberal川普跟美犹打成一片，跟右派安裤头和bannon势不两立 (转载)民主的代价：法国议会决定把“父亲”“母亲”从教育系统中删掉 (转载)图摘0216给大家谈个俗的，幸福是啥？希望和绝望。真是神一样的对话。这样的对手哪里找？Re: 中国战狼，地球战狼，太空战狼，下部是什么战狼？ (转载)写给军版同胞的心里话 (转载)图片0215不能不说洋鬼子太会玩了确认过眼神，我见过最壮的人男子喝醉酒后丢钱，怕被老婆骂说遭抢劫然后被拘留6天强奸犯，在监狱中过什么样的生活，你知道吗？邻居家的乌龟壳越长越小，从“豪宅”变成“开间”（多图）我发现了一个问题章鱼和海豹格斗，谁赢还不知道呢（多图）我们常温为什么离绝对温度这么近？ (转载)关于USANews版版主任免事件的说明