First of all, not compiled and interpreted (what he, of course, meant by a script that is somewhat vague and used for different purposes) are different sides of the same coin and, therefore, for the same reason.
The last reason it doesn't work on every platform is just confusing. It appears to be trying to advertise Java portability, and PHP is simply not Java. However, Java runs on one very specific platform: the JVM. This platform, in turn, runs on many other platforms and thus gives Java its portability, but it is not quite the same as the traditional use of "portable" ones. For example, C is portable and works on everything from the PDP-11 to the latest embedded devices.
However, C does this by setting the rules of its own abstract platform, and compilers convert the C code into an assembly in accordance with these rules. This is how Java compatibility is similar to C: they define rules that translate into instructions for a specific machine (processor); the difference is when this happens.
All problems in computer science can be solved with another level of indirection.
& EPRS; & EPRS; - David Wheeler
In fact, even an assembly or “machine code” is interpreted by the processor in its native actions. (I don’t have a good source for this, but I remember that it is slightly covered by A Crash Course in modern equipment , which is a good presentation anyway.) As the processor speeds up, we hardly notice on our underused boxes whether this program is in asm or launched through the interpreter, but this is where the definition of "real programming language" comes into play.
The only reasonable way to define a “real programming language” is the “language in which you need to do the real work,” but it does affect the definition of “real”. (However, he makes a distinction between esoteric programming languages , because no one does the real work, for example, at Malbolge , for any definition of “real” you could get ten people to agree.) And, compared to today, your choice of programming language was much more limited by their implementation strategies and overhead (such as a runtime interpreter) in the past. However, even today some languages ​​are more "real" than others, for certain applications and expected loads, it all depends on your requirements.
It looks like your teacher only experienced PHP through toy web applications (and perhaps using the “application” is a stretch for what he saw). Toy programs are not real work. PHP definitely has a lot of problems, but I could not say that this is not a real programming language, except for jokes.
Debugging is expected with disgust, reluctantly, and boasts forever. & EPRS; & EPRS; - Dan Kaminsky
There is a definite link between the “real” and the “hard work” (related to the “real work”), and your teacher may have expressed that feeling. It always seemed to me a form of bikeshedding (it’s better there, but I don’t remember), where one estimate of the value of a thing is connected with the effort that had to be invested in it (for example, a bicycle is more important when I presented the input data for the color of the roof and should whether he has a sign). We internally value our own efforts more than others; simply because we are familiar with it, if not for any other reason - ndash; even if that doesn't make sense. PHP, despite its shortcomings, makes some things easy, and this and the programs written on it can, therefore, be perceived as less worthy.