Hacker News Reader

> 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

That would make PHP standard library a lot easier and fun to use.

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.

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.

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.

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.

Do you want to elaborate a bit more? Which features that you saw as footguns.

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)

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.

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.

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.

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.

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.

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.

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

> 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.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.

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.

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
    $                                       $

Go requires every line to end in semi-colons if you look at the EBNF in the specification, but the compiler will insert them for you. It's kind of a subtle detail, but it shows up in some places, for example the following being a compile error:

  if true {
  }
  else {
  }

Because the semicolon is inserted when the last character on a line is "one of the operators and punctuation ++, --, ), ], or }" (among other cases, see https://go.dev/ref/spec#Semicolons). So you need to use the } else { style.

In practice, you can just leave of the semicolons at the end of lines (gofmt will remove them) and it's as if semicolons are not required, but if you want to get all technical about it then they are required.

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.

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.

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.

1. it requires that all your users churn their codebase for something which doesn't directly add value

2. it introduces errors which can remain latent or unfound for a while, especially when you're just changing the parameter ordering of a function in a dynamically typed language

> Do they not happen in php major versions anyway?

PHP has actually been awesome at preserving backwards compatibility.

I wrote a server, when PHP 4 was still the cutting edge, and it still works, now, at 8.1 (although I know that it is being rewritten, in order to leverage things like Laravel).

I set up something for someone in 2003/2004. It was largely PHP4 code that got a bit upgraded to 5.0. We lost touch.

I got a call at end of 2017 saying "this isn't working". Someone else had taken over hosting and been upgrading PHP along the way. There was finally something that broke (some weird dynamic object stuff that was making up for some PHP4 shortfall at the time) and... I did some small patch to get around it but suggested they have someone rebuild, either in PHP 7 or ... any tech from 2017. Just needed to migrate relatively simple database over.

I pointed out that they had basically 13 years of hassle-free system - that's generally a bit outside the norm for that sort of thing, and... that was the recommendation they gave back to their org's board of directors (small non-profit sort of thing).

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.

> 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-d...

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.

"I don't understand what's wrong with breaking changes. Do they not happen in php major versions anyway?"

See python2 vs python3. It almost ended the language IMHO.