Hello World
Spiga

Silverlight与微软技术(下):微软技术与技术学习

2010-11-04 10:57 by 老赵, 5275 visits

经常听到有人说微软的技术变化太快,持续性不好,让程序员追得很累。这种观点在微软技术社区内部和外部都有出现,似乎是一个不争的事实。但从我追随.NET平台这近十年的时间里,我并没有明显的感觉。微软的技术的确很多,但至少在.NET领域过渡性做的非常好,我没有任何疲惫之感。微软技术开拓了我的眼界,让我在微软内外许多技术方面越来越少有“新奇”的感觉,一切都是那么自然和稳妥。我现在就来仔细谈谈我在学习微软技术方面的经验与感受。

我一直对编程有浓厚的兴趣,上大学前在编程方面的经验主要来自于信息学竞赛,此外就是用一些VB或是Delphi写一些小程序,拿去参加高中的一些名不见经传的小比赛,那点小名次,小打小闹,仅此而已。到了大学里,学习(或自学)了Java,少许LISP,数据结构与算法,操作系统,计算机体系结构,计算机网络,编译原理等最传统的科班课程,但似乎学的不太好,现在想来颇是后悔。此外学过几次C++,但智商有限,几次下来都没有坚持到底,现在也忘得差不多了。可以这么说,我的专业程序员生涯的成长离不开微软与.NET。当然,我热爱各种技术,各方面也学习了很多。我接下来也会说到,技术本就不应该分为“微软”与“非微软”两个部分。

我在大学的时候学习和使用的是Java,也用Java参与了一些奇怪的“企业项目”——如上海海关进出口检疫局的什么什么系统(不过那时候我也已经开始接触C# 1.0和.NET了)。后来由于去了微软,自然全面转向.NET。我在微软只待了一年半,但这一年半给我最大的帮助就是让我开阔了眼界,知道技术领域有多么广阔,知道学校里了解的一些东西是多么的不靠谱。可以说在微软的这段时间对我来说是个突破,从那时起我就对各种技术都抱有强烈的兴趣。

有人说微软技术发展太快,且时常淘汰很多东西,对此我并不赞同太多。我接触到的说微软技术变化太快的同学,大都是老程序员,他们因为微软将重心放在了.NET上,导致了COM等技术运用场景减少,于是颇为不满。他们时不时“预言”微软以后会抛下.NET,虽然.NET已经发展了近10年,且力度越来越大,所以我称这种“预言”是一种FUD。我是从.NET 1.x/C# 1.0学起的,一直到现在,无论是语言还是基础类库,一切都良好过渡。您在C# 1.0里学到的东西,有哪些在C# 4.0里消失了么?您写的ASP.NET 2.0程序,直接无痛升级到ASP.NET 3.5——这是大众点评网的架构师在分享会上提到的,它的应用规模及复杂度不低于您的项目吧?微软是个对企业应用有许多投入的公司,在过渡和兼容性方面必须做到几乎百分百的保证,这些经验也总结成册,例如获得Jolt大奖的《Framework Design Guildline》,其中不断强调的一点,就是在设计时对兼容性方面的考虑。

在兼容性方面,某些技术领域的程序员就有更高的“觉悟”。例如Python 3.0成为了一门不兼容Python 2.x的语言,Rails 3.0也不兼容Rails 2.x。我咨询过几个Rails程序员对此的看法,他们观点十分一致,那就是对Rails 3.0很有好感,至于以前的项目,“没有必要从2.x升级到3.0啊!”。我也支持他们的看法,如果您不喜欢C#里的新特性,那就不用那些特性。如果您不喜欢新框架的功能,那就继续用原来的方式做事情,新的框架也不会对您有影响。我支持Python和Rails项目发展的决定,他们为了前进抛下一些历史包袱,我可以理解。这并不会影响我对Python和Rails的喜爱,它们依然是十分优秀的语言和框架。

有人说,微软会淘汰技术,那么对这些技术的投资不就失效了吗?这方面我认为自己有很好的发言权。我之前也提到过,我在社区里的“声望”是靠ASP.NET AJAX积累起来的。但是现在ASP.NET AJAX似乎慢慢地淡出了人们的视线,那么我的投资失败了吗?完全没有,确切地说简直太成功了。ASP.NET AJAX覆盖了浏览器端的JavaScript开发,以及后台对ASP.NET WebForms页面模型的扩展,当然,还包括两者的交互。我一直认为UpdatePanel是前后端交互的经典之作,它通过在前端页面的hook,以及对后端WebForm模型输出的捕获,做到了非常透明的AJAX效果,只可惜由于项目分工,前端开发人员大都喜欢手写的纯客户端模型,因此UpdatePanel不太受人待见。我读过了ASP.NET AJAX的前台代码,由此全方面了解了JavaScript语言和许多前端开发的技术和技巧。我读过了ASP.NET AJAX的后端代码,由此我了解了一个JSON序列化框架可以如何实现出来,体会到了ASP.NET及其WebForms模型丰富灵活的内涵。从ASP.NET AJAX开始,我可以自豪地认为自己“精通”了ASP.NET,对它各方面的扩展可谓如鱼得水。例如,我可以轻易写出一个UpdatePanel上传文件,或是ASP.NET MVC中UpdatePanel的原型,虽不至于成为一个通用的组件及解决方案,但是对于自己项目本身已完全够用(我几乎没有纯“玩闹”而写的扩展,都是源自于项目本身)。后来微软出了ASP.NET MVC,我花两天时间扫视一遍它的源代码,也已经基本掌握了它的原理,使用方式,扩展也罢,一切都那么顺其自然。例如Rails是个优秀的Web框架,包含许多对实际生产非常有效率的特性,但是我在看了这些特性的使用方式之后,几乎都可以立即想象出它在ASP.NET里的实现方式,就例如表现层的片段缓存那样。

我一直强调,我并不了解所有的.NET相关的框架,但就我所了解的.NET技术而言,它们都有这样的特征:过渡性很好,自然地,有底蕴的发展。就拿C#来说,C# 1.0中创造了“委托”这个函数的一等公民类型,而在C# 2.0里引入了匿名方法,C# 3.0里强化了函数式编程的理念,成就了这一到目前为止最为经典的C#语言。C# 3.0中引入了Monadic的LINQ语法,几年下来基于LINQ发展了太多太多,如PDC 09中的LINQ to Observable,PDC 10上的LINQ to Azure。社区里如围绕NHiberante的贡献更是数不胜数。微软技术在我看来是十分领先的,这个领先并不一定指它在计算机科学上的创新和突破,而是指它对于这些经典理念与工业生产相结合方面的超前。可能它不如某些朋友心目中LISP那般博大精深,但可以说更直接地在让我在实际生产中体会到了经典的魅力。

这样的“领先”给我带来了许多乐趣,也让我慢慢难以从其他技术上感到“惊喜”。例如,一个Java程序员转到Python以后,会感觉生产力有了显著的提高,但就我来说,相当部分的生产力在C#中都有体现,我不会以为生产力低下是“静态语言”的关系。同样,我最近在关注iOS及Mac OS方面的应用程序开发,接触了一些Objective-C,发现它的block就相当于.NET中的委托,而在09年随Snow Leopard引入的block的支持语法早在C# 2.0中就由“匿名方法”特性实现了,更不说C# 3.0在这方面有更进一步的发展。同样,我阅读了GCD(Grand Central Dispatch)的文档之后,发现它和.NET 4.0中的TPL(Task Parallel Library,任务并行库)解决的是相同的问题,其实现思路也有许多相同之处,例如都是主要通过描述“任务”(如任务内容及依赖关系)来避免程序员直接使用线程,避免复杂的同步问题,并由系统来负责对任务的调度。有时在推特上,我时常可以看到一些Cocoa的开发者津津乐道于block及GCD对于并行开发所带来的诸多便利——于是我想,这个早已不该是新闻了嘛。我现在还知道未来C#还会在这方面有更多便利,它在Anders Hejlsberg的带领下再一次走到了领先的位置。

微软的技术大都容易入门,但这并不影响这些技术深厚的底蕴,您在学习时应该了解这种底蕴。例如,您在学习C#时,不应该只关注它的表面特性,而要知道“为什么Anders会设计这样的特性”。我认为,一个优秀的C#程序员应该对函数式编程有一定程度的理解。当您学习Reacive Framework时,应该顺便去了解一下响应式编程。同样,我看到社区里有一些关于TPL的文章,但认为它们还是没有把握到精髓。事实上这些精髓都不是秘密,微软对各种原理几乎都不做保留。例如微软免费提供了《Patterns for Parallel Programming》等资料,详细解释了并行编程中的诸多模式,以及它们在TPL(C#与VB)或是F#中的实现方式,这些都体现了微软在设计这些语言或类库时的思路。微软在构建这些技术的时候并非无中生有,都是事先设计好使用场景的。例如用Task应对任务并行,用PLINQ应对数据并行,毫不草率,堪称经典。此外,TPL的设计者Joe Duffy是业界大牛,他写过一本《Concurrent Programming on Windows》,描述了大量关于TPL的实现细节,例如无锁数据结构的编写方式,Work Stealing,如何改善局部性等等。您了解了这些内容以后,我想GCD对您来说可能也只是换套API而已,应该也不算是件难事儿。我一直认为,就算微软明天给外星人一锅端了,我也能很快进入其他技术领域,并很快达到较高级的程度。但是,如果您每次都只了解一些表面,自然很容易觉得天崩地裂。盲目追赶,那也只是恶性循环而已。

我一直强调“眼界”,微软技术不断为我打开新视野,这些技术的设计者都在各种场合提到其他技术对他们的影响。因此,学习了C#和F#,我对于Python,Ruby,Scala,Haskell都产生了浓厚的兴趣,我不会像许多Java程序员认为Java语言已经足够了,或是像许多Ruby程序员那样认为自己领先于其他程序员,我能时刻保持Keep Stupid,Keep Hungry。我时常不解一些技术人员在我看来莫名其妙的轻视(不是“敌视”)微软技术,我认为技术的大千世界何其美好。因此,即便我再是厌恶Java语言,也对JVM和其生态环境敬爱有加。于是,我通过《CLR via C#》对.NET运行时浅尝辄止之后,又通过《Oracle JRockit: The Definitive Guide》深入了解JVM的虚拟机世界。我看过了《Concurrent Programming on Windows》之后,又去阅读了作者推荐的《Java Concurrency in Practice》。

如果眼界没有打开,即便您学习的是业界“最先进”的技术,也可能产生偏差。例如时常看到Rails开发人员自豪地说,他们可以从Rails里学习RESTful。由于前段时间我刚巧看了《REST in Practice》一书,再结合我对Rails的了解,我实在没有感到这个Web框架在RESTful方法的独到之处。于是他们让我去看Rails 3.0里强大的Routing功能。我看后,才意识到其实他们似乎对于REST的理解有所偏差——REST的精髓在于由Hypermedia驱动的State Transfer,而形如“/article/20”这样的URL,以及映射一些HTTP方法等等,其实远非RESTful架构设计里的关键。RESTful只是要求“每个资源对于一个URI”,但并没有规定URI的形式,而且如果客户端直接了解服务器端的URL规格并直接访问,就与REST的“解耦”目标渐行渐远了。事实上,《RESTful in Pratice》一书甚至有建议对URL做些混淆。总体而言,Rails只是对REST架构中的一小部分提供了较好的支持而已,还远不能“从Rails学习REST”。昨天晚上我和REST专家李琨老师谈了我在这方面的理解,他基本赞同我的看法。我庆幸不已,要知道在此之前我还看过《RESTful .NET》一书,但我走向《RESTful in Practice》之后,才意识到前者给我带来了不少错误的观念。幸好,我并没有良好的自我感觉,也没有满足于现状。

如果您学习的是.NET,那么打开眼界的一个有效工具便是Mono。Mono及Miguel de Icaza已经不再拘泥于跨平台的.NET这个目标,而是努力在其之上实现大量的开源或商业产品。其中的典型便是MonoTouch和MonoDriod让.NET及C#进入iOS和Android平台广受喜爱,也已经有越来越多的成功案例。此外,Mono对于开发原生Mac OS应用程序的支持也步入了正轨。我作为一个.NET开发人员,从没有过如此兴奋的感觉。

如果您正确地学习了.NET技术,您会发现自己走上了一条良性发展的道路。从另一方面来讲,微软的技术固然多,但作为开发人员我们并不需要了解每项技术。微软在创建一门新的技术的时候,都会讲清楚这门技术所解决的问题是什么,如果与您无关,完全可以不去学习。例如.NET 2.0与3.5之间还有一个3.0,其中提供了WPF,WF和WCF三个框架。我可以坦率地讲,我对它们没有任何了解,但这丝毫不影响我自称是一个优秀.NET技术人员的自信。很多时候,如“疲于追赶”这种事情,我觉得太多程度上都是自寻烦恼了。这样“无中生有”的烦恼还有很多,例如微软给出F#以后,就有人说微软要抛弃C#了。您为什么就不能认为这是一种互补,或者说,给您多了一种选择呢?微软同时发展VB.NET和C#语言好多年了,您一直没有学习VB.NET的烦恼,为什么现在多了一个F#,您又动摇了呢?还有例如近日的Silverlight问题,前篇文章已有详述,不提。

许多人会持有这样的观念:整个技术领域分割为“微软”和“非微软”两部分,然后指责“微软”技术不如“非微软”来的丰富。在我看来这种分割方式是十分可笑的,怎么没有人将技术分为“Ruby”和“非Ruby”,然后指责“Ruby”技术不够丰富呢?此外,还有一些观点,认为ASP.NET应用程序靠memcached提高伸缩性是种失败,这也是同样的割裂逻辑。为什么PHP和Rails使用memcached就被视为正当手段呢?说起来,memcached是C语言写的,还真不关PHP和Rails什么事情呢。

而且,正如我之前说的,微软技术对我的重要价值之一,便是促进了我对各方面技术的浓厚兴趣。无论您是专攻哪种技术的开发人员,如果只是停留在自己这一亩三分地上,这都是不甚可取的。没有人限制微软系的技术人员从其他领域吸取经验,正如一个优秀Ruby程序员肯定也从Ruby外的技术领域吸收了大量精华。说实话,除了政治需要,我实在找不到将微软和开源社区(或是其他社区)对立起来的理由。事实上,我时常感觉,您即便工作于.NET的竞争性平台,学习.NET对于个人提高来说也是大有帮助的。

就写到这里吧。希望对您了解微软技术,以及如何学习微软技术能够有所帮助。

相关文章

Creative Commons License

本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名赵劼(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言

Add your comment

126 条回复

  1. 嗯,写的好
    58.58.38.*
    链接

    嗯,写的好 2010-11-04 12:50:15

    赵杰瑞的博文真的很有爆发力,漂亮。

  2. Benjamin
    220.248.45.*
    链接

    Benjamin 2010-11-04 13:01:17

    支持老赵,辛苦了,写了这么长的文章,不错呵呵。

    老赵的关注面相当的广实在让人佩服啊,不知道有何读书的经验可以分享,英文的书读起来可能没那么快,跨度长的话如果不作笔记前面的会忘记了,有时候读一遍下来好象记得的东西不多需要读第二遍。

  3. 我还是不懂
    202.108.19.*
    链接

    我还是不懂 2010-11-04 13:20:07

    谢谢赵姐夫,基础还是很重要,刚对委托和事件有点感触的菜鸟。。。

  4. 小木
    123.147.247.*
    链接

    小木 2010-11-04 13:27:01

    我部分支持老赵的观点,确实现在大家对微软技术存在一定的误解,但是现在大学教育的确有微软一家独大的趋势,这是不好的,我个人至少是反对用VC++6.0这种垃圾平台来教大家C++的,也是反对.NET技术进课堂,侵占基础课的学时的。

  5. iceboundrock
    183.0.27.*
    链接

    iceboundrock 2010-11-04 13:29:43

    赞同,而且其实也不能说微软刻意减少COM的应用场景,只不过是随着web的兴起,客户端应用市场本身在萎缩。

  6. Guancheng Chen
    129.16.196.*
    链接

    Guancheng Chen 2010-11-04 13:32:56

    Concurrent Programming on Windows好像没有影印版?

  7. 老赵
    admin
    链接

    老赵 2010-11-04 13:52:20

    @Guancheng Chen

    印象中没见过影印版,中文版没看过,但是同系列的一本《Practical Algorithms for Programmers》可谓翻译地不忍卒看……

  8. 老赵
    admin
    链接

    老赵 2010-11-04 13:53:38

    @小木

    我觉得,只要是学了操作系统肯定用的是Linux啊,否则怎么做各种实验呢。当时我们还要写个简单的文件系统,虚拟内存实现呢。

  9. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-04 15:23:32

    我发现我是keep stupid 但是没有很hungry

  10. 链接

    小城故事 2010-11-05 00:22:11

    我想,未来编程语言,将成为三层架构:面向底层的 C++和C, 面向应用程序的 .Net, 面向前端的 Python/Javascript等。

  11. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 00:41:13

    无论是语言还是基础类库,一切都良好过渡。您在C# 1.0里学到的东西,有哪些在C# 4.0里消失了么?您写的ASP.NET 2.0程序,直接无痛升级到ASP.NET 3.5

    1、因为老赵你自己基本只经历了.net时代,自然觉得似乎一切都没有消失。

    2、基本语法的变化自然是很少的,int i = 0自然从1.0到4.0都不会过时。但是很多人是从vb6时代过来的,人家积累了几十万行的代码到vb .net转换是很困难的。比如说vb6是支持数组任意下标的。

    这就是为什么一直到今天,office excel的基本二次开发工具还是VBA,而不是VSTA,因为用excel的是商务人士而不是程序员。

    微软只敢不断的抛弃程序员重来,但是对待商业客户必须谨慎。

    3、事实上即使在.net中变化也是很大的,比如WF4.0就推倒重来了,再比如说winform停止发展了,转向wpf了,而根据《纽约时报》的使用成果,又证明了wpf和silverlight是不同的,现在微软力推的显然是silverlight,显然,光.net客户端微软程序员就变换了三次,还不提以前的MFC,WTL和VB6。

    相反,如果你过去是使用Qt和GTK的,基本框架根本就没有什么变化。

    这就是为什么GTK积累出了Gnome,Qt积累出了KDE。

    那么.net积累出什么来了呢?

    您写的ASP.NET 2.0程序,直接无痛升级到ASP.NET 3.5——这是大众点评网的架构师在分享会上提到的,它的应用规模及复杂度不低于您的项目吧?

    那恐怕是因为大众点评师是用asp、php的页面模式来写程序吧,用webform怎么能无痛扩展?我记得大众点评网是用基于libevent的memcached来做缓存,而不是用asp .net更方便的写高伸缩的服务器程序吧?

    但是现在ASP.NET AJAX似乎慢慢地淡出了人们的视线,那么我的投资失败了吗?完全没有,确切地说简直太成功了。

    因为老赵你是在做学术研究,自然太成功了,做学术研究,研究什么能说不成功嘛?

    问题是支持你的人是用来做项目的,假如大众点评网也用了asp 。net ajax,结果又全部换掉,能说是成功和无缝升级吗?

    至于说rails不断升级不兼容,那也不是成功的,当初火了一把外,现在国内有几个人用?社区有多大?

  12. 不及格的程序员-八神
    119.119.208.*
    链接

    不及格的程序员-八神 2010-11-05 00:54:32

    书是好书,但是很多初学者都还是看不懂的,多数web程序员整天忙着html与js打交道,对于深层次的东西,都不是很了解. 不像有c++或是linux 嵌入式编程经历的人,对于底层了解的要更多,比如CLR/java的内存模型,与cpu指令排序等等. 很多参加工作的同学还停留在整天三国杀的环境中,根本没有时间看书,更不知道哪些是好书,即便拿到了好书还看不懂...

  13. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 01:11:24

    微软这些升级最大的毛病就是价值不大,比如说linq to sql之类的,微软的主推数据库访问方式变了N种,OpenClient,ODBC,DAO,RDO, ADO,ADO .net, linq, ADO Entity Framework,

    结果就是很多人学了N种访问方式,却写不好基本的SQL语句。

    虽然价值不大,却频繁升级。导致微软程序员很难积累,程序并不是靠思想就能继承的,更重要的代码,要是KDE每隔几年就换一种界面框架和数据访问方式,那能成功吗?

    所以说我反对的不是学习,而是要把学习用在刀刃上,其实开发语言这个东西,到了一定程度再去下大力气去语言扩展已经没有意义了。

    更重要的是算法,最强大的算法实验工具matlab,R之类在语言本身并没有什么出奇之处,相反还是更简单,连面向对象都很少用。

  14. 老赵
    admin
    链接

    老赵 2010-11-05 01:49:06

    @mcpssx

    还都是些老调调,猜测来猜测去。

    .NET快10年了,过渡性很好,说到底你就纠结于10年前的一些事情,然后列举10年前的一堆名词,说现在如何如何。这就是我说的FUD,文章里也写了,你估计又没看到。程序员就不是为商业客户服务了?说微软抛弃程序员对商业客户谨慎,太无理头了。

    WPF和Silverlight不是不同的,只是要用Silverlight不能做到WPF一样的事情,上次讨论了这么多,你还是选择性忽略。如果你不需要跨平台,自然继续用WPF,哪儿又被抛弃了?这儿不是讨论这个话题的地方,要讨论回到上次那个帖子吧,免得大家都看不到那些讨论,又被你的“事实”忽悠了。

    ASP.NET WebForms就不能无痛升级?我都升过好多项目了。你还是在搞笑地猜测,猜测对你来说是家常便饭了吧。大众点评用memcached就能说明ASP.NET不行,Rails和PHP用memcached就说明厉害了?说到底你还是在不断把技术割裂为“微软”和“非微软”,好像Rails、PHP和ASP.NET都用memcached好像就变成微软的失败了。

    所以我现在觉得这篇文章写的真是太好了,处处谈到了你的问题,太过瘾了。对了再提一句,我不是搞学术研究,我搞得是纯工业生产,纯做项目的,我想做研究都没机会。我是靠ASP.NET AJAX精通了整个ASP.NET框架,这个框架从诞生起就基本没有太大改变。你说学习要用在刀刃上,学ASP.NET AJAX我觉得是最最刀刃的,真是一通百通。

    至于Rails的问题,你去和Rails粉丝们说去,JavaEye有一大片。

  15. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 01:54:36

    一个Java程序员转到Python以后,会感觉生产力有了显著的提高,但就我来说,相当部分的生产力在C#中都有体现,我不会以为生产力低下是“静态语言”的关系。同样,我最近在关注iOS及Mac OS方面的应用程序开发,接触了一些Objective-C,发现它的block就相当于.NET中的委托,而在09年随Snow Leopard引入的block的支持语法早在C# 2.0中就由“匿名方法”特性实现了,更不说C# 3.0在这方面有更进一步的发展。

    事实上,生产力底下与语言本身关系没有那么大,生产力取决于库,而库往往又取决于语言的简单性。

    1、py的生产力高,很大程度就是库。人人都知道,py特点之一就是语法简单,所以导致很多科学家和工程师是使用它,创造了海量的函数库。

    同样,研究人工智能,模式识别,数据挖掘,科学计算的最好的语言是fortran和matlab,研究统计分析的s-plus/r都是简单的语言,简单的语言才导致了非专业程序员的参与,导致了这些行业的生产力的提高。

    2、obj-c的block应该来自smalltalk,不过语法扩展并不重要,很早以前,我用过的foxbase的一个方言clipper也有这个东西。

    事实上,最流行的语言都是简单语言,php,c,java,vb6,这不是偶然,因为只有简单的语言和库的开源,才能让更多人参与和交流,进一步促进该语言的库发展

  16. 老赵
    admin
    链接

    老赵 2010-11-05 02:00:40

    @mcpssx

    Python的优势,库只是一部分,语言也是相当重要的,不信你去问Python程序员,尤其是从Java等语言转过去的程序员怎么说。语法扩展重不重要的问题,以前讨论过太多了,不想再重复了。

    还有,说到底你还是没有把握住文章精髓啊,我强调了无数次微软技术的最大优势就是为我打开了眼界,所以我“不会像Java程序员认为Python那么nb”,不是想真讨论“Python为什么nb”或是“C#和Python到底谁nb”,明白不?就算是去用Python,我也认为C#程序员会比同等级数的Java程序员容易适应。

    因为你老是强调代码积累,我一直强调思想积累:即便你工作上用不了.NET,学习.NET也对你个人能力有很大帮助,但没了以前的代码就做不来事情了,我实在没法赞同这种方式。

  17. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 02:26:24

    @老赵

    .NET快10年了,过渡性很好,说到底你就纠结于10年前的一些事情,然后列举10年前的一堆名词,说现在如何如何。这就是我说的FUD,文章里也写了,你估计又没看到。程序员就不是为商业客户服务了?说微软抛弃程序员对商业客户谨慎,太无理头了。

    1、所以说10年我都没有在客户端看到什么成果,从1990年算起,总共也就20年,占了一半的时间,现在基本上没有什么成果。

    请你去看看各个360软件管理,金山软件管理,百度软件管理,我一个也没想起来哪个是.net的。Delphi的全盛时期不知道过去多久了,.net的客户端比基本上比delphi开发的都差的很远。

    2、微软对商业客户不谨慎,怎么废弃了VB6,却没有废弃VBA?

    WPF和Silverlight不是不同的,只是要用Silverlight不能做到WPF一样的事情,上次讨论了这么多,你还是选择性忽略。如果你不需要跨平台,自然继续用WPF,哪儿又被抛弃了?这儿不是讨论这个话题的地方,要讨论回到上次那个帖子吧,免得大家都看不到那些讨论,又被你的“事实”忽悠了。

    1、问题就是为什么要不同呢?正如大家看到的,flash/air,GTK,Qt都能跨平台兼容

    2、事实上,silverlight无法做到跨平台兼容,我记得pc端官方就支持windows,mac os吧?而mac os显然是有问题的,才导致纽约时报废弃了。

    ASP.NET WebForms就不能无痛升级?我都升过好多项目了。你还是在搞笑地猜测,猜测对你来说是家常便饭了吧。大众点评用memcached就能说明 ASP.NET不行,Rails和PHP用memcached就说明厉害了?说到底你还是在不断把技术割裂为“微软”和“非微软”,好像Rails、 PHP和ASP.NET都用memcached好像就变成微软的失败了。

    当然了,.net搞不定你才会去用c语言写的高伸缩服务器嘛,我前面跟你讨论的不就是谁的开发效率高嘛。到底是libevent的库,还是.net语法中加入了各种要素,事实说明,大众点评网没有选择自己用.net的高效的实现嘛。

    那么支持你的人又有几个达到了大众点评网的水平呢,那么你说的那几个语法又有什么现实意义呢?

    所以我现在觉得这篇文章写的真是太好了,处处谈到了你的问题,太过瘾了。对了再提一句,我不是搞学术研究,我搞得是纯工业生产,纯做项目的,我想做研究都没机会。我是靠ASP.NET AJAX精通了整个ASP.NET框架,这个框架从诞生起就基本没有太大改变。你说学习要用在刀刃上,学ASP.NET AJAX我觉得是最最刀刃的,真是一通百通。

    我没有看明白,你一开始是用了还是没有用asp.net ajax,那你现在是用了还是没用?如果一开始用了后来不用了,那怎么能说无缝升级呢?

    光一通百通有什么用?对项目来说库是拿来用的,不是用来学习了以后再写一套新框架的。

    至于Rails的问题,你去和Rails粉丝们说去,JavaEye有一大片。

    你知不知道以前有一堆chinaonrails的论坛?而今何在。javaeye的你看看多少人多少天发一个贴?我刚看了一下,今天ruby首页上还有9月11的贴。

  18. Firen
    58.37.142.*
    链接

    Firen 2010-11-05 02:35:32

    回复看的我累了。争论点不在同一点上真是很累人的事。

  19. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 02:52:27

    @老赵

    Python的优势,库只是一部分,语言也是相当重要的,不信你去问Python程序员,尤其是从Java等语言转过去的程序员怎么说。语法扩展重不重要的问题,以前讨论过太多了,不想再重复了。

    我说的正是语法简单是重要优势吗。网上到处都是20分钟学会py,把这作为优势的嘛。这就是py的哲学嘛。正是这种哲学,才使得很多py的库都是科学家和工程师贡献的嘛。

    还有,说到底你还是没有把握住文章精髓啊,我强调了无数次微软技术的最大优势就是为我打开了眼界,所以我“不会像Java程序员认为Python那么nb”,不是想真讨论“Python为什么nb”或是“C#和Python到底谁nb”,明白不?就算是去用Python,我也认为C#程序员会比同等级数的Java程序员容易适应。

    py的用户很多就是非专业程序员,没什么更不更的问题。如果导致你说的这种结果,那是py的失败。就好像学习basic,有什么学了C#就比java更会用的问题?

    因为你老是强调代码积累,我一直强调思想积累:即便你工作上用不了.NET,学习.NET也对你个人能力有很大帮助,但没了以前的代码就做不来事情了,我实在没法赞同这种方式。

    那gnome的开发者明天就能写出一个kde来?所以我说.net的网站总是充斥着各种写hello,world的方法,光写hello,world自然思想最重要。

    但是做项目,你今天用winform,明天用wpf,再后天用silverlight,那永远是黑熊掰玉米。所以现在360软件管理上没看到.net的软件,而光是cnblogs上在写《教你用一种.net的新技术》

  20. 老赵
    admin
    链接

    老赵 2010-11-05 03:00:08

    @mcpssx

    重复来重复去,猜测来猜测去,对于.NET基本事实都不承认或搞不清楚就来讨论,别人的回答选择性过滤,不奉陪了。

    话说几小时前的消息,F#编译器和核心库开源了。我觉得是好消息,正要去写篇新闻。您再批评一下F#吧,比如说它太复杂了没前途,当然您以前已经说过了。哦对了,我觉得C#比Python简单多了,真不知道你为什么说Python语言简单。难道你还真觉得20分钟就能学会Python?哈哈。

  21. jc
    207.46.55.*
    链接

    jc 2010-11-05 03:54:10

    博主不去做微软的公关太可惜了。 微软内部项目尚不敢说无缝升级,你是怎么做到的?而且你知道不知道,微软内部项目是不用你说的Asp.net Ajax或者其他的一些看似很酷技术的,那些只是卖点,这你都能拿出来吹。。。 内部项目反而用的是最简单,最返璞归真的方式,比如就是HTML+javascript+服务端代码

  22. Daniel
    75.101.218.*
    链接

    Daniel 2010-11-05 04:05:29

    貌似老赵特别强调了ruby语言,以及ruby程序员的一种特有的成就感,呵呵... 有机会我一定会尝试一下 .net 并相信一定会从中汲取到知识,乐趣。 愿所有人都抱有一颗公正平和的心态面对各种语言,技术,社区,而不是带着对m$固有偏见来看待 .net

  23. 老赵
    admin
    链接

    老赵 2010-11-05 04:14:04

    @jc

    为什么不能无缝升级?我当时在微软的时候,刚好是从1.0升级到2.0,这虽不能说是无缝升级(因为程序集版本变了),但是重新编译一遍也就可以了。后来2.0到3.5基本就是无痛无缝的,我自己都升过好多项目,刚才又把一个项目从3.5升到4.0了,呵呵。

    至于ASP.NET AJAX,我强调的一直它在设计实现上的先进性和学习价值,没说一定要用(要看清楚文章)。当然如果你用了,现在还是无缝升级的。我现在基本也用HTML + JavaScript + 服务器端代码(主要是ASP.NET MVC)。不用ASP.NET AJAX还是因为现在的前端大都太喜欢裸写JavaScript代码了,即便从项目结果和现状上看,许多地方用ASP.NET AJAX太方便了。

  24. jc
    207.46.55.*
    链接

    jc 2010-11-05 04:31:55

    不是裸写javascript代码的问题,而是updatepanel post了很多无用的东西导致性能问题,且传输内容不透明。 这个恰恰是使用asp.net ajax时不推荐使用的,推荐的是Post Method方式,用XML或json格式来做数据交互。 不知您说UpdatePanel是完美模型,体现在哪里? 您有大型项目中大量使用它的经历么?

    还有,在ASP.NET MVC 之前,微软内部项目多用XML+XSLT的方式呈现内容,后台asp.net高级功能用的并不多,还是相当于服务器端逻辑代码。

  25. 老赵
    admin
    链接

    老赵 2010-11-05 04:53:26

    @jc

    UpdatePanel的Post不会比普通的WebForms的Post多,因此我不认为会因为UpdatePanel导致什么性能问题。不用ASP.NET AJAX的还有一个原因,是因为很多前端开发人员不喜欢WebForms,而ViewState、GridView都可以少用或不用,最后说到底总是变成“id不好看”,但其实这种洁癖其实对于项目的意义是不大的,说是增加页面体积,又能增加多少?

    我没说过UpdatePanel是完美模型,我说的是“精妙”,在于前后端的截获,相互配合而实现的完全透明的方式。这个精妙也让我认识到ASP.NET框架设计得实在太好了,真是一通百通。我没有在大型项目中用过ASP.NET AJAX,但是中小型项目用的还是很多的。因为大型项目总有独立的前端人员,他们喜欢裸写JavaScript,没机会用。

    至于你说微软内部项目多用XML+XSLT的方式,我在微软参加的是Windows Live系列的产品,从项目之间实现交流,代码参考来看,根本没见过有项目用这种方式,不知道你说的是哪些项目?

  26. 小木
    123.147.247.*
    链接

    小木 2010-11-05 06:12:03

    从昨天开始看到老赵同学的帖子,今天又详细看了一下各路大神的回复,否定的意见很多,又是一次口水战。我是一名示范性软件学院的在校生,从我的经验出发,是极其不赞成本科阶段教授.NET技术的,就业的话,腾讯,华为、中兴还是要C,C++的居多,倒不是说语言和平台很重要,而是语言和平台会很大限制你的工作范围。做.NET,你接触算法的机会很少,熟悉底层的机会都没有了,倒是玩AJAX,LINQ,整有业务流程的机会很多(另外说一点我对把IL当成所谓.NET底层实现的做法非常反感,有那时间,应该好好琢磨汇编)。更为现实的题,.NET只适合中小规模的应用,老赵同学可以反驳这一点,举出一个你认为符合以下要求的大规模应用:高并发(比如淘宝和门户),高可用性(海关、税务、银行的核心业务系统),老赵同学不能否认一点,.NET的部署环境非常恶劣,WINDOWS Server,这就是致命的缺陷,这也从根本上限制了.NET的格局,面向中小型应用,故其发展思路就是变革中求生存,不断的推出新技术,提高开发效率,降低入行门槛最后降低人力成本。而IBM 的一代神器,System Z,出道四十载,连操作界面都不变,70岁的老技术员可以被IBM返聘到大学来介绍主机技术,微软哪一样技术能有如此境界,能给技术人员一样的安全感?、 最后总结一下,我对老赵同学的文章很欣赏,但是不能赞同您提出的微软技术稳定论。

  27. 老赵
    admin
    链接

    老赵 2010-11-05 06:36:24

    @小木

    否定的意见没有很多,也就一个大家熟知的著名人物吧,呵呵。要说起来,.NET的大型应用就太多了,你不知道前段时间蛮火的StackOverflow用5台机器,抗住Digg的500台服务器访问量的1/3事情吧。还有MySpace,PlentyOfFish,国内有大众点评,5173。例子太多太多,你说Windows Server不靠谱,只是不知道哪儿给你灌输的偏见而已。

    我说技术稳定,也是我自己亲身体会,自然你不能和IBM搞个大型机出来相比,也并不是只有它才能算得上稳定。还有你说学.NET限制你接触算法和底层,更加无厘头了,不了解底层怎么写出高效的TPL来?看看搞TPL的大牛,Joe Duffy,Igor Ostrovsky,哪一个不是底层刚刚滴?当然我也没说应该在本科学习.NET,本科我觉得就该学点不能直接使用的理论,就像我学的那些课程一样。

  28. 小木
    123.147.247.*
    链接

    小木 2010-11-05 07:13:47

    老赵同学,搞TPL的人熟悉底层是肯定的,但是我说的是使用.NET限制了对算法和底层的视野,请问哪一个.NET开发人员回去自己写一个TPL?.NET本质上是微软的一个产品,比如ASP.NET MVC,真的可以说是姗姗来迟了,说出来全世界的JAVA开发者都要笑了,.NET的开发人员,包括老赵同学你居然这么能忍,作为曾经的JAVA阵营的一个fans的我感到非常吃惊。微软技术,归根结底,创造技术的人聪明且强势,跟踪技术的人却越来越低门槛和弱势。我本人极其不喜欢.NET上的那个TPL,如果我要SSE指令优化怎么办,如果我要考虑使用内存池优怎么办,真正搞并行牛的是INTEL,硬件的底层才叫底层,INTEL的IPP,MKL,哪一样离得开底层锱铢必较的汇编级别的优化,CLI包括JVM还是一边凉快去吧。

  29. 小木
    123.147.247.*
    链接

    小木 2010-11-05 07:22:29

    还有你说的那几个所谓的大规模应用,特别是你举的那个例子,我惊讶你把5173都当成大规模应用了,服了服了,还有stackoverflow的神迹,我的确不知道,但人家讲的是性能优化,老赵同学别转移话题。我只想你正面回答一下,举出一个你认为符合以下要求的大规模应用:高并发(比如淘宝和TX.搜狐等门户网站),高可用性(海关、税务、银行的核心业务系统),你别再拿5173忽悠我就行了。

  30. 老赵
    admin
    链接

    老赵 2010-11-05 07:25:06

    @小木: 使用.NET限制了对算法和底层的视野,请问哪一个.NET开发人员回去自己写一个TPL?

    我文章里说了,要学习就要学习它的精髓,如果你说你用了.NET里简单的API,就不去关注各种东西了,那不要怪在.NET头上,我也没觉得我说错了。我从.NET那里掌握的也是创造技术的能力,而不仅仅是跟踪技术,建议你重新仔细地再理解一下我的文章。

    至于ASP.NET MVC,不要以为提到个MVC模式,就以为Rails,Django,ASP.NET MVC和Struct就是一个理念的东西了,Java领域目前在这方面只有个更晚出的Play!框架……还有,我看出来你是底层控,因此不喜欢.NET和JVM,觉得这些都学不到好东西,这又是另外一个更大的话题了,我就先不讨论了。

  31. 老赵
    admin
    链接

    老赵 2010-11-05 07:27:33

    @小木: 我只想你正面回答一下,举出一个你认为符合以下要求的大规模应用:高并发(比如淘宝和TX.搜狐等门户网站),高可用性(海关、税务、银行的核心业务系统)

    难道MySpace和纳斯达克MDDS真的还不够说明问题?

  32. 小木
    123.147.247.*
    链接

    小木 2010-11-05 07:40:04

    我不是底层控,窃以为老赵同学你不是.NET开发人员,也不是.NET程序员,而是.NET研究人员兼微软技术忠实追随者。按照你的学习思路,无论学什么都可以,因为都要学习精髓,都要深入底层,你可以去看ASP.NET AJAX的源代码,可以去学ASP.NET MVC的源码,老赵同学认为底层到哪里是极限,我同样可以说你没有用SSE/MMX等高级汇编质量优化过你的代码,没有修改裁剪过LINUX内核也叫不懂底层,不会学习,可不可以?建议老赵同学要关注一下普通的.NET开发人员的需求,人家因为silverlight的一点风吹草动寝食难安了,你出来说赶不上技术发展是自己有问题(也许我过度解读你的文章了),我觉得你这样说是无法赢得一线开发者的人心的。同时也建议老赵同学关注一下学术界对开发平台开发语言的需求,我做计算机视觉的,有时候也需要做产品原型,对.NET满如蜗牛的执行性能无法忍受。最后我也比较关注F#技术,你上次盛大创新院的视频给了我不少启发,在此感谢一次。

  33. 不及格的程序员-八神
    119.119.208.*
    链接

    不及格的程序员-八神 2010-11-05 08:08:19

    从小木的回复来看,它是一个是有深度的人,不知你身在何方?

  34. FMax
    59.37.15.*
    链接

    FMax 2010-11-05 08:34:46

    @小木

    对于学什么都学个皮毛的,无论是什么,我相信有点风吹草动都会寝食难安的吧。为什么关.net的事。

    @mcpssx: 生产力底下与语言本身关系没有那么大,生产力取决于库,而库往往又取决于语言的简单性

    那微软提升了语言的简单性,提供了更多方便的库,你又觉得是缺点 ?

  35. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 08:47:41

    @FMax

    你对语言的简单性有误解,比如说C++是C的超集,C++比C提供了更多的便利手段,但是并不是C++比C简单。

  36. 小木
    123.147.247.*
    链接

    小木 2010-11-05 10:55:26

    从小木的回复来看,它是一个是有深度的人,不知你身在何方?

    只在此山中,云深不知处

  37. driedbeef
    61.143.46.*
    链接

    driedbeef 2010-11-05 12:59:40

    @老赵

    UpdatePanel的Post不会比普通的WebForms的Post多,因此我不认为会因为UpdatePanel导致什么性能问题。不用ASP.NET AJAX的还有一个原因,是因为很多前端开发人员不喜欢WebForms,而ViewState、GridView都可以少用或不用,最后说到底总是变成“id不好看”,但其实这种洁癖其实对于项目的意义是不大的,说是增加页面体积,又能增加多少?

    忍不住说一下这个问题。 UpdatePanel的性能问题我是有体会的,jc的评论很公道。另外,WebForm下大量ViewState,大量PostBack确实会造成性能不佳,以复杂页面下大量数据和交互逻辑的GridView为甚。

    其实ASP.NET WebForm + Atlas的设计,如果放在网络带宽和延迟堪比内存,服务端处理能力无限强大的背景下,简直堪称完美的模型。

    可惜理想很丰满,现实很骨感。从个人经验来看,这种设计适合做小型Web Application,尤其是部署在企业内部局域网的信息系统。微软也意识到这个问题,所以MVC和jQuery成为.NET平台Web开发下新的力推对象。

  38. 老赵
    admin
    链接

    老赵 2010-11-05 13:39:20

    @driedbeef

    哎,我仔细阅读过UpdatePanel的代码,完全了解它的行为方式,对于我说出的话是很负责任的。

    如果程序性能有问题,不是UpdatePanel带来的,而是本身WebForms页面写法不佳,例如开放了过多的ViewState。这种情况下,即使不用UpdatePanel,性能也一样差。总结成一句话就是:UpdatePanel不会给页面带来额外开销,它的数据传输量只会比没用之前要少。

  39. driedbeef
    61.143.46.*
    链接

    driedbeef 2010-11-05 14:09:19

    @老赵

    单说UpdatePanel的原理和实现的话,它确实不会造成性能“更差”,这点您说的没错。

    我也研究过一些ASP.NET AJAX相关的实现,当时确实感觉挺震撼的。但实际使用时,在性能上确实不太好。

    当然,我也可以纠结一下每个页面和server控件的ViewState,仔细划分一下UpdatePanel,不过如果这么麻烦的话,还不如就直接用jQuery裸写javascript了,前后端的职责划分更加清晰,生成的代码更整洁,输出控制也更强。所以我觉得它的应用场合还是偏窄的,快速开发倒是非常好的。

  40. 小木
    123.147.247.*
    链接

    小木 2010-11-05 14:39:04

    老赵同学是否同意我转载您的这两篇关于微软技术的文章到我所在学院的内部WIKI系统上,虽然我不完全赞同您的观点,但是深感您对微软技术的态度也研究技术的方法是有值得今天的软件专业在校学生参考的。我之所以不喜欢.NET,是.net把学风给带坏了,大家满足于.NET完善的类库支持,强大的控件资源,忽视了算法和底层的内功,就事论事,我个人对您是敬仰的。

  41. Mshadow
    123.118.1.*
    链接

    Mshadow 2010-11-05 14:55:03

  42. 老赵
    admin
    链接

    老赵 2010-11-05 15:11:33

    @小木

    没问题,只要给出原文链接就行了。

  43. 老赵
    admin
    链接

    老赵 2010-11-05 15:16:52

    @Mshadow

    我认为这个案例并不能说明太多问题,事故具体是什么原因到现在也不知道。纳斯达克似乎跑的就好好的,伦敦证交所也一直好好的,这次不知道遇到了什么bug。就刚才一段时间新浪微博许多用户没法登录了,是因为Memcached出了点问题,任何技术都会出点问题,好技术还是好技术。

    文章里也说了,迁移至新平台不是因为交易速度从2.7毫秒变成了0.5毫秒,而是因为新平台的专家认为成本更低。换句话说,.NET平台也是够用的,而且经过优化也不一定不能实现更好的性能。成本方面,实在也是一个公说公有理,婆说婆有理的事情,所以你可以看到我从来不在文章里谈成本的问题,最多说起做ASP.NET时只要用Web Server 2008就行了。

    还有我今天忽然了解到,F#已经应用在某主要银行里了(虽然不知道详情),也在教育界有了许多发展,很不错,可以关注一下。

  44. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-05 16:05:11

    我最近就在给一个webform的企业应用做性能优化顾问。很多性能问题究其根本是不负责的见招拆招实现造成的。 一个按钮变灰都要用服务器事件,这是脑残。updatepanel强大,脑残亦不能医。

    顺便说现在jquery是asp.net4标准配备配合scriptmanager的webservice引用,webform早就不是依赖服务器事件的那个webform了。

  45. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-05 16:13:40

    @jc

    你比较有意思,内部项目用什么,你怎么知道的,我怎么不知道

  46. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-06 01:38:21

    .net在“纳斯达克似乎跑的就好好的,伦敦证交所也一直好好的”,但是老赵应该知道,人家的解决方案以前是每天晚上重启机器。

    事实上,.net的解决方案和lamp根本不在一个数量级上。就算.net可以做,怎么做?statckoverflow, 纳斯达克是怎么部署的?相反,lamp的方案满互联网都是。

  47. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-06 01:43:32

    去年9月,伦敦证卷交易所的基于微软.Net技术平台TradElect下线了一整天,令任何傻傻的竟会相信微软软件能用于关键性任务的人脸上无光。TradElect运行在HP ProLiant服务器上,操作系统是Windows Server 2003,TradElect软件本身是定制的C#/.NET程序,由微软和Accenture公司共同开发。

    下线事故发生之后,伦敦证卷交易所否认是TradElect过错,但消息人士称问题就是TradElect本身。在交易所新的CEO Xavier Rolet上任之后,他立即做出放弃TradElect的决定。


    近日,伦敦证券交易所宣布了一个新的基于Linux的交易系统创造了126微秒交易速度的世界纪录。

    从今年夏天开始,伦敦股票交易所(LSE)决定放弃使用基于微软.NET技术的交易平台TradElect,TradElect在2008年9月发生了下线了一整天的严重事故。伦敦股票交易所将迁移到基于GNU/Linux的MillenniumIT系统,这是自由软件的又一次胜利。

  48. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-06 02:09:08

    光说“能做”是不够的,关键还有你要花费多大精力去做。

    作为客户端上linux上也能做windows上的事情,作为服务器windows也能做linux做的事情,但是难度是不一样。

    作为服务端,linux的方案更容易学习掌握,架构方案漫天飞。相反,光说windows能做是不够的,关键应该怎么做?老赵说了n次的stackoverflow,微软网站了,那具体架构是什么?实施过程中有疑问了能搜索到答案吗?

  49. 老赵
    admin
    链接

    老赵 2010-11-06 03:59:03

    @mcpssx

    我汗死了,这方面架构的内容太多了,不知道多少人写过分享过,你居然说没有,又来信口开河随意胡诌了。这次我还真就不搜给你看了,随你爱怎么说怎么说。实在是莫名其妙到了极致。

    至于伦敦证交所的事故,你居然不相信官方说法,而去相信匿名的“消息人士”,这种新闻都拿来当根据,我已经强烈无语了。而且一搜,果然是Solidot的,经典口吻啊。还有,能不能告诉我,你是如何知道他们是每天晚上重启的?

    我之前说过很多次,我相信你是高级技术人员,但是,你太给技术人员丢份了。我想过多少次不搭理你的胡说八道,但每次看你变本加厉,每次都忍不住,也真是没用。

  50. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-06 05:56:34

    @老赵

    所谓windows架构内容太多了,不知道从何说起?我看你说来说去就是stack overflow,本来例子都没几个,又哪来的公开的太多了?

    伦敦证交所是什么地方,你觉得人家就为了省钱要把运行了几年的.net全部换成linux吗?无论它是不是solidot的,总之,伦敦证交所的TradElect下线一整天是事实吧?伦敦证交所换成了linux是事实吗?

    难道说,飞信,纽约时报,evernote和伦敦证交所的技术人员都不如中国的。net程序员爱学习或者水平太低?

    事实上此新闻solidot报道了,并不代表就是solidot起源。

    请看http://blogs.computerworld.com/london_stock_exchange_to_abandon_failed_windows_platform?page=10

    TradElect runs on HP ProLiant servers running, in turn, Windows Server 2003. The TradElect software itself is a custom blend of C# and .NET programs, which was created by Microsoft and Accenture, the global consulting firm. On the back-end, it relied on Microsoft SQL Server 2000. Its goal was to maintain sub-ten millisecond response times, real-time system speeds, for stock trades.

    It never, ever came close to achieving these performance goals. Worse still, the LSE's competition, such as its main rival Chi-X with its MarketPrizm trading platform software, was able to deliver that level of performance and in general it was running rings about TradElect. Three guesses what MarketPrizm runs on and the first two don't count. The answer is Linux.

    而nasdaq的交易系统并不基于windows,该文跟贴中指出

    Nasdaq uses a Windows system for spreading market data, information about trades, information dissemination system.

    But the actual trading engine is done on Linux. So, Nasdaq does not run it's trading engine on Windows. It is only a support function that uses Windows.

    再请看这里

    A fortnight ago, the LSE announced that its trades were being conducted at an average of 126 microseconds – a figure largely accepted in the industry as a record for live use.

    But only five days after its announcement the LSE faced a potential contest when the New York-based *NASDAQ exchange, whose Genium INET platform runs on Linux in a reported C++ *environment, said it had delivered an average 97 microsecond latency during a week in mid-October.

    nasdaq的交易系统代号为genium,是在linux上用c++开发的。

    总之,伦敦证交所和nasdaq并不能作为证明windows系统关键业务能力的证据。

  51. kw2010
    216.94.84.*
    链接

    kw2010 2010-11-06 13:44:48

    @mcpssx: 而nasdaq的交易系统并不基于windows,该文跟贴中指出,Nasdaq uses a Windows system for spreading market data, information about trades, information dissemination system.

    看了一下,“该文跟贴”出自:Submitted by Anonymous on July 17, 2009 - 6:27 A.M.

    这样也行?

  52. 老赵
    admin
    链接

    老赵 2010-11-06 14:37:25

    @mcpssx

    我不会再陪你继续猜测下去了,solidot本就算不上一个媒体,只是个轶闻站而已,一点可信媒体的特征都没有,更何况是出了名的反微软。你情愿相信一个匿名的否定微软的结论,也不愿意相信一个微软和纽约证交所这两个“受大量群众监督”的官方机构对微软的肯定的说法,这还有什么讨论的基础么。

    等你什么时候停止猜测,找出切实的根据,不要用“知情人士”或是“匿名人士”透露的消息,确定是技术方面的问题,而不是政治或其他非技术方面的原因,再来否定微软技术吧。

  53. 链接

    Ivony 2010-11-06 14:48:19

    不用ASP.NET AJAX的还有一个原因,是因为很多前端开发人员不喜欢WebForms,而ViewState、GridView都可以少用或不用,最后说到底总是变成“id不好看”,但其实这种洁癖其实对于项目的意义是不大的,说是增加页面体积,又能增加多少?

    id不好看当然是借口来的,关于这个WebForm为什么不受欢迎我有撰文。。。当然是一家之言。

    当然有一些不是借口的东西,例如id和name不可控,这在前端与服务器控件交互的话就很麻烦,至于后端,由于name不可控,所以大体上我们只能通过控件去获取提交的值。而这些不可控name的控件又很大一部分是生成出来的,这里搞得问题很麻烦。当然PostBack使得呈现逻辑和处理逻辑有点纠缠不清也是一大原因,尽管可以通过事件来区隔到不同代码区域,但要掌握页面生存周期,正确的处理使得呈现改变的事件,还是比较麻烦的。至于ViewState,那么对于不需要保持状态的页面而言就是累赘,那么微软的脚本和AJAX又和ServerForm捆绑在一起,就让人有不爽的感觉了(显然这并非必要)。

    不管怎样了,WebForm的控件模型并非那么不堪,其体系仍有许多可圈可点之处,像ASP.NET MVC那样全盘否定我是很不看好的。

  54. mcpssx
    58.19.85.*
    链接

    mcpssx 2010-11-06 14:50:48

    @kw2010

    请看下面一段文章,nasdaq的官方报道,nasdaq的交易系统是Genium INET platform ,

    http://ir.nasdaq.com/releasedetail.cfm?ReleaseID=476024

    NASDAQ OMX to Deliver World's Fastest Trading Platform to Singapore Exchange

    The NASDAQ OMX Group, Inc. (Nasdaq:NDAQ) today announced that it will deliver an ultra low latency trading platform to Singapore Exchange (SGX). The new trading platform, named SGX Reach, will be powered by NASDAQ OMX's Genium INET, the fastest trading technology in the world. SGX's migration to the new trading platform will commence with cash equities in 2011.

    而genium是基于linux和C++的,并不是微软平台

    @老赵

    我的引文来自computerworld, 不是soliddot,就算你认为不是.net的问题,总之伦敦交易所现在使用的并不是微软的系统,而是linux。总之

    1、伦敦交易所发生了一次一天的交易事故

    2、之后论坛交易所更换了与微软联合开发的交易系统,转到了linux系统。

    It never, ever came close to achieving these performance goals. Worse still, the LSE's competition, such as its main rival Chi-X with its MarketPrizm trading platform software, was able to deliver that level of performance and in general it was running rings about TradElect.

    其中还有比较了伦敦交易所的竞争对手chi-x使用的linux交易系统。

    3、nasdaq的交易系统Genium 是基于linux的

    4,不知道为什么你又提出了纽约交易所?纽约交易所,芝加哥期货交易所同样是linxu架构的。

  55. 老赵
    admin
    链接

    老赵 2010-11-06 15:06:36

    @mcpssx

    唉,我之前引用的纳斯达克案例,链接里从没说是股票交易系统,而是指它的Market Data Dissemination System

    MDDS is a critical system for NASDAQ, as it keeps the official daily record of all trades. It must be fast and highly available because data is constantly inserted. NASDAQ’s MDDS solution receives about 8 million new rows of data per day, and gives users a view into risk management, trade summary, broker clearing, and NASDAQ market calendar information.

    MDDS handles 5,000 transactions per second plus a large volume of Web queries that come from NASDAQ’s WebLinkACT 2.0, a browser-based application that electronically facilitates the post-execution steps of price and volume reporting, comparison, and clearing of trades.

    “纽约”什么的是我笔误。

  56. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-07 02:41:12

    这正是那篇文章跟帖中指出的 mdds是个市场数据分发系统

    Nasdaq uses a Windows system for spreading market data, information about trades, information dissemination system.

    But the actual trading engine is done on Linux. So, Nasdaq does not run it's trading engine on Windows. It is only a support function that uses Windows.

    微软也说了,NASDAQ的内部开发团队使用SQL Server 2005数据库创建了它的市场数据分发系统(MDDS)。Windows Server 2003 和SQL Server 2005都是Windows Server System集成服务器软件的一部分。MDDS从NASDAQ的交易报表系统接收直接的输入,并且收集数据,把它存储在SQL Server 2005中。接着市场参与者便可以对其进行实时查询,使用者包括使用NASDAQ工作站的,使用基于Web工具连接到NASDAQ交易系统的。

    说白了,在金融界就是一个数据查询平台,就是把主机系统的交易数据拷贝到另一个前置系统中,供大家查询使用。

  57. 老赵
    admin
    链接

    老赵 2010-11-07 05:29:20

    @mcpssx

    无所谓它是干什么,只要能够达到critical system的要求就行了。之前MDDS使用基于Unix的大型机,现在改造成了Windows Server和SQL Server 2005,接受交易系统的实时信息,汇总,并提供外部查询。

    话说我发现,现在这个站点是Case Study的汇总站,感兴趣的人也可以转转。

  58. llj098
    96.44.135.*
    链接

    llj098 2010-11-07 07:40:10

    .NET作客户端就是很悲剧。飞信和Evernote都努力的尝试,但是最终放弃了.NET,重新回到了 Native Code上面。据Evetnote官方说法,貌似这问题不好解决,甚至是无解。

    还有别在拿Stackoverflow和Digg之间服务器数量的事说事了,没啥意义。具体的应用类型,具体承受的压力,服务器配置,等等因素,都是只是双方内部人员才能了解。

    .NET成熟大规模的应用就是少,和整体业界数量相比,少的可怜。

    PS:伦敦交易所是因为系统运营成本转型吧,飞信整个系统也要转型,也是因为运营成本。。。

  59. 老赵
    admin
    链接

    老赵 2010-11-07 08:08:38

    @llj098

    Evernote其实不说还好,它一说的太具体,已经有很多人指出很多方面不是问题了。

    我没拿StackOverflow和Digg说事,我从来不会说LAMP做不好网站,我只是用来证明.NET要做好完全没有问题。我当时看到这个消息时就说,StackOverflow做得很好,但Digg明显也有些问题,这个资源投入和压力相差太远了。我只要看到一定数量的成功案例,就确定它能做好。我也不会做些恶意推断,因为我不搞FUD,也没有双重标准。

    当然,像你的说法:“具体的应用类型,具体承受的压力,服务器配置,等等因素,都是只是双方内部人员才能了解”,这个其实许多人在反对微软的时候,也是可以考虑一下的。

    还有就是,飞信整个系统在转型吗?我只知道客户端方面的问题,而服务器端一直是.NET的。

  60. llj098
    111.193.204.*
    链接

    llj098 2010-11-07 08:36:50

    @老赵

    尽管外人怎么说都好,但的确是没有成熟的做的很好的.NET客户端应用阿。。

    另,飞信确实在转

  61. 链接

    zantesu 2010-11-07 09:16:16

    很烦总是拿.net客户端来说事的人.术业有专攻好吧,打开xx软件管家,有java程序吗?有python程序吗?有ruby做的客户端吗? 前阵子装了个openoffice,结果还不是一样慢吞吞很难用. 都说.net做客户端不行,为什么我机器上就这么多.net写的东西?paint.net,Expresso,甚至WPF写的Expression和QQ概念版?还没算上VS什么的 历史,以及性能总是看的很重这两个原因,现在流行的桌面软件基本都是原生程序的天下,这不是.net不行的原因,麻烦分辨清楚!QQ什么的整天扫硬盘,用概念版多好,除了启动慢点,广告和垃圾少点,已经非常好用了. 公司内部忽然有个需求,需要个什么什么的工具.我用.net几个小时就能弄出来一个完整版,要界面有界面要性能有性能,可配置可扩展,该有的都有.你用C++做,能办到么?

  62. tshao
    210.13.83.*
    链接

    tshao 2010-11-07 11:10:01

    随便说一下jc说的两点:

    1,微软内部项目是不用你说的Asp.net Ajax或者其他的一些看似很酷技术的

    这个绝对化了,许多项目就是经过内部的使用,经受过了一定的检验,才推给市场的。有部分项目未使用新技术的原因,其实来自于学习成本,即使是微软员工也不是每个都能立即上手最新技术的。Jeffrey Richter也经常会挑各个微软产品组的毛病,不是技术不好,是使用者跟不上。

    2,在ASP.NET MVC 之前,微软内部项目多用XML+XSLT的方式呈现内容

    有很多msn(非windows live)的实现都是依照这种框架的,那是因为web forms对前台的控制太不好掌握了,而那些网站对于前台的要求非常高。到mvc出现后,也确实有很多项目开始转向它。不过除了msn部门,还未听说其它的团队采取了这种开发方式。而且写xslt的生产效率太低,开发、调试都极不便,.net对其的支持也不给力。

  63. llj098
    111.193.204.*
    链接

    llj098 2010-11-07 13:02:09

    @zantesu

    确实,术业有专攻。但是.NET没有几个成功的客户端,这是事实。

    在linux上面,Python做的客户端很多,而且很不错。而且,搞不懂的是,基于Mono的Banshee,Gnome Do,Docky,Tomboy 性能都很好,用起来都非常爽,反而先windows平台上,没啥这么出彩的程序。。。。

  64. 老赵
    admin
    链接

    老赵 2010-11-07 13:38:20

    @tshao

    话说我想起来,ASP.NET AJAX出来前几个月,我还在微软,的确是在微软内部推动和ASP.NET AJAX很像的东西,当时还叫做Atlas。

    还有,无论如何用xslt做界面总是很奇怪的事情。即便是MVC框架,它使用的还是WebForm做表现层,如果觉得WebForm不好控制,那么就不用它的控件驱动,用写MVC表现层的方式就行了,完全没有问题。

  65. 小言
    211.94.36.*
    链接

    小言 2010-11-08 03:12:31

    仔细的看了各位的评论, 大多都是与老赵持反对意见的.....老赵受累了....

  66. Mikeshi
    112.64.127.*
    链接

    Mikeshi 2010-11-08 03:24:18

    F#终于要开源了,老赵又可以写文章了

  67. 老赵
    admin
    链接

    老赵 2010-11-08 04:09:29

    @小言

    还好,只是同样的人,反复用同样的说法……

  68. zhuisha
    221.216.161.*
    链接

    zhuisha 2010-11-08 05:06:05

    老赵 C#与Visual Basic的未来(下) 呢? 能不能先出完这个系列再开下个话题啊.等待也很不爽的...

  69. 链接

    陈梓瀚(vczh) 2010-11-08 06:45:43

    话说回来,学了C#的人底层的知识就真的那么不堪么?很多学了C++不也是半吊子,啥都搞不定。MD这些都是@mcpssx的幻想罢了。M$也从来没跟疼讯一样要求你们搞定C#之后就不能学其他东西了,都不知道是什么逻辑在说.net限制了个人的发展云云。pascal不也完蛋了么,难道投资在pascal那些人就没戏了?换个语言很难吗?反正【大部分】项目不可能永远维护下去的,迟早得重写,或者就死掉了。

  70. 链接

    陈梓瀚(vczh) 2010-11-08 06:46:36

    话说老赵教我一下,怎么回复……难道那个@XXX是我要自己打的?

  71. 老赵
    admin
    链接

    老赵 2010-11-08 06:54:19

    @zhuisha

    剩下半段不是很关键,于是就懒掉了……

  72. 老赵
    admin
    链接

    老赵 2010-11-08 06:54:47

    @陈梓瀚(vczh)

    对的,要自己打……

  73. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-08 06:55:56

    @陈梓瀚(vczh)

    1、delphi之所以完蛋的根本原因就是微软,和borland同时期的freepascal、QT,GTK+都活的好好的。

    boland的公司技术能力并不是比开发Qt的那个挪威公司差,只是跟错了微软平台而已。

    各位的学习能力能超过borland吗?

    2、决定社区学习能力的还有社区文化。

    很简单的道理,国内的delphi社区贡献的源代码和项目就超过了.net,比如说cnpack, delphi spring, DGL等等,再比如java的hibernate的翻译就是原来delphi社区的人做的。

    而国内.net,我多年只看到各种hello,world的教程。

  74. 链接

    陈梓瀚(vczh) 2010-11-08 08:58:20

    @mcpssx

    那你这种说法跟学生学不好怨老师有什么区别?我从其他社区上学到的大量知识照样可以用在C#上,怎么别人就不行呢?这显然是没有道理的。

  75. 链接

    陈梓瀚(vczh) 2010-11-08 08:59:34

    @mcpssx

    话说你没有回答我的问题哈。我对于delphi怎么死不关心(它还活着,事实上),我只之说我投资在delphi上学的那么多东西,换成C++和C#不是照样就用上了,怎么就浪费了呢?你自己的知识是不会浪费的。至于说历史遗留代码,那是公司的,不是你的。你不用操心。你不写自然还有别人写。

  76. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-08 09:34:35

    @陈梓瀚(vczh)

    好吧,我就不谈WCF,WF了,那请问如果你做web页面开发从asp,Asp.net WebForm, Asp .net MVC中间转过几次,学习了几次?如果你说做客户端开发的,请问你一路学会了WinForm,WPF和silverlight没有?你对这些掌握深度有多少?

    我只之说我投资在delphi上学的那么多东西,换成C++和C#不是照样就用上了,怎么就浪费了呢?

    那微软开发office的怎么不都换到C#上呢?opera公司不是坚持Qt每隔几年换一次能写出opera吗?

    在市面上那么多软件,请问你见到哪几个是更换了开发语言的?

    作为一个研究人员,自然换了哪个都无所谓。研究和实际项目开发是两会事情。

  77. 老赵
    admin
    链接

    老赵 2010-11-08 09:35:50

    @陈梓瀚(vczh): 我从其他社区上学到的大量知识照样可以用在C#上,怎么别人就不行呢?

    不能以你自己来衡量别人,你不算是.NET开发人员,你算是个技术人员,但喜欢.NET,用.NET而已。如果你学的不是.NET,肯定会比现在更好(虽然无法证明)。一个.NET程序员,就应该是除了微软的东西什么都不知道,什么都不会。因此,.NET是垃圾的,微软技术也是很垃圾的。

    以上是一种“标准解答”,我见过许多次了……此外,类似的对话方式可以运用在很多地方,例如你提出的微软技术社区的成果和贡献云云,都有理由“不承认”,“算不上”。微软做的好的地方,都是没有意义的,因为微软有其他做的不好的地方。就算做得好,它也是微软挖来的人做的。总之,微软和微软技术社区是非常垃圾的。

    理由么,终究是找得出来的……

  78. 老赵
    admin
    链接

    老赵 2010-11-08 09:39:23

    @陈梓瀚(vczh)

    我觉得吧,Delphi的杯具在于快速开发比不上.NET,原生开发已经有C++了,Delphi正好处在个不上不下的地方,于是被边缘化了。就算Delphi活在Linux平台上,照样被C++和Java围攻至趴下……

  79. kw2010
    206.210.105.*
    链接

    kw2010 2010-11-08 13:04:20

    @mcpssx: 如果你说做客户端开发的,请问你一路学会了WinForm,WPF和silverlight没有?你对这些掌握深度有多少?那微软开发office的怎么不都换到C#上呢?opera公司不是坚持Qt每隔几年换一次能写出opera吗?

    个人经验:从 .NET beta 1 开始,大部分时间用 winform 开发 smart client,最近一年多开始用 SL 4.0 打造产品下一代。一路上在学,谈不上学会,掌握谈不上深度,主要力求满足用户需求。也确实需要解决 memory leaking, gdi+ issue。做技术么。

    重点是 team 绝大多数时候知道什么情况下该怎么用某项技术解决特定问题。

    更重点的是,力求满足用户需求 -- 这也是微软为什么(现在)没有(完全)使用 .NET 重写 office。至于微软那些产品完全或部分使用 .NET,很容易 google 到吧(注意我没有说 bing 到)。

    多说无益。不再回帖。一是跑题,二是就算证明微软平台不能胜任某些特定场合(抛开背后大量政治因素),又怎样?和楼主的文章关系不大。已然有几个文章跟贴一再讨论这些讨论了十几年的问题了。

  80. mcpssx
    113.57.84.*
    链接

    mcpssx 2010-11-08 14:27:25

    @陈梓瀚(vczh),@老赵

    我觉得吧,Delphi的杯具在于快速开发比不上.NET,原生开发已经有C++了,Delphi正好处在个不上不下的地方,于是被边缘化了。就算Delphi活在Linux平台上,照样被C++和Java围攻至趴下……

    悲剧在于今天无论在控件数量还是实际的客户端应用程序上,.net仍然远远比不上已经没落了多年的delphi,如果加上C++Builder,.net就更悲剧了。

    比如wps的界面就是delphi的,你用spy++一看就知道了,再比如说控件,国内.net的控件网基本没有,而delphi没落了这么多年了,还有一大堆控件网站,而且delphi的大部分都有源代码,而.net的基本没有源代码。

    delphi边缘化的原因只有一个,微软重新开了新平台,总是跟随微软的borland公司就倒下了。

    borland公司的技术实力比MySQL(vs Interbase)差?比开发Qt的Trolltech差?

    都不差,问题就是跟了微软平台。

  81. Duron800
    207.46.92.*
    链接

    Duron800 2010-11-09 02:44:43

    @老赵: 剩下半段不是很关键,于是就懒掉了……

    烂尾是不好的。

  82. 链接

    陈梓瀚(vczh) 2010-11-09 03:19:50

    @mcpssx

    毛啊,金山公开说他们的界面是自己开发的一个“KFC”库,鬼采用delphi写WPS呢。话说回来,我(客户端)至少能用WinForm做IDE的intellisense哈(虽然技术上的重点显然不在GUI上),至少证明我能按照自己的需求去改造或者添加新控件了吧。

    话说回来,有多少个项目的生命比语言还长的?你不要拿著名的opera说事,那是活下来的了。就像创业一样99%的不还是死掉了。你把那些算进去,你就会觉得TMD一个语言就算他能有个5年也够你写大部分的东西了。反正你连.net和其他的东西一起学不就行了,类库学起来都是很简单的。你也知道原理难是吧,但是怎么我学.net就能搞得定原理别人就不行呢,那还不是因为学习不够努力啊。何必分门别类呢。微软的平台就咋了,不也比一大堆的软件长命。

  83. 链接

    陈梓瀚(vczh) 2010-11-09 03:21:12

    @mcpssx

    而且看你现在电脑里面的软件,显然原声GUI也没完蛋哈。Delphi显然不是因为当年在Delphi Studio里面添加了C#才挂掉的,那个公司本来就快完蛋了,人都走光了,做什么都会死的。

  84. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 04:39:00

    @陈梓瀚(vczh) 2010-11-09 11:19:50

    毛啊,金山公开说他们的界面是自己开发的一个“KFC”库,鬼采用delphi写WPS呢。

    用spy++一看就知道了,wps菜单就是TTbxToolBar控件,或者直接用资源工具看。wps是delphi和C++合用的。

    话说回来,我(客户端)至少能用WinForm做IDE的intellisense哈(虽然技术上的重点显然不在GUI上),至少证明我能按照自己的需求去改造或者添加新控件了吧。

    是啊,所以说你也只会一种啊,微软四种mfc, winform, wpf, silverlight你都学会了?现在还在用winform,是不是说明不爱学习?

    话说回来,有多少个项目的生命比语言还长的?你不要拿著名的opera说事,那是活下来的了。就像创业一样99%的不还是死掉了。你把那些算进去,你就会觉得TMD一个语言就算他能有个5年也够你写大部分的东西了。

    是啊,既然够用了,那更加不用跟着微软跑了。

    反正你连.net和其他的东西一起学不就行了,类库学起来都是很简单的。你也知道原理难是吧,但是怎么我学.net就能搞得定原理别人就不行呢,那还不是因为学习不够努力啊。何必分门别类呢。微软的平台就咋了,不也比一大堆的软件长命。

    你说反了,其实语言是很简单的,一个语言语法再复杂也很难超过C++。一个星期可以学习一种语言,但掌握wcf,wf,winform,wpf, silverlight, QT, GTK+, MFC任何一种框架的学习时间都要超过学习一个语言语法。

    比如说你,你依然在使用winform嘛。

  85. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 04:46:00

    @陈梓瀚(vczh)

    老赵说的是 "微软的技术的确很多,但至少在.NET领域过渡性做的非常好,我没有任何疲惫之感。"

    把你那个intellisense的ide过渡到wpf看看,看看是不是过渡的非常好,没有任何疲惫之感。

    你和老赵都是.net研究人员,自然毫无疲惫之感,可以拿着微软宣布不再维护升级的winform继续玩,反正代码都是实验性的和给开发人员自己用的,那面对客户的开发人员能这么想吗?

  86. 老赵
    admin
    链接

    老赵 2010-11-09 08:26:29

    @陈梓瀚(vczh)

    微软真倒霉,用WPF重写VS2010的编辑器么,说WinForm就被抛弃了。如果不重写么,就会被说“你看看微软自己都不用”。但如果微软不变化呢,自然还是说微软技术多么多么差,又没创新什么的。其实微软无论怎么做,总归可以从某个角度可以找到缺点,就看愿不愿意找了。Microsoft Hater挑微软刺永远不留情面,这时候哪关心什么“权衡”啊,“利弊”啊,长处啊,专挑坏处说就行了,实在很轻松。

    所以我觉得苹果很厉害。一个之前苹果的高人现在来创新院了,上周末在饭桌上说,苹果经常会淘汰或颠覆自己的东西,的确一开始会觉得不舒服,但是用来两年回头看看的确是种进步。但厉害的就是,就算一开始觉得不方便,但就是有大批果粉追捧啊,愿意花钱买它的东西。

    还是那个道理,要挑刺,总归找得到理由的。你和我觉得某些方面没问题,还是因为我们都是.NET研究人员,不属于真正的开发人员。

  87. 链接

    陈梓瀚(vczh) 2010-11-09 08:40:09

    @mcpssx

    那你说从symbian到android是不是也是不顾及开发人员的感受啊?我们知道世界上曾经有很多代码上的投资在symbian的,你也得出相同的结论吗?

  88. 链接

    陈梓瀚(vczh) 2010-11-09 08:43:39

    @mcpssx

    而且你也犯了一个逻辑上的错误哈,我使用WinForm难道是因为我不懂WPF吗?这显然是我的个人爱好哈。那你从哪里得出我不是MFC WINFORM WPF SILVERLIGHT都会的结论呢?当然抛开这个不说了,我也学你断章取义挑刺哈,你说“一个语言语法再复杂也很难超过C++。一个星期可以学习一种语言”,是不是再说一个星期就可以搞定C++捏,嘿嘿。

    当然你又犯了一个错误,就是在转移话题了。我说的是,我在WinForm(或X)上的投资,会随着WinForm(或X)的消失而消失吗?显然你一直都没有正面回答我的问题。难道我学习C++学到手的知识,会在C++死掉的那一天就没价值了?我还是想要正面回答哈,你不要来跟我扯我会什么不会什么。

  89. 链接

    陈梓瀚(vczh) 2010-11-09 08:45:48

    @老赵

    @mcpssx就是一个典型的执着的微软黑啊……

  90. 老赵
    admin
    链接

    老赵 2010-11-09 09:26:34

    @mcpssx: 那你说从symbian到android是不是也是不顾及开发人员的感受啊?我们知道世界上曾经有很多代码上的投资在symbian的,你也得出相同的结论吗?

    话说,MonoTouch真的很好用啊,编译db4o直接用。能够通杀iOS,Android,WP7的也就只有.NET了,这“积累”真是无与伦比啊……

  91. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 09:32:30

    @老赵

    1. 果粉其实是针对最终用户而言,是用的,而不是搞开发的。
    2. 对苹果的开发人员来说,现在热闹的参加开发的其实是只经过了objective-c一代,还没有体会到不断技术换语言的经历。

    而obj-c其实是从乔布斯离开苹果后的nextstep一路来的,nextstep第一版发布于1989年,到现在obj-c语法变化并不大。何况obj-c本身就是兼容c的。

    @陈梓瀚(vczh)

    那你说从symbian到android是不是也是不顾及开发人员的感受啊?我们知道世界上曾经有很多代码上的投资在symbian的,你也得出相同的结论吗?

    你难道不认为失败吗?

    而且你也犯了一个逻辑上的错误哈,我使用WinForm难道是因为我不懂WPF吗?这显然是我的个人爱好哈。那你从哪里得出我不是MFC WINFORM WPF SILVERLIGHT都会的结论呢?

    对啊,所以说你是.net研究人员嘛,自然不在乎了。人家公司开发能用一个没有升级的产品吗?

    当然抛开这个不说了,我也学你断章取义挑刺哈,你说“一个语言语法再复杂也很难超过C++。一个星期可以学习一种语言”,是不是再说一个星期就可以搞定C++捏,嘿嘿。

    你应该这么理解,当你掌握了C++,基本上你一星期可以学会一种同类命令语言。 c++已经集语言概念复杂性之大成。

  92. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 09:39:50

    @陈梓瀚(vczh): 当然你又犯了一个错误,就是在转移话题了。我说的是,我在WinForm(或X)上的投资,会随着WinForm(或X)的消失而消失吗?显然你一直都没有正面回答我的问题。难道我学习C++学到手的知识,会在C++死掉的那一天就没价值了?我还是想要正面回答哈,你不要来跟我扯我会什么不会什么。

    你是为了学习知识而来,还是为了最终产品而来?

    你现在为啥不改用pascal写你的编译器呢?知识不是一样的吗?

    没错,用ODBC,DAO,RDO,ADO,Linq, ADO Entity Framwork都可以访问数据库,知识都是可以继承的,那你愿意每隔2年把你的数据库访问代码重写不?

  93. 老赵
    admin
    链接

    老赵 2010-11-09 09:44:08

    @mcpssx

    如果你觉得obj-c的变化不大,那么其实你应该觉得C#的变化也不大,看上去我觉得也都是差不多类型的变化么,而且,C# 4.0也是兼容C# 1.0的,不是吗?其实obj-c和Cocoa每年一次改进的速度,要说起来还真和.NET不分伯仲……

    虽然我不知道你是不是支持苹果,我只是想说明,这种“双重标准”我实在遇到的太多太多了……

  94. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 09:56:51

    @老赵

    我重点没说C#1.0到4.0的语法变化,我大部分时间都是在说“库和框架”,比如说ODBC,DAO,RDO,ADO,ADO .net, linq, ADOEntityFramwork, 比如说NetDDE,DCOM, Remotion, WCF等等。

    苹果我基本不用,如果也跟微软这样,那也是瞎折腾。

  95. 老赵
    admin
    链接

    老赵 2010-11-09 10:02:01

    @mcpssx

    框架类库又如何?其实你黑微软的的套路早就已经很清楚了,要么把好多年前甚至十多年前的东西翻出来反复说,要么把互补互足,甚至没有关系的一些名词罗列一番。通过你这些罗列,基本也可以看出你对微软技术的了解也就仅限于这些名称了。

    微软黑真是一门有前途的职业,太轻松了,的确不怎么需要学习,不像你口中的“微软技术”一样困难。

  96. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 10:03:19

    @老赵: 话说,MonoTouch真的很好用啊,编译db4o直接用。能够通杀iOS,Android,WP7的也就只有.NET了,这“积累”真是无与伦比啊……

    对啊,那你有没有注意到,其实这时候monotouch已经抛弃了.net库了,什么ADO Entity ,WCF,WF,WinForm,WPF都统统不用了。

  97. 老赵
    admin
    链接

    老赵 2010-11-09 10:18:17

    @mcpssx: 你有没有注意到,其实这时候monotouch已经抛弃了.net库了,什么ADO Entity ,WCF,WF,WinForm,WPF都统统不用了。

    可笑之至,你说越多,愈发显得你在胡扯。请别忘了我是.NET和MonoTouch的使用者,你扯这些之前哪儿来的自信?不做解释,想知道原因的话自己找吧。

  98. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 10:45:18

    @老赵: 可笑之至,你说越多,愈发显得你在胡扯。请别忘了我是.NET和MonoTouch的使用者,你扯这些之前哪儿来的自信?不做解释,想知道原因的话自己找吧。

    哦,monotouch还能用WPF、WinForm来写iphong程序?那我就很难理解了,wpf自己都和winform不兼容,怎么又能和cocoa兼容?

  99. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-09 10:59:22

    我看了一下老赵的《在Visual Studio中使用MonoTouch开发iOS应用程序(下):开发体验

    似乎也是用的apple的xib,而不是wpf,winform,其实mono在完整的linun上都支持不好,怎么会在一个受限的手机平台上支持的好?

    我看了一下,monotouch自己也说了

    Monotouch is also an extended subset of several Silverlight and desktop .NET assemblies.

  100. 陈梓瀚(vczh)
    124.79.164.*
    链接

    陈梓瀚(vczh) 2010-11-09 12:22:20

    @mcpssx

    就是因为我觉得都一样,所以我才不用相比之下落后的pascal,使用先进而且我喜欢的C++嘛,但是我从来没有担心过C++完了我会怎么怎么。

    话说回来你还是犯错误了,谁说wpf和winform不兼容了,我就干过把wpf和winform混用的事情,不也是好好的(当然不可能比单独用wpf或者单独用winform轻松的了)。而且你想用wpf做一点特别高级的事情的时候,API还是有用的(wpf最外面的窗口不也是窗口),连DirectX的PixelShader都有用(哈,爽吧)。知识都是一环扣一环的,将来wpf撕掉就咋了,那些RIA的架构不都是差不多的,难道这个时候你学起flex就能比那些什么都不会的难吗?

    话说回来,延续性当然是有的,可恶的VC6今天都还有人用呢,微软又没有跟疼讯一样说你运行了VC6就不给你上网。wpf是个新东西,相比起来算个啥。

  101. 老赵
    admin
    链接

    老赵 2010-11-09 13:33:11

    @mcpssx

    UI方面需要原生应用程序带来的体验,不用WinForm和WPF太正常不过了。要用WPF的话,就只能在WP7上用Silverlight做UI。但是,WCF是可以用的(因为这也是Silverlight的一部分),甚至MonoTouch没有提供一些工具,需要使用Win SDK里的工具自动生成代码,然后在MonoTouch里使用。

    此外,各种基础类库是可以用,ADO.NET是可以用的(访问的自然是SQLite),LINQ当然也是可以用的。你还可以拿一些开源项目,比如Json.NET,FlickrNet,CoolStorage等等,基本拿来编译直接用。各种各样的类库,不管是ORM也好,序列化之类的也罢,网络通信等等,几乎一切都是按照.NET程序员的习惯和积累。

  102. Terry Sun
    114.246.254.*
    链接

    Terry Sun 2010-11-09 14:41:24

    近期阅读的最靠普的一往往篇文章,说的也比较实在,不过我只对RESTful部分比较感兴趣,老赵在这方面看样子有很好的理解,其待你这方面的文章

  103. Aroden
    120.199.6.*
    链接

    Aroden 2010-11-10 01:18:25

    @mcpssx: 事实上,生产力底下与语言本身关系没有那么大,生产力取决于库,而库往往又取决于语言的简单性。

    技术我不会说,单看这一句话:我的天,什么逻辑。

    结论1:生产力不取决于语言。结论2:生产力取决于库。结论3:库取决于语言

  104. 链接

    陈梓瀚(vczh) 2010-11-10 02:12:41

    @Aroden

    所以这才有喷的乐趣啊……

  105. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-10 04:09:58

    @Aroden: 技术我不会说,单看这一句话:我的天,什么逻辑。结论1:生产力不取决于语言。结论2:生产力取决于库。结论3:库取决于语言

    你应该结合上下文来理解,

    1、我的“生产力底下与语言本身关系没有那么大”的意思就是并不是语言越复杂语法糖越多就越有生产力,这个典型就是C++。

    2、语言太复杂,虽然表面上语法的表达能力似乎强了,但是导致掌握库的生产力的下降,反而损坏了整个语言的生态圈。

    这个典型还是C++,C++的boost,loki都是非常精巧,非常难掌握反而损害了C++的库发展。

  106. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-10 04:25:13

    “生产力底下与语言本身关系没有那么大”这句话可能导致了歧义,所以我再明确一下。

    老赵自己翻译过anders的“一篇编程语言的发展趋势及未来方向”

    但是如果你关注一下目前的软件……过去27年里编程语言到底进步了多少?呵呵,有趣的是如果你仔细观察这些代码,会发现C#还比Turbo Pascal的版本多一行。这也给我们带来了一些值得关注的东西。

    首先,编程语言的发展非常缓慢。期间当然出现了一些东西,例如面向对象等等,但是远没有好上1000倍。另一方面,你可能会想,那么这些努力都到哪里去了呢?事实上这些努力没有体现在编程语言上,而是出现在框架及工具等方面了。

    它们都是基于现有框架构建的。现在已经有太多东西可以直接利用了,每次从头开始的代价实在太高。

    说明如下几点

    1、大多数的语法改进并不具有革命意义,如果掌握不好可能还导致歧义。这就是我说的够用了,新改进对生产力关系不大的原因。

    2、频繁改动库,等于从头开始,代价太高。

    3、简单的语言,参与者更多,使用时候错误更少,boost不但难写,而且难用。这就是为什么C比C++多,php比ruby多。

    兼容性好的语言,继承发展更好,目前所有的科学计算库大都有悠久的历史。

  107. 链接

    陈梓瀚(vczh) 2010-11-10 05:45:42

    @mcpssx

    嗯,根据你的原理,所以为了程序员的幸福,android这种比Windows Mobile和Symbian新的东西是不需要出现的。

  108. 链接

    陈梓瀚(vczh) 2010-11-10 05:54:58

    @mcpssx

    话说回来了,至少C++的生产力不可能比C底哈,所有C的东西到了C++都能用,你要是实在学不会C++还能去用旧的东西啊。你也要想想C++是什么时候出来的了,当时当然有当时的目的了。

    到了java和C#和haskell和clojure和F#和javascript和ruby和python和一些其他现代化的东西出来之后,问题就来了,你愿意牺牲现在的时间去换取将来的生产力呢,还是想牺牲将来的生产力去换取现在的时间呢?我们知道你不可能学不会任何新东西的,这显然是个前提。而且显然我们应该承认,在那些性能关系不是特别大(譬如说慢一点就要死的操作系统啦)的地方,这些语言做起事情来都比C++要方便很多。

  109. harry
    180.154.195.*
    链接

    harry 2010-11-10 06:23:19

    话说,我也对微软技术不怎么感兴趣,不过觉得mcpssx说的实在是牵强,甚至是可笑,你不如直接说一句你不喜欢微软技术就行了。

  110. 蔡春升
    58.34.116.*
    链接

    蔡春升 2010-11-12 08:27:04

    老赵,我想请教您是怎么研究Ajax的源代码的? 有什么方法么?最好来点给力的,哈哈

  111. 老赵
    admin
    链接

    老赵 2010-11-12 16:57:23

    @蔡春升

    好像这些是开源的吧,没开源就用.NET Refactor看。

  112. mathgl
    113.12.168.*
    链接

    mathgl 2010-11-13 08:14:13

    @llj098: 确实,术业有专攻。但是.NET没有几个成功的客户端,这是事实。在linux上面,Python做的客户端很多,而且很不错。而且,搞不懂的是,基于Mono的Banshee,Gnome Do,Docky,Tomboy 性能都很好,用起来都非常爽,反而先windows平台上,没啥这么出彩的程序。。。。

    mono在suse上的client的应用 基本上是基于 gtk#的。完全用winforms写的 我印象中没见过。

    早几年我曾经试图过把一些winform的东西移植到mono上。当时支持中文还不完善。2.x之后中文已经可以支持。但是整体效果还是有些怪异...

    跨平台比较好用的库还是qt..

    client有太多历史的缘故,现在用delphi7的开发native client的人还多的是。我们外销的实时监控系统就是基于winform的,没见有谁抱怨有性能的问题。

    要问为什么不用c++写? 答案比较简单:本地找不到这么多合格的c++开发人员。

  113. eflay
    218.2.216.*
    链接

    eflay 2010-11-14 05:39:15

    360软件管家上 .Net写的小程序挺多的,撞见好几个了,都没调查过就信口开河??

  114. 链接

    zsbfree 2010-11-14 11:19:04

    mcpssx ,你个脑残,老赵都不搭理你了,还他妈在这里叫唤

  115. 伍迷
    116.235.121.*
    链接

    伍迷 2010-11-20 13:05:48

    老赵,完全可以写一部中国程序员的自传。:)写得太好,不得不在潜水中探出头来挺你一下!

  116. cormin
    173.192.137.*
    链接

    cormin 2010-11-30 01:34:17

    突然发现老赵的rss刷新了好几十条,还以为一下子写了几十篇,吓一跳~ MonoDriod or MonoDroid 笔误吧?

  117. xin
    61.145.242.*
    链接

    xin 2010-12-08 07:49:09

    @mcpssx

    不清楚你为什么会来逛老赵的博客?单纯想跟老赵开辩论赛吗?我觉得你压根就不该用.net觉得哪个好用就用哪个去。

  118. Benjamin
    114.92.153.*
    链接

    Benjamin 2011-02-27 03:48:13

    书名《RESTful in Practice》好象写错了,应该是《REST in Practice》。

  119. sinpo
    113.132.152.*
    链接

    sinpo 2011-03-06 06:57:28

    技术这个东西,够项目用就行。有能力有时间可以往下挖挖。。

  120. 链接

    冯建 2011-05-09 15:02:49

    其实我同意你的能力,你的说法,但是我不同意你总是从你的角度来阐述net语言本身的问题,鉴于你名声太大,你会带给很多人的误导,你讨论技术就好。

  121. 老赵
    admin
    链接

    老赵 2011-05-10 04:24:24

    @冯建

    你不同意的话说清楚你的观点就行了,没必要说这种奇怪的话,我说什么都是我的自由,我没有误导任何人。还有就是,我讨论的如果不是技术还是什么?

  122. 枫天
    119.144.236.*
    链接

    枫天 2011-08-17 09:03:08

    终于把文章和评论看完了,发表下个人意见:windows的技术如同快餐,快得都没时间去研究它的原理,几年就换一次了,Unix/Linux的东东则如古董,几十年都没变。有的人喜欢新东西,有的人喜欢老古董,各取所需吧。决心要走微软路线的同学,建议看看这篇文章 http://coolshell.cn/articles/3008.html

  123. 老赵
    admin
    链接

    老赵 2011-08-17 12:02:55

    @枫天

    双方都有快餐和原理的东西,没人逼你学会微软的每个新东西,*nix也不是没有新东西。

    你给的这篇文章也完全不知所云,比如.NET其实就解决了dll hell的问题。某些人一边骂别人FUD,一边FUD别人,人品值得推敲。

  124. liiir1985
    84.163.187.*
    链接

    liiir1985 2011-10-14 11:03:15

    看了上面mcpssx的一些评论,我已经被雷的不行了……

    为啥Monotouch不支持WPF……,你这就跟问为啥iOS的objective-c不支持QT或者GTK一样……

    飞信客户端悲剧也不是因为.net性能低……而是因为当时国内.net不普及,他自己封装了个自己的虚拟机在跑.net(貌似是mono的自制版,我也沒太深研究),能不慢吗

    还有老赵说的无缝升级,指的是等效升级,例如c#1.0的代码,你拿到现在的vs2010+c#4.0一样可以直接编译和运行。你问winform到wpf为什么不能无缝升级……本来就是两个不同的东西,WPF又不是winform的升级版……但是并不是说你c#4.0就不能用Winform了啊。升级到新技术怎么可能无缝,因为老版本根本就没有这东西,你要怎么无缝从无变成有……如果你对新技术不感兴趣,你就直接用老技术就好了啊,只升级c#版本就好了。

    我是越来越不理解一些优越帝了……就像很多原生代码控喷C#说是解译型虚拟机,每个指令都要解译一次一样……我除了无奈摊手我能干啥,java初期的确是解译型虚拟机,但是也早就是历史了,而c#打出生就不是解译型。

    关于java和c#,我是两个都在用,java由于开源类库丰富,加上linux服务器的廉价和稳定性和高性能,所以有一定优势,但是我个人是非常不情愿用java写东西,一个是很多东西写起来比c#麻烦很多,二一个就是java的IDE操蛋(单独看其实还是满优秀,但是跟VS比起来真的是操蛋)……

    还有为啥现在很多公司依然是c++做客户端,很简单,这些公司在过去投入了巨资开发的类库或者引进的类库是c++,现有资深程序员也是c++,你要他怎么换。但是如果一切从头,很多公司都不会选择c++,而是java或者c#/vb.net,因为同样一个东西c++得一个月,而后者也许就2星期就搞定。

    还有程序性能低别怪罪给运行库或者工具,我见过一台服务器支持3000在线玩家的java/.net 服务器端,但是也见过一台服务器只能支撑200人的linux c++服务器端

  125. celt
    60.247.49.*
    链接

    celt 2012-04-17 09:20:03

    对于互联网开发来说,还是支持部署在linux平台下的语言更适合。

  126. Shihira
    125.92.79.*
    链接

    Shihira 2012-05-04 04:20:49

    不知你们对自由(开源)软件怎么想?因为我是学C++的,至于微软把开发力度放在了.Net,Web应用这些东西上,C++没有得益。这使得我的这条路举步艰难了呢……

发表回复

登录 / 登录并记住我 ,登陆后便可删除或修改已发表的评论 (请注意保留评论内容)

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

评论内容(大于5个字符):

  1. Your Name yyyy-MM-dd HH:mm:ss

使用Live Messenger联系我