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

191–197 of 197 posts

Re: PHP 8.5

#191

Post by aj_hackman »

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.

Python has been massive since the 2000s. When AI rolled around, it was already there, a bunch of people knew it, and it was Good Enough (tm).

Re: PHP 8.5

#192

Post by dr0verride »

PHP is still an incredibly verbose and tedious language to work with. I'm glad that it's continuing to improve because I'm stuck with it everyday.

Re: PHP 8.5

#193

Post by rini17 »

jasomill wrote: post #186
rini17 wrote: post #151

Earlier quoted context omitted.

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 som…

Before you could assume...null pointer derefs will be trapped by the OS Before when? Microsoft(R) MS-DOS(R) Version 6.22 (C)Copyright Microsoft Corp 1981-1994. C:\TMP>type foo.c void main() { long q = 0; q = 0/q; } C:\TMP>cl /Od foo.c Microsoft (R) Optimizing Compiler Version 5.10 Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved. [...] C:\TMP>foo run-time error R6003 - integer divide by…

In DOS you always had to manage your expectations, not sure what you're trying to prove here?

Re: PHP 8.5

#194

Post by dotancohen »

array_key_first wrote: post #144
dotancohen wrote: post #10

Earlier quoted context omitted.

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…

I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.

How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic.

Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.

Re: PHP 8.5

#195

Post by array_key_first »

tuqqu wrote: post #190
array_key_first wrote: post #182

Earlier quoted context omitted.

I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it. Also, you can just flip on strict typing in PHP, and you should know that.

Strict types determine whether a function accepts a variable of a certain type, casts it, or throws a TypeError. It does not affect int + string operations or anything else really

Kind of but not really. Even without strict types, functions will throw a type error if you give them the wrong thing for almost all types, except primitives, which will be automatically coerced. Strict types turns that coercion off.

Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.

Re: PHP 8.5

#196

Post by array_key_first »

dotancohen wrote: post #194
array_key_first wrote: post #144

Earlier quoted context omitted.

I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.

How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic. Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which complet…

I don't know, I think it's really fine. It's very typical to compose a bunch of array functions together and, honestly, I think that's good form most of the time. This makes that a little bit easier.

Re: PHP 8.5

#197

Post by devmor »

rafark wrote: post #187
dgb23 wrote: post #83

Earlier quoted context omitted.

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…

>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features. The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is conside…

To be fair, PHP's internal development was once heavily sponsored by a corporation. That corporation's sponsored developer(s) were the primary source of resistance against BC breakage and forced the language to stagnate for years.
Post reply on HN