4 ms·

PHP is improving, slowly, but it is still way better than the PHP 5.x days. If your last memory of PHP is from 5.x, it's a very different language now - even if

PHP is improving, slowly, but it is still way better than the PHP 5.x days. If your last memory of PHP is from 5.x, it's a very different language now - even if it still has oddities, quirks, inconsistencies, and footguns, but PHP is still not the king of footguns - C++ is. I would ask though that if any PHP developers are reading this, I would love a feature called `modern_syntax` or similar which represents a major break in backwards compatibility in exchange for modern language conventions (i.e. no `$` prefix on variables, no `;` ending lines, perhaps some renamed core functions for consistency - we can have a debate about this). Kind of like how we have `strict_types`. Or, perhaps it could be invokable on a per-file basis, by using `<?phpmodern` instead of `<?php`. Then you could have your traditional PHP framework (say, Laravel) which has years of work on it remain intact while having a modern-PHP layer of your app-specific code on top. That would help, I would argue, with killing many of the PHP-specific criticisms while allowing some degree of backwards-compatibility.

zach_garwood 4y ago
Some people absolutely LOVE their semicolons. As a fan of Python, I don't really get it. But I think you would have to pry the semicolon from some people's cold, dead hands.
- gjsman-1000 4y ago
  Right - I'm only throwing the idea out there of a "modern PHP" layer that breaks some old conventions for more modern ones, but it would be opt-in and not too different, so that old code doesn't run into massive compatibility issues, and so that the "modern PHP" can be gracefully added (or not added) into any application where the developer has a different programming background, so as to allow a smoother transition.
- masklinn 4y ago
  TBF there are languages where the semicolon have important semantics meaning. Not needing to `\` every other line is also nice. And then there's javascript, of course, eating glue in the corner as usual.
- nobleach 4y ago
  Honestly this is something I love about Kotlin/Rust/Go. You either have them, or you do not. There are no time-wasting silly arguments over their veracity... just because a language makes them optional.
  - nequo 4y ago
    In Rust, they are not optional though. The semicolon turns an expression into an expression statement.[1] [1] https://doc.rust-lang.org/reference/statements.html https://doc.rust-lang.org/reference/statements.html
    - masklinn 4y ago
      > The semicolon turns an expression into an expression statement.[1] And more relevant, this has the effect of suppressing the expression's value when used in tail position of a block, by moving from the second to the first branch of the block expression grammar: https://doc.rust-lang.org/reference/expressions/block-expr.html https://doc.rust-lang.org/reference/expressions/block-expr.h... Which also explains why it sometimes doesn't work e.g. in non-block match arms, because they're not blocks, and thus don't accept statements.
    - nobleach 4y ago
      Right, that's exactly what I'm saying. They're NOT optional in any of those languages. Some of them (Kotlin and Go) don't have them, but there is no argument.
      - nequo 4y ago
        Oh, I misunderstood. I don't know Go very well but they do seem optional there: $ cat with_semicolons.go $ cat without_semicolons.go package main package main import "fmt" import "fmt" func main() { func main() { var x = 3; var x = 3 x += 1; x += 1 fmt.Printf("%d\n", x); fmt.Printf("%d\n", x) } } $ go run with_semicolons.go $ go run without_semicolons.go 4 4 $ $
- conductr 4y ago
  I'm a fan of both but when I started with Python, after years of PHP, it took me a minute to get the indentation and line breaks in the right places so it would execute a simple script. This may have improved but it was really hard to find where I did something wrong with format and with PHP I could easily spot a missing $ or ;. Going back to PHP, the $ and ; made things look messy at first. With either, if you stick around long enough it just becomes muscle memory and you don't even consider it overhead of writing code and your eyes adjust to the syntax. I find it a non-issue these days.
- gremlinsinc 4y ago
  i like using them in php and not javascript, it's almost like a switch, that tells me we're in a new context, don't write php here. Python is nice, but the whitespace can often have issues, and formatters can be wonky in vscode... It's pretty though, like rails. Still, I'm most comfortable w/ Laravel/php so will stick w/ that for time-being.
jeltz 4y ago
My last memory from PHP is 8.0 and I would still call it the king of footguns. I stopped coding PHP at 5.X and then after many years came back to 8.0 which everyone said was supposed to be better, and while it was better it was not much better. It is still a language full of footguns and unexpected behavior.
- Ayesh 4y ago
  Do you want to elaborate a bit more? Which features that you saw as footguns.
  - toolslive 4y ago
    I'll bite. ``` >>> (bool)"1"; => true >>> (bool)"0"; => false >>> (bool)"false" => true ``` (there are plenty of other things like that; the default call-by-value is also unexpected) Also: Laravel has plenty of "magic" ie things are intercepted via runtime reflection and then rerouted into something that hopefully "does-the-right-thing". It obfuscates control flow, causes unexpected side-effects and confuses IDEs and developers alike. Even the popular frameworks have combinations of subawesome code and silly ideas. Just the latest example I ran into: ``` int append(string $path, string $data) /* the signature of the Filesystem facade */ /* the implementation in FilesystemAdapter: */ public function append($path, $data, $separator = PHP_EOL) { if ($this->fileExists($path)) { return $this->put($path, $this->get($path).$separator.$data); } return $this->put($path, $data); } ``` - It's not correct as it will add (ffs why?) a newline in between the files. - Performance wise, this is bloody awful. - however, you *can* specify the separator in any call as the facade interface is just documentation and is bypassed via reflection (but that confuses your IDE)
    - Ayesh 4y ago
      Right, these are awful I totally agree. There were even some incorrect type casting specially with numbers and "numeric strings", which were fixed recently. I use strict typing in every new piece of code I work on, which largely fixed the problem. Laravel, while being extremely popular, isn't exactly the flagship choice for "quality code", not even Laravel claims it to be. Symfony framework gets a lot of things right, and IMO the showcase for more modern PHP.
Raydovsky 4y ago
I don't think people's proglem with PHP are the semicolons and $ variable declarations. It's mostly legacy stuff like built in function naming.
- padjo 4y ago
  I dunno, I used to work in PHP and I came to really loathe all the $ and ->. Like I get it’s just aesthetics but it bothered me how unnecessary they are.
- mekster 4y ago
  The time when semicolons become optional in PHP, it'll probably be my primary language over Typescript. I just don't get why people tend to type the semicolons in JS/TS when they don't need to like they don't know it's optional.
fatboy 4y ago
I don't understand what's wrong with breaking changes. Do they not happen in php major versions anyway? Why not fix the parameter ordering and built in function names whilst you're at it? Seems odd to me.
- lordgroff 4y ago
  Sometimes it's fine, sometimes it's not. And PHP has VERY FEW breaking changes in general. Think about something like WordPress, it powers so much of the internet, they're not going to be doing massive rewrites so that PHP can fix some legacy issues.
- gjsman-1000 4y ago
  There are breaking changes - but they tend to be very granular, and typically occur after a few rounds of deprecation. Renaming a bunch of core functions, and doing something radical (like, deleting the `$` prefix requirement) would break every single line of code, in every function, and in every library. It would be Python 3 all over again. Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2. If you opt-in on this particular file, the syntax requirements are different. Obviously that would prevent some deeper changes, but it would help modernize the language without as much of a radical break.
  - masklinn 4y ago
    > Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2. It's easy to imagine: Python 3 would not have existed. At all. Python 3 changed fundamental language semantics in ways which went way beyond syntax, that's why the core team shoveled so many changes in: they were breaking the language in a way which didn't brook mere syntactic opt-ins, this meant additional changes were minor issues easily handled compared to the fundamental difficulty of overhauling the language's entire string model and significant parts of the object model. > If you opt-in on this particular file, the syntax requirements are different. You're about 20 years late to the party, welcome to Python 2.1: https://docs.python.org/3/whatsnew/2.1.html#pep-236-future-directives https://docs.python.org/3/whatsnew/2.1.html#pep-236-future-d...
Isinlor 4y ago
> That would help, I would argue, with killing many of the PHP-specific criticisms I don't see why appeasing critics should be the goal of PHP. Removing $ and ; signs doesn't help me at all. I actually like the "$" sign. Maybe little bit less ;, but I don't really notice it. But I would certainly notice the mess of splitting language syntax into two separate branches. Breaking changes in language are not fun to address and take away the time from building features. I would be a lot more happy with generics. Or scalar objects, something like: $string = "abc"; var_dump($string->length()); // int(3) var_dump($string->startsWith("a")); // bool(true) https://github.com/nikic/scalar_objects https://github.com/nikic/scalar_objects That would make PHP standard library a lot easier and fun to use.
Beltalowda 4y ago
I always felt they focused on the wrong thing with all these improvements. PHP 5 as a language after 5.4/5.5 or so was okay; not great, but okay, or at least workable enough. It has footguns and issues but you can deal with those with a bit of practice. I always considered the standard library to be a far bigger problem. For example, as near as I can tell I still can't have fopen() tell me why it failed; it just returns False and one of those magic E_WARNING things. This is simple stuff, but also pretty critical to correctly implement some basic file I/O of the kind that you can do in ... pretty much any other language. Language blitz is nice, I guess, but not really "needed" as such. PHP5-the-language never really prevented me from doing things, PHP5-the-standard-library did, and from the looks of it, it still does. Things like no $ or ; are non-issues, and a good example of the wrong focus on syntax and "blitz" rather than things that actually matter. I'm not expecting things to be free of inconsistencies, oddities, historical baggage, etc. I just want ... basic functionality.

zach_garwood 4y ago

Some people absolutely LOVE their semicolons. As a fan of Python, I don't really get it. But I think you would have to pry the semicolon from some people's cold, dead hands.

gjsman-1000 4y ago
Right - I'm only throwing the idea out there of a "modern PHP" layer that breaks some old conventions for more modern ones, but it would be opt-in and not too different, so that old code doesn't run into massive compatibility issues, and so that the "modern PHP" can be gracefully added (or not added) into any application where the developer has a different programming background, so as to allow a smoother transition.
masklinn 4y ago
TBF there are languages where the semicolon have important semantics meaning. Not needing to `\` every other line is also nice. And then there's javascript, of course, eating glue in the corner as usual.
nobleach 4y ago
Honestly this is something I love about Kotlin/Rust/Go. You either have them, or you do not. There are no time-wasting silly arguments over their veracity... just because a language makes them optional.
- nequo 4y ago
  In Rust, they are not optional though. The semicolon turns an expression into an expression statement.[1] [1] https://doc.rust-lang.org/reference/statements.html https://doc.rust-lang.org/reference/statements.html
  - masklinn 4y ago
    > The semicolon turns an expression into an expression statement.[1] And more relevant, this has the effect of suppressing the expression's value when used in tail position of a block, by moving from the second to the first branch of the block expression grammar: https://doc.rust-lang.org/reference/expressions/block-expr.html https://doc.rust-lang.org/reference/expressions/block-expr.h... Which also explains why it sometimes doesn't work e.g. in non-block match arms, because they're not blocks, and thus don't accept statements.
  - nobleach 4y ago
    Right, that's exactly what I'm saying. They're NOT optional in any of those languages. Some of them (Kotlin and Go) don't have them, but there is no argument.
    - nequo 4y ago
      Oh, I misunderstood. I don't know Go very well but they do seem optional there: $ cat with_semicolons.go $ cat without_semicolons.go package main package main import "fmt" import "fmt" func main() { func main() { var x = 3; var x = 3 x += 1; x += 1 fmt.Printf("%d\n", x); fmt.Printf("%d\n", x) } } $ go run with_semicolons.go $ go run without_semicolons.go 4 4 $ $
conductr 4y ago
I'm a fan of both but when I started with Python, after years of PHP, it took me a minute to get the indentation and line breaks in the right places so it would execute a simple script. This may have improved but it was really hard to find where I did something wrong with format and with PHP I could easily spot a missing $ or ;. Going back to PHP, the $ and ; made things look messy at first. With either, if you stick around long enough it just becomes muscle memory and you don't even consider it overhead of writing code and your eyes adjust to the syntax. I find it a non-issue these days.
gremlinsinc 4y ago
i like using them in php and not javascript, it's almost like a switch, that tells me we're in a new context, don't write php here. Python is nice, but the whitespace can often have issues, and formatters can be wonky in vscode... It's pretty though, like rails. Still, I'm most comfortable w/ Laravel/php so will stick w/ that for time-being.

jeltz 4y ago

My last memory from PHP is 8.0 and I would still call it the king of footguns. I stopped coding PHP at 5.X and then after many years came back to 8.0 which everyone said was supposed to be better, and while it was better it was not much better. It is still a language full of footguns and unexpected behavior.

Ayesh 4y ago
Do you want to elaborate a bit more? Which features that you saw as footguns.
- toolslive 4y ago
  I'll bite. ``` >>> (bool)"1"; => true >>> (bool)"0"; => false >>> (bool)"false" => true ``` (there are plenty of other things like that; the default call-by-value is also unexpected) Also: Laravel has plenty of "magic" ie things are intercepted via runtime reflection and then rerouted into something that hopefully "does-the-right-thing". It obfuscates control flow, causes unexpected side-effects and confuses IDEs and developers alike. Even the popular frameworks have combinations of subawesome code and silly ideas. Just the latest example I ran into: ``` int append(string $path, string $data) /* the signature of the Filesystem facade */ /* the implementation in FilesystemAdapter: */ public function append($path, $data, $separator = PHP_EOL) { if ($this->fileExists($path)) { return $this->put($path, $this->get($path).$separator.$data); } return $this->put($path, $data); } ``` - It's not correct as it will add (ffs why?) a newline in between the files. - Performance wise, this is bloody awful. - however, you *can* specify the separator in any call as the facade interface is just documentation and is bypassed via reflection (but that confuses your IDE)
  - Ayesh 4y ago
    Right, these are awful I totally agree. There were even some incorrect type casting specially with numbers and "numeric strings", which were fixed recently. I use strict typing in every new piece of code I work on, which largely fixed the problem. Laravel, while being extremely popular, isn't exactly the flagship choice for "quality code", not even Laravel claims it to be. Symfony framework gets a lot of things right, and IMO the showcase for more modern PHP.

Raydovsky 4y ago

I don't think people's proglem with PHP are the semicolons and $ variable declarations. It's mostly legacy stuff like built in function naming.

padjo 4y ago
I dunno, I used to work in PHP and I came to really loathe all the $ and ->. Like I get it’s just aesthetics but it bothered me how unnecessary they are.
mekster 4y ago
The time when semicolons become optional in PHP, it'll probably be my primary language over Typescript. I just don't get why people tend to type the semicolons in JS/TS when they don't need to like they don't know it's optional.

fatboy 4y ago

I don't understand what's wrong with breaking changes. Do they not happen in php major versions anyway? Why not fix the parameter ordering and built in function names whilst you're at it? Seems odd to me.

lordgroff 4y ago
Sometimes it's fine, sometimes it's not. And PHP has VERY FEW breaking changes in general. Think about something like WordPress, it powers so much of the internet, they're not going to be doing massive rewrites so that PHP can fix some legacy issues.
gjsman-1000 4y ago
There are breaking changes - but they tend to be very granular, and typically occur after a few rounds of deprecation. Renaming a bunch of core functions, and doing something radical (like, deleting the `$` prefix requirement) would break every single line of code, in every function, and in every library. It would be Python 3 all over again. Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2. If you opt-in on this particular file, the syntax requirements are different. Obviously that would prevent some deeper changes, but it would help modernize the language without as much of a radical break.
- masklinn 4y ago
  > Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2. It's easy to imagine: Python 3 would not have existed. At all. Python 3 changed fundamental language semantics in ways which went way beyond syntax, that's why the core team shoveled so many changes in: they were breaking the language in a way which didn't brook mere syntactic opt-ins, this meant additional changes were minor issues easily handled compared to the fundamental difficulty of overhauling the language's entire string model and significant parts of the object model. > If you opt-in on this particular file, the syntax requirements are different. You're about 20 years late to the party, welcome to Python 2.1: https://docs.python.org/3/whatsnew/2.1.html#pep-236-future-directives https://docs.python.org/3/whatsnew/2.1.html#pep-236-future-d...

Isinlor 4y ago

> That would help, I would argue, with killing many of the PHP-specific criticisms I don't see why appeasing critics should be the goal of PHP. Removing $ and ; signs doesn't help me at all. I actually like the "$" sign. Maybe little bit less ;, but I don't really notice it. But I would certainly notice the mess of splitting language syntax into two separate branches. Breaking changes in language are not fun to address and take away the time from building features. I would be a lot more happy with generics. Or scalar objects, something like: $string = "abc"; var_dump($string->length()); // int(3) var_dump($string->startsWith("a")); // bool(true) https://github.com/nikic/scalar_objects https://github.com/nikic/scalar_objects That would make PHP standard library a lot easier and fun to use.

Beltalowda 4y ago

I always felt they focused on the wrong thing with all these improvements. PHP 5 as a language after 5.4/5.5 or so was okay; not great, but okay, or at least workable enough. It has footguns and issues but you can deal with those with a bit of practice. I always considered the standard library to be a far bigger problem. For example, as near as I can tell I still can't have fopen() tell me why it failed; it just returns False and one of those magic E_WARNING things. This is simple stuff, but also pretty critical to correctly implement some basic file I/O of the kind that you can do in ... pretty much any other language. Language blitz is nice, I guess, but not really "needed" as such. PHP5-the-language never really prevented me from doing things, PHP5-the-standard-library did, and from the looks of it, it still does. Things like no $ or ; are non-issues, and a good example of the wrong focus on syntax and "blitz" rather than things that actually matter. I'm not expecting things to be free of inconsistencies, oddities, historical baggage, etc. I just want ... basic functionality.