3 ms·

tl;dr: I value consistency in my tools because it's a great measure of how frequently they'll trip me up and get in my way while reading or writing code. My bi

by eevee 14y ago

tl;dr: I value consistency in my tools because it's a great measure of how frequently they'll trip me up and get in my way while reading or writing code. My biggest problem with PHP above all else, which I tried to write my article around, is that it's an inconsistent jumble from top to bottom. You're absolutely correct, of course, in that you can write decent PHP by avoiding large chunks of the language, memorizing what things act differently from other things that look the same, not trying to do anything too dynamic, adding boilerplate to every project to fix useless default interpreter behavior, and so on. You can also waltz across a minefield if you just remember where all the mines are. But the necessity of doing all these things is exactly my argument: why bother with all this from a tool that's supposed to help you get stuff done? Because it has $_GET out of the box? You can't even claim "ease of learning" as an advantage after all this, because judging by your own responses, much of the language is pitfalls just waiting to trip up beginners who haven't yet learned the right painful lessons. Yes, I'm not a PHP programmer. And as a not-PHP programmer, a lot of PHP looks totally crazy. But when outsiders complain about craziness in Python or Perl or Haskell or whatever, at least that craziness can usually be explained as consistent with the rest of the language, or part of an overall philosophy, or the result of some valuable tradeoff. And if not, we're very sympathetic about the ugly warts on our dearly beloved. Yet all anyone has ever been able to tell me about PHP craziness is "well, you shouldn't do that anyway" or "that's how it is in one of ten other languages" or "I have no explanation but here's a workaround so it's like the problem doesn't actually exist, right". It is hard for me to understand how even someone who loves PHP can't see this as deeply alarming. > You only need distinct operators if your language is weakly typed. I don't dispute that: I claim that having separate addition and concatenation operators, but having a single set of equality/comparison operators, is inconsistent. > Yes, like most ever other language in existence. You know, Java, C#, Python, etc. Incorrect. Python passes everything by reference (value reference, not name reference) because everything is an object. Passing never performs a copy. I'm under the impression that Java is the same. Perl passes by alias, though the aliases are generally then copied to locals, and it has that whole array-flattening behavior which muddies things. > Because all code should be contained within a namespace going forward. Constants should not be defined in the top-level. Everything in Perl is in the `main` namespace unless otherwise specified. One wonders why PHP could not retrofit its new features onto the language like Perl has done for decades, rather than leaving half the language to flounder. > No, it doesn't work that way. You have to explicitly cast. If you use an array type-hint you can only pass an array. I'm assuming you're using the explicit cast inside the hypothetical function. > PHP is also bytecode-interpreted. I'm not really sure what point you're trying to make. You appeared to be citing interpreted-ness as a reason for having a wonky module system. I am naming other interpreted languages with useful module systems as counterexamples. > The fact that is or is not a function is insignificant; you use it the same way. Unless you want to do other function-y things to it, or any of the other pseudo-functions. The syntax is deliberately designed to make you think something is a function, but it only acts like a function in one particular way. (And as a side effect, there are a ton of simple function names you can't use as method names, because the parser gets very confused -- even though this seems like it should be unambiguous.) > Oh, you're saying if you don't provide any of your own error handling and let it spill out the terminal -- yes, you're right -- no stack trace by default. Not that you should be doing that. Defaults matter. This is an atrocious default. > Turn on E_STRICT and it'll tell you. It'll tell me what things I've already done; I can't easily find out what I should be avoiding proactively. > Calling a string literal is pointless! 'test'() is test()! So what? Both are values; why is there any distinction? Hell, you can call methods on numbers in Ruby and Python. I don't care about the practical value here; it's yet another place where PHP is inconsistent for seemingly no reason. > If you've ever complained about security in PHP, you need to give that up right now. Because you just gave everyone a false sense of security. Howso? The problem with mysql_escape_string was that it didn't take the current database handle into account. So: make it take the current database handle into account. It may not have solved everyone's problems, but the exceptions are obvious, and it would have fixed problems for far more people than the actual solution (zero). If you're using multiple handles and passing them around explicitly, you'll have to fix your code either way.

wvenable 14y ago
> I'm under the impression that Java is the same. No, Java is not the same. Scalars not objects in Java and are passed by value. C# is similar, except scalars are value-type objects and are passed by value. > I'm assuming you're using the explicit cast inside the hypothetical function. That's not what we were talking about. It's incredibly hard to have a reasonable conversation about this with you because you clearly only know a very small set of similar languages and have no experience with PHP at all. > You appeared to be citing interpreted-ness as a reason for having a wonky module system. You cited byte-code interpreted as if that's somewhat significant. PHP's module system really isn't very "wonky" -- it works as advertised. But since you don't use it, you wouldn't know. > It'll tell me what things I've already done; I can't easily find out what I should be avoiding proactively. You could read the manual. If you're new to PHP, you'd probably code strictly from the start. > So what? Both are values; why is there any distinction? Most languages make the distinction. Why shouldn't there be? That's really ugly code. > Hell, you can call methods on numbers in Ruby and Python. That's fine. It doesn't mean every language should do the same. Most languages, especially those PHP is based on, do not do that. Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that? > The problem with mysql_escape_string was that it didn't take the current database handle into account. Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what? It picks the first connection as the default and you encode incorrectly? Or if you had a second connection, do you just break all the existing code? What if the second connection doesn't happen every time? Then you're code is broken only every second Wednesday? You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion.
- eevee 14y ago
  > No, Java is not the same. Scalars not objects in Java and are passed by value. How are pass-by-value and pass-by-object distinguishable for immutable values? > That's not what we were talking about. Yes it is. You said (array) as a cast is useful because a function can accept either a single value or an array of values, and the (array) cast will produce an array either way. I contend that doing this doesn't really work, because passing a single value that happens to be an object will cause the function to cast it to an array of the object's contents, which will have fascinating but useless results. > You cited byte-code interpreted as if that's somewhat significant. I only mentioned bytecode for the sake of pedantry: strictly speaking Python isn't interpreted, whereas e.g. shell is. > You could read the manual. I had to do quite a lot of that. It's kind of wordy. :) > Most languages make the distinction. Why shouldn't there be? That's really ugly code. I'm not proposing that people write code like this. I'm objecting to the inconsistency between a value in a variable and a value in source code. Note that, for the same reason, you also can't chain calls like `foo()()`. There ARE good reasons for that: you could return a function name, or a closure, or an object that supports being called. But because the parser doesn't just allow trying to use parentheses on an arbitrary value, this doesn't work. Just like `foo()[]` didn't work until recently, because it too had to be special-cased. > That's fine. It doesn't mean every language should do the same. Most languages, especially those PHP is based on, do not do that. Really? C doesn't have methods. C++ has methods, but string literals are C strings so they have no methods. Perl doesn't consider builtin types to be objects, but if you turn them into objects with `autobox`, methods work equally well on variables and literals. Python allows method calls on literals -- and will let you try to call them, but of course literal strings aren't callable so this won't do anything. It parses, though. Ruby is the same. "foo".equals("bar") is a common Java idiom. What language are you thinking of where there's a distinction made -- in the parser, no less -- between a variable and an expression? > Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that? Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()? > Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what? Then you're screwed no matter what Zend does and still need to fix your code. So the options were: 1. Leave the existing function totally broken. Create a new one with a confusing and even longer name. Make everyone fix their code and remember to use the new function in the future. 2. Fix the issue in-place for the vast majority of existing code. Make the edge cases fix their code by doing the same thing they have to do with every other API function anyway. Optionally, throw a warning when multiple handles exist and mysql_escape_string is called with only one argument. What, then, is the appeal of (1)? > You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion. I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it. I draw a lot of comparisons to Python and Perl because they're in the same family and I know more about their inner workings than anything else. That doesn't mean they're the only languages I've used or the only languages I think are worthwhile. Yes, I picked on a lot of little things. It's the little things that matter. Every language (ahem, most) has function calls, data structures, and loops. What differentiates them is the little day-to-day stuff. So what am I missing? What makes these design decisions good, what makes PHP great? I've heard a lot of defenses and a lot of statistics, but not too many outright advantages. Most of your original response is just workarounds, not reasons why the behavior is good or even acceptable. The image I'm left with is that of an overgrown playground filled with active mines, but most of the mines have upturned buckets over them so you probably won't step on them, and that's supposed to make it a great place to send your kids. If even PHP's supporters can do no better than explain how to write passable PHP when I have a gun to my head, why would I want to use it?

by eevee 14y ago

wvenable 14y ago

> I'm under the impression that Java is the same. No, Java is not the same. Scalars not objects in Java and are passed by value. C# is similar, except scalars are value-type objects and are passed by value. > I'm assuming you're using the explicit cast inside the hypothetical function. That's not what we were talking about. It's incredibly hard to have a reasonable conversation about this with you because you clearly only know a very small set of similar languages and have no experience with PHP at all. > You appeared to be citing interpreted-ness as a reason for having a wonky module system. You cited byte-code interpreted as if that's somewhat significant. PHP's module system really isn't very "wonky" -- it works as advertised. But since you don't use it, you wouldn't know. > It'll tell me what things I've already done; I can't easily find out what I should be avoiding proactively. You could read the manual. If you're new to PHP, you'd probably code strictly from the start. > So what? Both are values; why is there any distinction? Most languages make the distinction. Why shouldn't there be? That's really ugly code. > Hell, you can call methods on numbers in Ruby and Python. That's fine. It doesn't mean every language should do the same. Most languages, especially those PHP is based on, do not do that. Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that? > The problem with mysql_escape_string was that it didn't take the current database handle into account. Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what? It picks the first connection as the default and you encode incorrectly? Or if you had a second connection, do you just break all the existing code? What if the second connection doesn't happen every time? Then you're code is broken only every second Wednesday? You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion.

eevee 14y ago
> No, Java is not the same. Scalars not objects in Java and are passed by value. How are pass-by-value and pass-by-object distinguishable for immutable values? > That's not what we were talking about. Yes it is. You said (array) as a cast is useful because a function can accept either a single value or an array of values, and the (array) cast will produce an array either way. I contend that doing this doesn't really work, because passing a single value that happens to be an object will cause the function to cast it to an array of the object's contents, which will have fascinating but useless results. > You cited byte-code interpreted as if that's somewhat significant. I only mentioned bytecode for the sake of pedantry: strictly speaking Python isn't interpreted, whereas e.g. shell is. > You could read the manual. I had to do quite a lot of that. It's kind of wordy. :) > Most languages make the distinction. Why shouldn't there be? That's really ugly code. I'm not proposing that people write code like this. I'm objecting to the inconsistency between a value in a variable and a value in source code. Note that, for the same reason, you also can't chain calls like `foo()()`. There ARE good reasons for that: you could return a function name, or a closure, or an object that supports being called. But because the parser doesn't just allow trying to use parentheses on an arbitrary value, this doesn't work. Just like `foo()[]` didn't work until recently, because it too had to be special-cased. > That's fine. It doesn't mean every language should do the same. Most languages, especially those PHP is based on, do not do that. Really? C doesn't have methods. C++ has methods, but string literals are C strings so they have no methods. Perl doesn't consider builtin types to be objects, but if you turn them into objects with `autobox`, methods work equally well on variables and literals. Python allows method calls on literals -- and will let you try to call them, but of course literal strings aren't callable so this won't do anything. It parses, though. Ruby is the same. "foo".equals("bar") is a common Java idiom. What language are you thinking of where there's a distinction made -- in the parser, no less -- between a variable and an expression? > Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that? Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()? > Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what? Then you're screwed no matter what Zend does and still need to fix your code. So the options were: 1. Leave the existing function totally broken. Create a new one with a confusing and even longer name. Make everyone fix their code and remember to use the new function in the future. 2. Fix the issue in-place for the vast majority of existing code. Make the edge cases fix their code by doing the same thing they have to do with every other API function anyway. Optionally, throw a warning when multiple handles exist and mysql_escape_string is called with only one argument. What, then, is the appeal of (1)? > You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion. I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it. I draw a lot of comparisons to Python and Perl because they're in the same family and I know more about their inner workings than anything else. That doesn't mean they're the only languages I've used or the only languages I think are worthwhile. Yes, I picked on a lot of little things. It's the little things that matter. Every language (ahem, most) has function calls, data structures, and loops. What differentiates them is the little day-to-day stuff. So what am I missing? What makes these design decisions good, what makes PHP great? I've heard a lot of defenses and a lot of statistics, but not too many outright advantages. Most of your original response is just workarounds, not reasons why the behavior is good or even acceptable. The image I'm left with is that of an overgrown playground filled with active mines, but most of the mines have upturned buckets over them so you probably won't step on them, and that's supposed to make it a great place to send your kids. If even PHP's supporters can do no better than explain how to write passable PHP when I have a gun to my head, why would I want to use it?