25 Years of PHP [video]
youtube.com
youtube.com
One thing I appreciated about the video was how one of the biggest complaints against PHP isn't quite accurate: Inconsistencies of needle/haystack parameter order in functions. (there is a consistency there, but I didn't know it)
And the fact that PHP was developed over time and in dramatically different eras of the internet that heavily influenced it's features. He admits where mistakes were made, but also where people misunderstood the source/reasoning behind some of the decisions in PHP. (though he seems to sidestep some of them completely)
Magic quotes, globals, register globals, etc... he has really good reasons for why and how these things came about. I found this talk fascinating, especially since I build a system that has morphed over time as well.
He never intended PHP to last longer than 6 months. He kept waiting for someone to make something better so he could shut it down... it just didn't happen. Also, he admits he's not a great programmer.
As a counter point doesn't every language "introduce problems" of some kind?
But a lot of the choices were short sighted, and a devotion to backwards compatibility has limited the ability to clean up.
PHP is now a super fast, relatively mature web programming language that carries a lot of its baggage.
He addresses your issues about "short sighted" choices and backwards compatibility.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
I was trying to suggest it as a helpful way to understand Rasmus' perspective and a very complex history of development that has real logic to the choices he made that so many people have been critical of over the years. And that I think if someone heard him out would realize they would likely have made the same choices he did if they were in the same situation.
I just felt there wasn't a need for me to quote the video, but I suppose that was a little lazy of me.
That said, the improvements in version 7 look impressive. I still prefer a language that's not quite as ugly though.
PHP hit an optimum equilibrium between usability, features, and price. This only changed when virtualization changed the hosting game. Arguably PHP is still very close in terms of usability - deployment is fundamentally trivial - it's just lagging elsewhere.
There were other things like Zope and Roxen/Pike around back then, but I never used them. Ah and OpenACS/AOLServer which was TCL from memory.
Some folks were also compiling C and gluing it together with a CGI module, and a lot of others in the Microsoft world were using Frontpage and its brethren. But, the Microsoft stack only ran on Windows servers, and Windows web servers had a reputation (deserved, imo) for kinda sucking.
PHP's killer feature was mod_php. It was dead simple to integrate into any shared hosting environment, and so pretty much every shared host did. mod_php magically knew how to spit out html when reading html, and execute php when encountering php tags, so that gave us the html-mixed-with-php pattern that was wonderful at the time but considered bad practice now.
But also scope has changed a lot. At the time, people were mostly looking for hit counters, contact forms, and "guestbook" forms. For all those things, PHP excelled, so it gobbled up the market fast.
My first website back in `96 also had some compiled C via cgi. No database. I've said this before but using compiled Go with the web brought back memories of those good old days.
I spent about 4 years doing classic ASP before .Net arrived and had a hand in building a lot of big sites some of which still exist (and still use ASP): Most corporate jobs seemed to use the Microsoft stack then (or Java), where PHP was the what you did on the side because it didn't require server licensing.
Also safe_mode and open_basedir, which promised shared hosting providers that their users wouldn't hack the server and each other
I was primarily a Perl programmer at the time, responsible for writing CGI apps that were slow and unreadable to anyone I worked with who didn't know Perl.
I think vbasic was around but that required IIS and was an unmitigated disaster in every way. I sadly had to work in that a lot too.
I never messed with coldfusion but it seemed to get the job done for people who did.
Once you could get Apache with mod_php set up, PHP felt like something you could use to actually get stuff done.
But if you think about it array_filter expects an array first and function second because the callback is optional and it compares to false if left out. OTOH with array_map there is only one function callback and there can be N number of arrays so the function needs to be the first and the arrays second.
It makes perfect sense to me but for a lot of people it may look like inconsistencies.
I mean that if it's array,function at line X this time, it will be next time - again, unless you are trying to intentionally break this rule through a coding acrobatics exercise.
Since it's now known (with relative confidence), it can be optimized.
If someone truly is doing wacky things then we are left exactly where we were beforehand, with a broken system. Most of the time, however, it'd be better
For those who are interested, this is around 24:25: https://youtu.be/wCZ5TJCBWMg?t=1465
Anyway, here is the original source [1], that this time was NOT in their video description.
[1] https://www.youtube.com/watch?v=iGOAQli7tGc
And this is the last time I commented about this channel [2]
Of course for every content producer more viewers is a good thing, but the platform should redirect all profits to the original authors.
I was so happy to see that Rasmus feels exactly the same way. In the video he states that PHP alpha was created as a way to make his life easier to build dynamic websites rather than coding in C CGI.
I started out coding C in CGI and then moved to PERL. When I saw the PHP mail() function I was hooked. It enabled me to send an email with one line of code vs the 30+ it took in C or PERL.
Rasmus states himself, that he expected someone else to create a better competitor to PHP, and in his mind he was only going to use it for another 6 months until that new awesome project was released.
I felt exactly the same way!
But they kept updating PHP just as I was starting to think about new tools. Then Laravel came along and they also improved core performance of PHP.
So, now, PHP and Laravel are an absolutely beautiful (and comfortable) tool to work with and the performance is awesome.
Additionally, Laravel and PHP updates keep flowing freely and I can see no end in site of innovation from the amazing people behind these projects.
"This is a tool. PHP is not important. What you do with it is important."
I have the a lot of respect for Rasmus and I love the PHP community as it was my first language. I love how PHP and the community around is so practical.
And I still think PHP is the easiest language to deploy of all the languages I have tried.
I found it interesting but didn't quite grasp the explanation. If mod_perl was too powerful and had access to too many of Apache's internals, why not just create a lighter version or make it configurable?
The perl people didn't want to? My recollection of mod_perl was that you really needed to have everything about the server configured around the perl system, and it was quite a pain to get configured and working properly. My sysadmin skills weren't all that great 20+ years ago, but I did get it eventually working, but anything you wrote would only be able to be run on another mod_perl system, which were relatively uncommon (compared to the shared perl/cgi setups).
PHP was really more powerful and easier to read for many common scenarios compared to perl in those early days.
And while there were some scenarios where mod_perl was indeed more powerful... my experience was 1) those scenarios were relatively rare and 2) the community of people who had that experience was small, and never grew much (even when perl usage was on an uptake).
"C++ is the main language of choice for backend services. There are 10s of millions of lines each of mobile and backend code."
The isolation isn’t perfect, but it’s good enough for good sys admins to manage.
File system permissions work, etc. It's much simpler than the cloud.
For a historical perspective, MS-DOS was a single user OS, while Unix was always multi-user. Windows NT / 2000 / XP was more like Unix since networking (LAN and Internet) became more important.
I still run my blog on shared hosting [1] and it works great. (Several of my posts have been on the HN front page and it always handles the load fine. Including one at the #1 or #2 spot.)
https://en.wikipedia.org/wiki/Shared_web_hosting_service
The Twitter pic here is a good analogy for blogs in the cloud:
https://christine.website/blog/the-cult-of-kubernetes-2019-0...
But mod_php runs in the Apache process instead, for better performance. What I'm not sure about is whether it changes the user somehow when handling the request or just runs everything as the Apache user. I believe it's the latter since I've seen various modules that claim to address the problem.
I think the system was called basedir restriction.
He did mention in the talk that mod_perl was infeasible for this use case because it gave the user too much control. One user could override the Apache base_dir and redirect another user's traffic to his pages!!!
He said that as a result, hosting providers in the 90's would charge 100x the price for mod_perl hosting on a dedicated bare metal box, vs mod_php which could be shared. Didn't know that.
So I guess the answer is that mod_php has to be careful and not expose too many Apache hooks to the user.
The PHP interpreter does seem to have some unique qualities that make it good for embedding, compared with Perl, Python, Ruby.
1) The web server ran with a common account (eg www-data), and only had read access to users files.
2) The web server could be configured to run each site in the context of the file owners.
The advantages of 1) were that your website didn't have write access to your files. The advantages of 2) were that other peoples websites didn't have read access to your files, but your own site could overwrite them.
I only felt "safe"(ish) on a dedicated server, using option 1).
Other isolation levels were needed, like an MPM that would run vhosts as their own user, or a vhost level chroot.
Alternatively, there was php-cgi via suexec, but it didn't have the persistent qualities of mod_php.
also open_basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir
Looks like this is the syntax:
fn($x) => $x * 3
$x => $x * 3
I would think that this:
$a=[ 'doubler' => $x => $x*2 ]
2: And how about just using some other char combination?
$x ~> $x * 2
Yes.
$a = [ $x => $x * 2 ];