ÎÒ¾õµÃÕâ¸öÊÀ½çÉϵijÌÐò <http://dev.yesky.com/>Ա
¿ÉÒÔ·ÖΪÁ½ÖÖ:"Ö÷¶¯³ÌÐòÔ±"ºÍ"±»¶¯³ÌÐòÔ±"¡£"Ö÷¶¯³ÌÐòÔ±"¿ÉÒÔ×Ô¼ºÑ¡Ôñ¿ª·¢·½Ê½£¬¿ª·¢ÓïÑԺͿò¼Ü£¬"±»¶¯³ÌÐòÔ±"±»¶¯½ÓÊܹ«Ë¾Ö¸¶¨µÄÓïÑԺͿª·¢·½
ʽ¡£ÆäʵÔÚÏÖʵÉú»îÖУ¬ÕâÖÖ·ÖÀಢ²»¾ø¶Ô£¬Ò»¸ö³ÌÐòÔ±¿ÉÄÜÔÚ²»Í¬µÄʱºòµ£µ±²»Í¬µÄ½ÇÉ«£¬"±»¶¯³ÌÐòÔ±"Ò²¿ÉÄÜÏíÓÐÓÐÏÞµÄÖ÷¶¯È¨¡£Õâô·ÖÀಢ²»ÒÔ³ÌÐòÔ±±¾Éí
µÄÖªÃû¶È£¬²Æ¸»¶àÉÙ£¬ÊÇ·ñ×Ô¼º´´Òµ»¹ÊÇÊܹÍÓÚÈËÓйء£

David Heinemeier Hansson ÊܹÍÓë 37 Signal £¬µ«ÊÇÈÔÈ»¿ÉÒÔ×Ô¼ºÑ¡Ôñ½¨Á¢×Ô¼ºµÄ Rails
¿ò¼ÜÀ´Íê³ÉÏîÄ¿£¬ËûÓ¦¸ÃËãÊǸö"Ö÷¶¯³ÌÐòÔ±"¡£Firebird Êý¾Ý¿âµÄÁìµ¼ÕßͬʱҲÊÇ Interbase Êý¾Ý¿âµÄ´´Ê¼ÈË Jim Starkey
½«×Ô¼ºµÄ¹«Ë¾Âô¸øÁË Mysql AB ¶ø²»µÃ²»¸ø Mysql
¸É»î£¬´Óij·½Ãæ˵£¬ËûÓ¦¸ÃÊǸö"±»¶¯³ÌÐòÔ±"¡£´ó¶àÊýµÚÈýÊÀ½ç¹ú¼ÒµÄ³ÌÐòÔ±Ó¦¸ÃÊôÓÚ"±»¶¯³ÌÐòÔ±"£¬ËûÃDZà³ÌÖ»ÊÇΪÁËÒ»·ÝÑø¼Òºý¿ÚµÄ¹¤×÷£¬ËûÃÇÎÞȨѡÔñ×Ô
¼ºÏ²»¶µÄ±à³ÌÓïÑÔ»òÕß¿ò¼Ü£¬ÒòΪÕâÊǹ«Ë¾¸øËûÑ¡ÔñµÄ£¬ÒòΪÈç¹ûÑ¡ÁËÆäËû£¬Ëû¿ÉÄܾÍÕÒ²»µ½¹¤×÷ÁË¡£Ôø¾­Óиö¼´½«ÀëÖ°µÄͬÊÂÈÃÎÒ¸øËûÍƼöÒ»¸ö±È½ÏºÃµÄ±à³Ì¿ò
¼Ü£¬¿ÉÒÔºÜÈÝÒ×Íê³ÉÒ»¸öÍøÕ¾µÄÖÆ×÷£¬ÎÒ¸øËûÍƼöÁË Zope, »¹ÓÐ Rails, ËûÌýÎҵĽéÉܾõµÃ²»´í £¬µ±ÎÒ¸æËßËû±ØÐëѧϰ python ºÍ Ruby
±à³ÌÓïÑÔʱ£¬ËûÏԵúܾªãµ£¬"ÄÇÄÜÕÒµ½¹¤×÷Âð?"¡£Õâ»°ÆäʵҲ±í´ïÁË´ó¶àÊý¹úÄÚ³ÌÐòÔ±µÄÏë·¨¡£¿´¿´ÕÐƸÍøÕ¾¾ÍÖªµÀ£¬ÏÖÔÚ×îÐèÒªµÄ³ÌÐòÔ±ÊÇ
Java<http://dev.yesky.com/devjava/>³ÌÐòÔ±£¬×îÐèÒªÁ˽âµÄ¿ò¼ÜÊÇ
Struts¡£Èç¹û²»»áÄãºÜÄѵõ½ÃæÊԵĻú»á£¬ËùÒÔ¾ÍËãÄã²»»áÒ²ÒªÔÚ×Ô¼ºµÄ¼òÀúÖÐ"ÐÞÊÎ"һϡ£

ÓÐЩ×Ô¼º´´ÒµµÄÈË¿ÉÒÔ×Ô¼ºÑ¡Ôñϲ»¶µÄ±à³ÌÓïÑԺͿò¼Ü£¬µ±È»ÄDZϾ¹ÊÇÉÙÊý¡£Èç¹ûÎÒÄܹ»Ñ¡ÔñµÄ»°£¬Îҿ϶¨²»Óà Java
À´×öÍøÕ¾Ó¦Óá£ÒòΪËüÍê³ÉÒ»¸ö¼òµ¥µÄ¹¤×÷Ì«Âé·³ÁË£¬ºÜÄÑ¿ìËÙÊÊÓ¦ÐèÇóµÄ±ä»¯¡£µ±È»ÎÒÒ²²»»áÈ¥Óà PHP £¬ÒòΪÎÒÒѾ­Ï°¹ßÁËÃæÏò¶ÔÏóµÄ±à³Ì·½Ê½ÁË¡£
ÎÒ·¢ÏÖÒ»¸öÆæ¹ÖµÄÏÖÏó:´ó¶àÊýתÏòѧϰ Ruby on rails ¿ò¼ÜµÄÈ˶¼ÊÇÀ´×Ô Java ÕóÓªµÄ³ÌÐòÔ±£¬¶øתÏòPython
¿ò¼ÜZope£¬django µÄ³ÌÐòÔ±´ó¶àÓÐ ASP,PHP ±³¾°¡£ÒòΪ Ruby ÊÇÒ»¸öÕæÕýµÄÃæÏò¶ÔÏóµÄÓïÑÔ£¬ Ëüͬʱ¾ß±¸Á˽ű¾ÓïÑÔµÄÌص㣬¶ø
Python Ê×ÏÈÊÇÒ»¸ö½Å±¾ÓïÑÔ£¬Ëü¾ß±¸ÁËһЩ OO µÄÌØÕ÷¡£Java ³ÌÐòÔ± ºÜÄÑÈÌÊÜ×ß»Øͷ·£¬ËùÒÔËûÃÇÑ¡ÔñÁËÒ»¸ö±ÈJava¸üÃæÏò¶ÔÏóµÄÓïÑÔ Ruby
£¬¶øPHP,ASP³ÌÐòԱûÓÐÄÇôÖصÄ˼Ï븺µ££¬ËûÃÇÑ¡Ôñ Python ¿ÉÄÜÊÇÒòΪËüµÄ´úÂë¸ü Beauty
£¬Ô¶±ÈËûÃÇÒÔǰдµÄ"Òâ´óÀûÃæÌõ"ʽµÄPHP,ASP ´úÂëÒª¸É¾»µÄ¶à¡£

ÎÞÂÛÊÇ python, »¹ÊÇ Ruby ÕâЩ·ÇÖ÷Á÷³ÌÐòÓïÑÔ¿ª·¢µÄ¿ò¼Ü£¬Ê¹ÓÃÆðÀ´¶¼Òì³£µÄ¼ò±ã£¬ËûÃÇ¿ÉνÊÇÕæÕý´Ó³ÌÐòÔ±½Ç¶È¿¼ÂǵĿò¼Ü¡£ÎªÊ²Ã´ Ruby
Ò»³ö£¬½ÁµÄ Java µÄÊÀ½çһƬ»ìÂÒ£¬ÎÒÏëÔ­Òò»¹ÊdzöÔÚ Java ÕâÀµ± Java ³ÌÐòÔ±Ï뵱ȻµØÈÏΪ³ÌÐò¿ª·¢Ó¦¸ÃÈç´ËÂé·³µÄʱºò£¬Rails
µÄ³öÏÖÈÃËûÃÇÁ¢¿Ì¾õµÃ±»ÕâЩËùνµÄ Java Á÷Ðпò¼ÜºÍ Sun ¸øÆÛÆ­ÁË£¬ÕâÖÖÆÛÆ­ÊÇÈç´ËÖ®ÉÒÔÖÁÓÚËûÃÇÖмäÓеÄÈË"Í·Ò²²»»Ø"µÄÀ뿪ÁË Java,
ת¶ø¹¥»÷ Java µÄÖÖÖÖ²»ÊÇ¡£ÕâÆäÖбȽÏÓÐÃûµÄÈ˾ÍÊÇ Bruce Tate £¬ÕâλÀÏÐÖдÁËÁ½±¾ºä¶¯ Java ÊÀ½çµÄÊ飬Spring: A
Developer's Notebook ºÍ Better, Faster, Lighter Java (¸ÃÊé¿ÉÊÇ»ñµÃ Jolt
´ó½±µÄ£¬Ç¡ºÃÎÒ»¹¶¼¶Á¹ý)£¬Ëæ×Å Rails µÄÁ÷ÐУ¬ÕâλÈÊÐÖÁ¢¿ÌÅÑÌÓ³ö Java ÕóÓª£¬Ð´ÁË Beyond Java Ò»Ê飬×ÅÖؽéÉÜÁËһЩ·ÇJava
¿ò¼Ü£¬±ÈÈç Smalltalk µÄSeaside, ºÍ Rails¡£

Java ΪʲôÕâô¸´ÔÓ£¬ÎÒÏëÁ˺ܾ㬵óöÕâô¸ö½áÂÛ:ÕâÊÇÒòΪ Sun Ï£ÍûËüÄÇô¸´ÔÓ¡£ÎªÊ²Ã´Õâô˵ÄØ?Sun
²»ÊÇÒ»¸öºÃµÄÈí¼þ¹«Ë¾£¬Ëü×îÉó¤×öµÄÊÇÖƶ¨¹æ·¶£¬ÕâºÜÀàËÆJava ±à³ÌÖÐµÄ Interface, ¾­³£±àд Java ³ÌÐòµÄÈË£¬»á·¢ÏÖ Interface
¿ÉÄÜÊdzöÏÖ×î¶àµÄÒ»¸ö´Ê»ãÁË£¬Èκοò¼ÜÖж¼³äÂúÁËInterface ¡ª½Ó¿Ú£¬´ó¶àÊý±à³ÌÊ鶼ÍƼöÃæÏò½Ó¿Ú±à³Ì(µ±È»Õâ²»ÊÇJavaµÄ´í£¬ÊÇÉè¼ÆģʽҪÇóµÄ£¬²»¹ý
Java ½«´Ë·¢»ÓµÄ×îºÃ)¡£Ê×Ïȶ¨Òå½Ó¿Ú£¬È»ºóÕë¶Ô½Ó¿Ú±àд²»Í¬µÄʵÏÖ£¬ÖÁÉÙÌṩĬÈϵÄʵÏÖ¡£Sun Ò²ÊÇÈç´Ë£¬¿´¿´ J2ee µÄ¹æ·¶°üº¬Á˶àÉÙ J
´òÍ·µÄ¼¼Êõ£¬ JDBC,JNI,JCA,JDO,JPA .... £¬ÏÖÔÚµÄ JCP ×éÖ¯¸ü¼ÓÈç´Ë£¬Ã¿¸ôÒ»¶Îʱ¼ä£¬¾ÍÓдóÁ¿µÄ¹æ·¶ÎÊÊÀ£¬Draft µÄ£¬»¹ÊÇ
Final µÄ£¬³ä³â×ÅJava ÊÀ½ç£¬ÕâÊÇ Sun Ï£ÍûµÄ£¬ ÿ¶¨ÒåÒ»¸ö¹æ·¶£¬¾Í»áÓкܶ೧ÉÌÀ´ÊµÏÖËü£¬Java µÄÈí¼þÊг¡¾Í×ö´óÁË£¬ÕâÑù Sun
¾Í¿ÉÒÔ¿¿ÊÚȨ£¬ÈÏÖ¤Äøü¶àµÄÇ®£¬Äã¿´ Sun µÄ¹ÉƱÄÇôµÍÃÔ£¬¶øÈ´ÓµÓÐÄÇôÐÛºñµÄÁ÷¶¯×ʽð£¬Ô­ÒòÔÙÃ÷°×²»¹ýÁË£¬Ö»Òª Sun »¹ÓµÓÐ Java
£¬Ëü¾ÍÓµÓÐÁËÒ»ÇС£

Sun Ï£Íû Java ±äµÃ¸´ÔÓ£¬¾ÍÈçͬ³ÌÐòԱϣÍû Perl ´úÂëÄÑ¿´Ò»Ñù£¬ÕâÑù×öÊÇ¿ÉÒÔ´øÀ´ºÃ´¦µÄ¡£Java
µÄ¸´ÔÓÐÔÒ²´øÀ´Á˲úÒµÁ´ÉÏÆäËûÐÐÒµµÄ·±ÈÙ£¬±ÈÈç×Éѯ£¬ÔÚ Php £¬Perl Á÷ÐÐ Internet µÄÄê´ú£¬ÍøÕ¾¿ª·¢Ëƺõ»¹²»ÐèÒª×Éѯʦ£¬°üÀ¨ C/S
Ê¢ÐеÄʱºò£¬ÆóÒµ¿ª·¢Ò²²»ÐèÒª×Éѯʦ£¬È»¶øËæ×Å J2EE
Öð²½Ö÷Ô×ÆóÒµ¼¶¿ª·¢£¬×ÉѯÐÐÒµÒ²¿ªÊ¼ÐËÍúÆðÀ´¡£ÆóÒµ´ó°Ñ´ó°ÑµÄ°ÑǮͶÈëµ½¿ª·¢×ÉѯÖУ¬¾¿¾¹Ð§¹ûÈçºÎ£¬²»µÃ¶øÖª¡£ÎÒÏë¶Ô´ó¶àÊý³ÌÐòÔ±£¬ÓÈÆäÊÇÄÇЩÓÐ×Ô¼ºÏë·¨
µÄ³ÌÐòÔ±À´Ëµ£¬ÇëÇó×Éѯ¹«Ë¾£¬»¹²»Èç×Ô¼ºÈ¥Á˽âÀ´µÃÇå³þ¡£Èí¼þ¿ª·¢×ÉѯʦÔÚÎÒ¿´À´£¬ÓеãÏóÊÇ"ÂÉʦ"¡ª"´ú±íÌ°À·µÄ¹«Ë¾£¬ÈÃÕâ¸öÊÀ½ç±äµÃ¸üÔã¸âһЩ"(ÖÐ
Alex
µÄ¶Ô°×)¡£Èç¹û˵¹úÍâµÄ×ÉѯʦÊÇÏ£Íûͨ¹ýÖ÷¹ÛµÄŬÁ¦À´½â¾ö¿Í¹Û´æÔڵĿª·¢¸´ÔÓÐԵĻ°£¬ÄÇô¹úÄÚµÄ×ÉѯÐÐÒµ¿ÉÄÜ°ÑÔ­±¾¸´ÔÓµÄÈí¼þ¿ª·¢±äµÃ¸ü¼Ó¸´ÔÓÁË¡£ÎÒ²»Ïà
ÐÅËûÃÇ£¬ÎÒÄþ¿ÉÑ¡Ôñij¸öÈí¼þµÄÅàѵ£¬¶ø²»Ï£ÍûÓÐÈËÀ´´ÓÍ·µ½Î²Ö¸µãÄãÈçºÎ¿ª·¢£¬ÒòΪ¹úÄÚ×ÉѯʦµÄˮƽ±ÈÄã´ÓÊé±¾ÉÏÁ˽âµÄ¸ß²»µ½ÄÄÀïÈ¥£¬¹«Ë¾Óֺαػ¨·ÑÕâ±ÊÔ©
Í÷Ç®ÄØ¡£

ÄÇôÈç¹ûÄãÊǸö"Ö÷¶¯³ÌÐòÔ±"£¬Äã»á¸ú×Å Sun µÄÖ¸»Ó°ô×ßÂð? ÎÒÏëÀ뿪 Java ÊÀ½ç£¬ÄãÑ¡ÔñµÄ»ú»áÓ¦¸ÃºÜ¶à£¬µ«ÊÇÇ°ÌáÊÇ:ÄãÔ¸²»Ô¸ÒâÀ뿪 Java
¡£ÒòΪ´ó¶àÊýÈ˾õµÃ¸Ä±äÏÖ×´Æäʵ²¢²»ÊǸöºÃÊÂÇ飬ѧϰһ¸öÐÂÓïÑԺͿò¼ÜÒâΪ×ÅÄã¹ýÈ¥ËùÓеľ­Ñé¾ÍÏûʧÁË£¬ÕâÆäÖÐÓзçÏÕ¡£¶Ô´ó¶àÊý³ÌÐòÔ±
À´Ëµ£¬±à³ÌÆäʵ¾ÍÊǷݹ¤×÷£¬¸úÂôºÐ·¹£¬×°»úÆ÷ûʲôÇø±ð£¬Ö»Òª¸ãºÃ±¾Ö°¹¤×÷¾Í¿ÉÒÔ¡£ÊÔͼ¸Ä±äÏÖ×´µÄÈ˺ÜÍ´¿à£¬Á˽â²îÒìµÄÈËÒ²ÊÇÈç´Ë£¬¾ÍÈçͬ Neo
ÔÚ½ÓÊܺìÒ©ÍèºÍÀ¶Ò©Íè¡£

ÎÒÔÚµ±Äêѧϰ Perl µÄʱºòÔø¾­Âò¹ýÒ»±¾¡¶Learning perl¡·£¬ÊéµÄ×÷ÕßÔø¾­Õâô˵£¬Ñ§Ï° Perl ÊÇΪÁËÈÃ×Ô¼º°Ñ¸ü¶àµÄʱ¼äÓÃÔÚÈ¥»¬Ñ©£¬
PHP µÄ´´Ê¼ÈË Rasmus Lerdorf
Ò²Ôø¾­ÕâÑù±íʾ¹ý£¬ËûÏ£Íû×Ô¼ºÄܹ»¼õÉÙ¶¢×ŵçÄÔµÄʱ¼ä£¬¿ÉÊÇÕâô¶àÄê¹ýÈ¥ÁË£¬Ëû·¢ÏÖ×Ô¼º»¹ÊÇÒª¼ÌÐø¶¢×ŸÃËÀµÄµçÄÔ¡£ÆäʵÎÒ¶ÔÑ¡Ôñ¿ò¼ÜÓïÑÔÒ²²¢Ã»Ê²Ã´ÐËȤ£¬
ÎÒÖ»ÊÇÏ£ÍûÄܹ»ÒÔ¼òµ¥µÄ·½Ê½Íê³É¹¤×÷£¬¶ø°Ñʱ¼äÊ¡ÏÂÀ´È¥ÌýÌýÒôÀÖ£¬¿´¿´µçÓ°¡£Êµ¼ÊÉÏÎÒ¸ú²»Ï£Íû¸Ä±äÏÖ×´µÄÈËûʲô²»Í¬£¬ËûÃDz»Ï£ÍûѧϰеĶ«Î÷£¬ÒòΪÏÖÓÐ
µÄ¶«Î÷ºÜÊìϤÁË£¬Ñ§Ï°Ð¿ò¼Ü£¬»¹²»Èç°Ñʱ¼ä·Åµ½ÍæÉÏÈ¥£¬ÎÒµÄÄ¿µÄÒ»Ñù£¬ÎÒѧϰֻÊÇÏ£Íû×Ô¼ºµÄ¹¤×÷¸üÇáËÉÒ»µã£¬ÕâÑù¿ÉÒÔÓøü¶àµÄʱ¼äÀ´Íæ¡£ËùÒÔÿµ±ÎÒ¿´µ½¸÷
ÖÖ¼¼ÊõÂÛ̳Éϳä³â×ÅJava, .net , ROR £¬Python
Ö®ÀàµÄÕù³³£¬ÎÒ¶¼¾õµÃºÜºÃЦ¡£ÆäʵΪÁËά»¤Ò»¸öÓïÑÔ¶øÕù³³×îûÓÐÒâÒå¡£±à³ÌÓïÑԾͺÍÓ¢Ó¼ÆËã»úÒ»Ñù£¬¾ÍÊǸö¹¤¾ß£¬Ñ¡ÔñËüÃÇÖ»ÊÇΪÁ˾¡¿ÉÄܼòµ¥µØÍê³É¹¤
×÷£¬Ìá¸ßÉú»îÖÊÁ¿¡£ÎªÁËÓïÑÔ¶øÓïÑÔ£¬ÎªÁË¿ò¼Ü¶ø¿ò¼Ü¶¼ÊÇû±ØÒªµÄ¡£"Ö÷¶¯³ÌÐòÔ±"¿ÉÒÔÑ¡Ôñ×Ô¼ºµÄ·½Ê½À´¹¤×÷£¬ÕâÊÇ´ó¶àÊýÈË×ö²»µ½µÄ¡£Èç¹ûÓпÉÄÜ£¬ÎÒҲϣÍû
×öÒ»¸ö"Ö÷¶¯³ÌÐòÔ±"¡£
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/7af29da3/attachment.html 

so great!一言成箴！
红丸兰丸？没有对錯 ，只有信念！

On 3/10/07, BiFF <qq274980在gmail.com> wrote:
>
>
> 　　我觉得这个世界上的程序员
> 可以分为两种:"主动程序员"和"被动程序员"。"主动程序员"可以自己选择开发方式，开发语言和框架，"被动程序员"被动接受公司指定的语言和开发方
> 式。其实在现实生活中，这种分类并不绝对，一个程序员可能在不同的时候担当不同的角色，"被动程序员"也可能享有有限的主动权。这么分类并不以程序员本身
> 的知名度，财富多少，是否自己创业还是受雇于人有关。
>
> 　　David Heinemeier Hansson 受雇与 37 Signal ，但是仍然可以自己选择建立自己的 Rails
> 框架来完成项目，他应该算是个"主动程序员"。Firebird 数据库的领导者同时也是 Interbase 数据库的创始人 Jim Starkey
> 将自己的公司卖给了 Mysql AB 而不得不给 Mysql
> 干活，从某方面说，他应该是个"被动程序员"。大多数第三世界国家的程序员应该属于"被动程序员"，他们编程只是为了一份养家糊口的工作，他们无权选择自
> 己喜欢的编程语言或者框架，因为这是公司给他选择的，因为如果选了其他，他可能就找不到工作了。曾经有个即将离职的同事让我给他推荐一个比较好的编程框
> 架，可以很容易完成一个网站的制作，我给他推荐了 Zope, 还有 Rails, 他听我的介绍觉得不错 ，当我告诉他必须学习 python 和 Ruby
> 编程语言时，他显得很惊愕，"那能找到工作吗?"。这话其实也表达了大多数国内程序员的想法。看看招聘网站就知道，现在最需要的程序员是
> Java 程序员，最需要了解的框架是
> Struts。如果不会你很难得到面试的机会，所以就算你不会也要在自己的简历中"修饰"一下。
>
> 　　有些自己创业的人可以自己选择喜欢的编程语言和框架，当然那毕竟是少数。如果我能够选择的话，我肯定不用 Java
> 来做网站应用。因为它完成一个简单的工作太麻烦了，很难快速适应需求的变化。当然我也不会去用 PHP
> ，因为我已经习惯了面向对象的编程方式了。 我发现一个奇怪的现象:大多数转向学习 Ruby on rails 框架的人都是来自 Java
> 阵营的程序员，而转向Python 框架Zope，django 的程序员大多有 ASP,PHP 背景。因为 Ruby 是一个真正的面向对象的语言，
> 它同时具备了脚本语言的特点，而 Python 首先是一个脚本语言，它具备了一些 OO 的特征。Java 程序员
> 很难忍受走回头路，所以他们选择了一个比Java更面向对象的语言 Ruby ，而PHP,ASP程序员没有那么重的思想负担，他们选择 Python
> 可能是因为它的代码更 Beauty ，远比他们以前写的"意大利面条"式的PHP,ASP 代码要干净的多。
>
> 　　无论是 python, 还是 Ruby
> 这些非主流程序语言开发的框架，使用起来都异常的简便，他们可谓是真正从程序员角度考虑的框架。为什么 Ruby 一出，搅的
> Java 的世界一片混乱，我想原因还是出在 Java 这里，当 Java 程序员想当然地认为程序开发应该如此麻烦的时候，Rails
> 的出现让他们立刻觉得被这些所谓的 Java 流行框架和 Sun
> 给欺骗了，这种欺骗是如此之深，以至于他们中间有的人"头也不回"的离开了 Java, 转而攻击 Java
> 的种种不是。这其中比较有名的人就是 Bruce Tate ，这位老兄写了两本轰动 Java 世界的书，Spring: A Developer's
> Notebook 和 Better, Faster, Lighter Java (该书可是获得 Jolt 大奖的，恰好我还都读过)，随着 Rails
> 的流行，这位仁兄立刻叛逃出 Java 阵营，写了 Beyond Java 一书，着重介绍了一些非Java 框架，比如 Smalltalk
> 的Seaside, 和 Rails。
>
> 　　Java 为什么这么复杂，我想了很久，得出这么个结论:这是因为 Sun 希望它那么复杂。为什么这么说呢?Sun
> 不是一个好的软件公司，它最擅长做的是制定规范，这很类似Java 编程中的 Interface, 经常编写 Java 程序的人，会发现 Interface
> 可能是出现最多的一个词汇了，任何框架中都充满了Interface
> —接口，大多数编程书都推荐面向接口编程(当然这不是Java的错，是设计模式要求的，不过 Java
> 将此发挥的最好)。首先定义接口，然后针对接口编写不同的实现，至少提供默认的实现。Sun 也是如此，看看 J2ee
> 的规范包含了多少 J 打头的技术， JDBC,JNI,JCA,JDO,JPA .... ，现在的 JCP
> 组织更加如此，每隔一段时间，就有大量的规范问世，Draft 的，还是 Final 的，充斥着Java 世界，这是 Sun 希望的，
> 每定义一个规范，就会有很多厂商来实现它，Java 的软件市场就做大了，这样 Sun 就可以靠授权，认证拿更多的钱，你看 Sun
> 的股票那么低迷，而却拥有那么雄厚的流动资金，原因再明白不过了，只要 Sun 还拥有 Java ，它就拥有了一切。
>
> 　　Sun 希望 Java 变得复杂，就如同程序员希望 Perl 代码难看一样，这样做是可以带来好处的。Java
> 的复杂性也带来了产业链上其他行业的繁荣，比如咨询，在 Php ，Perl 流行 Internet 的年代，网站开发似乎还不需要咨询师，包括 C/S
> 盛行的时候，企业开发也不需要咨询师，然而随着 J2EE
> 逐步主宰企业级开发，咨询行业也开始兴旺起来。企业大把大把的把钱投入到开发咨询中，究竟效果如何，不得而知。我想对大多数程序员，尤其是那些有自己想法
> 的程序员来说，请求咨询公司，还不如自己去了解来得清楚。软件开发咨询师在我看来，有点象是"律师"—"代表贪婪的公司，让这个世界变得更糟糕一些"(中
> Alex
> 的对白)。如果说国外的咨询师是希望通过主观的努力来解决客观存在的开发复杂性的话，那么国内的咨询行业可能把原本复杂的软件开发变得更加复杂了。我不相
> 信他们，我宁可选择某个软件的培训，而不希望有人来从头到尾指点你如何开发，因为国内咨询师的水平比你从书本上了解的高不到哪里去，公司又何必花费这笔冤
> 枉钱呢。
>
> 　　那么如果你是个"主动程序员"，你会跟着 Sun 的指挥棒走吗? 我想离开 Java 世界，你选择的机会应该很多，但是前提是:你愿不愿意离开 Java
> 。因为大多数人觉得改变现状其实并不是个好事情，学习一个新语言和框架意为着你过去所有的经验就消失了，这其中有风险。对大多数程序员
> 来说，编程其实就是份工作，跟卖盒饭，装机器没什么区别，只要搞好本职工作就可以。试图改变现状的人很痛苦，了解差异的人也是如此，就如同
> Neo 在接受红药丸和蓝药丸。
>
> 　　我在当年学习 Perl 的时候曾经买过一本《Learning perl》，书的作者曾经这么说，学习 Perl 是为了让自己把更多的时间用在去滑雪，
> PHP 的创始人 Rasmus Lerdorf
> 也曾经这样表示过，他希望自己能够减少盯着电脑的时间，可是这么多年过去了，他发现自己还是要继续盯着该死的电脑。其实我对选择框架语言也并没什么兴趣，
> 我只是希望能够以简单的方式完成工作，而把时间省下来去听听音乐，看看电影。实际上我跟不希望改变现状的人没什么不同，他们不希望学习新的东西，因为现有
> 的东西很熟悉了，学习新框架，还不如把时间放到玩上去，我的目的一样，我学习只是希望自己的工作更轻松一点，这样可以用更多的时间来玩。所以每当我看到各
> 种技术论坛上充斥着Java, .net , ROR ，Python
> 之类的争吵，我都觉得很好笑。其实为了维护一个语言而争吵最没有意义。编程语言就和英语，计算机一样，就是个工具，选择它们只是为了尽可能简单地完成工
> 作，提高生活质量。为了语言而语言，为了框架而框架都是没必要的。"主动程序员"可以选择自己的方式来工作，这是大多数人做不到的。如果有可能，我也希望
> 做一个"主动程序员"。
> _______________________________________________
> python-chinese
> Post: send python-chinese在lists.python.cn
> Subscribe: send subscribe to
> python-chinese-request在lists.python.cn
> Unsubscribe: send unsubscribe to
> python-chinese-request在lists.python.cn
> Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
>


-- 
'''Time is unimportant, only life important!
http://zoomquiet.org
blog在http://blog.zoomquiet.org/pyblosxom/
wiki在http://wiki.woodpecker.org.cn/moin/ZoomQuiet
scrap在http://floss.zoomquiet.org
douban在http://www.douban.com/people/zoomq/
____________________________________
Pls. use OpenOffice.org to replace M$ Office.
     http://zh.openoffice.org
Pls. use 7-zip to replace WinRAR/WinZip.
     http://7-zip.org/zh-cn/
You can get the truely Freedom 4 software.
'''

说得很好。

说的很好 ，不介意我转载吧

2007/3/10, Neil(木野狐) <chenrong2003 at gmail.com>:
>
> 说得很好。
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese




-- 
devdoer
devdoer at gmail.com
http://devdoer.blog.sohu.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/5e610b4e/attachment-0001.htm 

原创是谁啊？

在07-3-10，bird devdoer <devdoer at gmail.com> 写道：
>
> 说的很好 ，不介意我转载吧
>
> 2007/3/10, Neil(木野狐) <chenrong2003 at gmail.com>:
> >
> > 说得很好。
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
>
>
> --
> devdoer
> devdoer at gmail.com
> http://devdoer.blog.sohu.com/




-- 
devdoer
devdoer at gmail.com
http://devdoer.blog.sohu.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/c45b2375/attachment.html 

ÔΣ¬ÉÙÌùÁËÒ»ÐУ¬Ô­´´ÊÇIT168£¬µÈÎÒÔÙÕÒÕÒ

ÔÚ07-3-10£¬bird devdoer <devdoer在gmail.com> дµÀ£º
>
> Ô­´´ÊÇË­°¡£¿
>
> ÔÚ07-3-10£¬bird devdoer <devdoer在gmail.com> дµÀ£º
> >
> > ˵µÄºÜºÃ £¬²»½éÒâÎÒתÔØ°É
> >
> > 2007/3/10, Neil(ľҰºü) <chenrong2003在gmail.com>:
> > >
> > > ˵µÃºÜºÃ¡£
> > > _______________________________________________
> > > python-chinese
> > > Post: send python-chinese在lists.python.cn
> > > Subscribe: send subscribe to python-chinese-request在lists.python.cn
> > > Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> > >
> > > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> >
> >
> >
> >
> > --
> > devdoer
> > devdoer在gmail.com
> > http://devdoer.blog.sohu.com/
>
>
>
>
> --
> devdoer
> devdoer在gmail.com
> http://devdoer.blog.sohu.com/
>
> _______________________________________________
> python-chinese
> Post: send python-chinese在lists.python.cn
> Subscribe: send subscribe to python-chinese-request在lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/e44b9749/attachment.htm 

有点像转到我的博客上
>


-- 
--~--~---------~--~----~------------~-------~--~----~
Best Regards
JesseZhao(ZhaoGuang)

Blog : Http://JesseZhao.cnblogs.com
E-Mail : Prolibertine在gmail.com
IM(Live Messager) : Prolibertine在gmail.com
--~--~---------~--~----~------------~-------~--~----~

On 3/10/07, bird devdoer <devdoer在gmail.com> wrote:
> 原创是谁啊？
>
最早我在csdn上看过。
http://groups.google.com/group/python-cn/browse_thread/thread/b0d49319427a96c6/8cc6eae86e58be4a?lnk=gst&q;=%E4%B8%BB%E5%8A%A8%E7%A8%8B%E5%BA%8F%E5%91%98&rnum;=2#8cc6eae86e58be4a

-- 
I like python!
UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad
My Blog: http://www.donews.net/limodou

²»ÐУ¬ÉÏgoogle²éÁËһȦ£¬ÕÒ²»µ½Ô­´´×÷Õߣ¬Ó¦¸ÃÊÇ´ÓÀÏÍâÄÇÀïÒëÀ´µÄ

¹úÄÚºÜÄÑÓÐÈËÄܹ»Õ¾ÔÚÕâô¸ßµÄ¸ß¶È£¡£¡£¡

2007/3/10, limodou <limodou在gmail.com>:
>
> On 3/10/07, bird devdoer <devdoer在gmail.com> wrote:
> > Ô­´´ÊÇË­°¡£¿
> >
> ×îÔçÎÒÔÚcsdnÉÏ¿´¹ý¡£
>
> http://groups.google.com/group/python-cn/browse_thread/thread/b0d49319427a96c6/8cc6eae86e58be4a?lnk=gst&q;=%E4%B8%BB%E5%8A%A8%E7%A8%8B%E5%BA%8F%E5%91%98&rnum;=2#8cc6eae86e58be4a
>
> --
> I like python!
> UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad
> My Blog: http://www.donews.net/limodou
> _______________________________________________
> python-chinese
> Post: send python-chinese在lists.python.cn
> Subscribe: send subscribe to python-chinese-request在lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/bba0ba64/attachment.html 

http://www.javaeye.com/topic/24499

ÔÙ¿´¿´Õâ¸ö £ºruby on railsΪʲôÔÝʱÎÞ·¨³ÉΪÆóÒµÓ¦Óÿª·¢µÄÖ÷Á÷£¿ <http://www.javaeye.com/topic/24499>


ÔÚ07-3-10£¬BiFF <qq274980在gmail.com> дµÀ£º
>
> ²»ÐУ¬ÉÏgoogle²éÁËһȦ£¬ÕÒ²»µ½Ô­´´×÷Õߣ¬Ó¦¸ÃÊÇ´ÓÀÏÍâÄÇÀïÒëÀ´µÄ
>
> ¹úÄÚºÜÄÑÓÐÈËÄܹ»Õ¾ÔÚÕâô¸ßµÄ¸ß¶È£¡£¡£¡
>
> 2007/3/10, limodou <limodou在gmail.com>:
> >
> > On 3/10/07, bird devdoer <devdoer在gmail.com> wrote:
> > > Ô­´´ÊÇË­°¡£¿
> > >
> > ×îÔçÎÒÔÚcsdnÉÏ¿´¹ý¡£
> >
> > http://groups.google.com/group/python-cn/browse_thread/thread/b0d49319427a96c6/8cc6eae86e58be4a?lnk=gst&q;=%E4%B8%BB%E5%8A%A8%E7%A8%8B%E5%BA%8F%E5%91%98&rnum;=2#8cc6eae86e58be4a
> >
> > --
> > I like python!
> > UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad
> > My Blog: http://www.donews.net/limodou
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese在lists.python.cn
> > Subscribe: send subscribe to python-chinese-request在lists.python.cn
> > Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
>
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/71b2185f/attachment.html 

лл£¬·Ç³£ÊÜÒæ¡£

2007/3/10, BiFF <qq274980在gmail.com>:
>
> ²»ÐУ¬ÉÏgoogle²éÁËһȦ£¬ÕÒ²»µ½Ô­´´×÷Õߣ¬Ó¦¸ÃÊÇ´ÓÀÏÍâÄÇÀïÒëÀ´µÄ
>
> ¹úÄÚºÜÄÑÓÐÈËÄܹ»Õ¾ÔÚÕâô¸ßµÄ¸ß¶È£¡£¡£¡
>
> 2007/3/10, limodou <limodou在gmail.com>:
> >
> > On 3/10/07, bird devdoer <devdoer在gmail.com> wrote:
> > > Ô­´´ÊÇË­°¡£¿
> > >
> > ×îÔçÎÒÔÚcsdnÉÏ¿´¹ý¡£
> >
> > http://groups.google.com/group/python-cn/browse_thread/thread/b0d49319427a96c6/8cc6eae86e58be4a?lnk=gst&q;=%E4%B8%BB%E5%8A%A8%E7%A8%8B%E5%BA%8F%E5%91%98&rnum;=2#8cc6eae86e58be4a
> >
> > --
> > I like python!
> > UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad
> > My Blog: http://www.donews.net/limodou
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese在lists.python.cn
> > Subscribe: send subscribe to python-chinese-request在lists.python.cn
> > Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
>
> _______________________________________________
> python-chinese
> Post: send python-chinese在lists.python.cn
> Subscribe: send subscribe to python-chinese-request在lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request在lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>



-- 
            ´ËÉÏ.
            calf!
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/b49f9ed6/attachment.htm 

תһƪÎÒ¿´ºóºÜÓид¥µÄÎÄÕ¸ø´ó¼Ò

À´Ô´£ºhttp://www.hacknot.info/hacknot/action/showEntry?eid=90
Developers are from Mars, Programmers are from Venus 9 Oct 2006
 Permalink <http://www.hacknot.info/hacknot/action/showEntry?eid=90>
Printable<http://www.hacknot.info/hacknot/action/showPrintableEntry;jsessionid=CD3C4396D4F52A86D7DEE7EE6DDF04C7?eid=90>

Many of us use the terms "programmer" and "developer" interchangeably. When
someone asks me what I do for a living I tend to describe my vocation as
"computer programmer" rather than "software developer", because the former
seems to be understood more readily by those unfamiliar with IT. Even when
writing pieces for this site, I tend to swap back and forth between the two
terms, to try and avoid sounding repetitive. But in truth, there is a world
of difference between a computer programmer and a software developer.

The term "programmer" has historically referred to a menial, manual input
task conducted by an unskilled worker. Predecessors of the computer, such as
the Hollerith machine, would be fed encoded instructions by operators called
"programmers". Early electro-mechanical, valve and relay-based computers
were huge and expensive machines, operated within an institutional
environment whose hierarchical division of labor involved, at the lowest
level, a "button pusher" whose task was to laboriously program the device
according to instructions developed by those higher up the technical ladder.
So the programmer role is traditionally concerned only with the input of
data in machine-compatible form, and not with the relevance or adequacy of
those instructions when executed.

A modern programmer loves cutting code - and *only* cutting code. They
delight in code the way a writer delights in text. Programmers see their
sole function in an organization as being the production of code, and view
any task that doesn't involve having their hands on the keyboard as an
unwanted distraction.

Developers like to code as well, but they see it as being only a *part* of
their job function. They focus more on delivering value than delivering
program text, and know that they can't create value without having an
awareness of the business context into which they will deploy their
application, and the organizational factors that impact upon its success
once delivered.

More specifically ...
Developers have some knowledge of the domain and the business

Programmers like to stay as ignorant as possible of the business within
which they work. They consider the problem domain to be the realm of the
non-technical, and neither their problem or concern. You'll hear programmers
express their indifference to the business within which they operate - they
don't care if it's finance, health or telecommunications. For them, the
domain is just an excuse to exercise a set of programming technologies.

Developers view the business domain as their "second job." They work to
develop a solid understanding of those aspects of it that impact upon their
software, then use that knowledge to determine what the real business
problems are that the application is meant to be solving. They make an
effort get inside the heads of their user base - to see the software as the
users will see it. This perspective enables them to anticipate requirements
that may not have occurred to the users, and to discover opportunities to
add business value that the users may have been unaware was technically
possible.
Developers care about maintenance burden

Programmers crave new technologies the way children crave sweets. It's a
hunger that can never be satiated. They are forever flitting from one
programming language, framework, library or IDE to the next; forever gushing
enthusiastically about the latest silver bullet to have been grunted out by
some vendor or open source enthusiast, and garnished with naive praise and
marketing hype. They won't hesitate to incorporate the newest technology
into critical parts of their current project, for no reason other than that
it is "cool", and all the other kids are doing it. They will be so intent on
getting this new technology working, and overcoming the inevitable troubles
that immature technologies bring, that there will be no time to spare for
documentation of their effort. Which is exactly how they like it - because
documentation is, they believe, of no use to them. Sure, it might be useful
to future generations of programmers, but who cares about them?

Developers have a much more cautious approach to new technology. They know
that a new technology is inevitably hyped through the roof by those with a
vested interest in its success, but that the reality of the technology's
performance in the field often falls short of the spectacular claims made by
proponents. They know that a technology that is new is also unproven, and
that its weaknesses and shortcomings are neither well known or publicized.
They know that part of the reason it takes time for the negative experiences
with technologies to become apparent is that many developers will be
hesitant to say something critical amongst that first flush of community
enthusiasm, for fear that they will be shouted down by the newly-converted
zealots, or dismissed as laggards who have fallen behind the curve. So
developers know to stand back and wait for the hype to die down, and for
cooler heads to prevail. Developers also know the organizational chaos that
can result from too many changes in technical direction. A company can
quickly accumulate a series of legacy applications, each written in a host
of once-popular technologies, that few (if any) currently on staff possess
the skills to maintain and extend. Those that first championed those
technologies and forced them into production may have long since moved onto
other enthusiasms, perhaps other organizations, leaving behind the byproduct
of their fleeting infatuation as a maintenance burden for the organization
and future staff to bare.
Developers know that work methods are more important than technical chops

Programmers often focus so intently upon the technologies they use that they
come to believe that technology is the dominant factor influencing the
ultimate success or otherwise of their projects. The mind set becomes one of
constantly looking over the horizon for the next thing that might solve
their software development woes. The expectation becomes "Everything will be
better once we switch to technology X."

Developers know that this "grass is greener" effect is a falsehood - one
often promulgated by vendors, marketers and technology evangelists in their
quest to sell a product. The dominant factors influencing the quality of
your application, and ultimately its success or otherwise, are the quality
of the people doing the development and the work methods that they follow.
In most cases, technology choice is almost incidental ( the one possible
exception being where there is a generational, revolutionary change in
technology, such as the transition from low level to high level programming
languages). Therefore developers frequently posses an interest in QA and
software engineering techniques that their programmer counterparts do not.
Programmers try to solve every problem by coding

It is characteristic of the programmer mentality that every problem they
encounter is perceived as an opportunity to write more code. A typical
manifestation is the presence of a "tools guy" on a development team. This
is the guy who is continually writing new scripts and utilities to
facilitate the development process, even if the process he is automating is
only performed once in a blue moon, meaning that there is more effort
expended in writing the tool than the resulting automation will ever save.

Developers know that coding effort is best reserved for the application
itself. After all, this is what you are being paid to produce. They know
that tool development is only useful to a point, after which it becomes just
a self-indulgent distraction from the task at hand. Typically, a retreat
sought by those with a love of "plumbing" and infrastructure-level
development. Developers know that there are many development tasks that it
is simply not worth automating and, where possible, will buy their
development tools rather than roll their own, as this is the most time- and
cost-efficient way of meeting their needs.
Developers seek repeatability, programmers like one-off heroics

If development were an Aesop's fable, then programmers would be the hares,
and developers the tortoises. Programmers, prone to an over-confidence
resulting from excessive faith in technology's ability to save the day, will
find themselves facing impending deadlines with work still to go that was
meant to be made "easy" by that technology, but was unexpectedly
time-consuming. Not surprisingly, the technology doesn't ameliorate the
impact of too little forethought and planning. These last-minute saves, and
the concentrated effort they require, are later interpreted as evidence of
commitment and conviction, rewarded as such, and thereby perpetuated.

Developers are very aware that there are no silver bullets, be they
methodological or technological. Rather than pinning their hopes on new
methods or tools, they settle down to a period of detailed analysis and
planning, during which they do their best to anticipate the road ahead and
the sorts of obstacles they will encounter. They only proceed when they feel
that they can do so without entertaining too much risk of making faulty
assumptions, and having to later throw work away.
Programmers like complexity, developers favor simplicity

It's not uncommon for programmers to deliberately over-engineer the
solutions they produce, simply because they enjoy having a more complex
problem to solve. They may introduce requirements that are actually quite
unnecessary, but which give them the opportunity to employ some technology
that they have been itching to play with. Their users will have to bear this
extra complexity in their every interaction with the system; maintenance
programmers will have to wade through it in every fix and patch; the company
will have to finance the extensions to the project schedule necessary to
support the additional implementation effort; but the programmers care about
none of this - as long as they get to play with a shiny new tech toy.

Developers continually seek the simplest possible resolution to all the
design forces impinging on their project, regardless of how cool or trendy
the technology path it takes them down. If the project's best interests are
served by implementing in Visual Basic, then VB is what you use, even though
VB isn't cool and may not be something you really want to see on your CV. If
the problem doesn't demand a distributed solution, with all the scalability
that such an architecture provides, then you don't foist a distributed
architecture upon the project just so you can get some experience with the
technologies involved, or just because it is possible to fabricate some
specious "what if" scenario to justify its usage, even though this scenario
is never likely to occur in a real business context.
Developers care about users

Programmers often view their user base with disdain or even outright
contempt, as if they are the ignorant hordes to whose low technical literacy
they must pander. They refer to them as "lusers", and laugh at their
relative inexperience with computing technology. Their attitude is one of
"What a shame we have to waste our elite programming skills solving your
petty problems" and "You'll take whatever I give you and be thankful for
it." Programmers delight in throwing technical jargon at the user base,
knowing that it won't be understood, because it enables them to feel
superior. They are quick to brush off the user's requests for help or
additional functionality, justifying their laziness by appealing to
"technical reasons" that are too involved to go into.

Developers don't consider users beneath them, but recognize and respect that
they just serve the organization in a different capacity. Their contribution
is no less important for that. When speaking with users, they try to
eliminate unnecessary technical jargon from their speech, and instead adopt
terminology more familiar to the user. They presume that requests for
functionality or guidance are well intended, and endeavor to objectively
appraise the worth of user's requests in terms of business value rather than
personal appeal.
Developers like to satisfy a need, programmers like to finish

Programmers tend to rush headlong into tasks, spending little time
considering boundary conditions, low-level details, integration issues and
so on. They are keen to get typing as soon as possible, and convince
themselves that the details can be sorted out later on. The worst that could
happen is that they'll have to abandon what they've done and rewrite it -
which would simply be an opportunity to do more coding and perhaps switch
technologies as well. They enjoy this trial and error approach, because it
keeps activity focussed around the coding.

Developers know that the exacting nature of programming means that "more
haste" often leads to "less speed." They are also mindful of the temptation
to leap into coding a solution before having fully understood the problem.
Therefore they will take the time to ensure that they understand the
intricacies of the problem, and the business need behind it. Their intent is
to solve a business problem, not just to close an issue in a bug tracking
system.
Developers work, programmers play

Many software developers enter the work force as programmers, having
developed an interest in software from programmer-like, hobbyist activities.
Once they learn something of the role that software plays in an
organizational context, their sphere of concern broadens to encompass all
those other activities that constitute the difference between programmer and
developer, as described above.

However, some never make the attitudinal transition from the amateur to the
professional, and continue to "play" with computers in the same way they
always have, but do so at an employer's expense. Many will never even
appreciate that there could be much more to their work, if only they were
willing to step up to the challenge and responsibility.

Software engineering, not yet a true profession, places no minimum standards
and requirements upon practitioners. Until that changes, hobbyist
programmers will remain free to masquerade as software development
professionals.

It is the developers that you want working in your organization. Programmers
are a dime a dozen, but developers can bring real value to a business. Wise
employers know how to tell the difference.
-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/48141e5b/attachment-0001.html 

我觉得只要进入编程这个行当就没有所谓的“主动”的，全都是被动的随着大潮起起
落落，所谓“长江后浪推前浪，前浪死在沙滩上”，所谓的“主动”只是某种幻像。

程序员之间最大的区别就在于你有没有创造力，这是为什么现在很多人还在重复的
发明各种轮子，因为发明再小的轮子它也是发明，而使用再大的轮子也只是使用而
已。


在 2007-03-10六的 13:11 +0800，BiFF写道：
> 　　我觉得这个世界上的程序员 可以分为两种:"主动程序员"和"被动程序
> 员"。"主动程序员"可以自己选择开发方式，开发语言和框架，"被动程序员"被
> 动接受公司指定的语言和开发方 式。其实在现实生活中，这种分类并不绝对，
> 一个程序员可能在不同的时候担当不同的角色，"被动程序员"也可能享有有限的
> 主动权。这么分类并不以程序员本身 的知名度，财富多少，是否自己创业还是
> 受雇于人有关。
> >..........

vcc wrote:
> 我觉得只要进入编程这个行当就没有所谓的“主动”的，全都是被动的随着大潮起起
> 落落，所谓“长江后浪推前浪，前浪死在沙滩上”，所谓的“主动”只是某种幻像。
> 
> 程序员之间最大的区别就在于你有没有创造力，这是为什么现在很多人还在重复的
> 发明各种轮子，因为发明再小的轮子它也是发明，而使用再大的轮子也只是使用而
> 已。

重新发明轮子是我能想到的最低水平的开发活动。如果人类把重新发明轮子这种事
情也当作“发明”跟“创新”的话，我们索性回到茹毛饮血的时代好了 :-)

Cheers,
-- 
Xin LI <delphij在delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!

-------------- 下一部分 --------------
一个非文本附件被清除...
发信人: %(who)s
主题: %(subject)s
日期: %(date)s
大小: 249
Url: http://python.cn/pipermail/python-chinese/attachments/20070310/cbae790e/attachment.pgp 

个人比较喜欢重新发明轮子，从中有相当的乐趣，况且，已有的轮子并非很完美。再者重新实现一遍轮子也是一种很好的学习过程。
是不是理解错了"重新发明轮子"的意义了？


-- 
从前有一只很冷的毛毛虫，他想获得一点温暖。而获得温暖的机会只有从树上掉下来，落进别人的领口。
片刻的温暖，之后便失去生命。而很多同类却连这片刻的温暖都没有得到就..
我会得到温暖么？小心翼翼的尝试，却还是会受到伤害。
我愿为那一刻的温暖去拼，可是谁愿意接受?

欢迎访问偶的博客：
http://blog.csdn.net/gashero

以君所见，所有的操作系统都应该是最低水平的重复轮子了；－）可能FreeBSD除
外 ;-)

玩笑话，不必当真，没有人能够确保自己做的东西一定是没有前人做过的，牛顿都
说自己是站在巨人的肩膀上，没有真正创新过是很难理解这个的，重要的不是那个
轮子，是敢于挑战的精神。

在 2007-03-10六的 22:43 +0900，LI Xin写道：
> vcc wrote:
> > 我觉得只要进入编程这个行当就没有所谓的“主动”的，全都是被动的随着大潮起起
> > 落落，所谓“长江后浪推前浪，前浪死在沙滩上”，所谓的“主动”只是某种幻像。
> > 
> > 程序员之间最大的区别就在于你有没有创造力，这是为什么现在很多人还在重复的
> > 发明各种轮子，因为发明再小的轮子它也是发明，而使用再大的轮子也只是使用而
> > 已。
> 
> 重新发明轮子是我能想到的最低水平的开发活动。如果人类把重新发明轮子这种事
> 情也当作“发明”跟“创新”的话，我们索性回到茹毛饮血的时代好了 :-)
> 
> Cheers,
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese

gashero wrote:
> 个人比较喜欢重新发明轮子，从中有相当的乐趣，况且，已有的轮子并非很完美。再者重新实现一遍轮子也是一种很好的学习过程。
> 是不是理解错了"重新发明轮子"的意义了？

哦。。。我的“重新发明轮子”的概念是指做一个完全一样甚至不如原来东西的玩
意。所以只要有改进，无论大小都不能算重新发明轮子了。

Cheers,
-- 
Xin LI <delphij在delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!

-------------- 下一部分 --------------
一个非文本附件被清除...
发信人: %(who)s
主题: %(subject)s
日期: %(date)s
大小: 249
Url: http://python.cn/pipermail/python-chinese/attachments/20070310/6fbf5e91/attachment.pgp 

vcc wrote:
> 以君所见，所有的操作系统都应该是最低水平的重复轮子了；－）可能FreeBSD除
> 外 ;-)
> 
> 玩笑话，不必当真，没有人能够确保自己做的东西一定是没有前人做过的，牛顿都
> 说自己是站在巨人的肩膀上，没有真正创新过是很难理解这个的，重要的不是那个
> 轮子，是敢于挑战的精神。

呵呵，我说的重新发明轮子主要是一些并非以学习为目的，而且明明知道别人做
过，还要再做一遍的行为。人这一辈子要挑战的东西很多，我个人认为把劲用在正
路上还是挺重要的，偶尔学唐吉訶德跟风车叫会板没问题，但是一辈子都这么做就
不对了 :-)

Cheers,
-- 
Xin LI <delphij在delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!

-------------- 下一部分 --------------
一个非文本附件被清除...
发信人: %(who)s
主题: %(subject)s
日期: %(date)s
大小: 249
Url: http://python.cn/pipermail/python-chinese/attachments/20070310/a9ab42a0/attachment.pgp 

整个Java体系的复杂性是有原因的，事实上，除了对Java语言标准的控制，Sun不过是JCP的一员，我更愿意相信Java的发展是整个企业、开源和开发者社区一起推动的。

Java语言本身还是挺简单的，庞杂的是Java体系的标准池和类库，但是，我感觉，如果让ruby或者python去完成同样的事，它们可能或多或少也要面对同样的问题，比如XA，配置和管理，消息中间件等等。


On 3/10/07, BiFF <qq274980 at gmail.com> wrote:
>
>  我觉得这个世界上的程序 <http://dev.yesky.com/>
> 员可以分为两种:"主动程序员"和"被动程序员"。"主动程序员"可以自己选择开发方式，开发语言和框架，"被动程序员"被动接受公司指定的语言和开发方式。其实在现实生活中，这种分类并不绝对，一个程序员可能在不同的时候担当不同的角色，"被动程序员"也可能享有有限的主动权。这么分类并不以程序员本身的知名度，财富多少，是否自己创业还是受雇于人有关。
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://python.cn/pipermail/python-chinese/attachments/20070310/e7bbe691/attachment.htm 

同意郭丹的看法。

此外，现在不管是哪个web 2.0的框架，好像团队里的每个开发人员，都必须对里面的方方面面都非常熟悉，否则玩不转。这大概是限制这些东西发展的原因了吧。

On 3/10/07, 郭丹 <mark.guo在gmail.com> wrote:
> 整个Java体系的复杂性是有原因的，事实上，除了对Java语言标准的控制，Sun不过是JCP的一员，我更愿意相信Java的发展是整个企业、开源和开发者社区一起推动的。
>
> Java语言本身还是挺简单的，庞杂的是Java体系的标准池和类库，但是，我感觉，如果让ruby或者python去完成同样的事，它们可能或多或少也要面对同样的问题，比如XA，配置和管理，消息中间件等等。
>
>
> On 3/10/07, BiFF <qq274980在gmail.com> wrote:
> >
> >
> >
> 　　我觉得这个世界上的程序员可以分为两种:"主动程序员"和"被动程序员"。"主动程序员"可以自己选择开发方式，开发语言和框架，"被动程序员"被动接受公司指定的语言和开发方式。其实在现实生活中，这种分类并不绝对，一个程序员可能在不同的时候担当不同的角色，"被动程序员"也可能享有有限的主动权。这么分类并不以程序员本身的知名度，财富多少，是否自己创业还是受雇于人有关。
> >
> >
>
> _______________________________________________
> python-chinese
> Post: send python-chinese在lists.python.cn
> Subscribe: send subscribe to
> python-chinese-request在lists.python.cn
> Unsubscribe: send unsubscribe to
> python-chinese-request在lists.python.cn
> Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
>

On 3/11/07, shhgs <shhgs.efhilt在gmail.com> wrote:
>
> 同意郭丹的看法。
>
> 此外，现在不管是哪个web 2.0的框架，
> 好像团队里的每个开发人员，都必须对里面的方方面面都非常熟悉，否则玩不转。这大概是限制这些东西发展的原因了吧。
>
>
不知道shhgs所说的Web 2.0 框架是指什么，据我所知很多的web2.0公司，例如feedburner,
friendster还是采用Java架构的，Flickr的很多后端服务也是Java实现的

Java架构/框架的复杂度，源于大公司企图通过控制标准来主导技术发展的方向，这一招还是跟微软学来的。控制了产业标准，竞争厂商永远落后标准厂商一步，
所以微软可以通过.Net 迅速将Borland的优势变为0.
J2EE之类的标准的不断升级，可以让厂商不断地出新的release,
才可以不停地向企业销售，永远保持其高额利润，所以标准烂不是问题，复杂度更是要保持的，你想想除了业界几家巨头，谁还有那么多的人力物力去维护这么复杂的一个体系架构，所以优势将永远保持在这几家巨无霸手上。


-- 
simple is good
http://brucewang.net
skype: number5
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: http://python.cn/pipermail/python-chinese/attachments/20070311/6619b8a3/attachment-0001.html