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

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

181–190 of 610 posts

Re: A look at modern PHP

#181

Post by [deleted] »

Ygg2 wrote: post #164
s1k3s wrote: 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…

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?

[deleted]

Re: A look at modern PHP

#182

Post by spdionis »

nsomaru wrote: post #110
simion314 wrote: post #93

Earlier quoted context omitted.

Just curious what problem are you trying to solve, I never had the need for different threads to communicate in PHP, most of the time in my work a user makes a request, and a PHp scripts does something like update the database or does some searching/working and returns a result.

What if that request was a document upload and your system is calling out some external api or processing for long enough such that you’d rather return now and update later when the job finishes. Maybe through Ajax or a redirect. The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Aja…

You can easily setup and use queues in PHP projects too.

Re: A look at modern PHP

#183

Post by tommica »

currriuosly wrote: post #25
tommica wrote: post #10

I've worked with PHP since 5.4, and to me the language has not been the obstacle, it has been my own skill-level that has held me back, and still is - I lack very much the core architectural skills in getting forward as a developer, among many other things. I've seen some codebases using an even older version, and I think I can understand where people are coming from with their angst towards the language - but I thin…

Good, that you can confirm your skill level, so maybe PHP suites you very well. For me, having no standard HashMap and having to set strict mode params in functions - is an instant no go. There is no lack of better options.

> Good, that you can confirm your skill level, so maybe PHP suites you very well.

Could you elaborate on this one, I am not exactly sure what you mean by it.

Re: A look at modern PHP

#184

Post by sadfklsjlkjwt »

Ygg2 wrote: post #164
s1k3s wrote: 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…

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?

Why are you using "=="? Use "===" and make explicit casts as required.

Re: A look at modern PHP

#185

Post by fetbaffe »

mekster wrote: post #148
creshal wrote: post #105

Earlier quoted context omitted.

> why does a language need to be constantly revolutionary if it solves what it sets out to solve well? That's a very big If in PHP's case.

What is the problem of admitting PHP solves the problem of quickly deploying web sites?

Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.

Re: A look at modern PHP

#186

Post by spdionis »

cletus wrote: post #168

It saddens me to see some of the (largely baseless and otherwise largely historical) hate for PHP. I use Hack in my day job, which has at this point diverged from PHP, and I like it for the most part. The thing that PHP does right that so few languages do is having a stateless core in the webserver. This is an incredibly efficient approach to serving HTTP traffic. Consider the startup cost issues with Java, or Rails'…

> The thing that PHP does right that so few languages do is having a stateless core in the webserver.

I never understood why the HN crowd always ignored this massive benefit of PHP, in a world where it's becoming clearer everyday that keeping things stateless across the stack provides many benefits towards managing complex systems.

Re: A look at modern PHP

#187

Post by AegirLeet »

2ion wrote: post #151

Is it possible to write long-running processes well in PHP today? Is the memory management of PHP up to the task? Or is it all a *cgi-based execution model? This question still is what makes it hard to place PHP. Basically all "high perf"/"high load" applications of it I know about run under PHP-FPM or webserver modules or uwsgi.

Long-running processes are definitely possible. You obviously have to be a bit more careful not to leak memory.

It's common to have things like queue workers implemented as long-running CLI processes. I just checked one of our services at work and there's a queue process that has been running for more than 4 months. There might be others that have been running even longer, but I don't feel like checking every service right now ;)

Projects like Swoole or ReactPHP are trying to make similar things possible for serving web requests too.

Re: A look at modern PHP

#188

Post by simion314 »

valand wrote: post #144
simion314 wrote: post #37

Earlier quoted context omitted.

Most of the time you do not chose a language or ecosystem because it has some cool syntax or some new feature. As an example if you need to do X you look at what solves X the best, if I can do X by installing say ffmpeg and write a bash script I will do that and not cry that bash does not have some cool feature. I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you ha…

X sometimes stands for problems above technical problem, such as: - Existing team is comfortable with using PHP - Existing project is tightly coupled PHP monolith - Existing project cannot be migrated to other language fast enough if needed All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people. I must emphasis though, all party must not freeze in time. They…

Sure, but sometimes X is something like you have a video and you want to use the GPU to analyze it and the best library for that is in C and there are great python bindings. So a professional developer would use C or Python and not waste his client time by trying to create it's own unmaintainable CoolLang bindings (where this dev is just now learning CoolLang and there are not that many people that know CoolLang).

Even for new projects, say you have a desktop app and you want to let the users submit some data and save it on your server(like feedback or crash reports), you can do this on your server with 1 PHP file and a few lines of code, no dependencies on 300 packages.

Re: A look at modern PHP

#189

Post by [deleted] »

fetbaffe wrote: post #185
mekster wrote: post #148

Earlier quoted context omitted.

What is the problem of admitting PHP solves the problem of quickly deploying web sites?

Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.

[deleted]

Re: A look at modern PHP

#190

Post by Ndymium »

holler wrote: post #80
nelsonic wrote: post #43

Earlier quoted context omitted.

Agree that PHP, Python and Ruby Web Frameworks lack modern features. Have you tried Elixir + Phoenix?

what modern features does python 3 lack compared to phoenix/elixir?

Considering the GP commenter started with an emphasis on concurrency, Elixir's concurrency features (thanks to the Erlang VM) are totally different than what Python can offer, namely isolated processes (scheduled in the VM so like green threads) where you can write blocking or CPU intensive code without worrying about blocking the other processes and where GC is per-process. With Python you (AFAIK) run into the GIL when threading or you fork OS processes that are heavyweight so you can't do that for every request or you'll fall down. Or you have to write async code which can still only saturate one core.

Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.

Post reply on HN