Has kept me in work for at least 20 of the 25 :-)
On 8th June 1995 programmer Rasmus Lerdorf announced the birth of "Personal Home Page Tools (PHP Tools)". The PHP system evolved into one that now drives nearly 80 per cent of websites using server-side programming, according to figures from w3techs. Well-known sites running PHP include every Wordpress site (WordPress claims …
Same here - I was struggling trying to get something working in (Mod-)Perl back in 2000 for the company I worked for at the time. Then my company sent me to the Apache conference in London later that year. At first I went to some Perl and Mod-Perl sessions. Both had low attendance and had people complaining about things that just didn't work - it was all pretty negative. Then I went to a PHP session to find it packed and full of positivity. Upon returning home I ditched (Mod-)Perl, rewrote everything in PHP and it worked! Haven't looked back since!
Yes, there are plenty of ways of doing it wrong in PHP (the way WordPress has been coded being one of them in my opinion - awaits the downvotes!) but doing it right and doing it efficiently is also extremely possible in PHP as well.
(...awaits the downvotes!)
Not from me, and this is a perfect example of a topic I broached in another article. Too many engineers worry about elegance in their solutions. Real Life isn't about "elegance", it is about getting things done, and sometimes the universe shows you that "elegance" is either non-functional or the hard way, simply appeasing your human sense of 'style' rather than creating a straight line to the solution.
Your story perfectly demonstrates this, as Perl most likely is seen as the 'better' alternative yet PHP was the functional, pragmatic preference.
That would be the clients who did not realise that EITHER they have wasted their money on a product with no future OR it is not finished on delivery.
Decent products last long enough to see a version 2, which will cost the client a pretty penny if they have to pay for a rewrite of version 1 before they can start.
Ignoring the costs of future maintenance is like planning to fail. You wonder why people bother.
Mmm, that does somewhat depend on one's perception of 'elegance'. Arguably for something to be truly 'elegant' it must be 'functional', in fact functionality and efficiency should be the foundations of elegant code - it does what it is supposed to do, no more and no less, does it efficiently and in a way that is pleasing to read, i.e. maintainable!
> Too many engineers worry about elegance in their solutions. Real Life isn't about "elegance", it is about getting things done
And that's how we end up with monstrous lumps of unmaintainable spaghetti code.
To be fair, there normally has to be some compromise between elegance, maintainability, performance, scalability and development time.
But in general, an "elegant" solution is more likely to be maintainable, performant and scalable.
I'm sure all developers have got horror tales of walking into a new project and finding that the last person "just got things done" in a way which left an unspeakable mess for the next person to clean up.
I know I've walked into that a a few times :)
> Perl most likely is seen as the 'better' alternative
There isn't really that much between Perl and PHP at the most basic level - they're both procedural, they both use variable prefixes and they're both little more than shims over standard shell and C library functions (e.g. fopen, echo).
Then too, Perl helps to highlight how "elegant" solutions can actually be a nightmare. Because in traditional use cases, it leans heavily on regexes, and these can be combined with implicit variables.
E.g. (and with the caveat that I haven't written Perl for a few years, so the syntax may not be 100% correct!)
foreach (<>) /(.+)(.+)/ && print $2;
From one perspective, that's a beautifully elegant solution, as it's hooking into PHP's implicit variables and involving a bare minimum of code
But from another perspective, that's just a bunch of random characters tapped out by an infinite number of monkeys, and which some poor sod is going to have to untangle a few years down the line.
And sadly, "just get it done" often tends towards stuff like the above.
"PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals".
- Jon Ribbens
"Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term".
- Alan Kay
"the way WordPress has been coded"
To me its also the way companies use WordPress, its has a large template and plugin community but are a source of pain (But its the same for all frameworks, I used to use a CMS called e107 back in the day which had very similar security issues.)
It's also a function of how Wordpress maintains compatibility. You should have a look at a well-used Wordpress site's database, one that uses a lot of plugins. Wordpress, if you use it as a blogging platform, is pretty good. But to keep compatibility, the database is used as a really inefficient key-value store, filled with gobs of serialized objects and the like.
Also, Wordpress (and Drupal) work the way they do because they needed to work around PHP's limitations before it had decent OOP mechanics. So you would end up writing Wordpress (or Drupal) code in a PHP-flavored syntax. Wordpress developers must bow to The Loop, for The Loop sees all and The Loop knows all.
PHP is pretty expressive. If you like Java, you can use the Zend Framework (or whatever they call it now) and feel right at home. If you like node, you can mess with Swoole. If you like to get your hands dirty, you can use Phalcon and write your own C extensions using their Zephir language. It's pretty impressive how widely varied PHP has become. Which is partly why it's so hated, as you never know what weird mutation of PHP you have to work with.
IIS for Micros~1 servers implemented a similar-to-PHP server-side vs client-side syntax that would allow you to (essentially) use server-side code to conditionally send web code, which I believe is PHP's strongest (and most basic) feature.
This kind of straightforward design enables SO much flexibility in what you can do with it, but yeah, you DO need to make your code formatting sensible, or else you'll misread your own curly braces and indents.
[I stick with something resembling Allman style and attempt to make PHP code as readable and maintainable as possible from the beginning, mostly so _I_ can read and maintain it]
Regularly coming fourth as the most popular language in the Redmonk rankings, PHP has rarely got a mention in the analysis.
Probably because most people using it for their WordPress, et al. websites don't realise it's there. There rarely go beyond choosing a theme and disabling comments: job done really for many people.
PHP really is an awful language. That said, it was probably the right tool at the right time. Initial decisions which were to later cause so many problems were instrumental in this: it ignored the CGI and was quickly available as an Apache module that just streamed to the browser; it quickly got drivers for databases like MySQL and was available for Windows, which made it accessible to new generation of people who learned programming by making their homepages. Being close to C and streaming made it comparatively fast, which made it suitable for websites that were growing quicky and the more websites there were, the more popular the web became. So, kudos to Rasmus and the others who made it work!
> PHP really is an awful language.
I like it :-)
I like Perl too so maybe I'm just weird.
I've tried Java and tomcat and TBH, PHP kicks its butt.
I keep trying to use other stuff but find myself falling back to PHP.
Same with Go and Rust and all those other new languages, I keep falling back to C or C++.
I've tried Java and tomcat and TBH, PHP kicks its butt.
Not that I like Java but that's not a fair comparison: Tomcat is a framework for turning Java applications into websites with everything that implies: you get scalabilty but you also get verbosity. Certainly won't get you up and running very quickly.
But what else can you use PHP for? Of course, it's not strictly limited to being embedded in the web server's process, but it's what it's most suited for, which is why it runs WordPress and not Spotify.
But what else can you use PHP for?
I have used it for semi-automated graph generation (drawing primitives in GD). A version of this ran on an intranet site for a few years, but its main use was from the command line.
Most of the logic was folding, spindling and mutilating text input (file names and then their ASCII contents) into numbers, though, which is a strong fit for PHP.
I write all sorts of programs in PHP, run from the command line.
As a language, it has lots of issues (eg inconsistency of parameter order, or auto type conversion which could trip you up) but the sheer volume of built-in functions means there's almost always already a quick way of doing something. Or a solution on the web.
I used to use Perl for such things but PHP took me over...
I think this excerpt from Rasmus himself pretty much encapsulates how PHP was designed:
Well, there were other factors in play there. htmlspecialchars was a very early function. Back when PHP had less than 100 functions and the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths names were picked specifically to make them fit into a specific length bucket. This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names.
> PHP really is an awful language.
I often think of it as Perl's stupid cousin, but it does a job and it does it very well and despite the inelegance of a lot of it, the inconsistencies, the way OO is very much stuck on with gaffa tape, for the jobs I use it for (which is most of the jobs I do) I've never felt the need to look for an alternative. It's a pragmatic solution to creating stuff that works.
Converting the world from PHP 5.0 to PHP 7 would save 15B Kilowatt hours annually and 7.5B less carbon dioxide emissions he said
15B kWh ??
7.5B CO2 ??
So, we're generating random prefixes and use CO2 as a new unit (El Reg, please take note). That will save the world, clearly, when we all use PHP 7 with the NewPrefix extension.
Assuming Billion for 109, then we have Giga-kilo, which is a no-no. That'll be Tera then. So, 15 TWh saved. That is just over 0.05 % saved in electric power with respect to 2017 numbers of world electric energy consumption. At least it is something. Does it have impact with respect to annual growth? You decide.
And then, saving 7.5 billion CO2... molecules? Tons (metric, short, long or volume)? Please elaborate. I'm actually interested in the answer. Maybe we can redefine the meaning such that its impact will be negligible, regardless the number. That'll save the climate a lot of problems.
Thanks, I appreciate your correction very much, so do not get me wrong here.
However, to be pedantic, sorry,... it is "kg" (kilogram) and not "KG" (Kelvin Gauss??). Also, it is kiloWatt hour (officially "kW·h" or "kW h", but commonly accepted as "kWh"). Case is important. The difference between 'm' and 'M' is a factor 109 and between 'p' and 'P' is a factor 1027; 's' is seconds and 'S' is Siemens (just to name a few).
I read the numbers in the story and I think of my students mixing it all up and creating lots of confusion. Just like they mix up units and the phenomenon they want to describe (like referring to electric resistance by saying "the Ohm of X is..." instead of "the resistance of X is...", well, I guess "the meter to home is..."... flexible in length).
I suggest that, when you quote, then use the full name (billion) or at least put a [sic] in the correct place to emphasize the error. Otherwise, errors will propagate and more confusion will be certain.
There's alot of hate out there for PHP but for the job of bringing up a website or webservice I would still choose it. In fact I often use it in the terminal for general text-wrangling, connecting to web services and basic DB processing. Granted there was plenty of terrible copy-pasted code out there in the 00s. And people would always be quick blame PHP for the dreadful performance of their Drupal/Joomla/whatever site, ignoring the 2k DB queries they made it do on every page load with the hundreds of plugins. But with such a wide choice of very high quality frameworks being available over the last 15 years I'd say those days of shoddy code are long in the past. IMO a huge amount of credit for PHP's wide adoption must go to the sensible layout of the official documentation on php.net - accessible, clear, easy to follow.
I went from mangled combinations of Perl and SSI to PHP in about 2004ish and I'd say even now there's no reason to completely rule PHP out of the running for new webapp-style projects.
Granted there was plenty of terrible copy-pasted code out there..
Terrible copy & pasted code exists in all languages - mostly driven by Q&A websites that just post a line or two of code without bothering with error or security checking. e.g. How many code examples out there just disable SSL certificate checking and then get blindly copied?
I want to say most of the hate is from the large amount of crappy code out there, and I think a lot of the crappy code exists because PHP was too easy to learn. PHP was almost like the BASIC of web apps. It was the first language that a lot of people learned and they flooded stackoverfow with their horrible code which propagated it.
Well written PHP code honestly isn't bad at all!
Although IMHO, the language itself got "dirtier" when they first started to try shoehorning OOP into a language that from the beginning wasn't designed for OOP.
I'd written some large apps ( a huge CMS _ Web shop) in VB ASP (before ,NET) and when I redid it for myself in PHP I found some really really weird behaviours that require some defensive programming to get round - this was 15 or so years ago so I cant quite remember the exact details but it was a tad annoying.
I do wish someone had made an ASP with an already tried and trusted language rather than make the same mistakes everyone seems to make in re-inventing the wheel.
I don't know PHP and from what I've heard, the language kind of sucks, but, at this point, I think I would take it over the completely insane microservice-based BS that is being forced down my throat. All client-side SPA web apps do is make things unnecessarily more complicated. I really don't think they result in a better user experience at all. Server-side is the way to go IMHO. That coupled with a few AJAX enabled UI controls here and there. I #$%^ing hate the new and allegedly improved way of creating web apps. It's an epic fail if you ask me.
I hear you. "Not very exciting and not much to it" sounds like a dream come true these days. Every time I have to deal with some frothing-at-the-mouth evangelist about the latest pattern x, language y or working method z I die a little inside. It's just another thing to have to spend time learning to keep one's head above water without any meaningful progress. I have no problem with learning new things, but when it's just a never-ending constant stream of BS that never goes anywhere it starts to grate.
I must be getting old.
First there was node.js, and the front-end developers rejoiced.
Then came npm, and the back-end developers sang songs of joy.
Then came the dark winter of left-pad, and all developers gnashed their teeth and rent their garments.
Then came yarn, and bower, and many other gifts, and the developers all battled on the fields of How-To.
Then the god of node.js saw that his children were saddened.
So the god made deno.js to bring his children home.
And the front-end developers rejoiced.
So the god made oden.js to help his children fight the robot uprising.
Absolutely. One thing which hasn't changed is the fact that HTTP is a stateless protocol. There's no harm in actually reloading a page, or having a separate (server side rendered) page for a given request/response cycle. The JS AJAX based approach basterdises that even further.
Well, I can think of languages which are far worse.
As many have pointed out, it is easy to write duggy and insecure code in PHP, but if you have a good understanding of it, you can write some robust web apps, especially if you build them on top of great frameworks like Laravel. You can easily write buggy code in Python, but do great things with it too.
I have no intention of stopping coding in PHP, just because it isn't the most fashionable language right now.
Much less useful though. My first dynamic website work in 2000 or so was CGI using a third party Delphi library called CGIExpert. Once I got my head aroun the statelessness and the request/response side it was a doddle to create page templates in any editor and populate them from a back end database. I didn't have to learn a new language, only to be unable to use it anywhere else (i.e. desktop applications)
I have used PHP for well over 15 years at work. The speed at which an idea sales has to migrate/extract data for a customer can be realised quickly into a working solution on Linux with a backend MySQL database is very powerful. It has it flaws but making changes then running the code without having to wait for a compile saves a lot of time. The other benefit I also see is that there are so many folks using it that someone else out there usually has a solution to a tricky part that you need to code.
"The speed at which an idea sales has to migrate/extract data for a customer can be realised quickly into a working solution on Linux with a backend MySQL database is very powerful".
Anyone who could compose that English sentence probably isn't too devoted to elegance, simplicity or maintainability.
It is possible to understand, but only with some sacrifice of time and effort. And the lurking uncertainty remains.
25 years ago, PHP was born. So was Allaire Cold Fusion. Then Macromedia ColdFusion. Then Adobe ColdFusion.
Of course, 25 years ago, most of us were still on dial-up and websites were simple and looked like this:
Personal Home Page using the extension phtml for web documents. Used a database called msql not mysql originally, I believe from new Zealand. Got originally because someone wanted to know how often their pages were viewed. Think i used with the ncsa web server, which is what "A Patchy" server was developed from. Back in the '90s. Continued to use when it became php because it was very easy to do simple things for simple dynamic web pages, embed the code in the html. Made modifying early html very simple, didn't have to abandon the first draft completely. Gradual improvements, added library's, extremely flexible to add features. Haven't used since version 4, 5 was just coming out. Don't do websites anymore. Used a text editor at the time.