e***a
发帖数: 1661 | 1 Ruby能做的，Java都能做。
与 Java 相比，Ruby 有啥优势？ |
p*****2
发帖数: 21240 | 2 rails
functional
dynamic
rapid development
more fun
but will lose to node.js. |
b***e
发帖数: 1419 | 3 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.
|
e***a
发帖数: 1661 | 4 how about sencha/html5?
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
|
c*****a
发帖数: 808 | 5 java code又长又臭.....最近用过java, node js写service，区别太大了 |
z*******3
发帖数: 13709 | 6 任何脚本语言跟高级语言相比
开发效率永远都是优势
无论这个脚本是python还是ruby还是php还是sql还是javascript还是shell script
也无论后面的高级语言是java还是c++
当你还在为java里面各种类型是不是对象而烦恼的时候
人家hello world已经出来了，但是作为trade off
脚本语言需要一个相对成熟的平台
比如os，比如db，比如browser，比如web server
所以比较局限在某一个领域里面 |
p*****2
发帖数: 21240 | 7
大牛我现在再搞clojure.
【在 b***e 的大作中提到】
: Man, you have a true enthusiasm in node, even crazier than me.
|
w**z
发帖数: 8232 | 8 does node.js perform well under high load ?
【在 p*****2 的大作中提到】
: rails
: functional
: dynamic
: rapid development
: more fun
: but will lose to node.js.
|
z*******3
发帖数: 13709 | 9 开发人员还是不能仅局限在脚本语言里面
脚本语言就是司机
但是现实中需要开发人员做适当的创造
而不是只会用就好了
实际上各个脚本的trade off很明显
有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
还有就是各个脚本类型往往很自由
写js经常被jquery里面的${}到底指代的是哪个而烦恼
但是这些东西在小规模时候，都不是问题，但是一旦做大了
那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
想不了那么远，东西赶快做出来融资要紧，做大了再改
以前java程序猿经常用的是其它三种脚本和两个置标
三个脚本是sql, shell和javascript，两个置标是html和xml
加上java本身，这就六种语言了，要说难嘛
也不难，这些学过cs基础课，基本上都会
转行的往往短板在这几个地方 |
z*******3
发帖数: 13709 | 10 你们打算换nodejs写web？
【在 w**z 的大作中提到】
: does node.js perform well under high load ?
|
|
|
c*****a
发帖数: 808 | |
p*****2
发帖数: 21240 | 12
纯异步应该不差吧？
【在 w**z 的大作中提到】
: does node.js perform well under high load ?
|
l*n
发帖数: 529 | 13 反驳下gc的问题：不是个问题。
http://stackoverflow.com/questions/7347203/circular-references-
js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
|
z*******3
发帖数: 13709 | 14 当你把希望寄托在文档和注释的完整上的时候
你就已经失败了
就像你反驳的那个引用里面的“Most” garbage collectors don't do
这种most，也许，或者等各种不严谨可以让项目在做大之后华丽滴垮掉
千里之提
吗？
【在 l*n 的大作中提到】
: 反驳下gc的问题：不是个问题。
: http://stackoverflow.com/questions/7347203/circular-references-
: js里面搞不明白${}是什么，不知道你指的是什么。是跟this的动态绑定有关的问题吗？
: software engeering在函数之外的确主要是解决复杂度问题。但是你说的小规模变大时
: 需要改写甚至换系统是不是也跟当初的毛糙有关？比如文档、注释等不系统。
|
b***e
发帖数: 1419 | 15 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公司来说
|
z*******3
发帖数: 13709 | 16 你应该意识到，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.
|
w**z
发帖数: 8232 | 17 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？
|
p***n
发帖数: 83 | 18
这个说得中恳贴切。
【在 z*******3 的大作中提到】
: 任何脚本语言跟高级语言相比
: 开发效率永远都是优势
: 无论这个脚本是python还是ruby还是php还是sql还是javascript还是shell script
: 也无论后面的高级语言是java还是c++
: 当你还在为java里面各种类型是不是对象而烦恼的时候
: 人家hello world已经出来了，但是作为trade off
: 脚本语言需要一个相对成熟的平台
: 比如os，比如db，比如browser，比如web server
: 所以比较局限在某一个领域里面
|
p***n
发帖数: 83 | 19
FB 想改都改不了啦。
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
|
a****g
发帖数: 3027 | 20 这个（bash）shell语言用的是不是要吐血？
【在 z*******3 的大作中提到】
: 开发人员还是不能仅局限在脚本语言里面
: 脚本语言就是司机
: 但是现实中需要开发人员做适当的创造
: 而不是只会用就好了
: 实际上各个脚本的trade off很明显
: 有些有很可怕的设计缺陷，比如js的交叉引用无法被gc
: 还有就是各个脚本类型往往很自由
: 写js经常被jquery里面的${}到底指代的是哪个而烦恼
: 但是这些东西在小规模时候，都不是问题，但是一旦做大了
: 那就麻烦了，但是任何东西都有其适应范围，作为小规模的web或者startup公司来说
|
|
|
b***e
发帖数: 1419 | 21 第一，你应该意识到，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，我不否认在某些领域，脚本做的的确不错
: 事实上这些脚本被发明出来，本身就是打算强化或者说简化某一个领域的开发的
: 如果这些都做不好，那完蛋了
: 脚本在特定领域，可以看作是高级语言的简化版
|
p*****2
发帖数: 21240 | 22 大牛的这段话完全暴露了强大内力。我跪服了。
这极大地丰富的设计模式的可能性，其灵活
性经常远远超出了Java程序员的想象能力。唯一可以在表达性上可以和JS相比的是
Common Lisp。 |
e***a
发帖数: 1661 | 23 I really feel that I am lagging too far behind these young gurus
for new software technologies.^o^ |
e*******o
发帖数: 4654 | 24 长见识。谢谢。
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
发帖数: 534 | 25 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。不过这些在历史的洪流中已
|
w**z
发帖数: 8232 | 26 举个例子，让俺们用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。不过这些在历史的洪流中已
|
b***e
发帖数: 1419 | 27 Function closure。这个在JS里是built-in basic language feature。Java里原先是
encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
长蛋，现在再使劲也就是安个机关屌。
【在 w**z 的大作中提到】
: 举个例子，让俺们用Java 的丰富一下想象力。
:
: browser
|
g*****g
发帖数: 34805 | 28 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设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
|
g*****g
发帖数: 34805 | 29 blaze大牛说的东西，看看笑笑也就完了。10年前极力鼓吹Haskell，看不起俺们Java程
序员。一晃10年过去了，感情找到新最爱了。 |
g*****g
发帖数: 34805 | 30 再说说动态语言和静态语言的优势劣势。
我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
不换掉。 |
|
|
s*****h
发帖数: 155 | 31 好贴
学习了
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
|
p*****2
发帖数: 21240 | 32
perl,
感觉大牛漏了一个startup。
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
|
m******n
发帖数: 187 | 33 好虫，请问怎么才能私下联系你？你站内邮箱满了。
【在 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
发帖数: 83 | 34
perl,
说得好。做过大系统的都会同意你说的。
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
|
f*******t
发帖数: 7549 | 35 强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
test，能过就送上production的主。
不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
写得爽就行。
根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
脚本只能用来自动化简单的ops。
perl,
【在 g*****g 的大作中提到】
: 再说说动态语言和静态语言的优势劣势。
: 我一直认为，动态语言在前端有优势，在后端劣势。代表性的动态语言，如php, perl,
: python, ruby都最多见于web前端，所谓web scripting的领域，同样也可以用于取代
: shell scripting。好处主要有俩，简洁，不用重启VM就可以重新调试。
: 但在后端，天然的劣势就突出来了。测试总是不充分的，编译能找出的问题改正是成本
: 最低的，反之如果在产品里发现，成本轻松高100倍。编译不能找出所有的问题，能找
: 到一些总是好的。另外一个，则是分层的问题。动态语言往往为了简洁，分层不清，
: RoR是个典型例子，小的时候很方便很快速，大了就很难维护。就像twitter一样，不得
: 不换掉。
|
p*****2
发帖数: 21240 | 36
manual
storm就是clojure写的。
【在 f*******t 的大作中提到】
: 强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
: test，能过就送上production的主。
: 不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
: 写得爽就行。
: 根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
: 脚本只能用来自动化简单的ops。
:
: perl,
|
p*****2
发帖数: 21240 | 37
manual
storm是clojure写的
openstack是python写的
cloudfoundry是ruby写的
脚本语言开发主要是TDD的模式。看来大牛对脚本语言有偏见呀。
【在 f*******t 的大作中提到】
: 强烈同意。说脚本语言好的，看上去都是写完跑个positive test，说不定还是manual
: test，能过就送上production的主。
: 不知道这些大牛都是啥公司啥职位，貌似从来不用愁维护之类的脏活累活，只要开发时
: 写得爽就行。
: 根据我极其有限的业界经验，正经写大工程，还是静态语言C++、Java之类的最靠谱。
: 脚本只能用来自动化简单的ops。
:
: perl,
|
z*******3
发帖数: 13709 | 38 服务器端应用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。不过这些在历史的洪流中已
|
z*******3
发帖数: 13709 | 39 fp有一个最简单的问题
拿你自己说的可维护性来说
你确定别人看得懂你在写什么？
看不懂就不要谈重用了
实际上不要说lambda，就是匿名类
我都主张直接废掉不用，因为影响代码重用
匿名类本身也很难重用
我本科就是学软件工程的
什么重用可维护这些东西听都听烂掉了
我只是说脚本的一些不足，脚本什么就牺牲了一些东西
以达到迅速便捷开发的目的，这就是脚本的本意
实际上脚本也就是做这些，你要真那么想争
来，用脚本写一个游戏就知道了，游戏的实现会让脚本的各种破绽暴露无遗
js用来写游戏不是没有过这么美好的幻想的那么一个年代
没少鼓吹用js来写游戏，只不过结果都很悲剧
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
|
z*******3
发帖数: 13709 | 40 可维护，重用
和
灵活
这是一个天平的两端
你只要侧重任何一边，另外一边就会被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
发帖数: 13709 | 41 只要模式固定
你自己都可以定义和实现一个脚本语言
也不是很难的事，比实现一个编译器或者jvm之类的平台要简单太多了
何必用别人的？
天天被哪种不是数学也不是英语更不是汉语的语法折磨
动不动还需要深入了解其实现机制
不累么？
而且其实模式固定到一定程度
都不需要脚本，直接上置标语言，xml之类的
可读性直接秒掉所有脚本语言，你敢说不是？
【在 b***e 的大作中提到】
: Function closure。这个在JS里是built-in basic language feature。Java里原先是
: encode，再后来就是使劲加lamba。但是搞来搞去还是个阉割版的。JVM设计的时候就没
: 长蛋，现在再使劲也就是安个机关屌。
|
c**d
发帖数: 579 | 42 想起最近linked mobile用node.js的事，吹嘘说性能提高了10倍，然后有人指出，10倍
看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。 |
z*******3
发帖数: 13709 | 43 脚本适合用来做黏合剂
把各种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
发帖数: 21240 | 44
什么算直接提供战斗力？
你们大牛们怎么总是忽略startup呢？
【在 z*******3 的大作中提到】
: 脚本适合用来做黏合剂
: 把各种app给粘起来
: 各种cloud平台上其实用脚本做黏合剂还是很有市场的
: 不过这一块本来就是传统脚本的领域
: 很多时候开发就是用高级语言写核心程序
: 然后外面包一层脚本，在部署时候跑一下脚本就好了
: cloud平台说白了就是一个大的集中的数据中心
: 所以有各种脚本横行也不奇怪
: 本来脚本就适合不讲究效率的领域
: 比如用来部署或者是测试之类的
|
e***a
发帖数: 1661 | 45 why is RoR bad?
RoR developers earn bigger than Java developers.
【在 c**d 的大作中提到】
: 想起最近linked mobile用node.js的事，吹嘘说性能提高了10倍，然后有人指出，10倍
: 看你跟谁比，跟你原来系统比，只能说明原来系统太烂，他们原来用的RoR。。。
|
g*****g
发帖数: 34805 | 46 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.
|
p*****2
发帖数: 21240 | 47
RoR过时了。
【在 e***a 的大作中提到】
: why is RoR bad?
: RoR developers earn bigger than Java developers.
|
c******o
发帖数: 1277 | |
m*****k
发帖数: 731 | 49 >>就像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。不过这些在历史的洪流中已
|
