8 ms·

Ah, an obscure point of absurdity which utterly kills my pending interest in the language. If this sort of thing exists under the hood, revealed only by a detai

Ah, an obscure point of absurdity which utterly kills my pending interest in the language. If this sort of thing exists under the hood, revealed only by a detailed analysis of the specification, what other nonsense is there? Going so far as analyzing a string to determine whether it consists entirely of numbers for the non-sequitur process of then and only then converting it to what it isn't for logical evaluation is working pretty hard to do something counter-intuitive; might be tolerable if it actually preserved all digits, but not only does it work hard to convert a string to an integer, it then converts large integers in to floating-point values - not just one, but two layers of explicitly undesired and unnecessary and unreasonable typecasting. I'm currently working with barcodes: numerical strings from 6 to 55 digits. In no way can I risk having one barcode be evaluated as equal to a literally different barcode just because the symbols in that string just happen to exhibit a passing resemblance to data of a different type. Again, it's not just that it has loose typing. It's that it's taking what is OBVIOUSLY a string, converting it to an integer, THEN converting it to yet another data type which imposes data loss. Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you... ETA: Oh, I'd love to know the justification for the downvoting.

hackermom 15y ago
"Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you..." Have you been out on the internet the past decade? Do you have a tendency to make extremities of things and trying to stand the needle on its tip?
- ctdonath 15y ago
  It throws away data on an obtuse, obscurely-documented, whim. Making extremes? My medical application would fail FDA approval in minutes if ported to PHP precisely because of this issue.
  - luser001 15y ago
    All languages have their idiosyncrasies. You can pick out some obscure aspect of any language and say $LANG sucks. Btw, PHP's behavior doesn't totally make sense to me either. But I'm willing to assume that its users and designers have thought this through and it makes sense for PHP's intended use cases, because I don't know PHP. Javascript (which most people on HN seem to like) also has similar issues (null vs. undefined, == and === etc). It got so bad that "Javascript: the good parts" had to be written to define a de-facto sane subset of the language. People are actually writing in Coffeescript (in part) to avoid Javascript's pitfalls. YMMV.
  - Groxx 15y ago
    "obscurely-documented"? That seems pretty clear to me, given that it's a fundamental feature of the language, and documented (floating point problems too) in an obvious location.
  - tedunangst 15y ago
    Would your medical application fail FDA approval if you used a language like C or C++ that contained strncmp? Because that function throws away data, too.
    - ctdonath 15y ago
      There's a difference between strncmp existing precisely so you can specify how many characters to compare, vs. throwing away trailing characters in a string just because, by sheer chance, it contains only numerics.
  - eli 15y ago
    Your medical application should probably be using === for comparisons. I'm not defending PHP's language design, but I think it's pretty well known among professional PHP developers that you should almost always use === and avoid implicit type conversions.
    - jrockway 15y ago
      How does one ensure that they do not accidentally use ==?
      - eli 15y ago
        Got me. How do old-school C programmers ensure they don't accidentally use = when they mean == ? There are actually some decent commercial PHP IDEs, believe it or not. I wouldn't be surprised if some of them are able to Warn on loose equality comparisons. I don't have much direct experience with them though.
        jrockway 15y ago
        How do old-school C programmers ensure they don't accidentally use = when they mean == ? By making the constant the expression's lvalue. But they don't have to do this anymore; gcc warns when you accidentally use = instead of == now.
whateverer 15y ago
> Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you... I'm sorry, I would like that to be true, but programmers rarely are half as smart as they think they are. We have many more years of PHP and its resulting insanity ahead of us.
kcbanner 15y ago
You could use strcmp like you're supposed to I suppose, or ===.
- ctdonath 15y ago
  The language could not throw away data on an obscure whim.
  - jasonlotito 15y ago
    It does not throw it away on an obscure whim. It's clearly documented, and well known. === is pretty much the standard. Your lack of knowledge does not make it obscure.
    - whateverer 15y ago
      > It does not throw it away on an obscure whim. So you could have predicted this yesterday? Just because it's codified somewhere, it doesn't make it clear, or anything other than a whim, or a product of circumstances, at best. That's not how languages should be defined, even if PHP clearly demonstrates that they can end up that way by chance. Rasmus' lack of foresight does not make it reasonable.
      - Groxx 15y ago
        Yes, you could have predicted this yesterday. In fact, this behavior has been documented explicitly for a year and a half: http://web.archive.org/web/20100808122711/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20100808122711/http://www.php.net... Earlier versions have said the comparison converts the numbers to integers though, which may be incorrect, and misleading if it was. Did PHP not convert float-like strings to floats in, eg, 2009? http://web.archive.org/web/20091024233139/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20091024233139/http://www.php.net...
        whateverer 15y ago
dunham 15y ago
Just do the /bin/sh thing and prepend "x" on the strings before comparing them. :)
jlarocco 15y ago
"Intolerable for real-world use. A toy language." Seems like a silly thing to say. I wouldn't write avionics software with it, but there are a billion websites demonstrating that it's pretty decent for real-world use. At least as good as any other language, I'd guess.
tedunangst 15y ago
Downvoting because you're railing against a language without understanding it. That, and your C++ comment above, make you sound like the programmer version of internet tough guy. Whatever your real life skills may be, it certainly sounds like a lot of posturing.
JadeNB 15y ago
> Going so far as analyzing a string to determine whether it consists entirely of numbers I was about to give an outraged reply that, if PHP is like Perl, then it doesn't scan the string afresh, just keeps a flag indicating whether or not it thinks a string is numeric. However, it turns out that's not true at all. `Perl_looks_like_number`, defined in `sv.c`, calls `Perl_grok_number`, defined beginning on l. 577 (as of v5.14.2) in `numeric.c`, which (after some book-keeping) does this: if (s == send) { return 0; } else if (*s == '-') { s++; numtype = IS_NUMBER_NEG; } else if (*s == '+') s++; if (s == send) return 0; if (isDIGIT(*s)) { UV value = *s - '0'; if (++s < send) { int digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; if (++s < send) { digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; if (++s < send) { digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; and goes on and on and on and on in the same vein. Sheesh! (I didn't forget to close that last brace; the next line is de-dented, but that seems to be a mistake.)
- chromatic 15y ago
  Perl does cache whether an SV contains something usable as an integer (the IOK flag) or a floating point number (the NOK flag). That's why you almost never see `looks_like_number` on its own and always called after using one of the appropriate flag checking macros.

hackermom 15y ago

"Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you..." Have you been out on the internet the past decade? Do you have a tendency to make extremities of things and trying to stand the needle on its tip?

ctdonath 15y ago
It throws away data on an obtuse, obscurely-documented, whim. Making extremes? My medical application would fail FDA approval in minutes if ported to PHP precisely because of this issue.
- luser001 15y ago
  All languages have their idiosyncrasies. You can pick out some obscure aspect of any language and say $LANG sucks. Btw, PHP's behavior doesn't totally make sense to me either. But I'm willing to assume that its users and designers have thought this through and it makes sense for PHP's intended use cases, because I don't know PHP. Javascript (which most people on HN seem to like) also has similar issues (null vs. undefined, == and === etc). It got so bad that "Javascript: the good parts" had to be written to define a de-facto sane subset of the language. People are actually writing in Coffeescript (in part) to avoid Javascript's pitfalls. YMMV.
- Groxx 15y ago
  "obscurely-documented"? That seems pretty clear to me, given that it's a fundamental feature of the language, and documented (floating point problems too) in an obvious location.
- tedunangst 15y ago
  Would your medical application fail FDA approval if you used a language like C or C++ that contained strncmp? Because that function throws away data, too.
  - ctdonath 15y ago
    There's a difference between strncmp existing precisely so you can specify how many characters to compare, vs. throwing away trailing characters in a string just because, by sheer chance, it contains only numerics.
- eli 15y ago
  Your medical application should probably be using === for comparisons. I'm not defending PHP's language design, but I think it's pretty well known among professional PHP developers that you should almost always use === and avoid implicit type conversions.
  - jrockway 15y ago
    How does one ensure that they do not accidentally use ==?
    - eli 15y ago
      Got me. How do old-school C programmers ensure they don't accidentally use = when they mean == ? There are actually some decent commercial PHP IDEs, believe it or not. I wouldn't be surprised if some of them are able to Warn on loose equality comparisons. I don't have much direct experience with them though.
      - jrockway 15y ago
        How do old-school C programmers ensure they don't accidentally use = when they mean == ? By making the constant the expression's lvalue. But they don't have to do this anymore; gcc warns when you accidentally use = instead of == now.

whateverer 15y ago

> Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you... I'm sorry, I would like that to be true, but programmers rarely are half as smart as they think they are. We have many more years of PHP and its resulting insanity ahead of us.

kcbanner 15y ago

You could use strcmp like you're supposed to I suppose, or ===.

ctdonath 15y ago
The language could not throw away data on an obscure whim.
- jasonlotito 15y ago
  It does not throw it away on an obscure whim. It's clearly documented, and well known. === is pretty much the standard. Your lack of knowledge does not make it obscure.
  - whateverer 15y ago
    > It does not throw it away on an obscure whim. So you could have predicted this yesterday? Just because it's codified somewhere, it doesn't make it clear, or anything other than a whim, or a product of circumstances, at best. That's not how languages should be defined, even if PHP clearly demonstrates that they can end up that way by chance. Rasmus' lack of foresight does not make it reasonable.
    - Groxx 15y ago
      Yes, you could have predicted this yesterday. In fact, this behavior has been documented explicitly for a year and a half: http://web.archive.org/web/20100808122711/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20100808122711/http://www.php.net... Earlier versions have said the comparison converts the numbers to integers though, which may be incorrect, and misleading if it was. Did PHP not convert float-like strings to floats in, eg, 2009? http://web.archive.org/web/20091024233139/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20091024233139/http://www.php.net...
      - whateverer 15y ago

dunham 15y ago

Just do the /bin/sh thing and prepend "x" on the strings before comparing them. :)

jlarocco 15y ago

"Intolerable for real-world use. A toy language." Seems like a silly thing to say. I wouldn't write avionics software with it, but there are a billion websites demonstrating that it's pretty decent for real-world use. At least as good as any other language, I'd guess.

tedunangst 15y ago

Downvoting because you're railing against a language without understanding it. That, and your C++ comment above, make you sound like the programmer version of internet tough guy. Whatever your real life skills may be, it certainly sounds like a lot of posturing.

JadeNB 15y ago

> Going so far as analyzing a string to determine whether it consists entirely of numbers I was about to give an outraged reply that, if PHP is like Perl, then it doesn't scan the string afresh, just keeps a flag indicating whether or not it thinks a string is numeric. However, it turns out that's not true at all. `Perl_looks_like_number`, defined in `sv.c`, calls `Perl_grok_number`, defined beginning on l. 577 (as of v5.14.2) in `numeric.c`, which (after some book-keeping) does this: if (s == send) { return 0; } else if (*s == '-') { s++; numtype = IS_NUMBER_NEG; } else if (*s == '+') s++; if (s == send) return 0; if (isDIGIT(*s)) { UV value = *s - '0'; if (++s < send) { int digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; if (++s < send) { digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; if (++s < send) { digit = *s - '0'; if (digit >= 0 && digit <= 9) { value = value * 10 + digit; and goes on and on and on and on in the same vein. Sheesh! (I didn't forget to close that last brace; the next line is de-dented, but that seems to be a mistake.)

chromatic 15y ago
Perl does cache whether an SV contains something usable as an integer (the IOK flag) or a floating point number (the NOK flag). That's why you almost never see `looks_like_number` on its own and always called after using one of the appropriate flag checking macros.