6 ms·

Rewriting PHP

24 points by qhoxie 18y ago

Scriptor 18y ago
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 18y ago
  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 18y ago
    What's with the downvotes? I found that insightful.
- eru 18y ago
  I was bitten by something like array(1,2,3)[0] once. I got especially mad because it is the php parser that throws up. That thing must be full of special cases.
russell 18y ago
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.
compay 18y ago
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 18y ago
  Have you used Lua for building web apps? I'm thinking of giving it a try.
  - compay 18y ago
    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 18y ago
      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 18y ago
        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?
halo 18y ago
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.
bprater 18y ago
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.
- gsmaverick 18y ago
  I think that targeting Parrot or JVM would be a bad idea, because that would break the simplicity of the PHP installation we have today.
  - jrockway 18y ago
    mod_parrot should be just as easy to install as mod_php. Tomcat is also as easy to install. Deployment in any language is not much of a problem on machines that you control. PHP is popular because of mod_php shared hosts that charge $1/month. Paying a dollar is apparently an easier way to get started with programming than `apt-get install <a real language>`, hence PHP's popularity.
- old-gregg 18y ago
  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.
shaunxcode 18y ago
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 18y ago
  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 18y ago
    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.
- jamongkad 18y ago
  That kind sounds like what the Haxe Project is doing now.
  - shaunxcode 18y ago
    Interesting - my approach is to have the entire thing written in php so there is no incurred "cost" of having to install anything or compile from one framework to another.
    - jamongkad 18y ago
      Hang on you're writing a Scheme that compiles down to PHP?
k4st 18y ago
The following is a comment I made on Reddit (http://www.reddit.com/r/programming/comments/7aiex/php_forked/c0648fo http://www.reddit.com/r/programming/comments/7aiex/php_forke...) 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>
sam_in_nyc 18y ago
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.

24 points by qhoxie 18y ago

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 18y ago
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 18y ago
  What's with the downvotes? I found that insightful.
eru 18y ago
I was bitten by something like array(1,2,3)[0] once. I got especially mad because it is the php parser that throws up. That thing must be full of special cases.

russell 18y ago

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.

compay 18y ago

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 18y ago
Have you used Lua for building web apps? I'm thinking of giving it a try.
- compay 18y ago
  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 18y ago
    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 18y ago
      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?

halo 18y ago

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.

bprater 18y ago

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.

gsmaverick 18y ago
I think that targeting Parrot or JVM would be a bad idea, because that would break the simplicity of the PHP installation we have today.
- jrockway 18y ago
  mod_parrot should be just as easy to install as mod_php. Tomcat is also as easy to install. Deployment in any language is not much of a problem on machines that you control. PHP is popular because of mod_php shared hosts that charge $1/month. Paying a dollar is apparently an easier way to get started with programming than `apt-get install <a real language>`, hence PHP's popularity.
old-gregg 18y ago
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.

shaunxcode 18y ago

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 18y ago
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 18y ago
  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.
jamongkad 18y ago
That kind sounds like what the Haxe Project is doing now.
- shaunxcode 18y ago
  Interesting - my approach is to have the entire thing written in php so there is no incurred "cost" of having to install anything or compile from one framework to another.
  - jamongkad 18y ago
    Hang on you're writing a Scheme that compiles down to PHP?

k4st 18y ago

The following is a comment I made on Reddit (http://www.reddit.com/r/programming/comments/7aiex/php_forked/c0648fo http://www.reddit.com/r/programming/comments/7aiex/php_forke...) 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>

sam_in_nyc 18y ago

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.