z****e
发帖数: 54598 | 1 连个括号的错误都判断不出来
脚本这种问题应该挺多
不用IDE的话，比较苦逼 |
N********n
发帖数: 8363 | 2
脚本一旦动态起来连IDE都搞不清楚程序里面到底定义啥了。一个语言设计
到把IDE搞晕就在工程上很失败了。
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
n*****t
发帖数: 22014 | 3 printf 是我用得最频繁的函数，没有之一 。。。
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
b******0
发帖数: 101 | 4 赞一个。这一点确实让人觉得脚本用起来实在很苦逼。 |
t****a
发帖数: 1212 | 5 脚本编程没有比较大的问题，赵策兄你有比较大的问题，需要好好学习脚本编程
个人觉得，靠DEBUG来找错本身就是很低效率的行为
有本书叫做interactive programming，好好看看吧。interactive programming是人月
神话中宣称的70年代编程领域效率提高的两种主要方法之一
我写脚本的时候，写一行测一行写一个函数测一个函数，所以一路写下来，程序都是对
的。怎么测？用REPL。如果有emacs，C-c C-c就测试了。测完了像整个unit test就整
，不想就扔了算了
写程序的时候就保持一个使得程序容易测试的念头：比如，在逻辑上分块，写容易测试
修改的小函数，使用函数式风格，都是办法
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
p*****2
发帖数: 21240 | 6 说实话，脚本对程序员的要求更高了一截。一般的程序员是搞不定的。 |
z****e
发帖数: 54598 | 7 我用vi搞JAVA没有什么问题
基本上可以无bug
但是你要说让我去看别人写的代码
要很快debug出来，这个我自信水平达不到
我也不相信这里有谁能做到
毕竟人不是机器
我对错误的容忍度比较高，很少装，该用啥就用啥
不过分依赖人本身，因为人总归是人，犯错是常事
我大学老师，上黑板做四则运算都能算错
更何况是写点代码了
【在 t****a 的大作中提到】
: 脚本编程没有比较大的问题，赵策兄你有比较大的问题，需要好好学习脚本编程
: 个人觉得，靠DEBUG来找错本身就是很低效率的行为
: 有本书叫做interactive programming，好好看看吧。interactive programming是人月
: 神话中宣称的70年代编程领域效率提高的两种主要方法之一
: 我写脚本的时候，写一行测一行写一个函数测一个函数，所以一路写下来，程序都是对
: 的。怎么测？用REPL。如果有emacs，C-c C-c就测试了。测完了像整个unit test就整
: ，不想就扔了算了
: 写程序的时候就保持一个使得程序容易测试的念头：比如，在逻辑上分块，写容易测试
: 修改的小函数，使用函数式风格，都是办法
|
z****e
发帖数: 54598 | 8 所以这个是对的
发信人: NeverLearn (24K golden bear), 信区: Programming
标 题: Re: 脚本比较大的问题就是DEBUG
发信站: BBS 未名空间站 (Thu Jan 30 17:44:29 2014, 美东)
脚本一旦动态起来连IDE都搞不清楚程序里面到底定义啥了。一个语言设计
到把IDE搞晕就在工程上很失败了。
【在 p*****2 的大作中提到】
: 说实话，脚本对程序员的要求更高了一截。一般的程序员是搞不定的。
|
t****a
发帖数: 1212 | 9 这话没错，用别人的code如果不太清楚他的思路就不太容易弄。如果接手的code写得很
烂，我总有想推了重写的冲动。
话说回来，让烂程序员写，什么语言到他手里都是烂程序。
【在 z****e 的大作中提到】
: 我用vi搞JAVA没有什么问题
: 基本上可以无bug
: 但是你要说让我去看别人写的代码
: 要很快debug出来，这个我自信水平达不到
: 我也不相信这里有谁能做到
: 毕竟人不是机器
: 我对错误的容忍度比较高，很少装，该用啥就用啥
: 不过分依赖人本身，因为人总归是人，犯错是常事
: 我大学老师，上黑板做四则运算都能算错
: 更何况是写点代码了
|
z****e
发帖数: 54598 | 10 所以总结下来
你的说法就是脚本不适合大项目，那这个不行啊
哥喜欢大气点的东西
玩游戏都喜欢搞大决战
这点小打小闹没啥意思
【在 t****a 的大作中提到】
: 脚本编程没有比较大的问题，赵策兄你有比较大的问题，需要好好学习脚本编程
: 个人觉得，靠DEBUG来找错本身就是很低效率的行为
: 有本书叫做interactive programming，好好看看吧。interactive programming是人月
: 神话中宣称的70年代编程领域效率提高的两种主要方法之一
: 我写脚本的时候，写一行测一行写一个函数测一个函数，所以一路写下来，程序都是对
: 的。怎么测？用REPL。如果有emacs，C-c C-c就测试了。测完了像整个unit test就整
: ，不想就扔了算了
: 写程序的时候就保持一个使得程序容易测试的念头：比如，在逻辑上分块，写容易测试
: 修改的小函数，使用函数式风格，都是办法
|
|
|
z****e
发帖数: 54598 | 11 年轻人，这种冲动谁都有
但是现实一般是：老大不允许你这么干
作为资本家，谁也不想让自己之前的投资打水漂不是？
越大规模公司越是如此，小公司无所谓了
【在 t****a 的大作中提到】
: 这话没错，用别人的code如果不太清楚他的思路就不太容易弄。如果接手的code写得很
: 烂，我总有想推了重写的冲动。
: 话说回来，让烂程序员写，什么语言到他手里都是烂程序。
|
p*****2
发帖数: 21240 | 12
顶大牛。
【在 t****a 的大作中提到】
: 脚本编程没有比较大的问题，赵策兄你有比较大的问题，需要好好学习脚本编程
: 个人觉得，靠DEBUG来找错本身就是很低效率的行为
: 有本书叫做interactive programming，好好看看吧。interactive programming是人月
: 神话中宣称的70年代编程领域效率提高的两种主要方法之一
: 我写脚本的时候，写一行测一行写一个函数测一个函数，所以一路写下来，程序都是对
: 的。怎么测？用REPL。如果有emacs，C-c C-c就测试了。测完了像整个unit test就整
: ，不想就扔了算了
: 写程序的时候就保持一个使得程序容易测试的念头：比如，在逻辑上分块，写容易测试
: 修改的小函数，使用函数式风格，都是办法
|
t****a
发帖数: 1212 | 13 大家都说脚本不适合大项目，我在琢磨是不是大家都是听别人说的。
我相当的怀疑这话的可信度啊。
大概脚本是不太适合良莠不齐的一大票程序员吧。如果能有一个很精干的小分队，也许
脚本就是很牛B的东西了。需要高效率的部分用C/java，其他统统脚本。
【在 z****e 的大作中提到】
: 所以总结下来
: 你的说法就是脚本不适合大项目，那这个不行啊
: 哥喜欢大气点的东西
: 玩游戏都喜欢搞大决战
: 这点小打小闹没啥意思
|
z****e
发帖数: 54598 | 14 我现在想的是，通过某一种架构
把脚本的使用，限制在一个小范围之内
比如MODULE酱紫，这样就可以适当地在项目中使用脚本了
这点vert.x走在我的前面
【在 t****a 的大作中提到】
: 大家都说脚本不适合大项目，我在琢磨是不是大家都是听别人说的。
: 我相当的怀疑这话的可信度啊。
: 大概脚本是不太适合良莠不齐的一大票程序员吧。如果能有一个很精干的小分队，也许
: 脚本就是很牛B的东西了。需要高效率的部分用C/java，其他统统脚本。
|
p*****2
发帖数: 21240 | 15
写大项目应该是不如static language。但是现在SOA使得script做大项目也成为了可能
。
【在 z****e 的大作中提到】
: 所以总结下来
: 你的说法就是脚本不适合大项目，那这个不行啊
: 哥喜欢大气点的东西
: 玩游戏都喜欢搞大决战
: 这点小打小闹没啥意思
|
z****e
发帖数: 54598 | 16 所以最后是架构的问题，不是语言本身的问题
要规划好架构来适应这些脚本，这就对架构提出了更高的要求
单纯的SOA恐怕是不够，要细分下去的SOA
SOA分为广义和狭义两种，一般都指的是狭义
但是狭义的SOA在这里都显得太重，需要再NARROW一点
【在 p*****2 的大作中提到】
:
: 写大项目应该是不如static language。但是现在SOA使得script做大项目也成为了可能
: 。
|
z****e
发帖数: 54598 | 17 脚本你这样定位就是牛人用来简化操作用的
但是大多数时候，人们定位脚本是初学者不需要太多投入就能上手干活的工具
那这两个目标是多少冲突的
【在 t****a 的大作中提到】
: 大家都说脚本不适合大项目，我在琢磨是不是大家都是听别人说的。
: 我相当的怀疑这话的可信度啊。
: 大概脚本是不太适合良莠不齐的一大票程序员吧。如果能有一个很精干的小分队，也许
: 脚本就是很牛B的东西了。需要高效率的部分用C/java，其他统统脚本。
|
q*c
发帖数: 9453 | 18 当年共产主义也是这样设想的。
如果人人都 XXX....结果大家都知道吧。
【在 t****a 的大作中提到】
: 大家都说脚本不适合大项目，我在琢磨是不是大家都是听别人说的。
: 我相当的怀疑这话的可信度啊。
: 大概脚本是不太适合良莠不齐的一大票程序员吧。如果能有一个很精干的小分队，也许
: 脚本就是很牛B的东西了。需要高效率的部分用C/java，其他统统脚本。
|
b*******s
发帖数: 5216 | 19 脚本写得好的基本都是强人
【在 z****e 的大作中提到】
: 脚本你这样定位就是牛人用来简化操作用的
: 但是大多数时候，人们定位脚本是初学者不需要太多投入就能上手干活的工具
: 那这两个目标是多少冲突的
|
g*****g
发帖数: 34805 | 20 亿万 php 程序员笑而不语。
【在 p*****2 的大作中提到】
: 说实话，脚本对程序员的要求更高了一截。一般的程序员是搞不定的。
|
|
|
m******t
发帖数: 635 | 21 用ruby的话，上ruby-debug或者pry，设置断点，步进，当场修改变量值都可以
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
s***o
发帖数: 2191 | 22 哈，亿万夸张了点。不过就接私活来说，PHP是王中王没什么问题吧。不知道以后风头
会不会被JavaScript盖过。
【在 g*****g 的大作中提到】
: 亿万 php 程序员笑而不语。
|
z****e
发帖数: 54598 | 23 下一个不用ruby了
我之前用的是aptana studio 3
各种高亮感觉还不错，这个还兼容python
但是之前测试也不是在本机上，所以折腾了一下
ruby的hash感觉不太方便用
没有java的简单
【在 m******t 的大作中提到】
: 用ruby的话，上ruby-debug或者pry，设置断点，步进，当场修改变量值都可以
|
z****e
发帖数: 54598 | 24 之前做RUBY的那个的确不错
【在 b*******s 的大作中提到】
: 脚本写得好的基本都是强人
|
t****a
发帖数: 1212 | 25 话说回来，括号的配对问题是编辑器的责任
换一个好点的编辑器吧
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
w**z
发帖数: 8232 | 26 我们php一deploy，就得盯着log看，不知哪里就起火了。
【在 t****a 的大作中提到】
: 大家都说脚本不适合大项目，我在琢磨是不是大家都是听别人说的。
: 我相当的怀疑这话的可信度啊。
: 大概脚本是不太适合良莠不齐的一大票程序员吧。如果能有一个很精干的小分队，也许
: 脚本就是很牛B的东西了。需要高效率的部分用C/java，其他统统脚本。
|
c******o
发帖数: 1277 | 27 这个说实话，没啥特别争论的，脚本语言写了超过两年，代码增加超过一倍，参与人数
超过3个的。
肯定有过悲惨的回忆。
我对php/python都有这样的回忆，php是payment, python是stack集成。
唯一一个比较好的是ruby ror 网站，完全是因为严格的TDD,任何时候都严格的先写测
试，然后写代码往上套。即使这样，也还是会出问题，只敢做
website,不敢做后端。 |
p*****2
发帖数: 21240 | 28
可惜大牛没试过Node。
【在 c******o 的大作中提到】
: 这个说实话，没啥特别争论的，脚本语言写了超过两年，代码增加超过一倍，参与人数
: 超过3个的。
: 肯定有过悲惨的回忆。
: 我对php/python都有这样的回忆，php是payment, python是stack集成。
: 唯一一个比较好的是ruby ror 网站，完全是因为严格的TDD,任何时候都严格的先写测
: 试，然后写代码往上套。即使这样，也还是会出问题，只敢做
: website,不敢做后端。
|
z****e
发帖数: 54598 | 29 做游戏的，如果有些丢包server不相应什么的
会投诉的，他们估计都没有用异步这个机制
持续连接并且block是比较常用的模式，对于他们来说
【在 p*****2 的大作中提到】
:
: 可惜大牛没试过Node。
|
p*****2
发帖数: 21240 | 30
socket.io呀。
【在 z****e 的大作中提到】
: 做游戏的，如果有些丢包server不相应什么的
: 会投诉的，他们估计都没有用异步这个机制
: 持续连接并且block是比较常用的模式，对于他们来说
|
|
|
d********g
发帖数: 10550 | 31 SOA不是什么神奇的玩意儿，Python也有重的架构不过用的人不多：
https://zato.io
做Python的一般还是倾向于不是太重的架构。不是喜欢重新发明轮子或者直接买车，而
是喜欢买个普通轮子锦上添花
【在 z****e 的大作中提到】
: 所以最后是架构的问题，不是语言本身的问题
: 要规划好架构来适应这些脚本，这就对架构提出了更高的要求
: 单纯的SOA恐怕是不够，要细分下去的SOA
: SOA分为广义和狭义两种，一般都指的是狭义
: 但是狭义的SOA在这里都显得太重，需要再NARROW一点
|
a***n
发帖数: 538 | 32 写script比较好的地方是没有封装，底层库不爽的地方可以随便改。写java不知道要写
多少code绕过去了。 |
t****a
发帖数: 1212 | 33 我今天才知道另一个100人左右的startup也全用python。
越来越相信所谓静态检查的作用被夸大了——三人成虎啊。
【在 c******o 的大作中提到】
: 这个说实话，没啥特别争论的，脚本语言写了超过两年，代码增加超过一倍，参与人数
: 超过3个的。
: 肯定有过悲惨的回忆。
: 我对php/python都有这样的回忆，php是payment, python是stack集成。
: 唯一一个比较好的是ruby ror 网站，完全是因为严格的TDD,任何时候都严格的先写测
: 试，然后写代码往上套。即使这样，也还是会出问题，只敢做
: website,不敢做后端。
|
p*****2
发帖数: 21240 | 34
P?
【在 t****a 的大作中提到】
: 我今天才知道另一个100人左右的startup也全用python。
: 越来越相信所谓静态检查的作用被夸大了——三人成虎啊。
|
q*c
发帖数: 9453 | 35 提高对程序员的要求 等于 只能做更简单的事情。
因为项目的最终最大复杂度是有限的，，受制于当前的人脑智能。语言本身的要求高，
那么最终的产出就低。
【在 p*****2 的大作中提到】
: 说实话，脚本对程序员的要求更高了一截。一般的程序员是搞不定的。
|
q*c
发帖数: 9453 | 36 如果那个 startup 的商业模式和运行比较好，他们用汇编或者 fortran 也能成功，你
信不？
是语言的作用在商业成功里面因素基本是零，区别不过是里面程序员的苦逼程度不同罢
了。
startup 用啥全是随机，根本和语言质量一分钱关系没有，就开头那几个人啥熟练用啥
。后面的人不用也得用。除非后来很大了，发现实在不行，有实力就推倒重来。
【在 t****a 的大作中提到】
: 我今天才知道另一个100人左右的startup也全用python。
: 越来越相信所谓静态检查的作用被夸大了——三人成虎啊。
|
i**i
发帖数: 1500 | 37 修一个bug的话，动态语言还要快一点．
问题是，动态语言没有什么约束． 太容易写成一锅糨子了, IDE帮不上忙．
【在 z****e 的大作中提到】
: 连个括号的错误都判断不出来
: 脚本这种问题应该挺多
: 不用IDE的话，比较苦逼
|
t****a
发帖数: 1212 | 38 你说的商业模式是很重要，没错。不过除非是做硬件高度相关的，我不信他们用汇编也
能成功。fortran我不知道。
【在 q*c 的大作中提到】
: 如果那个 startup 的商业模式和运行比较好，他们用汇编或者 fortran 也能成功，你
: 信不？
: 是语言的作用在商业成功里面因素基本是零，区别不过是里面程序员的苦逼程度不同罢
: 了。
: startup 用啥全是随机，根本和语言质量一分钱关系没有，就开头那几个人啥熟练用啥
: 。后面的人不用也得用。除非后来很大了，发现实在不行，有实力就推倒重来。
|
t****a
发帖数: 1212 | 39 另外一家，已经被收购了
【在 p*****2 的大作中提到】
:
: P?
|
q*c
发帖数: 9453 | 40
汇编是个夸张的说法， 不过有些软件关键部位为了提高效率就是用汇编写。
我的 point 就是你说因为有 start up 用 动态语言， 所以说明这个静态类型不重要
， 是完全没有逻辑关系的推论。 过去还基本全部是奴隶制呢？ 难道人类大部分人喜
欢当奴隶？ 根本原因是生产力决定生产关系， 和人类的喜好无关。
你这个也是一个道理。start up 用啥完全是随机问题。
【在 t****a 的大作中提到】
: 你说的商业模式是很重要，没错。不过除非是做硬件高度相关的，我不信他们用汇编也
: 能成功。fortran我不知道。
|
|
|
t****a
发帖数: 1212 | 41 前辈，也许我没有把我的逻辑完整说清楚，那是有上下文的。所提供的100人用python
的startup的信息，目的是反驳coltzhao同学的说法.
"这个说实话，没啥特别争论的，脚本语言写了超过两年，代码增加超过一倍，参与人
数超过3个的。肯定有过悲惨的回忆。"
其实，我个人目前欠缺和很多人一起开发动态语言的切身经验，不能很有信心的为动态
语言正名；我仅仅从这些很红火的具有一定规模的ruby python startup来怀疑所谓静
态检查极度重要的说法：如果真的极度重要，这些百人以上的企业怎么活下来的？这就
是反证法而已。
你说startup用啥完全是随机问题，我不同意，因为我看到的不是这么回事；当然你也
可以说我的视角不客观，我也无法保证我的视角就100%客观。
【在 q*c 的大作中提到】
:
: 汇编是个夸张的说法， 不过有些软件关键部位为了提高效率就是用汇编写。
: 我的 point 就是你说因为有 start up 用 动态语言， 所以说明这个静态类型不重要
: ， 是完全没有逻辑关系的推论。 过去还基本全部是奴隶制呢？ 难道人类大部分人喜
: 欢当奴隶？ 根本原因是生产力决定生产关系， 和人类的喜好无关。
: 你这个也是一个道理。start up 用啥完全是随机问题。
|
g*****g
发帖数: 34805 | 42 startup用啥纯粹取决于创始人熟悉啥。facebook(php), linkedin(java), twitter(
ruby)都是社交网站，很多功能相近，用的语言完全不同最后都上市了。
公司越大越倾向于用静态的语言作后端。一方面是bug的成本随着用户数目增多加大了
，另一方面静态语言层次比较清楚，容易堆人去修改维护。 |
p*****2
发帖数: 21240 | 43
公司越大越倾向于用静态的语言作后端。
SOA的话也不一定吧？
【在 g*****g 的大作中提到】
: startup用啥纯粹取决于创始人熟悉啥。facebook(php), linkedin(java), twitter(
: ruby)都是社交网站，很多功能相近，用的语言完全不同最后都上市了。
: 公司越大越倾向于用静态的语言作后端。一方面是bug的成本随着用户数目增多加大了
: ，另一方面静态语言层次比较清楚，容易堆人去修改维护。
|
g*****g
发帖数: 34805 | 44 那你说twitter从ruby转scala/java为了啥？
【在 p*****2 的大作中提到】
:
: 公司越大越倾向于用静态的语言作后端。
: SOA的话也不一定吧？
|
z****e
发帖数: 54598 | 45 soa的控制相对high level
静态的控制则相对low level
所以还是静态用得多
【在 p*****2 的大作中提到】
:
: 公司越大越倾向于用静态的语言作后端。
: SOA的话也不一定吧？
|
