I have read much about Fibers since they were introduced and have never come up with a real use case. All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as…
Exploring Coroutines in PHP
41–50 of 68 posts
Re: Exploring Coroutines in PHP
#42Personally I've never come across any problem in PHP that I feel like Fibers would help me solve. Having Fibers in PHP is a nice addition but it definitely feels more like plumbing for other PHP extensions/frameworks to use, rather than something the average dev would use themselves directly day to day.
Of course you haven't come across any such problem in PHP, because up until this point, if you had, you would have had to switch to another language to solve the problem that required the feature PHP didn't have. There's an evaporative cooling effect on languages that don't have certain features where all the people who need those features leave after some number of years of not having them, leaving behind only the p…
To be clear, my point wasn’t that I think fibers are useless or that people shouldn’t use them. I think it was a great addition.
Just that they wouldn’t be directly useful to the average PHP dev, until they’re being used by frameworks/libraries/extensions, say for example: a HTTP library that can fire off multiple requests asynchronously.
Re: Exploring Coroutines in PHP
#43Earlier quoted context omitted.
I work daily with PHP and honestly nearly all my code I write is synchronous. The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.
The shared-nothing architecture is great for some scenarios. Long running processes and async I/O are a great tool to have though. They are present in PHP for almost two decades now, and despite having many incarnations (select(), libevent, etc) and even frameworks (amp, reactphp, etc) the knowledge is highly transferrable between them if you understand the fundamentals.
Re: Exploring Coroutines in PHP
#44Earlier quoted context omitted.
This means, that most likely the keyword will not be "yield". PHP is not known for keeping a low number of keywords. Rather they introduce new ones, to tack on things to the language, like one can see in the implementation of anonymous functions, where one needs to use "use" explicitly, instead of the language having the semantics that most other languages have for lambdas. Which immediately turns in to a source for…
That's not totally correct. PHP has a "short function" syntax for that specific use case, it automatically captures data without the 'use' statement. $a = 5; $b = fn ($c) => $a * $b; print($b(2)); // 10 print($b(4)); // 20
Re: Exploring Coroutines in PHP
#45https://stackoverflow.com/questions/12939319/coroutines-in-p...
Looks like generators were released in php 5.5 in 2013:
https://versionlog.com/php/5.5/
I was interested in coroutines because most backend server logic eventually devolves into a sea of state machines where each request/response advances the state by updating database rows. This becomes unmanageable by humans, which is why server code can only reach a certain level of complexity, perhaps 1 million lines, before it becomes "enterprise" and triaging overtakes architecting as the main mode of operation for developers.
This is akin to how in the 1990s, object-oriented programming (OOP) limited the size of most desktop programs to around 1 million lines, due to similar state management limits under imperative programming.
I had hoped to replace the state machine soup of backend API endpoints with coroutines that guided users through stuff like their onboarding steps along one-shot functions made up of mainstream conditional logic and higher-order methods.
This history explains why most websites and apps today have so little actual business logic. Most would be considered entry-level or semester projects for desktop developers in the olden days, who were forced to wrangle the complexities of C++ and Java.
Today, most time is lost to the idiosyncrasies of managing build pipelines, version updates, boilerplate, etc. Meaning that we're too mired in babysitting our tools to see how old school approaches like using spreadsheets and batch files in office environments would make a mockery of our work. Now it's mostly all a waste of time, and we can feel it, but I digress.
Anyway, I had attempted to make this state machine coroutine bridge by saving php functions and their state using the jeremeamia/super_closure package:
https://packagist.org/packages/jeremeamia/superclosure
https://github.com/jeremeamia/super_closure
Which gave way to opis/closure:
https://packagist.org/packages/opis/closure
https://github.com/opis/closure
Which gave way to laravel/serializable-closure:
https://packagist.org/packages/laravel/serializable-closure
https://github.com/laravel/serializable-closure
That way the coroutine would get resurrected during each user request and proceed through its logic. Thereby removing the mental load complexity limit imposed by state machines and allowing 1 or 2 developers to compete with larger enterprise teams at big companies.
Since then, I've abandoned these types of approaches and moved towards pure functional programming (less state management and fewer side effects), declarative programming (repeatable processes that eventually meet constraints imposed by integration tests), and data-driven development (higher-order methods on trees and graphs). So lots of work with spreadsheets, Terraform, Firebase, etc. I find that programming languages mostly get in the way now.
After a career mostly spent hacking on legacy code and tearing my hair out, I yearn to be free to get real work done. This would look like abandoning most approaches people are pursuing today. For example, most of the async/await stuff in Javascript is an evolutionary dead end, because we already went down the cooperative threading road in the 1990s and discovered that there was no there, there. Async is today's goto. Same with absurdities like the "final" keyword, which is a self-flagellation habit born from difficulties around name-mangling when exporting C++ methods in object files. The compiler should reorder structures and classes to match the constraints of the runtime, not humans. Otherwise we break Postel's Law:
https://martinfowler.com/bliki/Seal.html
https://martinfowler.com/bliki/SoftwareDevelopmentAttitude.h...
https://martinfowler.com/bliki/DesignedInheritance.html
https://martinfowler.com/bliki/OpenInheritance.html
https://martinfowler.com/bliki/TolerantReader.html
With this context, we can see how large powerful companies have doubled down on the Directing Attitude and Designed Inheritance to the point that we're handcuffed to our tools. They've done little or nothing to advance the state of the art of our languages and frameworks from first principles to be more freeing by providing more leverage. For every revelation like Erlang and Go, there are countless AWSs and Reacts. Forcing us to focus on specifics like regions and edges, side effects and performance, etc. Because nobody did the real work of designing distributed systems that "just work" via techniques like true multiprocessing, memoization.. I could rant forever. It's all bare hands work now, by us serfs under neofeudalism.
Sorry this got long, it's a passion project for me, a dream I may never have time to live if the rest of my life gets lost to making rent.
Re: Exploring Coroutines in PHP
#46Earlier quoted context omitted.
The shared-nothing architecture is great for some scenarios. Long running processes and async I/O are a great tool to have though. They are present in PHP for almost two decades now, and despite having many incarnations (select(), libevent, etc) and even frameworks (amp, reactphp, etc) the knowledge is highly transferrable between them if you understand the fundamentals.
I agree, but I would always pick a different language (like Go) for long running processes. PHP is great for shared-nothing apps though.
Re: Exploring Coroutines in PHP
#47Earlier quoted context omitted.
PHP generators/iterators is a hot mess. I don't know any other language which forces iterators to output a key for `foreach(... as $key => ...)`.
PHP doesn’t force keys... You can omit the key and simply write `foreach($items as $value)`
Re: Exploring Coroutines in PHP
#48Earlier quoted context omitted.
PHP generators/iterators is a hot mess. I don't know any other language which forces iterators to output a key for `foreach(... as $key => ...)`.
PHP doesn’t force keys... You can omit the key and simply write `foreach($items as $value)`
It's literally in the interface.
Re: Exploring Coroutines in PHP
#49I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding la…
PHP 10 with a clean slate is a cute idea that would wreak havoc. Perl, or whatever it is called now, tried this and it was a total disaster.
Re: Exploring Coroutines in PHP
#50Earlier quoted context omitted.
Of course you haven't come across any such problem in PHP, because up until this point, if you had, you would have had to switch to another language to solve the problem that required the feature PHP didn't have. There's an evaporative cooling effect on languages that don't have certain features where all the people who need those features leave after some number of years of not having them, leaving behind only the p…
Genuine question, what kind of problems would using fibers help with? To be clear, my point wasn’t that I think fibers are useless or that people shouldn’t use them. I think it was a great addition. Just that they wouldn’t be directly useful to the average PHP dev, until they’re being used by frameworks/libraries/extensions, say for example: a HTTP library that can fire off multiple requests asynchronously.
"Just that they wouldn’t be directly useful to the average PHP dev,"
But you're restating my point, whether you realize it or not. They're not useful to the "average PHP dev" because if the "average PHP dev" needed them, they would cease to be a PHP dev, just as I ceased to be a Perl dev when I needed something it couldn't do for similar reasons. All the use cases that PHP could have with fibers have evaporatively-cooled out of the community because PHP couldn't do them, leaving behind precisely that set of people who don't have problems that could be solved with fibers.