{转载}《梦段代码》读后感(I, II, III) by 邹欣
pongba
推荐邹欣老师的博客：http://yishan.cc/blogs/xin/default.aspx
梦断代码 读后感 (I) 驱动和责任
几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》 的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一 到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了 中文版，也有一些感想如下。
1）驱动
到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？
有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源，社区，共享的模式会更好（集市/Bazaar模式）也许更好。正如在第26页所说的 [所有页码都是指英文版]
... it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26]
这理论听起来很好，但是我想起了两个故事：
1) 美国的一个肥皂剧Seinfield里有一集，讲了一个混混Kramer
热心地加入了一家公司，义务打工，起初他的口头幽默和热情感动了团队，领导委以重任，不料Kramer
根本没法儿把事情做好。最后领导只好找他谈话，Kramer 承认自己不行，他说- 但是俺是义务给你们打工的！
领导说，对，这就是让我们为难的地方。。。
项目中来了一位"义务打工的"，照理说，对项目只有帮助，而且别人是"义务"，你怎么好意思把别人赶走？
2) 我以前在西雅图的时候参加过一个非营利组织，成员们都是有热情为社区服务，而且义务付出。但是后来有些成员就逐渐找不到了，一些事情也不了了之。 由于大家都是义务贡献，你没法如何要求别人。
在Chandler 项目中，Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" -
They don't know whether to count on you or not. And because you're not getting paid, there's lack of control. [p167]
后来这位Hertzfeld 也拍拍屁股走人了，大家可以为 fun 和 Ego 一起工作，但是如果fun 和 ego 都得不到满足，那motivation 也会急剧下降。
2）责任
和驱动紧密相关的，是责任 - Accountability.
在 Hard Drive 这本书中，讲了这样的故事 - 由于Windows 一再拖延，BillG 最后跟 SteveB 说 - 如果今年下雪之前Windows 还没出来，你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么，但是第二天一个员工背着睡袋进驻了办公室。
很多年以后，Windows Vista 也经历了很长的拖延，在又一次宣布拖延之后，人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。
我们回过头来看，在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。 [有不少人离开，但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚，那我为什么一定要拼了老命要避免下一次拖延呢？
在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在"集市"，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任，那到底谁负直接责任呢？
在《移山之道》 中，我讲了下面的例子：
阿超：我今天在"顶球"网吧看到大牛他爹在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一哄而散，老崔后来也没法，只好认输了。
一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说："无责任的旁观者和有重大责任的当局者的看法自然是不一样的"。
无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。
我 在清华大学的这一次《现代软件工程》课，我发现有些学生好像不是特别投入，后来了解到，由于申请学校用的GPA只计算前三年的成绩，第四学年课程的分数就 和申请学校没有什么关系了，所以比较"鸡肋"。有一个同学说，如果这门课是在第三学年，那许多同学们会非常计较分数，排名。现在，只要能过就可以了。怪不 得一两个项目中出现了 "花最少的努力，能过就行" 的心态。
一个软件团队可以制定出动人的远景/Vision， 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。
梦断代码 读后感（II） 交流和时间
[part 2]
几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》 的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一 到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了 中文版，也有一些感想如下。
时间和交流：时间对每一个人都是公平的，对每一个软件项目也是这样。
nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs. But it was rare project manager who actually planned to allocate developers' time according to such a breakdown. [p17]
书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。在这里插播一个有奖竟猜：
| 当Windows 研发团队在开发Windows 2000的时候，团队内部每天有多少封e-mail 交流？ |
对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展（通过email 或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成"手头工作"？
一 个微软的同事前两天跟我说，他们最近没写什么代码，集中精力做"planning" 去了，大家写了很多PowerPoint，改了很多PowerPoint。然后给VP, General Manger 做了两轮汇报，然后根据VP们的意见再修改，再汇报。。。 PowerPoint 的风格变得非常专业和花哨，但是他们仍然没有完成Planning，进入实质开发阶段。华丽的 PowerPoint 中的每一个条目，也需要花PM 很多时间才能写明白，让VP 了解，同时也要花一线dev/test 很多时间才能实现，但是VP，PM 和 Dev/Test 面对同一个条目，他们心里想的是同一回事么？
外部交流
在Chandler 项目中，幸运的是，他们没有这么多VP 要汇报 （真正的VP - Al Gore 只露了一个小脸），但是我注意到他们用于交流的时间也非常多。例如
Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]
1 internal and 4 external email list set up.
blogs, wiki's...
这 些都是花时间的！我看到团队成员还要回复素未谋面的爱好者的各种问题（例如质问他们为何不用某某框架，等等），当然这种透明度也满足了很多人的好奇心，开 源，社区的优点么。。。 另一方面，项目管理人员发现他们面对着大量的任务没有时间完成。就像第一章 Doomed 的开篇就说到：
John is doomed, he has 500 hours of work scheduled between now and the next release... [p11]
团 队中其他人也好不到哪里去。那在这种情况下，是花时间继续参加各种讨论，blog，提供Transparency，满足大众的好奇心，还是集中精力把自己 "手头的事" 搞定？我从书中没有看到经验丰富的管理人员这时候采取了什么措施。事实上，在产品发布之后，没有证据表明，那些在IRC，Email，BBS 上发了很多议论的爱好者未必真正下载并使用你根据他们的意见开发出来的软件。那这么忙于交流是为嘛?!
事实上，这么多交流和信息并不能帮助人们回答一个最重要的问题 -
What had each programmer accomplished in the past week, and what task was next? [p141]
我 的故事 - 在MS Outlook97 发布之后，网上对这个V1 版本有很多意见，也有很多期待。 其中很多用户在 NewsGroup (新闻组) BBS 上发表了强烈的建议，要求Outlook 支持直接阅读 NewsGroup/BBS 的内容，当时只有Outlook Express 有这个功能。Outlook 的开发成员一度认为用户的要求太强烈了，如果我们没有这个功能，可能V2就会很不受欢迎 （几个dev 已经做了一个初始版本）。 但是大家仔细分析后发现，在BBS上强烈发言的，就是那么几个人，因为他们老用BBS，因此他们的需求特别强烈，并且好像声势浩大，但是别的大部分用户根 本就不上BBS，因此也没机会表达意见。所以Outlook 决定不做 NewsGroup 的功能，一直到现在。
内部的交流
除 了外部的交流，还有内部的交流，随着一个人经验的增多，会有很多其他人来找你，为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成，怎么办？微 软的员工对这种情况也不陌生，微软团队允许一些人 "Go Dark"，他们可以关起门自己干活，敲门不答应，不回答一般的email，不参加会议等等。
据说很早以前，BillG 把开发OS/2 API 的任务交给了一个牛人，这位前辈接受任务之后，并没有开新闻发布会，建立email distribution list, 或者QQ 群，而是挂了一个和下面类似的牌子在办公室门外，把门一关，一个人闷头开发去了。
我们知道交流很重要，但是软件不是在QQ 群中交流出来的（当然，有人在QQ 群中交流别人写好的软件），而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 "集市" 风格， "共享" 的开发氛围中，如何能保证关起门来开发呢？
//答案是 d)
梦断代码 读后感（III）远虑和近忧
[part 3]
几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》 的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一 到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了 中文版，也有一些感想如下。
Kapor 的团队看起来非常重视"远景"， 他们似乎没有近忧 - 这也许是致命的。
他们对于软件的基本架构/infrastructure 非常关心，例如对于存储系统，它们提出了下列需求：[p103]
- it has to make life easy for the Python programmers
- it has to operate efficiently over a network
- it needs to be able to handle very large individual date items and very large numbers of items
- it has to be reliable, using database "transactions."
- it has to support searching and indexing
- [0] User experience //Kapor 后来加上去的，似乎不相干的一条远景。
后来对于Data Storage，又有如下构想：[p109]
- Provide programmers with as revolutionary a data model as users
- data can live anywhere.
- Data is safe from corruption.
- Data is quick to get.
- Data can be large.
非常令人佩服的远虑。 如果一个项目能同时实现其中3个目标，就已经能实用并吸引客户，开始赚钱了。 但是Chandler 项目的同志们不满足于只实现两三个，他们要实现全部5个梦想。
一群牛人在 "没有近忧，只有远虑" 的条件下讨论问题，最后只能议而不决。 在一次次延续到深夜的讨论中，有人感慨 - "How is this night different from all other nights?" //[p110]
没有近忧，或者说不用为近忧而负责 - "我们这个月的目标没完成不要紧，但是我们的远景一定要讨论好"。 导致了项目不能收敛 - 一个项目的一个里程碑中，不确定的事情应该越来越少，bug 也越来越少，直到产品发布。
Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 - 151]
正因为大家没有近忧，所以大家可以继续等待，设计要等技术决定后才好做，而技术的选择要等设计决定后才好开始。就这样，大家折腾到2005年的时候，他们才从高瞻远睹的远虑的云端中下来，有了第一个脚踏实地的计划：
But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that ... [p232]
Kapor 毕竟是聪明人，很多年以后，他说到了教训：
We've consistently overinvested in infrastructure and design... [p342]
收 敛的另一个特点是 - 做过了的决定，就要执行，不要反复。事实上，Chandler 团队在很多决定上摇摆不定。 架构师Hertzfeld 度假回来，发现他带领其他同事奋战一个夏天得到的 Document Architecture 被扔到一边，原来 Kapor 决定 "We'll have to come back and realign things" [p168]。 如果你是做义务劳动的 Hertzfeld，你还能做下去么？
回到 "远景"， 我相信几乎没有合适的解决方案能满足"远景" 中的所有要求，很难找到 "多快好省" 的解决方案（书中提到 fast|cheap|good 不能兼得，这也是MSF 中 time | resource | feature 三个元素的矛盾）。但是往往存在若干方案，从不同的角度逼近最优，但是有各自令人讨厌的缺点。我们能否有智慧来选择这样一个方案，把近忧，远虑都慢慢解 决？
我自己在微软正在做一个创新项目，前几天一位加入这个项目不久的优秀的开发人员对我说，我们去年设计的数据库问题太多了，如果我们早就像我这样设计，估计会好很多。我不是数据库的专家，我只能对他说，如果我们当时坚持要做到今天这样才发布，这个项目也许就做不到今天了。
换句话说，正是因为早期那些不完美，但是及时的设计，让后来者有挑剔这些不完美的奢侈机会。
我们每个人在使用这些不完美的软件（Windows, Outlook, 甚至Linux）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
Zoom.Quiet
转一下邹欣老师最近写的这个系列，虽标题是读后感，但其实内容都是自己长期经验的积累，有感而发。
梦断代码 给世人一个极端的实例,来从各种方面思考银弹问题的解,,,
就 Chandler 项目现在的状态看,依然是有梦想的,,,
从一个作品的诞生动机看,怀着梦想诞生的比被合同挤出来的,怎么感觉也是前者自在些了,,,
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Usage OOo to replace M$ Office; You can get the truely Freedom 4 software.
pongba
是的，很巧今天翻了一下自己的美味书签，在unread tag下面翻到一篇旧文，是ted neward写的"can dynamic language scale"，结论部分他提到：
I find it deeply ironic that the news piece TSS cited at the top of the discussion claims that the Chandler project failed due to mismanagement, not its choice of implementation language. It doesn't even mention what language was used to build Chandler, leading me to wonder if anybody even read the piece before choosing up their sides and throwing dirt at one another.
有人讨论讨论这种可能性吗？Ted似乎是在认为Chandler的失败至少不大不小的程度上得归结于用错了语言技术？
Ted的这篇文章全文如下（不知为何暂时访问不了他的博客，以下是从google cache里面贴来的，所以有一些html格式，见谅）：
The recent "failure" of the Chandler PIM project generated the question, "Can Dynamic Languages Scale?" on TheServerSide, and, as is all too typical these days, it turned into a "You suck"/"No you suck" flamefest between a couple of posters to the site.
I now make the perhaps vain attempt to address the question meaningfully.
What do you mean by "scale"?
There's an implicit problem with using the word "scale" here, in that we can think of a language scaling in one of two very orthogonal directions:
- Size of project, as in lines-of-code (LOC)
- Capacity handling, as in "it needs to scale to 100,000 requests per second"
Part of the problem I think that appears on the TSS thread is that the posters never really clearly delineate the differences between these two. Assembly language can scale(2), but it can't really scale(1) very well. Most people believe that C scales(2) well, but doesn't scale(1) well. C++ scores better on scale(1), and usually does well on scale(2), but you get into all that icky memory-management stuff. (Unless, of course, you're using the Boehm GC implementation, but that's another topic entirely.)
Scale(1) is a measurement of a language's ability to extend or enhance the complexity budget of a project. For those who've not heard the term "complexity budget", I heard it first from Mike Clark (though I can't find a citation for it via Google--if anybody's got one, holler and I'll slip it in here), he of Pragmatic Project Automation fame, and it's essentially a statement that says "Humans can only deal with a fixed amount of complexity in their heads. Therefore, every project has a fixed complexity budget, and the more you spend on infrastructure and tools, the less you have to spend on the actual business logic." In many ways, this is a reflection of the ability of a language or tool to raise the level of abstraction--when projects began to exceed the abstraction level of assembly, for example, we moved to higher-level languages like C to help hide some of the complexity and let us spend more of the project's complexity budget on the program, and not with figuring out which register needed to have the value of the interrupt to be invoked. This same argument can be seen in the argument against EJB in favor of Spring: too much of the complexity budget was spent in getting the details of the EJB beans correct, and Spring reduced that amount and gave us more room to work with. Now, this argument is at the core of the Ruby/Rails-vs-Java/JEE debate, and implicitly it's obviously there in the middle of the room in the whole discussion over Chandler.
Scale(2) is an equally important measurement, since a project that cannot handle the expected user load during peak usage times will have effectively failed just as surely as if the project had never shipped in the first place. Part of this will be reflected in not just the language used but also the tools and libraries that are part of the overall software footprint, but choice of language can obviously have a major impact here: Erlang is being tossed about as a good choice for high-scale systems because of its intrinsic Actors-based model for concurrent processing, for example.
Both of these get tossed back and forth rather carelessly during this debate, usually along the following lines:
- Pro-Java
(and pro-.NET, though they haven't gotten into this particular debate
so much as the Java guys have) adherents argue that a dynamic language cannot scale(1) because of the lack of type-safety commonly found in dynamic languages.
Since the compiler is not there to methodically ensure that parameters
obey a certain type contract, that objects are not asked to execute
methods they couldn't possibly satisfy, and so on. In essence,
strongly-typed languages are theorem
provers, in that they take the assertion (by the programmer) that this
program is type-correct, and validate that. This means less work for
the programmer, as an automated tool now runs through a series of tests
that the programmer doesn't have to write by hand; as one contributor
to the TSS thread put it:
"With static languages like Java, we get a select subset of code tests, with 100% code coverage, every time we compile. We get those tests for "free". The price we pay for those "free" tests is static typing, which certainly has hidden costs."
Note that this argument frequently derails into the world of IDE support and refactoring (as its witnessed on the TSS thread), pointing out that Eclipse and IntelliJ provide powerful automated refactoring support that is widely believed to be impossible on dynamic language platforms. - Pro-Java adherents also argue that dynamic languages cannot scale(2) as well as Java can, because those languages are built on top of their own runtimes, which are arguably vastly inferior to the engineering effort that goes into the garbage collection facilities found in the JVM Hotspot or CLR implementations.
- Pro-Ruby (and pro-Python, though again they're not in the frame of this argument quite so much) adherents argue that the dynamic nature of these languages
means less work during the creation and maintenance of the codebase,
resulting in a far fewer lines-of-code count than one would have with a
more verbose language like Java, thus implicitly improving the scale(1) of a dynamic language.
On the subject of IDE refactoring, scripting language proponents point out that the original refactoring browser was an implementation built for (and into) Smalltalk, one of the world's first dynamic languages.
- Pro-Ruby adherents also point out that there are plenty of web applications and web sites that scale(2) "well enough" on top of the MRV (Matz's Ruby VM?) interpreter that comes "out of the box" with Ruby, despite the widely-described fact that MRV Ruby Threads are what Java used to call "green threads", where the interpreter manages thread scheduling and management entirely on its own, effectively using one native thread underneath.
- Both sides tend to get caught up in "you don't know as much as me about this" kinds of arguments as well, essentially relying on the idea that the less you've coded in a language, the less you could possibly know about that language, and the more you've coded in a language, the more knowledgeable you must be. Both positions are fallacies: I know a great deal about D, even though I've barely written a thousand lines of code in it, because D inherits much of its feature set and linguistic expression from both Java and C++. Am I a certified expert in it? Hardly--there are likely dozens of D idioms that I don't yet know, and certainly haven't elevated to the state of intuitive use, and those will come as I write more lines of D code. But that doesn't mean I don't already have a deep understanding of how to design D programs, since it fundamentally remains, as its genealogical roots imply, an object-oriented language. Similar rationale holds for Ruby and Python and ECMAScript, as well as for languages like Haskell, ML, Prolog, Scala, F#, and so on: the more you know about "neighboring" languages on the linguistic geography, the more you know about that language in particular. If two of you are learning Ruby, and you're a Python programmer, you already have a leg up on the guy who's never left C++. Along the other end of this continuum, the programmer who's written half a million lines of C++ code and still never uses the "private" keyword is not an expert C++ programmer, no matter what his checkin metrics claim. (And believe me, I've met way too many of these guys, in more than just the C++ domain.)
A couple of thoughts come to mind on this whole mess.
Just how refactorable are you?
First of all, it's a widely debatable point as to the actual refactorability of dynamic languages. On NFJS speaker panels, Dave Thomas (he of the PickAxe book) would routinely admit that not all of the refactorings currently supported in Eclipse were possible on a dynamic language platform given that type information (such as it is in a language like Ruby) isn't present until runtime. He would also take great pains to point out that simple search-and-replace across files, something any non-trivial editor supports, will do many of the same refactorings as Eclipse or IntelliJ provides, since type is no longer an issue. Having said that, however, it's relatively easy to imagine that the IDE could be actively "running" the code as it is being typed, in much the same way that Eclipse is doing constant compiles, tracking type information throughout the editing process. This is an area I personally expect the various IDE vendors will explore in depth as they look for ways to capture the dynamic language dynamic (if you'll pardon the pun) currently taking place.
Who exactly are you for?
What sometimes gets lost in this discussion is that not all dynamic languages need be for programmers; a tremendous amount of success has been achieved by creating a core engine and surrounding it with a scripting engine that non-programmers use to exercise the engine in meaningful ways. Excel and Word do it, Quake and Unreal (along with other equally impressively-successful games) do it, UNIX shells do it, and various enterprise projects I've worked on have done it, all successfully. A model whereby core components are written in Java/C#/C++ and are manipulated from the UI (or other "top-of-the-stack" code, such as might be found in nightly batch execution) by these less-rigorous languages is a powerful and effective architecture to keep in mind, particularly in combination with the next point....
Where do you run again?
With the release of JRuby, and the work on projects like IronRuby and Ruby.NET, it's entirely reasonable to assume that these dynamic languages can and will now run on top of modern virtual machines like the JVM and the CLR, completely negating arguments 2 and 4. While a dynamic language will usually take some kind of performance and memory hit when running on top of VMs that were designed for statically-typed languages, work on the DLR and the MLVM, as well as enhancements to the underlying platform that will be more beneficial to these dynamic language scenarios, will reduce that. Parrot may change that in time, but right now it sits at a 0.5 release and doesn't seem to be making huge inroads into reaching a 1.0 release that will be attractive to anyone outside of the "bleeding-edge" crowd.
So where does that leave us?
The allure of the dynamic language is strong on numerous levels. Without having to worry about type details, the dynamic language programmer can typically slam out more work-per-line-of-code than his statically-typed compatriot, given that both write the same set of unit tests to verify the code. However, I think this idea that the statically-typed developer must produce the same number of unit tests as his dynamically-minded coworker is a fallacy--a large part of the point of a compiler is to provide those same tests, so why duplicate its work? Plus we have the guarantee that the compiler will always execute these tests, regardless of whether the programmer using it remembers to write those tests or not.
Having said that, by the way, I think today's compilers (C++, Java and C#) are pretty weak in the type expressions they require and verify. Type-inferencing languages, like ML or Haskell and their modern descendents, F# and Scala, clearly don't require the degree of verbosity currently demanded by the traditional O-O compilers. I'm pretty certain this will get fixed over time, a la how C# has introduced implicitly typed variables.
Meanwhile, why the rancor between these two camps? It's eerily reminiscent of the ill-will that flowed back and forth between the C++ and Java communities during Java's early days, leading me to believe that it's more a concern over job market and emplyability than it is a real technical argument. In the end, there will continue to be a ton of Java work for the rest of this decade and well into the next, and JRuby (and Groovy) afford the Java developer lots of opportunities to learn those dynamic languages and still remain relevant to her employer.
It's as Marx said, lo these many years ago: "From each language, according to its abilities, to each project, according to its needs."
Oh, except Perl. Perl just sucks, period.
PostScript
I find it deeply ironic that the news piece TSS cited at the top of the discussion claims that the Chandler project failed due to mismanagement, not its choice of implementation language. It doesn't even mention what language was used to build Chandler, leading me to wonder if anybody even read the piece before choosing up their sides and throwing dirt at one another.
Kenny Yuan
同一个事情，常常是"仁者风仁，智才见智"，但有时候更夸张，是"黑者见黑，白者见白"——完全相反的观点从同一个例子中得出
像outlook的那个例子，就可以正反两方面说（业界有一句名言："一个愤怒的用户背后是1000个离开的用户"），真*相究竟如何，恐怕不是听人讲故事和想像猜测能够得出结论的。或者，如果有人认为自己的判断准确，请在几年前的背景下考虑这个问题：outlook中是否应该加入RSS功能？
Chandler毕竟只是个案。不宜过多推广。比如《读后感1》中对"驱动力"和"责任"的怀疑是有些道理的，但这样会给人造成一种错误印象，认为在这么基本的问题上都有重大漏洞，这种模式怎么可能会走得通呢？其实这种方式在某些情况下是走得通的，人们需要的是这样一个问题的答案（而不是对它进行Yea/Nay的回答）：目前这种模式走得通的概率多大？
当然，作为感想，不应该为这种错误印象负责任。但作为一个教师，如果考虑更多，并且少作结论（或罗列向着同一个结论的事例），那么对他的学生会更有益处。
（说到责任问题，我也想到一个例子：10年前有些为什么企业不使用Linux？一个原因是：没有花钱购买，出问题时也就无法找到为之负责的厂商。那么，为什么现在这几乎不再是一个问题了？你认为原因有多少个？分别是什么？有没有数据能支持你的这种判断？）
《读后感3》中关于设计应该"完美与否"的倾向性很明显。读过文章后应该很容易赞同作者。但是什么是完美呢？每个人，每个team，每个公司的判断标准不同，得出的结论（特别是事前的结论，而不是事后的）也就不尽相同。如果作者关于完美与否的结论是正确的，我们打算去应用它指导当前项目，可是出现这样的情况该怎么办：1、有人用"不完美更佳"作为借口拒绝良好的设计；2、有人认为当前的设计离完美还很远，我们现在就还可以在合理范围内改进它。如果出现了这样的种种情况，这种"完美与否"的标签应该如何去使用呢？
还有一个问题，我想我需要帮助作者补充："完美与否"与项目成功与否没有严格的因果律？它是否需要和许多其它的因素共同起作用？
下面说一下我的读后感（对"读后感"的"读后感"）：如果有一个人的文章，能让读者看过后，认为自己已经了解了事情的本质，许多人就会捧着它大声叫好。因为它让人有一种"终于明白事情运行机理"的成就感(http://www.howstuffworks.com/)，这样就能够让自己显得很niubility；特别是对于有些人，对事情有些感性认识但没有完全搞懂，或没有亲自体验过（参见那个网站中的种种条目，不可能每个人对每种都亲身经历过吧？），在读过这类文章后觉得自己"终于明白了！"，这种情况就觉得more niubility，就更为叹服这篇文章。人们喜欢并乐于传播这样的讲演/文章/畅销书：将成功/失败的原因总结趋于简单化，如："我之所以成功（或失败），是因为重视（或忽视）了人才。"
但是，Dreaming In Code的作者没有这样做，他只是在叙述他了解的事情的整个过程，因为他知道这样复杂的一件事情不是能够那样简单地归结出原因的，甚至事情的成败还未最终定论。但是他的这种苦心被一些人直接无视了，他们仍旧在这本书的基础上得出结论并乐于推广。我曾经推荐这本书给许多人，有些人读过后跟我说：哦，不就是Chandler么，其实我很早就知道这个项目，它之所以失败，是因为……布拉布拉
Tiny fool
这本书是我的好友韩磊翻译的，所以问世之前，我就听过了书中的很多故事。但是因为赠书一直没有给的原因，我还没有看过全文。也许我有点武断，虽然我看过样章后就很推崇这本书，我总是觉得幸福的家庭是丰富多彩的，不幸的家庭却总是一样的。历史上有无数的错误的案例，为什么还有那么多项目继续前仆后继的去失败呢？我参加过一些项目，有些看似成功，但是实际上早已失败，有些一开始就错的很离谱。
我不想谈我得到了什么教益，因为我觉得对某些失败，我的认识不停的还在改变。但是我想说，很可悲的是，一旦成功就没有人知道你本来就做错了，即使失败了，也没有人能完全准确的找到负责人，所以我们身边充斥着各种各样的成功经验，有些来自于还没失败的项目，有些干脆就来自失败的项目。错误的种子，往往流传的更广。
这就是我另外一个由来已久的看法，很多巨大成功的事情，也很难说到底有多大的创新，而只是犯的错误少些，或者改正了前人的错误。例如Gmail的成功，很多人认为是UI好，我只看重容量这一点。不是说任何时候都是越大越好，而是说，在Gmail推出的时候，有1G的容量，你才能让用户真得喜欢用WebMail。现在仍旧写在Gmail首页的有这么一句话" you'll never need to delete another message"，这是核心的真理，如果用户在webmail上面需要删除邮件才能保证有足够的空间的话，那么他就不那么需要Webmail。但是这真得是伟大的创新么？我不觉得，我觉得是之前的邮件运营商们忘记了什么是用户真正的需求。97-98年的4M邮箱，就等于现在的1G，那时候，他们是酷的，是创新的，只是他们忘了时代变了。97-98年4M可以放下用户一年的信件，现在1G才可以。当年邮箱不用提供牛屄的垃圾邮件过滤系统，现在不行，我多次想尝试用用hotmail，但是人工从面摘取不是spam的信件太吃力了，所以，hotmail只能被我遗忘。所以，Gmail提供好的垃圾过滤，你可以说酷，但是那只是有人开始满足用户真正的需求而已。
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Msn: tiny...@hotmail.com
Phone: 13520711089
银杏技术咨询公司
http://www.yinxingtech.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
Kenny Yuan
我不想谈我得到了什么教益，因为我觉得对某些失败，我的认识不停的还在改变。但是我想说，很可悲的是，一旦成功就没有人知道你本来就做错了，即使失败了，也没有人能完全准确的找到负责人，所以我们身边充斥着各种各样的成功经验，有些来自于还没失败的项目，有些干脆就来自失败的项目。错误的种子，往往流传的更广。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
Zoom.Quiet
> 这个书评，我之前也共享过，但是不至于推崇。因为我觉得这里面确实有一些闪光的想法，但是有些想法又比较，或者类似"Kenny Yuan"说的反正话太多。
>
从自个儿的土拨鼠洞里探出头来,,,
从主流媒体的宣传中探出头来,,,
从朋友们忽悠的项目体验中探出头来,,,
看一看真实世界中的理想童话,以便找准当前的位置,靠谱的,一点点儿的改进,,,
> 这本书是我的好友韩磊翻译的，所以问世之前，我就听过了书中的很多故事。但是因为赠书一直没有给的原因，我还没有看过全文。也许我有点武断，虽然我看过样章后就很推崇这本书，我总是觉得幸福的家庭是丰富多彩的，不幸的家庭却总是一样的。历史上有无数的错误的案例，为什么还有那么多项目继续前仆后继的去失败呢？我参加过一些项目，有些看似成功，但是实际上早已失败，有些一开始就错的很离谱。
>
> 我不想谈我得到了什么教益，因为我觉得对某些失败，我的认识不停的还在改变。但是我想说，很可悲的是，一旦成功就没有人知道你本来就做错了，即使失败了，也没有人能完全准确的找到负责人，所以我们身边充斥着各种各样的成功经验，有些来自于还没失败的项目，有些干脆就来自失败的项目。错误的种子，往往流传的更广。
>
这是经典的劣币淘汰良币的行为哪,,,不用惊奇的,
也正是这种社会行为機制才保证了,少数清醒的人,结合机会才得以成功的哪!
> 这就是我另外一个由来已久的看法，很多巨大成功的事情，也很难说到底有多大的创新，而只是犯的错误少些，或者改正了前人的错误。例如Gmail的成功，很多人认为是UI好，我只看重容量这一点。不是说任何时候都是越大越好，而是说，在Gmail推出的时候，有1G的容量，你才能让用户真得喜欢用WebMail。现在仍旧写在Gmail首页的有这么一句话"
> you'll never need to delete another
> message"，这是核心的真理，如果用户在webmail上面需要删除邮件才能保证有足够的空间的话，那么他就不那么需要Webmail。但是这真得是伟大的创新么？我不觉得，我觉得是之前的邮件运营商们忘记了什么是用户真正的需求。97-98年的4M邮箱，就等于现在的1G，那时候，他们是酷的，是创新的，只是他们忘了时代变了。97-98年4M可以放下用户一年的信件，现在1G才可以。当年邮箱不用提供牛屄的垃圾邮件过滤系统，现在不行，我多次想尝试用用hotmail，但是人工从面摘取不是spam的信件太吃力了，所以，hotmail只能被我遗忘。所以，Gmail提供好的垃圾过滤，你可以说酷，但是那只是有人开始满足用户真正的需求而已。
>
以用户为中心,是永远不会变的,
但是在 2.0 时代,讨好少数靠谱的用户,比满足所有用户的基本需求,更加靠谱了,,,
服务要个性化,,,这是更加强烈的趋势,,,
> 2008/12/29 Kenny Yuan <yuank...@gmail.com>
>>
>> 文章中的"反正话儿"太多了，作为感想来说，是很好的感想，但是有一些地方不足以服人。
>> 同一个事情，常常是"仁者风仁，智才见智"，但有时候更夸张，是"黑者见黑，白者见白"——完全相反的观点从同一个例子中得出
>>
>> 像outlook的那个例子，就可以正反两方面说（业界有一句名言："一个愤怒的用户背后是1000个离开的用户"），真*相究竟如何，恐怕不是听人讲故事和想像猜测能够得出结论的。或者，如果有人认为自己的判断准确，请在几年前的背景下考虑这个问题：outlook中是否应该加入RSS功能？
>>
>> Chandler毕竟只是个案。不宜过多推广。比如《读后感1》中对"驱动力"和"责任"的怀疑是有些道理的，但这样会给人造成一种错误印象，认为在这么基本的问题上都有重大漏洞，这种模式怎么可能会走得通呢？其实这种方式在某些情况下是走得通的，人们需要的是这样一个问题的答案（而不是对它进行Yea/Nay的回答）：目前这种模式走得通的概率多大？
>> 当然，作为感想，不应该为这种错误印象负责任。但作为一个教师，如果考虑更多，并且少作结论（或罗列向着同一个结论的事例），那么对他的学生会更有益处。
>>
>> （说到责任问题，我也想到一个例子：10年前有些为什么企业不使用Linux？一个原因是：没有花钱购买，出问题时也就无法找到为之负责的厂商。那么，为什么现在这几乎不再是一个问题了？你认为原因有多少个？分别是什么？有没有数据能支持你的这种判断？）
>>
>>
>>
>> 《读后感3》中关于设计应该"完美与否"的倾向性很明显。读过文章后应该很容易赞同作者。但是什么是完美呢？每个人，每个team，每个公司的判断标准不同，得出的结论（特别是事前的结论，而不是事后的）也就不尽相同。如果作者关于完美与否的结论是正确的，我们打算去应用它指导当前项目，可是出现这样的情况该怎么办：1、有人用"不完美更佳"作为借口拒绝良好的设计；2、有人认为当前的设计离完美还很远，我们现在就还可以在合理范围内改进它。如果出现了这样的种种情况，这种"完美与否"的标签应该如何去使用呢？
>> 还有一个问题，我想我需要帮助作者补充："完美与否"与项目成功与否没有严格的因果律？它是否需要和许多其它的因素共同起作用？
>>
>>
>>
>> 下面说一下我的读后感（对"读后感"的"读后感"）：如果有一个人的文章，能让读者看过后，认为自己已经了解了事情的本质，许多人就会捧着它大声叫好。因为它让人有一种"终于明白事情运行机理"的成就感(http://www.howstuffworks.com/)，这样就能够让自己显得很niubility；特别是对于有些人，对事情有些感性认识但没有完全搞懂，或没有亲自体验过（参见那个网站中的种种条目，不可能每个人对每种都亲身经历过吧？），在读过这类文章后觉得自己"终于明白了！"，这种情况就觉得more
>> niubility，就更为叹服这篇文章。人们喜欢并乐于传播这样的讲演/文章/畅销书：将成功/失败的原因总结趋于简单化，如："我之所以成功（或失败），是因为重视（或忽视）了人才。"
>> 但是，Dreaming In
>> Code的作者没有这样做，他只是在叙述他了解的事情的整个过程，因为他知道这样复杂的一件事情不是能够那样简单地归结出原因的，甚至事情的成败还未最终定论。但是他的这种苦心被一些人直接无视了，他们仍旧在这本书的基础上得出结论并乐于推广。我曾经推荐这本书给许多人，有些人读过后跟我说：哦，不就是Chandler么，其实我很早就知道这个项目，它之所以失败，是因为……布拉布拉
>
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Free as in Freedom! 哲思自由软件社区:http://zeuux.org
pongba
我不想谈我得到了什么教益，因为我觉得对某些失败，我的认识不停的还在改变。但是我想说，很可悲的是，一旦成功就没有人知道你本来就做错了，即使失败了，也没有人能完全准确的找到负责人，所以我们身边充斥着各种各样的成功经验，有些来自于还没失败的项目，有些干脆就来自失败的项目。错误的种子，往往流传的更广。
泛化一下:D
事情的成败
1)往往是很多因素综合作用的结果，而我们的大脑又总是禁不住"单一因果"的诱惑。
2)连当事人往往也未必能够分析出来到底是什么原因导致的。因为当事人在对其成功归因的时候，往往是从两个方面入手的
- "我跟别人有什么地方不一样？" （实际上这倒是个很有用的启发法，只不过并不总是work就是了，因为毕竟自己能够觉察到的区别受到对"别人"的各方面因素的了解，和对自己的了解。有可能自己总结出来的差异性其实是一个minor的因素，而真正的significant的差别却不容易感受到，比如性格方面的差异往往是很隐蔽的，因为性格对于我们就好比水对于鱼一样）
- "我原先猜测这个会让我成功，后来我成功了，因此，原因肯定就是我当时猜测的那个"（confirmation bias）李笑来老师在《把时间当做朋友》里面讲了一个故事(via)：
- 其实还有第三个方面：我们认为是由于我们和别人的某些不一样导致我们成功的，然而这种将成功归因于自己的某些特质本身就是有所偏颇（不全面）的，因为它忽略了外界的随机因素（即运气），这一点在随机市场（如股市）中尤其常见：我们脑袋里有一个买卖策略，然后我们遵从这个策略，结果我们赚钱了，于是我们把它作为一个证据证明我们的策略是对的，只可惜往往实际上只不过是运气好导致的。如果我们使用一个策略，然后成功了，这并不代表成功就是该策略导致的，也许该策略起到了一定的正面作用，但是否决定性作用并不知道，是否是成功的必要或充分条件，也不知道。甚至该策略可能起到了负面作用。要证明该策略和成功的关系，只能通过随机控制实验，随机分两组，一组用该策略一组不用，观察结果差异。对于多个因素互相影响的复杂系统而言，随机控制实验是目前唯一能够靠谱地观测两个变量之间的相关关系的方法。我的教练臂围是43厘米，几乎和常人的大腿一般粗。有一次他告诉我他练习的诀窍——握哑铃的时候，一定要把手掌边缘贴到靠体侧的那一个哑铃片上。这 样的话，哑铃的另外一端将自然地向外翻转一个很小的角度，臂屈伸的时候恰好可以使肌肉获得最大的曲张刺激。然后他得意而灿烂地笑着说，"多简单啊！"而我 却突然明白了另外一件事：他的成功其实并不是来自于这个所谓"简单而神秘的技巧"，因为我认识另外一个健身教练臂围45厘米，我从来没看到那个45厘米臂 围的教练用这种方法握哑铃。但他们都成功了。
超出常人的臂围是这样练出来的：二头肌的常用练习动作只有那么三五个。每周专门针对二头肌练习一次；每次三个动作；每个动作至少要做５组；每组要重 复做８～１２次同一动作；重量要计算到恰好再也做不动了为止；持续５４周以上——至于如何握哑铃，关系并不大。尤其，对普通人来说，４３厘米和４５厘米没 什么区别，都是"粗的跟大腿似的……"最重要的只不过是这个：重复，不间断地重复，重复一年以上。
pongba
例如Gmail的成功，很多人认为是UI好，我只看重容量这一点。不是说任何时候都是越大越好，而是说，在Gmail推出的时候，有1G的容量，你才能让用户真得喜欢用WebMail。现在仍旧写在Gmail首页的有这么一句话" you'll never need to delete another message"，这是核心的真理，如果用户在webmail上面需要删除邮件才能保证有足够的空间的话，那么他就不那么需要Webmail。但是这真得是伟大的创新么？我不觉得，我觉得是之前的邮件运营商们忘记了什么是用户真正的需求。97-98年的4M邮箱，就等于现在的1G，那时候，他们是酷的，是创新的，只是他们忘了时代变了。97-98年4M可以放下用户一年的信件，现在1G才可以。当年邮箱不用提供牛屄的垃圾邮件过滤系统，现在不行，我多次想尝试用用hotmail，但是人工从面摘取不是spam的信件太吃力了，所以，hotmail只能被我遗忘。所以，Gmail提供好的垃圾过滤，你可以说酷，但是那只是有人开始满足用户真正的需求而已。
GMail 一开始的成功可以归因为容量，在其他方面不比别人差的情况下，拥有一个杀手特性，于是吸引了一批客户。但是在别人可以迅速模仿这些特性的IT领域，后来持续维持成功就不能仅仅仍然归因于容量了，必须持续做到"人无我有，人有我新，人新我变"。
再到后来，维持成功的因素也许又会发生变化，因为积累了大量的用户之后，即便产品没有新兴产品做得那么好，也仍然能够持续成功，因为市场的惯性（用户习惯；用户因迁移成本而产生的惰性；因多数人使用该产品而带来的从众效应、品牌效应等等），所以占领市场的公司，到后来其产品未必是最优的（当然前提是跟同类产品相比也没有致命弱点），但至少肯定是人最多的:P
Kenny Yuan
我的教练臂围是43厘米，几乎和常人的大腿一般粗。有一次他告诉我他练习的诀窍——握哑铃的时候，一定要把手掌边缘贴到靠体侧的那一个哑铃片上。这 样的话，哑铃的另外一端将自然地向外翻转一个很小的角度，臂屈伸的时候恰好可以使肌肉获得最大的曲张刺激。然后他得意而灿烂地笑着说，"多简单啊！"而我 却突然明白了另外一件事：他的成功其实并不是来自于这个所谓"简单而神秘的技巧"，因为我认识另外一个健身教练臂围45厘米，我从来没看到那个45厘米臂 围的教练用这种方法握哑铃。但他们都成功了。
超出常人的臂围是这样练出来的：二头肌的常用练习动作只有那么三五个。每周专门针对二头肌练习一次；每次三个动作；每个动作至少要做５组；每组要重 复做８～１２次同一动作；重量要计算到恰好再也做不动了为止；持续５４周以上——至于如何握哑铃，关系并不大。尤其，对普通人来说，４３厘米和４５厘米没 什么区别，都是"粗的跟大腿似的……"最重要的只不过是这个：重复，不间断地重复，重复一年以上。
我跑我跑我跑跑跑……题……
其实还有一种方法能更快地增加上臂围：除了每天练到胳膊举不动之外，多吃蛋白粉，多吃维生素，多吃肌酸，所有食物都要搅成糊吃以利于吸收，此外还要多吃激素（严重警告：睾丸酮类长期服用可能会使性能力丧失），如果能够坚持下来，上臂围超50也是很常见的事情……
伊索寓言式的结尾：以上的故事告诉我们什么呢？——每个人都想走捷径，而且往往也是有捷径可以走；只不过，捷径是有代价的。
峰郭
Tiny fool
我的意思是，不要小看容量这一变化，在这里容量带来了质变。Webmail中Hotmail算是个鼻祖，后面跟风者如云，然而，到了Gmail出现的时候。全球的Webmail都已经到了穷途末路之境，国内的尤其是，多加百兆的容量然后收点服务费，貌似是最好的选择。但是后面据我认识的朋友告诉我，VIP邮箱没什么真正的油水。整个世界都认为Webmail就这么没什么意思了，要被超越的时候Gmail冒出来了。
容量大，才能做到文件都不删除，才能实现你不管到哪里，只要打开一个浏览器，就可以看到你全部的邮件。这不是简单的容量增加，这是重新定义Webmail，或者说让Webmail回归本意。所以，我的意思是，不是Gmail有多牛。而是做老的Webmail的大家都迷失了，那时候的Webmail强调pop3特性，希望用户都把信收到本地，然后删除服务器存档。web端的操作方便等等也不被重视。这样就把Webmail这本来可以作为每个人的随时在线的信息中心的作用抹杀了。Gmail做的就是拨乱反正，回到正途。
就像我的Macbook因为硬件问题，崩溃过几次，我从来不备份apple mail，因为Gmail有全部的备份，下次安装好机器以后，再从新让Apple mail去同步就可以了。这样我永远保持了信息的随时在线，也完全不损失本地操作的灵活和迅速，以及离线时的处理信息的能力。
pongba
全球的Webmail都已经到了穷途末路之境，国内的尤其是，多加百兆的容量然后收点服务费，貌似是最好的选择。但是后面据我认识的朋友告诉我，VIP邮箱没什么真正的油水。整个世界都认为Webmail就这么没什么意思了
这个有意思，我对这段历史没有任何感觉，因为接触网络比tiny晚多了。所以我想在这个问题上多向tiny请教两句：
1) 当时为什么没有人想到通过广告收费？而不是通过收取容量费。
2) 本地客户端有很多不便（设置麻烦&需要安装从而对新手不利，本地存储从而对同步不利），webmail没这个问题，即便容量较小，但毕竟那个时候用邮件的人也没有今天那么多邮件吧？（猜测）为什么webmail却到了穷途末路呢？是不是带宽原因？webmail在那个时候不增加容量是不是又是因为硬件价格原因呢？
pongba
2) 本地客户端有很多不便（设置麻烦&需要安装从而对新手不利，本地存储从而对同步不利），webmail没这个问题，即便容量较小，但毕竟那个时候用邮件的人也没有今天那么多邮件吧？（猜测）为什么webmail却到了穷途末路呢？是不是带宽原因？webmail在那个时候不增加容量是不是又是因为硬件价格原因呢？
再加一个猜测：是不是Ajax那个时候还没流行？
Tiny fool
电子邮件最早像是某种标准件，不管什么网站都要做。最早的时候中国的大ICP几乎都有自己的电子邮件，好像你没有一个电子邮件系统就不是一个合格的网站一样。那时候没人考虑邮件怎么赚钱，唯一通过邮件赚钱的就是类似网易这种给别人提供电子邮件的公司。
到了后来，网站的其他部分开始赚钱，但是邮件还是没又开始赚钱。而用户需要的空间越来越大（比如开始流行带附件，尤其是某些多媒体的。或者就是本身邮件数目狂增。再者也有垃圾邮件的功劳），邮件服务提供者没有赚到钱，当然不会继续再给用户增大空间。
最早的时候，很多人是不懂如何使用本地客户端的，但是如果你的空间总是占满，你要不然就需要随时删邮件，要不然就需要学会本地客户端。我01年在某公司做网管的时候，一个常见的任务就是帮助公司的员工配置他们的邮件客户端，或者修复邮件客户段出现的问题。所以诚如你所说，那东西很不方便，但是因为webmail空间不足，实际就强迫用户转向了用本地客户端收信。其他的一些原因，还包括过去网速比较慢，信件较多的时候，客户端明显效率高些（对于时间收费的网民也经济一些，那时候的好习惯是，上线收信，下线回信）。
另一方面，随着ICP网站的发展，邮件客户越来越多，占用了大量的资源，却毫无收益。所以在，02-03年左右（具体时间待查吧），263等开始停止或者部分停止免费服务，开始VIP收费服务。虽然后来据说某些VIP还是收到了大量的金钱。但是很多服务商直接关闭免费，我说他们穷途末路估计不过分，不到穷途末路，谁会把花了大量真金白银的才积累来的客户都赶走了。
这里的矛盾在于，ICP网站希望用户使用他们的Webmail，有流量可以做广告，但是空间给的少，用户自然很少上Webmail，而直接用客户端收信。ICP网站都不希望用户用pop3，因为消耗一样的流量，一点钱都赚不到。但是谁也不敢率先不支持pop3，把用户推给对手。
Webmail最大的好处在于随时在线，信息不需要同步，用户会有非常高的粘度。但是容量不足，速度不快，用起来不方便，用户就会转向客户端。所以,Gmail出现的时机很好，全球带宽水平都已经上来了，网速很快了，我们可以上网的地点和场景也多了，所以然后解决容量问题和便捷问题以后就自然会受到用户的追捧。
2008/12/29 pongba <pon...@gmail.com>
Kenny Yuan
1）当时投放广告的模式还没改过来，还没有这样在邮箱里准确投放广告的。可以说google在邮件方面又发明了一根电线杆
2）容量费是在泡沫吹破的时候向用户趁伙打劫的，形成了习惯思维吧？中国还有尝试手机（通知）收费的
本地客户的使用模式有惯性，而且大家都觉得邮件在本地才保险（还是思维惯性吧）
那个时候，发达国家的带宽正好在增长，对于webmail应该算是已经可用了，这个时机也不错（现在他们的ADSL2+更牛——相比我们的ADSL来说）
3）如你所说，AJAX。那时候的Webmail都是点一下要刷半天的传统HTML，UE太差
最重要的一点：gmail让后来的用户觉得"webmail的世界本来就应该是这个样子"（用户通常不知道要什么，直到你给了他真正想要的东西）
Kenny Yuan
Bennie
On Dec 29, 4:04 pm, "Kenny Yuan" <yuankain...@gmail.com> wrote:
> 再加一条：如果一个人在同一台计算机上收邮件，那么对client的惯性就很难改变，直到他开始在2台或2台以上的电脑上试图同步邮件......可能当时人们使用邮件 的习惯开始向这个方向发展了？（这一条是我估计的，没谱儿）
>
> 2008/12/29 Kenny Yuan <yuankain...@gmail.com>
>
>
>
> > 我来插一句，看看别人和我的印象是不是相同的：
>
> > 1）当时投放广告的模式还没改过来，还没有这样在邮箱里准确投放广告的。可以说google在邮件方面又发明了一根电线杆
> > 2）容量费是在泡沫吹破的时候向用户趁伙打劫的，形成了习惯思维吧？中国还有尝试手机（通知）收费的
> > 本地客户的使用模式有惯性，而且大家都觉得邮件在本地才保险（还是思维惯性吧）
> > 那个时候，发达国家的带宽正好在增长，对于webmail应该算是已经可用了，这个时机也不错（现在他们的ADSL2+更牛----相比我们的ADSL来说）
> > 3）如你所说，AJAX。那时候的Webmail都是点一下要刷半天的传统HTML，UE太差
>
> > 最重要的一点：gmail让后来的用户觉得"webmail的世界本来就应该是这个样子"（用户通常不知道要什么，直到你给了他真正想要的东西）
>
> > 2008/12/29 pongba <pon...@gmail.com>
>
> >> 2008/12/29 Tiny fool <tinyf...@gmail.com>
>
> >>> 全球的Webmail都已经到了穷途末路之境，国内的尤其是，多加百兆的容量然后收点服务费，貌似是最好的选择。但是后面据我认识的朋友告诉我，VIP邮箱没什 么真正的油水。整个世界都认为Webmail就这么没什么意思了
>
> >> 这个有意思，我对这段历史没有任何感觉，因为接触网络比tiny晚多了。所以我想在这个问题上多向tiny请教两句：
>
> >> 1) 当时为什么没有人想到通过广告收费？而不是通过收取容量费。
> >> 2)
> >> 本地客户端有很多不便（设置麻烦&需要安装从而对新手不利，本地存储从而对同步不利），webmail没这个问题，即便容量较小，但毕竟那个时候用邮件的人也没 有今天那么多邮件吧？（猜测）为什么webmail却到了穷途末路呢？是不是带宽原因？webmail在那个时候不增加容量是不是又是因为硬件价格原因呢？
Kenny Yuan
chan jar
又有谁能说软件开发不是一场灾难呢。。。
Jeffrey Zhao
zhusupe
Kenny Yuan 于 12/29/2008 04:04 PM http://embed.mibbit.com/?channel=zhusupe 写道:
> 再加一条：如果一个人在同一台计算机上收邮件，那么对client的惯性就很难改
> 变，直到他开始在2台或2台以上的电脑上试图同步邮件……可能当时人们使用邮件的
> 习惯开始向这个方向发展了？（这一条是我估计的，没谱儿）
>
> 2008/12/29 Kenny Yuan <yuank...@gmail.com <mailto:yuank...@gmail.com>>
graham
Live Mail和Hotmail的关系，本质上是个变种的私有的IMAP协议，而且据此把客户端限定在微软自家的产品上，这可不是件好事情。
2008/12/29 Jeffrey Zhao <je...@live.com>: