PHP is probably the best language for server side webdev today. Still insanely easy to deploy, lots of features at the language level, and the frameworks that are available are very sophisticated. Whether you like Laravel or not, it’s influence is spreading to other frameworks within PHP and other languages. Also, Laravel has some of the best docs in OSS, period.
I think WordPress is pushing other projects forward as well. The tech stack over there doesn’t move nearly as fast, but the UX is still pretty good out of the box and with the enterprise clients I work with on a daily basis, they all still love WP.
Back to PHP proper for a minute, the language is fast. There are efforts being made to run PHP on Serverless infrastructure or with continuous process environments. New features are added to the language on a regular basis as evidenced by this post and others. The defacto package manager, Composer, is also world class.
It’s a good time to be a PHP dev!
As a final point, I’ll throw out some of my worries. I’ve been writing PHP since 2010~ as a high schooler fooling around.
The “Java-fication” of PHP is real. There is a push for more types and type related features. These aren’t bad in isolation, but as they move deeper into the core of the language, there is a risk of breaking legacy apps. Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. I’m not advocating keeping 100% compatibility forever, but recent versions have played more fast and loose with breaking changes. We’ve done a decent job of carrying the entire community onto new versions and that will be important for continued adoption.
Take a look at the open RFCs for more details. I think there is value for pulling good ideas from other languages, but we don’t need every idea from every language.
> I think WordPress is pushing other projects forward as well.
If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system!
Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites.
I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?
> It's shameful and disrespectful to take a client's money and give them a WordPress site in return
If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that?
I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time. It's better to have 10 code snippets to achieve 10 fixes, than 10 plugins to address those same fixes.
There must be a lot of developers out there paying their rent and feeding the cat from Wordpress plugin subscription earnings. While this does encourage the spammy ecosystem, it also encourages competition between plugin authors to maintain and develop quality plugins that do the job.
> Do these people actually not realize there's far better things out there?
I'd be interested to hear what good replacements there are for Wordpress+WooCommerce? I find WooCommerce slows down Wordpress, regardless of caching plugins and other tricks. It's annoying, and I'm genuinely interested in alternatives with as much flexibility and support?
> If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that?
None. I just finished up such a contract myself earlier this month. I was speaking of building new sites from scratch.
> I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time.
Put code in code files, under version control. Not in the database. Not in a blob field that gets eval()ed and is editable by users. This is sane web dev 101.
> I'd be interested to hear what good replacements there are for Wordpress+WooCommerce?
Drupal 7 + Drupal Commerce was very nice back in the day. I don't know the current state of Commerce under Drupal 9 but it's what I'd start looking at first if someone wanted me to build them a store from the ground up. Magento is still around, though I've heard that its code is incomprehensible. And if you're not afraid to take the thin framework or frameworkless route, the Omnipay library [1] combined with standard CRUD for the products should get you pretty far.
Insofar as there is an overlap between the two I'd pick wordpress. Shopify has all the painful buy-in that comes with a bloated sass with too much market share coupled with a marketplace that is just as toxic as that of wordpress. At least with WordPress you can control your deployment.
Yep, I almost added "not Shopify" when asking for alternative woocommerce suggestions, but thought that was a given! I did indeed mean alternatives where deployment is controlled. Wordpress+Woocommerce does actually tick along okay, like an old bus it blows a bit of smoke and eventually gets the user to the checkout.
> PHP is probably the best language for server side webdev today.
What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed.
I find most cheering for PHP and JS have very little exposure to other camps of software development.
> PHP is probably the best language for server side webdev today.
I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev.
This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.
> I have and to suggest replacing php/js with haskell as the best server side tool in general is signs that someone may be living in a bubble.
Please read my comment again. I'm not saying Haskell is the best lang for webdev. I'm just saying that claiming "PHP is probably the best language for server side webdev today" is missing a lot of innovation that is very usable for webdev, and hint at bubble think.
The "best language for server side webdev today" is going to be a matter of taste either way. But when one's saying it is PHP, I immediately wonder what other languages the person has done webdev in: since PHP is not a very nice language IMHO.
> I understand you have invested time in other languages, we all have but lets focus on facts not fears of your choice of language seeming less popular.
So what are the facts that make PHP the best for webdev? I dont think it is often picked for greenfield project by highly skilled teams, when given the choice to pick any language they like. And that would be a fact I'd respect in this context.
Php has been around for 20+ years which means the pool of experienced developers is much larger than other ecosystems with new languages. Greenfield php projects by experienced developers are created everyday.
When someone brings up haskell as a best choice for server side web development as a replacement for php it makes me think this person is either very new or trying virtual signal that they are smarter and more skilled because they use a more difficult powerful language. That's like saying building a laser from a kit to cut your bread is better than using a knife. Nevermind the cost, time, safety, availability of parts and employee market for each skill would clearly point to a knife as the best tool. Very few companies still in business build a laser when they need a knife.
The idea is that there are different things that different languages offer, and you need to know "what's out there" before you can claim that one language is the best.
For example, if you never programmed in any of statically-typed languages, you cannot say if they are better or worse. Similar things go for OOP-oriented stuff, or immutable-by-default languages or languages with well-designed stdlib, etc...
You may still think that PHP is the best language after trying a few other, wildly different ones, and that's fine. But unfortunately, in my experience, a lot of people who really advertise PHP (and some other languages like Pascal), haven't really tried the alternatives.
When discussing server side web dev, I think the most important aspect is the ecosystem and libraries/frameworks available as much as the language itself.
> Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure?
OCaml is an excellent language depending on what you are intending to do. I can't imagine though that it would be a pleasant generic server side.
The same would apply to most languages on your list, except perhaps Clojure who has an excellent ecosystem thanks to the JVM. But then, is Clojure a good webdev language ? maybe ? I only toyed with it for a very short time, but I don't see it on par with PHP or ruby for instance.
In my opinion, what makes a "language" the best for webdev is not its syntax. It is the ecosystem, the libraries, the amount of people that know it, the learning curve, the editor plugins available, the frameworks, etc.
Ocaml? Elm? Clojure? Haskell?. That's fun for side projects, not for real business.
> Why do you treat PHP and JS as similar languages? They're worlds apart, have different purposes and have almost nothing in common.
Because (1) both very often used in webdev, (2) both have many "adherents" that totally love the language yet have little exposure to languages of different paradigms, (3) are (opinion alert) not very well designed.
A fairly useful addendum to your list might be 4) both have grown up into completely ok languages.
If you, like me and many others, shrugged them both of for years and came back to them pleasantly surprised, it might change the timbre when reading that.
I'm not sure I agree that it's the best but it's got some things going for it:
- incredibly fast to deploy and iterate
- supported in some fashion on more hosting solutions than other languages or compiled binaries
- one of the best performing interpreted languages
Not all of these benefits apply to me so I don't use PHP but under the right circumstances I'd look at it again.
Find me a language without a few of those classic 'wat' quirks. They almost all have them.
PHP was quite fairly maligned for a long time. The issue was never "weirdness" but rather poor design. Starting with final 5.x they started turning it around and deprecating or fixing a lot of the worst bits.
JavaScript was a joke but modern js is tight, clean and generally very fast.
They have so much in common. They're far more similar than they are different. Both are procedural, object-oriented, loosely-typed. Their syntaxes are both loosely-derived from C. The similarities go on.
JS isn't per se. You can use it for OOP, but it's only a subset of what you can do with it (I'd argue there is enough traps that it's better used with other paradigms than OOP). I also don't see ES6 as very related to C syntax anymore.
To your point, PHP and JS could be close in spirit, pushing forward the good parts while letting the bad parts rot on the side, and heavily relying on programmers' discipline to build clean code. Good PHP devs tend to be good JS devs as well.
Your response is a perfect example of why these discussions are so difficult. What makes a language “good” depends heavily on your priorities and perspective.
I love Clojure, it’s so well designed. Haskell is hard to beat in terms of academic type correctness. But what if I’m trying to build a web app and my priorities were, ease of hiring and productivity, especially for junior devs, and a big ecosystem. Does Clojure win here against PHP? That’s a much harder argument to make. Would anyone say Rust is a better web development language than PHP?
All these tools have trade-offs. PHP is a fantastic choice for web development, the rough edges are becoming increasingly minimal with each successive version.
while there is certainly merit to choosing a language with a large talant pool. It drives me nuts how so many employers optimize for hiring juniors. Hiring a Junior is like getting a puppy and now you're picking a language that minimizes the scale of their messes.
I'd rather hire someone that knows what they are doing and give them tools to maximize the scale of their strengths.
2 good devs working in elixir, rails or clojure will accomplish far more than 10 juniors working in javascript or go.
I’ve personally tried projects in Ruby, Elixir, and node. PHP has been the best experience for me across both dev and production. Elixir has an excellent local environment story though!
> The defacto package manager, Composer, is also world class.
Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think.
I can't think of many things that really bug me much anymore.
Null coalescing operators and named parameters are the kinds of things that make me happy.
I also adore Laravel (and particularly Lighthouse).
But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.
The truth is whatever one's personal list of "must haves" and "should haves" are for a given language, there are probably at least 2 or 3 major languages that fit the bill in a given domain, and probably more if you're willing to use stuff like Haskell or Racket or Clojure (all fine languages but compare their popularity to JS or PHP to Python).
For every person who is vehemently in favor of one language over all others, it's usually pretty easy to point out another language that will get you 99% of what that other language will. So it's not a very tenable position to think one language is the be all end all.
But on the flip side, and in part because of the points above, "language cargo culting is stupid and should be avoided in almost every instance" can make a great deal of sense.
> There are efforts being made to run PHP on Serverless infrastructure
This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
> This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.
Yes, but now you have to pay for every requests made to your app instead of just paying $4 a month for a shared Apache server and I also have to architecture my PHP app in a rigid way to fit whatever "serverless" execution model the SAAS runs with.
> Which may be much cheaper than $4/month if you have very low traffic numbers.
A big IF. My $4/month stay $4/month without the added complexity of "serverless" deployment nor every stupid constraints this business model imposes. If serverless actually didn't make money, this business model wouldn't exist or wouldn't be pushed, mainly by Amazon employees here.
It's php, so your architecture by nature is already serverless unless you are using some newer plugin like swoole.
For most projects, that $4 server is great and what I would prefer. But where serverless can excel is an application that has very spikey usage.
If your $4 server gets hit with spikes of usage that would require a $500 server for an hour once or twice a month, you might be better off with serverless, rather than paying $500/month to have a server that big all the time.
why are we even talking about a $500 php server, that is like the 0.01% of websites, You either need really specialized requirements or to be in the top 1,000 websites to need anything near what you can get for $500/month.
That was an arbitrary number, but I don't think that is true. It doesn't take much functionality before you will start needing the power of a server in the $500 range. Many apps today do a lot more than serve up static requests. I run a php server with just a few thousand daily active users and we need a $250/mo server.
You have your app, and database, and then your logging, tracing, and tracking stack and It all starts adding up pretty quickly.
A fixed cost of $4 dollars that can host hundreds of websites or a variable pricing model where any traffic level would end up costing you more with no ceiling.
Choosing serverless would be a bad game theory strategy choice.
> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite.
This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.
Just anecdata. My SO is currently working for a very small regional dairy producer (think 18 people total). Naturally they have a website no one really knows how to handle. My SO needed to update stuff, received the login info and the first thing we saw was WordPress stating that php5.6 is too old and should be updated.
After some arguing with the company that is payed to manage their IT environment she got them to finally update the php version and now the server is running 8.1.
I was glad that at least wp was up to date. Current wp running on quite old php version and exactly nothing broke with the update.
I was positively surprised. Would have expected more problems from my experience with other projects in other languages.
The WordPress core team does a great job of updating to support new PHP versions as soon as betas are released. Hell, in the most recent version, they even patched in some of the new PHP8.1 functions so they can be used before the official release.
We all know the tech is out of date at its core, but I don’t think it’s fair when people say they’re holding PHP back when there is an active effort to keep things compatible.
It's holding PHP back in the sense that because there's so many WordPress installations out there running on old versions of PHP and old versions of WordPress, that _will_ have to update at some point, it means that PHP internal devs need to always consider how any breaking change they make would affect those users.
In general, the WordPress community is _slow_ and plugin authors and users definitely do not keep up at the same pace at the rest of the community using more modern frameworks. They tend to have written worse code in general, which are proportionately more impacted by deprecations and error promotions where the code wasn't using best practices.
The PHP internals maintainers hear complaints from people in the WordPress space saying "whoa you're making too many breaking changes too fast, I can't keep up", meanwhile having the developers of modern frameworks getting impatient, wanting all the new features to save them time in writing new code.
If PHP didn't have all these legacy projects still in use, deprecations/strictness changes could move at a faster pace.
I tracked the warnings and I keep up with changes out of necessity. But that's the least they can do - anything else would be insanity. However it does not make me feel any better when debugging version/compatibility/configuration issues between the language, different libraries and the environment.
I'm not saying there aren't good reasons for _some_ of the changes, including historical error prone baggage. I'm also not in any way try to disrespect the maintainers. But to say PHP is a stable language and ecosystem still does not reflect my experience with it.
The tests are there to give us confidence about _our_ code. They can help in those situations, but they don't protect us from others pulling the rug from under us.
Unless you're upgrading production before lower environments, you'll still find out exactly what you need to fix, won't you? And unless you're waiting until the last possible moment to upgrade core infrastructure I don't see how anyone is getting any rug pulled out from anywhere.
Again, seeing what will be broken is the baseline expectation. My comment is not about that. It’s about breaking changes, having to resolve them, facing incompatible versions (language, libs, tooling).
You telling me you broke my code in advance doesn’t make it OK.
Something I pick on with PHP is because requests are so isolated, it doesn't have a good story for pooling SQL and HTTP connections. Its model really limits you when it comes to sharing resources between requests.
It's possible to have persistent MySQL connections, but there's all kinds of caveats; MySQL connections are stateful, so bad things can happen, and the performance benefits are only very slight. https://www.php.net/manual/en/features.persistent-connection...
This is indeed a downside but there are workarounds -- The wikimedia foundation put out a good blog post talking about getting HTTP connection pooling for PHP
We handle 50-60 million monthly page views (comments embed requests) in our commenting system using PHP/Laravel, NGINX (2 load balanced servers), Redis (for queues and caching), and MYSQL.
All performance issues we have ever encountered were always related to the database - never had an issue with PHP or Laravel.
However, we use Node.js for websockets. Though there are some improvements in PHP for event-driven development (like ReactPHP [1]), it was quite hard to find proper documentation and help to build a production-ready WebSocket server. So, we ended up using Node.js for that.
The new features added to PHP in the latest versions are great. Type hinting and return types are really helpful in writing better code. I hope there will be an addition to type hint advanced data structures (ex: Arrays of Objects) in a future version.
We handle a couple million daily users, educational online reading product used by K12 schools worldwide.
Internal framework PHP monolith, nginx, Aurora MySQL, redis, Memcache, internally developed message queue, handful of small Go microservices.
While we're largely hosted on AWS, some countries require us not to be, namely China, where are product lives on servers run by the government. We've kept are infrastructure non-AWS compatible.
For our US installation, monolith scales up to 50+ servers during the day and down to a minimum of 2 at night.
At $WORK we serve billions of requests a month on with nginx, php-fpm, and Percona.
In total I think it’s something on the order of ~1000 application servers (nginx/PHP) that are specced to handle 28 concurrents, and 200 Percona instances of varying sizes. A big HAProxy cluster sits in front of the whole thing and cloud flare in front of that.
A whole bunch of memcached servers spread around too. By far the biggest bottleneck is the MySQL servers at the moment, so we rely heavily on memcached to keep requests away from the DBs.
I haven't. That's all Ops, and I'm a developer. We're a pretty small team of about 15, and managing physical servers would require a big investment in staff alone.
There is little difference in managing a bare metal server vs an AWS VM. Both can come preinstalled with your OS of choice. And you are responsible for maintaining the system either way. I'm not talking about colocating your own hardware in a data center. Just renting bare metal.
I am deploying considerably smaller applications but I've had good results lately with Caddy and PHP-FPM [0]. I tend to use MySQL 8 but I've made use of both Redis and Memcached where appropriate.
I don't even use any of the JIT stuff, but I will soon.
[0] Once I figured out how to configure Caddy, that is. (Laravel vs Caddy documentation ease of use is night-and-day territory.)
Do you have any specific comments regarding Caddy's docs? What exactly did you find difficult? I'm a Caddy maintainer, and I'm always looking to find ways we can improve.
(Thank you for your reply! I'm using some of that pattern. It wasn't enough for my requirements, unfortunately. What I have now works fine; I use the handle directive a fair bit and that makes sense to me. This is not a problem now)
The main problem with Caddy's documentation is that it is a maze of twisty tunnels! Lots of terse fragments of documentation that bounce you on to other terse fragments of documentation. It feels fractured and impermanent. I lose my place.
Part of the problem is inherent to very flexible packages like this, and it is going to be difficult to solve.
I think you possibly overestimate how many people have time to learn about the JSON syntax or API configuration, how many people want Caddy outside of a package manager installation, etc.
It almost seems to me that you need entire documentation guides -- "Caddy for Nginx users", "Caddy for Apache users", "Caddy for people who need an API-driven server" -- that have much more narrative flow to them.
(IMO, configuration file adapters are a hiding to nothing. Just explain to me why Caddy is better and help me make the switch)
I love Caddy for what it is now doing for me -- please don't get me wrong, I think it's an impressive project -- but after 28 years of configuring web servers I really need migration documentation that I can read in detail without clicking from link to link and lots of emoji people.
Small observation: the mid-blue text on a pale blue background for your code examples and monospaced text is difficult to read if your eyes are over 40 years old and it's been a long day.
This is valuable feedback, thank you. A lot of people just say that the docs suck and we can't do anything about that. This is more helpful. I'll see what we can do to improve cohesiveness and clarity/accessibility.
FWIW, I'm very comfortable with nginx, but preferred something with Acme built in.
What I struggled with most in setting up things with caddy was the context for a config statement.
I could usually find the config parameters I needed, but I had no idea at what level of nesting it was and in what context it was used.
I would have found it incredibly useful to have a reference caddyfile for every parameter so I could see it used in context and then just strip that reference file down to what I need and go from there.
In the end, I just went back to nginx and dealt with Let's Encrypt myself since that was what I was most comfortable with and decided learning this new thing wasn't worth the benefit at that moment for the specific project. I'll probably revisit it later this year.
Thanks -- I'm glad it didn't come across too whiny, because to be honest you've saved me from so much HTTPS pain so far I really will put up with a _lot_! :-)
I do want to work on improving the "Tutorials" section to make it apply to more installation methods (i.e. running in Docker requires additional setup to use the admin API, running as a service means you may need to turn off the service before playing with the tutorial, etc)
"Caddy for X users" pages are complicated to get right IMO, and I'm not sure it's worth the effort - those are also general purpose servers, and can be used an infinite amount of different ways. Comparing them is difficult and I'd argue that it's not that useful. Take for example https://statamic.com/vs/wordpress to get a sense of what I mean.
> I think you possibly overestimate how many people have time to learn about the JSON syntax or API configuration
I definitely don't; I spend a lot of my time improving and polishing the Caddyfile adapter since it's definitely the easiest way to use Caddy. The tutorials do put too strong a focus on JSON in my opinion (Matt wrote them). But on the other hand I think it's pretty important to understand that the Caddyfile _is_ an adapter to JSON and not the native config language. It's key to knowing how to debug and inspect how Caddy actually runs.
> how many people want Caddy outside of a package manager installation
I'm not sure I understand this point though, what are you trying to say here? You can definitely just download the caddy binary and run it wherever, you don't need to use a package manager. I'm not sure what this is trying to point to.
> The tutorials do put too strong a focus on JSON in my opinion (Matt wrote them).
I don't mean to start a fight between friends! :-)
> But on the other hand I think it's pretty important to understand that the Caddyfile _is_ an adapter to JSON and not the native config language. It's key to knowing how to debug and inspect how Caddy actually runs.
Agreed.
> I'm not sure I understand this point though, what are you trying to say here? You can definitely just download the caddy binary and run it wherever, you don't need to use a package manager. I'm not sure what this is trying to point to.
Sorry, I mangled that with a run-on sentence, didn't I! What I mean is, I think more users are likely to want the package manager, systemd-configuration deal. The automatic-HTTPS thing is such a strong sell that I think a lot of people will seek to replace nginx just for that.
I could totally be wrong here but this is where I think a sort of narrative document for Nginx users at least is perhaps worth it.
Some of this is always going to be a challenge because Caddy is a fascinating, category-straddling project; you've made a product that is somewhere between a magical automatic appliance, a Golang web dev framework and a traditional configurable server, that avoids the downsides of all of those things as far as is really possible.
Documenting that is definitely a unique challenge.
I'm prattling on now but thank you again for Caddy; it really is a great contribution.
We use AWS elastic beanstalk mostly, so just auto scaling EC2 servers running nginx, RDS serverless, SQS worker queues etc. Front end is static hosted on S3/cloud front. Handles up to ~100k orders per day.
I spent a decade writing PHP. I think the language is fine, but the lack of a real concurrency model (event loop or threads) pushed me to other languages for web dev.
Aside, but I hate ligatures in code. If I didn't know what they were, I would have no idea what the blog's representation of a fat arrow => or a triple equals were. As it is, I still have to translate them before I fully get it.
I remember when I saw the access operator "->" for the firsr time written as just a single connected right pointing arrow on a whiteboard as part of my first intro to programming class and being so confused about what button I was missing on my keyboard!
Words are only ever added to the OED after a period of use.
Before performant made it into the OED as an adjective, the nominal form was listed as a "nonce-word" only and didn't merit its own entry; it was kept under performance. It was never widespread in any dialect, unlike modern performant.
-Ant/-ent is not reserved for nouns anyway. There are informants, inhabitants, defendants, and many others, of course, but they can be ignorant, hesitant, pleasant, constant, tolerant, conversant, triumphant, significant, vigilant, dominant, compliant, adamant, reluctant, elegant...
Some of the second group fall into both categories, adjective and noun. Frequently the one form came later than the other. Add performant to that long list.
(I always forget how HN is hostile to whimsy. Even when it is carefully signposted with an emoticon.)
Just to add though: a word making its way into a dictionary is no guarantee of its usefulness, correctness or value. It only means a couple of definitions have been found in print. That's the standard by which words make it into dictionaries; there's no semantic gatekeeper.
You're qualifying my response as "hostile?" I guess we're getting into fluid definitions, so sure :) I'm not sure calling someone wrong accompanied with an emoticon qualifies as whimsical, either.
All that said, "correct" in language is "incorrect" tomorrow. That's how it's always worked.
If I learned to accept "entitled" as meaning "given a title" I'm sure we can all handle a fairly terse and parseable usage for performant.
No, not you -- that was exasperation at the sudden, aggressive downvoting of what was clearly signposted as a joke.
> I'm not sure calling someone wrong accompanied with an emoticon qualifies as whimsical, either.
It was as clearly whimsical as I can make it. Complimenting on being wrong on something so small.
But you're just making my point for me. I genuinely forget this place hates jokes that don't come with footnotes.
> If I learned to accept "entitled" as meaning "given a title" I'm sure we can all handle a fairly terse and parseable usage for performant.
I wholeheartedly agree. I don’t think I will ever understand why people want to mess with legibility in a craft that is so heavily dependent on using correct characters in correct places.
Author here, I agree. I use ligatures mostly because I write JS and it's not that annoying. Now that I wrote something about PHP it's a bit problematic.
I tried to like ligature coding fonts. I really wanted to like them. Ligatures are a really cool feature of prose fonts, and often even make text more readable. And they looked cool when I first encountered them in code. But every font I’ve tried with these ligatures added cognitive load in practice. And now I find the same when I see them in code examples.
Maybe there’s a way to do them “right”, where they have the same positive impact on code readability. But I haven’t found a font yet which pulls that off.
I’m not a font designer, so this is just using my imagination, but I suspect they’d work better if they still left some space in the monospace grid rather than fully spanning multiple characters. Eg => looks like an arrow but with a very fine gap (1px at any size? maybe 1 device pixel on high DPI at smaller sizes?) between the characters.
I think the hate for ligatures is overblown. You'll only encounter them in code, so you should instantly realize what they represent. I can understand _preferring_ to not have ligatures enabled, but hating them entirely seems unwarranted.
I mean, I don't hate them, but when I was reading this code, I came across a section that had what I presume was "===" (three equals signs) but it was three vertical lines the length of em-dashes stacked on top of one another, and this looks like absolutely nothing I can type.
And, I think that's really my objection to coding-specific ligatures. When you're used to them, you can "instantly realize what they represent," but they're rarely as clear as simply displaying the characters that you type. Historically, ligatures come from slightly tweaking the aesthetics of letter pairs or triplets to be (subjectively) more readable, never in ways that obscure the actual characters. Coding ligatures are arguably designed to obscure the actual characters being typed. That might be relatively inoffensive, like joining the characters in "=>" to make it look like an arrow, but it's not materially helpful -- and sometimes, like the Three Mystery Lines, it's actively puzzling.
With monospaced fonts, as used in programming, the ligatures take up 2 or more "spaces", but the special characters only take up one space. Thus, they are quite easily distinguished, for me.
It’s an opinion. About typography. I can’t understand having an opinion that another person shouldn’t have whatever opinion about typography they want.
If you really want to go down that rabbit hole, I was simply stating my opinion on another's opinion, and I can't understand having an opinion that another person can't understand another's opinion.
Liking or disliking something harmless is a matter of taste. Treating harmless preferences as subject to outside validation isn’t. It’s perfectly reasonable to expect that everyone is allowed to enjoy or prefer what they want, as long as no one is hurt by it.
You didn’t express a disagreement with the opinion, you expressed that the opinion shouldn’t exist. That’s not the same thing.
I said that the hate is overblown and unwarranted. That's not the same as saying it shouldn't exist; rather I was hoping to hear some good counterpoints to help me understand why some people dislike them to the point of hatred.
I've probably written some version of this comment over dozen times throughout the years when discussion about PHP rears its head (note that I'm fond of PHP):
PHP as a language is... okay. It's been modernized to include many of the faculties a developer would expect of a language in 2022. But honestly, I'm ready for the "improvements" to the language to stop. The closer you get to C# or Java the more obvious it is that PHP will never catch up! It's not that it has to catch up, rather, that few people actually choose PHP because the language is so great. If you were choosing a your stack based on "which language offers us the most features or highest ability to express our problem" you wouldn't be choosing PHP!
Here's the secret: PHP is probably the best language for server side webdev because of the runtime! It's so dead simple to develop and deploy PHP. I mean the language itself is basically a web framework right? How many other languages automatically parse an HTTP request and hand it to you by default? Or offer built-in templating semantics for composing HTML? Or have request routing by default? I don't know of another one. That's why I, and many others, choose PHP!
You know what I'd like to see? The trajectory of PHP's development change to lean in to the above -- to focus development on improving the reasons why it is chosen in the first place! I don't need a C# with slightly different syntax (or named parameters). I'd like:
- Improved templating semantics
- A better module system
- A way to bake routing into each file (overwriting the default semantics)
- Adding a built-in service-locator pattern/DI
- A way to make PHP scripts more testable
What I'm saying is just make it a better framework by default. I know I know... "Laravel this, Symfony that, have you heard of Slim?". Yes... I get it. There are community-made solutions to the above problems. And you know what? They won't be as performant or integrated as if the runtime itself was upgraded to make them obsolete. It's not like routing and DI are that complicated (the two most obvious reasons frameworks are employed).
I like that I can write a simple API in PHP without pulling in a single dependency! It makes so many things easier (the right things too). Now let's just extend that to all of the basic facets a modern web framework offers!
The odds of those things being worked into php-src are very, very small. Most of the time there has been discussion on these topics on the internals mailing list, it was clear that the majority favored keeping those things in userland.
The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.
On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?
An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?
For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.
+ Composer is so great that installing any of these packages is a breeze anyway.
I used to look down on PHP, but after being forced to use it for a while I begrudgingly came to admire it for all the reasons that you've pointed out. And I started using PHP by choice, generally for writing small scripts (no frameworks or libraries) that I could "deploy" simply by copying the .php file into /var/www. It's a very productive language when used as intended.
PHP scripts on shared webhosting was the original "serverless" and you didn't have to be too careful about object lifetimes and leaking database connections because as soon as the request was finished the entire process was nuked from orbit.
But "modern PHP" is the complete antithesis of everything that I grew to admire about PHP because it's just another Java or C# with awful syntax and weird equality rules and gigantic frameworks with thousands of classes and interfaces.
I would very much like to see a version of PHP that dropped all the nasty namespace and object-oriented misfeatures and just focused on cleaning up the language semantics and enhancing the built-in framework features...
> because of the runtime! It's so dead simple to develop and deploy PHP.
As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.
The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...
I deploy PHP applications all the time! I simply cannot share your sentiment though.
I cannot think of an easier deployment paradigm than what essentially amounts to a copy and paste in the simplest case (i.e. what we should strive for), and maybe one or two more steps in a more complex case (e.g. `composer install`).
An entire PHP installation can literally be copied and pasted onto another machine and "just work"(though you may need to fiddle with some paths in the .ini). Similarly PHP is fast enough that it's unlikely to ever be the bottleneck in terms of performance/scaling for 99% of use-cases.
I suppose I can agree that PHP may lend itself well to certain kinds of "bad practices", but that's true for any system if not managed well.
I think we live in different worlds, and that's a bit PHP's problem, many of it's devs and users do.
From my pov, manually logging in on a server has been something for emergencies only for a long time now (10y+), and if it's frequently required or even essential to deploy and run an application, this is a sign of bad practices. So the last thing I want to read to deploy some software is "can literally be copied and pasted onto another machine". Maybe you can do that, but you never ever should even have to consider doing this. Where is your versioning, ci/cd (testing, quality gates, automated deploy), how do you roll back in case of a problem? How do you track when new versions were deployed? How do you address patching, runtime differences, active PHP modules and php-level config? What webserver do you use, how does it need to be tuned for your workload? PHP-FPM? Do you expect something specific? Do you rely on .htaccess files? The list goes on and on.
These things are a major hassle at the scale I've had to deploy PHP services. Its best option is containerise them, and then you have a bunch of other challenges due to the process per request runtime design impacting monitoring, metrics, autoscaling, ...
Sorry. I wasn't advocating for "copying and pasting", rather, I was using that as an example of how simply PHP can be managed. More generally, the simplest case is often a good proxy for what to expect when dealing with more complex scenarios. Of course we automate the above behind the proper pipelines!
Many of your other concerns are big "nothing burgers". It's not like versioning, patching, config, tuning, monitoring, etc. are any less of a pain in other runtimes. At worst you could argue that it's different.
Because of the separation between PHP and the web server it makes developing PHP really easy because the web server handles the request for you.
But you pay the price when configuring your environment. Apache conf, php.ini, php modules, htaccess, etc.
To avoid too much craziness I tend to avoid custom htaccess files, unusual php modules, or weird php.ini settings to minimize the friction when deploying.
For large project you are almost required to run containers, but even then you can’t escape the custom bash script.
Used PHP for many years for high volume web applications. My biggest gripe is you (at least had to) run php behind another server (nginx, Apache) which meant your "scope" is always restricted to serving the current request.
If you want to do something like share some heavily read data across processes you need to then introduce memcahe/redis in to your stack, whereas in something like Go this can be done in your application code. This also means PHP is a nightmare for connection management to others resources like your database - if you autoscale your API you are in a very vulnerable place for maxing out connections on your database as every client request needs to create it's own. You can solve this with something like Envoy I think, but again it's adding more complexity to your stack, more tools to configure and deploy.
This was my main issue with PHP. I found the language itself fine to be honest. Not the most elegant but hardly as bad as people make out.
Next time you need to take a look at PHP, those two problems can be solved by php-apcu for caching and proxysql running side-by-side with php-fpm on each server.
I see comments like this an it always confuses me. AFAIK pooling or proxying a DB is actually worse for concurrent performance, because as soon as you hit the connection limit threads start waiting. It almost always makes sense to increase your DB capacity, or move hot data to a cache.
With apcu you're going to pay the cost of serializing/deserializing the data.
If you dump your read heavy data into a PHP file on disk, that just has a return of your generated data, you can be benefit from having that bytecode compiled data stored in opcache for free (for the entire lifetime of the php-fpm service, or until you reach the maximum opcache allocateable memory).
I think that PHP gives you a few nice utilities to handle sharing, but they are problem specific. For example you might also spawn threads within a background PHP task, and there is shared memory functionality you can use in that case as well which is going to be faster than apcu or opcache.
Latency just connecting to PostgreSQL (in my case) sucks anyway, so I end up having a connection pooler between PHP and the database in production just for the latency's sake, even if I don't care about scaling.
The only thing stopping me from using PHP is just I’ve been burned in the past by massive breaking changes going up in major and even minor versions. Granted they are major releases, but the amount of work to bring existing code up to “code” is a gargantuan amount of work. I’ve dealt with similar issues in Ruby as well as Rails, but it wasn’t too hard to fix and even older syntax is happily accepted without deprecation messages. With PHP, I’ve had to cleanup very verbose code (often from older open-source packages or software) and spent hours and hours cleaning up breaking changes.
Not sure how long ago you used PHP, but backwards compatability has in my opinion been excellent for at least 15 years. A ~500k LOC PHP project has basically been effortless to keep up to date with the latest versions. From what I can remember I've only done search and replace a couple of times in that period.
Well, code I wrote in 2006 still runs in production today, with very minor changes. I can't really be happier about backwards compatibility story. :)
I guess I started writing PHP when PHP 5 was already a thing, didn't depend on any third party code, and used PDO from the start, so... I guess I was lucky to pick the right abstractions.
The PHP 4->5 migration was harsh (but that was 2008 if I am not mistaken, the big 4.4 deadline was on 2008-08-08 and I've not heard anyone curse since then.
The backwards compatibility story has been much better lately in php, including across major versions. There were some bad practices with previous versions that had to be cleaned up, unfortunately.
$ php -a
php > echo $foo;
Notice: Undefined variable: foo in php shell code on line 1
> This is only a notice error, and PHP will happily carry on. This can be confusing for those coming from “exception-heavy” languages, because referencing a missing variable in Python for example will throw an exception:
> The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.
This is the kind of mentality that scares me about PHP. The author is saying that an undefined variable is just a small thing, nothing to be worried about and the correct behavior is not to "freak out" about it and just carry on. And only stop if something "extreme" happens.
Am I crazy to think that this is crazy? I can't think of a case where continuing with program execution after referencing an undefined variable is a good thing. Trying to use an undefined variable is a bug, a potentially very serious one, so I prefer my language to stop me from writing this bug, not just "note" it.
I thought about not responding to avert judgement, but how is this not ok for 99% of all websites? Where an "undefined variable" is very much a "small thing"?
I mean, we have ways to catch those errors, its just that when they do appear in prod its usually because the project is so low impact (99%) that the budget for testing and whatnot is nonexistant (and the reasons for that vary from project to project, of course).
My experience suggests that, were this error to appear in a more complex component (say a shopping cart or notification system) these "non-entirely static-content-based" parts usually are either separate projects or have their own adequately-sized test code.
"But this is not a website, its a complex web app" - then PHP was probably not the most sound technical choice from the start.
"But this teaches bad practices" - practices are always evolving, new languages appear from time to time. I'd rather work on fixing real world problems.
"But PHP is old!" - so is Java... besides, another name for "old technology" is "stable tecnology".
In short, it is best if there are no errors in your code (haha yeah right..). If there are any, and its a website written in PHP acessing an undefined variable, it is probably a small thing. And if its critical that it does not happen, its usually an engineering blunder. Not the language's fault.
Every time a PHP post makes it to the HN frontpage, there's a ton of people saying how easy it is to pick up, build a project on, and deploy. I sometimes wondered "hm, maybe I was wrong about it, I might try it out". I had no idea it had skeletons like this hidden in the closet.
One day I hope PHP will come up with a more user friendly template literal system. I love the javascript template literal system since single quotes and double quotes are all fine, and you can add variables, ternaries, and even functions inside of your template literal.
With PHP there's no one great way to write templates, there's all just kinda clunky ways (e.g. heredoc or using double quote strings with variables inside).
There are a lot of great things here but PHP just needs to embrace static typing (IMHO).
Take match expressions plus enums. Incredibly useful. You know what's even more useful? When it's a type error to leave out one of the values. This means when you add a new value you'll get a bunch of errors you need to fix. Technically you can get around this with a default case but I consider that an anti-pattern in most such cases.
The Hack type system, particularly the ability to express nullability, is just vastly superior.
Named parameters are an interesting one. The Hack equivalent is to use shapes [1]. This is slightly verbose but you can express what shape fields are required and optional. Javascript manages without named parameters using anonymous objects, which is basically the same thing.
I didn't know PHP lambda expressions can't be multi-line. That seems weird. Again, Hack is simply better here allowing both this syntax and anonymous functions, all of which can be multi-line.
I also find the Hack collection types (vec, keyset, dict) to be superior to PHP's array with more obvious semantics and less weird type coercion. PHP's default of maintaining insertion order is amazingly useful and I'm honestly surprised more languages don't copy this. Of course you have things like LInkedHashMap in Java but doing this out-of-the-box I tend to find more natural.
Anyway, I think the hate on PHP is a trope at this point, largely outdated and just boring. Modern PHP is actually quite pleasant to develop in (IMHO).
> The Hack type system, particularly the ability to express nullability, is just vastly superior.
I agree the type system is superior, given the language was created to have a type system in the first place (PHP was not).
But PHP has allowed nullable types in syntax since PHP 7.1.
> Named parameters are an interesting one. The Hack equivalent is to use shapes
Hack shapes are not Hack’s answer to named parameters. Instead they’re a way to specify dict contents on a more granular level. A comparable array shape type, expressed in docblock form, is now supported by all major PHP static analysis software.
> Take match expressions plus enums. Incredibly useful. You know what's even more useful? When it's a type error to leave out one of the values.
Most PHP static analysis tools give you this information.
> I also find the Hack collection types (vec, keyset, dict) to be superior to PHP's array with more obvious semantics and less weird type coercion.
Absolutely agree with this, but for now (and maybe in perpetuity) we’ll have to settle for the swiss-army-knife array type.
I don’t think we need static typing as a requirement. For folks who want to opt in, it’s probably fine.
The divide could be catastrophic and for me, would be a major turn off. Look at JS and TS. Some projects go all in, but then others half ass it with `any` return types all over the place. If the JS ecosystem can come together around TS, it’s probably still a decade out until it becomes the default used everywhere. That gap creates confusion and chaos.
If people want similar languages with more/less features, they can create those communities. Erlang and Elixir are good examples.
I don't think there's an alternative to optional static type checking at this point. Like you say, there's a bunch of untyped code out there.
I'd actually hate to see a JS/TS divide in PHP. The typing needs to really be a superset of existing PHP and backwards compatible. Such a typechecker should cover at least the following:
1. Point it to a codebase and spit out a bunch of errors/warnings; and
2. Run it at runtime where type checks are logged or a strict mode where they're fatal.
> There are a lot of great things here but PHP just needs to embrace static typing (IMHO).
Static typing cannot be retrofited into PHP. Core already has hard time with generics. PHP Types will always be just type guards with dynamically typed variables.
Because I never intentionally follow the updates of programming languages I use, I find from time to time that I am not using the new features. However, I find JetBrains IDEs can be very helpful in this regard. Its warning messages educate me to use new language features I am not aware of or I have never tried.
Does any other language require to use a special notation, similar to PHP’s “$”, any time a variable is referenced? I can only think of CSS, using “--“.
> It kind of annoys me that they all require $ on the left, whereas shell only requires it on the right
Interesting - it makes it look like Bash uses $ to “read” from the variable, while in PHP/Perl $ only indicates that the rest of the symbol _is_ a variable.
>>PHP also inherits shell's here doc syntax, e.g. <<EOF . Not sure if Perl has that.
It does.
>>It kind of annoys me that they all require $ on the left
Larry Wall says he went that direction to make namespace clashing between $dog, @dog, %dog, and "sub dog {}" (scalar, array, hashtable, function) a non-issue.
Back in the eighties, my father taught me that the “$” character in BASIC meant “string,” so when I later picked up PHP in ‘98 I mentally thought of $someVar as “string-someVar” (regardless of the actual type, which was of course no problem for PHP), kept that habit for well over a decade… I think it was partially my self-disgust over such silly and technically incorrect thinking that led me to bail for Node as soon that was a feasible alternative.
The dollar sign does kinda look like a loose piece of shoestring, though
I can't remember all details but in Lisp in small pieces, author describes variable handling with a table { creation, reference/access, modification, [deletion] }
with each category had it's own optional syntax, many language will avoid this through context in which the symbol is, thus (+ a 1) equates (+ (deref a) 1), but he meant that it was a choice and not an obligation and some systems used $ or other syntactic constructs.
krapp has already mentioned the Unix stuff. BASIC had a thing with a $ at the end of a string variable, iirc. Windows' CMD.EXE used %VAR% notation (and later !VAR! notation).
jQuery's $ and lodash's _ are not prepended to a symbol to denote a variable. Both are objects actually. In the case of jQuery, $ === jQuery (the root jQuery object). The case that the parent is talking about is PHP's requirement that all variables are denoted as such `$variable_name`. (Perl and Bash also do this)
The Named Parameters [0] are useful but there are editors that solves the problem in another way. Write a function with a docblock [1] on top of it and then mouse over the function call and it shows you the documentation of the function with every parameters use. Or start typing the function name and autocomplete fills in the rest with parameter names and show the docblock above. Saves my sanity many times per day.
The obvious downside of this is that you're adding all these noisy "@param string $filename The name of the file." and "@return string The modified filename." comments.
A lot of PHP projects are littered with this kind of stuff, and when there's actually some important comment it's easy to miss.
It's okay-ish if you need to document that actually needs documenting, but if you use docstrings for typing/IDE assistance people will document every single thing for that, leading to useless "documentation" like in my previous comment.
That said, I personally prefer just a paragraph or two of prose over "structured" formats.
As someone who played around a lot in Swift back in the day, I love named parameters and can't wait to be working on a project where I can use them (it will probably be a while). They really help the code stay self-documenting and solve the "Is it $haystack, $needle, or $needle, $haystack?" sorts of confusion.
I think named parameters were a mistake for PHP. They weren’t really added for documentation purposes, but to avoid the situation where a function with n arguments with default values needs you to specify all the intermediate ones just to override a value at the end.
They’re a great idea in languages designed with them from the start, but adding them to an existing language makes something that was previously a private implementation detail part of the public contract, and only for certain versions of the language. There are already packages that opt out of considering parameters names part of their semantic versioning, effectively demoting it to a “use at your own risk” feature.
I would almost have preferred it to be added only as a special case for built-in features, which are almost all plain functions and have become somewhat unwieldy in places. Third-party code is more often than not object oriented, and so could easily lean on stuff like parameter arrays or fluent interfaces to avoid the ergonomic issues from having tons of parameters.
All these features have been discussed countless times in "new release" threads and such, but I don't think I ever asked public opinion on the "spaceship" operator, so I want to raise the question this time. I always ignored it as a feature that I personally don't need, but somebody else does, so ok, whatever.
You see, I actually don't think I ever used usort in about 10 years (or how long is it since anonymous functions were introduced). Instead, in all of my projects there is an implementation of https://underscorejs.org/#sortBy
The difference is that the callback maps the value to something that is already sortable using other native PHP functions, like an integer or a string. I find it way more intuitive than writing these function($a, $b) {/* try to remember which of [-1,0,1] it is supposed to return */} abominations. So as a solutions to remembering "which of [-1,0,1] should it be" I'd expect just natively implementing in C sane sortBy function to replace this pre-historic PHP bullshit. But whatever, it's a matter of taste…
…Or so I thought until now. Now that I think about it, I see [-1,0,1] callback as something really fucked up. PHP usort (and basically all PL ordering functions I know) can order only linear sequences, i.e. it returns an ordered list. Not even a lattice. Basically this means real numbers (or, more comfortable to use in a PL: strings). And with [-1,0,1] I can define whatever the fuck I want. There's nothing to stop me from implementing "paper/scissors/rock" (or even something much more convoluted) in it, and I have no idea how usort will behave then. That doesn't sound good.
So I'd like somebody to persuade me that I personally need [-1,0,1] comparison model for some use case I apparently never encountered. The only reason I can think of why [-1,0,1] might be better is performance (or RAM, actually), but I don't accept it as a valid argument: somehow even my non-optimal sortBy PHP implementation always turns out to be enough, and if I really should worry about sorting performance, PHP probably isn't the right language for my use-case anyway.
Technically they are equivalent, meaning that theoretically you can implement one with the other. The main advantage of sorting with [-1,0,1] is if you are sorting by multiple parameters
Convoluted example: sort some cars by year then by weight except with all Toyota first
In general it is easy to simulate multiple SQL `order by` clauses with [-1,0,1].
Using primitives you can map each car to something like "0t-1994y-0300kg" (remembering to left pad numbers) and sort by that.
In practice they are equivalent (when used correctly) but it is easier to implement primitive sorting with [-1,0,1] than viceversa.
Sometimes I wish languages would have native equality and order operators on (immutable) arrays, so that [1,1]<[1,2]<[2,0]<[2,0,-1] would work...
They are not "technically equivalent", as I've shown above. You can implemnt papre/scissors/rock with [-1,0,1], which is not linear ordering function.
And you didn't show anything for which ordering cannot be defined by mapping objects (with any number of parameters) to strings, which is kind of the whole purpose of sortBy anyway.
> And you didn't show anything for which ordering cannot be defined by mapping objects (with any number of parameters) to strings, which is kind of the whole purpose of sortBy anyway
I did so by intentionally, as i believe that mapping to complex enough strings is enough.
> You can implemnt papre/scissors/rock with [-1,0,1], which is not linear ordering function.
In PHP and in most other languages NaN == NaN, NaN === NaN, NaN <= NaN, and NaN < NaN are all false due to how IEEE floating point numbers are defined so you can have weird stuff going on there too.
I've never used the spaceship operator in my own code, and whenever I see it in someone else's, I almost always have to look it up to remind myself what it does.
I guess it's a nice feature to have, but I tend to forget that it exists. Clearly it's not exactly a new feature I was ever very excited about.
It doesn't help that writing my own sorting callbacks is itself something I rarely need to do.
"PHP and MySQL" by Jon Duckett (Wiley, 2022) is a great introduction to server-side web development. If you are familiar with his previous books then you'll be glad to hear that he employs the same highly-visual yet comprehensive approach.
How widely is modern PHP deployed on the super-cheap shared hosts? Being able to write robust web applications that can be deployed on any cheap shared host in the world seems like a superpower.
I've never seen an affordable shared host that _didn't_ offer at least PHP support. They may be a version or two behind (the cheaper they get, the further behind) and they may have some functionality disabled for security (system(), file_get_contents HTTP calls, etc.) but for about half a dollar a month you can get a reasonably competent web host with enough storage to run a blog for years.
That said, if you care about performance, be wary of shared hosts. Some frameworks, like Symfony, need quite a bit of CPU and IO to build a up a cache to get acceptable execution speeds. Nothing too dramatic, but shortly after setting up a website it may be slow on shared hosts with strict CPU and memory limits.
For tech businesses, I agree wrt VPSes; but for businesses that run a couple of WordPress sites and where tech isn’t a core competency, you can’t beat traditional shared hosting from an ease-of-administration perspective.
I believe most common is to use VPS managed by some third party service like Laravel Forge, Ploi.io, Moss.sh, Serverpilot... It gives you more control and isolation but it's still pretty much like shared host experience and not much more expensive.
With PHP 8.1 I can easily map database JSON column as an array in a model class by setting the property type as array and the database abstraction runs json_decode on array typed properties when fetching and json_encode when saving. Quite handy.
The example in the article is poorly chosen, because an associative array (map) would be more suitable. What you wrote is almost the same with PHP:
['abc' => 2, 'def' => 3][$x] ?? 'default';
PHP's `match` is a kind of functional `switch`. For instance, in the following example, an associative array would induce several useless function calls, and `match` is more readable than a sequence of if+returns:
Yeah, it's more like a switch but as an expression. Some more examples: https://php.watch/versions/8.0/match-expression It only executes the matching branch, ignoring the others. If you used an array/map + index, then it executes the right-arm of each of the options if they're functions for example, even if their result is thrown away.
I wish. As far as I'm concerned, Hack was a better language and I wish it had taken off. But no. For one thing, HHVM supports XHP by default, but PHP doesn't, so you still need a separate framework with a DSL to safely handle HTML in PHP. Hack also had async/await, type checking and generics.
Also PHP's Composer no longer supports Hack. Hack was supposed to get its own package manager but AFAIK that never materialized.
Coming from someone who doesn't use php except when they have to:
PHP today is so so SO much better then the blubbering eldritch horror that was php 4/5.
I'm still not going to use it until they fix the ad-hoc/chaotic naming of their built in functions, but it seems there's a proposal to alias all their functions to new names that make sense and are consistent with each other. When that happens php will not just be widely productive, it'll be widely liked too.
I'd personally prohibit all PHP websites that require directories which are writeable + executable. This means basically every app which can be updated from web interface, or has plugins which can be installed from web interface -- Wordpress being a primary example.
I understand that it is convenient to deploy, but a single exploited vulnerability can turn a web server into a part of botnet, forever. And this has happened, numerous times.
I don't have a specific suggestion for alternate system, but it should have a very clean separation between "code" and "data", and have a very easy way to completely replace "code" part. This can be done with Docker, or deb-style installation, or just a sane design which keeps things separately.
And of course you can do it with modern PHP.. it's just that language makes it so easy to do the insecure thing. "I'll just make an uploads/ right next to my index.php, so users don't have to mess with server config too much" - and bam, you have a vuln. Compare it with Golang, or Java -- you'd have to work real hard to make this kind of vulnerability there.
Aside from WP installs I definitely lock down PHP execution to the single entry point; it's possible to do it with WP too, there are just a few more entry points, alas.
I am sure you do, but what about average PHP programmer? There are thousands of tutorials on the web which teach the insecure way. And even in this thread, there are many people who mention "ease of deployment" as #1 PHP advantage -- do you think they'll lock down their installs?
So if starting a new project, you either have a choice of going with PHP and trying to re-educate many experienced PHP programmers that their best practices are insecure... or maybe choosing some other language, like Golang and Python, instead. Those languages are secure by default, there is no need to force people to go against the grain.
With the greatest of respect I don't care about the average programmer anymore. People can be incompetent in all sorts of languages. I care about my own work.
I've implicitly mentioned "ease of deployment" myself in this thread, I think, and probably in others, and I don't care for the assertion. I suggest you ask the others who have, what they mean.
"Secure by default" is a big claim. Secure against this particular problem you identify, sure. But let's not over-egg the pudding; there are still vulnerabilities in popular Python frameworks.
This is a) ten years old, b) fairly out of date, and c) much more passive-aggressive and opinionated than people sharing it seem to think it is.
I mean, in the "stances", just as an example -- "a language must be concise"?
Really? It must? I think this is inappropriately assertive. IMO the better JS I have seen has avoided some of the more unnecessary conciseness. And that is before we discuss the worst example of "conciseness" thinking in a generation: JSX.
PHP and its community is, if you want a different opinion, more mature, more pragmatic and entirely less screwed up than Node.js, which is, to borrow the terminology, a fractal of indiscipline.
PHP's developers and its wider community have gone about fixing problems while NPM just seems to create new ones.
(The author of that post is in fact a Python fan, which makes it even more chucklesome when looked at over a ten-year timescale. One of the two languages managed to bring developers along for that whole decade with a campaign of carefully planned major improvements and deprecations, without causing major schisms, and it wasn't Python.)
> [] can be used on any variable, not just strings and arrays. It returns null and issues no warning.
It warns, will likely become an error in a later version (these are being slowly increased in error level to give people time to migrate): https://3v4l.org/qQdSP
> The [] indexing operator can also be spelled {}.
Most of the things in that article that are still true don't actually come up on a day to day basis for professional coders with a good framework and a decent IDE (basically PhpStorm).
It's not just papering over cracks, though. (There's a bit of that, but they do try to avoid it)
It's a slow, deliberative process to properly fix the most widely deployed server-side web programming language. It's not going to be easy, and it is being done by fairly wise heads.
While I enjoyed that article many years ago, and even identified with those sentiments. I've kept an eye on PHP over the years. It's not that same language. Certainly PHP, like all languages are not perfect. But I gotta hand it to the team. The evolution has been awesome.
I stopped using PHP. The language itself is fine, but PHP doesn't include a package manager. People will shout "but composer!", That is not PHP. That is a third party tool. What Rust understands, what Go understands, what Ruby understands, is how important the package manager is to the language.
No one is an island, and "batteries included" only gets you so far. In my mind, PHP is in line with C, with the mindset of "figure it out yourself" in regards to packaging. That's not acceptable.
Everyone has standardized on Composer. It's a better package manager than NPM, doesn't have many of the security problems that plague NPM.
The PHP internals maintainers don't have the time to maintain a tool like Composer alongside the rest of the language. And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.
> doesn't have many of the security problems that plague NPM
Is that true? How so?
I'm a long-time PHP dev, but of the issues I can recall regarding NPM, including the recent controversy related to the invasion of Ukraine, I don't see how that sort of thing couldn't happen with Composer some day, and it might just be a matter of time; that it hasn't yet has more to do with the relative ecosystems of the two languages and the developers they attract than anything technical, in my opinion. But I'd love to be proven wrong.
With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536
Composer packages also don't tend to have the "culture" of having a million tiny packages for small functions like left-pad, so that helps a ton too. Mostly because PHP's stdlib is pretty great by default, so lots of things like this don't require 3rd-party libs.
Obviously Composer isn't bullet-proof, someone controlling a dependency of an important project can still cause harm by making a minor version release with malicious code, but it's easier to vet a smaller list of packages in the tree, especially if all you need to do is scan through their code on github.
Thanks for the response. I didn't know that NPM packages aren't just Git pulls as they are in Composer. That's surprising. I wonder why they decided against implementing it that way - it seems like just using Git or other package managers would save from having to deal with hosting, versioning, and so many other things inside the manager system itself.
Generally, NPM packages are transpiled/minified with webpack (or w/e newer tool) and published as minified bundles. That's why it's done that way. It avoids committing the webpack compiled dist to the repo.
With PHP, since there's no compile/minify step, there's no need for "build artifacts", so you can grab the code directly and run it as-is.
But obviously this has big supply-chain security downsides.
> And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.
CPAN is bundled with Perl, but CPAN can update itself to a newer version (try `cpan CPAN`). Similarly, NPM is bundled with node.js, but NPM can upgrade itself to a newer version (on Linux/Unix/macOS by running `npm install -g npm@latest`; unfortunately doesn't work on Windows for whatever reason.) Why couldn't Composer use the same model? Composer supports updating itself (when installed as a PHAR) via "composer self-update". So bundle the PHAR with PHP, and then when you run it, can check for a newer version and print a warning if there is a newer version available, and in response to that warning you can run "composer self-update".
It seems like you have an unexamined presumption that bundling a package manager with a language is a superior practice, and you "don't care" about any argument that might challenge that.
Is Ruby Gems a first party thing now? I remember, back in the day, being tangentially involved with creating a Ruby package manager before Gems had become the de facto standard.
Nitpick, but Go the language doesn't have package management. The 'go' tool -- an implementation detail of the most popular implementation -- has features for fetching packages, etc., but the language spec does not require these features or constrain how they work.
I think WordPress is pushing other projects forward as well. The tech stack over there doesn’t move nearly as fast, but the UX is still pretty good out of the box and with the enterprise clients I work with on a daily basis, they all still love WP.
Back to PHP proper for a minute, the language is fast. There are efforts being made to run PHP on Serverless infrastructure or with continuous process environments. New features are added to the language on a regular basis as evidenced by this post and others. The defacto package manager, Composer, is also world class.
It’s a good time to be a PHP dev!
As a final point, I’ll throw out some of my worries. I’ve been writing PHP since 2010~ as a high schooler fooling around.
The “Java-fication” of PHP is real. There is a push for more types and type related features. These aren’t bad in isolation, but as they move deeper into the core of the language, there is a risk of breaking legacy apps. Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. I’m not advocating keeping 100% compatibility forever, but recent versions have played more fast and loose with breaking changes. We’ve done a decent job of carrying the entire community onto new versions and that will be important for continued adoption.
Take a look at the open RFCs for more details. I think there is value for pulling good ideas from other languages, but we don’t need every idea from every language.
Here’s to another 20 years of PHP!