Reboot PHP: keep the philosophy, improve the syntax (PHP on the JVM) | Hacker News Reader

Reboot PHP: keep the philosophy, improve the syntax (PHP on the JVM)

code.google.com

71 pointscemerick53 comments

As a long-time PHP developer (12+ years, yuck it up PHP haters) I look at this with a combination of awe and disappointment. Awe that someone would be willing to take on implementing a version of PHP that can run on the JVM much like Quercus. Disappointment because what they are doing is not PHP.

If the goal is to recreate the "let's build a better runtime" situation that exists in Ruby but in the PHP world, that is admirable. But if you really want the project to get any sort of traction, creating almost-PHP isn't the way to go.

If you can't run your existing PHP code in this thing, then what's the point?

Agree with the above. I've used Quercus in several projects - porting existing code to the JVM seems like a different use case than re-designing PHP.

http://www.caucho.com/resin-3.0/quercus/

I'm in your boat as a PHPer (11 years :)), but I like projects like this. I know you can't use your existing projects in it, but if it gains PHP some more respect from the general programming community, I'm all for it.

Considering one of the examples demonstrates running a SQL query in the middle of some HTML, I doubt much respect will be gained here.

Yeah, that's an epic fail of the 'awesome' things this implementation provides. Yeah! more horrible spaghetti code built in to the interpreter.

It reminds me of ColdFusion, e.g., CFQUERY.

That is never a good thing.

Some interesting examples there, but why not use EcmaScript 5 instead of PHP?

ECMA's a good choice, considering web developers should already be familiar with it, and (I think it's safe to say) it's a far better language than PHP.

A different language running on a different backend means making a clean break with all your old code. But anyone developing PHP has already made a decision to not make a clean break, otherwise he'd be using rails, node.js, django, clojure, catalyst, you name it.

What I'd like (and maybe I'll have to write if it doesn't already exist) is an ECMAScript-to-PHP5 compiler. Targeting the JVM is fine I suppose, but targeting mod_php5.c would mean PHP developers could dip their toes in more easily.

Every PHP programmer has lamented PHP's TMA (Too Many Ampersands) design, inconsistent method naming, function parameters order, etc. But PHP is the 800 pound gorilla with 15 years of momentum. It is what it is: a DSL written in C that's good enough at web development.

But you ain't gonna teach that old PHP dog new tricks without creating an entirely new language---in this case a DSL written in Java. When you get finished redesigning PHP, it's not PHP anymore. It's not even JPHP.

BTW, there are already languages that are free of sigils, semi-colons, and braces: Python and Ruby have been there for 15 years. If you need to do web development in those languages, they provide ample tools (Django, Rails, etc.) Both Python and Ruby have been ported to the JVM.

You want your existing PHP code working? So what you want is a port of PHP to the JVM.

But that doesn't really solve the problems of the PHP language.

As I understand it, the goal of this project is to solve the main problems of PHP. And that means of course to have it incompatible to PHP code.

If you're just looking to run existing php faster, then check out facebook's HipHop: http://developers.facebook.com/blog/post/358

I think this shows a remarkable misunderstanding of what PHP users actually like about PHP:

* We like semicolons. The culture who thinks saving this one character is valuable tends toward a non-pragmatic purity that is completely missing the point of PHP. We like to know when the line ends and to break up lines easily.

* The $ before all variables is a feature, we like this too. It's jarring coming from other languages but we think it adds readability.

* Inline SQL with no special syntax to denote that it is special? This seems way too far off the deep end of preventing an extra character at all costs. Give me a key word or a syntax if you like but don't make it look just like a variable, please.

* No from/to string auto-conversion. We like this too. Having the sense to not overload "+" for strings goes a long way here.

1 . 1 == "1" . 1 == "1" . "1" == 11 == "11"

1 + 1 == "1" + 1 == "1" + "1" == 2 == "2"

Yes there are warts and some paradoxes but we deal with it, and we have to be very conscious of what data could be provided by users, but our web apps work fine provided we know the language. (Yes, there are very many PHP programmers who don't.)

Re: "The $ before all variables is a feature [...] but we think it adds readability."

The argument for the $ sign is not readability. If it were you'd see JavaScripter's prefixing all of their variables with a dollar sign, too. var $foo = 'bar'; is completely valid JavaScript. (Aside: $ prefix is handy in JS when holding references to jQuery objects ie $container = $('#container');)

The argument is for simplified string manipulation with magic quotes and is an homage to unix shell scripting.

Without the $ prefix string manipulation would be reserved to concatenation/printf/replacement/etc. With the $prefix you can do things like:

   $base = __DIR__;
   $user = (object)array('name'=>'Foo','dir'=>"foo");
   $size = "lg";
   $image = "$base/users/$user->dir/images/$size.jpg";

vs:

   image = base + "/users/" + user.dir + "/images/" + size + ".jpg"

When doing a lot of string manipulation and scripting the $ is quite handy.

The dollar sign also enables variable variables and dynamic property access. i.e.

   $foo = 'Hello, world.';
   $bar = 'foo';
   echo ${$bar}; // 'Hello, world.'

- and -

   $user = (object)array('name'=>'Foo','dir'=>"foo");
   $prop = 'name';
   echo $user->{$prop}; // 'Foo'

The dollar sign for variable variables is weak because variable variables is usually an indication of code gone awry. Dynamic property access, on the other hand, is much more useful in a dynamic language like PHP/JavaScript. That said, I believe JavaScript's solution is much more elegant. i.e.:

   var user = {name: "Foo", dir: "foo"};
   var prop = "name";
   alert(user[prop]); // 'Foo'

By overloading the index operator on objects to accept a string that dereferences to an object's property you get the same benefit in a much more elegant way.

Thus the $'s primary justification is magic strings and string manipulation.

The $ also completely separates variables from the other namespaces, like reserved words. You can have variables named $if or $while and not worry about conflicts now or in the future.

Yes, all that, plus readability. I know when something is a variable. Prefixing variables in JS with $ doesn't do this because I still have to look out for things without a $ that are variables as well so it's the worst of all worlds.

> (Aside: $ prefix is handy in JS when holding references to jQuery objects ie $container = $('#container');)

I really really don't want to see that in a project I'm in charge of. It looks terrible to me, and I really don't like $ as an ordinary alphanumeric character. I like $ in jQuery projects to only be used for jQuery calls. (If it doesn't have to co-exist with something else and use noConflict mode.)

> var user = {name: "Foo", dir: "foo"};

I hate that about Javascript, how in object literals the left side is a literal string and the right side is an expression. Except, I really should quote the left side anyway - I think Crockford recommends this - because I might want a hyphen in there, or I might want to use a keyword (like "interface" where it isn't even obvious that it actually is a keyword.)

Also, if I have var key, and var value, I want to be able to pass it into a function that takes a dictionary argument as {key: value}, and not have to do var dict={}; dict[key]=value;

I also think Javascript absolutely begs for a real dictionary type. Objects don't work so well because I have to worry about someone extending them and I have to use hasOwnProperty - never mind someone could override hasOwnProperty. Also the performance characteristics of JS objects are terrible - Did you know that in Firefox a switch statement is one hundred times faster than an object lookup?

PHP's dual purpose variables are ugly as hell (with object -> syntax and array [] syntax) but I actually like being clear on whether I'm using it as an object or a simple array/dictionary.

> Did you know that in Firefox a switch statement is one hundred times faster than an object lookup?

A switch statement in what language? I presume by "object lookup" you mean the "bar" in "foo.bar" in javascript.

With all respect, I think you are worrying too much :)

> A switch statement in what language?

Javascript.

> I presume by "object lookup" you mean the "bar" in "foo.bar" in javascript.

Yes, but more specifically what I tested was the foo[bar] form, where bar contains a string, versus switch(bar).

> With all respect, I think you are worrying too much :)

For a language that is supposed to be nearly ready for writing rich interactive applications including pixel-by-pixel manipulation, two orders of magnitude (and widely variable across browsers) is a huge deal. I'm guessing you haven't tried to do much canvas programming?

I really don't like the $ prefix. The rest of your comment is OK.

the $ is perhaps my favorite feature. I love being able to easily scan the code which parts are variables, and which parts are strings. This comes in really handy when your page has php, js, and html hacked together because you can more easily tell what language the code you are reading is in.

I'd like to add 'we like braces'.

Braces are explicit, and guard against dropped lines.

Any decent editor can use color coding to contextualize variables and such: no need for syntax cruft. I'm a longtime PHP user and much prefer working in languages with less visual noise.

I don't think this project is properly leveraging PHP's advantages. PHP code's ability to be run on almost any server with Apache is a big plus, but this project requires a JVM. It's different enough from PHP that the plethora of PHP programmers will need to learn a new language, which is another hurdle. It's not backwards compatible so existing PHP code will need to be rewritten. In fact, it looks very different from PHP except for the intended use of the PHP library, which is one of PHP's weakest points.

The project has a lot of great ideas but I don't think branding it as a PHP derivative is one of them.

>This is a reboot of PHP, like the reboot of Star Trek.

So it's going to be a cotton-candy superficial take on a language with a deep and active user base that basically ends up making it no different from every other language of the month that people promptly forget about?

I dunno—the Star Trek reboot reinvigorated the series after lackluster box office performance. If you're looking for things ignored by the active user base and promptly forgotten, I think a better comparison would be the Ewoks movie... :-)

Wait, less ';'?

The semicolons are only optional in JavaScript if you are okay with being incompetent. Or, well, slowing down your programs a bit and risking errors through ambiguity.

The JSON style syntax is nice, PHP really needs that. I'd be pleased to never see or type => ever again.

I have no idea what to think about the rest. Inline SQL? Isn't some heinous mixture of PHP, SQL, JavaScript and XML all in the same file something that normal people would seek to avoid?

It's definitely interesting, but I think they should develop this as a separate language - specialised for the web. Inline HTML, JSON and SQL look excellent but to me this should be developed as a "new" language, so it is not bound by restrictions of trying to look like PHP.

See also links (http://groups.inf.ed.ac.uk/links/) which has lots of these things, but hasn't gained any traction probably due to it's academic origin.

But, I agree with your statement. Saying it's similar to PHP, or PHP++, or PHPReboot is just hype.

>> less ';' like in javascript

You should read the book by Douglas Crockford - JavaScript: The Good Parts, p102 (Appendix A: Awful Parts), this is not fun.

If only there was a programming language where you could write something like:

  do { foo; bar; baz }

or:

  do
    foo
    bar
    baz

and they would both be equivalent.

I'm not sure if your comment was intended as sarcasm, but you can pretty much do this in Ruby.

    myarray.each {|x| func_a(x); func_b(x); puts x }

is equivalent to

    myarray.each do |x|
        func_a(x)
        func_b(x)
        puts x
    end

Yes, I was being sarcastic. That's Haskell.

Whoa. I admire the chutzpah, and I definitely think aspects of PHP could use a Star Trek style reboot (albeit with less lens flare), but I also think the proposed syntax here actually makes PHP less clear.

My specific issues: As others have commented, fewer semicolons equals potential ambiguity. I'm totally not okay with the inline XML or SQL syntax presented here - clearly demarcated, storage-agnostic code makes me sleep soundly at night. That said, the duck typing and inline JSON structures are neat.

I don't really like the SQL integration. I would prefer an object layer on top of it.

Making assumptions about an underlying database is a sure way to get burned when you switch to another. And assuming SQL to be the "official" persistence engine makes it hard to migrate to non-relational platforms in case you want to.

I was about to make the classic "but how often do you switch to another" comment when I realised that every single one of my active projects uses both (MySQL or PostgreSQL) and SQLite.

upvoted for sincerity

It seems more like JavaScript changing more towards PHP than anything else. If that is the goal, then perhaps nodeJS is the solution.

I've been considering using nodeJS for more and more logic as time progresses, but truthfully PHP works 99.9% of the time.

I like my ';' - Even in javascript

If you really want inline XML and SQL, why not have some sort of quoting operator so that this is actually possible to implement sanely?

Programming languages designed by PHP programmers... the goggles do nothing.

Awesome. If it had first-class functions I'd be downloading it now.

But it has first-class SQL statements! Rock on!

I'd be curious to hear how PHP devs would contrast this with something like HipHop from Facebook (which requires a specific coding style and some restriction of PHP features).

This project has nothing to do with PHP, except that the letters P, H, and P are in the name and that it's a bad implementation of a bad idea.

I wonder if google will ever include PHP into Google App Engine ..

There's an implementation of PHP on the JVM Quercus: http://www.caucho.com/resin-3.0/quercus/

Presumably, you could run it now...

See http://phpwithjava.appspot.com/info.php

why?

Looks like an experiment, someone attempting to innovate.

From Rémi Forax's announcement on the JVM Languages Group (http://groups.google.com/group/jvm-languages/browse_frm/thre...):

It's as far as I know the first reboot of an existing language :)

The idea is to keep the spirit of PHP but change its syntax to natively support XML, SQL, JSON, XPath/XQuery, Perl5 regex, etc.

Embedding those DSL provides several benefits:

- better readability

- variable values are correctly escaped by default (no SQL injection, etc)

- integration into a common runtime type system which avoid runtime conversions

Unlike PHP wich is based on C runtime, PHP.reboot is based on the JVM which natively supports unicode, exceptions and provides a runtime optimizing environment.

PHP.reboot uses a gradual type system (not yet finished) and will soon get a runtime compiler thanks to JSR 292 API. The interpreter already use this API to speed up method calls and member access.

> It's as far as I know the first reboot of an existing language :)

What an absolute nonsense. As if nobody has ever re-implemented a language that already existed, it's maybe a first for PHP but it's more the rule than the exception that there are dialects of programming languages.