PSA: JavaScript is retarded


  • Discourse touched me in a no-no place

    @rhywden said in PSA: JavaScript is retarded:

    @dkf said in PSA: JavaScript is retarded:

    @rhywden said in PSA: JavaScript is retarded:

    Naw, for that we'd have to start the index at 9.

    Ugh, that reminds me of porting code from a language that did that and where the author of the code had used it extensively. :(

    Seriously? :wtf:

    Seriously. It's amazing the sort of bizarre stuff you could find in Algol68 code, and in that case it was the only place that had an otherwise-sane description of the algorithm I needed. But it was definitely deeply twisted code. I've got this vague feeling that there was something else tricky going on, but it's a very long time since I did this so I've forgotten the details; that it was using weird array offsets was the main thing of interest in the whole affair at the time. I don't even actually remember what the algorithm was otherwise doing. 😆

    (Of course, I managed to unfuck the algorithm implementation in the end, and that in turn meant that any future porting to other languages would also be fairly simple.)



  • @sh_code said in PSA: JavaScript is retarded:

    @cheong said in PSA: JavaScript is retarded:

    @sh_code said in PSA: JavaScript is retarded:

    0_1507227845971_67bc7557-fc56-4a8a-99ba-56a4d463741f-image.png

    Datetime is difficult. That's why we have Moment.js .

    and JS is shit but people are too dumb to make some actually sane replacement for it, and they rather try to cover it up by piling layers of bandages made from shit on top of it, because that's the webstack mentality. that's why we have jQuery, typescript, whateverelsescript and who knows what else.

    also processors are dificult, yet i don't see DYI wooden addons which would be basically required for them to work in at least remotely sane way.

    Well... old compilers did have option to generate floating point emulation codes, and some generate MMX emulation too. :P



  • @sh_code another option would be something like

    new Intl.DateTimeFormat(undefined, {year: 'numeric', month: 'numeric', day: 'numeric'}).format(new Date);
    

    ...by leaving locale undefined, it will default to the user's current locale; or, it can be specified:

    0_1507570005741_3c589db6-2e3c-4186-b7bf-34dfccf09e36-image.png



  • @bulb said in PSA: JavaScript is retarded:

    @ben_lubar said in PSA: JavaScript is retarded:

    Enumerations start at 0

    They don't, because you can assign the numbers. But it is completely irrelevant. What is relevant is where indices start and since C, they always start at 0 in most languages.

    @blakeyrat said in PSA: JavaScript is retarded:

    In C# they can start at any integer.

    As far as I can tell, indices start always at 0 though. And that is what matters.

    But the range of values for a month variable form an enumeration, not a collection that can be indexed.



  • @djls45 said in PSA: JavaScript is retarded:

    But the range of values for a month variable form an enumeration, not a collection that can be indexed.

    No. The range of values for a month variable must be valid indices into array of month names (and ditto for days of week, but those don't have customary numeric representation, so starting with 0 is not surprising there).

    And note that you can't work this requirement around by stringification of the enum, because the array might be dynamically read from some resource. Or at least that's what those who set the strange numbering apparently expected.



  • @Bulb So we currently have four different representations for months. You're saying that it's required because we need to use a zero-based index so the translatable terms can be more easily determined from an array?

    internal (index/ID)numeric IDtranslatable nametranslatable abbreviation
    0?1January (Enero/Leden/Janvier/etc.)Jan/etc.
    1?2FebruaryFeb
    2?3MarchMar
    3?4AprilApr
    4?5MayMay
    5?6JuneJun
    6?7JulyJul
    7?8AugustAug
    8?9SeptemberSep
    9?10OctoberOct
    10?11NovemberNov
    11?12DecemberDec

    Why not just use the numeric representation as the internal identifer (limiting the representations to the three that are commonly used) and force the translation resources to map the ID properly?

    ;ID="name","abbreviation"
    1="January","Jan"
    2="February","Feb"
    ...
    
    { "month-translation": [
        { "id": "1", "name": "January", "abbr": "Jan" } }
        { "id": "2", "name": "February", "abbr": "Feb" } }
        ...
        ]
    }
    

    It's already been mentioned that an enum (in C-like languages) can properly handle the underlying int value, but string-ifying the enumeration would only work for the coder's own language anyways, so a translatable resource should be used in internationally-distributed programs.



  • @djls45 said in PSA: JavaScript is retarded:

    Why not just use the numeric representation as the internal identifer

    That's precisely what the function is doing. Numeric identifier is internal, so it can map 0 to January and nobody should care, right?

    @djls45 said in PSA: JavaScript is retarded:

    It's already been mentioned that an enum (in C-like languages)

    JavaScript does not have enum. It should not really have a problem with 1-based array but whatever.

    @djls45 said in PSA: JavaScript is retarded:

    tring-ifying the enumeration would only work for the coder's own language anyways, so a translatable resource should be used in internationally-distributed programs.

    Yes, precisely. Or almost; a sane translatable resource is string->string, so it will translate from something like month,full\034January, where the last part is the stringification fo the enum. But many will simply have an array and that's why the internal numerical identifier starts from 0. And can't do otherwise, because JS does not have enums (well, but it has localization, so programmers shouldn't be doing it themselves, but whatever; sometimes in portable code it is easier to do yourself then try a dozen native methods to see which works).



  • @bulb said in PSA: JavaScript is retarded:

    @djls45 said in PSA: JavaScript is retarded:

    Why not just use the numeric representation as the internal identifer

    That's precisely what the function is doing. Numeric identifier is internal, so it can map 0 to January and nobody should care, right?

    No, the numeric identifier is the way it's represented when printing out the date in numeric format: 2017-10-09. The function accepts the other common parts of a date (year, day of month) in the same format as most date formats, so why not month?

    @djls45 said in PSA: JavaScript is retarded:

    It's already been mentioned that an enum (in C-like languages)

    JavaScript does not have enum. It should not really have a problem with 1-based array but whatever.

    @djls45 said in PSA: JavaScript is retarded:

    string-ifying the enumeration would only work for the coder's own language anyways, so a translatable resource should be used in internationally-distributed programs.

    Yes, precisely. Or almost; a sane translatable resource is string->string, so it will translate from something like month,full\034January, where the last part is the stringification of the enum. But many will simply have an array and that's why the internal numerical identifier starts from 0. And can't do otherwise, because JS does not have enums (well, but it has localization, so programmers shouldn't be doing it themselves, but whatever; sometimes in portable code it is easier to do yourself then try a dozen native methods to see which works).

    Does JS have map or related? If so (or even if not), it should be able to read a set of translations from something like the JSON-style excerpt for a translation resource in my post. I know there's JSON libraries for JS.

    Any translator should have no problem translating "1" to "January" or "Jan", and "1" to "01" is trivial.

    Associating the index position in an array to something meaningful is :doing_it_wrong:. Not that it should happen with the months in a year, but what should happen if something is added or removed from the array? Or, for something that is more likely, what happens if the serialization of the data is corrupted and elements from the array are lost?



  • @djls45 said in PSA: JavaScript is retarded:

    No, the numeric identifier is the way it's represented when printing out the date in numeric format: 2017-10-09.

    Ok, the Date.prototype.getMonth() returns internal index. Not numeric identifier.

    @djls45 said in PSA: JavaScript is retarded:

    Does JS have map or related?

    Of course it has. Object.

    @djls45 said in PSA: JavaScript is retarded:

    If so (or even if not), it should be able to read a set of translations from something like the JSON-style excerpt for a translation resource in my post. I know there's JSON libraries for JS.

    Your snippet is an array. It is, therefore, indexed with zero-based index where 0 means January to 11 means December. That is exactly what I am saying all the time is the reason Date.prototype.getMonth returns 0 for January to 11 for December.

    @djls45 said in PSA: JavaScript is retarded:

    I know there's JSON libraries for JS.

    Remember, it is JavaScript Object Notation. Every JSON is valid JavaScript.

    @djls45 said in PSA: JavaScript is retarded:

    Associating the index position in an array to something meaningful is :doing_it_wrong:.

    Yep. And that's precisely why Date.prototype.getMonth has range [0..11]. It is the index position. It is not meaningful.



  • @Bulb
    So then why does Date.prototype.getDate() not return a range [0..30]? That's the index position for the day of the month. Why doesn't Date.prototype.getYear()Date.prototype.getFullYear() return a zero-based index to the year? Where's the consistency?



  • @bulb said in PSA: JavaScript is retarded:

    Remember, it is JavaScript Object Notation. Every JSON is valid JavaScript.

    :pendant: There are two Unicode characters, U+2028 Line separator and U+2029 Paragraph separator, that can be used inside JSON strings but not valid in JavaScript strings. Because why not. https://stackoverflow.com/a/23753148/1233508



  • @djls45 said in PSA: JavaScript is retarded:

    @Bulb
    So then why does Date.prototype.getDate() not return a range [0..30]? That's the index position for the day of the month. Why doesn't Date.prototype.getYear()Date.prototype.getFullYear() return a zero-based index to the year? Where's the consistency?

    Because day-of-month and year are always written as numbers. There is no use for a table, so they return the printable value directly.



  • @bulb said in PSA: JavaScript is retarded:

    @djls45 said in PSA: JavaScript is retarded:

    @Bulb
    So then why does Date.prototype.getDate() not return a range [0..30]? That's the index position for the day of the month. Why doesn't Date.prototype.getYear()Date.prototype.getFullYear() return a zero-based index to the year? Where's the consistency?

    Because day-of-month and year are always written as numbers. There is no use for a table, so they return the printable value directly.

    And month can be (and often is) written as a number, too, so why should it use the wrong number that requires correction by adding or subtracting an offset?
    Even if a zero-based index is used internally to the library, the "public-facing" API should accept the "natural" numbers for the months. Requiring that zero-based index exposes the internals of the library implementation, which is normally considered a Bad ThingTM.



  • @djls45 That's not internals. It is expected user will index a localization table with the month, so it's zero-based. It's expected they'll just print the day-of-month and year, so they are not. That expectation might be wrong, but it is traditional.



  • @Bulb Wouldn't the localization table be accessed via library functions, and not indexed directly? Or it would be a key->value mapping (perhaps accessed via library functions)? In either case, a zero-based index is unnecessary, since the library would be handling the lookup.



  • @djls45 Who knows how the user designs their localization table.

    Of course these days the library can provide the appropriate localized strings itself, so there is no reason for the user to have their own. But some still do. And the library can't change the convention now anyway.



  • @bulb it's JavaScript, it's entirely possible thatenough hipsters will declare it needs fixing in this years edition of JS.


  • Notification Spam Recipient

    @arantor said in PSA: JavaScript is retarded:

    @bulb it's JavaScript, it's entirely possible thatenough hipsters will declare it needs fixing in this years edition of JS.

    Possible? Sure. Probably? Not on your life... 😉


  • BINNED

    @bulb said in PSA: JavaScript is retarded:

    And do you have support for skeletons? Or at least for he base locale-aware formats full, long, medium and short? I don't see it in that documentation. JavaScript at least does, although with rather verbose syntax.

    Yes on the latter at least:

    I never messed with skeletons, if it's somewhere in there I can't find it. More likely it's not there



  • @arantor said in PSA: JavaScript is retarded:

    hipsters will declare it needs fixing in this years edition of JS

    Hipsters may declare whatever they want, but they are not the ones in control of browser implementations and the browser maintainers will not break backward compati(de)bility.


  • ♿ (Parody)

    @dreikin said in PSA: JavaScript is retarded:

    WebAssembly is a thing.

    Is it a thing that anyone is actually using yet?


  • ♿ (Parody)

    @sh_code said in PSA: JavaScript is retarded:

    @blakeyrat said in PSA: JavaScript is retarded:

    @sh_code said in PSA: JavaScript is retarded:

    metaphor meant to express what that sentence about moment.js sounds like. "my processor can't do basic stuff it should be able to do! “ - “that's normal because processors are hard, glue this hobbyist-made addon to it which will make it work fine, or, rather, which will hide and circumvent all its original by-design shittery"

    I think this is the new winner for "worst metaphor ever".

    thank you, I tried really hard. good to know my effort was not in vein :-D

    Go for the artery next time.


  • ♿ (Parody)

    @bulb said in PSA: JavaScript is retarded:

    No. The range of values for a month variable must be valid indices into array of month names (and ditto for days of week, but those don't have customary numeric representation, so starting with 0 is not surprising there).

    It is still incandescently stupid to use the wrong numbers for months.


  • ♿ (Parody)

    @bulb said in PSA: JavaScript is retarded:

    @djls45 That's not internals. It is expected user will index a localization table with the month, so it's zero-based. It's expected they'll just print the day-of-month and year, so they are not. That expectation might be wrong, but it is traditional.

    SPANK SPANK

    I feel like I'm channeling blakey while I'm reading your rationalizations of this abomination.



  • @boomzilla said in PSA: JavaScript is retarded:

    @dreikin said in PSA: JavaScript is retarded:

    WebAssembly is a thing.

    Is it a thing that anyone is actually using yet?

    I seriously doubt it.The assembler and linker is there (binaryen) and the browser support is there, but there are is severe shortage of actually useful compilers targeting it. There is only emscripten for C++, which still looks like a one-man show, and Rust has official target, but while it's use is growing fast, it's still nowhere near mainstream language. And I don't see compiler for any other language (apparently there is no managed heap yet and languages like Java and C# have to wait until there is).



  • @boomzilla said in PSA: JavaScript is retarded:

    abomination

    The whole business of timekeeping is so insanely complicated and messed up that this one tiny idiosyncrasy is nothing. If you want to maintain sanity, you want to avoid the split time methods altogether anyway.


  • ♿ (Parody)

    @bulb said in PSA: JavaScript is retarded:

    @boomzilla said in PSA: JavaScript is retarded:

    abomination

    The whole business of timekeeping is so insanely complicated and messed up that this one tiny idiosyncrasy is nothing. If you want to maintain sanity, you want to avoid the split time methods altogether anyway.

    I agree that it's a complicated field. Which is what makes it all the more frustrating that this decision to use the wrong numbers for months has been propagated so much. The numbering of the months is not any sort of arbitrary thing. The months are all very strongly associated with particular numbers. This is a decision that satisfies the CDO of some low level developer somewhere at the expense of making something obvious to the entirety of the world more confusing.



  • @bulb said in PSA: JavaScript is retarded:

    The whole business of timekeeping is so insanely complicated and messed up that this one tiny idiosyncrasy is nothing.

    It's not complicated on Python, it's not complicated on C#. You're just using retarded tools.


  • Discourse touched me in a no-no place

    @sockpuppet7 said in PSA: JavaScript is retarded:

    It's not complicated on Python, it's not complicated on C#.

    No, it's complicated there too. It's just that the system library hides almost all the horror…


  • Considered Harmful

    @bulb said in PSA: JavaScript is retarded:

    @boomzilla said in PSA: JavaScript is retarded:

    @dreikin said in PSA: JavaScript is retarded:

    WebAssembly is a thing.

    Is it a thing that anyone is actually using yet?

    I seriously doubt it.The assembler and linker is there (binaryen) and the browser support is there, but there are is severe shortage of actually useful compilers targeting it. There is only emscripten for C++, which still looks like a one-man show, and Rust has official target, but while it's use is growing fast, it's still nowhere near mainstream language. And I don't see compiler for any other language (apparently there is no managed heap yet and languages like Java and C# have to wait until there is).

    Actually, it's a LLVM compiler and doesn't have to be specific to Rust or C++. You could compile .NET Core in Clang and turn that into WebAsm (with a heavy number of tweaks) and then load .NET binaries directly.


  • Discourse touched me in a no-no place

    @pie_flavor said in PSA: JavaScript is retarded:

    Actually, it's a LLVM compiler and doesn't have to be specific to Rust or C++.

    If that's so, the annoying bit will be the part of the runtime that binds to the outside world (OS, browser, windowing system, etc.) and those bindings are the key to what a real world application can actually do.



  • @pie_flavor said in PSA: JavaScript is retarded:

    Actually, it's a LLVM compiler

    LLVM is only a backend. To make it a compiler, it needs a front-end too.

    Now there are more front-ends that use LLVM backend, but only Clang (C/C++/ObjC) and Rust are production quality and have significant user-base. Additionally LDC (D), Stacker and Julia can be considered stable, but niche. And then there is a bunch of half-dead experimental ones including Java and C# (in Mono), but those are not really practical.

    @pie_flavor said in PSA: JavaScript is retarded:

    You could compile .NET Core in Clang and turn that into WebAsm

    Yes, you probably “could”. It would be absurdly slow because all the efficient run-cores depend on the properties of the underlying platform which can't be used here.


  • ♿ (Parody)

    @dkf said in PSA: JavaScript is retarded:

    @pie_flavor said in PSA: JavaScript is retarded:

    Actually, it's a LLVM compiler and doesn't have to be specific to Rust or C++.

    If that's so, the annoying bit will be the part of the runtime that binds to the outside world (OS, browser, windowing system, etc.) and those bindings are the key to what a real world application can actually do.

    Well, I guess the browsers are already working on this:

    0_1507674764334_1995c07d-7a19-4be0-8ae4-3827fb76d077-image.png


  • Considered Harmful

    @boomzilla said in PSA: JavaScript is retarded:

    0_1507674764334_1995c07d-7a19-4be0-8ae4-3827fb76d077-image.png

    E_DUPLICATE_RECORD at ordinal 4 (previous: 2)


  • Discourse touched me in a no-no place

    @bulb said in PSA: JavaScript is retarded:

    To make it a compiler, it needs a front-end too.

    It does have a native language that it supports, but you probably don't want to write text-form LLVM IR by hand if you can help it.


  • 🚽 Regular

    > let x = [1, 2, 3];
    undefined
    > let fakeArr = {0: 'a', 1: 'b', length: 2};
    undefined
    > Array.prototype.map.call(fakeArr, x =>x+x)
    [ 'aa', 'bb' ]
    > [...fakeArr]
    Uncaught TypeError: object is not iterable (cannot read property Symbol(Symbol.iterator))
    > x.concat(fakeArr)
    [ 1, 2, 3, { '0': 'a', '1': 'b', length: 2 } ]
    > fakeArr[Symbol.isConcatSpreadable] = true;
    true
    > x.concat(fakeArr)
    [ 1, 2, 3, 'a', 'b' ]
    > [...fakeArr]
    Uncaught TypeError: object is not iterable (cannot read property Symbol(Symbol.iterator))
    >


  • @Zecc :surprised-pikachu:

    This is what you get when a language is modernized while maintaining backward compati(de)bility.

    The new operations are defined in terms of special methods, which are defined in Array prototype, but the old ones were defined in terms of looking at length and then iterating for(i = 0; i < x.length; ++i) and can't be changed because of above mentioned compatidebility.


Log in to reply