我同意楼主观点,现在的程序员太不懂底层了,就这么说吧,你不懂得计算机到底怎么共坐的,你如果那天真接手了一格case让你开发底层方面程序,你怎么办?

还有,连基本的内存,缓存这些也不知道,你又怎么可以开发出有效的java程序,或者说是任何程序。

再简单点,现在的人只知道鼠标点来点去,连基本的格式化都不知道,所以,到现在我身边还有朋友问我怎么从装系统,我说先格式化,然后从状,他们就鼠标点击,然后告诉我格式化不了,你说我能说话,甚至有人直接在windows的run里面打format(好点的,知道了format).

如果说,Open Source的各种框架如此堆积,以前的话也许是互相学习,现在就是让一些人学者偷懒,连我同学,学经济的都问我,是不是变程序就是在网上下载代码,然后东凑西凑就行了。

以前是资源共享,现在是,垃圾堆里面淘金子,就说Hibernate吧,最著名的,也是最火的Linkin.com这个网站系统,2000万注册人数(不止),底层就直接JDBC,谁敢用Hiberanate,一个简单的查询,要select两边数据库,一遍id,一便内容,可是没做过以前数据库开发,写过SQL语句的,谁又知道这种潜在性能差距?

记住了,做程序和做人一样,托的越高摔的越狠,和解?被各种新技术,新框架把程序员们慢慢的托德越来越离开基础,底层的东西,到时候,大批人进入那个层次,竞争力增加,薪水降低,后果自己就可以像出来,这也是为什么大批人说程序员工资低,找不到好工作的原因。

简单描述一下我理解当中的层次,当然忽略了不少:
->JDBC->Hibernate等ORM->业务类库和接口
在上面这个层次当中,每一层都可以使用下层的API却不依赖下层的实现,如果说orm影响了性能,那是ORM的实现出了问题而不是接口出了问题,因为性能不佳就要下探到JDBC层次,也会发现某个情况下JDBC也不能满足要求,只好再次下探去寻找更好的JDBC驱动实现,如果JDBC也不能满足,就只好再次下降到DB级用专用工具解决,这样的情况才导致了不断下降的趋势。ORM出了问题应该放到ORM实现和JDBC提供的接口这一层中去解决,而不是说ORM的接口和业务类库间有问题,既然站在这个层次上使用ORM接口,说明已经默认了ORM可以适应,如果不能适应可以换ORM实现(其实用JDBC实现之后,就是自己实现了一个专用的ORM,但此时自己在充当另一种角色,ORM开发的角色,这个角色和他上面的业务开发角色是不同的,没必要让业务开发的角色知晓他下面到底有什么动作即便两个角色是同一个人),而不是不要层次,越过层次去直接用下层管理,当然就会像前面说的不断下降,只有把问题归结在某个层次,然后去管理那个层次的实现,这才能保证层次间的透明性。
[该贴被freebox于2008-09-23 12:09修改过]

查询资料的时候路过这里,发现火药味真的很浓,其实没必要了。想研究底层的同志就去研究吧,如果你把研究底层作为一种乐趣的话,喜欢直接用框架的同志就直接用吧,剩下时间做做其他娱乐活动也不错。世界本来就是多样的,不要说谁是真正的程序员谁不是,不要说谁配得上真正的程序员谁配不上,走自己的路就好了,喜欢练内功就练内功,喜欢剑走偏锋也可以,还真不知道谁能拿武林盟主呢。软件开发是要看客户的需要的,我现在开发的项目就是一个小项目,什么框架都没用,简单jsp+javabean,能满足客户需要就好了,千万不要为了追求新技术而追求技术,个人愚见。
[该贴被dandyzhao于2008-09-26 10:28修改过]

我们不需要造轮子,并不代表我们不需要知道轮子怎么造出来的,只有最清楚轮子怎么造出来的人,才是最知道怎么使用轮子的人

难道不知道汽车怎么造出来的,就不知道怎么开汽车了吗?

软件的首要目的是做成系统,支持业务.
各种框架的存在是自然规律,这样的层次多了去了.
钻研到什么程度是个人爱好.各种层次的人都有其生存的空间,楼主想的太多了.
依你的理论,了解这些框架原理和方法就够了吗?怎么也得写几个框架出来吧?Java语言就不该了解吗?JDK得明白点吧?汇编语言是什么东西?机器语言是什么东西?电脑是怎么造出来的?半导体怎么生产?
想那么多没必要,工程师活的未必比工人快乐
[该贴被accipiter于2008-10-20 17:30修改过]