PHP 8: Before and After • Hacker News Board

Re: PHP 8: Before and After

#171

Post by shawnz » Fri, Oct 23, 2020, 10:50 AM UTC

tannhaeuser wrote: post #158

shawnz wrote: post #123

Earlier quoted context omitted.

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML content type from a PHP script. It would require many new syntaxes (e.g. for outputting variable data in the attribute values of elements, selectively outputting elements or attributes, looping through them, etc). It would also mean the language is tied to spec…

Backward-compat and syntax doesn't have to be a problem. The ` ` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly bla whatever "?> &x where x is bound to markup checked against permissible elements in the first context (eg rejecting ) and escaped into <p>whatever<p>…

There are many cases that doesn't solve, for example, how can I conditionally decide to either inject an attribute or not inject it using this technique? How do I mix user-controlled text which should be escaped with dynamically generated HTML in PHP strings that I don't want to be escaped? How will scope be managed and can those constants be redefined (not normally a concern in SGML)?

Plus, what makes you expect this opt-in syntax would catch on if people already don't care enough to use HTML-aware template engines?

EDIT: Also, what happens if the static parts of the document aren't syntactically correct SGML? How can you even know if the final output will be syntactically correct SGML until you run all the legacy parts of the PHP code that output directly in the document stream?

Re: PHP 8: Before and After

#172

Post by SergeAx » Fri, Oct 23, 2020, 10:53 AM UTC

codegeek wrote: post #137

js4ever wrote: post #134

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new pr…

"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/…

You can't rely on a compiled/JIT language to address performance requirements. There's always time when your server is overloaded, no matter if it can handle 100 or 10000 RPS. You should architect your app with scalability in mind. And then there's not much difference between languages, only marginal savings on infrastructure. But one month of decend web server host costs about the same as one hour of decent software engineer.

Re: PHP 8: Before and After

#173

Post by fetbaffe » Fri, Oct 23, 2020, 10:55 AM UTC

JekLod10 wrote: post #11

So php tries so hard to be Java. Well, just stick with Spring and get the job done professionally. Learning PHP these days is a waste of time.

I learned Spring, one of the worst frameworks I ever worked with (note that I have worked with Laravel too). Spring is a bloated mess with lots of legacy & misuse of annotations, a.k.a necromancy.

It has somewhat improved with Spring Boot, but still to be avoided.

Database layer in Spring, especially if you combine it with the monstrosity called Hibernate, is enough to apply to an insane asylum. Trying to debug what combinations of annotations that work and doesn't work is time you could have used writing PHP instead and get results.

The idea that you can annotate a SQL schema & query language into a Java class with annotations is one of the most asinine ideas I ever come across.

And don't get me started on Java collections.

Re: PHP 8: Before and After

#174

Post by codeulike » Fri, Oct 23, 2020, 10:55 AM UTC

stabbles wrote: post #39

I'm glad you can now write: public static function new(): static { return new static(); } It really brings the point across it's static.

and new

Re: PHP 8: Before and After

#175

Post by psychoslave » Fri, Oct 23, 2020, 10:55 AM UTC

8 years after the publication of the famous "PHP: a fractal of bad design", has PHP overcome any of the point raised in this article?

https://www.pixelstech.net/article/1334166417-PHP%3A-a-fract...

Re: PHP 8: Before and After

#176

Post by LeonM » Fri, Oct 23, 2020, 10:59 AM UTC

dkarlovi wrote: post #73

jmnicolas wrote: post #64

Can a fellow geek knowledgeable in PHP gives me a few pointers? I have inherited a 12 year old PHP app written by 2 interns. The code was written with Notepad++ (no IDE), no comments except when they copy pasted something from the internet, most variables are single letter and it's the biggest spaghetti bowl I have ever seen. To add insult to injury I have no experience with PHP (apart from peeking at this code to fi…

Roughly in the order you should do it. Hopefully it's at least PHP 5.3 code: 1. Definitely get a PHP IDE: https://www.jetbrains.com/phpstorm/ 2. Get a step debugger and hook it in: https://xdebug.org/ 3. Fix the code style: https://github.com/FriendsOfPHP/PHP-CS-Fixer 4. Run the code through some static analysis tools https://phpstan.org/ https://psalm.dev/ 5. Upgrade the code with an AST fixer (might help you update…

If you do #1, you'll get #3 and #4 for free, and full integration of #2 and #6 :-) Best 80 bucks you can ever spend if you write PHP.

My basic procedure when inheriting legacy code is:

- Load the project in phpstorm

- Perform autoformatting so it becomes readable

- Run code inspection to find any obvious issues the original author missed

- Write tests in phpstorm, if not already exists

- Run the code with xdebug, step through it

Re: PHP 8: Before and After

#177

Post by jpalomaki » Fri, Oct 23, 2020, 11:03 AM UTC

andi999 wrote: post #169

codegeek wrote: post #137

Earlier quoted context omitted.

"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/…

I am wondering this: are people who do crud apps (in php or otherwise) do consider race-conditions in the database? Like one query and then based on that query another one which inserts/updates? And if so, where can I read about the standard techniques used in practice?

Database transactions is the topic you should look into. There's ways to handle these in all environments.

https://en.wikipedia.org/wiki/Database_transaction

Re: PHP 8: Before and After

#178

Post by jhgb » Fri, Oct 23, 2020, 11:04 AM UTC

dcabrejas wrote: post #136

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…

I haven't found any good arguments against PHP in the comments here, just pure hate. Let's name a few of the arguments people are making: 1. Its variables start with $ and that is ugly: I mean, come on, I won't even entertain this bigotry. 2. It used to be better before: This is just pure nonesense, before OOP PHP wasn't good to create any big and well-structured application, it is ironic because most of the bad opin…

> 1. Its variables start with $ and that is ugly:

At the very least it seems nonsensical and cargo-cultish: As a non PHP-er, what is the actual purpose of $? In Perl, it indicates variable context (for better or worse, there's more than one, so it has to be indicated somehow). In shell, it indicates the substitution of variable name by its value. In PHP...I draw a blank. It really seems like an "I wanted my language to look like some other language but I had no idea what it should be doing" kind of thing.

Re: PHP 8: Before and After

#179

Post by SergeAx » Fri, Oct 23, 2020, 11:05 AM UTC

Please remember that PHP is more or less the only truly free (as freedom) community driven language suitable for both prototyping/pet projects and enterprise grade web software development. TypeScript and C# are Microsoft, Go is Google, Java is Oracle. Python is not suitable for complex multi-layered systems, Rust is too young and let's see where it will go without Mozilla. Ruby? IMO Ruby is in sunset phase, no new ambitious projects are started with Ruby.

Re: PHP 8: Before and After

#180

Post by minot » Fri, Oct 23, 2020, 11:06 AM UTC

codegeek wrote: post #142

systemvoltage wrote: post #129

Earlier quoted context omitted.

More than anything, I find the language $ugly. Is that fair? No. Am I being unreasonable. Yes. Do I love PHP? Gross. I just have to live with it and go past the ugly syntax. It’s like an unhappy marriage. It’s just fine.

But that's just like your opinion man (quoting the Big Lebowski). I like seeing the $ sign. Does that mean I am not a good developer ?

I think PHP is a fine language if you are working on an existing application or are building on top of symfony but I’ll begin second guessing all your design decisions if you increase the default execution time of php from thirty seconds to over five minutes. I submit PHP does not belong anywhere outside the request response cycle. If you use it for other stuff, you are not wrong. I mean I’ve used puppeteer and node js to capture screenshots and I still think that ideally JavaScript should only exist in client-side web browser based development. I would never voluntarily do any of the react native or express/hapi server side development with JavaScript. I will do it if there is money involved, it just isn’t my preference.

It is ok to have a preference to do non web work with PHP but you owe it to yourself to at least try something else before saying you prefer it over everything else.

There is nothing wrong with $ though. That’s just insane. Also I’m very excited to see Drupal 9 being released with twig 2 support and more recent symfony support. I just think you should at least evaluate other options before saying “everything goes better with php sauce” just like the JavaScript crowd should stop and get some help before using JavaScript for native development and or server side development.