How is PHP pragmatic compared to other languages? Do tell.
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.
> 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.
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.
So did they in PHP.
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.
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.
Op is proposing that PHP be embedded directly in HTML. That obviously has maintainability and security issues. WordPress is a good example.
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.
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.
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.
Using PHP in HTML allows you to do just that.
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.
}
}You can still embed PHP into HTML.
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.
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.
React does not mix business logic and view logic in the same scope.
So is PHP.