PHP As A Next-Generation Programming Language?

[blackshard]

I'm actually a little intrigued as to the disdain for multiprocessing. I'll admit I work in a different world than most in safety critical embedded systems (so no actual Python in most of my "real code"). The issue I have with threading is that I don't want access to everything else the other side is doing. In fact, I want to minimize that so I don't have to worry as much about resource contention, race conditions, etc. multiprocessing has Pipe and Queue to set up explicit data sharing points. Resources still must be shared via Lock calls (or just message the other side to do it). If you want to share a value not through a Pipe or Queue, there's Value and Array or Managers for more complicated scenarios. It even has a built-in Pool object.

I think green threads w/ no global state (a la Erlang, gunicorn, Twisted, or Tulip) solve the I/O limited case for threading quite well. This is the situation where you may have thousands of threads of processing open.

I also think either multiprocessing properly handles the CPU limited case, while being safe about not affecting the global state. (ZeroMQ handles going to multiple computers fairly easily though.) In this case, you shouldn't have more than a few threads of processing opened at a single time anyways. Anything over #CPUs simultaneously isn't helping anyone. They are a bit heavier than threads, but forking isn't anywhere near a 2x memory use increase. In fact, it's copy on write for the pages, so much of it should remain the same.

The problem with multiprocessing it that spawning processes and sharing objects between them is costly, and it is the main reason threads exists: don't fork the whole process, but create a new lightweight schedulable kernel entity that completely shares the memory address space with the process. Massive parallelism is the use case where kernel threads are useful, and currently have limited support in CPython, due to the GIL. But I reaffirm that this is an implementation problem and not a language issue.

If you have an I/O bound condition, user threads (ie: green threads) can be useful, in case of distributed parallelism multiprocessing is the only way.

[TheOne]

The problem with multiprocessing it that spawning processes and sharing objects between them is costly, and it is the main reason threads exists: don't fork the whole process, but create a new lightweight schedulable kernel entity that completely shares the memory address space with the process. Massive parallelism is the use case where kernel threads are useful, and currently have limited support in CPython, due to the GIL. But I reaffirm that this is an implementation problem and not a language issue.

If you have an I/O bound condition, user threads (ie: green threads) can be useful, in case of distributed parallelism multiprocessing is the only way.

in any case somebody doesn't knows there is pthreads (http://pthreads.org/) for PHP which works with a thread safe build of php

[Pajn]

Not necessarily. PHP, for example, prevents wrong behavior having different operators for sum (+) and string concatenation (.). You can sum two strings and you will obtain the sum of the numbers, because the plus operator automatically casts the strings. These are little and apparently useless details that at last makes a lot of sense.

However as PHP is inconstant between numbers in strings and pure numbers any application depending on this have bugs.

Absolutely it is not syntactic sugar, it is a proper implementation of data abstraction and OOP. You may access a private member of a class in PHP, Java or C# and C++, but it is not an easy task, it is discouraged and a bad practice just because you are not supposed to access a private attribute, since it denotes an internal state of the class instance and must be modified only by the instance itself.

Which Pythons underscore convention is too. It denotes a private field that you shouldn't mess with. Writing private instead of _ is syntactic sugar though.

Maybe when the instance gets destroyed? I mean, __init__ gets called each time an instance is created, no matter the reference counter. __del__ instead is called when all the instances of a class gets destroyed (or the reference counter reaches 0, if you prefer this way), but there any hook is called when the reference counter of a class is decreased.

And when do the instance get destroyed in a garbage collected language?
Actually this is exactly what Pythons __del__ does, its problem however is exactly that you can't
depend on it as it's impossible to know when or even if an instance gets destroyed.

So it is a problem of unskilled programmers messing with templates, not PHP one. PHP is, by design, made to do that.

PHP however does have a design that encourages bad behavior. If PHP templates would have been pure templates
without a full language in its backpack there would have been no problem.

I absolutely not think so. I extensively used, benchmarked and profiled Smarty in PHP and just the instantiation of the template engine took more than half of the time to fulfill the whole request.

Well, Smarty just transpiles your templates to PHP so of course pure PHP will be faster.
However that transpilation can be done before publishing giving you a delimited place to develop your templates
while still giving the same speed.

[jimbohale]

PHP is awful. The only way to improve it is to throw out most of the stuff, so you might as well just throw the entire thing out. Java servers based on async frameworks like Netty are FAR superior in terms of performance (while suffering in the ease of development department) and Python with Django is also quite good and is pretty easy to develop. There is nothing good about PHP. It encourages bad programming practices such as not escaping SQL statements (among other things). If PHP didn't allow arbitrary concatenation of SQL statements, there would be FAR fewer website hacks, and that's just one of the so, so, so many issues PHP has. It doesn't have any concept of concurrency and it's flat out not designed for it, it's designed for the entire script to be executed once per request. That's awful. Any attempts to add concurrency to PHP will be pointless unless you introduce a module system for web requests (i.e. class whatever extends request_handler), but even then I have little faith that the incredibly incompetent PHP devs will be able to do it right, as thus far they have done so very little right. They have random ass string functions from C that don't belong in the standard library that have become crucial to it (i.e. count should NOT exist, if you're going to attempt to make a procedural language OOP, at least make strings objects that you can call .size() from). There is no defined error when you attempt to do random things like add strings instead of concat ("abc" + "123" = random crap). It should error because there is no reason to add two strings OR it should use the + to concat. I could go on for days, but PHP really doesn't deserve my time. It needs to die. Every time I see it, I sigh. It's so bad. It's obvious that no thought was put into it, and yet for some stupid reason people think it's a good idea to use it, just because everyone else uses it. It really is the Kardashian scripting language.

As for the uneducated comment about Java not supporting a distinction between private and public: It does. You can't access private fields or methods if you're outside of the class. Now, you can modify the bytecode to do it but realistically that's not the languages fault and that's not done in any practical situation ever, it's easier to just use either public or private.

[Cyber Killer]

The day when python or ruby can be ran as fastcgi on nginx or lighttpd instead of implementing their own webservers and running through proxy_pass + will use the system provided libs instead of having their own repositories is the day we can start considering them as replacements for php on the popular web.

[psychoticmeow]

PHP is awful. The only way to improve it is to throw out most of the stuff, so you might as well just throw the entire thing out. Java servers based on async frameworks like Netty are FAR superior in terms of performance (while suffering in the ease of development department) and Python with Django is also quite good and is pretty easy to develop. There is nothing good about PHP. It encourages bad programming practices such as not escaping SQL statements (among other things). If PHP didn't allow arbitrary concatenation of SQL statements, there would be FAR fewer website hacks, and that's just one of the so, so, so many issues PHP has. It doesn't have any concept of concurrency and it's flat out not designed for it, it's designed for the entire script to be executed once per request. That's awful. Any attempts to add concurrency to PHP will be pointless unless you introduce a module system for web requests (i.e. class whatever extends request_handler), but even then I have little faith that the incredibly incompetent PHP devs will be able to do it right, as thus far they have done so very little right. They have random ass string functions from C that don't belong in the standard library that have become crucial to it (i.e. count should NOT exist, if you're going to attempt to make a procedural language OOP, at least make strings objects that you can call .size() from). There is no defined error when you attempt to do random things like add strings instead of concat ("abc" + "123" = random crap). It should error because there is no reason to add two strings OR it should use the + to concat. I could go on for days, but PHP really doesn't deserve my time. It needs to die. Every time I see it, I sigh. It's so bad. It's obvious that no thought was put into it, and yet for some stupid reason people think it's a good idea to use it, just because everyone else uses it. It really is the Kardashian scripting language.

As for the uneducated comment about Java not supporting a distinction between private and public: It does. You can't access private fields or methods if you're outside of the class. Now, you can modify the bytecode to do it but realistically that's not the languages fault and that's not done in any practical situation ever, it's easier to just use either public or private.

You can expect many of these problems to be solved in the next major release, except those that are not language problems that will be solved by third party libraries, for example ReactPHP. But I guess actually knowing that people are solving these problems would've prevented you from going on an uneducated rant. Maybe not, though.

The day when python or ruby can be ran as fastcgi on nginx or lighttpd instead of implementing their own webservers and running through proxy_pass + will use the system provided libs instead of having their own repositories is the day we can start considering them as replacements for php on the popular web.

Actually, you can do the same with PHP and it's a lot faster than PHP-FPM, combine it with some nice systemd configuration and you've got a killer setup.

[Cyber Killer]

Actually, you can do the same with PHP and it's a lot faster than PHP-FPM, combine it with some nice systemd configuration and you've got a killer setup.

That's nice, but as a sysadmin I care more about stability and maintenance than performance, so having multiple instances of small different http servers is not helping in this. Anyway, php wins cause it can be used in either case, where in python & ruby they force one to use their daemons.

[jimbohale]

You can expect many of these problems to be solved in the next major release, except those that are not language problems that will be solved by third party libraries, for example ReactPHP. But I guess actually knowing that people are solving these problems would've prevented you from going on an uneducated rant. Maybe not, though.



Actually, you can do the same with PHP and it's a lot faster than PHP-FPM, combine it with some nice systemd configuration and you've got a killer setup.

Just because someone proposed it doesn't mean it'll happen. Judging by the fact that it made it out the door for this long I would say that it won't happen. As well, the ability to register primitive type extensions arbitrarily is a terrible idea. That will bring essentially different dialects of PHP between different projects. On top of that, that doesn't solve ANY performance issues that it is utterly crippled by. One person rapidly reloading a webpage can take down a high-spec'd server with PHP (yes, I did the opcode caching properly), while on Java thousands of people rapidly reloading a webpage on that same server does nothing. I know that I can blacklist that one person but I shouldn't have to. PHP's interpreter shouldn't be THIS bad. If somehow, some way PHP7 does exactly what it should (and what was outlined is NOT exactly what it should) and HHVM actually works with it then PHP might not be so very dumb. Python and everything else minus the .NET stuff would still be better, though. Anyone who thinks anything about PHP is a good idea is the uneducated one.

[psychoticmeow]

Just because someone proposed it doesn't mean it'll happen. Judging by the fact that it made it out the door for this long I would say that it won't happen. As well, the ability to register primitive type extensions arbitrarily is a terrible idea. That will bring essentially different dialects of PHP between different projects. On top of that, that doesn't solve ANY performance issues that it is utterly crippled by. One person rapidly reloading a webpage can take down a high-spec'd server with PHP (yes, I did the opcode caching properly),

Congratulations for enabling op-caching I guess, but perhaps next time you should look into optimising your application instead?

while on Java thousands of people rapidly reloading a webpage on that same server does nothing.

Just like a well written PHP application then, on a well configured server, I guess?

If somehow, some way PHP7 does exactly what it should (and what was outlined is NOT exactly what it should) and HHVM actually works with it then PHP might not be so very dumb. Python and everything else minus the .NET stuff would still be better, though. Anyone who thinks anything about PHP is a good idea is the uneducated one.

What I linked to was a list of things being discussed, and a list of things confirmed to be implemented in the next major version of PHP. But in general the PHP developers share your concerns about the language and have slowly been chipping away and removing the crufst. PHP 7 obviously presents them with a chance to remove a lot more of it.

But basically what I'm getting from you is that PHP isn't Java and therefore you don't see the need for it. Which is fine, but then why are you shitting up this thread with FUD about PHP?

[jimbohale]

Congratulations for enabling op-caching I guess, but perhaps next time you should look into optimising your application instead?

You mean like a hello world that is simply <?php echo "HELLO"; ?> ?

Just like a well written PHP application then, on a well configured server, I guess?

Again, <?php echo "HELLO"; ?> can't handle more than like 100 requests a second on a decent server (quad core xeon w/ hyperthreadding, much RAM).

What I linked to was a list of things being discussed, and a list of things confirmed to be implemented in the next major version of PHP. But in general the PHP developers share your concerns about the language and have slowly been chipping away and removing the crufst. PHP 7 obviously presents them with a chance to remove a lot more of it.

Clearly not, since they're not doing the world a favor and abandoning it.

But basically what I'm getting from you is that PHP isn't Java and therefore you don't see the need for it. Which is fine, but then why are you shitting up this thread with FUD about PHP?

It's not FUD, it's straight up the fact that PHP SUCKS. Granted, there are some hyperboles but really PHP shouldn't be used in production, ever, yet it is being used on such a wide scale and that's frustrating. Something like the Hack language is what needed to be done, not this nonsense. You can't fix what was completely broken in the first place. PHP is so inherently broken it's better to just rethink it from the start. You cannot have a language that performs well that is designed like PHP is, which is to execute completely every load. It's similar to why Apache has or had the c10k problem (new thread every page load).