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

71–80 of 610 posts

Re: A look at modern PHP

#71

Post by alphadevx »

laumars wrote: post #44
alphadevx wrote: post #11

Many of the features highlighted in that article as "new" are from PHP 5.x, so it reads more like a list written by someone who has been out of touch with PHP development for a number of years.

Did you actually read the article or just the headings? Any features that pre-date 7.x are discussed as being 5.x features and, where applicable, the author expands on how it's been further refined / improved upon in 7.x releases

Yes I read it, why accuse me of not doing so? The main block of sample code is highlighting OOP features in PHP, but PHP has had most of those features since 5.3, e.g. namespaces, so my point still stands. Those features are not part of "PHP showing its maturity in release 7.4", but have been around since at least 2009, so why lead with that example?

Re: A look at modern PHP

#72

Post by zozbot234 »

Narann wrote: post #51

Depicts language feature, PHP ecosystem is dying. For me, an example is latest MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated anymore, to pygments (Python) using a sub process. I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature. I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an eco…

Would it be feasible to write a PHP equivalent to emscripten, so that one could export software compiled from any frontend language (including, e.g. the WASM representation) as a php object that can be run directly by mod_php?

Re: A look at modern PHP

#73

Post by luckylion »

frenchman99 wrote: post #38
Svip wrote: post #14

Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt. PHP's raison d'être remains its ease of getting an instance running on a webserver. But…

I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0]. PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go. [0] https://www.indiehackers.com/podcast/007-john-onolan-of-ghos... [1] https://symfony.com/

Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things done, and using a very common tool helps with having a large pool of people you can call upon.

Re: A look at modern PHP

#74

Post by dastx »

Narann wrote: post #51

Depicts language feature, PHP ecosystem is dying. For me, an example is latest MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated anymore, to pygments (Python) using a sub process. I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature. I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an eco…

This is a side effect of open source. GeSHi, and many others, suddenly stop getting maintained, and more often than not, project ownership doesn't get passed down.

This problem isn't unique to PHP. I have seen this is many projects across all kinds of different languages and tooling.

Unfortunately, if there's no good alternative written in PHP, MediaWiki could have either reimplement it from scratch. In my opinion, GeSHi isn't the best implementation of a syntax highlighter, so I get their reason to not adopt it. Writing a syntax highlighter from scratch isn't a trivial task either.

None of this says that the PHP ecosystem is dying though. MediaWiki isn't going to suddenly move away from PHP. Nor will many, many of the other big name projects that are still built on top PHP, and as long as there are big name projects, PHP ecosystem will continue to evolve.

I will say choosing a Python sub-process at the sacrifice of portability (considering how many people simply run this on a PHP webhoster) is quite surprising.

Re: A look at modern PHP

#75

Post by solraph »

simion314 wrote: post #55
cageface wrote: post #40

PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.

What do you mean by concurrency here? JS like async or Java/C# like threads? And why would concurrency help in problems where PHP is involved, in the problems I solve with PHP I don't think I ever needed async. For unning more things in parallel like processing 1000 RSS feeds you can spawn 10 scripts that run in parallel and if one crashes the others still continue to work(I had experienced crashes with some RSS XML…

Not the parent, but it would be nice to have separate thread for things like logging and firing events into a queue.

Re: A look at modern PHP

#76

Post by Okawari »

manigandham wrote: post #21
andrewjmg wrote: post #12

Earlier quoted context omitted.

"so many new and established options that are better in almost everyway" such as?

C# (optionally using the ASP.NET framework) running on the fast, efficient, cross-platform .NET Core. Or Java/Scala/Kotlin. Or Go. Or Python. Or Node + Typescript.

If my project is "big enough" to warrant something like Laravel, I would just pick Rails or Phoenix over it any day. I find both those languages much better to work in and I just feel like I'm getting things done way faster. If its smaller than that, I'dd definitly just pick go or node with express or go maybe.

I work with PHP 5 days a week through work and even a few years into it, i still do not like it. Its feels like a mess compared to the other languages I work with for my own projects. Even when working with something like Laravel which do mask a bunch of the pain points of the language, it still feels cumbersome IMO.

Re: A look at modern PHP

#77

Post by aetherspawn »

realharo wrote: post #64
barbegal wrote: post #60

Earlier quoted context omitted.

But in the overall scheme of things it's order of magnitudes more difficult to deploy. PHP is upload a file whereas docker requires many more steps (for example: https://kb.sloppy.io/en/collections/156106-getting-started )

The first section in that link literally says >In our dashboard you will find pre-configured Open Source apps like WordPress, Plone and other. They are all based on the official docker images and can be deployed with just one click. Otherwise I don't see how something like this is that much more difficult https://www.openshift.com/blog/deploying-applications-from-i... Or this https://kb.sloppy.io/en/articles/1313693-…

They had to write an installer ecosystem around installing docker images, whereas with PHP and most stock server configs you can SSH a file into a server and you're pretty much done.

Still if I want to write a simple web app in < 1 day, I would definitely use PHP.

Re: A look at modern PHP

#79

Post by stonogo »

simion314 wrote: post #62
fatboy wrote: post #49

Earlier quoted context omitted.

The thing I hate about php is the inconsistency and unpredictability for new-to-php developers. camelCase? snake_case? nocase? Who knows what the global function will be. And who knows what order the arguments should go in. Sometimes the array is first, sometimes not (in array iterating functions like map). The thing that got my goat the most however was that referencing an undefined variable merely caused a warning,…

FYI when you start a PHP project you need to change your dev machine php.ini to be super strict, so all warrnings should just error out. The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where…

It never made sense. The original hash bucketing mechanism for the function lookup in PHP was the length of the name of the function, so each new function was named a specific length to ensure the function list was evenly distributed across the hash table.

Re: A look at modern PHP

#80

Post by holler »

nelsonic wrote: post #43
cageface wrote: post #40

PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.

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?
Post reply on HN