On Wed, 29 Dec 2004 08:35:28 -0800, Tony Di Croce <[EMAIL PROTECTED]> 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 the client 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. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
