PHP 8.1.0
php.net
php.net
If you work long enough with a language and figure out most its quirks, it's a breeze. It's nice that they are adding all these new features, but they are hardly what makes it or break it for me.
Here is the one features that is taken for granted in "modern stacks":
Edit file -> Alt+tab ctrl+R. Oops, Alt+tab fix -> Alt+tab ctrl+R.
When debugging I can do that 50 times a minute. With my react app, I can do it maybe 5 times a minute. With my golang app I'm lucky if I can do it twice a minute.
This to me feels really underrated nowadays - at best, you shouldn't always have to reason about your code inside of your head and try to figure out how it'll work in detail, or read API docs for all of the obscure frameworks that you're using.
Test things in real time at first and in the cases where they don't, continue doing so, but with a debugger and stepping through everything bit by bit, or read the docs, or whatever the non-trivial cases will demand.
In my eyes, that's the exact same thing as autocomplete in IDEs - instant feedback, to free you from having to think about yet another mundane level of abstraction or API details, instead letting you solve the actual problems that you're faced with.
If you find Emacs in a container, it's probably me ;-)
I think I would need to run some sshd program on the binary and use a reverse SSH tunnel from my laptop, but that requires me to expose an SSH port on the pod which isn’t a big concern, but it’s just a grind to get it all working end to end.
The difference in time it saves the dev can be anywhere from a few seconds to minutes per mistake.
Multiplied by hundreds of mistakes, it makes a huge difference. And that's not even getting into the advantages of better autocomplete for external libraries.
As someone who has written many thousands of lines of PHP, JS, TS, C#, Java, and Python, I now find it baffling that someone would start a project in 2021 without a great type system as a safety net.
The human in the loop is a good thing. All things being equal, the type system is also a good thing, but what usually happens is that you end up checking your page once a minute or once every 10 minutes, not 50 times in a minute. That difference can make or break a project.
I'm working on a project that has a legacy PHP code base and a new JVM code base. What kind of naturally happened is that we end up doing most of our front end work in PHP and all of our new backend work on the JVM.
User interfaces, data science, and security/reverse engineering work are three domains that really require tight feedback loops. The work I did on parsing shell [1] is basically a kind of blackbox reverse engineering, and was done with < 100 ms feedback loops.
[1] https://www.oilshell.org/blog/tags.html?tag=parsing-shell#pa...
Of course you will need some manual procedure, and e2e tests, but not “50 times a minute”. That is just frustrating.
I am not saying that a type system will find all bugs. It will stop you from running incorrect code “50 times a minute”. Then you should have tests. Lastly you must also do some manual procedure (or run slower e2e tests).
Doing all this yourself constantly is just frustrating.
PHP has always been a powerful language where the burden of making it work properly 250% relies on the dev. Stuff like enums should significantly reduce that ratio, it’s a big deal I think.
On the debugging part, I found something like ruby’s pry to be the easiest and fastest option. I wish PHP had something similar.
As for react, I work with a medium sized code base in the hundreds of thousands of lines and all I have to do is alt tab since it hot reloads for me. Don’t see how PHP is any better since it isn’t even hot reloading. Also with react I can update css and it doesn’t lose the state which is nice for debugging style changes.
Not denying your point though. There is some real awful stuff out there that could make a grown man cry.
In interviewing, I've seen a few candidates re-run their application after making single statement changes. They'll rename a variable, re-run. Change a conditional, re-run. Introduce whitespace, re-run.
These people aren't even confident in renaming variables!
PHP enables this type of underestimation in your own abilities. You don't need to distrust yourself so much.
Don't think you have to do this.
That might be true, but sometimes it happens that you overestimated and introduced a breaking change 20 changes ago and now you have to rewind your steps back to find the exact place. If an iteration can be done in less than a second, it's probably cheaper (and less stressing) to just check every single change like this. This is what many coding editor integrations actually do for you.
I've even had IDE refactoring tools fail on me whilst doing this, in type checked Java codebases, with reflection in place and annotations, which predictably caused problems down the road. At this point, i'll take any and every method that can help me in development, especially in the face of meaningless cruft and unreasonable complexity.
I'm actually writing this in my 5 minute break after being stuck at work 1 hour past my official work hours, due to some stupid bug where one service ignores a client certificate from service A, but not from service B on the server in containers.
The opposite end of this spectrum (my current circumstances) is completely unreasonable IMO - a change in code needs an app recompilation and a push to the container registry before it's deployed on the server (cannot reproduce locally, possibly proxy configuration is to blame, but it's so simple it should not be possible), whereas configuration changes need the Ansible playbook to run to the end, which also takes time.
Thus, my feedback loop is ~10 minutes for seeing a new way in which the app will fail to do something supposedly simple. Even in normal circumstances, local app reboots still take at least a minute or so, since JRebel and code hotswapping just doesn't work a lot of the time with the frameworks we're using. I'd take being able to see the changes in my code every X seconds over every X minutes any day of the week.
Even if i trust myself, i still want that freedom and speed of development and checking why everything breaks.
>Edit file -> Alt+tab ctrl+R. Oops, Alt+tab fix -> Alt+tab ctrl+R.
Yeah, this is pretty much what the Common Lisp and Smalltalk people have been doing since mid 1980s. Except that they're not limited to web applications. And also python people to some extent, with ipython. And Haskell people with ghci.
The value of less friction cannot be overstated in coding work.
With PHP, you're not limited to web apps as well. The same rapid-fire style development can be applied when building CLI applications.
It's probably part of the reason for the success of PHP and similar.
However, being able to have a "compile" step that does a lot of work to make things faster is also very useful. The key is being able to switch between them easily.
In PHP for example there is the code cache (added later but basically standard now), and assuming it's a web app you probably want to crunch the images and CSS in production.
One of the reasons I use golang where possible, I feel more productive in golang because any mistakes you are make are almost always logical issues with the code, rather than language error and usually works first time.
The heart of PHP (not the standard library binding C libraries part) do have come a very long way. Even the things that look the same to you on surface have change under the hood and are way more performant thanks to it.
> When debugging I can do that 50 times a minute. With my react app, I can do it maybe 5 times a minute. With my golang app I'm lucky if I can do it twice a minute.
Hmm... when working on React stuff I don't even have to do the ctrl+R stuff. Hot reloading in the browser is a thing and works quite well. When working with Django it's very close to being the same as the PHP experience thanks to automatic server reloading. I worked with PHP extensively back in the day but I never miss the tight feedback loop (although maybe this experience is why I always make sure I have such a tight feedback loop in whatever I do, I guess you don't always get it by default).
And by things I don't mean just web development.
The current limitations I see in PHP is that there is not an official multi-core coroutines solution.
The alternative would have to be TCL levels of bad to make me choose PHP.
my favorite part of modern PHP is how nice writing libraries is. so it might not be what you're looking for, but I remember being pretty impressed with the code quality of the Amp PHP library recently. the v3 branch is 8.x only and (I believe) is targeting the Fibers feature just introduced in 8.1
https://github.com/amphp/amp/tree/v3
one of the best things to come with PHP are the community standardizations around things like interfaces for HTTP requests, logging, DI containers, and even code style standards. it makes for a very consistent experience when developing (at least when you're in the "new world"), since most newer libraries are all written in a similar style using common interfaces
I ended up in a position where I've become responsible for a very high volume WooCommerce/Wordpress store and the things that I've seen in _brand new code_ is mind boggling. Their new, branded, in-house paypal plugin/integration is currently at 1.5/5 rating on the wordpress plugin marketplace [0]. It just doesn't work for various reasons for various people. It's 2021, how do you screw up a payment gateway for wordpress when you _are_ wordpress? But wait, there's more. They already had PayPal integration, built into the core and already included in all WooCommerce installs. So what to do? Force disable the already existing, working-properly, integration and recommend their new plugin to be used. [1] This is hostile.
If your woocommerce webhook delivery fails 3 times in a row, woocommerce will just turn off that webhook/stop delivering them. Silently. No option for any sort of alert to be sent/logged, no way to store/replay the missed webhooks. Just off. This is irresponsible.
Our installation happens to have a lot of details that go into each line item on an order - which, in turn, turns into many rows of meta data. Woocommerce doesn't rely on dedicated tables for orders or related metadata, it's all stuffed into 'posts' and 'post_meta'. It doesn't scale well, terrible really. It's a large enough problem that LiquidWeb starting working on a fix for high volume sites that end up getting crushed with database/performance issues related to these tables/the way the order data is stored. [2][3] This was supposed to merged into the WooCommerce core but that seems to have stalled/fizzled.
I was able to reduce response time on an API request to get_order() from 3-5s to 0.25s by adding an index to the meta table mentioned above. (The query wasn't using any index) This likely isn't the case for the vast majority of installations, or it doesn't matter because the databases are small enough. But things like this indicate to me that the test suite/benchmarking is seriously flawed - or they're not doing things like testing and benchmarking against real-world databases.
Taking a look at various release notes the types of bugs seem to indicate to me there's not a lot of automated testing going on or that things are so convoluted/messy that it's become too complex.
All in all, for the people behind the PHP workhorse (the hero we deserve...) it's all pretty scary. The code quality, quality control and just about everything leaves a poor taste in my mouth. I'm not a big "Team PHP" guy - I like the idea of using the right tool for the job and the scary thing is that Wordpress is the right tool for the job for a lot of people. (WooCommerce, these days, is basically never the right tool)
This is a terrible look for PHP.
Laravel/Symfony on the other hand... take my money. It's a pleasure. LiveWire, tailwind, oh my.
There's still a place for Wordpress - it's not going anywhere... but it's got a long way to go before I'd say it's anywhere near ok. Let alone approaching latest standards (even despite it's supporting older versions of the language). Can we get first-party/first-option composer support? Why, again, is it another company driving Wordpress forward? [4]
[0] https://wordpress.org/support/plugin/woocommerce-paypal-paym...
[1] https://developer.woocommerce.com/2021/07/12/developer-advis...
[2] https://github.com/liquidweb/woocommerce-custom-orders-table
While I agree this is an antipattern it appeared to be the recommended way when I first got into WP plugin development. IIRC because one cannot guarantee hosting will backup all tables of the DB, and some DBs mix other non-WP stuff.
If you can do as little as possible in PHP and rely on the low level functions to stitch together what you need, deserialize and render data in the front end, use front-end templating, then PHP is insanely fast, practical language.
The issues with PHP are usually when people build out giant frameworks in PHP, rather than using PHP as a higher level glue language for the built-in fast C functions.
Laravel and Symfony are both extremely good, and the only reason people don't use them tends to be out of misplaced arrogance. Unsurprisingly, they end up building their own awful framework, and at some point the project either dies or someone says "Erm, we should put this in Laravel".
There are some people who've built great projects without these frameworks, and there are many projects in these frameworks that are terrible. But in terms of probabilities, you've got a much better chance of a project being well-built if it's in Symfony or Laravel.
There just is so much legacy in the PHP world that separating the wheat from the chaff in itself becomes tedious. And don't understand me wrong: legacy in itself is not a problem. It's the combination of PHP being easy to pick up, lots of outsourcing, people writing procedural code without any notion of code readability, lack of tests, use of global state, etc that usually just make me cry and move on. For me the percentage of worthwhile PHP projects to chase is too low in comparison with many other technologies.
Even though PHP was what got me into programming in the first place, I nowadays thus chose to pick other battles. But every once in a while I still nostalgiously float back in time to my childhood days, enjoying every line of the almighty 4MB imagemagick monstrosity scripts I conspired. And then I'm happy that you nor I have to solve these enigma puzzles.
use App\Events\ArtistInformationFetched;
use App\Services\MediaMetadataService;
use Throwable;
class DownloadArtistImage
{
private MediaMetadataService $mediaMetadataService;
public function __construct(MediaMetadataService $mediaMetadataService)
{
$this->mediaMetadataService = $mediaMetadataService;
}
public function handle(ArtistInformationFetched $event): void
{
$info = $event->getInformation();
$artist = $event->getArtist();
$image = array_get($info, 'image');
if (!$artist->has_image && $image && ini_get('allow_url_fopen')) {
try {
$this->mediaMetadataService->downloadArtistImage($artist, $image);
} catch (Throwable $e) {
}
}
}
}
https://laravel.com/docs/8.x/container#introduction
Or, if you wanted something perhaps at least use one of their featured partners for real code? https://github.com/tighten/jigsaw/blob/main/src/Jigsaw.php
I also would argue that the majority of code I see in other languages is equally or worse than the example you gave.
You can write terribly in any language, Laravel included.
The nails are http requests and PHP is a damn good hammer.
Hello World
You would need something like
import { stdout } from 'process';
stdout.write("Hello World"); console.log("Hello World")God I wish that was true...
It's not that the language is necessarrily bad. It's the sludge of legacy code I've had to deal with and teams treating it as the hammer for every problem that they think they must treat as a nail.
Efficency be damned.
I do wonder if there really was value in salvaging PHP when we have a wealth of other languages and frameworks that do a perfectly fine job without any of the legacy mistakes sitting around.
Among that choice set, PHP is definitely the best contender.
can rails compete with the performance of octane using swoole with 8k reqs per sec?
rails is the first framework I ever learned in 2012 but I kept jumping back and forth until laravel basically started lapping rails in terms of baked in goodies.
I have a HTML page. How do I add a hit counter to it with Ruby?
I can do it right now in PHP with zero dependencies and it'll fit in this comment:
<html><body>
<p>You are visitor number:
<?php
$count = file_get_contents('hit_count.txt');
$count = $count + 1;
file_put_contents('hit_count.txt', $count);
echo $count;
?>
</p>
</body></html>
When you want to do something, you can just copy and paste a handful of lines of PHP into a file and rename it from .html to .php and it'll basically work anywhere. You don't need to worry about frameworks or anything. Routing is handled by the web server. Hosting is handled by someone else. Deploying is just FTP'ing a .php file off to a server somewhere and then requesting it.
But when you are ready to get into "real" programming, that's all there too. PHP has a true learning _curve_. Every bit of complexity is only a small step from the previous. Getting started does not require a ton of background or knowledge. You can start out copying and pasting some code into the middle of some HTML and a year later end up working within once of the nicer, more comprehensive frameworks managing your dependencies with a relatively decent package manager... and still hosting it all on your $3/mo shared hosting.
If every professional developer stopped using PHP tomorrow, we'd still end up back exactly where we are as a bunch of people found PHP as the most accessible and direct solution to the problem they have.
While with rails, to do basically anything, you already have a full db ready and incrementing a counter using the ORM is even easier than opening a text file. So people avoid PHP because it most likely involves dealing with absolute crap code written with no understanding.
How it makes it harder? Or you compare PHP a language with Rails a framework? Maybe shut up if you have no idea or show us a pure Ruby code that does the same thing. Or install the most popular PHP framework, really learn that and then tell us that PHP made things harder. I don't know Ruby or rails so I can't shit on that like an idiot.
<? include '../menu.php' ?>
The tales of legacy mistakes holding back php are things with no basis in reality. What legacy mistake holds php back? Method names/parameter ordering?
When I started with php in 2001 those elite programmers at meetups were looking down at php because Java was cool. In 2003 those elite programmers thought php should die because asp took over. PHP kept going along quietly taking over the web until the facebook movie came out making PHP cool for a moment. Those elite programmers decided PHP was too mainstream and the why PHP sucked movement started. The elite guys moved to Ruby On Rails then node/MongoDB, angularjs, React, Nextjs leaving each ecosystem for the next hoping that one day they will strike gold.
I'm not even really sure why python is so popular for DevOps cause I do everything in php and it's unit tested and works well with reproducible results.
Nobody can tell me why PHP is “bad” or what Python does that PHP can’t. Inconsistent params are the only argument I’ve heard. Which my IDE solves. What about JavaScript splice vs slice. I look it up every time.
Personally, I can't stand writing PHP, because, sure, I can write secure, testable, safe code in any language, including PHP, but, how do I say this, PHP is the only language that feels actively hostile to my attempts to do so. The house style at my current company could be boiled down to "Check 3 times that there are no PHP footguns present in this code. We have been burned before." The developer experience and tooling is far behind comparable languages. I feel like I have to put my sysadmin hat on to fix anything that goes wrong with my environment.
When I write Javascript or Python, I have complaints and issues, but I enjoy writing code. I think PHP, for many programmers, including myself, is just a hostile and unenjoyable experience. If you enjoy writing PHP, I have nothing against you and am certain you will remain employable, there's a lot of PHP out there.
> Honest question: what are people using if not PHP? Node? Python? The 80% of us who aren’t FAANG and are writing CRUD apps.
Python, Node, Java, .NET, Ruby. MVC CRUD apps are pretty similar in all of these (also in PHP). All of those languages (including PHP) power many many many software companies (including FAANG, who use a lot of Java and C++, and Facebook famously was built on PHP).
Surely JS has at least an equal amount of foot-guns to PHP. I mean, at least PHP (to my knowledge) never had a meta-language written around it that compiles to PHP to make it safer.
Static typing, concurrency, blazing fast, single binary.
They have trouble grokking that there is a method of dev in which the server is not the language parser, so all other languages feel like a wrong step.
Here on HN someone just asked why anyone would write in anything except JS [1].
Now, Node has it's advantages, and so does PHP. My personal preference is PHP. But in mindset, Node is far ahead of anyhere that Rails or Django ever got in their respective waves.
This is important
* memory model (shared, per request, etc)
* request model (by the app or by the web server)
* compilation/build step
* deployment
* hosting
* tooling (IDEs, linters, testing, package manager, etc)
* how to scale
* available programmers
* community
* $ in variable names
* arrows (->) for accessing object members
* argument order in standard library
* not elegant enoughI have once heard an ancient prophecy (I think it's Greek) that says "Debating around PHP online summons the ghost of the dark behind your back" or something like that (I don't speak Greek, sorry).
In the Client/Server world now days, the most of the time you only need one or two languages, one running on the Client side (JavaScript for example) and one running on the server (**, Go, Java, JavaScript etc).
In that setting, JavaScript comes with the hard advantage of both-end compatibility, that gives you something like Server-side Rendering, which no other backend-only language could do, at least not "natively". If you have a foundation this good, people will build the library themselves when the language/runtime don't have it built-in. (the same is true when it comes to Swift/Dart/Kotlin. I bet there is someone/company out there writing both their app and their backend in Swift/Kotlin)
For "backend-only" languages, it's largely down to personal/team preference. Some needs performance, some wants "write-friendly" (contains many factors). But the problem is, the market now days is saturated with better options that also do more things (often in a better way). When you bring all the options on the table, then suddenly that-language-the-name-we-shall-not-say started to look way less attractive.
It's just that, comparison/competition kills things, no elite required.
Isn't it the definition of a "backend-only language" that it renders server-side?
The problem with swapping out php on the backend for node is now you have to maintain a node server, manage long running processes. If you make a change to a node file you have to restart the server. Where php is running under apache or nginx and files can be dropped in without taking down the site.
That's why everyone is going serverless.. who wants to manage a node server.
That's a lousy dig at Python. Stuff you solve with a free text editor and 15 seconds worth of configuration aren't real problems.
There was no chance of it being killed off rapidly as the author was perhaps implying. It might have slowly rotted away, had the maintainers not stepped up with v7 and hit a home run.
caching, jobs, docker via sail, authentication and authorization, one command to have a full multi team/tenant SaaS app template via jet stream.
even rails doesn't have this, as you need to choose your own implementation for auth and access control, something like sidekick for job queue etc....
plus the ecosystem. I've tried so hard to like other frameworks and some I really do (like remix.run) but the lack of real momentum and community hurts most anything else and just doing everything as serverless micro services isn't always preferred or using micro frameworks.
I'm excited for the new features and with octane you can get more reqs per second than Phoenix framework which should make it easier to scale apps with less resources.
1. The combination associative array/array data type is weird and I feel like the performance is not predictable unless you devote time to learning specifically about it
2. You're still stuck with all the weird legacy stuff, even if you don't use it, because someone else might bring it in
3. The OO stuff is basically like an old version of Java and a bit tedious to write. An IDE is definitely required
4. Many PHP developers formed their ideas about coding in the bad old days and will resist efforts to make code more testable or whatever because it's "too complicated."
The OO 'stuff' in PHP is far better. Notably, Traits, Statics and Testing.
Java (and JUnit) do not work well with static methods/classes, when it's unironically the most effective way to limit state. In PHP you can create a static class, that has static utility methods. Now you can ensure you have no side effects - unless accessing static properties somewhere, ofc. Then PHPUnit has no trouble helping you test these. It's a huge improvement over the acrobatics of booting up Spring to manage a singleton (which isn't the same thing as a static class) whenever you want access to those real static methods.
I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.
@Test
public void testSomeMethod_FromStatic() {
StaticWrapper1 staticWrapper = new StaticWrapper1();
int mockInput = 1;
RegularClass rc = new RegularClass();
int expected = 2;
int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput);
verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput);
assertEquals(expected, ret);
}
public class StaticWrapper1 {
static class StaticClass {
public int someMethod(RegularClass foo, int val){
return foo.someAddMethod(val);
/* it's not practical to chain, eg
staticWrapper2.someAddMethod(foo, val);
because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */
}
}
}
Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP.
Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.
PHP is better with how it deals with statics today, which bleeds into other areas like testing.
No. Just no. PHP will not be solid and elegant by evolution. It might have become an excellent tool for the area it's supposed to be used in, but the only way it could ever become elegant is if it had its python2=>python3 sort of moment. They would need to break it to fix it.
I don't think they'll do that, since I think they understand that it doesn't matter at all that the language sucks.
https://github.com/epiecs/phpmiko for connecting to devices and https://github.com/epiecs/mikodo for inventories and concurrency
The multi core coroutines comment is true but there are ways (to hack) around that.
The way I solved concurrency is just by forking and using sockets: https://github.com/epiecs/mikodo/blob/6bdcebe9fa7f44ffdedd82...
I use it at work atm does what it's supposed to. I also use Python as well but I wanted to know if it could be done in php :D
I’ve never learned to like the language, but have gotten pretty proficient with it. I don’t claim to be a PHP maven, though. I know that my style is fairly “primitive.”
I tend to use it for my backend work. It’s quite performant, has huge infrastructure support, and it’s entirely possible to write safe, high-quality, low-level systems in PHP. I’m a good engineer, and do a decent job; regardless of the tool I use.
C++ is the same way. People have been hating on that language for even longer than they have, PHP. C++ is still used for many major infrastructure projects, though; because it’s the best language for that kind of thing.
If you give a kid a chainsaw with the guard removed (as most arborists do), don’t be surprised, when the screaming starts.
PHP always wins when it comes to deployment and productivity. In my opinion that's the power of PHP.
It's also versatile. I used it for small projects, multi-million € projects, COM-port communication, API communication, prototyping and what not.
The syntax is not great, but to me PHP is this multi-tool that just gets the job done and will run reliable for years.
That's an interesting contrast to Python where the need to use "value = await fn()" v.s. "value = fn()" depending on whether or not that function is awaitable causes all kinds of API design complexity, all the way up to the existence of tools like https://github.com/python-trio/unasync which can code-generate the non-async version of a library from the async version.
result = fn()
if isawaitable(result):
result = await result
I didn't realize it had a significant performance overhead though, I should look into that.
Sounds like an excellent way to create weird concurrency heisenbugs.
And, if we're being honest, the reality is that for that chunk that would break, most of them would either not have a developer on hand to fix it, or would be what I call a "Wordpress cowboy" who has a WP site they set up five years ago that they never update, and the sum total of their development experience is installing various WP plugins until the site vaguely does what they want it to do.
It's hard, because on one hand, if we didn't have things like Wordpress, then PHP would be in a position to undertake more breaking changes that would overall give the language and its libraries the much needed quality improvements. On the other hand, without things like Wordpress, it does become somewhat questionable as to whether PHP would have survived the dark days of PHP4 and the early versions of PHP5.
In saying all that, the work that the dev team have done to add great features and solid performance, alongside the community which has done a lot of good things like PSR's and the PHP League libraries to me, is one of the key things that makes PHP still an attractive environment to work in.
Automattic is now more involved in PHP so hopefully that'll enable some collaboration
Originally GET/POST, cookie and environment values automatically became variables. This means page.php?id=123 gave you a variable $id. Along with no variable declarations, this was intuitive and was probably one of the reasons PHP was so popular with beginner developers. Unfortunately it was also the cause of untold numbers of security bugs, because people would write code like:
if (securityCheck()) { $isAdmin = true; }
//....
if ($isAdmin) {... }
So in April 2002, PHP 4.2 [1] was released that disabled this by default -- but so many (badly written) applications relied on this that it was not until March 2012 -- 10 years later! -- that PHP 5.4 [2] finally removed this option entirely.
I’ve used it since 2002, and have recently got back into it properly after a decade in architecture roles, and it feels very welcoming and love using it. And I _have_ tried the whole JavaScript thing, but simply find it’s ever changing build tools, package managers, etc a pain. Just my opinion though.
That still doesn't change the fact that, when you master hammers, you still have no idea of how to correctly use a screw.
Every language comes with some blind spots. Learning different languages is often enlightening because it forces one to see the solution space with a different kind of glasses.
Are you talking about building an Android app?
I've built app in different Javascript frameworks. Angular, Vue, React.
If I was building a website I would use PHP over Python, Golang or Javascript frameworks because what you get out of the box doesn't compare.
Each language does something well. If I was building AI python would be my first choice.
I have used Kotlin for web services and, while I prefer Scala or plain Java for that, some of my colleagues prefer the Kotlin syntax and features.
> what you get out of the box doesn't compare.
Would you like to elaborate here? I have used Rails and Django and they get you a lot out of the box.
Welp, guess all my Spring Boot web apps in Kotlin have actually been Android apps in disguise all this time..
Because it's not possible to instantiate an enum, if one appears in the constructor of a class it'll break auto-wiring. I've written my own IoC containers and one fundamental assumption in them is that when class_exists returns true, it is what it says on the tin. Using a specialized factory would still be possible. I wonder if other containers would break on seeing enums as well, but I hope they fixed this because it's not mentioned in the breaking changes. The documentation for class_exists doesn't mention enum.
If you mean classes with private constructors, those are technically illegal. According to the PHP manual, constructors must be declared public. The fact that private constructors work at all should be considered an implementation detail.
Breakage occurs when something is said to be a class, yet isn't a class but still appears in the parameter list of a constructor. The container would instantiate a ReflectionClass of whatever is being requested and pass that around. At some point it'll call newInstanceArgs either with configuration-provided arguments or with auto-wired dependencies. The first case could still work, but foregoes auto-wiring.
* A hydrator/extractor that changes the type of the value it handles
* A task or job that has a certain priority to it
I wrote an indepth article about this: https://php.watch/versions/8.1/enums#enum-exists
There is an `enum_exists` function that only returns true for Enums. It's fairly unintuitive to combine class_exists with enum_exists to filter out Enums, I agree.
I believe we are a few steps away from a fully builtin production ready server and db connection support.
"You’ve still got two colors. Async-await solves annoying rule #4: they make red functions not much worse to call than blue ones. But all of the other rules are still there: ..."
You can continue the story at:
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
I can see it being a boon for the esoteric stuff like ReactPHP, but for a regular MVC site it just seems like a unnecessary complication?
In JS land, it atleast makes interacting with the event loop and NOT blocking the UI thread easier.
Modern PHP might not have all the shiny features other high profile languages have, but it's getting there. It's slower than many would like because of much debt and legacy. But it'll get there.
Also, you can write shitty code in any language. I would bet that, if back then python was as easy to deploy, as PHP, we'd now be fighting about that the same way as we are about PHP.
I'm asking, because it was the hobbyists and kids who got started in PHP mucking around in their everyday white-label cPanel/Plesk-based web-hosting accounts in the very early 2000s that really gave PHP the mindshare of enthusiastic users and thus its staying power. But it's 2021 now: all the kids are getting started with NodeJS for server-side web-applications, not PHP.
With the decline of traditional web-hosting as something that people have and might experiment with (replaced at the low-end by Wix and Squarespace, and major "Cloud" providers at the high-end), what opportunities does PHP have to attract new eyeballs?
Years ago self-hosted WordPress and phpBB installs would have been been a good gateway, but both of those are going out of fashion owing to the substantial maintenance burden that comes with self-hosting. Everyone I know that used to self-host WordPress (former clients, friends, local small businesses, etc) have all given-up and switched to WordPress.com's managed-hosting model or gone with the aforementioned Wix and Squarespace.
Ultimately PHP as-we-know-it will last as long as Zend (UPDATE: it's now owned by Perforce?!? wow...) can secure sales/support funding, which is predicated on their continued penetration of major enterprise customers - or indirectly through the continued popularity of WordPress and the like, even if it's hardly ever self-hosted anymore.
Personally, my money's on maybe 5-10 years' continued credibility, and then another 15 years of slow decline into irrelevance.
My 6th Form experimented with Moodle when I was a student there - that was a loooooong time ago (2004? 2006?). I remember the staff weren't happy that Moodle allowed students to set their own avatars because too many kids figured out you could use animated GIFs as avatars, probably copied from eBaums or deviantArt; while others uploaded shock-images or just controversial content because I guess that's just funny to a bunch of 16yos.
The school ditched the experiment after a few months because Moodle simply wasn't delivering any real value: the teachers didn't want to have to type-up their handwritten lesson-plans and manually scan-in their existing non-digitized content, and those that did already have digitized content (those smug 6th Form computer science teachers, naturally) didn't want to have to "refactor" (I guess that's the right word?) their content to fit into Moodle's way-of-doing-things.
I think as the experiment came to an end we were only using it for ungraded quiz-taking - we weren't even using it for submitting homework (teachers still preferred e-mail for that: the 6th Form already had its own on-prem MS Exchange set-up that everyone used - and we could e-mail staff from our personal e-mail accounts too, which was nice - I know a lot of schools kept closed, on-prem-only, not-internet-facing e-mail systems to avoid spam - this was back when spam filters were awful and spam itself regularly included actual porn and other very-inappropriate-for-schools content, so I can understand why those other schools did).
----------
I haven't laid-eyes Moodle ever since then - every few years someone will mention it but I've never had a chance to speak to anyone who actually uses it to find out if it's actually any better than it was 15 years ago - and how it's changed at all. Can you fill me in?
And still far better than Blackboard?
It's replacing and older custom application, built on liferay (or alfresco? can't really remember).
However, it's doing okay. And it's scaling fairly big (~40-45k users).
Announcement
https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundati...
PHP Foundation
https://opencollective.com/phpfoundation
Accepts donations to help the development of PHP.
The community's complaints with PHP are far more concerned with technical matters relating to the language, runtime and libraries than how Zend etc have handled the usual issues in politics and project governorship. I don't think PHP has ever had a brouhaha anything like what happens in Java's JCP or the Oracle sale. Other platforms (like .NET) have their own foundations but they aren't taking seriously by the community because we all know the commercial companies that back the tooling are the ones that really matter.
...so what's the real reason for PHP suddenly switching to a Foundation-supported model? And why couldn't they entrust PHP with an existing and well-regarded foundation like Apache or FSF?
PHP is a community driven project, comparing that with C# or Java is a bit unfair because they are backed by companies worth billions.
What you describe about Zend I think that is more the old days before PHP 7. I don’t have the full picture of this but my understanding is that because of the failure of PHP 6 (never released), another group of developers from the community started to work with PHP 7 and I don’t think neither of them was from Zend.
Today there is an open RFC process and anyone can submit an RFC and then the core teams votes on it. If you contribute to PHP you can become a member of the core team.
If you want to be part of the discussion you can join the internals mailing list. Here you can read it without joining.
If someone is unhappy with direction of PHP my advice to them is to start contributing, bug fix, write documentation, translate, write RFCs, implement functionality, code review etc. Why? because PHP today is a community driven project.
Promises, async and await in javascript, coroutines and threads in kotlin, fibers in some language runtime (including this php 8.1 [0]), single process (nodejs), multi-process(php-fpm worker), single-thread, multi-thread, goroutines in go, multi-core coroutines
Googling the definitions and x vs y situation helps a little, the main confusion to me is why some people want this xyz feature in a language runtime and not the other, the pros and cons are seriously so confusing
I have probably used several, like promises, async, await, like others said async would be implement on fibers [1] (is php 8.1 implementation same as V8,spidermonkey,javascriptcore? or any other language runtime). And I have tried to understand kotlin coroutines as well
modern times to run php, people would use php-fpm with nginx, it is running multiple worker (single) process, so why would anyone [2], [3] wants multi-core coroutines in it? What does it even mean?
Writing this out ease my mind a bit yea, need to be able to communicate the confusion instead of just saying "programming is difficult"
[0]: https://news.ycombinator.com/item?id=29343773
[1]: https://news.ycombinator.com/item?id=29344427
Not everyone does. There's also https://reactphp.org (which is an event loop runtime, similar to Node), and https://amphp.org (also event loops), and Swoole https://github.com/swoole/swoole-src (coroutine runtime, similar to Go).
Fibers are basically an API that event-loop runtime libs can use so that userland code doesn't need to use promises or generators to run non-blocking operations. Fibers are not useful for php-fpm or swoole users.
On the other hand, though, PHP’s always tended to be a borrowing language that accumulates features from elsewhere, so there probably is some TS influence.
Also I hope we'll get generics at some point. I know there are some issues with their implementation, but even non-runtime enforced generics would be better then relying on a docBlock annotation.
Enums are neat, though.
class User
{
/**
* @Assert\All({
* @Assert\NotNull,
* @Assert\Length(min=5)
* })
*/
public string $name = '';
}
PHP 8.1
class User
{
#[\Assert\All(
new \Assert\NotNull,
new \Assert\Length(min: 6))
]
public string $name = '';
}That piece of code is about data validation.
See more at https://www.php.net/manual/en/language.attributes.overview.p...
Very similar to Java annotations.
https://front-line-php.com/cheat-sheet
It’s covered under “Attributes”.
I use it constantly not because it's well-designed but because TINA (there is no alternative).
[] == ![]; // true. Go ahead. Run it in your console...
Because an array is an object which has a 'truthy' value '![]' evaluates as 'false'.
Simplifies to a statement similar to 'false == false'.
A little useless arcana for those interested.
Well, not so useless if your expecting '!someEmptyArray' to evaluate to 'true'. Use '!someEmptyArray.length' instead.
PHP has become better and better over the years!
* it has its quirks but we know them and each newer version fix more of them.
* its damn fast (more than python or ruby)
* its type system is better than python (trait/interface , union type <3 , and now intersection type ! )
* symfony/laravel have evolved over the last 10 years, most of the things you knew 10 years ago are still true now
you will not find for example "genius developer, that write code faster than you think, who writes all his project in rust but is now thinking to switch to haskell and will leave your company as soon as it find a company that use it"
Take our company for example, our flagship web product was developed more than a decade ago, and, well, today we still use PHP, because rewriting everything in a different language is a gargantuan task. It's not only about the language itself, but also about all the tooling/best practices etc. around it, which you have to replace, and it's costly. We do gradually modernize our code to remove all the PHP5-era warts, and it's much easier to accomplish than switch to a different language entirely. Modern PHP7+ with Symfony is very pleasant to work with, and in my opinion, from the productivity standpoint, there's really no reason to switch to anything else. Also, PHP7+ seems to be faster than Python/Ruby in raw interpreter speed. However, we realized that we can't scale further if we stay with our PHP/Symfony monolith for everything because of Symfony's considerable startup overhead, so we now try to write new services in Go (request processing is usually 10 times faster for our loads), and seems like the combo PHP+Go is very popular among PHP developers in general.
So, I'd say, PHP isn't "dead" and is still widely used in 2021, however, in my opinion, its usage is indeed dwindling, because there seems to be a trend even in our own PHP community to gradually supplement/replace/augment parts of our projects with services written in Go, and PHP is more and more frequently equaled to "legacy"/"monolith".