On Wed, 29 Dec 2004 08:35:28 -0800, Tony Di Croce <dicroce@xxxxxxxxx> wrote:
So far, I really love PHP... It just makes web development so much more convenient... But I sometimes wonder why so much server side work is done with intrpreted scripting languages... Why haven't languages been created that when "compiled" result in C code, which could then itself be compiled and run natively?
Back when CGI was the thing to do, most of the 'scripts' were compiled C programs with hooks to the Common Gateway Interface. Then Perl happened, and the whole landscape changed.
The modern version of this is a Java-based web application server like ATG Dynamo or IBM Websphere. Everything, right down to the front-end JSP (or JHTML in Dynamo's case) pages are compiled into Java Objects and then cached and run accordingly. I think you'd find that architecture very interesting.
It should be possible to create a "reintrepreter" capable of translating code written in a language like PHP into C code, which could then be compiled and executed natively... (IE, Faster)... If it was desired, it could even copy the syntax of the PHP language exactly... You would get the rapid development of PHP combined with the execution speed of C...
Their must be a good reason this has never been done (or has it?).
I'm pretty sure pre-compiling PHP has been tackled before, but it certainly doesn't seem to be popular. I'm not sure anyone has ever tried your idea of porting it to a different language, and then compiling it.
I think the main reason web development is so widespread is that it's an easy 2 step process. When you're writing C code, you write, compile (with errors), modify, compile, then run. With PHP, you just write and reload ad infinitum. Scripting languages compress the compile/run steps (and debug, in most cases), and makes it as easy as a couple of keystrokes to get your application running. Since the application server is running the entire time you're developing, there's no lag time to wait for it to load libraries, load a GUI, etc. It's such a rapid development process, I think you'd have a hard time convincing PHP developers to go back to the more structured method.
I can understand the execution speed argument, but so much of what PHP
does can be tuned at the application level, you often don't need to
change your code to make your site run significantly faster. The time
you'll save having your scripts pre-compiled pales in comparison with
doing a little tuning of your SQL queries. In my experience,
compile/execution time isn't the most constricting factor when dealing
with web apps. I usually get more hung up on data transfer times.From DB server to the App server, and then from the Web server to theclient for example.
You could certainly label me a skeptic on this topic. I just don't see a huge amount of gain possible for what seems like a lot of work to me. Then again, I've been scripting about as long as you've been compiling, so I might not have the full picture. :)
The idea is to compile the bits that need to be compiled and avoid compiling the bits that don't. When you need to perform an SQL query, for example, it is obvious that your database needs to be a compiled native application and it is also very beneficial that the client library that sends the request and talks to the DB server over a socket is a natively compiled library. But the little bit of logic that decides which query to send or builds the query from some user input will never be the bottleneck and at the same time it is the piece of the puzzle that you will be tweaking over and over again, so you leave that in something that is easier to work with.
This has been the approach of PHP from day 1. Anything that is performance-sensitive you write in C and compile it in. Anything that isn't you leave in PHP. There is nothing wrong with writing your own PHP extensions for the bits of a larger application that can benefit from that. The pear/pecl installer even makes it easy to distribute that extension in a way that anybody can compile and build your extension on their platform.
-Rasmus
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
