Recursion is a powerful, relatively low-level approach, and the price for expressive power is readability, but it has legit use cases. What you said has a grain of truth in that usually you should prefer combinators like map or filter (if you're doing FP), but just throwing away recursion is silly. Having a strong opinion on it and not seeming to know about TCO is also not a good look.
I don't think it's necessarily more difficult to read, especially with the mindset of the "recursion goblins" mentioned in another comment here, where one only looks at the current iteration and does not care about, where input argument comes from.
But of course, if what one wants to do can be expressed using map and filter and such, why write some recursive procedure.
This is a common straw man; PHP 5 and 7 made large strides, but that's because there was so much to fix, and there still is and will continue to be, like lack of first class functions, actual modules, etc. PHP is also unsuitable for persistent processes like serving WebSocket.
Why do you need "actual modules"? I feel that (when PSR-4 is followed) PHP's code separation practices are among the best, especially compared to other interpreted web-languages (Python, Ruby, js). And it's convenient while experimenting that it doesn't really enforce anything.
Without modules there can be dependency hell: conflicting subdependency versions, unless all your dependencies update their subdependencies in lockstep.
Websockets are no problem with Ratchet. OhDear is a high traffic app that uses laravel-websocket (based on Ratchet) with absolutely no performance issues.
Never, since PHP is fundamentally flawed, and trying to redesign it would make the split between Python 2 and 3 pale in comparison. PHP's main selling point is backwards compatibility and the existing ecosystem; a fundamental redesign would remove that. PHP's name is also mud when it comes to programming language design, and its community is notorious for poor practices, so no one's really clamoring for a more modern PHP.
The bitter truth for PHP stans is that it is what it is, you can get things done, and you can have valid reasons for using it (like legacy reasons, job market, etc.), but it's rightfully trending down and will continue to.
It's a major recurring theme; for example, anything that refers to implicit or explicit is part of it. The list you quoted is a placeholder to be elaborated.
Asynchronicity is just how sequential models are extended to support concurrency. Parallelism and concurrency are orthogonal, so a concurrent model can be executed in parallel.
> Asynchronicity is just how sequential models are extended to support concurrency.
Asynchronicity just means not existing or occurring at the same time, i.e. not synchronised or without synchronisation.
How you expand that definition to computer science is a matter of opinion. I personally take the opinion that an asynchronous operation could be either concurrent or parallel.
> Parallelism and concurrency are orthogonal, so a concurrent model can be executed in parallel.
07:48 <xkapastel> HAX
07:48 <xkapastel> `slikts: a self post made it to #1
07:48 <xkapastel> what kind of witchcraft is this
07:48 <`slikts> xkapastel: just need to get initial traction
07:48 <xkapastel> must be nice having a botnet
07:49 <xkapastel> tbh :)
...
07:52 <simpson> `slikts: So *did* you stuff the ballot box with upvotes?
07:52 <xkapastel> there's some voting ring
07:52 <xkapastel> the first post was a smiley from one of his friends, but afaik people do this sort of thing a lot so it's not really a big deal
07:52 <`slikts> simpson: very slightly
07:53 <`slikts> I don't have anything that could be called a botnet
07:53 <`slikts> but from past experiences it takes just a few votes to get past the initial bump
07:53 <xkapastel> too bad, a botnet is a good application of concurrent programming
07:54 <`slikts> also strategic timing counts
07:54 <`slikts> around now is the prime time to share content
07:54 <`slikts> middle of the week when US is getting up
"Very slightly" means that I shared that I'd submitted it here; realistically a couple of upvotes could have come from that, but I don't know. The talk about botnets and whatnot is just hyperbole. You inferring alternative accounts and pulling numbers out of thin air is ridiculous.
The trade-offs of locks are accidental locking like deadlocks; message passing removes this trade-off but is less flexible, and dataflow further constrains the use of explicit synchronization. It's part of the larger argument for declarative approaches enabling equational reasoning.
Task/data parallelism bear to be mentioned because they're common terms; thanks for pointing it out.
