|
Gazpacho posted:While I understand that there are many design horrors in PHP, and to a lesser extent Javascript, this hand-wringing over implicit conversion reminds me of the arguments when I was learning BASIC against using = for assignment (as well as comparison), because some poor stupid programmer might flip out over a statement like X = X + 1. There are people who freak out over that kind of statement. They don't go on to become programmers. It is lovely syntax though, assignment should be done like this: MOV X, X + 1.
|
# ? Sep 2, 2012 15:03 |
|
|
# ? Jun 5, 2024 05:51 |
|
What kind of a noob language are you using that has assignment?
|
# ? Sep 2, 2012 15:55 |
|
geonetix posted:You can already do it that way by using the "go-to" operator: Except when it violates its own prototype, like the money_format "bug" mentioned a few weeks ago. Then out selectively chooses not to coerce, without warning.
|
# ? Sep 2, 2012 16:11 |
|
The money_format one is a bit more complex, it used to coerce and then stop doing it. I'm not sure about that as I'm writing this from memory, but it was something incredibly stupid like that going on there. My point just was that you have to learn what your language does when you want to use it for anything larger than displaying the result of 1+1.
|
# ? Sep 2, 2012 16:44 |
|
geonetix posted:My point just was that you have to learn what your language does when you want to use it for anything larger than displaying the result of 1+1. And my point is, some languages act logically, and don't decide to, one day, without any warning or notice, stop coercing types for a single function and then blame the user for not verifying he was passing a proper value to the function. I don't know if PHP is unique in this regard, or even rare, but that doesn't mean it's right or smart. So, I have to learn it, yes, but that implies that what I've learned doesn't randomly change. When it does, that's no longer my fault, and is entirely worthy of complaint.
|
# ? Sep 2, 2012 17:26 |
|
geonetix posted:My point just was that you have to learn what your language does when you want to use it for anything larger than displaying the result of 1+1. Wow, that's so insightful. You should start a blog, man. I don't even get your point unless its just the trivially obvious point that to use a language you have to know it, and if that's your point I don't know why you bothered typing it out. If your point is to excuse it, then that's loving retarded because that excuses any retarded language design. edit: That came off more abrasive than it should. I'm irritable this morning. Thermopyle fucked around with this message at 18:08 on Sep 2, 2012 |
# ? Sep 2, 2012 17:53 |
|
It's unprovable, but I'm pretty sure there is no language feature so terrible that you cannot find apologists for it.
|
# ? Sep 2, 2012 18:47 |
|
Now I want to write a language where a side effect of the addition operator is that a file on your hard drive is chosen at random and deleted. Just to see what apologists would come up with.
|
# ? Sep 2, 2012 18:50 |
|
carry on then posted:Now I want to write a language where a side effect of the addition operator is that a file on your hard drive is chosen at random and deleted. Just to see what apologists would come up with. It's pretty good for doing spring cleaning on your hard drive. You never get around to doing it yourself anyway. Besides, for anything important you would have external backups, so you can't really lose anything you couldn't live without if you're at all sensible.
|
# ? Sep 2, 2012 19:04 |
|
carry on then posted:Now I want to write a language where a side effect of the addition operator is that a file on your hard drive is chosen at random and deleted. Just to see what apologists would come up with. No one is forcing you to use the addition operator. Instead of 1 + 2 you can simply do 1 - -2 instead.
|
# ? Sep 2, 2012 19:10 |
|
carry on then posted:Now I want to write a language where a side effect of the addition operator is that a file on your hard drive is chosen at random and deleted. Just to see what apologists would come up with. It's a logical extension of the Chaos Monkey concept. It encourages the development of fault-tolerant operating systems and robust security models.
|
# ? Sep 2, 2012 19:25 |
|
Thermopyle posted:Wow, that's so insightful. You should start a blog, man. My point is that this kind of idiotic behaviour is indeed very commog in PHP and I reckon you have to know about it. The sudden number_format example excluded, because changing functionality without warning or anything is beyond comprehension. I was personally still going on about the whole 'lol "0.00" == 0' thing. quote:If your point is to excuse it, then that's loving retarded because that excuses any retarded language design. No excusing it, just wondering why people are still amazed this happens.
|
# ? Sep 2, 2012 20:32 |
|
carry on then posted:Now I want to write a language where a side effect of the addition operator is that a file on your hard drive is chosen at random and deleted. Just to see what apologists would come up with.
|
# ? Sep 2, 2012 20:40 |
|
geonetix posted:My point is that this kind of idiotic behaviour is indeed very common in PHP and I reckon you have to know about it. The sudden number_format example excluded, because changing functionality without warning or anything is beyond comprehension. I was personally still going on about the whole 'lol "0.00" == 0' thing. I don't think anybody's amazed it happens, I at least have come to terms with the fact that PHP is utter rubbish. What is amazing is how utterly rubbish it is and in what ways, like the whole number_format thing, or the eternally popular "lol 0 =='0.00'", which I agree is starting to drag a little bit. As far as your point goes, that PHP is acceptable so long as you're aware of its many failings and idiosyncrasies, the bastard offspring of a Yugo and a Ford Pinto would be a perfectly acceptable car, get you wherever you need to go so long as you remain aware of its idiosyncrasies. I'd still drop it in favor of a car that doesn't explode or break down every mile, and I'd drop PHP for a language that doesn't violate common sense and logic.
|
# ? Sep 2, 2012 23:15 |
|
geonetix posted:My point is that this kind of idiotic behaviour is indeed very commog in PHP and I reckon you have to know about it. The sudden number_format example excluded, because changing functionality without warning or anything is beyond comprehension. I was personally still going on about the whole 'lol "0.00" == 0' thing. I don't think (hope?) anyone is going around telling everyone how amazed they are at PHP's wackiness. This is the Coding Horrors thread, an appropriate place to post Coding Horrors.
|
# ? Sep 2, 2012 23:18 |
|
darthbob88 posted:I don't think anybody's amazed it happens, I at least have come to terms with the fact that PHP is utter rubbish. What is amazing is how utterly rubbish it is and in what ways, like the whole number_format thing, or the eternally popular "lol 0 =='0.00'", which I agree is starting to drag a little bit. I don't mind '0.00' equaling 0. What I mind is the intransitivity of type coercions, that 0 = false but '0.00' = true.
|
# ? Sep 3, 2012 00:15 |
|
Golbez posted:I don't mind '0.00' equaling 0. What I mind is the intransitivity of type coercions, that 0 = false but '0.00' = true. Then ensure all if-statements use a boolean value instead of relying on type coercion, like Java. It's a questionable design choice, but there are valid reasons why PHP's type coercion leads to intransitivity, so as long as one knows about it, it shouldn't be a major drama.
|
# ? Sep 3, 2012 00:42 |
Golbez posted:I don't mind '0.00' equaling 0. What I mind is the intransitivity of type coercions, that 0 = false but '0.00' = true. The correct way to do it is having every value except nil and boolean false evaluate as true.
|
|
# ? Sep 3, 2012 00:50 |
|
nielsm posted:The correct way to do it is having every value except nil and boolean false evaluate as true. Every type has a 0 value which evaluates to false. The only real inconsistency is that "0" is coerced to an integer. I think there's a certain merit to Java's strategy of "MUST BE A BOOLEAN," because otherwise you end up with weird personal interpretations of what does and doesn't make sense. One of the problems with PHP is that it's easy to write awful code, but the same is true in some degree for every language. The solution is to proactively use good coding practices to avoid writing lovely code, even if the language will allow you to do it.
|
# ? Sep 3, 2012 01:38 |
|
I thought this was the coding horrors thread, not the language debate thread.
|
# ? Sep 3, 2012 03:13 |
|
Jabor posted:I thought this was the coding horrors thread, not the language debate thread. Tomato, tomato. One man's feature is another man's shambling horror, somebody else's idea of the Right Way to Do It is always wrong and horrifying. Speaking of, encoding options and flags in prime factorizations: good idea, or best idea?
|
# ? Sep 3, 2012 07:46 |
|
darthbob88 posted:Tomato, tomato. One man's feature is another man's shambling horror, somebody else's idea of the Right Way to Do It is always wrong and horrifying. Speaking of, encoding options and flags in prime factorizations: good idea, or best idea? Best idea, especially if you don't document it and have wildly disparate options under the same prime 'key'.
|
# ? Sep 3, 2012 10:12 |
|
Has some government started funding people to defend PHP (and Yugos) on the internet or something?
|
# ? Sep 3, 2012 12:44 |
|
I'm not sure if this is a horror or not, but I just wrote a testcase:JavaScript code:
So, I'm going:
|
# ? Sep 4, 2012 09:32 |
|
Zombywuf posted:There are people who freak out over that kind of statement. They don't go on to become programmers. Due to the influence of BCPL and B, in the earliest version of C, the & and | operators could either be bitwise operators that evaluate both arguments or short-circuiting logical operators depending on context. Ritchie added the && and || operators to clear things up, but there was already code that depended on & and | having lower precedence than == so operator precedence in C has been hosed ever since. So no, it's not just people who "don't go on to become programmers" who worry about identical expressions having different semantics due to context. And let's not even get started about IF IF = THEN THEN THEN = ELSE; ELSE ELSE = THEN; being a valid PL/I statement.
|
# ? Sep 4, 2012 10:25 |
|
that awful man posted:And let's not even get started about IF IF = THEN THEN THEN = ELSE; ELSE ELSE = THEN; being a valid PL/I statement. And #define if fuckYouMaintenanceProgammer is valid C.
|
# ? Sep 4, 2012 13:31 |
|
code:
|
# ? Sep 4, 2012 15:01 |
|
In C++, stick this in a global/force include:code:
|
# ? Sep 4, 2012 15:10 |
|
MarsMattel posted:In C++, stick this in a global/force include: I've seen that and in the same file was: code:
|
# ? Sep 4, 2012 15:16 |
|
I first heard of it being used to help a script system integrate with a game. Something about the scripting system needing access to data it otherwise wouldn't be able to access...
|
# ? Sep 4, 2012 16:04 |
|
MarsMattel posted:In C++, stick this in a global/force include: What good is that without code:
|
# ? Sep 4, 2012 16:49 |
|
I always found the best way to screw with someones code to becode:
code:
|
# ? Sep 4, 2012 23:45 |
|
I've always been partial to Lisp code:
|
# ? Sep 4, 2012 23:53 |
|
tractor fanatic posted:What good is that without Unlike some of the others, thats vaguely legit if you're doing unit tests.
|
# ? Sep 5, 2012 00:34 |
|
Golbez posted:I don't mind '0.00' equaling 0. What I mind is the intransitivity of type coercions, that 0 = false but '0.00' = true. I'd really be interested in seeing some real, in-the-wild example of how this tripped someone up. People complain about it a lot, but PHP type coercion has never done anything but save me time.
|
# ? Sep 5, 2012 02:21 |
|
Bug #54547: wrong equality of string numbersquote:I'm just gonna paste in that PHP Sadness article to show why this is such a big Comparing two strings and finding that they're tested for numeric equality is utterly ridiculous.
|
# ? Sep 5, 2012 02:55 |
|
code:
|
# ? Sep 5, 2012 02:55 |
|
Lysidas posted:Bug #54547: wrong equality of string numbers Apparently just '0xFF' == '255' is true. That is absurd.
|
# ? Sep 5, 2012 03:14 |
|
Tiny Bug Child posted:I'd really be interested in seeing some real, in-the-wild example of how this tripped someone up. People complain about it a lot, but PHP type coercion has never done anything but save me time. I had a function to query sums from a database, and then, based on a flag passed to the function, either include only non-zero sums or zero sums. Yes, in retrospect I suppose this could have been done several ways, like in the query itself, but eh. So I decided, for 'include non-zeros', to loop through and use array_filter() without a callback, to trim out all the zero entries. However, because the MySQL field I was summing was a DECIMAL, the SUM() function was returning "0.00" rather than "0", as I was used to. Since "0" coerces into false, but "0.00" coerces into true, array_filter() wasn't removing things properly. This did not get pushed live, thankfully, so it fails your "in the wild" criteria, but it came close. My initial solution was to cast the output to float, then run array_filter(), then I said screw it and wrote "if ($Row['sum'] == 0)", which still hurts my soul. Why that instead of "=== '0.00'"? Because I didn't want to trust it to always only return two decimal places, and I was annoyed with it. There's a lot of stuff I can change in retrospect as I write this, but it still annoyed me. I don't mind PHP's type coercion, there's times when I rather like it, but what I don't like is the random way in which its internal functions respect this, and I don't like the intransitivity of it. Maybe "0.00" should evaluate to false, as should ".00" and any number of zeros before and after the decimal. Also, give us a money-safe decimal type, rather than having to rely on the bcmath extension.
|
# ? Sep 5, 2012 03:24 |
|
|
# ? Jun 5, 2024 05:51 |
|
Suspicious Dish posted:Apparently just '0xFF' == '255' is true. That is absurd. Can we all agree that, when comparing two items of the same type, that there should never be any coercion performed when comparing them?
|
# ? Sep 5, 2012 03:26 |