There are a lot of people who think that if a language or framework doesn’t completely disallow bad practices (and of course the authors have to agree with their very specific subjective ideas of what bad practices are) then it sucks. I’ve always found that weird. Like why are you mad at a tool for being “too flexible”? Why not be okay with learning what not to do?
Is there any language that completely disallows bar practices? Even Rust has unsafe{}.
For a long time PHP did suck, because of its easy going type system. Is $user an object? A string? An ID? You’ll find out during runtime! Modern PHP has added enforced type annotations (making PHP objectively better than Javascript) which turned it from “kind of shit” to “pretty good” in an instant.
I think languages can be too flexible. Just look at C and the weird hacks C programmers use to bypass the lack of protections built into the language itself, and the amount of weird stuff you need to know if you want to recognise undefined behaviour. The more flexible your language is, the more experienced programmers you’ll need not to turn the program into a complete mess, which will eventually become a problem when a new team member replaces a greybeard who moved on to another project.
Super flexible languages are great for experimenting and programming as art, but if you’re trying to build functioning software, boring limitations are your friend. It’s why Java is still so popular after all this time: the language looks like it hasn’t changed since 2005 and the code you write is clunky and verbose, but at least it’ll be read readable in ten years when you need to replace the code.
If you’re going to do that, then you also have to have a community that stresses best practices.
In 1999, Perl was leading the world with a tutorial for DBI (its primary database driver interface then and now) that uses placeholders in its very first code example. The community made that the standard, and it was the first hit on “Perl SQL tutorial” on Google for a long time. Perl applications with SQL injection attacks are out there, but have been relatively uncommon.
Notice that the API doesn’t force you to use placeholders. It’s simply strongly encouraged by the community.
Also in 1999, PHP was leading the world in not having a database driver interface through a common API, but rather a thin wrapper over whatever C libraries were used for individual databases. If that database supported placeholders at all (MySQL didn’t, and guess which database was most popular with PHP?), then it often had a different syntax* for every one. (Note that Perl’s DBI uses a translation interface that can implement “?” as a placeholder for you if the underlying DB doesn’t do anything else or uses weird syntax). You could always use a filtering function, and PHP devs would routinely try to write their own rather than use the one that came with the database API that’s already vetted. Either way, there was no widespread community pressure to use safe practices, and PHP led the world in SQL injection vulnerabilities for well over a decade.
*As a side note, I was recently accused by another dev of having a Python app riddled with SQL injection vulnerabilities. In fact, it was well protected, but it was using the psycopg interface to PostgreSQL, and it has a weird placeholder syntax that the other developer wasn’t familiar with. Thanks, psycopg!
An interesting thing you may have missed is that the PHP community actually aggressively removed posts from stack overflow suggesting the old broken autoquoter approach. I’d say that PHP actually has an incredibly security minded community at this point.
I don’t doubt the language has improved. I just don’t see a point when there’s a million other options. In the 90s/early 2000s, you had Perl, Python, Java, and PHP. Ruby was playing around the fringes. There had been some attempts at server side JavaScript, but they weren’t well developed or integrated with the frontend the way it is today.
We’re now spoiled for choice, and I see no reason to give PHP any of my time over Elixir, Rust, Go, or TypeScript.
There are a lot of people who think that if a language or framework doesn’t completely disallow bad practices (and of course the authors have to agree with their very specific subjective ideas of what bad practices are) then it sucks. I’ve always found that weird. Like why are you mad at a tool for being “too flexible”? Why not be okay with learning what not to do?
Is there any language that completely disallows bar practices? Even Rust has unsafe{}.
For a long time PHP did suck, because of its easy going type system. Is $user an object? A string? An ID? You’ll find out during runtime! Modern PHP has added enforced type annotations (making PHP objectively better than Javascript) which turned it from “kind of shit” to “pretty good” in an instant.
I think languages can be too flexible. Just look at C and the weird hacks C programmers use to bypass the lack of protections built into the language itself, and the amount of weird stuff you need to know if you want to recognise undefined behaviour. The more flexible your language is, the more experienced programmers you’ll need not to turn the program into a complete mess, which will eventually become a problem when a new team member replaces a greybeard who moved on to another project.
Super flexible languages are great for experimenting and programming as art, but if you’re trying to build functioning software, boring limitations are your friend. It’s why Java is still so popular after all this time: the language looks like it hasn’t changed since 2005 and the code you write is clunky and verbose, but at least it’ll be read readable in ten years when you need to replace the code.
On the flip side, there is VBA which practically enforces bad practices.
Yes
If you’re going to do that, then you also have to have a community that stresses best practices.
In 1999, Perl was leading the world with a tutorial for DBI (its primary database driver interface then and now) that uses placeholders in its very first code example. The community made that the standard, and it was the first hit on “Perl SQL tutorial” on Google for a long time. Perl applications with SQL injection attacks are out there, but have been relatively uncommon.
Notice that the API doesn’t force you to use placeholders. It’s simply strongly encouraged by the community.
Also in 1999, PHP was leading the world in not having a database driver interface through a common API, but rather a thin wrapper over whatever C libraries were used for individual databases. If that database supported placeholders at all (MySQL didn’t, and guess which database was most popular with PHP?), then it often had a different syntax* for every one. (Note that Perl’s DBI uses a translation interface that can implement “?” as a placeholder for you if the underlying DB doesn’t do anything else or uses weird syntax). You could always use a filtering function, and PHP devs would routinely try to write their own rather than use the one that came with the database API that’s already vetted. Either way, there was no widespread community pressure to use safe practices, and PHP led the world in SQL injection vulnerabilities for well over a decade.
*As a side note, I was recently accused by another dev of having a Python app riddled with SQL injection vulnerabilities. In fact, it was well protected, but it was using the psycopg interface to PostgreSQL, and it has a weird placeholder syntax that the other developer wasn’t familiar with. Thanks, psycopg!
An interesting thing you may have missed is that the PHP community actually aggressively removed posts from stack overflow suggesting the old broken autoquoter approach. I’d say that PHP actually has an incredibly security minded community at this point.
I don’t doubt the language has improved. I just don’t see a point when there’s a million other options. In the 90s/early 2000s, you had Perl, Python, Java, and PHP. Ruby was playing around the fringes. There had been some attempts at server side JavaScript, but they weren’t well developed or integrated with the frontend the way it is today.
We’re now spoiled for choice, and I see no reason to give PHP any of my time over Elixir, Rust, Go, or TypeScript.