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.
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.
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.
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.
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.
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.
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?
See, but C, and the x86 architecture, has none of that, or it all can be changed (like calling conventions), and yet all languages and VMs can be implemented in C. Despite the explicit lack of support for those things, many C libraries are available with specific language bindings.
That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.
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.
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.
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.
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.
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.
But I don't think that will cut it in terms of making PHP go away. There has always been competition for PHP, but it's pretty popular right now, and it will be hard to displace...
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.
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.)
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?
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.
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.
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.
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.
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.
precisely. My ultimate (and totally attainable) goal is for the generated code to actually perform better than the "hand-written" php would for a given task. Regardless it's fun to go through the r5 spec piece by piece and fully digest it. quote and quasi quote + the macro system are clearly the most interesting pieces and I am striving to not get side tracked and start working on my own flavor of things thus why its nice to fall back on the spec as the initial goal/proof of concept. Are you interested in helping or just disgusted?
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.
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:
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.