5 ms·

I mean, who uses mysql_real_escape_string when you have PDO and bindings ? PHP isn’t perfect. As OP said, no language is, and any competent software engineer u

I mean, who uses mysql_real_escape_string when you have PDO and bindings ? PHP isn’t perfect. As OP said, no language is, and any competent software engineer uses the parts of the language that work well for them, and just ignores the things that don’t work for them. I don’t believe for a second that the abuse the language has suffered over the years has anything to do with mysql_real_escape_string, it’s more to do with crappy code. You can write crappy code in any language, and it’s more a reflection of the programmer than the programming language IMHO. Part of PHP’s problem is that it’s so easy to use. Any C programmer can pick up the basics pretty easily, hack together something that scratches an itch, and move on. Later someone will criticize the quick hack and say “you didn’t use mysql_real_escape_string so that code has a SQL vulnerability. Don’t use PHP”. In reality, there are mechanisms for preventing SQL injection and they just weren’t used. Is that a failing of the language ? Partly, perhaps, for providing the unsafe way of doing things, but a lot of blame also lies with the coder. I’ll admit to a soft spot for PHP - I was putting database-driven websites on the web when that wasn’t much of a thing (back in 1981, if foggy memory recalls true). I wrote the asset management system that was used by Lucasfilm on Star Wars, by Manix on the Matrix, by various post-production houses in Soho, etc. etc. - all in PHP. We had video-streaming from remote locations before RealNetworks were mainstream. All because of PHP. I also used PHP to write a content management system for the RiskWaters Group - around 100 magazines in the CMS, with forums, mailmerge, access-rights per page or per view-count or per time-period, with back-end admin pages, with macros the editors could use, etc. etc. Used properly and judiciously, PHP is a powerful tool. It comes with a few areas that ought to be marked ‘here be dragons’, but frankly so do most languages. These days, I mostly use PHP for shell-scripting (it comes installed as standard on my Mac), nothing so grandiose as the halcyon days of yore, but I still have PHP to thank for getting the job I’ve had for the last 15 years, in R&D at Apple (“these are the guys that Lucas was talking about”, said the VP who bought my small company). I’ll finish with a line from a song “Baby, life’s what you make it, celebrate it”. That applies to PHP as well.

ragnese 6y ago
You're using the two super-fallacious arguments I refer to in my original reply: 1. You can write bad code in any language. 2. All languages have warts. My response to #1: Here is a rock. Please use it, with some nails, to hang a bunch of pictures on your walls. Don't complain about your tool because it's entirely possible to use it successfully at this task. Or, less sarcastically, why use a tool that encourages bad results when you can use a tool that nudges you toward better results? My response to #2: Would you rather have one wart, or 100 warts?
- spacedcowboy 6y ago
  Not really. As I thought I'd alluded to in the above, when I was using PHP "in anger" as it were, there were 3 options for dynamic content: 1) Write a C program, and use the GCI-BIN interface. In developmental terms, this sucked dead bunnies through thin straws 2) Use some god-awful server-side script thing, updating static files with externally-invoked changes. Yes, people resorted to this. 3) Use PHP/FI. Life is now harmonious and (relatively) pain-free. There was Cold Fusion, but it was Windows-only. The sane world, at the time, wouldn't serve websites on windows software unless there was a dedicated uptime team involved. One of these was clearly the better solution. For things it didn't do, it was easy to extend (I wrote the PHP database support for Illustra, a now-defunct object-orientated database that we used) These days I use it for shell-scripts, and I can bash out something that I need/want in much shorter time (basically because of the enormous standard library) than using any of the other options. My criterion here is "a text editor and 10 minutes"... There are some, very modern, languages that it takes 10 minutes to spin up the IDE and set up the damn project...
  - ragnese 6y ago
    You're moving the goalposts. PHP was a great option in 1995. It is not today (except as a basic scripting language, where you and I agree completely. I would use PHP as soon as my bash script gets to about 100 lines). Your post here is arguing about 1995 or whatever. The post I replied to was full of present-tense about "just use the good parts" and "all languages have issues", etc.
    - spacedcowboy 6y ago
      That's ... fair comment. My apologies, I have a bad habit of not clicking on parent to see what the context of a post is.
      - deleted 6y ago
        [deleted]
    - DonHopkins 6y ago
nobleach 6y ago
> 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
1981? The title of the article is "25 Years of PHP", which checks out because PHP appeared in 1995, and this is 2020, and 2020-1995=25, but 1981 was 39 years ago. The ARPANET was using NCP with 8 bit host IDs in 1981, and nobody was listening for the HTTP protocol on port 80 back then, and homosocketuality was still prohibited. https://news.ycombinator.com/item?id=14178993 https://news.ycombinator.com/item?id=14178993 >The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2]. https://www.saildart.org/allow/IMPSER.DOC%5bSS,SYS%5d https://www.saildart.org/allow/IMPSER.DOC%5bSS,SYS%5d >Illegal gender in RFC, host hhh/iii, link 0 >The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.
- spacedcowboy 6y ago
  Yup. My bad. I started trying to figure out when it was by when I was at college, how long I did the PhD for, how long I was in the first job, how long into the second job I started using it and I screwed up the maths along the way. It was in 1996, not 1981... No excuses, that's just bad.
  - DonHopkins 6y ago
    You also said you wrote the asset management system that was used by Lucasfilm on Star Wars, which was released in 1977. Are you sure you don't mean one of the later J. J. Abrams films, and not the film whose title was actually "Star Wars"? Mistakes about dates and context aside, I still can't believe you're actually trying to make excuses for mysql_real_escape_string. It has the word "real" in it. I mean, come on, who would ever name a function "real", and why? That implies the existance of a not-so-real mysql escape string function. Why didn't they simply FIX the gaping security hole in the not-so-real mysql escape string function, instead of maintaining one that was real that you should use, and one that was not so real that you should definitely not use, in the name of backwards compatibility? Or were there actually people out there using the non-real mysql escape string function, and they didn't want to ruffle their feathers by forcing those people with code that had a security hole so big you could fly a space shuttle through to fix their gaping security holes? The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the not-so-recent PHP community. And you shouldn't be making excuses for it, or blaming it on the wrong people for using it, instead of the right people for creating it then evangelizing it then not fixing it. It was a TERRIBLE mistake. The crappy code was PHP itself, and the code was crappy because the culture was crappy. I'm not going to start linking to all the anti-intellectual Rasmus quotes, or to the bug report about the time he checked in huge security regression to the crypto code that would have been caught by the tests, and then CUT A RELEASE, but didn't bother running the tests first because they produced so many errors. But you can google that debacle yourself.
NOGDP 6y ago
> Used properly and judiciously, PHP is a powerful tool. What is a 'powerful' programming language?
- type0 6y ago
  LISP

ragnese 6y ago

You're using the two super-fallacious arguments I refer to in my original reply: 1. You can write bad code in any language. 2. All languages have warts. My response to #1: Here is a rock. Please use it, with some nails, to hang a bunch of pictures on your walls. Don't complain about your tool because it's entirely possible to use it successfully at this task. Or, less sarcastically, why use a tool that encourages bad results when you can use a tool that nudges you toward better results? My response to #2: Would you rather have one wart, or 100 warts?

spacedcowboy 6y ago
Not really. As I thought I'd alluded to in the above, when I was using PHP "in anger" as it were, there were 3 options for dynamic content: 1) Write a C program, and use the GCI-BIN interface. In developmental terms, this sucked dead bunnies through thin straws 2) Use some god-awful server-side script thing, updating static files with externally-invoked changes. Yes, people resorted to this. 3) Use PHP/FI. Life is now harmonious and (relatively) pain-free. There was Cold Fusion, but it was Windows-only. The sane world, at the time, wouldn't serve websites on windows software unless there was a dedicated uptime team involved. One of these was clearly the better solution. For things it didn't do, it was easy to extend (I wrote the PHP database support for Illustra, a now-defunct object-orientated database that we used) These days I use it for shell-scripts, and I can bash out something that I need/want in much shorter time (basically because of the enormous standard library) than using any of the other options. My criterion here is "a text editor and 10 minutes"... There are some, very modern, languages that it takes 10 minutes to spin up the IDE and set up the damn project...
- ragnese 6y ago
  You're moving the goalposts. PHP was a great option in 1995. It is not today (except as a basic scripting language, where you and I agree completely. I would use PHP as soon as my bash script gets to about 100 lines). Your post here is arguing about 1995 or whatever. The post I replied to was full of present-tense about "just use the good parts" and "all languages have issues", etc.
  - spacedcowboy 6y ago
    That's ... fair comment. My apologies, I have a bad habit of not clicking on parent to see what the context of a post is.
    - deleted 6y ago
      [deleted]
  - DonHopkins 6y ago

nobleach 6y ago

> 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

1981? The title of the article is "25 Years of PHP", which checks out because PHP appeared in 1995, and this is 2020, and 2020-1995=25, but 1981 was 39 years ago. The ARPANET was using NCP with 8 bit host IDs in 1981, and nobody was listening for the HTTP protocol on port 80 back then, and homosocketuality was still prohibited. https://news.ycombinator.com/item?id=14178993 https://news.ycombinator.com/item?id=14178993 >The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2]. https://www.saildart.org/allow/IMPSER.DOC%5bSS,SYS%5d https://www.saildart.org/allow/IMPSER.DOC%5bSS,SYS%5d >Illegal gender in RFC, host hhh/iii, link 0 >The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.

spacedcowboy 6y ago
Yup. My bad. I started trying to figure out when it was by when I was at college, how long I did the PhD for, how long I was in the first job, how long into the second job I started using it and I screwed up the maths along the way. It was in 1996, not 1981... No excuses, that's just bad.
- DonHopkins 6y ago
  You also said you wrote the asset management system that was used by Lucasfilm on Star Wars, which was released in 1977. Are you sure you don't mean one of the later J. J. Abrams films, and not the film whose title was actually "Star Wars"? Mistakes about dates and context aside, I still can't believe you're actually trying to make excuses for mysql_real_escape_string. It has the word "real" in it. I mean, come on, who would ever name a function "real", and why? That implies the existance of a not-so-real mysql escape string function. Why didn't they simply FIX the gaping security hole in the not-so-real mysql escape string function, instead of maintaining one that was real that you should use, and one that was not so real that you should definitely not use, in the name of backwards compatibility? Or were there actually people out there using the non-real mysql escape string function, and they didn't want to ruffle their feathers by forcing those people with code that had a security hole so big you could fly a space shuttle through to fix their gaping security holes? The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the not-so-recent PHP community. And you shouldn't be making excuses for it, or blaming it on the wrong people for using it, instead of the right people for creating it then evangelizing it then not fixing it. It was a TERRIBLE mistake. The crappy code was PHP itself, and the code was crappy because the culture was crappy. I'm not going to start linking to all the anti-intellectual Rasmus quotes, or to the bug report about the time he checked in huge security regression to the crypto code that would have been caught by the tests, and then CUT A RELEASE, but didn't bother running the tests first because they produced so many errors. But you can google that debacle yourself.

NOGDP 6y ago

> Used properly and judiciously, PHP is a powerful tool. What is a 'powerful' programming language?

type0 6y ago
LISP