Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_gr_vy3b1SDYfLLh2kCAWR8psdAbEE4Hm38L1E6kGKY9A@mail.gmail.com>
References: <CADqTB_gr_vy3b1SDYfLLh2kCAWR8psdAbEE4Hm38L1E6kGKY9A@mail.gmail.com>
Date: Fri, 9 Dec 2011 12:22:55 -0700
Message-ID: <CALKFbxtzXOnNwGYQ15fQm9z+zPMWuMyy6hFLuSAf=hRiTbAAOA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Phalanger
From: chrisstocktonaz@gmail.com (Chris Stockton)

Hello,

On Thu, Dec 8, 2011 at 4:28 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> Don't take this the wrong way, I'm merely trying to provoke your thoughts=
 a
> bit with this e-mail! :-)
>
> Has it occurred to anyone, to abandon the official PHP codebase and adopt
> Phalanger instead?
>
> Some convincing (to me) points:
>
> - Phalanger runs on Mono, meaning similar platform-reach as PHP. (but
> eliminating most platform-specific implementations.)
>
> - It's fast. (probably fast enough to mostly eliminate the need for nativ=
e
> extensions in general.)
>
> - The community would be able to write modules/extensions in PHP or other
> CLR languages.
>
> - It's secure. (not that C/FFI PHP extensions tend not to be trustworthy,
> but they do tend to come from a relatively small group of authors.)
>
> - Access to more languages means a much bigger community who can contribu=
te
> extensions and core patches.
>
> - Access to existing CLR codebases means more third-party libraries can b=
e
> readily integrated without writing and maintainting C/FFI wrappers.
>
> - The codebase is new, clean and modern (it's not dragging around a lot o=
f
> legacy baggage.)
>
> - Fully take advantage of new 64-bit hardware (vector computations and
> larger address space) in all aspects. (core, extensions, PHP scripts).
>
> I'm not going to try to sell you on the fact that the integration with th=
e
> Windows world is tighter in Phalanger than in PHP - but it is a point tha=
t
> carries considerable weight =A0to many businesses.
>
> People I know have had a tendency to view Phalanger as "PHP for Windows" =
-
> it's really not. It's PHP for CLR - and CLR is not (only) Windows. And it
> is readily available on most modern operating systems with good support f=
or
> various hardware platforms.
>
> Now, before you start flaming me - I'd love to hear precisely why you're
> eager to hang on to the C codebase. What are the benefits of the C codeba=
se
> over Phalanger?
>
> I understand the licensing may be an issue. It may be the argument that
> outweighs everything else, but I'm curious to hear what else would keep y=
ou
> from moving to Phalanger?
>

I am not sure the response you are expecting, suggesting to abandon
the PHP project with over a decade of tried and proven work to
architecture that prohibits a great portion of the implementations
very attraction for a majority of large projects... furthermore doing
it on a list full of the very developers who have put in all this time
and effort is almost a bit ridiculous. If PHP ever took away my
freedom to write efficient C extensions for domain specific problems,
library integration or was better favored to a windows world I would
unfortunately have to move to another technology.

I would like to make note in no disrespect to anyone that I think some
graphs showing some bars larger then others, are meaningless to me in
the current state of technology. I haven't had to write a C extension
for performance improvements in years. Scaling web applications is
just so easy, the bottlenecks are almost NEVER in the web tier anymore
and when it does reach capacity provision a new web box and voila.
What is expensive ($$) is data storage and network communication
(performance) to external service providers (fb api, openid, twitter,
internal enterprise services, pick your api).

Just a couple thoughts from me and my experience, in a nut shell it's
great to see work on alternative implementations that better fit a
specific group or set of groups problem domains, but such a drastic
statement as to drop the current implementation and start anew is
pretty far away from logical :- )

-Chris