Except PHP isn’t dead - in fact it’s probably going through a renaissance.
The language and tooling have improved a lot over the last few years - to the point where starting a new CRUD web project using Laravel is a good default choice unless you have very special requirements.
I presume it's (Lavarel) a good default choice for someone active in PHP. Like many people, PHP was my first programming language, and I migrated away from it long ago. What's relevant for me is:
* How many new developers are picking up PHP
* How many remain using it after say 10 years
* How many end up contributing to its tooling and ecosystem
If those numbers are good in absolute terms, then I agree with you.
I'd consider Perl to be a dying language, not PHP. I'd also expect an active language's tooling to improve over the years, so that probably doesn't stand out too much for me (there's brilliant people working in various languages, in PHP I consdier Nikita Popov as one of them).
The fact that there are new and exciting things happening has nothing to do with whether the language is becoming less popular/relevant/adopted. Almost any index or ranking for programming languages you can find, TIOBE, stackoverflow survey and even Google Trends show that interest in php has been declining and not coming back. That is just the reality, and nobody is going to care if some part of the language or ecosystem improves.
Is that because its relative share is declining or because the absolute number is declining? The former indicates they are capturing as much of the new growth in devs, the latter there is an approaching problem.
> This type of thing happens all the time. In the UK you can work as an independent contractor for years then one day HMRC will randomly decide to make a case that you're were actually an employee the whole time and should have been paying a significantly higher rate of tax.
I assume you're referring to the IR35 laws - which were brought in specifically to combat a form of tax avoidance by highly paid contractors on long-term projects, who functioned exactly like employees (by being a contractor instead of an employee you could save a whole bunch of tax in the UK).
Yes, IR35 is a complicated pain - but everyone and their dog in the UK tech scene knows that contracting is/was the way to pay less tax. So it makes sense that HMRC is attempting to close the loophole.
> Uber paid their taxes as they understood UK tax law.
They were specifically attempting to use a loophole to avoid paying VAT the standard way (by claiming they're a "Tour Operator"). They've already lost multiple cases around the world for doing similar bad-faith interpretations of laws - so I think in this case it's Uber doing the exploiting.
People use Stripe’s forms because they’re convenient. It’s not a requirement in any way. Stripe provides APIs to build everything in their provided forms so you can build the functionality into your own site easily.
You are apparently not working in eCommerce and don't seem to know how 99% of merchants work nowadays. Merchants don't integrate by calling the Stripe API. They use a platform and those integrations are built-in. The amount of merchants that are actually building their own integration to Stripe API is a very small %, and majority of them would be very large retailers that have the staff to create their own ecom platform and are PCI compliant. Small/medium retailers for the most part are not working that way.
Again, merchants don’t integrate by calling Stripe APIs directly out of convenience. It’s more convenient to use an out of the box solution. But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.
> But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.
From a technical perspective, no, nothing is stopping the merchant from asking you for a string of numbers and a month/year date, storing it, and believing that "technically" they can send it to the Stripe API to charge you.
That's when they will realise that, from a business perspective, there absolutely is something stopping them: that they literally cannot do any business whatsoever with your CC details directly, unless they are fully PCI compliant to the same level as an actual PSP.
I had a job waiting tables when I was a teenager when my co-worker got busted for writing down credit card numbers and info when she took the tables' cards to charge them. Apparently she had racked up over 100 thousand in fraud over time.
No, because React is dynamically generating the HTML on the fly.
If you pre-compile the HTML using something like Jekyll, so that the webserver is just serving HTML files without any dynamic/on-the-fly processing at request time, then it's considered static.
This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!
Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.
> It's not beautifully well thought-out the way Python is.
This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).
> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.
Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax.
It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And there's so much more nice things coming in languages that have been designed from the ground up to be nice to use.
I understand PHP's pragmatism, but can't find it pleasant to use TBH.
PS: we got arrow functions, but they stay limited to anonymous functions for instance...
Maybe PHP can add a "stricter" mode that gets rid of all the cruft? Enable it per-file, allow it to simmer for 10 years, remove legacy support in PHP 12.
This would really help in a lot of way IMHO. PHP has good aspects, getting rid of the weirder one, even if compatibility gets sacrificed, would be a boon for building new applications.
I’m in agreement with you that it came a very long way.
Now, most of those have been present in many other languages [0], often with less limitations.
And as usual the old ways haven’t all been deprecated either, so it stays weird. For instance typed properties were a chance to reset the clock on type handling, but no, declaring a type will force cast parameters to that type instead of throwing an error (i.e. passing 0 for a string argument will convert it silently)
[0] Constructor property promotion isn’t, but TBH I’m of mixed feelings about it. We get conciseness in exchange for weirdness as the properties aren’t declared outside of the constructor, where they would be otherwise. I wished it was done the other way round.
Yes, except it has to be set on the _caller_ side.
I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the strictness set. [0]
So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.
[0] Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system. And it still doesn’t work for native functions.
> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system
There was this RFC[0] but it seems to have fizzled.
> And it still doesn’t work for native functions.
The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array_map I don't think this happens all that much.
> So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.
That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?
> That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?
It is completely unelegant, but works decently in practice (fits the subject perfectly…). We’re extensively using phpstan, especially as it’s the best way to expose in array types.
Phpstan still has blind spots, including the ability to disable it on the caller side (in particular, as far as I know you can’t disable specific errors inline, so if you have to do it for one parameter for instance, it applies to all parameters), and the option to overwrite a variable type just for phpstan. Those comes from developer error, but that’s exactly what we want to protect the system from.
Actually checking at runtime that a value is of the right type is more secure.
Yes, the backward compatibility is a crux on the one hand, on the other hand it has made upgrading PHP versions a breeze. In the past 6 months I updated several code bases from PHP 7 / 8.0 to PHP 8.1 / 8.2, the PHP part was easy (just the deprecated dynamic properties in 8.2 caused a wall of text in our loggers), the framework was a bit more difficult. The most problematic were the exotic packages that the clients had installed ages ago and that are not properly maintained anymore, so I have to figure out a replacement for those code modules.
Constructor property promotion is fine, I think. I think it ties in well with the readonly property.
public function __construct(
public readonly Company $company,
)
{
}
There's just so much info & functionality + type safety crammed into there that wouldn't have been possible previously; it's really nice.
The one feature on PHP that I wish was more commonplace is the `use` keyword in function expressions as it is one of the few ways to limit what names are in scope at a given point in the code
IIRC Rust's `mod` declarations can behave similarly.
GP’s take was way too salty, but to be honest I understand where he comes from.
Yes, it’s a matter of personal preference, but I also never worked with people that thought PHP was beautiful. Not that we look down on it, but it’s probably the same feeling construction people have towards their white vans. We value the good parts, hate the jagged parts, and if tomorrow it made more sense to ride Miata for whatever crazy reason, we wouldn’t look back. But I’m not holding my breath to have any decent reason to get out of PHP at my current job, and I appreciate the reasons why.
> No more random scattering of SQL statements in HTML files!
And yet you will still find this, because the long-tail of bad PHP is near infinite.
> although ideally all code from the 5.3 era should be burned at the stake
I guarantee you that a decent amount of real PHP coding right now is maintaining legacy stuff, not the new fangled 8.
It is, of course, the same in the Java world - most of the day job is not using Java 17. It's just that Java 6 code forced onto Java 8 isn't as bad as PHP 4 code hacked into PHP 5 code still struggling along in PHP 9. (Especially because as a scripting language, it will more likely fail at runtime, not build-time).
Is PayPal work for small SaaS at all especially one with micropayments? I fear such business would generate more refunds than usually and PayPal is much worse when it's come to blocking your account and freezing your funds.
When did this happen? When I was in Munich a few years back there were poster ads for cigarettes everywhere. I remember them being not very subtle about their “smoking is cool” message.
Tobacco ads are generally banned on Radio, TV, Print and the Web with some exceptions. Outdoor advertising is still very much allowed, Germany is the only EU country that allows this.
Btw manufacturers (not the merchants though) are still allowed to hand out free cigarettes.
I think there is some rule that the cigarette ads need to be targeted to smokers and not to non-smokers. As in Marlboro can try to make ads to convince Gauloises smokers to buy Marlboro on their next purchase instead of their usual brand but wouldn’t be allowed to make ads for non smokers to get hooked. (As if it would work That way)
Ads for cigarettes have been banned in Europe for a long time, thats why there is zero tobacco in Formula 1. In Denmark its now illegal to show the tobacco in the store, it has to be hidden
True in the UK too. Cigarette adverts were banned forever ago. Then they stopped displaying them in the store. Now, if I'm not mistaken (I don't smoke), they don't even display branding on the packets - the packets have a very plain, uniform design with no flashy colours or logos.
