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

PHP 8.5

stitcher.io

Post reply on HN
Print view View original

81–90 of 197 posts

Re: PHP 8.5

#81

Post by dgb23 »

kijin wrote: post #42
rob74 wrote: post #35

Earlier quoted context omitted.

I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework ( cough Laravel cough ), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...

PHP is a reasonable choice if you care about writing something that will still work out of the box 10 years from now. But of course this assumes that you work with a team that can see a year ahead, let alone 10.

PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.

PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.

Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.

There are languages that are _much_ more stable and reliable than that.

Re: PHP 8.5

#82

Post by bawolff »

greiskul wrote: post #41
s1mplicissimus wrote: post #14

Earlier quoted context omitted.

Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :) Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses

The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate. PHP has an operator for something you should never do in a sane codebase. You know that python wants good good to look good? PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be…

> The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.

The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.

It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.

The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.

Re: PHP 8.5

#83

Post by dgb23 »

dotancohen wrote: post #10
f311a wrote: post #7

PHP becomes a complex language with each update. For what reason? Its application is still limited to the web, mostly.

I downvoted you before reading the fine article. I'm back to correct that. The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unar…

Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.

Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.

Re: PHP 8.5

#84

Post by dgb23 »

pabs3 wrote: post #49
habibur wrote: post #27

Backticks as an alias for shell_exec() are deprecated Used that a lot in shell scripts. using php-cli. like in `mkdir $dirname`;

That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.

Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.

Re: PHP 8.5

#85

Post by dgb23 »

The pipe operator example omits the typical way you would write this code in any language: simply by introducing temporary variables or by shadowing.

The url parse example is not being compared to the builtin parse_url function that is just as easy to use.

Re: PHP 8.5

#86

Post by conradfr »

dgb23 wrote: post #81
kijin wrote: post #42

Earlier quoted context omitted.

PHP is a reasonable choice if you care about writing something that will still work out of the box 10 years from now. But of course this assumes that you work with a team that can see a year ahead, let alone 10.

PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion. PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff. Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as we…

That has not been my experience and I have a project that started in 2017 with PHP 7.1 & Symfony 3.3 and is now at PHP 8.4 & Symfony 7.3 with plenty of dependencies.

Not everything will always update flawlessly but with Composer and a popular framework with planned depreciations and releases the ecosystem tends to sync fairly well.

Re: PHP 8.5

#87

Post by monooso »

rytis wrote: post #59
ffsm8 wrote: post #45

Earlier quoted context omitted.

I think he's thinking more along the lines of PHP 5-8.5 That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax. Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowl…

And what exactly 9-5 has to do with caring for coding or time investment in language learning?

Not GP, but I assume the suggestion is that it's difficult to stay abreast of new developments within the constraints of a typical work day. Especially if your job utilises older technologies, as most do.

Re: PHP 8.5

#89

Post by [deleted] »

deaddodo wrote: post #52
pjmlp wrote: post #38

Earlier quoted context omitted.

This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....

C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now. If you pull out examples of the earliest C, sure, it looks weird . But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modificat…

[deleted]

Re: PHP 8.5

#90

Post by rini17 »

deaddodo wrote: post #52
pjmlp wrote: post #38

Earlier quoted context omitted.

This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....

C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now. If you pull out examples of the earliest C, sure, it looks weird . But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modificat…

You can learn everything about undefined behavior in 30mins?
Post reply on HN