[GLLUG] PHP vs Python

Richard Houser rick at divinesymphony.net
Sun Nov 11 01:55:04 EST 2007

Hash: SHA1

Nicholas Kwiatkowski wrote:
> Why do you say that vendor issues prevent the use of .NET or ColdFusion?  I
> realize that .NET will lock you into a single operating system, but
> ColdFusion and Java are both cross platform.  Java runs on virtually every
> platform under the sun (no pun intended).  ColdFusion has multiple vendors
> (Adobe, New Atlanta, Smith, etc), so boxing it in because a single vendor is
> not fair.  ColdFusion runs on any platform that Java runs on (because in
> essence, 2 of the vendors package it as a EAR/WAR file that runs on a J2EE
> server).

The source is not freely available to either technology and Coldfusion
is owned by Adobe (and trademarked - single vendor).  I understand that
Smith is available as a third-party replacement server (single vendor)
that can run nested inside a J2EE container, but that doesn't make it
any better than .NET in my opinion.  If you already need to run J2EE,
why stack another layer on top of it instead of just running J2EE?  In
either case, I would call these significant vendor issues.

> While OOP is not a requirement of /any/ project, if you are working on
> larger projects, it greatly helps simplify some of the 'golden nuggets' of
> large programming projects.  Things like code-reuse and code modularity are
> huge time savers when working with larger projects.  These 'nuggets' simply
> can't be realized to their full potential in procedural projects.

I never doubted the benefits of OOP.  I just pointed out that even Java
or Python don't force you to write OOP code, as people will just stick
procedural code inside the objects if they don't understand the
concepts.  That will still be a problem, even for many programmers that
think they understand Java.  Python will at least make the code
readable, but the huge design flaws will remain.

> When working with web projects, while scripting based languages (interpreter
> languages) work, the don't scale well.  When every line of code needs to be
> evaluated for each hit on your site, you obviously loose lots of horsepower.
> This is the same reason why (at the time) languages such as BASIC (think
> back to q-basic) were SLOW and languages such as C/C++ ran much faster.
> They could both generate the same result.  This is a much larger deal when
> you have lots of heavy lifting that occurs, or when you have lots of hits
> that need to be processed.   With byte-code, the compilation is already
> done, and therefore the code doesn't need to be interpreted for each
> instance.

That is only somewhat correct.  With byte-code, the compilation is
PARTIALLY done.  Byte code is NOT machine executable and needs to be
translated into machine code to execute.  To avoid all the compilation,
you need to generate native code, which runs faster than the byte-code.
 The big thing that byte-code saves you in scripting languages is the
text parsing.  In the newer JVMs, bytecode will sometimes be compiled
into native code for specific segments and then executed natively, but
this just in time compilation does take a slight initial penalty.

The fact that the byte-code is in-between, however, limits the
performance of the machine as the code has to be compiled for the
byte-code specification and not to the limits of the hardware it runs
on.  This of course is a flexibility versus performance tradeoff.  In
the case of Java on an Intel, for example, an instruction for i++ will
look like this:

read memory into register;
increment value in register
copy register to memory;

Compiled natively, this would be a single instruction:

increment value in memory;

> I have worked on many websites that do some heavy lifting -- in the real
> world PHP is still seen as a toy, and .NET and Java are seen as the way.  If
> you look at the top ten websites out there, I can think only one that runs
> PHP, and even that uses PHP only for its presentation layer.

In the business world, I will agree that J2EE has vastly more
penetration on big systems than Python.  That was the primary reason
that I suggested it as a possibility.  Python on the other hand, forces
the developer to write at least readable code and does not rely on a JVM
that was until recently, proprietary and not portable to other systems
(SUN only supported a few platforms).

> -Nick Kwiatkowski
> -----Original Message-----
> From: Richard Houser [mailto:rick at divinesymphony.net] 
> Sent: Saturday, November 10, 2007 11:03 AM
> To: Nicholas Kwiatkowski
> Cc: 'Marshal Newrock'; linux-user at egr.msu.edu
> Subject: Re: [GLLUG] PHP vs Python
> I personally think .NET (even with the existence of Mono) or ColdFusion
> would be very poor choices for the project due to the vendor issues.
> None of the languages require OOP principals as they are quite easy to
> circumvent, but Python and Java certainly do encourage OOP use and it is
> considered the right way.
> As for the compilation issue, all the Python I've worked with ran from
> pre-compiled byte-code, so I don't think that factors in much.  Since
> this was supposed to be a web application, compiling to native machine
> code (Java - with gcc) wouldn't be all that useful of a feature.

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org


More information about the linux-user mailing list