HN Theater @HNTheaterMonth

hey,

this reminds me of the speech Rasmus Lerdorf - the creator of PHP *) - delivered to the 25th birthday of the language ...

* https://youtu.be/wCZ5TJCBWMg

you don't have to watch the whole speech, but during the last 5 minutes he says:

"work on things that matter (to you)"

imho. don't fall for the "money-trap", life is what happens between the (un)planned progress of your career ... and happiness has no price-tag attached to it!!

just my 0.02€

*) yes, the silly little language, which powers around 50% of the web ;)

You should watch this video: https://youtu.be/wCZ5TJCBWMg

It's a talk by the creator of PHP about how PHP grew to what it is today. The entire thing is really interesting.

There is actually a reason for things like 'inconsistent' argument ordering. They're ordered based on the C API, rather than being consistent in user land ;).

⬐ cutler

I think the C roots are also why PHP arrays double as hash maps.

On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times.

https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les...

I think he thought it would be Perl:

"And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance.

“So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.”

the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s

⬐ pengaru

I was a sysadmin through this era, and we refused access to both mod_php or mod_perl on shared hosting accounts. Customers always received php-cgi.

Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance.

By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area.

At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show.

Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.

btw.

"25 years of php" - an interesting talk about the background/history from its creator Rasmus Lerdorf

* https://youtu.be/wCZ5TJCBWMg

with a god point during the last 5 mins.

"work on things that matter (to you)"

ps.: imho ... don't waste your time on "vim vs emacs"/"win vs linux"/"python vs php"/... style discussions ... just use both.

use the best of both worlds. in the end this doesn't really matter as long as you get your work done ;))

Rasmus Lerdorf look at the last 25 years of PHP: https://www.youtube.com/watch?v=wCZ5TJCBWM

Really interesting for anyone wondering what the thinking was behind function naming and other inconsistencies jump to: https://youtu.be/wCZ5TJCBWMg?t=987 and https://youtu.be/wCZ5TJCBWMg?t=1466

⬐ fireattack

You left out a "g" for the first link.

⬐ JAlexoid

If I look from outside - it looks like there was exactly 0 thinking involved in function naming.

⬐ _-david-_

That is the look on the inside as well.

if you have an hour to spare, this (https://www.youtube.com/watch?v=wCZ5TJCBWMg) is a great talk by Rasmus Lerdorf, the creator of PHP, on the design of the language, the reason it ended up the way it did, and the ways that it is evolving for the better.

Actually, you should research about the story why php was created... it was primarily envisioned as a templating language and the creator wanted people to use c/c++ for business logic etc, however people didn't do that because it was easier with php.

There is absolutely no reason why a website should be build with c, sry...

Edit: link to rasmus lerdorf on 25 years php: https://m.youtube.com/watch?v=wCZ5TJCBWMg

⬐ zapttt

php was never anything serious until it lived on top apache.

⬐ paedubucher

> There is absolutely no reason why a website should be build with c, sry...

Please tell this Felix von Leitner (fefe.de, blog.fefe.de), and post his reply in this forum.

His blog software is written in C. It's one of the most frequented blog in German speaking countries and running on a single machine (AFAIK).

Of course, not everybody has the expertise to build something like a blog in C.

⬐ la_fayette

I know this blog very well and fefe is definitely enought of a geek to do something like this...

This is howevwr not a good example you know that right?

I don't think that it is a question of expertise, more like choosing the right tool for the right problem.

There has been substantial gap closing in the past few years and I understand where a lot of the initial hate came from.

This fairly-recent hour long talk covering the 25 year history of PHP by its creator was very good, if you're into that sort of thing =)

https://www.youtube.com/watch?v=wCZ5TJCBWMg

As someone who works in web I have to deal with javascript also, and always enjoyed that too, until node and npm became standard tools. Now everytime I have a project that involves npm I end up wanting to tear my hair out eventually.. I have not had similar issues with Composer.

I think rasmus's presentation explained pretty clearly why PHP won. Mod_php was a game changer and mod_perl failed by making the wrong choices. Overall, PHP was faster, easier, cutting edge and full of features without becoming too expensive to run, thats why web hosts supported it, not the other way around. What's not to love, honestly, even today.

https://www.youtube.com/watch?v=wCZ5TJCBWMg

Specifically to that point, Rasmus talks here about the reason PHP succeeded where Perl failed https://youtu.be/wCZ5TJCBWMg?t=552

⬐ blindseer

This is tangential but this channel frustrates me to no end. They shamelessly rip other people's content, stripping their videos of author information, conference information etc, AND add their own title card so that it appears like they are the publishers of the video. Why is this acceptable!

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]

[2] https://news.ycombinator.com/item?id=20797683

⬐ villgax

The same goes for SSWolf or whatever on YouTube as well, just giving a banal commentary on the weeks top posts/gifs/videos on reddit without permission or attribution. I think content like that can come under the radar for repetitive clause.

⬐ anarchyrucks

This. It frustrates me to no end. I've read somewhere that they explicitly ask for permission to put videos on their channel but I still cannot get over how they edit the video and try to make it look as if it was their own.

⬐ softwarelimits

This is a very old problem on YT, there are many, many content thiefs. It would be very nice to have a good toolset available that helps with finding these videos, however it does not help if YT team does nothing.

Of course for every content producer more viewers is a good thing, but the platform should redirect all profits to the original authors.

⬐ jv22222

I've been coding for 30 years and I've always considered programming just a means to an end. It's the tool you use to create that vision you have.

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.

⬐ paulgrimes1

Great to see this. Well said Justin. Love Laravel and it’s ecosystem. Also: almost 20 years ago I played session guitar for you. Great days! Hope you’re well. PG

⬐ jv22222

Hey I remember you! Great to hear from you again. Awesome that you are into Laravel. Feel free to ping me on jv at vip dot ie let's chat and catch up :)

⬐ kalecserk

There is literally a slide titled: `What was we thinking` where Rasmus goes through the most controversial decisions he made while doing PHP. I recommend this talk for anyone, specially because most of us, if we are lucky, will have to deal with a 25 year system at some time during our career.

⬐ nodesocket

"Arguing about the color of the hammer used to build that thing is just moronic. And all these flames about technologies and stuff... We can't lose track of what we are doing here; why we are programming. We are programming to solve a problem." --Rasmus (video 1:07:09)

⬐ open-source-ux

If this talk is too long for you to watch, I can recommend this segment towards the end:

"This is a tool. PHP is not important. What you do with it is important."

https://youtu.be/wCZ5TJCBWMg?t=3879

⬐ buboard

Wish people would start treating their dev tools as tools rather than objects of worship. The web today feels less robust than those simple tools of the past.

⬐ Kenji

I don't know what's your problem. I built PHP pages 10-15 years ago and without a single modification of the code, they are still rock-solid today on a modern LAMP stack. I wish people would learn to use the tools at their disposal properly.

⬐ adventured

I vouched for your flagged-to-death comment, on the basis that you should edit your comment & remove the first sentence. Without that, what you said is fine. No need to project at the parent.

⬐ ecmascript

Really interesting talk and for the first time ever, I gotta say I really loved the youtube comments. On the first page (at least) there isn't a single negative comment.

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.

⬐ mihaifm

Does anyone have more background on the mod_php vs mod_perl problems he highlighted here: https://youtu.be/wCZ5TJCBWMg?t=599.

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?

⬐ mgkimsal

> 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).

⬐ cutler

The problem with mod_perl for hosting companies was that it was much harder to protect global variables from being visible from other accounts on the same machine. It also consumed a lot more memory than mod_php from what I remember so it never became a part of the shared hosting scene which enabled PHP to flourish. Mod_perl was also a lot more complicated than CGI Perl which is why Perl remained only a CGI option on cheap hosts. Some very big sites ran on mod_perl but they were running on dedicated hosts, not shared.

⬐ tpmx

Is Facebook still running on some kind of PHP variant?

⬐ kyriakos

Yes it uses hack

⬐ tpmx

I can't even...

⬐ botto

True, they use hacklang but it's no longer folowing the php spec https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html

⬐ tpmx

Does anyone know what language(s) they tend to use for more "backend" style services?

⬐ minxomat

Mostly Hack and C++ as far as I can tell from glancing at their recent ACM paper: https://dl.acm.org/citation.cfm?id=3338112

⬐ tpmx

Nice, a very fresh source (August 2019)!

"C++ is the main language of choice for backend services. There are 10s of millions of lines each of mobile and backend code."

⬐ qilo

The original untrimmed video of this talk by GrUSP (Italian PHP events organizer) can be found here: https://www.youtube.com/watch?v=iGOAQli7tGc

⬐ ptx

He mentions how mod_php allowed web hosts to support thousands of users on a single server, but doesn't that run all the different users' scripts under the same Unix user account, letting everyone mess with each other's stuff?

⬐ gbrunacci

Not really, you were able to run everything inside a virtual host under a specific user+group. That was key for cPanel which is what you would usually get when purchasing a shared hosting account in the 2000s until "the cloud" became a thing. https://cpanel.net

⬐ rob-olmos

For mod_php, they'd run as the same httpd user account and could mess with other user's stuff if they were set to be httpd writeable.

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.

⬐ antod

From hazy memory there were two ways of configuring apache/mod_php.

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).

⬐ ptx

This means that everyone can read each other's configuration files, though, and thus connect to each other's databases, doesn't it? (Edit: Ah, that's why you had a dedicated server.)

⬐ kalleboo

PHP had safe_mode which tried to solve the problem https://www.php.net/manual/en/features.safe-mode.php

also open_basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir

⬐ nkozyra

Mess with each other's stuff in what regard? Sites could be sandboxed but yes everything was running under some web server user account, and it was a single machine so you could ddos anyone.

⬐ LeonM

I think he meant thousands of users from a performance perspective.

⬐ encoderer

You know Docker? Basically you can do a lot of that with chroot.

⬐ chubot

A single server has many Unix accounts! That’s how all servers worked before the cloud and VMs and containers.

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...

⬐ ptx

I'm aware, but maybe I didn't phrase my question well. CGI scripts, including PHP when run in that mode, fork a new process as the appropriate user - as you say.

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.

⬐ chubot

Yeah that's true, I misunderstood.

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.

⬐ tpetry

Everything was/is run as the apache user. PHP tried to make it secure by restricting the folders a script was allowed to access but over the years so many ways to break had been found that a fastcgi process per user showed its the best solution.

I think the system was called basedir restriction.

⬐ epx

I don't like the language but the execution model is unbeatable. Not having to worry the whole server goes down if your code breaks or runs for too long, is nice. I'd like to know if there is some way to run JS code just like that.

⬐ ptx

There is. It's called CGI and works with any language and many web servers. It was around before PHP and still works fine if your program is small and starts quickly.

https://en.m.wikipedia.org/wiki/Common_Gateway_Interface

⬐ kyriakos

What today devs call serverless execution model

⬐ epx

Yeah, had forgotten these options (FastCGI, WSGI).

⬐ FreeHugs

I stumbled across him mentioning arrow functions comming to PHP.

Looks like this is the syntax:

    fn($x) => $x * 3

Strange that they went with fn() and not with the simpler approach established in Javascript:

    $x => $x * 3

Here is a link to see an arrow function in action:

https://3v4l.org/JpFJl

⬐ wvenable

Because the arrow already exists in PHP and is used for key => value mapping in arrays and foreach statements.

⬐ FreeHugs

1: But does the syntax really collide?

I would think that this:

    $a=[ 'doubler' => $x => $x*2 ]

clearly should create an array with an elemnt that is a function and has the key 'doubler'. Where is the problem?

2: And how about just using some other char combination?

    $x ~> $x * 2

Or something like that.

⬐ francislavoie

It's all covered here in the discussion section: https://wiki.php.net/rfc/arrow_functions_v2

⬐ simion314

Isn't readability more important then typing a few less characters? We spend more time reading the code so readability is more important IMO.

⬐ jorams

> But does the syntax really collide?

Yes.

    $a = [ $x => $x * 2 ];

Is this an array mapping the key $x to the value $x * 2, or is this an array mapping the key 0 to a function that doubles its input?

⬐ bogdanu

They chose this approach to avoid ambiquity/complexity in the parser and code readability since => is also used to declare arrays.

⬐ deepprocess

Cool video. Thanks for posting. He graduated 94 and starts the clock then. I was born in 94 and got into PHP as a hobby when I was like 16. It really helped me with programming. It was easy to learn. I never got into a career with it. I still like to mess around with PHP and other languages.

⬐ xellisx

Something I found interesting, was that he printed a whole code base and out it up on a wall to debug something when he was an intern.

⬐ tus88

HN on Python: it doesn't have typing, it shouldn't even be used to scrape a log file!

HN on PHP: it does the job, leave it alone! Look, even Facebook uses it for their entire web-site!

⬐ Vanderson

Anyone who has had to work on a single system for many years may be interested (even entertained) by this talk.

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.

⬐ lucb1e

> 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)

For those who are interested, this is around 24:25: https://youtu.be/wCZ5TJCBWMg?t=1465

⬐ nkozyra

A lot of these things came about because they allowed people to bypass harder aspects of programming for the web. This was great for ease of entry but introduced tons of problems.

⬐ simion314

I was not on the internet at that time, were there better alternatives?

⬐ pixelbath

The big alternatives were: Perl if you had the technical chops and a host who'd basically let you have root access to the hosting machine (C/C++ worked this way too through CGI), ColdFusion which isn't really an alternative, ASP using VBScript which was wordy, complicated, slow, and gave almost no help to the developer (Provider error '80004005': Unspecified error) when a bug appeared unless it was during object initialization.

Once you could get Apache with mod_php set up, PHP felt like something you could use to actually get stuff done.

⬐ edoceo

MS-ASP or CGI. 20 years ago PHP was like "amazing", compared to what else was around. Maybe ColdFusion

⬐ toyg

ColdFusion was terribly expensive, like all the other stuff like WebObjects or Netscape. The Microsoft stuff was expensive AND insecure. CGI (i.e. Perl) was cheap but annoying to learn, setup, and maintain. Java was sluggish and unusable in shared-host environments (i.e. expensive, again).

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.

⬐ antod

Yup, those were the two web "stacks" I had tried before PHP - around 1999 or so. At the time PHP did feel amazing compared to Classic ASP in VBScript (shudder), and I never really felt comfortable with Perl.

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.

⬐ nkozyra

Perl was the most comparable but CGI was limiting and I don't recall a lot of strong, simple frameworks. Also, it was Perl.

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.

⬐ cutler

Most Perl web development was done with Lincoln Stein's CGI.pm in the late 90s. HTML::Mason was Perl's answer to PHP but it relied on mod_perl which most hosting companies were not prepared to let you have on the cheap. You could do CGI.pm procedural style or OO style with $obj->method() calls similar to PHP. "MySQL and Perl for the Web" by Dubois was a pretty good web primer at the time based on CGI.pm. This and "Programming Perl" got me started after I became intrigued by regular expressions which led to a deep interest in Perl. It's easy to forget that Perl was VERY cool back in the early 2000s. Reading "Programming Perl" for me was like reading great literature. Larry Wall the linguist really comes through strongly in the book.

⬐ thaumaturgy

I was a maturing young programmer back then. The leading alternative was Perl, which was still pretty lively but had a lot of the same complaints at the time that it does now (readability). Perl's what I was primarily using; it took me a bit to adopt PHP, but once I did, I never looked back.

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.

⬐ cutler

It's often overlooked that many of the cheap hosting companies who provided the environment for PHP's phenomenal growth only offered PHP as a CGI. You often had to pay a lot more if you wanted mod_php because it was harder to secure and required more resources. PHP/CGI was the way to max out the number of users on a server even it was slower.

⬐ kalleboo

> 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

Also safe_mode and open_basedir, which promised shared hosting providers that their users wouldn't hack the server and each other

⬐ dwd

Remember Matt's Script Archive? That was all Perl and covered a lot of the hit counter, contact/guestbook and forum software pre-PHP.

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.

⬐ Vanderson

I think it's a little unfair to not refer to his responses to these allegations in the video.

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?

⬐ nkozyra

Again, I don't think this is his fault in this regard. I also think he's humble about his capabilities and I'm sure this long project matured his chops across the board.

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.

⬐ Vanderson

I'd really recommend you watch the video to understand how long term development of a hugely popular system isn't as easy as it may seem. Especially if the environment is as dynamic as the internet.

He addresses your issues about "short sighted" choices and backwards compatibility.

⬐ nkozyra

I had watched it and comments like yours are generally frowned upon here.

> 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."

⬐ Vanderson

Sorry, I forgot about that rule. I really wasn't being critical of you not watching it. (There is no tone in writing to convey that extra meaning.)

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.

⬐ ptx

The video was interesting and he comes across as a very reasonable and pragmatic guy who had good reasons for designing it the way he did. But those reasons and that design resulted in a not very excellent language - as the parent post (and Rasmus himself!) said. Convenient but problematic, intended to be replaced by something better.

That said, the improvements in version 7 look impressive. I still prefer a language that's not quite as ugly though.

⬐ Crazyontap

Sorry I haven't watched the video (don't have headphones) but I can understand why php changes the order or function params sometimes like array_filter wants the array first and callback second and array_map wants it in reverse.

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.

⬐ viraptor

It's not an either/or. Those signatures are inconsistent and there's a reason they were made that way. It could be done another way. (detecting the type of parameters or having a different name for the callback version)

⬐ kristopolous

Why not just let the type system figure it out in this instance?

⬐ tpetry

Because php has no function overloading by type system.

⬐ kristopolous

The type can trivially be checked inside the function. You don't need type system function overloading

⬐ totony

but this has runtime cost, where inconsistent order doesn't

⬐ kristopolous

Not necessarily. Unless someone is intentionally trying to be confusing, the parameter order will be consistent for a specific instantiation.

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

⬐ mktm

Great talk