Hello World
Spiga

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

2010-11-04 18:57 by 老赵, 7047 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 20:50:15

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

  2. Benjamin
    220.248.45.*
    链接

    Benjamin 2010-11-04 21:01:17

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

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

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

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

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

  4. 小木
    123.147.247.*
    链接

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

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

  5. iceboundrock
    183.0.27.*
    链接

    iceboundrock 2010-11-04 21:29:43

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

  6. Guancheng Chen
    129.16.196.*
    链接

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

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

  7. 老赵
    admin
    链接

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

    @Guancheng Chen

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

  8. 老赵
    admin
    链接

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

    @小木

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

  9. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-04 23:23:32

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

  10. 链接

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

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

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

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

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

  12. jc
    207.46.55.*
    链接

    jc 2010-11-05 11:54:10

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

  13. Daniel
    75.101.218.*
    链接

    Daniel 2010-11-05 12:05:29

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

  14. 老赵
    admin
    链接

    老赵 2010-11-05 12: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太方便了。

  15. jc
    207.46.55.*
    链接

    jc 2010-11-05 12:31:55

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

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

  16. 老赵
    admin
    链接

    老赵 2010-11-05 12: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系列的产品,从项目之间实现交流,代码参考来看,根本没见过有项目用这种方式,不知道你说的是哪些项目?

  17. 小木
    123.147.247.*
    链接

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

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

  18. 老赵
    admin
    链接

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

    @小木

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

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

  19. 小木
    123.147.247.*
    链接

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

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

  20. 小木
    123.147.247.*
    链接

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

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

  21. 老赵
    admin
    链接

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

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

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

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

  22. 老赵
    admin
    链接

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

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

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

  23. 小木
    123.147.247.*
    链接

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

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

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

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

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

  25. FMax
    59.37.15.*
    链接

    FMax 2010-11-05 16:34:46

    @小木

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

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

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

  26. mcpssx
    59.175.192.*
    链接

    mcpssx 2010-11-05 16:47:41

    @FMax

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

  27. 小木
    123.147.247.*
    链接

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

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

    只在此山中,云深不知处

  28. driedbeef
    61.143.46.*
    链接

    driedbeef 2010-11-05 20: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开发下新的力推对象。

  29. 老赵
    admin
    链接

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

    @driedbeef

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

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

  30. driedbeef
    61.143.46.*
    链接

    driedbeef 2010-11-05 22:09:19

    @老赵

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

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

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

  31. 小木
    123.147.247.*
    链接

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

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

  32. Mshadow
    123.118.1.*
    链接

    Mshadow 2010-11-05 22:55:03

  33. 老赵
    admin
    链接

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

    @小木

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

  34. 老赵
    admin
    链接

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

    @Mshadow

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

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

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

  35. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-06 00:05:11

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

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

  36. waynebaby
    112.64.20.*
    链接

    waynebaby 2010-11-06 00:13:40

    @jc

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

  37. 链接

    Ivony 2010-11-06 22:48:19

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

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

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

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

  38. llj098
    96.44.135.*
    链接

    llj098 2010-11-07 15:40:10

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

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

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

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

  39. 老赵
    admin
    链接

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

    @llj098

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

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

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

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

  40. llj098
    111.193.204.*
    链接

    llj098 2010-11-07 16:36:50

    @老赵

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

    另,飞信确实在转

  41. 链接

    zantesu 2010-11-07 17:16:16

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

  42. tshao
    210.13.83.*
    链接

    tshao 2010-11-07 19:10:01

    随便说一下jc说的两点:

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

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

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

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

  43. llj098
    111.193.204.*
    链接

    llj098 2010-11-07 21:02:09

    @zantesu

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

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

  44. 老赵
    admin
    链接

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

    @tshao

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

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

  45. 小言
    211.94.36.*
    链接

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

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

  46. Mikeshi
    112.64.127.*
    链接

    Mikeshi 2010-11-08 11:24:18

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

  47. 老赵
    admin
    链接

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

    @小言

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

  48. zhuisha
    221.216.161.*
    链接

    zhuisha 2010-11-08 13:06:05

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

  49. 链接

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

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

  50. 链接

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

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

  51. 老赵
    admin
    链接

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

    @zhuisha

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

  52. 老赵
    admin
    链接

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

    @陈梓瀚(vczh)

    对的,要自己打……

  53. 链接

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

    @mcpssx

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

  54. 链接

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

    @mcpssx

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

  55. 老赵
    admin
    链接

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

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

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

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

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

  56. 老赵
    admin
    链接

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

    @陈梓瀚(vczh)

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

  57. kw2010
    206.210.105.*
    链接

    kw2010 2010-11-08 21: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 到)。

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

  58. Duron800
    207.46.92.*
    链接

    Duron800 2010-11-09 10:44:43

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

    烂尾是不好的。

  59. 链接

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

    @mcpssx

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

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

  60. 链接

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

    @mcpssx

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

  61. 老赵
    admin
    链接

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

    @陈梓瀚(vczh)

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

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

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

  62. 链接

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

    @mcpssx

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

  63. 链接

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

    @mcpssx

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

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

  64. 链接

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

    @老赵

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

  65. 老赵
    admin
    链接

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

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

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

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

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

    @mcpssx

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

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

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

  67. 老赵
    admin
    链接

    老赵 2010-11-09 21: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程序员的习惯和积累。

  68. Terry Sun
    114.246.254.*
    链接

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

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

  69. Aroden
    120.199.6.*
    链接

    Aroden 2010-11-10 09:18:25

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

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

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

  70. 链接

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

    @Aroden

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

  71. 链接

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

    @mcpssx

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

  72. 链接

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

    @mcpssx

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

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

  73. harry
    180.154.195.*
    链接

    harry 2010-11-10 14:23:19

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

  74. 蔡春升
    58.34.116.*
    链接

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

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

  75. 老赵
    admin
    链接

    老赵 2010-11-13 00:57:23

    @蔡春升

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

  76. mathgl
    113.12.168.*
    链接

    mathgl 2010-11-13 16: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++开发人员。

  77. eflay
    218.2.216.*
    链接

    eflay 2010-11-14 13:39:15

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

  78. 链接

    zsbfree 2010-11-14 19:19:04

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

  79. 伍迷
    116.235.121.*
    链接

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

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

  80. cormin
    173.192.137.*
    链接

    cormin 2010-11-30 09:34:17

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

  81. xin
    61.145.242.*
    链接

    xin 2010-12-08 15:49:09

    @mcpssx

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

  82. Benjamin
    114.92.153.*
    链接

    Benjamin 2011-02-27 11:48:13

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

  83. sinpo
    113.132.152.*
    链接

    sinpo 2011-03-06 14:57:28

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

  84. 链接

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

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

  85. 老赵
    admin
    链接

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

    @冯建

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

  86. 枫天
    119.144.236.*
    链接

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

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

  87. 老赵
    admin
    链接

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

    @枫天

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

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

  88. liiir1985
    84.163.187.*
    链接

    liiir1985 2011-10-14 19: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++服务器端

  89. celt
    60.247.49.*
    链接

    celt 2012-04-17 17:20:03

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

  90. Shihira
    125.92.79.*
    链接

    Shihira 2012-05-04 12:20:49

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

已自动隐藏某些不合适的评论内容(主题无关,争吵谩骂,装疯卖傻等等),如需阅读,请准备好眼药水并点此登陆后查看(如登陆后仍无法浏览请留言告知)。

发表回复

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

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

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

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

使用Live Messenger联系我