主题：【原创】也来说说Linux和Windows下的开发感受 -- 昔杨今雨
家园 【原创】也来说说Linux和Windows下的开发感受 在河里闲逛, 看到这里大家讨论得挺热闹, 不由得手痒, 也来说说俺的感受.
俺的起步是Turbo C, 后来是Borland C++, 没有多久, 接触到了Sun Sparc Workstation, 其后4年, 一直在Unix下, 包括大学毕业后还在SCO下折腾了1年. 然后换了公司, 又在Windows下用了3年VC. 随着职位的升迁, 直接编程的机会越来越少, 直到辞职创业, 又回到了Unix环境, 这次是Linux了. 最近随着桌面产品的逐步推出, 处在LW两栖状态下, 真的变成了青蛙;-)
回顾一下这十几年的开发经历, 对这两种平台的开发感受也是随着时间不断有更深的体会.
最早的一个感受, 到现在我也依然这么认为, 就是Windows下的IDE让很多人成为一个庸庸碌碌的程序员. 我刚开始接触 Unix的时候, IDE? 不, 我们只有命令行:-). 开发人员面临的第一个问题就是如何组织你的源代码. 你必须很在意代码文件的命名和目录结构, 否则自己都会被搞糊涂. 记得当时常用的方法就是一个函数一个文件, 文件名就是函数名; 随时注意代码的重用, 可以编译成一个lib的, 就编译成lib, 模块化的概念由此产生; 命令行方式的debug不是很方便, 因此就必须在代码编写的时候高度重视代码的质量; F1帮助? 拜托, 请自己去查; 重复敲打命令很让人厌烦, 做个shell script来批量执行, 这又是最早对解释型编程语言的接触. everything is a file, do one thing and do it best, 这些Unix设计思想中的精华就这样深印在脑海里. 这些都是被逼出来的, 但是回头看看, 收获是如此丰厚, 以至于至今受益.
而舒适的IDE不会让一个刚刚接触编程的人获得上面任何一个经验, 就像一个一直用傻瓜相机的人永远不会成为一个优秀摄影师一样, 一直使用IDE编程的人也不会成为一个优秀的程序员. 顺便说一下, 我觉得唯一比一个初学者使用IDE更糟糕的是: 他(她)居然使用中文版的IDE.
我的第二个看法, Windows和Unix在它们诞生之初就存在很大的区别. 用玩具打个比方, 如果Windows是一个洋娃娃, Unix就是Lego. 当我们讨论这两个平台作为开发环境的优劣的时候, 我们不仅要评价它们各自可以给最终用户带来什么, 更应该认真思考一下这两个平台分别为程序员带来什么. Unix自身就是一个最好的演示, 因为它给了程序员一张解剖图, 而不是一个黑盒. 即使你仅仅在使用它, 只要你愿意多问个为什么, 它就会带着你由简入繁, 再由繁入简. 这就好像杨过睡的寒玉床, 不知不觉中, 功力就得到了提升. 从这个意义上来说, Unix难道不是一个最好的开发环境吗?
第三点是看了大家的讨论后而产生的, 在跟帖里面, 各位都有很多很好的意见, 但是我觉得大家在比较的时候似乎都忽略了很重要的一点, 那就是团队开发. 单个技术的比较在我看来容易发生分歧, 而且意义不大. 在实际工作中, 我们往往是在一个团队中或者领导着一个团队. 我说四个字"持续集成". 也许你看到这里已经微笑, 那么我们自有会心处. 如果您还不明白, 那么我就追问一句, 在Windows和Unix下, 分别搭建一个持续集成环境, 哪个更方便, 哪个更成熟?
顺便鸣谢AllenKi, 他的一篇讲IPhone SDK的文章, 看了以后给我触动很大, 可以说, 苹果对产品看法和开发原则给我打开了一片新天地, 我正在尝试走入这片新天地, 希望有一天我还可以对这三者进行一些深入的比较.
家园 重量级的好帖 也引发了重量级的讨论，很受教益。
最同意的一点就是Linux/Unix下的团队开发相当容易，比Windows要强不少。CVS还是open source的，真好。
家园 JAVA的资源共享做的真是好。 毕业两年之后，就开始在UNIX/C下忙活，n年下来积累了一套完整的工具库。
但是和JAVA平台相比，这个编程模式差别很大。在UNIX/C下面，如果出现一个新的自己没有编过的东西，是查资料，然后再自己设计算法，然后编出来。而做JAVA编程的人，则是先上社区四处转转，看有没有现成的控件，Down下来用。
真是有些羡慕死了，虽然做JAVA的不会做算术解析器，不会写XML解析器，但是满天下都是现成的东西可以用的，比之我们当时，要自己写，或者用YACC配置一个，真是天上地下的差别。
家园 那php的资源简直就是泛滥成灾了 你找个优秀的java论坛源码来看看
家园 php的web应用资源多过java有原因的 准确的说，某些web方面的开源应用（cms，论坛，简单电子商务应用）和部署、维护以及二次开发的难易程度有关，和host资源的多寡以及价格有关，这几项因素往往会超越技术层面成为决定因素。php在某种意义上说，是web开发的领域语言，其 dirty and quick的编码模式、低伸的学习曲线、相对价廉的外包开发资源，这些都很对web应用用户群的胃口，而且host资源多且便宜，所以在这些web应用开始在网络上流行的时候，php占了很大的优势，也就积累了极大资源优势。
但是发展的看，这些web应用逐渐成长，在应用的深度和广度上都开始进化，在二次开发的难度、伸缩性这些技术层面纷纷面临一些瓶颈，所以现在的web开发和应用开始出现变数，php自身在进化，从php5开始，OO和相对重量级的开发方法在语言层面开始慢慢得到支持，开发方面，大量的框架开始出现，散乱的“直写”方法不再被推荐，php的开发者开始注重工程方面的东西，同时，python,ruby 为代表的动态语言也登上舞台，django、ruby on rails走到了聚光灯下面，host资源也越来越多，吸引了一批php和java的程序员，尤其是java的程序员，rails的热度很大程度是java程序员扯起来的。从java本身来说，现有的比较通行的使用ssh搭建web应用，还是略嫌厚重了一点，现在很多人多在对java越来越重的状况开始反思，所以小羊觉得，web应用的开发，乱世刚起，也许静观一段时间才能分辨出真正的王者，也许根本就是诸侯争霸，没有王者，又或者，他们会在web开发的M,V,C，前台或者后台纷纷找到自己的位置，从此和谐相处过着幸福的生活。
家园 国外的资源共享很少用论坛 都是maillist多
家园 C/C++的资源比Java少吗? 我怎么一点都没有觉得. 现在我就在充当一个java项目组的技术管理者, 除了不直接写代码之外, 其它的事情也都管. (说这些是表明咱不是个java盲
)没有觉得java资源比C/C++多啊, 从人气上讲, java的几个framework显然热闹一点, 可是其中的原因我想也和java下面高质量的framework本来就少也有一点关系吧. 看看sourceforge, 从数量上和覆盖的范围上讲, C/C++的资源更多吧.
再看看PHP, 各类framework满天飞, 要说单独哪个的人气, 恐怕都不如java下的, 但是好在从低到高, 从简单到复杂全有, 而且很容易裁剪.
java下编程动辄要使用framework, 这些framework一个比一个庞大, 一个比一个难以裁剪. 由于使用java变成使用framework, 因此学习java也变成学习framework了, (前一阵我面试java程序员, 直接问你们熟悉哪些framework). 想想真没啥意思.
java现在越来越像.NET, framework背后都是企业而且是大企业在支持, 新的来自草根的framework如何出头?出头的难度太大, 于是很多情况下就直接放弃, 回到亦步亦趋地跟随那寥寥几个framework的道路上去. 我现在越来越不看好java了, 10年前我的毕业设计是用JDK1.0.2完成的, 那时候的java真是充满了活力.
家园 你对Java Framework的理解不对 衡量一个Framework是否有效，主要是看他能不能快速有效可靠地解决实际问题，而不是什么fancy的idea。Ruby on Rails我就没看到美国哪家银行用来做自己的业务系统。
framework是供你快速开发用的，基本上提供了一个模板，或者你也可以用一个公共的模板（比如Spring的Step-by-step那个），快速地实现你的业务逻辑（直接在里面加）。当然如果说到debugging那是另外一回事。
framework里面的代码都是经过大家大规模使用测试过的，实现相同的功能，比你自己写的东西可靠吧？而且比如ORM这样的东西，你有必要自己写吗。Hibernate4万多行程序，你自己写，自己
没有必要为了变化而变化。
家园 兄弟，话说太满了 framework里面的代码都是经过大家大规模使用测试过的，实现相同的功能，比你自己写的东西可靠吧？而且比如ORM这样的东西，你有必要自己写吗。Hibernate4万多行程序，你自己写，自己2000年那会儿，在北京写JAVA的程序员，谁要不自己写个ORM的库，好意思说自己是大牛吗？手下的程序员能拢得住吗？
在某个库被大众接受之前，肯定是牛就要写一个自己的framework的。因为不写framework，手下程序员就会四处乱跑，追都追不上
而且，写个framework也没你说这样难，象Hibernate、Struts核心就几百行、上千行代码吧，稍微有点儿理想的程序员就能搞定。即使是EJB容器，用动态代理的话，几百行代码也能搞定核心功能
- 复 兄弟，话说太满了
家园 2000年做ORM， 有性格 BCEL是2001年10月才加到Apache，难道真的有大牛已经在2000年做AOP了?
家园 记忆里是这样的 当时，大家已经认识到在Servlet里真接写JDBC是不好的，中间应该有个ORM层。
但当时并没有公认的解决方案，Hibernate还没影呢。我记得较早的一个是Turbine里的Torque。
这时候，一个团队里的大牛，如果不挺身而出写个ORM库的话，程序员是不会乖乖地把JDBC封装在Servlet之外的。而且这种团队内用的、简单的ORM并不需要很多代码，更多时更象一种Helper类。
而且，我即使现在还在用这样的薄薄的ORM层。可控、灵活，出现异常、或性能不足的话，直接查JDBC多简单、时尚啊:)
再加一点：我会把这个ORM层的写法教给程序员，新来的会很爱学，并有成就感。团队里，这非常重要！
- 复 记忆里是这样的
家园 这个玩艺我也做过一个.net实现的 零五年左右做的，很晚很晚。没招儿，跟您二位比不得。那是也才刚毕业嘛。
也是一半像helper,一半像hibernate。
最早写这个的灵感是公司买了一套代码，类似hibernate,然后看看加了访问控制，用sqlserver的role,approle和自己拼查询条件各实现了一次。从这开始就不能跨数据库了。（做.net的跨啥库啊，嘿嘿）
后来开始接小网站的活了，为了适应托管网站的条件，减少配置时间。给每个实体加了大量的元数据自动快速建表建视图，分配角色权限（网站的角色没集中），精简了配置，把详细配置数据和代码紧紧贴
再然后加了一堆接口，给每个实体增加建表，备份等功能。
考虑到hibernate操作实体类麻烦，我还留了一大堆位置能直接传sql,字段表明从对着的元数据里挑，反正跨不了平台了，可劲造。linq比较无耻，他竟然有办法增加语法，让编译器读懂sql,我不服我不服我不服。。。
还被大伙攻击为本来把存储和实现分开就是个进步，你咋又倒回去了。我说我就想适度降低自由度嘛。。。。linq学我做什么dependency。。。
再然后熊仔意外的碰上虚拟机这种每天可以做n个，干掉n个的工作环境，发现还是有点好处的，又不想学linq，拿着自己的这个小玩意用在乱七八糟的
自打以后不写数据库程序了，就写一篇浅薄之作供老鸟们笑笑。
- 复 记忆里是这样的
家园 2000年左右ejb还是主流，一堆的人排着队往里面装 项目里不弄个啥cmp，你都不好意思跟别人说你是搞java，这破风气好像一直到2005年，某个号称中国java第一人的家伙还无耻的说，不玩ejb的项目就不是真正j2ee项目。
不过也就是那个前后确实有不少人搞一些简单的orm工具，我自己也写过一个。另外还有so搞笑的，某人号称精通此道，资本就是也写过一个orm工具，问题是丫到现在连数据库外键会影响性能不止，如何写转职sql不知，总之一堆数据库的基本概念不清楚。所以么。。 会写orm，听听就好了
家园 那啥ORM,也就是 iBatis一类的简单ADO+SQL Mapping之类。不是说approach不对，但是这个和Hibernate之类的纯OO方法，难度不一样吧？
家园 看您的帖子, 大致可以明白也是个照葫芦画瓢的主 真服了您了, 我从framework developer角度写的东西, 您居然从一个framework user的角度来批评, 还批评得那么自信.
Ruby on Rails我就没看到美国哪家银行用来做自己的业务系统。美国银行咱没见过, 您牛, 您是见过美国银行的人. 原来您评价一个技术"能不能快速有效可靠地解决实际问题"的依据是美国银行有没有用来做自己的业务系统, 那可供您评价的选择也不多啊. 而且我严重怀疑您现在用着的framworks(想了半天还是加上个s吧)美国银行有没有用来做自己的业务系统.
而且比如ORM这样的东西，你有必要自己写吗。Hibernate4万多行程序，你自己写，自己您要是为了打工混口饭吃, 确实没必要自己写一个. 费那劲干什么? 运行速度慢? 加内存呗! 效率低? 硬件升级呗! 4万行程序, 那是多大的一个天文数字, 远远超过您从开始工作到现在为止写过的有效代码行数的总和. 唉, 还是别去碰了, 照葫芦画瓢吧.
别怪我口气冲, 我就烦你这样的, 上来先下个断言, "你对Java Framework的理解不对", 中间一堆初学者感言, 最后装个B, 说句半哲不哲的废话: "没有必要为了变化而变化". SUN!