Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8: Before and After

stitcher.io

Post reply on HN
Print view View original

311–320 of 346 posts

Re: PHP 8: Before and After

#311

Post by jozzy-james »

acdha wrote: post #296
jrochkind1 wrote: post #272

Earlier quoted context omitted.

> this has an impact on performance And yet, I find that PHP apps tend to be quite performant, compared to say Java or Rails (I don't know about node, maybe not compared to node). But I'm not a PHP developer, this is just my impression. And the complaints you hear about PHP, I seldom hear performance. No?

It varies considerably. If you write the kind of simple PHP pages which gave it that reputation, it's almost always going to be limited by I/O. If you use a framework which encourages enterprise-style apps with hundreds of includes and object hierarchies which would make a J2EE developer weep, even the opcode cache won't be enough to get back to that spot. I don't follow it enough to see if this passing away niw but…

i did a simple test between PHP, Java, Elixir and Haskell for fun (with a full payload/page that represents my problem domain) - PHP was within +/-10ms of the others for the same payload/template process. Guess which one was the slowest?

Re: PHP 8: Before and After

#312

Post by wccrawford »

ptx wrote: post #305
wccrawford wrote: post #200

Earlier quoted context omitted.

I think a better analogy would be that the PHP carpenters have standard old tools that people have used forever, and they work just fine. Normal hammer with wooden handles, normal planes, etc etc. But there are modern carpenters that have hammers that are 100% metal and never break and actually improve your hammering power. The new electric hand planes work a lot faster, though you do have to be more careful because…

Your analogy makes is sound as if the problem with PHP is that it's old or lacking features, whereas the point of the original analogy is that it's poorly designed. (Python is older than PHP, so it's not a question of being modern or not.)

By today's standards, old tools are poorly designed. At least, most of them. The one's that have stood the test of time aren't the bad ones.

Those old tools still worked, just not as well as modern versions.

Re: PHP 8: Before and After

#313

Post by francislavoie »

viraptor wrote: post #5

I'm not up to date on php code, but can't the first example be done using reflection? For example a SubscriberBase class which: lists all of its "on*" methods, checks if there's only one parameter, gets its type via https://www.php.net/manual/en/reflectionparameter.gettype.ph... and registers the method to receive events of that type. From the docs it looks like it's possible in php7 and doesn't need explicit text ma…

Definitely possible, but that's a bit "magic". It's nicer not to have to rely on methods being named exactly a certain way.

There was a discussion on reddit about this exact same thing, shows that attributes lets you bind multiple events to the same listener more easily: https://www.reddit.com/r/PHP/comments/jgkp2r/php_8_before_an...

Re: PHP 8: Before and After

#314

Post by Supermancho »

deergomoo wrote: post #239
gregoriol wrote: post #132

A lot of those changes look like good things taken from other languages that have done it well (the null ?-> and ??, ...). But many things seem to be quite of a burden instead of a progress => why create a new match syntax when a switch is already well known for something similar? That will create confusion (thinking of all the for types of loops in JS!), plus it's still not an enum and cases will be missed. And the…

> And the worst being the attribute #[] syntax... why?! Hah. Since the initial RFC was agreed, I think there were three changes to the syntax because no-one could agree. At one point it was going to be `@@attribute`. #[] is similar to or the same as Rust, I believe. It also has the advantage of being backwards compatible; while rarely used, comments in PHP can start with # instead of //, so older versions of PHP will…

PHP laughably adds warts almost as fast as it removes them, then codifies the new ones as intentional. Hack was a good attempt, but I fear it's too late to fix the soup of features by forking/cloning. I sincerely believe another language will replace it (not python), if they havent already (javascript shudder).

I've used PHP professionally for over 20 years along with other languages. The decisioning of language design, at large, has been mired in "good enough and doesn't break backward compatibility" nonsense all over the spectrum. PHP was the poster child of thinking differently in the 90s. Make the languages BETTER by looking at others, not clutching your Perls /s. Arcane sigils are not the way forward, that's a known (eg Erlang, Haskell, Pony, Perl, etc), even with powerful features that put existing languages to shame.

Re: PHP 8: Before and After

#315

Post by francislavoie »

ptx wrote: post #98
jonwinstanley wrote: post #37

Earlier quoted context omitted.

PHP is a great fit for the web, always will be. There are “better” languages and solutions but they are usually more difficult to setup or not as easy to learn.

How is it a great fit for the web, compared to other languages? All its unique strengths (in this very narrow context) are being phased out: 1) It used to be loaded straight into the Apache process as a module, which made it very convenient to get started with but required terrible broken hacks to run multiple applications/users separated from each other in a secure way. But nowadays people are switching to PHP-FPM,…

> But nowadays people are switching to PHP-FPM, which is the same approach used by Python, Java and most other languages.

What? Not even close. You can update PHP code by just replacing the files, it's not compiled. PHP-FPM is just a layer that provides a fastcgi interface and manages processes that run PHP. It's super easy to run, super easy to proxy to with Caddy or Nginx or whatever else support fastcgi.

Java is compiled, and typically runs its own HTTP server. Python is not compiled, but usually it runs its own HTTP server, or a WSGI server which adds another layer.

> Every possible extension baked right into the language as a global function instead of using namespaces and a package manager like other languages.

Are you trying to say that global functions are a strength? Namespaces are a big improvement. Many modern PHP extensions provide namespaced classes now, it's mainly the older ones that don't.

Re: PHP 8: Before and After

#316

Post by francislavoie »

erik_seaberg wrote: post #303
TheHemric wrote: post #112

I don't really understand why in 2020 there's still this kind of blind hatred against this language. It often comes from horrible bad memories from previous versions or old frameworks. Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications. I've been working on a SaaS API…

"foo" == TRUE "foo" == 0 TRUE != 0 NULL == 0 NULL -1 You have to test the simplest expressions because you can't trust the language to do what you wrote.

That's why `===` is a thing. But FYI, "foo" == 0 is no longer true in PHP 8: https://3v4l.org/fQLXX RFC is here: https://wiki.php.net/rfc/string_to_number_comparison

Re: PHP 8: Before and After

#317

Post by francislavoie »

kstrauser wrote: post #310
SergeAx wrote: post #308

Earlier quoted context omitted.

These examples are not about strong typing, but about type juggling. Strong typing is this: declare(strict_types=1); use \Domain\SomeItem; use \Domain\SomeItemId; use \Domain\SomeItemSpec; abstract class SomeItemRepo { public function GetOneByID(SomeItemId $id): SomeItem; /* * Still hacky * * @param []SomeItemSpec $specs * * @return []SomeItem */ public function GetManyBySpecs(array $specs): array; }

That's an example of strong typing specific to PHP, then, and not used in the rest of computer science. What you're describing there is usually known as static typing, which Python also supports.

No, types are checked at runtime in PHP. You can also use static types with docblocks and use static analysis tools, and both play complement eachother.

Re: PHP 8: Before and After

#318

Post by francislavoie »

ai_ja_nai wrote: post #153

I don't understand as of 2020 the use case for PHP. It's verbose as Java without its speed. Seriously, can anybody help here? It made sense to use PHP EXACLTLY in the good bad old days because it was just leaner to bang out applications in PHP than with other languages. Nowadays, I feel that PHP cake has been largely eaten by Python and Ruby. Why using PHP with such a level of verbosity?

PHP is faster than both Python and Ruby. That's one reason. And its request-response, shared-nothing model makes it incredibly scalable. Huge community, one of the best package managers in existence, etc.

Re: PHP 8: Before and After

#319

Post by mgkimsal »

wccrawford wrote: post #200
codeulike wrote: post #141

Earlier quoted context omitted.

Reminds me of "PHP Hammer" I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Sti…

I think a better analogy would be that the PHP carpenters have standard old tools that people have used forever, and they work just fine. Normal hammer with wooden handles, normal planes, etc etc. But there are modern carpenters that have hammers that are 100% metal and never break and actually improve your hammering power. The new electric hand planes work a lot faster, though you do have to be more careful because…

> On the other hand, the modern carpenters sometimes go a littler overboard with their tools and have problems that old-school carpenters don't have, especially with their tools randomly stopping working in the middle of a job. It might not be often, but it happens.

Great extra point. I'm often surprised at how much random breakage other people just accept as normal in "modern" webdev (meaning, for better or worse, you're involving javascript somewhere in the process). Put another way, I'm frustrated by how much I'm expected to just 'deal with' because a seeming large number of other people don't see a problem with it (or don't see enough of a problem with it).

Re: PHP 8: Before and After

#320

Post by lmm »

oblio wrote: post #88
lmm wrote: post #79

Earlier quoted context omitted.

Spring Boot code is probably going to be less maintainable than PHP though. Added a new dependency? Congratulations, now your application behaves completely differently.

How so? That sounds weird.

It scans the classpath and silently instantiates whatever it finds. E.g. you're depending on the mongodb client drivers? Congratulations, your spring context suddenly contains connections to mongodb servers. Upgrade one of your dependencies and the new version has a dependency on tomcat? Congratulations, your spring boot application silently starts running a webserver.
Post reply on HN