Python或Java还是PHP? [英] Python or Java or maybe PHP?

查看:64
本文介绍了Python或Java还是PHP?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,


我需要编写一个Web应用程序,它将支持数百万个用户帐户,

基于模板的用户页面和文件上传。客户端将用Flash编写的
。我想知道我是否能得到你的意见 - 你是什么?b $ b认为是服务器使用的最佳语言? Python还是Java?并且

我说的是可扩展性,面向对象,开发工具等。


Thansk任何想法!我很想听听它

2006年新的快乐,

Lior

解决方案

<李*** @ noks.com>写道:

大家好,

我需要编写一个Web应用程序,它将支持数百万个用户帐户,基于模板的用户页面和文件上传。客户端将用Flash编写。我想知道我是否会得到你的意见 - 你认为什么是服务器使用的最佳语言? Python还是Java?而且我正在谈论可伸缩性,面向对象,开发工具等。




我个人不会考虑PHP,就人而言可伸缩性(如果服务器需要增长到非常丰富的逻辑等等)。但是,
Ruby(当然,使用Rails作为服务器端框架),Python(许多

选项服务器端,从Twisted到Django)和Java (我相信,更多的是b $ b选项服务器端)是所有有价值的候选人。他们是所有面向对象的对象。足够他们之间的细微差别不是真的很重要;对于Java来说,开发人员工具的选择可能是最广泛的,而对于Ruby来说,最小的开发人员工具是最低的(对于服务器端的Web框架来说也是如此),但

这两种方式都会削减(一旦你已经决定将Java作为你的语言

仍需要多周的评估来选择工具和框架 - 如果你决定使用Ruby,工具和框架更多或更少固定 - Python

在两个字段之间介于两者之间。


等等是乐趣的地方;-)。 Java是静态类型的,Ruby和

Python是动态类型的:你可能会在web上找到更多关于编程语言这一方面的火焰战而不是所有的

其他人合并。基于丰富的个人经验,我坚定地参与动态打字阵营 - 坚信Ruby或

Python使开发人员和团队的工作效率更高,或者换句话说,Ruby和Python是更高级别的
。比Java,需要更少的代码来实现一定数量的功能,开发人员的生产率主要与代码量相关。他们需要

开发,调试,维护(功能规格和用户文档)OTOH

取决于功能,而不是实现

所需的代码功能,所以不依赖于实施的选择

语言[s])。


你也会发现很多火焰战关于附带问题的每一方,例如

社区,或程序员的质量。您可以轻松获得

语言A与语言B(几乎任何A和B的选择;-)。我不确定你应该给这些考虑多少重量,或者其他软而模糊的b $ b。诸如哲学之类的问题。通过每种语言的设计和社区反映




考虑到所有事情,我会暂时建议Python,但如果你是

稍微检查了两种语言然后选择了Ruby(或者,在你的开发团队中给出了一个合适数量的CS博士,Common Lisp,或者

Haskell ,但这是另一个问题)我没有根据预测你的选择是错误的b / b
;如果你选择了Java,我会强烈怀疑你做出了错误的选择。如果你选择了PHP,我个人会觉得你做出了错误的选择; ...)。


只是为了让魔鬼得到应有的,如果

这是一个可以接受的权衡,你的服务器永远被束缚到微软系统,你可能

甚至想要考虑ASP.NET - 我没有使用它的经验

,但是我尊重的技术判断的一些人声称这是一个不错的选择。就个人而言,无论如何我会认为''战略''成本

(上面提到的MS shackes)太高了,但只有你能够做出这样的决定才能做出这样的决定。你自己的情况。同样,苹果的

WebObjects也受到了广泛好评,但它们会束缚你到苹果系统(苹果直接支持的语言选择)

WebObjects是Objective C,Java和WebScript,是一种专有的

非常高级的语言;但我相信,感谢PyObjC,你可以使用Python代替
或者与ObjC并排,当然,就像你一样,
总是可以选择Jython,而不是与Java并排,

每当你选择一个 ;基于Java的平台。

Alex


谢谢!这真的很有用。我不确定我是否动态输入

家伙 - 来自C#,非常严格的语言和C ++,静态打字,

但是我毫无疑问地搜索并看到辩论变得强烈。不要尝试

在这里开始吧,但是你认为这是静态输入的 - 即,如果我确定正确的事情,那么就没有必要申报

变量 - 您认为它对生产力有这样的影响吗?


再次感谢!

Lior


NOKs< li *** @ noks.com>写道:

谢谢!这真的很有用。我不确定我是否动态输入
家伙 - 来自C#,非常严格的语言和C ++,静态类型,


C#'非常接近Java,打字方式,而C ++并不是那么遥远。我在上一篇文章中确实提到了一种GOOD静态类型的语言...

不幸的是,这是你需要一堆CS博士的那种语言之一'' s

- Haskell。

但是我确定地搜索并看到辩论变得强烈。不要试图在这里启动它,但你认为这是静态类型的 - 即,如果我正确地说,没有必要声明
变量这一事实 - 你呢?认为它对生产力有这样的影响吗?




一个很棒的编程原则是不要'重复你自己:当你是

必须一遍又一遍地表达同样的事情,有一些东西

错了。我相信DYR。措辞是由于所谓的Pragmatic

程序员,他们是Ruby的圣骑士,但我也相信这是最有经验的程序员可以接受的原则。


因此,在Java中你需要编码:


FooBar zap =(FooBar)glak;


你知道一定有什么问题 -

的要点让你说FooBar两次?!


有两种方法可以让你避免声明变量,启用DYR

并提高工作效率:


a。在运行时做所有事情(因为Java当然会进行检查,在上面的代码中,这个glak可以正确地强制转换为FooBar);如果你在运行时所做的所有类型检查都是一致的,你会得到一个动态类型的

语言。 "动态"与在运行时非常相似。而且它会变成

,你真正需要的唯一一个检查是:

- 当你调用bleep.zupdok()时,无论什么物体都会发出声音

指的是支持一个可以在没有args的情况下调用的'zupdok'方法吗?

启用运行时输入,作为一种高效的编程方法,通过

这个事实无论你的语言打字方式如何,你都需要单独测试
单元测试(因为它们是必不可少的,在运行时必须

,很多没有人可以静态检查的东西)...而且,作为

的副作用,好的单元测试也会复制所有(非常适度)

检查静态类型的语言可以帮到你。


b。在编译时完成所有工作。 Java,C#,C ++的类型系统实际上太弱而且不一致;然而,像ML这样的语言(在其几个变种中)和Haskell证明了类型系统CAN

的设计允许这样做。有了一个设计合理的类型系统,你还不需要声明:你编写类似的东西(在Python中用

语法)

def f (a,b):返回a + b

并且编译器推断出a和b必须是类型类的变量,

支持加法,并且函数f'' s返回值将与a和b相同的类型类别为

。所以,如果你以后调用f(2,3),编译器

接受它并且知道结果必须是int,但是如果你尝试编码

f(' 'zap'',67)编译器尖叫着你,因为它知道你不能添加

a字符串和一个int。这种类型推断是指类型推断。是非常强大的,并且实际上是等价的(至少在Haskell变体中,基于

类型类别,又称类型类,而不仅仅是类型)到动态

打字你得到了Python,还有其他好处(你得到了一些错误

诊断得更快,甚至不需要运行你的单元测试,这可以节省你几秒钟的时间)发生)。


不幸的是,我相信Haskell(和SML等)只适合那些具有非常特殊资格和思维模式的b $ b程序员 -

本质上,数学或CS的学位更高,或相当于

(当然,有些人会有没有正式头衔的诀窍,但

它有点难以预测谁会这样做。如果您有一个罕见的财富

,您的编程团队可以指望只由这样的人组成,请给Haskell一个尝试(不要忘记) Common Lisp,另一种

语言的神奇力量),你可能比使用

动态语言更快乐(不一定 - 一个高调的网站刚刚

从Lisp重新编写为Python,主要是出于高度务实的原因,例如
- 但是Python友好的,以Lisp为中心的权限,例如

Norvig和Graham仍然认为Lisp在这样的情况下会有优势,假设当然在你的情况下,实用问题可能会溢出




如果真的很好静态类型,就像在Haskell中一样,不是真正的可能性

- 也就是说,在现实世界中,给出了动态类型之间的选择

,如Python和半缺陷-static但是有一些不可避免的运行时间

方面和程序员需要的大量冗余打字就好了,

说,Java - 我真的毫不怀疑动态打字增加了b $ b程序员的生产力相当大。在谷歌,我看到了相同的工程师代码,包括Python,C ++和Java(谷歌使用的三种通用语言),以及我<生产力的结果观察似乎完全证实了我的观点(已经形成了基于

的其他经验,关于我自己的编码和其他

程序员的编码我过去观察过各种各样的技能。


一旦你决定尝试动态打字语言,问题就是

在Ruby和Python之间保持开放,当然(还有其他人,从Tcl到Perl的
,从Lua到Applescript等等,但我看不出真正的

原因除了Python和Ruby之外,还要考虑其他任何事情。)

尽管细节有很多差异(主要是,但不是唯一的,

语法糖的详细信息) ,我认为Ruby和Python本质上是

等价*作为语言*,所以我建议你选择一个严格的实用基础 - 框架和库的质量,执行速度,

工具,书籍,第三方扩展,& c。我认为这是对b / b
语言的致敬(对Rails vs没有太多的实际经验,

说,Django)我不确定哪一个最适合你,虽然

我怀疑,如果由于成熟度的原因没有别的,那么它可能是
Python。但要注意的是,至少有一个Ruby狂热分子口头上说b * b因为敢于表达这些而非常激烈地殴打我,我认为这是非常公平的判断(显然,通过考虑

仅仅是语法糖问题,在Python中你编码的事实,例如,if

a> b:c = d ,在Ruby中,你可以用另一种方式编写圆形,c = d如果

a> b,我一定是侮辱了一些神在哪个祭坛上这样的狂热分子

崇拜......);如果你选择倾听这样的狂热分子,那么你应该获得第二意见,而不是相信我自己对这些问题的评估。

Alex


Hi everyone,

I need to write a web app, that will support millions of user accounts,
template-based user pages and files upload. The client is going to be
written in Flash. I wondered if I coudl get your opinions - what do you
think is the best language to use for the server? Python or Java? And
I''m talking scalability, object oriented, development tools etc.

Thansk for any idea! I''d love to hear it
Happy New 2006,
Lior

解决方案

<li***@noks.com> wrote:

Hi everyone,

I need to write a web app, that will support millions of user accounts,
template-based user pages and files upload. The client is going to be
written in Flash. I wondered if I coudl get your opinions - what do you
think is the best language to use for the server? Python or Java? And
I''m talking scalability, object oriented, development tools etc.



I would personally not consider PHP, in terms of "human" scalability (if
the server needs to grow to substantially rich logic etc). However,
Ruby (with Rails, of course, as the server-side framework), Python (many
options server-side, from Twisted to Django), and Java (even more
options server-side), are, I believe, all worthy candidates. They''re
all "object oriented" enough that the fine distinctions among them don''t
really matter; choice of developer tools is probably widest for Java and
least wide for Ruby (and the same for server-side web frameworks), but
this cuts both ways (once you''ve decided on Java as the language you
still have many weeks of evaluation to pick tools and frameworks -- if
you decide on Ruby, tools and framework are more or less fixed -- Python
is "in between" in both fields).

The "etc." is where the fun is;-). Java is statically typed, Ruby and
Python are dynamically typed: you will perhaps find more flamewars on
the web about this one aspect of programming languages than about all
others combined. On the basis of extensive personal experience, I''m
firmly in the dynamical-typing camp -- firmly convinced that Ruby or
Python make developers and teams more productive, or, in other words,
that Ruby and Python are "higher-level" than Java, requiring much less
code to implement a given amount of functionality, and developers''
productivity is tied mostly to the "amount of code" they need to
develop, debug, maintain (functional specs and user documentation OTOH
depend on functionality, not on code needed to implement the
functionality, and so don''t depend on the choice of implementation
language[s]).

You''ll also find lots of flamewars on each side about side issue such as
"community", or "the quality of programmers" that you can easily get for
language A vs language B (for just about any choice of A and B;-). I''m
not sure how much weight you should give to these considerations, or
other "soft and fuzzy" ones such as the issue of "philosophy" reflected
by each language''s design and community.

All things considered, I would tentatively suggest Python, but if you
examined both languages a little and then picked Ruby (or, given a
suitable number of CS PhD''s in your development team, Common Lisp, or
Haskell, but that''s another issue) I''d have no basis for predicting that
your choice would be wrong; if you picked Java, I would strongly suspect
you made the wrong choice; if you picked PHP, I would personally feel
_certain_ that you made the wrong choice;-).

And just to give the devil its due, if it''s an acceptable trade-off for
your server to be shackled to Microsoft systems forevermore, you might
even want to consider ASP.NET -- I have no experience with it
whatsoever, but some people whose technical judgment I respect do claim
it''s a good choice. Personally, I would consider the ''strategic'' cost
(the above-mentioned MS shackes) too high in any case, but only you can
make such decisions for your own circumstances. Similarly, Apple''s
WebObjects have also been widely praised, but they would shackle you to
Apple systems (language choice directly supported by Apple for
WebObjects is Objective C, Java, and WebScript, a proprietary
very-high-level language; but I believe that thanks to PyObjC you could
use Python instead or side by side with ObjC, just as, of course, you
always have the option of Jython, instead or side by side with Java,
whenever you choose a "Java"-based platform).
Alex


Thanks! That''s really useful. I''m not sure if I''m a "dynamically typed"
guy - coming form C#, very strict language, and C++, statically typed,
but i definetly searched and see the debate going strong. Not try to
start it here, but do you think that statically typed - namely, if I
undertood correctly, the fact that there''s no need to declare the
variables - do you think it has such an effect on productivity?

thanks again!
Lior


NOKs <li***@noks.com> wrote:

Thanks! That''s really useful. I''m not sure if I''m a "dynamically typed"
guy - coming form C#, very strict language, and C++, statically typed,
C#''s pretty close to Java, typing-wise, and C++''s not that far away. I
did mention one GOOD statically typed language in my previous post...
unfortunately it''s one of those for which you need a bunch of CS PhD''s
-- Haskell.
but i definetly searched and see the debate going strong. Not try to
start it here, but do you think that statically typed - namely, if I
undertood correctly, the fact that there''s no need to declare the
variables - do you think it has such an effect on productivity?



One great programming principle is "Dont'' Repeat Yourself": when you''re
having to express the same thing over and over, there IS something
wrong. I believe the "DYR" phrasing is due to the so-called Pragmatic
Programmers, who are paladins of Ruby, but I also believe it''s a
principle most experienced programmers could accept.

So, when in Java you have to code:

FooBar zap = (FooBar) glak;

you KNOW there must definitely be something wrong -- what''s the POINT of
making you say "FooBar" TWICE?!

There are two ways to let you avoid declaring variables, enabling DYR
and enhancing productivity:

a. do everything at runtime (as Java will of course do for the check, in
the above code, that glak CAN be properly "cast to a FooBar"); if you do
ALL the typechecks at runtime, consistently, you get a dynamically typed
language. "Dynamically" is much the same as "at runtime". And it turns
out that the only check you really need is:
-- when you call bleep.zupdok(), DOES whatever object bleep
refer to support a ''zupdok'' method that is callable with no args?
Runtime typing is enabled, as a productive programming approach, by the
fact that, whatever your language''s approach to typing, you NEED
unit-tests anyway (because they''re indispensable to check, necessarily
at runtime, a lot of things nobody can check statically)... and, as a
side effect, good unit-tests will also duplicate all the (very modest)
checks a statically typed language could do for you.

b. do everything at compile time. The typesystems of Java, C#, C++ are
substantially too weak and inconsistent for that; however, language such
as ML (in its several variants) and Haskell prove that a typesystem CAN
be designed to allow that. With a properly designed typesystem, you
don''t NEED declarations either: you code something like (in Python
syntax)
def f(a, b): return a+b
and the compiler deduces "a and b must be variables of a typeclass that
supports addition, and function f''s return value is going to be of the
same typeclass as a and b". So, if you later call f(2,3), the compiler
accepts that and knows the result must be an int, but if you try to code
f(''zap'', 67) the compiler screams at you because it knows you can''t add
a string and an int. This "type inference" is very powerful, and
practically equivalent (at least in the Haskell variant, based on
"classes of types", aka "typeclasses", not mere types) to the "dynamic
typing" you get with Python, with further benefits (you get some errors
diagnosed faster, without even needing to run your unit-tests, which
saves you a few seconds when it happens).

Unfortunately, I believe Haskell (and SML, etc) only really suit
programmers who have a very particular qualification and mindset --
essentially, higher degrees in mathematics or CS, or the equivalent
(some people will have that knack without formal titles, of course, but
it''s somewhat hard to predict who will). If you have the rare fortune
that your programming team can be counted on to be composed only of such
people, do give Haskell a try (and don''t forget Common Lisp, another
language of uncanny power), and you may be even happier than with
dynamic language (not necessarily -- a high-profile site has just been
recoded from Lisp to Python, essentially for highly pragmatic reasons,
for example -- but Python-friendly, Lisp-centered authorities such as
Norvig and Graham still think Lisp would have an advantage in such
circumstances, assuming of course the pragmatical issues can be swep
away in your case).

If "really good" static typing, as in Haskell, is not a real possibility
-- that is, in the real world, given the choice between dynamic typing
as in Python and faulty semi-static "but with some inevitable runtime
aspects AND lots of redundancy required of the programmer" typing as in,
say, Java -- I really have no doubt that dynamic typing increases
programmer productivity quite substantially. At Google, I see the same
brilliant engineers code in Python, C++, and Java (the three general
purpose languages Google uses), and the productivity results that I
observe appear to fully confirm my opinions (already formed on the basis
of other experiences, both regarding my own coding and that of other
programmers, of varying skills, I observed in the past).

Once you''ve decided to give dynamic-typing languages a try, the issue
still remains open between Ruby and Python, of course (there are others,
from Tcl to Perl, from Lua to Applescript, etc, etc, but I see no real
reasons to consider any other but Python and Ruby for your task).
Despite the many differences of detail (mostly, though not exclusively,
details of "syntax sugar"), I consider Ruby and Python to be essentially
equivalent *as languages*, so I would suggest you choose on a strictly
pragmatical basis -- quality of framework and library, execution speed,
tools, books, third-party extensions, &c. I see it as a tribute to both
languages that (not having much real-world experience with Rails vs,
say, Django) I don''t know for sure which one would suit you best, though
I suspect that, if nothing else for reasons of "maturity", it might be
Python. Be aware, though, that at least one Ruby fanatic has verbally
assaulted me quite intensely for daring to express these, which I
consider to be very even-handed, judgments (apparently, by considering
"a mere syntax sugar issue" the fact that in Python you code, e.g., "if
a>b: c=d", while in Ruby you may code the other way ''round, "c=d if
a>b", I must have insulted some gods at whose altar such fanatics
worship...); if you choose to listen to such fanatics, you should then
definitely get a second opinion rather than trust my own assessment of
these issues.
Alex


这篇关于Python或Java还是PHP?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆