3 ms·

> I mean, who uses mysql_real_escape_string when you have PDO and bindings ? You've made my point. A person with tribal knowledge probably would NOT. Any new u

> I mean, who uses mysql_real_escape_string when you have PDO and bindings ? You've made my point. A person with tribal knowledge probably would NOT. Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date. Furthermore, the more precise point I was trying to make there was as a language designer, how on earth would you be okay implementing something like that? (Remove my example of `mysql_read_escape_string()` and insert any of the more WTF features of PHP. Lastly, see my comment about being able to build meaningful, fast, cool things with PHP. I never want to tear down anyone's hard work. (Rasmus/Zeev/etc included).

spacedcowboy 6y ago
Um, I'd criticize a C++ programmer who didn't know anything about the STL as well. Sure, you don't need to know the STL to write C++, but it's an odd decision. If you're going to use a tool, you have to learn it if you want the job done properly. PHP is old and carries some cruft along with it for compatibility reasons (I suppose). When mysql_* was implemented, the world was a gentler place, and SQL injection wasn't really a thing (or at least, known to be a thing). What you're really complaining about there is "they didn't throw away the stuff that doesn't work well today". That's a decision I can see going either way. [aside] Having said that, the number of interviews I do where the candidate, poorly, attempts to write me code that implements what could have been done with std::vector is crushingly disappointing. [/aside]
- btilly 6y ago
  I agree that the population of programmers who knew about SQL injection was much smaller, but it was certainly widely understood by people who cared. I believe that msql_* were implemented in PHP 3.0, in 1998. By comparison Perl's DBI was first released in 1994, with placeholders and an explanation of why they were important. Of course the idea wasn't original to DBI, the feature was based on an existing Oracle feature known as bind variables that I know was available and recommended with Oracle 7 in 1992. (I don't know if it was there before. It might have been.) So there was certainly no attempt to figure out best practices on the part of PHP. And compared to the other injection attacks that proliferated in PHP in this time frame, the mysql functions were practically sane.
  - DonHopkins 6y ago
    >but it was certainly widely understood by people who cared. Rasmus Lerdorf and the early-to-mid PHP community simply didn't care. As you can see by the quotes I posted in another comment, Rasmus Lerdorf actually brags about how much he doesn't care. It's a textbook example of anti-intellectualism. https://en.wikipedia.org/wiki/Anti-intellectualism https://en.wikipedia.org/wiki/Anti-intellectualism What the early-to-mid PHP community cared about, and was extremely successful at, was evangelism, and recruiting as many new inexperienced developers as possible. That didn't mix well with all the foot-guns and design flaws they carelessly built into the language, and left in for far too many long years. Along the axis of care, PHP is the opposite of Java. Compare PHP's complete lack of design with how carefully and conscientiously Java was designed (I may not agree with all of Java's design decisions, but at least they're all carefully researched, thought out, and debated to death first): https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 >"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling
lowercased 6y ago
https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st... Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no? > Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date You could mostly get that from going to the PHP doc site itself, which would indicate things that are deprecated. Or your IDE might tell you. Or, for things that are really out of date, like mysql_real_escape_string, they simply ... aren't in the language any more, having been removed completely from PHP7 several years ago. If someone is starting brand new today using a blog post walking them through setting up PHP5... they'll have much bigger problems. There's a shitload of 'tribal knowledge' around stuff in many languages - you find out a lot of that stuff via searching. If I read an 'older blog post' on Go from 2015, and complained that my Go didn't work very well (or was insecure, or whatever), how much blame should the language itself take?
- 14u2c 6y ago
  > Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no? Don't most ecosystems use some type of namespace for that instead of exposing everything as global functions? Those practices were quite late to the PHP community.

spacedcowboy 6y ago

Um, I'd criticize a C++ programmer who didn't know anything about the STL as well. Sure, you don't need to know the STL to write C++, but it's an odd decision. If you're going to use a tool, you have to learn it if you want the job done properly. PHP is old and carries some cruft along with it for compatibility reasons (I suppose). When mysql_* was implemented, the world was a gentler place, and SQL injection wasn't really a thing (or at least, known to be a thing). What you're really complaining about there is "they didn't throw away the stuff that doesn't work well today". That's a decision I can see going either way. [aside] Having said that, the number of interviews I do where the candidate, poorly, attempts to write me code that implements what could have been done with std::vector is crushingly disappointing. [/aside]

btilly 6y ago
I agree that the population of programmers who knew about SQL injection was much smaller, but it was certainly widely understood by people who cared. I believe that msql_* were implemented in PHP 3.0, in 1998. By comparison Perl's DBI was first released in 1994, with placeholders and an explanation of why they were important. Of course the idea wasn't original to DBI, the feature was based on an existing Oracle feature known as bind variables that I know was available and recommended with Oracle 7 in 1992. (I don't know if it was there before. It might have been.) So there was certainly no attempt to figure out best practices on the part of PHP. And compared to the other injection attacks that proliferated in PHP in this time frame, the mysql functions were practically sane.
- DonHopkins 6y ago
  >but it was certainly widely understood by people who cared. Rasmus Lerdorf and the early-to-mid PHP community simply didn't care. As you can see by the quotes I posted in another comment, Rasmus Lerdorf actually brags about how much he doesn't care. It's a textbook example of anti-intellectualism. https://en.wikipedia.org/wiki/Anti-intellectualism https://en.wikipedia.org/wiki/Anti-intellectualism What the early-to-mid PHP community cared about, and was extremely successful at, was evangelism, and recruiting as many new inexperienced developers as possible. That didn't mix well with all the foot-guns and design flaws they carelessly built into the language, and left in for far too many long years. Along the axis of care, PHP is the opposite of Java. Compare PHP's complete lack of design with how carefully and conscientiously Java was designed (I may not agree with all of Java's design decisions, but at least they're all carefully researched, thought out, and debated to death first): https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 >"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling

lowercased 6y ago

https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st... Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no? > Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date You could mostly get that from going to the PHP doc site itself, which would indicate things that are deprecated. Or your IDE might tell you. Or, for things that are really out of date, like mysql_real_escape_string, they simply ... aren't in the language any more, having been removed completely from PHP7 several years ago. If someone is starting brand new today using a blog post walking them through setting up PHP5... they'll have much bigger problems. There's a shitload of 'tribal knowledge' around stuff in many languages - you find out a lot of that stuff via searching. If I read an 'older blog post' on Go from 2015, and complained that my Go didn't work very well (or was insecure, or whatever), how much blame should the language itself take?

14u2c 6y ago
> Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no? Don't most ecosystems use some type of namespace for that instead of exposing everything as global functions? Those practices were quite late to the PHP community.