Hacker News Reader

Comment by skrebbel | Hacker News Reader

If they pull this off I just might return to PHP for a lot of work.

I love PHP's pragmatism, I love that it's batteries included, and most of all I love the deployment story. It's basically zero-config AWS Lambda without vendor lockin. If they manage to split off a better language without splitting up the community like Python 2/3 or Perl 5/6 did, then that's a spectacular win in my book. Having a little header on top of each file is real nice (and it also opens the door for mixed PHP/P++ projects, another thing Perl and Python failed at).

I find it telling that the PHP community keeps getting this sort of stuff right (they also got the php4->5 migration right back in the days, through collective community action; they fixed the error that was PHP 6 before it was too late, and so on). Pragmatism to the max, things have to not just keep working, but also stay convenient (like Hack wasn't).

View on HN

I do not mean to be rude or offensive but are there plans to fix the half-baked type system?

I am using PHP7 at work and the ability to annotate functions with types is a good idea until you get arrays which can take anything (so you can have an array of who-knows-what) so you can't assume further down the call stack that you're dealing with a known type so have to test what you're dealing with, or objects.

It's a bit of a mess to me and makes reading the code very difficult without running it in a debugger to step through what you're dealing with. Generics or some form of strong typing (which seemed to be what the type annotations and return value types hinted at) would really help, particularly with large projects. I am coming from a C++ background.

Any pointers or tips or documentation for me would be welcome.

If P++ pushes some of this strictness further onto the language then great. It saves me having to do it in code.

> until you get arrays which can take anything

There's a widely-used PHPDoc standard for annotating arrays: `Foo[]`, and there are at least three PHP static analysis tools that can correctly interpret those annotations: Psalm (https://psalm.dev), Phan (https://github.com/phan/phan) and PHPStan (https://github.com/phpstan/phpstan).

Phan and Psalm also support a docblock syntax for generics - I wrote about it here: https://medium.com/vimeo-engineering-blog/uncovering-php-bug...

Thanks for this! This is just what I was looking to know

Thanks!

How is PHP pragmatic compared to other languages? Do tell.

Instead of having a trillion build steps, you write PHP right in the HTML.

It’s so easy to teach. Learninh html css and php is such a win. Quick to bash out a simple site.

> Quick to bash out a simple site.

This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects. The language feels kludgey, and it attracts an ecosystem of beginners that don't necessarily have to learn much in the way of CS fundamentals or engineering to succeed. (Indeed, I've run into more than a few that don't know the difference between lists and dictionaries or the runtimes of the operations performed on them.)

It's not that I think that a language should be a barrier, but I've wasted so much time reading confusing and poorly-written PHP code, and it feels like the language actively empowers code to be written this way. A tool should also teach. There are other languages that have this problem as well (C++ comes to mind), but I think they tend to be hard enough to use that practitioners already understand the do's and don't's.

I know it's irrational of me to be so irate that this language is still active, but it bothers me that real engineering work and human productivity is spent on supporting one of so many scripting languages that are marginally different. I suppose I should be even more angry at all the cognitive effort being put into marketing and adtech, but PHP makes me sigh.

>> Quick to bash out a simple site.

> This is precisely why I don't think it's the appropriate tool for any substantial, serious, or long-lived projects

This is precisely why it is an appropriate tool - those simple sites become more complicated, and eventually they're Tumblr or Etsy or Wikipedia or what-have-you.

> it feels like the language actively empowers code to be written this way.

I've felt the same thing, especially early on. I think there are two reasons:

- a lack of a compile step means you're never forced to conform to someone else's idea of how your code should work (though running a static analysis tool fixes this).

- additionally, PHP's interpreter is designed to soldier on in situations where other runtimes would exit (e.g. when it encounters an undefined variable or array offset). While I can imagine justifications for this behaviour, it allows for a lot of bad code.

> The language feels kludgey, and it attracts an ecosystem of beginners that don't necessarily have to learn much in the way of CS fundamentals or engineering to succeed.

Reminds me of people complaining about JavaScript over the years, yet we pulled through, the language is better and most importantly, we're making money writing it.

>> we’re making money writing it

So did they in PHP.

you write PHP right in the HTML.

I hope this comment was meant to be ironic. Because that mindset demonstrates everything that is wrong with PHP and its community regarding engineering practices and security.

I think if you're going to make a statement like that you need to be prepared to provide an argument to back that up.

Ten years ago if you had told me we'd be interpolating HTML into javascript I might have said the same thing, yet here we are with React/JSX. It's not only common, it's generally regarded as good engineering.

A terrible and incorrect comparison. JSX is a templating language. Your logic still lives within a JS component.

Op is proposing that PHP be embedded directly in HTML. That obviously has maintainability and security issues. WordPress is a good example.

> [Embedding PHP in HTML] obviously has maintainability and security issues.

Honestly, I'm not sure it does. The two main security issues in typical PHP software are cross-site scripting and SQL injection, and both of those could be solved with better API design. (For example, PHP could use something similar to Rails's `html_safe` to make it harder to accidentally include untrusted HTML in the page.)

As far as maintainability goes, I'm not sure what makes PHP uniquely bad in this area. It seems like you could write a bad, unmaintainable React app in pretty much the same way you write a bad PHP app -- by eschewing MVC and sticking everything in the components/templates.

Honestly, I'm not sure it does.

Of course it does. Less maintainable code is always less secure.

Embedding PHP business logic in HTML makes it much easier to accidentally dump confidential state into the response.

Sticking everything into a component does not completely eschew MVC. You are still forced to bind values to a template.

Mixing PHP and HTML without a template engine provides no guarantees.

The responses here from PHP devs reaffirm my beliefs about how haphazard and sloppy PHP devs are.

> Embedding PHP business logic in HTML makes it much easier to accidentally dump confidential state into the response.

There's no reason confidential state will get dumped into the response unless your PHP settings are completely misconfigured.

There was a time when PHP had very insecure defaults and that sort of thing would happen regularly especially in shared hosting environments where you had limited control over the configuration. That was a long time ago.

I haven't worked on a PHP project in about 5 years, but I have seen well maintained PHP code. There's a lot of reasons to gripe about the language but this isn't one of them.

Wrong. Other languages require templating systems that won't allow you to dump variables because they won't be in scope in the first place.

Using PHP in HTML allows you to do just that.

Uh, no - templates are scoped to the function or method in which they are called. They are only global if you include the template globally.

    class MyTemplate {
        function displayTemplate() {
           include 'mytemplate.php'; // mytemplate.php has access to only class properties. 
           // Anything declared within mytemplate.php is scoped to the displayTemplate function. 
        }
    }

Uh, that is a contrived example not suggested by the op.

You can still embed PHP into HTML.

Using class methods to scope template variables is contrived? Huh?

You can still embed PHP into HTML.

> Other languages require templating systems that won't allow you to dump variables because they won't be in scope in the first place.

This isn't true of every templating system in popular use. Rails's Action View, if I recall, allows you to stick <%= ENV["THE_DATABASE_PASSWORD"] %> into a template with no fuss at all, and yet Rails developers somehow manage to avoid doing that.

PHP isn't bad because it lets you put code in HTML, it's bad because the default behaviors and APIs it provides make it easy to shoot yourself in the foot. A better, safer language could keep PHP's ease of deployment without its issues. Maybe P++ will be that language and maybe it won't.

That's not the same. I have seen plenty of unmaintainable PHP code that embeds business logic in HTML.

PHP was originally invented to be a templating language. Your templating logic can still reside in a PHP file, function, or class, the same way it can in javascript with JSX.

WordPress isn't bad because it uses PHP as a templating language (I think it's just the go-to "bad PHP codebase" example people use without really understanding why they are citing it). It's bad because it has competing code patterns that it evolved over time because it has to maintain backwards compatibility with an entire plugin ecosystem that is now decades old.

That is not true. I had to work with WordPress years ago, and one of the reasons it was so terrible is that it went to great lengths to mix view and business logic by interspersing PHP with HTML all over the place.

Yet React projects mix view and business logic by design and aren't usually that confusing to make changes to. That's not the reason the WP codebase is bad.

MVC does not mix view and business logic.

React isn't MVC.

React is MVVM, a variant of MVC.

React does not mix business logic and view logic in the same scope.

> JSX is a templating language.

So is PHP.

Reply on news.ycombinator.com