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

151–160 of 197 posts

Re: PHP 8.5

#151

Post by rini17 »

deaddodo wrote: post #111
rini17 wrote: post #90

Earlier quoted context omitted.

You can learn everything about undefined behavior in 30mins?

It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus. But, if you want an answer to your question: You can learn to avoid undefined behavior in about 30 seconds . If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an…

Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.

> You can learn to avoid undefined behavior in about 30 seconds.

Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.

Re: PHP 8.5

#152

Post by ffsm8 »

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?

A person that cares for coding will inevitably code more then 9-5 and consequently get familiar with new syntax

A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax

So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge

Re: PHP 8.5

#153

Post by jaredklewis »

matula wrote: post #132
inovica wrote: post #28

I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since t…

I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.

This is true. As long as only one person interacts with the code, all languages can be simple. C++ can be simple.

But once multiple people are involved and I have to read someone else's code, then I really start to appreciate languages with less features. There are some language I love to write code in, like Ruby or Haskell, where I feel like a damn genius when I write it, but want to pull my hair out when I have to read someone else's code.

Re: PHP 8.5

#154

Post by kyriakos »

erickf1 wrote: post #122
johnisgood wrote: post #33

Earlier quoted context omitted.

I think PHP is way better now than it used to be. Learn PHP 8 and you are good to go.

Until two years later the same thing is said about PHP 9, 10, 11. Constant change is not good.

It gets updated but breaking changes are not that many and always well justified. Most breaking changes I've seen the past decade only broke if your code was already bad relying on non standard ways of using language features. There are tools that help with migration.

Re: PHP 8.5

#155

Post by LexiMax »

inovica wrote: post #28

I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since t…

PHP is a perfect example of how to undergo major transitions correctly.

In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.

They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.

They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.

If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.

Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.

Re: PHP 8.5

#156

Post by graemep »

okeuro49 wrote: post #135
tim333 wrote: post #127

Earlier quoted context omitted.

Simplicity may often get ignored but I think it's been a big reason for Python's success which has gone from about #10 on the TIOBE language list to #1 since when I started learning it, which was probably around when the XKCD "everything is so simple" cartoon came out. ( https://xkcd.com/353/ )

Doubtful it is anything to do with simplicity. Python's success is explained by it being the language of choice for AI.

I think its the other way around. Python became the language of choice for AI because it was already popular. Lots of things made it popular: use for systems management scripts, web apps (Django, especially), then numerical stuff,...

I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.

Re: PHP 8.5

#157

Post by attendant3446 »

idoubtit wrote: post #131
gramakri2 wrote: post #30

Earlier quoted context omitted.

IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.

Are the new features really readable? I have no idea what this code from the OP is meant for: #[SkipDiscovery(static function (Container $container): bool { return ! $container->get(Application::class) instanceof ConsoleApplication; })] final class BlogPostEventHandlers { /* … */ } As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#". See https://wiki.php.net/rfc/c…

I'm glad it's not just me who finds the syntax of some of the new PHP features confusing and complicated. And it's not just this version either, they keep adding weird "sugar" in each new release.

Re: PHP 8.5

#158

Post by hu3 »

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…

This has not been my experience at all.

PHP code requires very little maintenance to keep working for a decade+.

Re: PHP 8.5

#160

Post by oconnor663 »

LexiMax wrote: post #155
inovica wrote: post #28

I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since t…

PHP is a perfect example of how to undergo major transitions correctly. In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements. They did this by not breaking the universe in these major updates...o…

> They did this by not breaking the universe in these major updates

I don't think the amount of breakage per se was the problem with Python 3. I think the problem was that for a long time (until u"" strings in 3.3? four years after 3.0?) there was ~no way for a library to support both 2 and 3 in a single codebase. That meant that each project had to either maintain a fork, or do a "flag day" migration, which in practice meant you couldn't migrate until all your dependencies were migrated. Big mistake in retrospect.

Post reply on HN