对比java和python
对比java和python
2011年04月18日
1.难易度而言。python远远简单于java。
2.开发速度。Python远优于java
3.运行速度。java远优于标准python，pypy和cython可以追赶java，但是两者都没有成熟到可以做项目的程度。
4.可用资源。java一抓一大把，python很少很少，尤其是中文资源。
5.稳定程度。python3和2不兼容，造成了一定程度上的混乱以及大批类库失效。java由于有企业在背后支持所以稳定的多。
6.是否开源。python从开始就是完全开源的。Java由sun开发，但现在有GUN的Openjdk可用，所以不用担心。
7.编译还是解释。两者都是解释型。
我理解，C好比手动挡车（编译型语言），java和python（解释型语言）好比自动档车。跑的最快的车都是手动档，但是对开不好的人来说，开自动档反而更快些。
Kno有一篇文章谈到选择编程语言，“先确定你的需求”，不要由语言的简单还是复杂去觉定。只有能够编写你真正认为有用的程式，才能获得满足感，学习才能继续。
那么java和python分别适用于什么样的环境呢。由sourceforge.net可以看出：
最著名，久经考验的普通应用程序，基本都是c++写的。例如emule，7-zip，WinSCP,FileZilla等等等。
一部分由java开发，例如最有名的OpenOffice。
python写的很少，如Pidgin，FireBird。
开发语言（有多少个程式由此语言开发）的排行如下：
# Java46,202
# C++36,895
# PHP30,048
# C28,075
# C#13,476
# Python13,379
# JavaScript11,285
# Perl9,216
# Unix Shell3,869
# Delphi/Kylix3,548
# Visual Basic3,186
# Visual Basic .NET
很多框架和类库也和应用软件一样在这个列表里，因此比较公平。
由此可以看出，java不管在GNU还是商业领域都是应用最广的语言。C主要用于构建系统底层。c++和java用于构建中间应用层。如果资源足够，那么会选择c++开发，以求运行速度，否则会用java开发，以求开发速度。python在各方面都比java优秀，可谓次世代语言。可最受争议的是它的速度，纯python比java慢很多，以及背后没有商业支持，稳定性备受诟病。目前为止，python在商业层次上，主要作为一种胶水语言，粘合其他语言（主要是c/c++）的类库。在GNU领域，主要局限于小规模的应用和个人化应用。以及逆向工程（黑客）应用。
为什么java在服务器端被大量应用，在客户端用的却比较少呢。难道服务器端用到的计算量反而少么。我认为这说明对比c++，java的速度还是可以接受的。无法被接受的是JRE平台，以及JRE平台启动时卡的那一会儿。我就曾经为此认为java写就的程式性能低下。
python用户常常拿来说嘴的一点是：python并不慢，因为python运行时调用了大量c库，而c是很快的。反过来想想，这正反映了其胶水语言的事实，任何一种语言都可以调用c库，这么比较有价值么？假如一个库完全由python，那么它的运行效率...不说也罢。编程不能总是用别人的库啊。
----
Python编程语言目前的使用中需要不断的学习。下面我们就详细的看看如何才能更好的进行相关知识的学习。最近我一直在看一个基于wxPython的GUI应用程序代码，大概45.5KLOC的左右，而且这还不包括它所用到的库(如Twisted)。
代码是由那些对Python比较生疏的Java的开发者写的，所以它存在很严重的性能问题(如三十秒的启动时间)。在检查代码的时候，我发现他们写了很多在Java中能讲得通但是对Python编程语言来说去却是很难接受的东西。并不是因为“Python比Java慢”，而是因为在Python中有更方便的方法去完成同样的目标，甚至是在Java中不可能的事情。
所以，令人难过的事就是这些家伙事倍功半，写的那些代码比本应合乎用Python编程语言实现的慢很多。下面，让我们来看一些例子：
◆Java中的静态方法不能翻译成Python的类方法。哦，当然，他多多少少也能产生同样的效果，但类方法的目的实际上是做一些通常在Java中甚至都不可能的事情(如继承一个非默认的默认函数)。Java静态方法惯用的翻译通常翻译成一个模块级的函数，而不是一个类方法或静态方法。(并且静态常量应该翻译成模块级常量.)
这不是性能上的问题，但是一个Python编程语言程序员如果想调用Foo.someMethod，他要是被迫采用像Java中Foo.Foo.someMethod的方式去做的话，那么他就会被逼疯的。有一点一定要注意:调用一个类方法需要一个额外的存储空间,而调用静态方法或函数就不需要这样.
对了,还有就是这些Foo.Bar.Baz的属性链也不是自己就能数出来的.在Java中,这些带点的名称是有编译器来查找的,运行的时候并不会去考虑一共有多少.而在Python中,查找的过程是在运行时进行的,所以要包括每个点.(在Python中,要记住一点,"平铺的结构别嵌套的要好",尽管相对于从性能方面来说,可能它更多涉及的是"可读性"和"简单要比复杂好".)
◆要使用switch语句吗?Python编程语言将是一个哈希表，不是一堆if-then语句。要使用在Java中不是switch语句而且还有字符串参与了的一堆if-then语句吗?它将仍然是一个哈希表。CPython字典是用在我们所了解的领域中认为是最佳性能之一的哈希表来实现的。你自己所写的代码也不会比这个再好了，除非你是Guido、Tim Peters和Raymond Hettinger的私生子,而且还是遗传增强了的。
◆XML不是答案。它也不是一个问题。现在用正则表达式来解释Jamie Zawinski，“一些人，当他遇到一个问题的时候，就会想‘我知道，我要用XML.’那么他们就有两个问题了。”
相对于在Java中来说这是个不同的情况，因为比起Java代码，XML是灵活而且有弹性的。但比起Python的代码来，XML就是一个船锚，一个累赘。在Python中，XML是用来协同工作的，而不是你的核心功能，因为你不需要那么做。在Java中，XML可能是你的救世主,因为它让你实现了特定领域的语言并且“不用编码”就提高你的应用程序的适应性。在Java中，避免编码是一个很大的优势，因为编码意味着重新编译。但在Python中，通常是，写代码比写XML更简单。还有就是Python处理代码要比处理XML快很多很多。(不仅仅是这个，你必须写XML处理代码，同时Python就已经为你写好了.)
如果你是一个Java程序员，你并不能利用本能知觉来考虑你是否要在你的Python核心应用中使用XML作为一部分。如果你不是因为信息交互的原因去实现一个已经存在的XML标准或是建立某种输入、输出格式或者建立某种XML编辑器或处理工具，那么就不要这么做。根本不要去这么做。甚至连想都不要想。现在，丢掉那个XML模式然后把你的手解放出来吧！如果你的应用程序或者平台要被Python编程语言开发者使用，他们只会感谢你不要在他们的工作中添加使用XML的负担。
(这里唯一的例外是如果你的客户(your target audience)确确实实因为某些原因而需要使用XML。就好像，他们拒绝学习Python但如果你使用XML他们就给你付钱，或者你打算给他们一个很棒的能编辑XML的GUI，还有就是这个XML的GUI是另一个人写的，同时你得到免费使用的权利。还有一些很少见的架构上的原因需要用到XML。相信我，它们不会应用到你的程序中去的。如果有疑问，对一个资深的Python开发员解释你的用例。或者，如果你脸皮厚而且不介意被人嘲笑的话，试试向一个Lisp程序解释你的程序为什么要用XML!)
◆Getter和setter是恶魔。我应该说它是恶魔,是魔鬼！Python编程语言对象不是Java Bean。不要写什么getter和setter，而是还把它们内置在“属性”里面。它直到你能证明你需要比一个简单访问复杂一点的功能时才有意义，要不然，不要写getter和setter。它们是CPU时间的浪费，更要紧的是，它们还是程序员宝贵时间的浪费。不仅仅对于写代码和测试的人，对于那些要阅读和理解它们的人也是。
在Java中，你必须使用getter和setter,因为公共字段不允许你以后改变想法再去使用getter和setter。所以,在Java中你最好事先避开这些"家务杂事".在Python中，这样做很傻，因为你可以以一个普通特性开始并可以在任何时间改变你的想法，而不用影响到这个类的任何客户。所以不要写getter和setter方法。
◆代码重复在Java中通常来说就是一场不可避免的灾祸，你必须经常反复地写同一个方法而只有一点点的变化(通常是这是因为静态类型约束)。在Python中这样做是没有必要的也是不值得的(除了极少数一些特定的场合需要内联一些要求性能的函数)。如果你发现自己一遍一遍在写同样的代码而且变化很少，你就需要去学一下闭包。他们实际不并是那么可怕。
这就是你要做的。你写了一个包含了函数的函数。这里内部的函数就是你要一遍遍写的函数的模版，但是在里面加入了针对不同情况的函数要使用变量。外部的函数需要刚刚提高的那种变量作为参数，并且将内部的函数作为结果返回。然后，每次你要写另一种略微不同的函数的时候，你只要调用这个外部的函数，并且把返回值赋给你要让“重复”函数出现的名字。现在，如果你需要改变这个工作方式，你只需要改变一个地方：这个模版。
在我所看过的应用程序/平台中，只有一个很微不足道的程序使用了这个技术,它去掉了数百行重负的代码。实际上，因为开发者使用了特别的样板文件来为这个平台开发插件，所以这会节省很多很多第三方开发人员的代码，同时也使那些程序员要学习的东西变得简单了。
这只是Java->Python编程语言思维方式转变的冰山一角而已，现在我能正确的转变而不用去钻研程序的细节。本质上，如果你曾经用过一段时间Java，而且对Python比较陌生，那么你不要太相信自己的本能。你的本能已经被Java调节，而不是Python。向后退一步来说，最重要的是不要再写这么多代码了。
为了这样做，让自己觉得更加需要Python。假装好像Python是可以做任何你想做的魔棒，而你无须出一点力。问一下，“Python怎样解决我的问题？”还有“Python语言的哪个特点和我的问题最相似？”如果对于你需要的东西其实已经有了某种固定形式,那么你绝对会感到惊讶的。事实上，这种现象实在是太普遍了，甚至即使在很有经验的Python程序员中也会出现，以至于Python社区中给这种现象起了个名字。我们称之为“GUIDO的时间机器”，因为在我们自己还没有掌握它之前,通常看上去要得到我们所需要的东西好像那是唯一的方法。
所以，如果你在使用Python编程语言时候不能感到比使用Java要至少多出10倍的生产力话，你就最好做一下改动,你是不是忘记使用time machine!(chances are good that you‘ve been forgetting to use the time machine)(同时如果你还怀念你的Java IDE，你可以这样想：因为你写的Python程序比他所需要的要复杂得多.)