Speaking of php. It doesn't really have its own runtime in compare to python, ruby or go. Php is jsut a text preprocessor.
What exactly does it mean by, Php doesn't have runtime?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
I would say that quote is... at least, very, very deceiving.
First off, a preprocessor is a tool. And PHP is a language. So, that is a categorical error.
Addendum: As I will show below, PHP does not only have a runtime, it has multiple ones.
I can fallback to two possible interpretations:
The common wisdom is that PHP is an interpreted language... again, that is oranges to apples. PHP is a language, it is the runtime that can be an interpreter... However modern PHP has compilers, not interpreters.
When parsing PHP files, Zend Engine 2 generates a series of operation codes, commonly known as "opcodes", representing the function of the code.
Thanks to that, OPCache and other solutions can optimize the execution time. They do so by caching the opcodes instead of compiling the whole file every time.
Note: this is also why there are some fatal errors that will trigger even when the portion of code is not being executed. Although, in general PHP will not do much in terms of static checking. It is a dynamic language, after all.
I want to note that there other PHP runtimes. Notably Phalanger can compile PHP 5.4 to .NET.
Now, considering that the output of both of the mentioned runtimes is some form of binary opcode instead of text. I would say that PHP runtime is not just a text preprocessor. In fact, I have to say that PHP runs on a virtual machine.
There is a grain of truth here. The main use of PHP is to output HTML, or text for that matter (you can use PHP to output CSS, for example), from a web server to a client.
I want to note that PHP can be used for other things. For instance Phalanger allows to access .NET libraries, which you can use, for example, to create a desktop application.
Now, perhaps the misconception that PHP is a text preprocessors comes from the fact that text in the PHP source file that is not wrapped in PHP tags is output verbatim.
Meaning that, a person could understand the behavior of the PHP runtime as a tool that takes the text, looks for the php tags, takes the code, execute it, and replace the tags with the result.
Well, now that you know that the runtime outputs opcode, you know it is not so simple. It has to output opcodes that output the verbatim parts, and convert the code that is between the PHP tags to their appropriate opcodes.
I am not really familiar with the internals of Ruby, Go and Python.
At least I know that there is one runtime - among many alternatives - for Ruby that compile to Java.
I will just talk about Java.
I wonder if the author of the quote would think that Java is just a text processor because you can have a text file with some JSP tags and have it run in Tomcat or GlassFish.
Of course, when it comes to JSP, there is an extra step that converts your code to a servlet. You could have wrote a servlet directly, and probably get more advantage from it - in exchange of making the setup a bit less convenient.
There is not an equivalent to a servlet in plain PHP. However, you can choose to put
<?php on the top of the file, and never close it. Then proceed to use
echo to output. which would work similar to Java's
Note: Similar arguments would go to ASP.NET.
In the official runtime, the PHP code for each petition is isolated. And by default it is limited in execution time and memory. This, compound with the fact that you can setup a fully free and open source PHP stack, makes it very cheap and easy to manage for hosting providers.
On the other hand, if you use Java, Go, .NET, etc... you can very easily write code meant to persist across multiple petitions and take advantage of threading. While in PHP the closest you have to start a thread (without adding extensions to the runtime) is to make a new petition to the server.
Text preprocessor only have the text at hand to work with. Even if we allow them to access other systems - such as a database engine - they do not have knowledge of the execution of the code.
In theory, you can create a preprocesor that understands the code, and sees what happens when it is executed. At this point you will be the only person calling it preprocesor. It is now an interpreter.
Addendum: There is one thing that the preprocesor cannot do, even it is an interpreter, and that is to take the input from the user (that is, information about the petition). If it waits until it has the input, then it is not pre processing, isn't it?
The original meaning of "PHP" was Personal Home Page.
However that is no longer the case. The official documentation says "PHP: Hypertext Preprocesor". It seems to be that PHP folks are the ones who call it a preprocesor. This is a recursive acronym, I suggest to not take it seriously.
PHP, the language, like all textual programming languages is just a way to understand the meaning of the text.
I can run PHP in my head (clock cycles are a little slow) without a preprocessor just fine. So saying PHP is just a text preprocessor is a tad nonsensical. However, there may be a way to read this that makes some sense. Bare with me.
A preprocessor is a tool that can automate some tasks for working in a language. Preprocessor instructions added to the source code must be turned into code that conforms to the target language. There is a preprocessor that targets PHP called pre. Run it on something with it's fancy instructions and when it's done you'll have turned pre code into PHP code.
But if someone said "PHP is just a text preprocessor" and I had to assume they actually meant something meaningful I'd think they were saying that their existed a preprocessor that takes PHP source code and turns it into some other code for some other language. Which might well be what happens in their implementation.
Runtime or execution environment is the part of a language implementation which executes code and is present at run-time; the compile-time part of the implementation is called the translation environment (at least in the C standard).
So for this claim to make any sense they must be saying that some PHP implementation is a preprocessor to some other language which will not use a run-time environment (might be c for all I know).
Whether any of this is actually true for any PHP interpreter/compiler is beyond my caring and scope of this site. But somewhere someone might be doing it this way. If they are they're keeping quiet about it.
It certainly doesn't have to be done this way, because PHP is a language. I can interpret or compile it or hash it. Don't confuse a language with the tool stack used to make the language run.