硬件越跑越快，软件越陷越慢

近日总算有点空闲，走马观花测试了一些技术，包括Grails、Seam、AOM、Python、ZendFramework、CakePHP、Flex、WPF等等，回到JE看了一些讨论，忍不住又要放点黄腔了。

自从多核CPU成为PC标配以后，硬件又上了好大一个台阶。到朋友家看了一下“孤岛危机”，实在是超级惊艳。单位上也终于耗上了一台双核、2G内存，这下跑什么IDE和AppServer都不用去小歇片刻了，真是感谢硬件产商们的努力。

某天看了一篇文章，地址记不清了，却道出了应用程序的本质：“不过就是在数据库里读读写写”，这下便像吃了苍蝇般不爽了起来。搞腾这个行当转眼也七、八年了，回头一想，的确是该反省反省了。

好几年前，更换电脑似乎总是为游戏而换。越来越清晰、越来越眩目、越来越震撼，且不论游戏好不好玩，单声光效果的提高都物有所值。那时候的应用程序其实要求是不高的，VB、Delphi、ASP、PHP这些老革命的IDE和作品，至今可以在怀旧的时候，拿到奔腾166的老机器上去跑一跑，丝毫不见慢。所以那时候更换电脑是与App无关了。

Java引领的虚拟机时代让笔者一度迷了五六年，曾经笔者一度天真地以为只要全面进入虚拟机和中间件时代就可以解决企业应用软件的种种问题，达到高度的业务逻辑重用、高度的异构集成、高度的安全性与伸缩性。这其间折腾的技术、框架加起来怎么也有几十种了，时光飞逝，转眼三十老几了，回头一想，当初的信仰很傻很天真，到头来“不过就是在数据库里读读写写”，最可笑的不过是越来越复杂、越来越慢。看来这些年是陪Sun、IBM、Microsoft以及开源领域的大牛们玩过去了。

由于是在单位上混，出于饭碗的需要，几年来不得不参加了当初以为“不切实际”的软考，一直混到系统分析师。回头看下来，这些个“不切实际”的学究体系其实反倒有些有用处。硬着头皮大体上啃了一遍学究知识，最后才搞明白程序要快要稳定，还是要搞清楚CPU、内存和硬盘；而所谓的可靠性、重用性、扩展性、...XX性，不是靠什么具体的软件技术，而是在于规范的管理与审慎的规划。

缘木求鱼，这就是国内软件业超级混乱的根源。根子上在于我们想偷懒的惰性，明明是我们该自己去思考、去设计、去解决的问题，我们不断地迷信可以依靠“大腕”、“大牛”们来解决。其实连伟大的党都承认了，“没有放之四海而皆准的真理”，何况是软件这种由人造、由人用的事物。结果如何，“大腕”、“大牛”们出于各种各样的目的，不断制造混乱。而我们，正是那随波逐流混水中的泥。

虚拟机时代到来了，动态语言时代到来了，SOA时代到来了，XXX时代到来了，无数吹鼓手吹起了喇叭，震耳欲聋。大家昏头昏脑跳进大大小小的池塘，一边陷下去，一边互相嘲笑、互相鄙视、互相谩骂。好一个热闹的软件大超市。

吹嘘有何用，迷信有何用？最终，还是要抓住硬件这根救人的稻草。

评论

37 楼 icewubin 2008-05-07  

ztka 写道

回归到楼主的话题，为什么很多人说hibernate什么用起来不慢，他们碰不到数据量比较大的场景

数据量大的场景的使用方法就不是教科书上的那种了，数据量大必须要结合具体的需求来分析。

36 楼 icewubin 2008-05-07  

mcpssx 写道

缓存都是些赶时髦的，

企业应用还缓存个P？WEB应用会用什么hibernate缓存吗？

java的Web开发


用
XML说可配置，

用JAVA不用SQL说数据库可移植，
分N多层还说可维护，
关系模型不用去转换成什么对象模型，

最后被一群phper草根乱拳打死老师傅

企业应用为什么不能用缓存，以很小的代价获得高性能回报，为什么不用？
二级缓存先不提，hibernate一级缓存（一个事物中的缓存）就能直接减少数据库的访问次数，当然有用。
不要老说web开发，那只是“平原型”的项目，如果是“深井型”的项目，或者后台逻辑稍微一复杂，重点就不是web开发了。

XML可配置，现在不流行的，java框架也可以进步的，思想本来就可以借鉴的嘛。

可移植当然重要，难道你自己写针对不同数据高效的分页算法么？你不要告诉我什么项目定了，数据库就定了，我见过太多的更换数据库的例子，还就是做产品的话，怎么能不考虑数据库的多样性。

分N层不很正么，比如事务层，aspectJ配好就完事，一劳永逸有什么不好，难道自己不停的写begin transaction、end transaction么？你用数据库如何实现灵活的事务传播机制，难道不停的复制粘贴代码么，可维护性好么？

phper草根乱拳，我不否认任何语言的存在合理性。
1.思想可以互相借鉴，比如约定大于配置的思想。
2.技术的繁荣那个程度的因素不是有时否是“草根”决定的，非技术的因素太多了，说起来Hibernate不也是“草根”出身么？为什么phper的草根就比别人高贵么？

35 楼 lgcpeter 2008-05-07  

引用

由于是在单位上混，出于饭碗的需要，几年来不得不参加了当初以为“不切实际”的软考，一直混到系统分析师。回头看下来，这些个“不切实际”的学究体系其实反倒有些有用处。硬着头皮大体上啃了一遍学究知识，最后才搞明白程序要快要稳定，还是要搞清楚CPU、内存和硬盘；而所谓的可靠性、重用性、扩展性、...XX性，不是靠什么具体的软件技术，而是在于规范的管理与审慎的规划。

对于国内的程序员有很有教育意义！础性的知识不可缺乏，否则只能玩儿玩儿而已！

34 楼 ztka 2008-05-07  

icewubin 写道

ztka 写道

你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。

怎么会都是静态的，我还特地举淘宝的例子，图片我只是单独拿出来说，图片信息本身就是动态的，不同的卖家发布新的商品的图片更新。

1.你只用数据库存储过程，你设计一个taobao这样的网站试试？数据库能搞定多少问题，这种数据库方案也不过是利用（或者说迷信）数据库的同步机制罢了，和那些迷信J2EE所谓的高效同步机制有什么本质区别。

2.即使不说大网站，企业软件，并发上个50-200也是蛮正常的吧，刚才说了，用个结构很简单的数据字典缓存机制根据需求就能极大的改善性能，而且开发量相对不大，但用数据库结构做的到么。我的意思是系统复杂度达到一定程度，不好好设计整体的话，开发复杂的，代码（不管什么代码）复杂度，维护成本是以几何级数往上翻的。

你理解的静态是什么？一直不会变得东西？ 你用过squid吗？

以数据为核心设计，不是说只用存储过程。

你说淘宝架构，我用php+mmcache+squid+lvs+mysql等就可以实现，成本比你的java至少少50%，开发成本少50%

33 楼 icewubin 2008-05-07  

ztka 写道

你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。

怎么会都是静态的，我还特地举淘宝的例子，图片我只是单独拿出来说，图片信息本身就是动态的，不同的卖家发布新的商品的图片更新。

1.你只用数据库存储过程，你设计一个taobao这样的网站试试？数据库能搞定多少问题，这种数据库方案也不过是利用（或者说迷信）数据库的同步机制罢了，和那些迷信J2EE所谓的高效同步机制有什么本质区别。

2.即使不说大网站，企业软件，并发上个50-200也是蛮正常的吧，刚才说了，用个结构很简单的数据字典缓存机制根据需求就能极大的改善性能，而且开发量相对不大，但用数据库结构做的到么。我的意思是系统复杂度达到一定程度，不好好设计整体的话，开发复杂的，代码（不管什么代码）复杂度，维护成本是以几何级数往上翻的。

32 楼 ztka 2008-05-07  

icewubin 写道

lgx522 写道

icewubin 写道

有吗？为什么你会认为用了framework、ORM、Ioc、AOP就会严重降低，我这里说了是“严重”，慢是慢一点，但是在整个运行时的体系中，这样的慢是可以忽略的，牵涉到优化理论了，打住。

但是我说的慢是是一些固有的慢，比如反射的开销，而且随着JVM的进步，这些开销也在改善，JDK1.4的反射就要比1.2的速度快很多。

但是绝大多数的时候，这个“慢”是使用不当造成的，而不是这些技术带来的，当然大家可说，这些技术的带来了更多的学习成本。

有兴趣的测一下。同一台AppServer机器，同一台DB。先来个小库，弄上十来条记录；再来个大库，弄个几千万条记录。
随便配个连接池，拿jdbc+Servlet+jsp做点CRUD，找个工具测一下，顺便记录一下搞定这些事情的时间。
Spring+XX+XX，再做同样的事情，再测一下。
再测个Grails。
传统EJB就免了，来个时髦的Seam，再测。

Java体系外的，测一测RoR，ASP，ASP.NET，PHP，cakePHP、Zendframework。

顺便提一下缓存的问题：
互联网应用，缓存是个宝，多加内存吧。可惜当前的互联网应用交互性越来越强了，“写”的东西越来越多，缓存也未必能解决多少问题。
企业应用，缓存就免了。以写为主、即时查询统计数据，缓存无用。

测试下来看看每种技术下耗费的开发时间和运行效率，就会感慨Rod Johnson说的“问问机器”。这下子，才知道操作DB的效率是决定因素。如果效率不再重要，大网站也就不会连DB都不用，转回去用文件了。

拐一个弯就慢一点，拐好几个弯就慢得太多。倒不如简单直接，开发、运行和维护都才够快。
说真的，最近是越来越认同Oracle大牛们把业务逻辑放进存储过程的言论了，不仅仅是高效率，同时也是现实可行的高重用。好在MySQL5也可以用存储进程了，大家大可试试这种模式。

当你并发量百万级以上后，软体体系就不完全是这样的了，数据库是很重要，但不是万能的，在整个体系架构设计中，数据库就是一部分而已，最终考虑数据的流向还是要从业务需求来讲的，可以看看如taobao、myspace、土豆网的架构设计。

你刚才写的crud测试代码本身就是有问题的，要在一定的需求前提下讨论，如果拿电信计费这种需求来讨论的话，结果当然如您所说，但是如果用户操作习惯是类似于淘宝这种的话就是另外一回事了。

举个例子，一个较复杂的查询，之所以叫较复杂，是因为更复杂的就应该上搜索引擎了，这个查询可能有10个参数，不同的组合就是10！个sql可能，所以一般都是拼sql，如果正巧拼出来和某一次正好一样，中preparedstatment缓存的话另说了。而且不同的参数关联的表也有可能不一样，拼的过程中还能查询优化。抛砖引玉的例子，也不想说什么其他方式做得不好，只是实现和维护和需求变更的代价非常大而已。

再说缓存，往低的说Hibernate有自己的缓存机制，不过至少我觉的不太够用。一般的程序中可以考虑自行设计一些开发代价很小的缓存机制，比如数据字典的缓存。往大的说，像taobao这种网站的图片等数据，就是要专门设计分布式缓存服务器了，对就像你说的，抛弃了DB，直接转向文件系统，但是把数据从文件系统中读取，放到内存里，然后进行分布式管理和之中优化的算法，这还是软件做的事啊。

你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。

网站方面，也就是ebay和淘宝用java架构，其他的，google，youtube，facebook，wiki等都不是java架构。

31 楼 icewubin 2008-05-07  

lgx522 写道

icewubin 写道

有吗？为什么你会认为用了framework、ORM、Ioc、AOP就会严重降低，我这里说了是“严重”，慢是慢一点，但是在整个运行时的体系中，这样的慢是可以忽略的，牵涉到优化理论了，打住。

但是我说的慢是是一些固有的慢，比如反射的开销，而且随着JVM的进步，这些开销也在改善，JDK1.4的反射就要比1.2的速度快很多。

但是绝大多数的时候，这个“慢”是使用不当造成的，而不是这些技术带来的，当然大家可说，这些技术的带来了更多的学习成本。

有兴趣的测一下。同一台AppServer机器，同一台DB。先来个小库，弄上十来条记录；再来个大库，弄个几千万条记录。
随便配个连接池，拿jdbc+Servlet+jsp做点CRUD，找个工具测一下，顺便记录一下搞定这些事情的时间。
Spring+XX+XX，再做同样的事情，再测一下。
再测个Grails。
传统EJB就免了，来个时髦的Seam，再测。

Java体系外的，测一测RoR，ASP，ASP.NET，PHP，cakePHP、Zendframework。

顺便提一下缓存的问题：
互联网应用，缓存是个宝，多加内存吧。可惜当前的互联网应用交互性越来越强了，“写”的东西越来越多，缓存也未必能解决多少问题。
企业应用，缓存就免了。以写为主、即时查询统计数据，缓存无用。

测试下来看看每种技术下耗费的开发时间和运行效率，就会感慨Rod Johnson说的“问问机器”。这下子，才知道操作DB的效率是决定因素。如果效率不再重要，大网站也就不会连DB都不用，转回去用文件了。

拐一个弯就慢一点，拐好几个弯就慢得太多。倒不如简单直接，开发、运行和维护都才够快。
说真的，最近是越来越认同Oracle大牛们把业务逻辑放进存储过程的言论了，不仅仅是高效率，同时也是现实可行的高重用。好在MySQL5也可以用存储进程了，大家大可试试这种模式。

当你并发量百万级以上后，软体体系就不完全是这样的了，数据库是很重要，但不是万能的，在整个体系架构设计中，数据库就是一部分而已，最终考虑数据的流向还是要从业务需求来讲的，可以看看如taobao、myspace、土豆网的架构设计。

你刚才写的crud测试代码本身就是有问题的，要在一定的需求前提下讨论，如果拿电信计费这种需求来讨论的话，结果当然如您所说，但是如果用户操作习惯是类似于淘宝这种的话就是另外一回事了。

举个例子，一个较复杂的查询，之所以叫较复杂，是因为更复杂的就应该上搜索引擎了，这个查询可能有10个参数，不同的组合就是10！个sql可能，所以一般都是拼sql，如果正巧拼出来和某一次正好一样，中preparedstatment缓存的话另说了。而且不同的参数关联的表也有可能不一样，拼的过程中还能查询优化。抛砖引玉的例子，也不想说什么其他方式做得不好，只是实现和维护和需求变更的代价非常大而已。

再说缓存，往低的说Hibernate有自己的缓存机制，不过至少我觉的不太够用。一般的程序中可以考虑自行设计一些开发代价很小的缓存机制，比如数据字典的缓存。往大的说，像taobao这种网站的图片等数据，就是要专门设计分布式缓存服务器了，对就像你说的，抛弃了DB，直接转向文件系统，但是把数据从文件系统中读取，放到内存里，然后进行分布式管理和之中优化的算法，这还是软件做的事啊。

语言只是工具，设计模式是让你有更好的代码组织和重用，减少维护工作量，和提高响应速度（如果有这种需求的话）。好的设计模式有时候通常也不是以性能为代价的，甚至于可能有更好的性能。然后就是框架，首先要了解框架，看能利用其中多少，适合于自己的技术体系，或者是适合当前项目的业务特征，并且不使用不适合的部分，就像Spring东西一堆，我们只用其中小部分而已。
但是如果测试是按照什么教科书上的那些方式还是免了吧，实际项目中是不会这么做的。

30 楼 hsq972 2008-05-07  

现在大多数人都是因为framework而用framework.

但不可否认优秀的framework用得好,确实能大大提高生产效率.至于系统性能,对于已经非常便宜的硬价格来说,已不是大问题了.

29 楼 coolmenu 2008-05-07  

icewubin 写道

lgx522 写道

mathgl 写道

用C作业务不是没有。
我的同事做农发行的业务就是用C写业务处理的

java仅仅作为前端界面而已

那些是属于高端应用了，运行速度要求很高，肯定得用C。很多海量访问的网站，性能要求高的部分模块也是如此做的。

google和taobao算是海量吧，貌似都是java（不是所有模块，但是如google的底层操作系统不算软件模块）的吧。

google最常用的是c++ /java/python.关键的业务总是由c++做的
facebook的thrift框架看到了吧，也是用c++ 做的通讯关键层
facebook的访问量多大？好像是前4吧?

28 楼 ztka 2008-05-07  

回归到楼主的话题，为什么很多人说hibernate什么用起来不慢，他们碰不到数据量比较大的场景

27 楼 ztka 2008-05-07  

lgx522 写道

ztka 写道

因为首先硬件架构是基础，很多事情硬件架构基本解决了很多问题了。软件方面，我坚持简单就是美的风格，弄一大堆framework，不如弄简单的sql更好，说维护什么麻烦的，那是自己定义package没有定义好。

关于维护问题，说到点子上了。

很多说sql难以维护的，基本都是定义功能，模块，package什么定义的不好，导致那个结果。我看到大并发的东西，例如yahoo，google什么的，也没有用那么多framework。

26 楼 lgx522 2008-05-07  

ztka 写道

因为首先硬件架构是基础，很多事情硬件架构基本解决了很多问题了。软件方面，我坚持简单就是美的风格，弄一大堆framework，不如弄简单的sql更好，说维护什么麻烦的，那是自己定义package没有定义好。

关于维护问题，说到点子上了。

25 楼 lgx522 2008-05-07  

icewubin 写道

有吗？为什么你会认为用了framework、ORM、Ioc、AOP就会严重降低，我这里说了是“严重”，慢是慢一点，但是在整个运行时的体系中，这样的慢是可以忽略的，牵涉到优化理论了，打住。

但是我说的慢是是一些固有的慢，比如反射的开销，而且随着JVM的进步，这些开销也在改善，JDK1.4的反射就要比1.2的速度快很多。

但是绝大多数的时候，这个“慢”是使用不当造成的，而不是这些技术带来的，当然大家可说，这些技术的带来了更多的学习成本。

有兴趣的测一下。同一台AppServer机器，同一台DB。先来个小库，弄上十来条记录；再来个大库，弄个几千万条记录。
随便配个连接池，拿jdbc+Servlet+jsp做点CRUD，找个工具测一下，顺便记录一下搞定这些事情的时间。
Spring+XX+XX，再做同样的事情，再测一下。
再测个Grails。
传统EJB就免了，来个时髦的Seam，再测。

Java体系外的，测一测RoR，ASP，ASP.NET，PHP，cakePHP、Zendframework。

顺便提一下缓存的问题：
互联网应用，缓存是个宝，多加内存吧。可惜当前的互联网应用交互性越来越强了，“写”的东西越来越多，缓存也未必能解决多少问题。
企业应用，缓存就免了。以写为主、即时查询统计数据，缓存无用。

测试下来看看每种技术下耗费的开发时间和运行效率，就会感慨Rod Johnson说的“问问机器”。这下子，才知道操作DB的效率是决定因素。如果效率不再重要，大网站也就不会连DB都不用，转回去用文件了。

拐一个弯就慢一点，拐好几个弯就慢得太多。倒不如简单直接，开发、运行和维护都才够快。
说真的，最近是越来越认同Oracle大牛们把业务逻辑放进存储过程的言论了，不仅仅是高效率，同时也是现实可行的高重用。好在MySQL5也可以用存储进程了，大家大可试试这种模式。

24 楼 ztka 2008-05-07  

因为首先硬件架构是基础，很多事情硬件架构基本解决了很多问题了。软件方面，我坚持简单就是美的风格，弄一大堆framework，不如弄简单的sql更好，说维护什么麻烦的，那是自己定义package没有定义好。

23 楼 neora 2008-05-07  

软件架构复杂了一些，软件开发难度便简单了一些。
软件层次多了一些，开发出的软件功便更丰富了一些。
软件难度降低了一些，能从事软件开发人员的人数便多了一些。
程序员多了一些，软件成本便降了一些。
编程语言高层了一些，能重用的代码/组建和软件包便多了一些。
硬件High了一些，考虑性能的顾虑便少了一些。
CPU计算能力更发达了一些，总体软件的执行效率更下降了一些。

现在的软件越来越费电。

22 楼 icewubin 2008-05-07  

lgx522 写道

近日总算有点空闲，走马观花测试了一些技术，包括Grails、Seam、AOM、Python、ZendFramework、CakePHP、Flex、WPF等等，回到JE看了一些讨论，忍不住又要放点黄腔了。

自从多核CPU成为PC标配以后，硬件又上了好大一个台阶。到朋友家看了一下“孤岛危机”，实在是超级惊艳。单位上也终于耗上了一台双核、2G内存，这下跑什么IDE和AppServer都不用去小歇片刻了，真是感谢硬件产商们的努力。

某天看了一篇文章，地址记不清了，却道出了应用程序的本质：“不过就是在数据库里读读写写”，这下便像吃了苍蝇般不爽了起来。搞腾这个行当转眼也七、八年了，回头一想，的确是该反省反省了。

好几年前，更换电脑似乎总是为游戏而换。越来越清晰、越来越眩目、越来越震撼，且不论游戏好不好玩，单声光效果的提高都物有所值。那时候的应用程序其实要求是不高的，VB、Delphi、ASP、PHP这些老革命的IDE和作品，至今可以在怀旧的时候，拿到奔腾166的老机器上去跑一跑，丝毫不见慢。所以那时候更换电脑是与App无关了。

Java引领的虚拟机时代让笔者一度迷了五六年，曾经笔者一度天真地以为只要全面进入虚拟机和中间件时代就可以解决企业应用软件的种种问题，达到高度的业务逻辑重用、高度的异构集成、高度的安全性与伸缩性。这其间折腾的技术、框架加起来怎么也有几十种了，时光飞逝，转眼三十老几了，回头一想，当初的信仰很傻很天真，到头来“不过就是在数据库里读读写写”，最可笑的不过是越来越复杂、越来越慢。看来这些年是陪Sun、IBM、Microsoft以及开源领域的大牛们玩过去了。

由于是在单位上混，出于饭碗的需要，几年来不得不参加了当初以为“不切实际”的软考，一直混到系统分析师。回头看下来，这些个“不切实际”的学究体系其实反倒有些有用处。硬着头皮大体上啃了一遍学究知识，最后才搞明白程序要快要稳定，还是要搞清楚CPU、内存和硬盘；而所谓的可靠性、重用性、扩展性、...XX性，不是靠什么具体的软件技术，而是在于规范的管理与审慎的规划。

缘木求鱼，这就是国内软件业超级混乱的根源。根子上在于我们想偷懒的惰性，明明是我们该自己去思考、去设计、去解决的问题，我们不断地迷信可以依靠“大腕”、“大牛”们来解决。其实连伟大的党都承认了，“没有放之四海而皆准的真理”，何况是软件这种由人造、由人用的事物。结果如何，“大腕”、“大牛”们出于各种各样的目的，不断制造混乱。而我们，正是那随波逐流混水中的泥。

虚拟机时代到来了，动态语言时代到来了，SOA时代到来了，XXX时代到来了，无数吹鼓手吹起了喇叭，震耳欲聋。大家昏头昏脑跳进大大小小的池塘，一边陷下去，一边互相嘲笑、互相鄙视、互相谩骂。好一个热闹的软件大超市。

吹嘘有何用，迷信有何用？最终，还是要抓住硬件这根救人的稻草。

楼主的眼界应该更开阔一点，大厂商的技术本来就有多重要素，一方面，大客户如那些炼钢的或者是石油公司的超级复杂的软件体系，当复杂度超过一定程度，再考基本的一些所谓的业务管理是搞不定的；另一方面大厂商处于市场考虑推出各种技术，当然技术本身有好有坏，不一定都是吹牛的。

每年都会出现新技术，只要你能看清楚这些技术来龙去脉和本质，结合自己的技术观点，就能做出判断了，对搞技术的人来说，如SOA冷笑一声就可以了。IBM自己的人偷偷的说SOA的精髓只不过是一套做事的规范，不是什么软件规范（这句话机密，不要外泄）。

但是，如果你是一个业务分析师，即使技术出身，对于SOA的东西还是要作了结的，它的理论中总是有可取之处的，拿来主义嘛，不过这个属于市场营销层面的东西了，虽然和技术无关，但是技术要推广的好，也是部分依赖于市场营销的，像微软这方面就做得很好。

我认为再怎么混乱也比微软一家独大要好（尤其是不希望SL独大）。

21 楼 小虫1313 2008-05-07  

如有那天有LZ之见解与感慨，也不枉到大超市来一遭。。
学习中。。

20 楼 niwei 2008-05-07  

jjx 写道

说点实在的，在这个浑水缸里，踏踏实实掌握好DB、SQL和业务管理才是正道。

不知道大公司是什么样，个人觉得说的这点非常符合我现在所在的小公司。

19 楼 icewubin 2008-05-07  

lgx522 写道

mathgl 写道

用C作业务不是没有。
我的同事做农发行的业务就是用C写业务处理的

java仅仅作为前端界面而已

那些是属于高端应用了，运行速度要求很高，肯定得用C。很多海量访问的网站，性能要求高的部分模块也是如此做的。

google和taobao算是海量吧，貌似都是java（不是所有模块，但是如google的底层操作系统不算软件模块）的吧。

18 楼 icewubin 2008-05-07  

xianhe 写道

tedeyang 写道

无语
楼主还是去用C吧。
既然是做应用级软件，那就要有做应用级软件的觉悟。
看来楼主不是科班出身的。

其实计算机专业科班的门槛很低,除了离散数学,其他的都没有什么.软件工程只不过吸收了加工业和建筑业的经验,软件从业人员奉为圣经的UML不过是软件工程大师们希望能实现想机械图纸的功能."过程决定质量"也是从日本的加工制造业发展中得到经验,"设计模式"是建筑业的经验.说实话,计算机专业真的没有什么.

计算机和软件工程不是一个专业，不要混淆。

计算机专业本科除了离散以外，重要的还有操作系统和编译原理。