Live data from Hacker News

A look at modern PHP

lwn.net

421–430 of 610 posts

Re: A look at modern PHP

#421

Earlier quoted context omitted.

My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected. I've been bitten by it and also stuff like 800=="8E2". I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I hav…

I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful. It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light…

Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects.

The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude.

The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.

Re: A look at modern PHP

#423
post #420

Earlier quoted context omitted.

> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.

I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop. 1. https://3v4l.org/9…

Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times.

It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.

Re: A look at modern PHP

#424

Earlier quoted context omitted.

My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected. I've been bitten by it and also stuff like 800=="8E2". I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I hav…

I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful. It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light…

As someone who's worked heavily in C++/Java and tends toward functional programming approaches I enjoy PHP. There are some features in the language you should avoid, variable-variables being one of the ones that makes logic very difficult to decipher - but C, C++ and Java all have those - and Javascript has the wonderful combination of substr & substring. The useful portions of PHP are extremely powerful, having access to magic functions, a much more advanced concept of a local symbol table and a surprisingly good approach to inheritance & composition all end up bringing down code maintenance when well applied to provide clearly intentioned logic.

Re: A look at modern PHP

#425
post #127
post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

I'd assume that Django and Ruby on Rails can't be that far off.

Not sure why you're being downvoted.

If we just look at [3] above, we see these: https://trends.builtwith.com/framework/Django-Language https://trends.builtwith.com/framework/Ruby-on-Rails

Django, at least on that site, seems to be quite far off. Rails, at least on that site, is ahead of PHP.

Re: A look at modern PHP

#426
post #164

Earlier quoted context omitted.

So I take it all the things in this article ( https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ ) are no longer relevant? For example "foo"==TRUE, "foo"==0 and TRUE !=0 are logically consistent now? Or json_encode no longer returns null for invalid input?

Some of it is still true, some of it isn't true anymore and some of it simply isn't very relevant. Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing. json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error(). Both are un…

> it's hard to fix mistakes made 25 years ago.

I like PHP, less and less since I started with it in the 90s. Largely because of the current stewardship and syntactical changes. Many languages move forward rapidly. A difference between PHP and, say, Python is that PHP seems to move more slowly to the same end. There are still trivially fixable problems that would qualify as breaking changes. Seems lazy. Instead, we have a bunch of hand wringing because those who make the releases are heavily involved with projects that move slowly out of fear...ostensibly because they have customers they don't want to antagonize. They might jump to another framework or language.

Re: A look at modern PHP

#427
I'm starting a new project in PHP now. I've used the language for a long time, I think starting with the 3.x days, and it's come a long way. There's a lot of good things about it.

But.

I recently joked in frustration that I missed the days when PHP was a cargo cult version of Perl rather than a cargo cult version of Java. It's a joke, it's not a fully fair criticism, but I can't help but feel there's some truth to it. PHP is a fast dynamic language literally designed for embedding in web pages, with a batteries included mindset that shoves all sorts of useful things into the language itself (yes, kind of haphazardly and occasionally in slipshod fashion). If I want to know what the path of the request is, for instance, I could just do:

    $url = parse_url($_SERVER['REQUEST_URI']);
    $path = urldecode($url['path']);
But that's not The Right Way anymore, is it? Instead, I should use a PSR-7 compliant request object, and do this:

    $request = Laminas\Diactoros\ServerRequestFactory::fromGlobals();
    $uri = $request->getUri();
    $path = $uri->getPath();
"Okay, Chipotle, but that's just one more line, stop whining." Sure, but it's three lines that instantiates a Request object that in turn instantiates Stream and Uri objects and importa two Traits and implements, I don't know, let's say four? four Interfaces, and--

"Come on, it's still fast." Yes! Sure But you know what's faster? Looking at the $_SERVER variable. I can't help but paraphrase a famous quote:

Some people, when confronted with a problem, think "I know, I'll use a design pattern." Now they have two problems.

I know. I know. Using factories and dependency injection containers and tying yourself into knots to avoid anything that remotely looks like a global makes things testable and composable and decoupled, but it is so freaking heavyweight compared to other dynamic languages. Python's Flask web framework has a global context object just called "g", which is essentially a singleton that lets you arbitrarily store properties on it, not just variables but database connections. OMG GLOBAL RUN AWAY AAAA no, you know what? It's fine. Yes, in some sense it's probably more dangerous because someone could come along and blow away your database connection by overwriting the "g.db" property, but maybe sometimes the simpler answer is "well, don't do that."

Look, I've used Symfony, and CakePHP, and Laravel 4. I think I even contributed a test to Laravel 4's testing framework way back when. They're great. And I'm not saying "let's all just throw out objects and all separations of concern and mix HTML and business logic like it's 1999, baby." But PHP is virtually a framework on its own, and at times it feels like many smart people have put a great deal of effort into building entirely different frameworks on top of it, paradigms that PHP wasn't intended to fit into.

So for my new project, I'm just... rolling it all from scratch. I don't have a composer.json file because I don't need PHP-FIG compatibility--although the four-line autoloader I have would technically load any PSR-4 compatible module if I wanted to. It's using the front controller pattern, it has regex-based routing, it has a simple template system with layouts, it has request and response objects, it uses type hinting. It's probably not super great, but it's... kind of refreshing to write this way.

I love PHP despite its warts, and it's great that it's learned so much from Enterprise JavaBeanServerNetSwingPattern land. But I admit I'm kinda hoping for it all to get a little more relaxed about, you know, still being a dynamic language.

Re: A look at modern PHP

#428
As someone who started my career in PHP in 2002 and switched to Rails in 2008, I can say I do not miss PHP. I still maintain my old apps only because of the high pay associated, not because it is joyful. PHP's version of "mature" does not match other modern langs, not even close imho.

Re: A look at modern PHP

#429
post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

A lot of the common complaints about PHP are merely echoing the wildly outdated and misinformed "PHP: A fractal of bad design" that has been circulating for the better part of the last decade.

Unfortunately people tend to uncritically repeat whatever it says without actually paying any mind to the facts that, 1) it's 8 years old, 2) it's flat out wrong about a lot of its claims, 3) it's evidently written by a guy who has no idea what PHP is even intended to be.

Re: A look at modern PHP

#430

This may sound hurtful but hear me out - One thing worth mentioning why someone would not want to use PHP in 2020 is that a PHP programmer is looked down upon by other programmers. And im saying this without hate or malice. I love PHP since I was a PHP dev from 5.2 - 7.0. I built PHP libraries and WordPress plugins that have helped many people. Ive since moved to Node because PHP jobs have dried up in my country. PHP…

I look down upon people who look down upon people for their technology choices and would never willingly work with such assholes. Your point is irrelevant because those are people I have no interest in working with. To look down upon others (rather than a language) indicates that one is a complete idiot, asshole, and someone I'd rather not meet. Better those people self select out of my life when they hear php because they would clearly be a detriment to me and to anyone who isn't a moron like them. Not to mention unprofessional, naive, and arrogant.
Post reply on HN