• (cs) in reply to Dave
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.
    You were doing so well until you mentioned security and Windows OSes in the same sentence. ;D
  • Sunday Ironfoot (unregistered)

    This is why Strongly Typed languages like C# and Java (as in real Java not JavaScript) rule! In C# you would have to explicitly define your '09' as an 'oct' type and the method parseInt would have to be overloaded to except an 'oct' type argument.

    How can people think JavaScript is a cool language!?

  • (cs) in reply to Dave Ross
    Dave Ross:
    This is a Javascript rite of passage. It bites everyone once, and then you never forget.
    Absolutely. After this happened to me, I made it a point to always specify the radix.
  • Jasper (unregistered) in reply to Schmitter
    Schmitter:
    I thought it was "its not a bug, it is an undocumented feature." Seriously 2008 and computers still can't handle dates well? That is the WTF.
    It's not an undocumented feature - it's just a feature that goes back to C, where integer constants that start with a 0 are also interpreted as octal numbers. C++, Java and JavaScript inherited this idea from C.

    The only WTF here is that Charles Capps and the original programmer of the date widget didn't know that.

    Not really a WTF.

  • Sunday Ironfoot (unregistered) in reply to Dave
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.

    Great, so instead of building one website, we now have to build a program that works on Windows, another that works on Mac, then another that works on Linux, and then there's the mobile/PDA/iPhone versions. Just what I need, more work!

  • (cs) in reply to spacix
    spacix:
    If this a WTF, then all of the people who try to float two
    's in HTML side by side are building a WTF.

    Anyone who knows anything about HTML knows that if you want two things side-by-side you use the tag, which doesn't include a break before and after it!

    Having just agreed with you about Javascript dates, I'm afraid you've gone a bit amiss here. If you actually mean 'float' (as in the CSS property float) then the elements are taken out of normal flow, and will happily float next to each other whether they are 'div's, 'span's, 'p's, 'img's, or anything else. Try this snippet in a browser, then uncomment the floats and see what happens.
    

    

    

    Some text
  • (cs) in reply to Sunday Ironfoot
    Sunday Ironfoot:
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.

    Great, so instead of building one website, we now have to build a program that works on Windows, another that works on Mac, then another that works on Linux, and then there's the mobile/PDA/iPhone versions. Just what I need, more work!

    I missed the per-OS part. Something byte-coded and JIT compiled would be a better solution. Something that's not Java.

  • Sanjay Kumar (unregistered) in reply to Dave

    Let's all use ActiveX controls.

  • Collin Cusce (unregistered) in reply to Anon

    I wouldn't blame Javascript... I would blame the browser manufacturer.

  • Mike Shaver (unregistered) in reply to JimM
    JimM:
    Is it too much to ask for a function to throw some kind of error if the input doesn't make sense?

    JS didn't have exceptions when the Date object was implemented and standardized, though its Date object was largely copied from Java -- recognized now as a mistake, but seemed like a reasonable plan at the time.

    In Firefox, at least, we permit the "illegal" octal of 09 as a literal, because octal/decimal literals don't have a way to override the radix used to parse them, and web compatibility demands it. For parseInt, you can specify the radix, and should.

  • (cs) in reply to Sanjay Kumar
    Sanjay Kumar:
    Let's all use ActiveX controls.
    Yes, because everyone knows all browsers on all platforms can run ActiveX controls.
  • Mark (unregistered) in reply to Anon

    No, it shouldn't. parseInt()'s documentation states that it attempts to parse as much of an integer out of a string as possible. so "20th" returns 20, "0th" returns 0, and since '09' is detected as an octal number, and 9 isn't a digit in the octal system, '09' returns 0.

    When you call parseInt without specifying a radix, it applies some simple hueristics to guess what type of number it is. Simply put, 0x starts a hex number, 0 starts an octal number, and 1-9 start a decimal number. If it tried to be smarter, it would become more unpredictable.

    The developer just needs to specify the radix. That's TRWTF here.

  • (cs) in reply to Collin Cusce
    Collin Cusce:
    I wouldn't blame Javascript... I would blame the browser manufacturer.
    The browser is doing what it's supposed to. JavaScript is supposed to work that way. That's why the second parameter is available... If you need a number with a specific base you should pass the radix into the function to be sure. I just started using bitwise-or for 32-bit integer conversion, which I read first passes the value into an internal ToInt32 function... 
    var x = "05";
var y = "04";
var z1 = x + y; // "0504"
var z2 = (x|0) + (y|0); // 9
    The bitwise operation could easily be wrapped up into a function for readability... 
    function to_int32(value)
{
    // Try...catch may not be necessary.
    try
    {
        return(value|0);
    }
    catch(e)
    {
        return(0);
    }
}
  • (cs) in reply to ParkinT
    ParkinT:
    Schmitter:
    I thought it was "its not a bug, it is an undocumented feature." Seriously 2008 and computers still can't handle dates well? That is the WTF.
    That's because PEOPLE cannot handle dates well: 2008-09-01 01-09-2008 01/09/08 Sept. 01, 2008 September 1st, 2008 ... et cetera, et cetera

    Not to forget the Americanisation, sorry, -ization of dates: 09-01-2008 (mm-dd-yyyy)

    Lucky SQL 2008 is handling it...oh no, wait...it's bringing out more different datetime data types...

  • (cs) in reply to cparker
    cparker:
    Sanjay Kumar:
    Let's all use ActiveX controls.
    Yes, because everyone knows all browsers on all platforms can run ActiveX controls.
    Someone's sarcasm meter is out of wack. ;)
  • Magnus Bergmark (unregistered) in reply to spacix
    spacix:
    If this a WTF, then all of the people who try to float two
    's in HTML side by side are building a WTF.

    Anyone who knows anything about HTML knows that if you want two things side-by-side you use the tag, which doesn't include a break before and after it!

    If you are serious when saying this, then you are among the people who made the web such a pain in the ass to build for. Are you perhaps working on the IE team?

    is not a block-level element, which

    is. This should be enough to say, but just to make the point clear:

    Block-level elements contain other elements, which could be blocks or non-blocks. Inline (which is) is only designed to contain text and/or other inline elements. When you want to position two things side by side, it is usually not text in there.

    Note the difference between a paragraph and text here.

    is a block level element which may contain text, , , etc. A

    may not contain other blocks, though, so placing an image ([image]) inside a paragraph is stupid and non-standard. An image is not text, and it should be placed outside the paragraph.

    So if you're using elements to float contents side by side, you may not use images, lists, tables, forms, dividers, horizontal rules or any other block element in them. What is it good for, then? Well, you could do this:

      I am the greatest          Fear my powers of
  master in the universe.    deduction and spelling.

    I don't see the point of that, though. This could be accomplished better by placing paragraphs floated like that.

    Yes, you may override the display type of an element. A span may display and behave like a block when you use the property "display" and set it to "block", but this does not change the schematics, and CSS should be presentational ONLY.

    Please... Use standards, and try to at least understand them before you do. "Floating s" was even stupider than the original article here. :-(

  • Steve (unregistered)

    This isn't a bug, and it's not even an undocumented feature. It's part of the spec. So if you ran into this, it's your own fault.

    If you want parseInt to assume base 10 constantly, do something like:

    var oldParseInt = parseInt; parseInt = function(theNum){ oldParseInt(theNum,10);}

  • Chelmi (unregistered) in reply to Sunday Ironfoot
    Sunday Ironfoot:
    In C# you would have to explicitly define your '09' as an 'oct' type and the method parseInt would have to be overloaded to except an 'oct' type argument.

    O_o WTF ?!??!

  • Anon (unregistered)

    This post tries to explain why JavaScript behaves the way it does:

    http://blogs.msdn.com/ericlippert/archive/2003/10/06/53150.aspx

    [C# (and lots of other languages) is designed for professional developers, not hobbyists and departmental web developers who just want to get "glue code" written as rapidly as possible.

    That's why JScript's attitude towards error cases is not "die at the first sign of trouble" but rather "muddle along as best you can". Assign to an undeclared variable? Declare it dynamically. Forget a semicolon? Insert it. Try to create a date for the 31st of September? Move it to October 1st. Divide by zero? Return a NaN . Reference an element beyond the end of an array? Grow the array. All these things that would be compile time or runtime errors in other languages are just handled for you in JScript, for better or for worse.]

    BTW, when Eric says "JScript", he means "ECMAScript ECMA-262" http://www.ecma-international.org/publications/standards/Ecma-262.htm which was basically built from what Netscape originally released as JavaScript and Microsoft (and others) copied to try to be compatible with the original JavaScript 1.0. If you view the above behaviour as "problems", then they aren't the result of anything Microsoft did, other than copying the original JavaScript implementation.

    Anyway, the parseInt() behaviour is clearly documented in section 15.1.2.2 of ECMA-262, the new Date() behaviour is less clearly documented in section 15.9.3.1.

    In closing, I'd like to post some quotes from Richard Cornford, author of http://www.litotes.demon.co.uk/js_info/private_static.html and http://www.jibbering.com/faq/faq_notes/closures.html (and numerous other documents) which demonstrate that JavaScript is a rich language full of potential untapped by most developers.

    [...you might want to know that cross-browser scripting is one of the hardest programming tasks that there is, because such scripts cannot know in advance which browser environment they will be attempting to execute in and must be designed to exhibit planned behaviour in the face of all of the possible permutations. It is such a difficult task that few even aspire to attempt it, let alone successfully achieve it.

    Unfortunately browser scripting is superficially easy to do. There is no requirement for special authoring software, a text editor and a web browser is enough and most people have those as pare of their OS. The language itself is relatively simple, not always appreciated for its subtleties and capabilities but not difficult to assemble a sequence of statements and achieve expected results by executing them in a browser.]

    [...It is a "toy" language until it bites back and then it is broken language because it didn't turn out to be the toy that the misconception made it.

    Javascript's loose typing and dynamic nature, from the perspective of a class-based language programmer, may seem to be concessions made for the benefit of undisciplined amateur programmes. In reality they are powerful features ideally suited to programming for the quicksand environments of web browsers. Much harder to properly exploit than they at first seem, and requiring at least as much discipline on the part of the programmer to keep track of. In fact frequently a major stumbling block for amateur scripters rather than being a way of avoiding exposing them to issues.]

  • (cs) in reply to Dave
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.
    I hope you're kidding.
  • Samuel (unregistered) in reply to Dave
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.

    Per-OS?? Let me think -- FAIL. You haven't a clue of the whole point behind web browsers.

    Besides, you already have everything you've asked for above -- it's called C++. You might want to look it up.

    For the rest of the folks here, remember the first integer in any numeric base you care to think of starts at zero. 0 goes to 0, 1 goes to 1, ..., 7 goes to 7, and 8 goes to 0, 9 goes to 1, 10 goes to 2, etc.

    Not only was the article wrong about its octal mapping, so too were a surprising number of comments offering "corrections."

  • Chelmi (unregistered) in reply to Samuel
    Samuel:

    For the rest of the folks here, remember the first integer in any numeric base you care to think of starts at zero. 0 goes to 0, 1 goes to 1, ..., 7 goes to 7, and 8 goes to 0, 9 goes to 1, 10 goes to 2, etc.

    Not only was the article wrong about its octal mapping, so too were a surprising number of comments offering "corrections."

    Either I missed your point here or you're completely wrong. There is no "mapping" in octal. 8 and 9 are invalid octal digits, period. And by the way, 10oct is 8dec...

  • Pappacena (unregistered)

    "0 goes to 0, 1 goes to 1, ..., 7 goes to 7, and 8 goes to 0, 9 goes to 1, 10 goes to 2, etc. "

    8 goes to 0, 9 goes to 1? WTF?!

  • Andreu Escudero (unregistered)

    Well, this behaviour is the correct and documented behaviour for ParseInt. Every javascript developer should use some verification tool like JSlint, which would issue a warning when ParseInt is called without using the radix parameter, because it's dangerous (and I repeat, perfectly documented) to do so. The WTF here is not javascript, but the developer who has written these lousy code.

  • Schmitty (unregistered) in reply to Schmitter
    Schmitter:
    I thought it was "its not a bug, it is an undocumented feature." Seriously 2008 and computers still can't handle dates well? That is the WTF.

    That's because THE DATES KEEP CHANGING!! As soon as a computer is able to handle a date, it CHANGES! And it never changes back to one that's already happened, that'd be too easy!

  • Gareth (unregistered)

    The read WTF is that we're 75 comments in and no one has actually posted the right answer to this problem

    parseInt("08") // => 0 parseInt("10foo") // => 10 parseInt("foo") // => NaN

    Number("08") // => 8 parseInt("10foo") // => NaN parseInt("foo") // => NaN

    Simple

  • RichardPeterJohnson (unregistered) in reply to Lawrence

    To Lawrence-

    It's legacy from C. It was originally developed on a PDP machine which had 6-bit characters.

    What's weird is that C uses 0x prefix for hexadecimal constants, but 0 for octal constants. Had they been consistent in their definitions none of this would have happened.

  • Gareth (unregistered)

    Yes, I'm the real WTF.

    parseInt("08") // => 0 parseInt("10foo") // => 10 parseInt("foo") // => NaN

    Number("08") // => 8 Number("10foo") // => NaN Number("foo") // => NaN

  • RichardPeterJohnson (unregistered) in reply to RichardPeterJohnson

    Now that I think a bit more, the PDPs had 6-bit characters in some places and 7-bit in others.

  • (cs) in reply to RichardPeterJohnson

    Just (mis)use the loosely typed variables of JavaScript and thus avoid parseInt on a string you already know is a digit. Simply subtract 0 from the "string" and you get the number. Problem solved :D

  • Marijn (unregistered)

    parseInt is almost never what you want. Number("09") evaluates to 9.

  • Zach Leatherman (unregistered) in reply to JimM

    Look, as with any language, you have to know how it behaves in the environment that its used.

    In JavaScript, months are 0-indexed.

    So, var d = new Date(2008,0,365); would be January.

    It is a bit egocentric to think that just because the language doesn't behave how you expect it to behave, that it's wrong.

  • Niki (unregistered) in reply to fraserofthenight
    fraserofthenight:
    Some people thing the ?: operator in C/C++/C# is quirky. Does that make it a WTF?

    What's the quirk? It works just as I would expect it to in Java/D; is it different in C/C++/C#?

    The quirk is that the precedence of the ?: operator is strictly than the assignment operator in C, while in C++ the ?: operator is not strictly higher than assignment.

    In other words, the code: flag ? a=1:a=2; in C is the same as: (flag ? a=1:a) = 2; and in C++ is the same as: flag ? (a=1):(a=2);

    C and C++ aren't as compatible as most people think.

  • (cs)

    That's a well known bug in JavaScript. Just use parseFloat().

  • TopicSlayer (unregistered) in reply to Therac-25
    Therac-25:
    Don't blame Javascript, blame atoi.

    I've seen this same behaviour elsewhere, it's because it's dropping down to C's standard library.

    Wrong, but thanks for trying....

    prompt>cat tst_atoi.c #include <stdio.h> #include <stdlib.h>

    void main() { char *bla = "09";

        printf("%d\n", atoi(bla));

    } prompt>cc tst_atoi.c prompt>./a.out 9

    atoi converts for decimal base, if you want to force a base then there are other functions (eg. strtol and kin).

    P.S. Yes, I used "void main()" rather than "int main(int argc, char **argv, char **env)", or even "int main(int argc, char *argv[], char *env[])"; want to fight?

  • Errol Lorre (unregistered) in reply to Adriano
    Adriano:
    0106 0101 0111 0114

    0120 0125 0116 0124

  • TopicSlayer (unregistered) in reply to Niki
    Niki:
    fraserofthenight:
    Some people thing the ?: operator in C/C++/C# is quirky. Does that make it a WTF?

    What's the quirk? It works just as I would expect it to in Java/D; is it different in C/C++/C#?

    The quirk is that the precedence of the ?: operator is strictly than the assignment operator in C, while in C++ the ?: operator is not strictly higher than assignment.

    In other words, the code: flag ? a=1:a=2; in C is the same as: (flag ? a=1:a) = 2; and in C++ is the same as: flag ? (a=1):(a=2);

    C and C++ aren't as compatible as most people think.

    First, in my C compiler, "flag ? a=1:a=2;" won't compile. While "flag ? (a=1):(a=2);" will. There is probably a good reason for that.

    Regardless, code like that is why I have seen coding standards disallow use of the ? operator. I would say a sane use of the operator performing the same function would be:

    a = flag ? 1 : 2;

    and if you really want to visually clue in the clueless:

    a = (flag ? 1 : 2);

    Of course, if you did:

    flag ? (a = 1) : (b = 1);

    then it appears that you want two different behaviors based on flag and I would suggest an if better conveys that message.

  • (cs)

    IMO, Javascript is an awful language and I'm not talking about the syntax. It incorporates one of the worst practices possible which is to bury errors. This parseInt example is a good illustration. Sure it is powerful, much like heroin. A tiny bit of heroin might not kill you and might even feel good at first, but it doesn't take much to make it lethal.

  • (cs)

    scroll, scroll, scroll Wow, only about 75% of the comments are people complaining about me forgetting about the radix paramater. I originally guessed 90%. Damn.

  • Pitabred (unregistered) in reply to Chelmi
    Chelmi:
    Samuel:

    For the rest of the folks here, remember the first integer in any numeric base you care to think of starts at zero. 0 goes to 0, 1 goes to 1, ..., 7 goes to 7, and 8 goes to 0, 9 goes to 1, 10 goes to 2, etc.

    Not only was the article wrong about its octal mapping, so too were a surprising number of comments offering "corrections."

    Either I missed your point here or you're completely wrong. There is no "mapping" in octal. 8 and 9 are invalid octal digits, period. And by the way, 10oct is 8dec...

    And Halloween is Christmas... 31oct == 25dec ;)

  • Sarusa (unregistered) in reply to James
    James:
    I also vote for "no WTF here". If you're going to support octal at all, you have to do it right.

    Supporting octal (especially in JavaScript) is a WTF which I'm sure is only in there because other languages did that too. And why do they do that? Because languages for ancient obsolete hardware did that. Supporting octal in and of itself isn't stupid, but inferring octal from a leading zero is insanely stupid and only justified by the miniscule memory and processing powers of those old systems.

    There is just zero justification for this any more. I know so many people who have been tripped up by this and I bet nearly everyone who would defend 0011 parsing to 9 thinks the horrible, horrible imposition of having to type a 0x for 0x0A is just fine - and it is. Octal should be explicit and parsing an integer should always be base 10 unless overridden. Even documented bad behavior is still bad behavior.

  • ysth (unregistered) in reply to Anon Fred
    Anon Fred:
    Lawrence:
    Why the HELL is there any constant which is inferred to be octal?

    Because Perl did the same thing!

    Um, wtf? Lawrence said "This has to be one of my biggest pet peeves with current programming languages in general. Why the HELL is there any constant which is inferred to be octal? Current programming languages in general have octal constants because Perl does?

    However, Perl does act pretty much like JavaScript in that strings containing numbers, used as if they were numbers, are interpreted in base 10. It even has a function that converts a string to a number, obeying "0x" (for hex) or "0b" (for binary) prefixes, and otherwise using a default radix. It's called...

    oct

  • DKO (unregistered)

    For all the poor souls that have to suffer programming in JavaScript, here are obligatory videos.

    Basics (for people who think they figured out how JS works): http://video.yahoo.com/watch/111593 http://video.yahoo.com/watch/111594 http://video.yahoo.com/watch/111595 http://video.yahoo.com/watch/111596 (really, watch it. it's worth lots of laughs)

    And advanced: http://video.yahoo.com/watch/111585 http://video.yahoo.com/watch/111586 http://video.yahoo.com/watch/111587

  • (cs)

    A real wtf would be a mature language with a standard library function to convert strings to numbers coming up with a new specification that switched it to interpreting a leading 0 as indicating octal.

    Can anyone name the one-character language I mean?

  • Saccharissa (unregistered) in reply to Samuel

    Pedantic mathematician mode=on

    Samuel:
    For the rest of the folks here, remember the first integer in any numeric base you care to think of starts at zero. 0 goes to 0, 1 goes to 1, ..., 7 goes to 7, and *8* goes to 0, *9* goes to 1, *10* goes to 2, etc.

    Nope, sorry. You're confusing modulo arithmetic with base number representation. One is a system of setting numbers equivalent to each other, the other is a way of writing those numbers.

    In the first, yes, 8 mod 8 is 0, 9 mod 8 is 1, etc.; 8 is considered equal (equivalent) to 0. In base 8, you don't say that 8 is equivalent to 10, since, as someone already pointed out, the symbol "8" has no meaning. What you say is that this many things: XXXXXXXX represented by the symbol "8" in base 10, is represented by the symbols "10". Pedantic mathematician mode=off. We now return you to our regularly scheduled WTF.

  • jbinaz (unregistered) in reply to ParkinT
    ParkinT:
    Dave:
    The real WTF is Javascript. The sooner we junk this crap and start over with nice per-OS browser app which lets you do all the things you'd expect a program to allow you to do in 2008. We could ditch this html bollocks and let people design sites (sorry, apps) which look how you want them to look to the pixel, and use modern security such as that on Vista/Xp etc to allow/deny access to resources.
    You, sir, just described Adobe FLEX!

    Or Silverlight.

  • PerfectlyNormal (unregistered) in reply to Bram Geron

    Except, if you're from some strange part of the world that uses QWERTY, but doesn't have the US-layout. I have two buttons for +, and both requires just a single keystroke. (The one on the numpad requires moving my hand a lot though)

  • jbinaz (unregistered) in reply to PerfectlyNormal
    PerfectlyNormal:
    Except, if you're from some strange part of the world that uses QWERTY, but doesn't have the US-layout. I have two buttons for +, and both requires just a single keystroke. (The one on the numpad requires moving my hand a lot though)

    I get the numpad + that requires only one keystroke, where's the second? The only other one I see is above the equals sign, which requires a shift and the key - two keystrokes. Am I missing one?

  • Nate (unregistered) in reply to JimM

    The way javascript handles dates is pretty nice once you realize how easy this "WTF" makes date/time math.

    Everything gets converted into milliseconds, and then the date object is milliseconds since the epoch (1/1/1970). This means that adding/subtracting any unit of time will get converted to milliseconds and the date that will be displayed will be converted back to the usual human readable formats.

    Time becomes single number instead of having to handle each section of having to worry about all the different rules for how we keep track of time.

  • Da' Man (unregistered)

    And where exactly is the WTF?

    Ah, I see, some programmer was too lazy to read his "JavaScript for Dummies" until the end.

Leave a comment on “Thank you, Javascript”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article