A look at modern PHP • Hacker News Board

Re: A look at modern PHP

#391

Post by ragnese » Tue, May 05, 2020, 4:53 PM UTC

stephenr wrote: post #286

ragnese wrote: post #269

Earlier quoted context omitted.

Yeah, but if you're worried about bugs and security holes, I'm not sure PHP can possibly help more than it hurts. E.g., type juggling: https://www.netsparker.com/blog/web-security/php-type-juggli...

There are very few places where PHP cannot do strict comparisons. The first example in that article even highlights that `in_array` has a `$strict` parameter. I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.

Yeah, you're probably right about that.

Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.

On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.

Re: A look at modern PHP

#392

Post by slim » Tue, May 05, 2020, 4:54 PM UTC

nicoburns wrote: post #381

rgbrenner wrote: post #334

Earlier quoted context omitted.

1. Off the top of my head: SSR of JS apps, performance, better security track record. It also fits in the modern architecture better: you can certainly write a rest API in PHP, but that's not typically what you would use PHP for... and if you're going to write a react, vue, etc app, you're likely writing an api also. 2. This is not my attitude at all. I've been programming since the 90s.. In the past I've maintained…

> you can certainly write a rest API in PHP, but that's not typically what you would use PHP for Definitely not true in my experience. lot's of people are writing REST apis in PHP. > NodeJS is 11 years old... it's not a shiny new thing anymore. I write Node stuff for work at $dayjob, and lot's of stuff is great. But it still has nothing that's close to competing with Rails/Django/Laravel in terms of completeness.

He's right. PHP is a templating engine. So if you're not going to render pages server side, it's not the main use case for php. I'm a php developer and that useless lonely <?php tag at the beginning of my json service files bothers me

Re: A look at modern PHP

#393

Post by ragnese » Tue, May 05, 2020, 4:55 PM UTC

cletus wrote: post #353

ragnese wrote: post #268

Earlier quoted context omitted.

I think what the comment really means by "request scoped" is that the PHP process is totally torn down after each request. In Java you can mutate global state as its running. You can leak memory until you OOM.

This. One unfortunate side effect is PHP's choice to use the word "global" for what isn't really global but request scope. The "global variables are bad" folks look down on the PHP global scope just because of the name. Tearing down the entire request after processing is (IMHO) a remarkable effective approach.

I don't know. I think that global variables, even in PHP, are still poor software engineering. It still, very much, makes the code harder to reason about and debug. In fact, my understanding of the anti-global-vars rhetoric is that it's very much about understanding and debugging.

Re: A look at modern PHP

#394

Post by haberman » Tue, May 05, 2020, 4:55 PM UTC

alphadevx wrote: post #201

watermelon0 wrote: post #178

Earlier quoted context omitted.

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

Where to begin indeed! > - No proper connection pooling with circuit breakers. PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design. > - No proper multithreading (that works in web environment) or parallelism in gener…

> Yes programming in C is hard.

I'm not anti-PHP, so I'm not supporting the grandparent post in general. But as someone who is working on a PHP extension right now, I agree that PHP's C API is under-documented.

The best semi-official documentation I have found is http://www.phpinternalsbook.com/, but it is incomplete. Some important chapters are just blank, eg http://www.phpinternalsbook.com/php7/internal_types/zvals/me.... A lot of questions I can only answer by grepping the source code of the extensions in the PHP distribution itself.

I don't think this is just a case of "programming in C is hard." Some C APIs are amazingly well-documented, especially Lua. If you open up Lua's reference manual (https://www.lua.org/manual/5.3/manual.html#4), it explains just about everything you need to know to write good C extensions. Every public function, macro, and constant is documented. Python's C API is pretty well-documented too.

Re: A look at modern PHP

#395

Post by nucleardog » Tue, May 05, 2020, 4:56 PM UTC

tim_phpdev wrote: post #294

koheripbal wrote: post #265

Earlier quoted context omitted.

Coming from Java, the one pet peeve I have is the automatic type conversion. I just find that I never really know what my variables are _really_ holding. It's one of those foundational issues that I just can't get over. ...but it's my personal problem - I don't hate PHP.

Work as a PHP dev, in a PHP/JS shop. In all new work we require static typing on method parameters and defined return types. Of course, if your type is 'array' it could be an array of anything but we also try to avoid that and use collection classes. It honestly feels a lot like Java now, without the compile step.

We do similar (strict_types, declare parameter and return types, etc), but don't go as far as the Java-style collection classes except where absolutely necessary.

As a mostly-acceptable alternative, we just type hint as array and document the actual containing types in the phpdoc block and run phan for static analysis to catch any potential screwups.

    /**
     * Method for converting Foos into Bars
     *
     * @param Foo[] $foos
     * @return Bar[]
     */
    function convertFoosToBars(array $foos): array
    {
        // ...
    }

In theory this isn't perfect. In practice we haven't run into any issues yet.

Re: A look at modern PHP

#396

Post by stephenr » Tue, May 05, 2020, 4:56 PM UTC

ragnese wrote: post #391

stephenr wrote: post #286

Earlier quoted context omitted.

There are very few places where PHP cannot do strict comparisons. The first example in that article even highlights that `in_array` has a `$strict` parameter. I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.

Yeah, you're probably right about that. Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety. On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat…

There really aren't that many places to remember, and there is copious amounts of developer tooling available to identify, and in some cases even fix the issues automatically.

I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.

Re: A look at modern PHP

#397

Post by trey-jones » Tue, May 05, 2020, 4:58 PM UTC

unexaminedlife wrote: post #356

evilduck wrote: post #348

Earlier quoted context omitted.

Can you attribute that specifically to PHP making that possible? Why couldn't an equivalently capable peer use Python to do the same?

So the claim was that PHP "gotchas" are a drain on productivity. I'm not trying to compare with other languages, but I think my anecdata shows that, at least in my case, when you understand the tools PHP can be a very productive one.

Certainly gotchas are a drain on productivity. But I don't think this applies more to PHP than any other language I've used. The fact is, if you are less familiar with the language then you won't be as productive.

I personally spend a lot of time hopping among technologies and I always lean heavily on documentation. PHP has pretty good documentation, and this helps a lot in my opinion. I would guess that a lot of developers don't read the docs and just assume that something in a less-familiar language will work exactly like they expect it to, and then call this a "gotcha" when it doesn't.

Re: A look at modern PHP

#398

Post by out_of_protocol » Tue, May 05, 2020, 4:59 PM UTC

mywittyname wrote: post #326

out_of_protocol wrote: post #243

Earlier quoted context omitted.

Sometimes "==" is used under the hood ( switch/case i think?) and it's hard to avoid it completely even if you always use "===" in the code

You don't need to use switches. In fact, I'd argue that if blocks are better if you're evaluating against variable data types. Alternatively, if you really, really want to use a switch statement and loose typing might cause issues, it's pretty easy to compare types before the switch statement, e.g, if(gettype($a) !== "...") { return false; } switch($a) { ... }

Either choice doesn't really look like the sane language anymore

Re: A look at modern PHP

#399

Post by tzs » Tue, May 05, 2020, 5:00 PM UTC

aceman22 wrote: post #369

Laravel is the best REST api framework in existence for any language. Change my mind.

How well are older releases of Laravel supported?

I see on their website they are on version 7.x, and have documentation online there also for 6.x, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.1, 5.0, and 4.2.

For those with a conservative server software approach who install a Linux distro that will have long term support and then stick with it up until near the end of that long term, and stick with the version of PHP that came with the distro, we have to go back to 5.5 or 5.4 or maybe even earlier to get a Laravel that works with our PHP.

(Symfony appears to be at 5.3, with 4.4 and 3.4 still maintained. 3.4 will work with most major distros that are still in LTS, except I'm not sure about RHEL. 4.4 has the same requirements as Laravel 5.6, and so misses out on some existing LTS distros).

Re: A look at modern PHP

#400

Post by yjftsjthsd-h » Tue, May 05, 2020, 5:00 PM UTC

CommieBobDole wrote: post #379

fredsted wrote: post #145

I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app). Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building. In reality, the difference…

I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house. After years of using a lot of products and seeing which ones succeed and which ones fail, I question whether there's much of…

> I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house.

One brand of hammer causes RSI. This brand of hammer tends to bend nails unless they're made of titanium alloy at 80% higher cost. The houses built are basically fine, but they have quirks as a result of the builders trying to avoid having to use nails. You lose 10% of your workforce after every project to medical leave and burnout. Everything is fine because people keep buying houses (there's a shortage).