Python or Java or maybe PHP?

[liorm@noks.com]

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

[Alex Martelli]

Re: Python or Java or maybe PHP?

<liorm@noks.com > wrote:
[color=blue]
> 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.[/color]

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

[NOKs]

Re: Python or Java or maybe PHP?

Thanks! That's really useful. I'm not sure if I'm a "dynamicall y 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

[Alex Martelli]

Re: Python or Java or maybe PHP?

NOKs <liorm@noks.com > wrote:
[color=blue]
> Thanks! That's really useful. I'm not sure if I'm a "dynamicall y typed"
> guy - coming form C#, very strict language, and C++, statically typed,[/color]

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.
[color=blue]
> 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?[/color]

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. "Dynamicall y" 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 "typeclasse s", 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

[Peter Hansen]

Re: Python or Java or maybe PHP?

Alex Martelli wrote:[color=blue]
> 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.[/color]

Shall we assume DYR == "Do You Ruby?" ? <wink>

[Ilias Lazaridis]

Re: Python or Java or maybe PHP?

liorm@noks.com wrote:[color=blue]
> 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[/color]

You may want to review some basic evaluations, which can simplify the
selection process:

(note that this is a work in progress)

http://lazaridis.com/case/lang/index.html

and some community evaluations:

http://lazaridis.com/core/eval/index.html

-

You have to define your requirements.

This way you can manage the complexity of the evaluation.

-

please feel free to contact me with private email.

..

--

http://lazaridis.com

[Alex Martelli]

Re: Python or Java or maybe PHP?

Peter Hansen <peter@engcorp. com> wrote:
[color=blue]
> Alex Martelli wrote:[color=green]
> > 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.[/color]
>
> Shall we assume DYR == "Do You Ruby?" ? <wink>[/color]

Heh, I _did_ mean "DRY" of course;-)


Alex

[Cameron Laird]

Re: Python or Java or maybe PHP?

In article <1h8ia95.qy2gkb zh9jmcN%aleax@m ail.comcast.net >,
Alex Martelli <aleax@mail.com cast.net> wrote:

[Alex Martelli]

Re: Python or Java or maybe PHP?

Cameron Laird <claird@lairds. us> wrote:
...[color=blue]
> "c = d unless ...": it's possible to distinguish Python from
> Ruby in another way. Python is arguably better for group work,
> or at least more standard for team projects, because it more
> consistently exposes "one correct solution", while Ruby both
> admits more stylistic variation, *and* encourages construction
> of novel control structures.[/color]

Arguably, yes; but in the end any team (or firm working as a set of
fluid teams) that really wants such uniformity (and, it _should_;-),
can't rely on just the language, but must supplement it with an internal
"coding style" guide. It will supplement Python's rules by (say) PEP 8
and more rigid choices about capitalization of names (such guidance
about capitalization IS embedded in Ruby, btw -- one aspect where Ruby
promotes uniformity more than Python does); it will supplement Ruby's
rules by similar sets of style constraints. You can construct novel
control structures with Python's generators (particularly in 2.5, with
the already-accepted enrichments of generator functionality) just as you
can in Ruby by passing blocks to methods; whether you DO so on a routine
basis (rather than, say, in a few specific "common modules" that are
collectively accepted and maintained by the whole team or firm) does not
depend so much on the language, as on the team's/firm's central
collective coordination. (Much the same, in spades, could be said of
macros in Common Lisp, of course).

Yes, Python has a cultural, community value of "uniformity " -- that may
make it easier to convince Python enthusiasts of the need to agree
collectively on strict coding-style standards, compared to doing the
same convincing on enthusiasts of languages whose cultural values
include enthusiastic, exhuberant acceptance of individual variation.
But I do not think that such "cultural and philosophical differences" as
they apply to a whole community are more than a secondary factor in
determining the culture and philosophy of a specific team, or firm...


Alex

[Mike Meyer]

Re: Python or Java or maybe PHP?

"NOKs" <liorm@noks.com > writes:[color=blue]
> Thanks! That's really useful. I'm not sure if I'm a "dynamicall y 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?[/color]

Alex Martelli gave an excellent overview of this question, and his
answer ("Yes"). However, you're in a forum for dynamically typed
languages, so that's to be expected. In a forum devoted to statically
typed languages, you'll find people who will answer the other way,
using their experience and observations as the grounds for that
conclusion. What's notably lacking for both camps is any real research
on the subject. I've seen it claimed that the SPARK folks have that
research, but have been unable to find such. What SPARK papers I have
found concentrate more on correctness than productivity: IIRC, they
claim millions of lines of production code with no errors.

I wanted to point out that there are other more sides to this
issue. To start with, when you say "declare variables", you really
mean "declare variables TYPES". There are dynamically typed languages
where you have to declare every variable, and others where variables
spring into existence when mentioned. Python is halfway between the
two, requiring you to declare arguments, and only creating variables
when they are assigned to. As Alex mentioned, there are statically
typed languages where you don't have to declare the variables types
either. I'm just starting to look into this, and I don't know of any
that don't require you to declare all your variables as well.

Finally, there's a camp that pushes static typing up a notch,
practicing what's called "Design by Contract" (DbC). Languages like
Eiffel and D incluce DbC facilities. With these, you add extra code
that provides checks on the preconditions to a method invocation,
postconditions when it exits, invariants for an object, and various
conditions on a loop. This help with the DRY principle, as a good set
of unit tests would check all these things before and after each test,
so you'd have to code the checks (or invocations of them) for every
method invocation in every test. With language support, you only code
them once, and the compiler generates code to check them
automatically. Again, people who use them swear by them - but have no
hard data to back up their believes.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steven D'Aprano]

Re: Python or Java or maybe PHP?

On Mon, 02 Jan 2006 19:35:10 -0500, Mike Meyer wrote:
[color=blue]
> What SPARK papers I have
> found concentrate more on correctness than productivity: IIRC, they
> claim millions of lines of production code with no errors.[/color]

Writing error-free code is easy. That's just a matter of incremental
improvement of error-full code.

Writing error-free code *the first time* is hard. One wonders how many
edit-compile-test cycles it takes to get these millions of lines of
error-free code.


--
Steven.

[Mike Meyer]

Re: Python or Java or maybe PHP?

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:[color=blue]
> On Mon, 02 Jan 2006 19:35:10 -0500, Mike Meyer wrote:[color=green]
>> What SPARK papers I have
>> found concentrate more on correctness than productivity: IIRC, they
>> claim millions of lines of production code with no errors.[/color]
> Writing error-free code is easy. That's just a matter of incremental
> improvement of error-full code.[/color]

*Proving* that it's error-free is the hard part.
[color=blue]
> Writing error-free code *the first time* is hard. One wonders how many
> edit-compile-test cycles it takes to get these millions of lines of
> error-free code.[/color]

Dunno. But the SPARK folks are doing things where errors kill people
(airplane flight control systems being the example that comes to
mind). The amount they're willing to spend getting error-free code is
probably more than it is for most people.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[James]

Re: Python or Java or maybe PHP?

Now I am curious. How do Python 2.5 and Ruby create new control
structures? Any code samples or links?

Thanks.

[Alex Martelli]

Re: Python or Java or maybe PHP?

James <fphsml@gmail.c om> wrote:
[color=blue]
> Now I am curious. How do Python 2.5 and Ruby create new control
> structures? Any code samples or links?[/color]

A Ruby example of reimplementing while:

def WHILE(cond)
| return if not cond
| yield
| retry
| end
i=0; WHILE(i<3) { print i; i+=1 }

Python's a bit less direct here, but:

def WHILE(cond):
if not cond(): return
yield None
yield WHILE(cond)

i = 0
for blah in WHILE(lambda: i<3):
print i; i += 1

You need to explicitly guard the condition with a lambda to defer
execution (while Ruby's retry repeats deferred execution directly), and
explicitly use recursion to "loop forever", but conceptually the
differences are not all that deep.

Of course nobody would write such WHILE functions in either Ruby or
Python, since the built-in 'while' statement of each language is
perfectly sufficient, but I hope this suffices to show what we mean...


Alex

[Hans Nowak]

Re: Python or Java or maybe PHP?

Alex Martelli wrote:
[color=blue]
> A Ruby example of reimplementing while:
>
> def WHILE(cond)
> | return if not cond
> | yield
> | retry
> | end
> i=0; WHILE(i<3) { print i; i+=1 }
>
> Python's a bit less direct here, but:
>
> def WHILE(cond):
> if not cond(): return
> yield None
> yield WHILE(cond)[/color]

Maybe I misunderstand, but shouldn't this be:

def WHILE(cond):
if not cond(): return
yield None
for x in WHILE(cond): yield x

After all, the original version only yields two things: None and a
generator.

(Or is this behavior different in Python 2.5? I hope not...)

--
Hans Nowak

http://zephyrfalcon.org/