You know the script
(pardon the pun)
Angry comment shitfest coming in 3, 2, 1…
Version 8.0 of the PHP scripting language is scheduled for release on 26 November, which coincides with the US Thanksgiving holiday. PHP turned 25 earlier this year and its latest iteration brings a variety of improvements to those who enjoy the language, which certainly isn't everyone. Type "is PHP" into Google Search box, …
In my opinion, one of the reasons computer languages run in fads is that if they are easy to learn, then they both get picked up by hobbyists/existing-programmers as well as introductory computer programming classes. The majority of folks who's programming education is limited (the vast majority of programmers) is limited because they are Scientists & Engineers whose use of programming originally is "to get the job done" for their own fields.That, and the fact that a lot of those folks over time end up writing software for a living, leads to the problems mentioned in this article where over time the code base get polluted with a lot of bad code, and "real programmers" start denigrating the language.
And then someone invents the next flavor of the month language and the rush of lemmings starts anew towards the new blank slate.
> Type "is PHP" into Google Search box, in Incognito mode, and the first two auto-complete suggestions you'll see are "is PHP still used" and "is PHP dead."
To be fair, Google results for some reason seem to be biased towards constant negativity, no matter what your search term is (permanent private browsing here).
"Some of the very large PHP projects have not always had the best coding practices and then those projects have been kind of trapped in a stage where they can't really work their way out of that problem, because they have a huge community and a huge amount of inertia behind the existing code base."
Gosh, whatever popular blogging platform for pressing words onto the screen could you possibly be referring to...?
> Story added that he believes PHP has developed a bad reputation because, being easy to learn, it gets picked up by a lot of novice developers early in their careers. "So you get people who maybe don't have formal training or maybe don't know all the best practices and then they fall into the pit of success where PHP just does what they need to do," he said.
To be fair, the same could be said of many a language, including for instance Python which I'm not a big fan of, but it doesn't have the same reputation. One thing that did set PHP apart back in the day, though, is that it wasn't originally "designed" as such. It was more of a quick hack by a guy to make his life easier when writing CGI scripts, so there were some pretty big holes in the early implementations that were trivial to exploit (like much CGI at the time). I guess we were all still in the age of innocence back then.
It did me great service in the first decade of this century, but around 2012, when time came to set out the requirements for a new project, I just couldn't see myself inflicting PHP upon the team and I. My feeling was that it had become rather unwieldy. Not claiming to be right, just sharing why I moved away from it. Your experience may be different and if you're happy with it, so much the better.
It's also appallingly inconsistent about what a library function that does something is named.
That is because the library function names were originally tweaked to have different name lengths, because that is how they were bucketed. This is official, as declared by the creator of the language.
> Just out of curiosity, what language did you choose instead?
First of all, it's not a matter of language. Language is not that important, except in financial terms (developer pool) and to the extent that they are usually tied to particular ways of doing things.
What happened was that around that time by accident I ended up doing a stint at a startup. It was a radically different way of doing things and I learned a lot from it. I had never worked on a system with millions of daily users before. You very quickly realise that your corporate/academic/purist way of doing things is, to put it frankly, crap.
It turns out that those high volume sites tend to be super simple behind the scenes. It makes sense if you think about it, as every CPU cycle counts when you're dealing with high traffic.
So I took a page from their book. Ok, more like a few chapters.
The other thing that has changed, always within web-y sort of stuff, is that the frontend stack (HTML, CSS, JS, SVG, canvas, WebGL, …) has evolved a lot in the last ten years and is now quite complete and efficient so you can offload a lot of stuff to the client and it can, in turn, take advantage of the various APIs with are basically efficient abstractions of more or less commonly used operations.
So, a lot of backend stuff nowadays is static. Nothing more than text (HTML, CSS, JS, JSON) files, perhaps supplemented by an API (or a collection thereof). This has a series of advantages, e.g., in terms of separation of concerns (presentation vs data), modularity, reusability, overall flexibility, and, not least, economy.
So, if your presentation layer is static HTML + CSS and your data layer is either also static (e.g., JSON) or abstracted into an API, it doesn't really matter what you use to generate either the presentation layer or the data.
In practice, I take an opportunist approach and start by reusing whatever is available and optimising / refining later if warranted. A recent project consists of hand-written HTML + CSS (Stylus) and a mixture of Python for input data processing, PostgreSQL for a database, and a Node.js API, with Bash for instrumentation. Another project is static HTML + CSS + JS files generated with Hexo.js and JSON data generated with Bash + Awk. Yet another was static HTML with a Node.js backend with custom C plugins to do the data processing.
An important rule of thumb that I learned is, it shouldn't take more than half an hour to explain your architecture to a new employee / contractor. If you can't, your architecture is too complex (and almost certainly, unnecessarily so) and you better simplify it before you go any farther.
"so you can offload a lot of stuff to the client and […] So, a lot of backend stuff nowadays is static."
Ugh, so, reading between the lines, you're sadly one of those people that we all grumble about because teh modernz web is a ghastly mess of bloated client-side JavaScript, rather than most of the heavy lifting (and validation) being done on the server where it belongs? :-(
(JavaScript might be a useful thing, but it would still be nice if as much of the web as reasonably possible could still work without absolutely requiring it, not to mention that anything on the client is something that someone malicious with time on their hands can manipulate to feed malicious data back to the server…)
There is using and there is abusing.
Yes, there will be people writing crap code that happens to use JS. The problem is the crap code, not the tools (a bad craftsman, etc.) Would you trust the same person to write secure and reliable backend code, for instance?
If your site is essentially a marketing brochure, there is hardly any point in using JS, let alone requiring it. That's why I use NoScript.
OTOH if you are providing an application or an application frontend, there is hardly any justification to not use JS. Aside from providing a much more fluid user experience, it saves the extra bandwidth and time wasted on unnecessary data + content/data round trips, lets you offload some or all processing to the client, and preserve the user's privacy and confidentiality by either not needing to send data across the network at all (if the processing can be done locally, e.g., photo editing, barcode generation, …), or by using end to end encryption (where data is encrypted on the client before transmission, so the server never has access to the payload contents).
PS: My first web project was a CGI program in C, before PHP and all the rest even existed and around the time when the default Apache configuration gave you access to the whole server via /cgi-bin (because people were trusting like that back then ☺).
"To be fair, the same could be said of many a language, including for instance Python which I'm not a big fan of, but it doesn't have the same reputation. One thing that did set PHP apart back in the day, though, is that it wasn't originally "designed" as such. It was more of a quick hack by a guy to make his life easier when writing CGI scripts, so there were some pretty big holes in the early implementations that were trivial to exploit (like much CGI at the time). I guess we were all still in the age of innocence back then."
This is true of anything. Even video games. When they made TF2 free to play, I was still playing with some usual suspects, and then an ocean of newbies arrived, being comically clumsy/ignorant.
I even remember as a medic, killing a spy in hand to hand combat.
Back then, it was *never* suppose to happen.
"...don't have formal training..."
Formal training in PHP consists of re-re-referencing the API so that the next new thing doesn't break the old thing... that's it, formal training done! BTW, the training exercises for The International Obfuscated C Code Contest are now being hosted at https://www.php.net/manual/
BTW, if you look at the highlights for PHP v8, you might see some mimicking of another "V8" (node.js)
The problem with PHP is "best practice" is stuff to work around the craziness of the language, rather than ways to make your code as well-structured and high-performance as possible.
Python's mutable default arguments are so well known because they're a rare case of the language doing something unexpected, and so require a "best practice" rule. PHP is full of such cases.
"I expect there is work for code maintenance for PHP, but I assumed nobody in 2021 is going to start a new project with it."
It really depends on the scale. For example, I sometimes work on one-time projects for charities, which usually take the form of some basic web forms glued together. I often end up using PHP for the backend because it doesn't require additional effort to get it running. Nearly every server already supports PHP scripts in the backend. Had I chosen a framework that requires other things, I'd have had to ensure the server they're planning to use supports it, that it's been installed and configured correctly, etc. Since a lot of these nontechnical and small places use a shared hosting plan, it's much easier to say "put these files on your server via FTP in this directory, or give me the credentials and I'll do it for you" rather than "We're using a framework called Flask, so I'll need access to your server to verify that it supports it. Also, we will need your server software to redirect some URLs to the Flask engine so please remember that I did that in case the next person to volunteer for your web tasks doesn't figure that out". Also, while someone might not be starting a new large project from scratch given the CPU limitations of PHP, there are plenty of existing codebases written in it. When people want to add features to those, they'll probably end up writing their new features in PHP too.
in the last 2 years I have designed no fewer than 3 major projects that have a PHP back-end for a web interface, typically for a touch screen on an embedded system (not to mention the supporting web server, a 4th project in a way). I specifically chose PHP as the best solution for rapid development to customer deployment, for its maintainability, and for overall performance.
PHP is most certainly _NOT_ dead, nor has it been relegated to "maintenance only".
You're not wrong, but I suspect PHP is more likely to suffer that fate.
If you're running, say, a Flask of python, or a NodeJS instance, or a perl app on Plack, etc, then the webserver is just a layer adding HTTPS (and a few other bits).
If it's misconfigured, you get an error page - no source code leakage.
For code running in a processor in the web server's space, if you're on apache you can usually assume PHP will work, while for mod_perl (for example) you're more likely to need to install it yourself.
That assumption means you may forget to check.
PHP being an easy option for beginners to quickly hack something together means it's more likely to see beginner mistakes
"mainly because I was lazy and rails provided all the scaffolding I needed to get the job done."
I hate to nitpick and correct typos, but you misspelled "I saw that rails had much of the structure I needed, meaning I could save the time, cost, and frustration of developing a bespoke solution".
I come from a C background having moved on from hardware device drivers to embedded industrial systems and web backends. Always had a soft spot for PHP because there is so much carry over from C, it can be very powerful and quite nippy in the right hands. I have some fairly large projects written in PHP including an accounting application I wrote 15 years ago that's still going strong.
I've written a couple of online shops and customer support db apps and a db app document/security controller with it around the turn of the millennium. Not been near it since - I found I had to write a few functions to wrap it to prevent it doing PHP things but I found the ASP approach far easier to manage and maintain than Django or Flask even with bizarre PHP quirks. Its so much easier to interface the server with the client when most of the code is on the same file and screen.
I may pop back and see if the new version solves a couple of problems that worried me about the language 15 years ago as I have a particular fondness for ASP that even VB didnt put me off.
To be honest I still think you need a good reason to choose something other than PHP for server-side web and HTTP API stuff.
Python, Ruby, Scala even Go, all have web frameworks. PHP and any of the many modern frameworks is still hard to beat.
People download Drupal/Joomla/Wordpress, install a bunch of plugins for whatever business requirements, then blame PHP for the fact they can't get more than a couple of hundred rps... ignoring the fact that their CMS is probably making 1000+ database queries to render each page.
Or the other side are the PHP apps developed 8+ years ago by an opinionated dev who thought they were better than using a modern framework, completely sacrificing the project's modularity and maintainability in the process. Yes Laravel might not work exactly the way you want but seriously, for the sake of future developers/employees working on your project, just use a community-developed framework. Any framework will be better than your hand-crafted gubbins.
Oh also a shout out to the PHP docs. The most accessible language documentation I've ever used. Individual pages per function/class with version history and curated examples. Compare that to the nightmare single page wall-of-text with different URLs for each language versions that you often see.
> Yes Laravel might not work exactly the way you want but seriously, for the sake of future developers/employees working on your project, just use a community-developed framework. Any framework will be better than your hand-crafted gubbins.
Results may vary.
The theory of frameworks is a good one: you get to have a set of standardised, community-vetted libraries to do all the hard work - and they're designed to work within a "best practice" approach. And they help to get rid of (or at least minimise) the underlying weaknesses and problems with the underlying language and architecture.
After all, as one teacher was fond of saying, anything can be fixed with another layer of abstraction.
But. That extra layer of abstraction carries it's own costs.
First is the fact that you now have to learn how to use the framework. And while it may not be true for all frameworks. Laravel (and Symfony, from which it inherited a lot of features) have a lot of complex implicit features which aren't particularly well documented; if you're stuck on something, the odds are far better that you'll find the answer on stack overflow rather than on the official Laravel website.
E.g. Laravel has a templating system based around "views". And you can set up "composers" which will be automatically triggered if a given view is loaded, and which can then be used to prepopulate the template with useful data.
So you don't have to worry about manually setting things up in the controller, nor do you have to put any complex logic in the view.
But at the same time, the fact that it's implicitly triggered means that if you're not the person who developed that code (and/or it's been long enough for time and alcohol to kill off the memories), then you'll have to hunt around to find where the composer definition is, and what it actually sets.
Similarly, you can specify that a HTTP controller method takes a specific "request" class; this class will inherit from the base "request" class, but will then contain custom logic to validate the data sent to the server (and/or perform other secondary tasks, like pre-loading data).
Which, again is great. But if the validation fails, the request will be silently rejected without any exceptions or log messages - the action won't even reach your controller method!
One of the developers where I work - who's spent years working with Laravel - lost the best part of a day trying to figure out why his new code was failing, until eventually realising that some validation logic was unexpectedly being triggered deep within the many layers of the request object his method was trying to use.
And so on. All this heavily abstracted and complex logic is great if you have the time to learn it all, and make frequent enough use of it to not forget it. Though even then, you have to hope that there hasn't been some sort of paradigm shift between framework versions which invalidates the previous set of abstractions...
The second aspect is performance. A lot of stuff in Laravel - especially the Eloquent database system - is done via "magic" methods, where you request a class attribute or method which doesn't exist; Laravel then uses PHP's __magic() methods to figure out what it was you actually wanted and does lots of stuff behind the scenes to do the actual work.
As a result, it's not uncommon to see stack traces which are sixty or more layers deep, as the action you requested is fed into __call(), which then goes off and creates a new object, which then triggers it's own magic method, which then goes off and creates a new object, which then...
And then there's Eloquent. Which at heart, is a way to abstract your database logic into a set of classes. Again, this is great - you get a single, standard set of classes; not only can you have methods on these to perform actions, but you can define relationships between them.
But this approach really doesn't scale well, especially if you're working with complex legacy database schemas. Want to pull data for a couple of one "entity", with data coming from half a dozen tables? Ok. A few hundred? Fine. Creeping up into the thousands? Time to make a cup of tea and come back when it's done.
(never mind the amount of twisting you have to do if you're wanting to do any complex joins or filtering, or the state of the queries which are generated by Laravel. Or how nasty the Eloquent calls become when you start throwing together all the relationship mappings, especially if you're using closures and the like...)
To be fair, some of this is specific to Laravel's particular implementation, and there is stuff you can do (e.g. eager loading) to improve things like database query performance. But sometimes, it's a lot simpler, quicker and more maintainable to do things the old fashioned way.
Admittedly, I've no desire to return to the days of hand-crafting everything, since that carries it's own set of risks and issues. But I do think that while frameworks are great - and definite development time savers - when they work, they're also a nightmare at times!
I think one of the biggest problems for PHP is outdated documentation. As someone who's not a coder but needed to get something to work I found an example in php that did the trick, this happened several times and so when coming to build something bigger it started becoming my go to, especially as these are internal things never to see the light of a public network it was fine.
Down the line I need something public facing and oh god how many security holes are in these examples I'm reading through, like, fixed decades ago but still showing the old way in recently posted tutorials.
My film club needed a way to handle rsvp's since covid struck and we had to limit to 14 people, nothing I could find (in our budget of three beans) could handle rsvps with a cap and a waitlist so I was like, hey, that sounds like something I could probably bash out in an evening with a bit of copying from stackoverflow for the hard bits. Go out and look for "php user login system" and see how many examples have any SQL injection protection. Like, pdo with binded variables will leave a SQL injection dead in the water (as far as I've read) but barely any example uses them and only a few having a passing mention that the end user might want to look up about security - the end user who needs to google how to do a login page, they're not going to grasp the wider issue at hand here.
I'm sure I've made several other beginner errors (hence not linking it here as an example), especially with post or global variables (I've worked around get variables at least) and although I think I sanitise everything, I don't really know, and I guess I'm not the only person in this boat, just might be old enough to at least wonder about security rather than just be happy I got shit up and running.
But, as I have a day job (that seems to like to be an evening job fat too often), really digging in to the security isn't something I have time to do and, a little, the inclination, given the wording of a lot of the documentation I do find isn't very accessible to someone starting out, which is kinda counterproductive, given we're the ones who're going to make the biggest mistakes? Trying to teach someone security once they've got their bad habits well and truly ingrained seems a poor choice.
This is true and very typical of PHP pre-2008/2010 era. People scratching around forums, finding a function someone wrote in 2004 and re-using it. It's all a nightmare.
In the last 10 years or so there has been such a good choice of PHP frameworks that you shouldn't ever need be involved in the security/plumbing at all. Codeigniter and cakephp were probably the first popular ones, allowing any hideous complexities to be abstracted away behind single functions/classes.
Googled-copied-pasted snippets of code of *any* language with permission to read/write to file systems and databases while being exposed to the internet will always end in tears. It was the same with Perl in cgi-bin directories all over the web in the late 90s.
"I think one of the biggest problems for PHP is outdated documentation."
That's not the official documentation that is out of date. The PHP group have always been very good at keeping the official documentation up to date, and at putting up big red warnings about the deprecation of, say, the mysql functions well in advance (as well as telling you why you should really be using newer, better, more secure database functions instead), etc.
It is, as other posters have said, other people's own tutorials, possibly long abandoned, but with good search ranking, possibly cargo-cult copied from other earlier also outdated tutorials, and even books still being published that glibly spewed about the mysql functions after these were known not to be best practice, that were the problem. Thankfully the evolution from PHP 5.x to PHP 7 removed those, as well as various other crufty junk.
Heck, if you search the web for "formmail" (or "mail form"), that old insecure Perl script from "Matt's Script Archive" even now still comes up fairly highly in the search results!
Yes, clearly an opinion piece written over 8 years ago by a furry with a section on their website called "weird porn" is an opinion you can trust!
Any remotely complex project written in any programming language requires you to adhere to best practice unless you want an unmaintainable tangle of spaghetti code.
Eeek, I had never realised that that "PHP: a fractal of bad design" website had some other more, uhh, esoteric content on it!
But, on the other hand, their article about CSS is quite interesting reading (in real life, I got to roughly the stage they describe of trying to make multi-columnar pages with CSS floats (which was a little fiddly itself) before CSS then got way more complicated and, it not being the main part of my job, I sadly could no longer keep up with and properly absorb all teh shiney new stuf after that…).
Just because they have some, umm, unusual hobbies doesn't mean that some of the stuff they write might not be worth reading…
Best practices for many programming languages are very similar. There are differences when addressing each language's quirks and community preferences for naming conventions, etc. The main idea of best practice is produce readable and maintainable code efficiently that someone familiar with language can understand without getting a migraine.
The cloud providers are hyping "functions" as a completely server-less tech (just more power, money and control grabbing off course). This is, in actuality, CGI reinvented.. HAR!
Thinking about just writing CGI in C. All the higher level "web languages" are crap, bloating, dying or evil (or all 4 ;-) ).
No, it's because PHP is a fucking nightmare of astoundingly poor design decisions and, probably more frequently, design accidents because no one gave them sufficient thought to merit the label "decision".
The type system is a mess, with inconsistent ad hoc conversions and operators, and crap mechanisms for type safety in function calls. The interactions between static configuration, runtime configuration, and syntax such as the @-prefix for error-handling suppression are unpredictable. The library is a vast wasteland of incoherent rubbish. Features which might improve the situation a bit, such as exceptions, are awkwardly bolted on, don't interact properly with other features, and weren't refactored into the existing library and core language. The OO stuff, while it helps (when used sensibly), is also a bizarre mess; for example, instanceof is an operator1 and is_a is a function, and they do more or less the same thing, except is_a can trigger autoload and who knows what other horrible behavior lurks in there? And so on, and so on, and so on until the heat death of the universe.
PHP invented mistakes no one had ever conceived of before. I find it hard to think of anything PHP does correctly.
And, of course, traditionally PHP positively encouraged security holes, thanks to adopting string concatenation and interpolation as its default mechanisms for doing pretty much anything, including database operations.
1Side note: If I go to php.net and search for "instanceof", it says there are no hits. But it's mentioned in the documentation for is_a, for example. That's because the search box apparently only searches the functions, and not other language features; and it only searches the titles. Why? Because the PHP philosophy is "do it wrong".
Of course you can browse the documentation for it. The Operators page helpfully says this: "instanceof = instanceof". You don't need to know anything more! Do not question it!
If you compare with any tech PHP cost CERO.
Cero in compile the code before "production" How much money you save stuff in resources?
Cero in time to dev something. Do you need to install jdk, maven, npm, packages, 300 hundreds of line of code and config to say "Hello World".
Cero time in changes, hot changes in production.
Cero time in learn and spent to get good developers
Cero resources to mantain his performance
Cero time to create a good architecture.
All you need is love.... and be a good Engineer not be a good Marketer tender
I assume this is an attempt at a joke?
"Cero in compile the code before "production" How much money you save stuff in resources?": Because compiling any number of smallish projects uses so much precious CPU time? This isn't the 1970s. I can type "make" and wait five seconds.
"Cero in time to dev something. Do you need to install jdk, maven, npm, packages, 300 hundreds of line of code and config to say "Hello World".": I have to install PHP and, if I'm using PHP in the most typical way, a webserver configured to use it. Not much different.
"Cero time in changes, hot changes in production.": You're fired. Really. You don't install changes into production. You run it through tests and review first, then it's elevated to production.
"Cero time in learn and spent to get good developers": Ah. Free PHP devs? Sure thing. Send me ten of those; I'll find something for them to do if the work is free.
"Cero resources to mantain his performance": I don't know what this even means.
"Cero time to create a good architecture.": Trust me, whatever you're writing in, you need time to create a good architecture. It's one of the most important things to spend time on.
"One of the key things that people love about Python is being able to use named parameters and not have to worry about the position of the parameters as much and not have to wrap them in another structure like an array."
One of the key things that people have strong opinions about Python is the delimiting by whitespace/indentation. Were they at all tempted to lift that?
Note: subject line - whitespace
This post has been deleted by its author
Just tried to use PHP for a small web project and it most certainly isn't easy. Open syntax doesn't make for decent error checking tools, a weird mix of functional and oo styles, odd function names in the core libraries a huge mish-mash of frameworks in the ecosystem (frameworks are fast becoming a pet hate), and poor debugging support.
No, it's not easy, or good.