PHP has only one feature going for it: it already exists. As soon as you introduce a new programming language, you lose what PHP has to offer. Another success is the lack of a library culture -- just copy-and-paste code into your app, and you never have to worry about installing dependencies on your shared host.
If you want a better version of PHP, try Perl / Python / Ruby. If you want a language that can check your code for safety at compile-time, use Haskell. But if you invent your own language, it will have three problem: nobody will know how to use it, it won't be installed on any three-dollars-a-month shared host, and it won't have any libraries.
If you can't solve the "I want to use it for $3 a month" problem, your programming language is a failure compared to PHP. If you can afford more than $3 a month for hosting, then you're not using PHP anyway. Most people learn to program because they want to share something with their friends. They choose PHP because it lets them do that, and they don't have the experience to know that They Are Doing It Wrong. By the time you introduce a PHP "reboot", you're not going to get that "Don't Know That I'm Doing It Wrong" crowd anymore, and then who's your audience?
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.
The stated goals of this project aren't the ones I would have picked, but I'm sympathetic to the motivation behind it.
I think that a vastly cleaned up PHP (PHP6 or whatever) would attract the millions of loyal developers that PHP already has.
Many people just don't appreciate how much mindshare PHP has in parts of northern / central europe. And for those people it's not about $3 hosting, for them it's a proven workhorse language in which they can get things done on the web.
Not to mention that a business culture has grown up around these localised skill concentrations in which lots of businesses are now run on PHP.
I think when you say, "PHP has only one feature going for it: it already exists", you are vastly over trivializing steamroller-like traction and market penetration.
"for them it's a proven workhorse language in which they can get things done on the web" ... which has a lot to do with its broad adoption (and thus easy hiring), and with certain software packages like Drupal, WordPress, Moodle and so on.
When has the elegance or power of a language ever been a consideration in the general business culture?
It hasn't been the case with Fortran or COBOL, IMO. And both are still used, despite being "dead," to maintain legacy systems that companies can't quite afford to replace yet.
But if he's creating a new, unrelated language and calling it PHP, all he's doing is hijacking that "steamroller-like traction and market penetration" anyway.
Exactly. Most other web languages have this issue: You start from (1)"Here is how to do xyz. Fun huh" and (2)"Here is how you start working on your webapp."
Step 2 involves getting a server somewhere (as opposed to mamp or $3 hosting). Deciding on a framework (or no framework). Probably some command line stuff. etc.
With php, there is no step 2. Some of what you do in step 2 php programmers might want to do anyway (eg install a framework) but it's not necessary for starting out.
Upsides and downsides to that, I guess (I'm not a programmer) but that is core. If you could take that (MAMP-like installation, through your code into html, etc.) and use another language (including an existing one) I think you would have something.
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.
I wholeheartedly agree. "phpreboot" isn't PHP, it is a new programming language that looks similar to (or shares traits of) PHP.
I'm not sure how this gains traction associating itself with PHP. As a currently PHP developer, I'm certainly not going to hitch my wagon to something that looks to be a forked version of PHP.
- Bigger community, thus more resource documentation out there (Perl has Perl Monks going for it).
- More MVC frameworks (CakePHP, CI, Symfony, Lithium) vs. Catalyst.
- PHP has a cleaner syntax
I'm biased to PHP so of course I think it's better. For someone getting started with web development, I would recommend PHP over Perl. That is not to say that one should never "explore" Perl. Hell, Lawrence Livermore Labs uses a lot of it.
As Perl was developed originally as a scripting language for unix, it is fast, but I don't think it's well suited for the web (my opinion).
Plus, like the troll below me said (who apparently wrote a book on Catalyst, hence his bias), PHP was highly influenced from Perl, so if anything PHP is an alternative to Perl, not the other way around (like the OP mentioned).
I don't suggest Perl because I wrote a book on Catalyst. I wrote a book on Catalyst because I suggest Perl.
Anyway, here's what Perl has going for it:
* a larger group of core contributers
* an order of magnitude more modules (and module authors)
* Moose
* excellent Emacs support
* higher average level of proficiency among core team, and module authors
Ultimately, CPAN is the reason for using Perl. But after doing a lot of work in Python, I do really appreciate the things that Perl has built-in, too, like all-encompassing regexes.
They use it cautiously and reluctantly because they don't have much choice at this point. The Asana and Quora founders ditched it at the earliest opportunity.
Clearly, Facebook is in a different PHP area than your bog-standard $3/month crowd. Facebook has an advanced PHP tool chain that compiles PHP down to C++ (hip-hop)and they reap performance gains from that. They also built PHP repl (phpsh) because `php -a` sucks.
But to be fair, their PHP is a subset of the official PHP, and they probably use all of their own libraries (rather than the ones you have access to outside of Facebook).
So if you want Facebook to be your PHP success story, all you get out of it is "PHP didn't kill their company; they were eventually able to move away", which I suppose is not exactly a swimming endorsement.
Hi guys,
I'm the author of PHP.reboot and also one of the guys that worked on JSR 292 (invokedynamic in Java).
First, I don't know based2 and please don't be too serious, PHP.reboot was written as a small prototype to see what can be done on top of invokedynamic. It was also used to debug the hotspot implementation of JSR 292.
The language is tailored unlike any dynamic languages. Instead of adding features and wondering how to optimize them after, I have worked backward and carefully pick/design features only if I was able to optimize it to be at least as fast as Java.
The hidden jewel of PHP.reboot is its runtime which first interpret the script and then use a type inference/type checker algorithm to try to emit exactly the same bytecode as javac.
So some parts of the language are quite fast, but not the whole language because some parts still run in interpreted mode only.
As a demo, I've taken the mandelbrot benchmark from the Computer Language benchmark[1] and write it in PHP.reboot
(I hope with no mistake). Here is the result on my laptop:
[forax@localhost phpreboot]$ time bin/phpr.sh test/mandelbrot.phpr >/dev/null
real 0m34.189s
user 0m34.087s
sys 0m0.088s
You can compare with your favourite dynamic language :)
If you're serious about this moving forward, I very strongly suggest renaming it. PHP.reboot is a very hostile, aggressive name that is clearly trying to steal thunder. Call it a reboot of PHP informally, playfully base the name off of PHP somehow, but don't outright call your language "PHP.something that Google won't correctly parse as part of the same word so the search will still pull up nothing but PHP results". In addition to the hostile nature of the name, being effectively Google-blacklisted isn't a great way to start.
Also, admittedly off of just a glance, beware the specialized syntax sinkhole. Can I easily take two XML snippets and compose them together somehow? Can I easily take two SQL snippets and compose them together? A lot of times these specialized syntaxes make for cute-looking demos but in practice work out worse than just using language constructs because they are so highly specialized you can't do anything with them but exactly the one use case the author had in mind. I'd submit there's a reason that basically no large-scale successful language has this sort of specialized syntax built into it, and you may want to ponder on those reasons until you understand them. It isn't because it's hard to write the grammar or anything implementation-related like that. (And I'm not saying don't do it. Personally, I think it's a solvable problem. Look to LINQ for what is probably the closest to date. I'm suggesting you try to spend some time understanding why the obvious solutions haven't worked before you go too far down what can be a language-killing rathole.)
Here is why I've chosen the name the language PHP.reboot.
My father ask me to patch one of the page of his website written in PHP
so I've written one page of PHP. 3 days later, my younger brother (not 18 years old at that time) call me and ask me to never touch a PHP page again because I had introduced 3 security holes.
It was a painful day for me, I have a Phd in Computer Science, I study computer languages, compilers and runtimes but I'm not able to write a correct PHP script.
That's why I think I own the right to call this language PHP.reboot.
Don't get me wrong, I think the project is a neat one. I like the features, I like the goal, and honestly I just like new-language projects in general. So please don't think I'm hating on the project.
But your argument for the name is so utterly broken.
First of all, having a PhD in CS and introducing 3 security holes is no reason to blame the language. It's not even necessarily a reason to blame yourself. Since when is a PhD in CS supposed to make you a good software engineer? If it is, I know a lot of PhDs who got a raw deal.
Second, how does your language fix the three security bugs you introduced? The only security feature I see in your highlights list is "secure by default: no eval, no magic quotes/string interpolation". 99 out of 100 competent PHP programmers force magic quotes off (so if your brother didn't, he can shut up), and most bugs that can be introduced with string interpolation can be (and usually are) introduced with string concatenation (which I assume you can still do).
Third, the main thing you demonstrated with this story (as others have said) is that you aren't very good with PHP. That's no big shame, but it's also not a reason you "own the right to call this language PHP.reboot". This reasoning is crazyface.
Fourth, as others have said, calling it "PHP.reboot" just confines it to the ghetto. If it were to grow, people wouldn't be able to search for articles/blogs/forums/help/mail/etc about it without getting lost in the PHP (even admitting that for me googling "php reboot" does return your google-code repo). And right in the name it says "I'm the wanna-be little brother of the big successful language". Although I don't think this last criticism is a problem, because I assume the goal was not to actually replace PHP, because that's impossible for reasons others have mentioned. So, no big deal.
The GOOD argument for the name is "It's just a toy language, so it doesn't matter what it's called, and rebooting PHP was my motivator when I started this particular project."
Oh, and as an aside, if one page of PHP is your web programming experience, then you really should probably not be shipping an HTTP server.
I agree with you, I'm not a good PHP developer.
Before that bad experience, I was thinking that PHP was a kind of visual basic for the Web. Easy to write, fast to get something.
I was wrong, that why I've called my language PHP.reboot because I think that PHP in 2010 should be rebooted to be secure by default.
Now, the main point of this toy language as you call it is to demonstrate that a dynamic language can be fast if you don't design it with an interpreter in mind.
BTW, I really hope that this is what Dart is.
> Oh, and as an aside, if one page of PHP is your web programming experience, then you really should probably not be shipping an HTTP server.
I disagree. How are webprogramming skills applicable to writing a HTTP server? Seems to me the relevant skill would be network programming and my (admittedly limited) web developing experience leads me to believe the skills are mostly if not completely disjoint...
Yeah, that's absolutely true, so I overstated my case somewhat on that point (although in my defence I did say "probably"). So, in place of the mis-stated claim in my original comment, let me try that part again.
Writing robust high-load network servers is actually a little tougher than it seems, and the skillset has very little overlap with the "designing a nice language" skillset, or the "making an efficient compiler" skillset. And not only is robustness is important, but to be useful it probably needs a lot of auxiliary features like HTTPS and authentication and logging and FSM-knows-what-all (this point, on which features matter, is the only place that web-programming experience might actually be relevant). And so tacking a half-assed HTTP server onto your new-language project is, well, half-assed. And IMO, there are enough shitty toy web-servers out there already.
As much as I hate just citing a logical fallacy, that's a nonsequitor. You "own" the name because... you can't program in it after what must have been entire hours of effort? If we're going to go down that route at all, that's an argument that you don't have any right to the name, since you've put next to zero effort into it.
Of course, the real reason is that no, you don't own the right to the name, in any sense, but hey hoo, carry on, whatever.
What's with the attitude? Remi just explained the background for the name of his neato prototype PHP-like project. I don't see why that deserves these kinds of snarky replies.
That's the worse reason I've ever heard of to create a new language. If I was asked write ruby or .net or java it probably wouldnt be great code either. That doesn't mean they're language issues, that means I don't know those languages, plain and simple.
Php reboot has less to do with php being broken and more to do with your ego refusing to accept that you're not the worlds nest programmer.
No, unlike PHP, PHP.reboot is secure by default.
That's why PHP.reboot use DSLs, because it enables the runtime to know the context thus sanitize the inputs by itself.
As for "Secure by default". PHP can be perfectly secure. PDO supports parameterised queries, and was first available in PHP 5.1, which shipped just short of SIX YEARS AGO. Even mysqli supports parameterised queries, and that shipped more than SEVEN YEARS AGO.
If you're using the ancient mysql extension (i.e. the mysql* functions) that is YOUR FAULT, not the fault of the language.
but one advantage of having different syntaxes inside the language is that you don't rely on strings to do everything.
So your language is more secure and can have better performance because by example for the SQL syntax you can produce a tree instead of serializing your request as a string.
It's cool to do it as a prototype language, but I doubt someone would make use of it over php. Until someone ports drupal or wordpress to "the next php language", php in the current form probably isn't going anywhere.
Sometimes on rainy nights when I've had a few too many glasses of wine, I dream of doing a PHP "reboot": something with syntax and features like C#, which I personally love, but without the sometimes deceptive magic that goes on behind the scenes of stuff on the .NET stack. Just output HTML to the browser, no compilation required, arrays like PHP, and sane and useful built-in libraries. FOSS.
Sometimes I even think it would be a good idea to half-ass it and just create a "wrapper" type library to map built-in PHP functions to namespaced and standardized (naming, parameter order, etc.) functions.
Then I usually wake up in the morning with a bad hangover and a deep sense of sadness.
What exactly is the philosophy of PHP? You should write a bit about it on the project page.
Right now it looks like a completely different language, and you might as well just give it an original name. I'm having a bit of a hard time seeing the connection to PHP here.
They didn't make it very clear, but I think the embedded SQL idea is meant to be for things like querying against collections, similar to LINQ[1]. Even it's meant for databases, it's still up to you where in the app you put it.
That being said, my initial reaction is to wonder why, when designing a new language, one would model after PHP of all things.
Yeah I'm also not a fan of linq. Or at least not in my PHP.
I think something like underscore.js[1] would be much more in the style of PHP - I always thought PHP and JS were similary in their wackiness - and I would much prefer it to LINQ.
As far as modeling after PHP, there are things I'd leave/take, but really the biggest issue is the standard library.
Really? It's cleaner to have queries represented as strings than as a language-integrated syntax that can throw errors at compile time? To each their own, but if I had to guess, I'd say you've got a minority opinion there.
I doubt it's a minority opinion, at the very least amongst PHP devs. Having it as a string allows me to pass it to a logging function, or output it in a debug console, or send it to a query pre-processor that adds the right database prefix for the current app, etc.
As encoderer said, you can definitely do that in Linq. The query operators basically just map to methods, which are overridden by the different providers... The SQL ones basically create SQL statements for you behind the scenes (as log gable strings).
I thought it was all kind of weird and wrong at first too but now it's probably my favorite c# feature next to the (very much related) lambda expressions, especially for non-SQL collection queries. Of course this doesn't mean PHP needs integrated queries or anything, but it is a very nice feature to have if done right. XML/json literals, on the other hand, do feel kind of wrong to me though (although I bet they are handy still, as many vb.net devs will probably attest to).
Here's a contrived example to demonstrate the value of sigils:
/* in version x of SFL (Sigil-Free Language) */
school = get_school("Saint Fred's School For Girls");
class = get_class(school, "Agricultural Studies", 12);
yield = get_agricultural_yield(class, "Turnips", 2011);
printf("The Year 12 Ag Studies class produced %d turnips in 2011", yield);
Now we try upgrading to version x+1 of SFL, which adds object-orientation and concurrency (it was a BIG upgrade!). Now three of the lines in that four-line program contain errors, because "class" and "yield" are no longer valid variable names, having been turned into keywords.
In a language with sigils, that's no problem. It also makes it easier (therefore faster) for syntax highlighting to spot where variables are used, without needing a full dictionary and an exact version number - that makes a difference for me as an Emacs user especially.
etfb is on the right path, but for me it just feels right. I guess that's just a personal preference, but the dollar sign is a visual indicator that a particular string is a variable, and not a function call.
For me, it makes a big difference in languages like ruby where you could either be calling a method, a monkey-patched method_missing callable, or a property in some scope.
Well, in PHP you already have a mandatory '()' at the end of function call - so it's pretty hard to confuse the two.
Additionally if your language has first class functions, it would feel kind of strange if names of some functions started with $ and others without it.
Good point. If variables can be functions and functions can be represented by variables, variable naming rules would to apply to functions both declared and assigned. Which is to say all functions. The $sigil would have to melt away or be everywhere.
When will people realize that the main reason PHP was/is so successful has nothing to do with the language? PHP got huge because it's free and super easy to deploy on commodity-level hosting. Ubiquity breeds popularity.
Basing a reboot on the JVM makes little sense in this context.
That said, you lost me at "less ';' like in javascript".
IMO you are only partially right and some of PHP's success does have to do with the language and not just availability.
As horrible as PHP is, it is really easy to sit down with PHP and a tutorial or a book and start banging out code that gives you instant results. PHP is like the MS Basic 2.0 of the web era -- people who aren't really programmers (yet?) can sit down with it and GTD right away -- their code may be ugly but they can see it working as they go. They don't have to learn what a 'WAR' directory is and how it is structured, they don't have to mess around with xml configurations, etc. The ubiquity helps, certainly, but IMO the reason it got ubiquitous is how easy it is to go from nothing to "hello web world".
I think a project that maintains this instant GTD environment but improves the language is actually quite a good idea, though I also think cutting ties with PHP by giving it a new name makes more sense than calling it phpreboot and once you involve Java it seems less likely PHP's context-free easy start-up will be maintained.
As horrible as PHP is, it is really easy to sit down with PHP and a tutorial or a book and start banging out code that gives you instant results...
You could say the same thing about ASP, or even ColdFusion.
I'd argue that those instant results had more to do with the higher availability of PHP on cheap web hosts, than the accessibility of the language itself.
That's exactly right. I learned to code from a PHP book a decade ago, and now I am using the excellent OOP Symfony2 PHP Framework. The full spectrum of options are already available with PHP, the language and its frameworks lack nothing.
It lacks a coherent design philosophy; it's a collection of hacks; a house of cards with no style. It's full of idiosyncrasies that must be memorized because they make no logical sense. Put simply, it completely lacks taste.
Right, and under the category of easily:
What languages do you already know,
What languages are you already actually comfortable using for a large scale project, and
What is the production server running.
If the answer to all of the above is PHP, then you're going to get projects done faster there than you would in Python or Ruby.
Being able to do something like install Apache with modphp in one go and then just put a file into the correct directory and have it execute code is without a doubt the most low barrier way to get started. Other languages are catching up though, but taking a different route (e.g. hosted platforms like Heroku).
Why, when "rebooting" PHP, do you still keep the inane non-object arrays? Why not either/both create a syntax for manipulating arrays, or promote arrays to objects with their own methods.
When I see special functions which exist to do basic array-as-list operations, like his `add()` function, my eyes roll. Then I see arbitrary, inconsistent use of the dollar sign to indicate variables and they start to bleed -- you either have a dollar sign or not, but pick one and make it work.
When the language designer adds features at whim, without considering whether or not his implementation is keeping consistency or breaking it, well that's how you get a language like PHP in the first place!
what might make sense is to only implement the SPL stuff, and force all array access to be objects implementing the SPL interfaces. it would hurt 'ease of use' compatibility, but would enforce as a standard something that's already defined in PHP.
Interesting, this is by Rémi Forax who is involved in the Asm Java bytecode manipulation library[1] as well as hacking on all kinds of other Java related stuff.
He's got a blog post here with some initial performance tests:
Looks really fast when using type annotation (edit: faster than Java?!). Interestingly he is using the upcoming -hsx Hotspot server flag which makes a big difference in speed.
Would a coffeescript-like language that generates php be something of interest to people? Improving the syntax whilst maintaining the ability to just drop onto an apache server.
It would be really cool. In fact, I was thinking about that right now.
Just convert and bingo, instantly deployable on 100% of php hosts. For local development, a script with --watch a la sass, or maybe a single index.php for converting things on the fly...
Yes, that would be something huge (or maybe I'm thinking that because I have this idea for a long time and really wish someone would do this).
Obviously, the quality of the output php code would matter a lot. Actually, by quality I mean mostly the performance.
I've started something like that a year ago. It's called purplescript( https://github.com/martinrusev/purplescript ) and it's a ruby like language written in Python ( with PLY ) and it compiles directly to PHP, so there is no need to rewrite PHP functions - they just work.
Probably to some people, sure. For totally 100% from scratch projects, it might be nice - may be harder to deal with existing code bases that you want to extend or integrate with, no?
Writing a programming language in this day and age and posting about it on HN is like visiting each denomination of your favorite religion and announcing that you're starting a new cult. Personally, I think it's a lot of fun, just don't expect a positive or welcoming reaction. Best of luck to you.
Native parsing of markup and SQL looks like a neat idea (reminds me of Facebook's XHP plus LINQ) but I'm concerned about using the JVM. Does this use a .NET style multithreading model instead of using one process per request? If not, I can't see the benefit of using a JVM given its best features (GC and JIT) would be rendered not only useless, but a bit of a drag.
My personal PHP wishlist is:
* Better interfaces for the core libraries. Ideally replacing them all with namespaced and object-oriented ones with none of this needle-hackstack mixup
* A standard autoloader
* Removing the concept of 'PHP errors' and replacing them all with exceptions
Basing this on the JVM may afford some benefits, but widespread adoption will not be one of them. I'm a big Groovy fan, and love Grails, but it's never going to challenge PHP in uptake. I get a lot of JVM benefits by using Grails, but I still do a lot of PHP too, and each have their place. I suspect others would chime in with their own non-PHP loves (ruby, c#, python, etc) but PHP's massive adoption has a lot more to do with availability than syntax.
The people that don't like PHP's syntax already use other tools when they can, and when they can't, because they need to use PHP, it's likely going to be because they're using some existing PHP library or platform already (wordpress, drupal, etc).
I'm all for people experimenting and trying to make things better, but you're probably better off just making a new language than trying to make something that's sort of like php, but different enough that existing code libraries won't work with it.
I have a been in a love affair with PHP and also have been FRUSTRATED for its lack of few things. Despite the fact that PHP lived as a royal king of its era, few new comers like Rails, NodeJS are really taking the attention away; I've been always wondering and why wasn't community really taking the great examples of nifty syntax from ruby and evented model from Node to create the same beast again? I've been waiting 3 years for getting myself out of crappy array('foo' => 'bar') syntax to something neat like {'foo': 'bar'}. I really appreciate your move to create something where we would be able to fix these issues. Keep up the good work!
PHP (and Perl, and Rails, and even Erlang) were all created to fulfill an immediate need. That's one of the reasons why they are so successful. They aren't like, say, Pascal in that they were created with abstract goals in mind. If you want to replace PHP you have to do so on PHP's turf and PHP's terms, you need to make something even MORE practical and even EASIER to go from zero to functional dynamic website.
"What's missing ?
...
- ports of all useful PHP functions"
Seems a bit premature to call it "phpreboot". In the present factor, the programmatic constructs identified have equivalents in nearly every language I can think of.
Maybe once it has some PHP functionality incorporated, it could be called phpreboot.
A little confused about why this project is starting when there is already a fully supported PHP for the JVM in Quercus. http://www.caucho.com/resin-3.0/quercus/
Understand the cleaner syntax hopes... and using JVM 7 features...
I don't like the reduction of brackets, one thing I like in php is the readability of the symbols:
if(){
}else{
}
I know when things start and stop, with the conditionals presented there are no indication of start/stop except possibly indentation... lack of closure symbols is one of the reasons I am not comfortable with python as much, I gain comfort in being able to visibly close my sections, and I think for learning a language it makes it way more readable/understandable too.
My second thought is it needs a seamless transition path where you can run both old and new PHP without error, there is a lot of code out there and I don't think everything would be rewritten in one fail swoop in many applications.
Native JSON is a nice step, but for the most part I would have to agree with the other commenters.
Especially embedding SQL as a literal as seems more convoluted than clarifying.
I think it might be elegant in small doses - just look at C#'s LINQ. Also, it's a nice strategy to lure newbies away from string concatenation and give security for free...
One extra comment different from my last - easier Android app development could make this a very interesting project. That's assuming this as a JVM language will work on Android (groovy doesn't right now because of too much AST stuff, fwict).
I think this is a good idea. PHP solves a niche of small sites with slightly dynamic templates.
(To some extent it owes more to rebol than to php - it has a large grammar and a notable amount of literals.)
It makes first class what other languages embed in strings - sql, urls, html, etc. In doing so it can solve a large class of security problems that plague many php projects - you don't need to worry about sql injection when the language handles the query parsing.
PHP was successful for a number of reasons, one of which was that it was embedded and exposed a number of cgi specific features into the language ($GET, $POST, etc), this continues in this vein to embrace urls, sql and html as part of the language. The programmer no longer has to deal with escaping or transforming or sanitising strings. This is cool.
Given it runs on the jvm - it should be possible to layer this atop of heroku or google app engine without worrying too much either.
This approach isn't new either - philip wadler tried in a similar way with the functional language 'links'.
(disclaimer: I think php is a terrible, terrible implementation of some good ideas - the library, language and implementation are notable examples of bad ideas in programming)
I just wonder: how are you supposed to escape braces in embedded JavaScript? If the language 'intelligently' finds braces inside <script> tags, then I'd recommend everyone to run as fast as possible in the opposite direction.
A better approach might be to go the CoffeeScript way or better still, contribute to php itself. Sure it might take longer but languages take years to catch on...
My PHP reboot is simple: drop it for more versatile interpreted languages like Ruby & Python, and their respective web frameworks. Loving it, personally.
If you want a better version of PHP, try Perl / Python / Ruby. If you want a language that can check your code for safety at compile-time, use Haskell. But if you invent your own language, it will have three problem: nobody will know how to use it, it won't be installed on any three-dollars-a-month shared host, and it won't have any libraries.
If you can't solve the "I want to use it for $3 a month" problem, your programming language is a failure compared to PHP. If you can afford more than $3 a month for hosting, then you're not using PHP anyway. Most people learn to program because they want to share something with their friends. They choose PHP because it lets them do that, and they don't have the experience to know that They Are Doing It Wrong. By the time you introduce a PHP "reboot", you're not going to get that "Don't Know That I'm Doing It Wrong" crowd anymore, and then who's your audience?
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.