
Rewriting PHP - qhoxie
http://pooteeweet.org/blog/0/1418
======
Scriptor
This is a great idea. I'd love to see a language that was somehow compatible
with mod_php yet was redesigned with sound principles in mind. PHP is
handicapped in that it started as more or less of a tool for counters, and
also because its inner workings don't seem to change very much.

It is because of this that major new features seem to be dirtily patched on:
Namespace separators require a completely new syntax, anonymous functions that
inherently can't behave like closures. Also, the language just seems like a
meddle of things that have to be forcibly patched together to work together.
For example:

    
    
      array(1,2,3)[0]
    
      (new FooObject())->some_method();
    

Neither of those work, yet the equivalent works in other languages.
Personally, I like the idea of a language where new features emerge out of
smaller bits bit put together in different ways. This is clearly not how it
works in PHP.

~~~
mst
This is where, for all its mistakes, perl5 has won big - the core language
itself provides basically an OO construction kit, and so over the years CPAN
has iterated repeatedly towards better object systems.

The latest, Moose, which is rapidly taking over the perl world, comes close to
providing a superset of the features available in competing languages - and
with the advent of the Devel::Declare syntax creation system we're able to add
new keywords to support this, resulting in the MooseX::Declare system.

While people often complain that perl5 should have these things out of the
box, I think it contributes to the longevity of the language to be able to
provide them externally on a solid core - if somebody comes up with a better
set of ideas, new code can switch to using those, and current code will be
unaffected - as we're currently seeing with projects using Moose for new code
without having to touch any of their existing classes.

~~~
fizx
What's with the downvotes? I found that insightful.

------
bprater
The future is languages that target a VM. Once you have a VM humming along on
any webserver, you can apply any language you want to that VM.

If today's PHP used a VM, writing a "new PHP" would be pretty straightforward.
You wouldn't have to worry about backward compatibility since "old PHP" would
target that same VM, too.

You could use the basic syntax, do all your fun namespacing, break oldly named
functions out of the core language, etc.

If someone attempts the build a "new PHP", targeting Parrot or the JVM would
be the way to go.

ColdFusion made a similar break a few years ago. They rebuilt the entirely
language in Java, and now ColdFusion is basically a layer on top of Java.

~~~
old-gregg
_The future is languages that target a VM_

I hope not. You may be predicting the future, and there are many indicators
pointing that way, but I _hope_ you're wrong.

VM design is never 100% language-neutral. Targeting existing VMs means
inevitably accepting VM limitations and letting some of the original language
design choices go. Even things like float point arithmetics, threading and
exceptions support are pretty much dictated by your choice of VM. JRuby's team
has been constantly struggling with JVM internals [and still couldn't get
continuations] and Ruby on LLVM was considered by many to be too difficult to
implement. _And Ruby isn't very unconventional_.

Furthermore, commercial VMs tend to be heavy platform-dependent pigs and by
targeting one of them you're inevitably denying your language the right to be
called "general purpose". By platform dependence I mean that Ruby.NET has to
deal with a single "system instance" of .NET, assembly cache and other crap,
i.e. things outside of language designer's and software author's control.

And finally, you will never be able to port your language to platform X if
your favorite VM isn't available there. I can run C and Python programs on my
router. C# or Java? Nope.

~~~
thwarted
"VM design is never 100% language-neutral."

The goal for VMs should be to create a generic enough base machine
infrastructure such that you end up with the same capabilities and flexibility
that the x86, PPC or any other hardware/microcode based architecture provides.

VM design may not be language neutral, then maybe some VM designers could
learn something from hardware/chip designers. The very reason we're having
this discussion is because ANY language can be implemented on ANY of the
general purpose hardware architectures available.

The problem arises when things like sandboxed execution and optimizations for
a specific runtime or language come into play. These are the kinds of things
that tie a VM to a specific language and platform. Associating a VM with a
runtime also confuses the technologies; admittedly this is often done because
the company pushing their VM product has a vested interest in also providing
developers with the tools and the libraries and the UI they program to.

~~~
blasdel
_The problem arises when things like sandboxed execution and optimizations for
a specific runtime or language come into play. These are the kinds of things
that tie a VM to a specific language and platform._

That's just superficial stuff -- the real VM language constraints are things
like: calling conventions, type-checking, data structure semantics (esp
objects), GC, and module interfaces.

These are the kinds of things you want to have shared among languages if you
want a useful multi-lang VM. Otherwise what's the point?

~~~
eru
Type-Checking in the VM? One would have to think hard to accomodate a diverse
range of type systems on this level.

(And the Haskell guys keep expanding their type systems all the time.)

~~~
blasdel
"Type-Checking in the VM" means support for runtime type-checks, which can
take several forms.

In Haskell, all that type-checking is happening only in the early stages of
the compiler -- and then the types are erased in the later stages.

------
k4st
The following is a comment I made on Reddit
([http://www.reddit.com/r/programming/comments/7aiex/php_forke...](http://www.reddit.com/r/programming/comments/7aiex/php_forked/c0648fo))
some time ago on the subject of PHP being forked:

As I tend to work with php a lot I often think about how to make PHP better
and given that I like functional programming, more functional. Here are a few
of the ideas I've thought up:

Putting a $ in front of a symbol, e.g. $var is equivalent to defining and
requiring that variable to be within, and only within, the current lexical
scope. Given that within PHP, if/for/while/switch statements don't create new
lexical scopes, everything would still work as is. The benefit would be to say
that $ is no longer required such that variables could now be accessed without
$, as is the case with functions. A symbol without a $ would be one that goes
to each parent scope and either looks for the existence of a symbol. This is
consistent with how current PHP functions works because currently all PHP
functions belong to the global namespace, ie: they all are part of the root
scope. So, this establishes that variables don't need to be preceded by $, and
that $ is an operator that says look at the local symbol table for variables.

The above model sets the stage for variables being passed down through child
scopes and functions as well. That would all for proper closures that don't
require parent scope variables to be used be explicitly defined. This also
means that functions defined within functions (legal PHP) would not be put
into the global namespace (this is inconsistent with previously versions of
PHP).

Finally, most symbols will either be values (in the cases of scalars, arrays,
etc), instances (in the case of class instances), references, resources
(function resources, other resources), or a few other data types that PHP
currently supports. So, the symbol 'substr' is a function resource to the
substr() function and '$substr' is only defined within the root scope as the
same function resource. The idea of function resources is consistent with how
PHP 5.3 implements anonymous functions.

ex) If within the current scope one defines '$substr', then both 'substr' and
'$substr' will point to that something else within the current scope and all
subscopes.

ex) If '$substr' is not defined in the current scope and one redefines
'substr' in the current scope then the actual 'substr' reference is changed
for all scopes after that.

</braindump>

------
russell
Backwards compatibility is pretty much a requirement for a widely supported
language, otherwise you impose a huge amount of pain on your user base and may
kill he language in the long run. Java and Python have pretty much tried to
maintain backwards compatibility, Python 3 notwithstanding. OTOH not moving
forward in language design also means a slow death as your users move on to
more capable languages/frameworks. As the article says, the future of PHP is
probably neoPHP, a fork that cleans it all up.

Java is another language that needs to break with the past and may ave already
done so in the form of Groovy, Scala, and the other JVM based languages. I
think the constant churn in Java frameworks is an indication that something is
wrong. PHP, at least, has managed to evolve.

------
halo
I've long thought one of the biggest problems with PHP, the ugly inconsistent
non-namespaced standard library, could be fixed without breaking backwards
compatibility.

While keeping the current function-names for backwards compatibility, move
them all into namespaces while correcting syntactical inconsistencies, poor
naming and other problems. In the long-run, deprecate the old function names
and move the old PHP4 functions into an PHP.ini switch or importable library.

------
compay
I agree with the author that while PHP is aesthetically ugly, it works well in
its niche and already has so much momentum there's basically no point to doing
a rewrite.

I also think a rewrite is poinless because in many ways Lua is already a
better PHP. It's easy to learn, blazing fast, small and portable. You can
easily embed it in web pages with <? or <% tags just like PHP and other
scripting languages.

As far as I know the only thing missing is an Apache module of the quality of
mod_php. There is a mod_lua, though it appears to have been neglected for a
while.

So rather than a rewrite of PHP, I'd rather see someone put the time into
getting Lua up to snuff for solid web development, because it's already pretty
close.

~~~
danw
Have you used Lua for building web apps? I'm thinking of giving it a try.

~~~
compay
I've been looking into it for a couple weeks and am about to do some "hello
world" apps this week. There's some interesting stuff in the Kepler project
but the available libraries are definitely pretty low compared to a lot of
other languages.

~~~
jrockway
The good news is that at least Lua has the core language features you need to
implement good libraries and extensions. It also has very nice syntax for a
non-Lisp.

If Lua became the new "standard" for web development, I wouldn't complain at
all. I probably wouldn't use it, but if I had to, it wouldn't be bad :) (I was
recently forced to do some PHP and Java projects. Wow. Never again.)

~~~
danw
Lua seems like a cross between javascript and python in terms of style. Has
anyone built a server side javascript app? Or have access to Rhino on Rails?

~~~
LogicHoleFlaw
Similar in terms of style, maybe, but conceptually Lua is extremely close to
Scheme. It's an extremely intentional resemblance. The language core is very
clean, concise, and consistent.

------
shaunxcode
Take advantage of the ubiquity of php4+ and write languages that compile TO
php... Maybe I am crazy but it's working well for me thus far! I should be
releasing a full r5 scheme implementation soon.

~~~
jrockway
While writing Scheme is probably better than writing PHP, how are you dealing
with PHP's poor support for ... everything? I am really interested in taking a
look at this code, especially your tail-call elimination algorithms and the
continuations implementation.

~~~
shaunxcode
One of the interesting things about php is that it does NOT lack support for
many of the cool paradigms and libraries it just has a very ugly way of
showing it.

Continuations really aren't that hard and are represented by a very simple
class. As far as tail call elimination goes right now I am ignoring it (I know
that means it is not technically r5) SAYING THAT I have an idea for
reformatting such cases into an iterative form (sort of likes rubys redo) but
it's on the pile labeled optimization.

------
sam_in_nyc
I really would love to see multiple inheritance. I don't understand why it's
such a faux pas in OO languages. "Ohh... the functions might have the same
name!" they say. Big deal! First one in wins, or last one in wins, I don't
care, just pick one.

