19 ms·

0.2 + 0.1 === 0.3 That's not really a JS problem, that's a floating point problem. Plenty of languages will have the same issue. +!![] "" - - "" (null - 0)

0.2 + 0.1 === 0.3 That's not really a JS problem, that's a floating point problem. Plenty of languages will have the same issue. +!![] "" - - "" (null - 0) + "0" Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. It's like picking examples from the Annual Obfuscated C Contest to show how hard it is to understand C. Yes, some languages enable you to write weird garbage code that's hard to reason about, and ideally they wouldn't because enforcing sane code would be great, but come on. Most of these things aren't a big problem that we suffer every day. Just be moderately careful about casting things from one data type to another and all these problems go away.

bruce343434 5y ago
Yup, garbage in garbage out. I'm not a huge fan of JS, but this sort of criticism is absurd.
- wdroz 5y ago
  I rather have the language say "Error, this is garbage!" than silently output garbage.
  - madeofpalk 5y ago
    Which is why we use Typescript
    - AnIdiotOnTheNet 5y ago
      The fact that there has to be a different language on top of your language to make it same days all that needs saying really.
      - lotsofcows 5y ago
        I keep having this argument with my boss but he refuses to let me write machine code.
        dangerbird2 5y ago
        If the good lord wanted us to code in assembly language, he'd have made transistors operate on mnemonics, not electric currents.
        lostcolony 5y ago
        If the good lord had wanted us to interact with transistors based on mnemonics, not electrical currents, he'd have implemented our brains in mnemonics, not electrical currents.
        akiselev 5y ago
        Nitpick: voltage potentials and ion channels. There's not much actual current flowing.
        AstralStorm 5y ago
        Nitpick over nitpick: synapses are not exactly electrical or ion current based, they have active transporters. If all electrical activity ceases, does memory survive? (Answer is very likely yes given cryonic experiments. Brain is protein, ion currents have tendency to auto fire on defrost.)
        akiselev 5y ago
        Ah, I was under the mistaken assumption that ion transport was a subset of ion channels but I see now the latter is passive only.
      - madeofpalk 5y ago
        Pragmatism of an runtime/ecosystem that highly favors backwards compatibility above all else.
      - deleted 5y ago
        [deleted]
      - Griffinsauce 5y ago
        This goes for all compiled languages?
        AnIdiotOnTheNet 5y ago
        We invented compiled languages because of issues with writing everything in assembly. In other words, we invented C because assembly wasn't very good. Just like we invented TypeScript because JavaScript wasn't very good.
      - AnIdiotOnTheNet 5y ago
        Man do I hate my phone's autocorrect. For anyone confused as shit: The fact that there has to be a different language on top of your language to make it sane says all that needs saying really.
    - cygned 5y ago
      Typescript doesn’t save you from all the weird things happening at runtime. A missing check at a context boundary and you can have a wild time (been there).
      - kevinmgranger 5y ago
        Context boundary meaning where it interfaces with javascript?
        cygned 5y ago
        The points where you parse JSON, for example.
        sli 5y ago
        This particular annoyance has made me a huge fan of Elm's (and other languages') JSON decoders, and specifically No Red Ink's JSON decoding pipeline. All the type safety I could ever want and no falling back to writing defensive JS to maintain safety at runtime.
  - hajile 5y ago
    The sad truth is that this stuff was not in the first version of JS. It was added AT THE REQUEST OF DEVS (a decision Eich has said he regrets). Like most bad things, it's only around because a big company said so. Like all bad things in JS, there was a push to remove it at ECMA, but Microsoft had reverse-engineered JS into JScript and refused to go along with the changes to fix the weirdness.
  - blacktriangle 5y ago
    The root of the problem is the original intent of Javascript. Javascript was intended to be a small layer of dynamism added to web pages that were mostly defined via HTML which were presented to a human for interpretation. When your user agent is a human trying to look up an address for a restaurant, they can look at a garbled piece of crap where the JS crashed and still maybe find what they were looking for in the rendered text. Limp along the best you can is a great failure strategy for Javascript's original use-case. Only now that we've turned Javascript into a general purpose programming language is this a failure. Even Javascript's weak typing makes sense in this case. Why automatically convert everything? Becausethe expectation was that inputs to your Javascript would be HTML attributes which are all strings. Automating type conversions from strings made sense. But once you move to larger scale programing, Javascript's weak typing is awful
blowski 5y ago
Exactly. Finding flaws in a language doesn't mean the language is bad, just that it has... flaws. The proof that JS is actually pretty good is that it has been used to build so many things. Like the old adage about economics, these criticisms are taking something that works in practice and trying to see if it works in theory.
- anoncake 5y ago
  No. Popularity does not indicate quality. Judging the quality of something by its popularity is a form of cyclical reasoning. Especially when there is an obvious alternative explanation, namely that JS is the only language you can in the browser without transpiling and for a long time the only one period. While the fact JS can be used to build all these things puts a floor on its quality, that floor is uselessly low.
  - blowski 5y ago
    I'm not using popularity as the metric. "1 million identical websites were built with JavaScript" wouldn't say much beyond the first website. But that there is a very broad range of successful applications partly relying on JavaScript for their success undercuts the idea that JavaScript is inherently rubbish. Whether it has some subjective "quality" is a conversation best left for art galleries.
    - anoncake 5y ago
      If you say JS is "pretty good" how is that not a statement about its quality?
      - blowski 5y ago
        Fair point. I guess I could rephrase it as "JavaScript provides a lot of value".
    - joelfolksy 5y ago
      "The proof that JS is actually pretty good is that it has been used to build so many things." [French Narrator] 5 minutes later... "I'm not using popularity as the metric."
wartijn_ 5y ago
The site does say so in the introduction > Even if you're a JS developer, most of this syntax is probably, and hopefully, not something you use in your daily life. So I think you should look at this site more as something fun you might not have known if you're an js developer than as criticism of js. That being said, the !!"" isn't that weird of a syntax is it? I see and use the double exclamation mark all the time.
- leoc 5y ago
  > that weird of a syntax ought to be "that weird a syntax": it's 'so [adjective] a [noun]' not 'so [adjective] of a [noun]'. It's 'so much of a syntax' but that's because 'much' is a determiner not an adjective, which really makes a much difference. Or if you want to be plain-spoken you can ofc just say 'such a weird syntax'.
  - KMnO4 5y ago
    English is as weird as JavaScript.
    - bryanrasmussen 5y ago
      no, it's fine - you just need the right education https://publicdomainreview.org/collection/english-as-she-is-spoke-1884 https://publicdomainreview.org/collection/english-as-she-is-...
  - blowski 5y ago
    https://english.stackexchange.com/a/30012/7762 https://english.stackexchange.com/a/30012/7762
    - leoc 5y ago
      Yes, the quotation from dictonary.com exactly supports what I am saying. It's a piece of spoken dialect not standard English. It's as if I was after using hiberno-English constructions in a HN comment. Will you go on out of that.
nly 5y ago
> That's not really a JS problem, that's a floating point problem More accurately it's a binary problem. 0.1 and 0.3 have non-terminating representations in binary, so it's completely irrelevant whether you're using fixed or floating point. Any number that can be represented as the sum of powers of 2 and 5 have a terminating decimal representation, whereas only numbers that can be represented as the sum of powers of 2 have a terminating representation in binary. The latter is clearly a subset of the former, so it seems obvious that we should be using decimal types by default in our programming languages. Oh well.
- xingyzt 5y ago
  Floating bar numbers are an interesting way of giving terminating representations to more commonly used decimals. Each number is essentially a numerator and denominator pair, with some bits to indicate the position of the division bar separating them. https://iquilezles.org/www/articles/floatingbar/floatingbar.htm https://iquilezles.org/www/articles/floatingbar/floatingbar....
- tpm 5y ago
  It's not a binary problem, it's a particular binary representation problem. You can represent 0.1 and 0.3 such that it terminates. In Java for example just use BigDecimal (integer unscaled value + integer scale) and you are ok.
  - josefx 5y ago
    The floating point standard defines various float types, the common float/double types are called binary32 and binary64. It also defines decimal types. > integer unscaled value + integer scale binary float does the same, just using 2^exp instead of 10^exp for scale.
- simiones 5y ago
  In pure mathematics, you can get perfect precision with non-terminating fractions. For example, 0.(6) + 0.(3) = 1 is true. The decimal (or binary) representation is just "syntax sugar" for the actual fraction - in this case, 2/3 + 1/3 = 1; or, if you prefer, 10/11 + 1/11 = 1, or 0.(10) + 0.(01) = 1. Note: I'm using a notation for infinitely repeating decimals that I learned in school - 0.(6) means 0.6666666...; 0.(01) means 0.010101010101...
SuchAnonMuchWow 5y ago
Some of them are stretched examples, others comes from other languages/constraints (floating point, octal, ...), but some other are legitimately weird and error prone: [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" [,,,].length // -> 3
- FrontAid 5y ago
  Both of these examples are well-known (and not unexpected) behaviours. I assume you already know why it behaves like that. If not, I can explain it. > [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" What would you expect instead? > [,,,].length // -> 3 Is there any use case where you would want to deal with sparse arrays?
  - realo 5y ago
    [1,2,3] + [4,5,6] An addition operation over two numerical vectors of length 3. I would expect the result to match its inputs and provide a numerical vector of length 3. Thus: [5, 7, 9]
    - fenomas 5y ago
      The issue there is that arrays aren't first class types in JS, they're just objects with numeric property names. So if applying an operator to arrays spread the operation across all the elements that way, it would imply that the same should happen generally for all object properties, with whatever weird implications that would entail. a.foo = 1 b.foo = 'there' a + b // { foo: '1there' } ?
    - meowface 5y ago
      What language has this behavior by default?
      - DangitBobby 5y ago
        Fortran :)
  - 5y ago
viraptor 5y ago
I think the situation is a bit different. This situation looks different in reality. The result may be (null-0)+"0", but the actual code will be foo()-bar()+baz(). And C will at least give you warning about types, even if NULL-0+"0" could give you an address. Plain JS without extra tooling would happily give you the unexpected result. Some other dynamic languages would at least throw an exception about incompatible types for -/+.
- brobdingnagians 5y ago
  We've had these exact same sorts of issues in PHP. It can go undetected for awhile and cause subtle bugs. A good type system helps a lot. I appreciate that Kotlin is more stringent than Java with no implicit conversions between Int/Long/Float/Double.
  - deergomoo 5y ago
    I once lost most of an afternoon debugging an issue where orders in a PHP e-commerce system would very occasionally fail. Turns out several months before, someone was doing some refactoring, moved some methods around, but also changed a "==" to a "===" in the process. Generally a good idea, but it slipped through to production without anyone noticing or breaking any tests. The issue ended up being that a rare code path in a tangentially related method would cause that method to return a float instead of an int. This propagated through, eventually causing a check of 0.0 === 0 to fail where previously 0.0 == 0 passed.
    - irrational 5y ago
      The problem here is == was used in the beginning. Always use ===.
      - johnmaguire 5y ago
        Unfortunately "use X from the beginning" is rarely a solution when you're no longer at the beginning.
- 5y ago
z3t4 5y ago
Also things like +!![] is because while JS is dynamic it does have a very strict type system! ![] becomes a boolean +true becomes a number.
- viraptor 5y ago
  This is a result of the implicit type conversion feature rather than a strict type system.
- simiones 5y ago
  JS has a very weak type system, full of implicit conversions. In dynamic languages with strong type systems, like Common Lisp, such operations typically result in errors: (+ (not (not '()))) The value NIL is not of the expected type NUMBER. Similarly in Ruby: +!![] undefined method `+@' for true:TrueClass (NoMethodError) [Condition of type TYPE-ERROR] Interestingly, Python does the same thing as JS in this case, even though it is typically quite strongly typed. Edit: not quite the same, as the empty array is converted to False in Python, just as it is in Ruby (in CL, nil/'() IS the canonical false value); but still, Python outputs 0, it doesn't complain like the other two.
  - epidemian 5y ago
    > Interestingly, Python does the same thing as JS in this case, even though it is typically quite strongly typed. [...] > Python outputs 0, it doesn't complain like the other two. yep, this is one of those Python weird bits. in Python, booleans are ints, True is 1 and 0 is False. and i don't mean it in a JS-ish way like "they can be converted to...". no, True is the integer value 1. in fact, the type bool is a subtype of int. if you think of types as sets of values, and subtypes as subsets of their parent set, that `book < int` relation suddenly makes a lot of sense ;) >>> +(not not []) 0 >>> (not not []) False >>> 0 == False True >>> 1 == True True >>> True + True 2 >>> True - False + True * 0.5 1.5 >>> isinstance(False, bool) True >>> isinstance(False, int) True >>> bool < int True so, if you accept that the operation `not []` makes sense to be defined as True (because `bool([])` is False), and that it makes sense for False to be the integer 0, then `+(not not [])` being 0 is just a logical consequence of that :) for the record, i do think it's weird for Python to define bools as ints, and to make all values define a boolean semantics via __bool__().
wruza 5y ago
The same for “== considered harmful”. I scanned the entire comparison table and the only unobvious or error-prone cases are those you never really do in programming. https://stackoverflow.com/a/23465314 https://stackoverflow.com/a/23465314 For me it’s only rows [[]], [0], [1], i.e. array-unfolding related, but all others are regular weak-typed comparisons like in perl and other dynamic semantics. <snip> Edit: just realized “if (array)” is okay, nevermind.
- emteycz 5y ago
  undefined and null sometimes make problems. IMHO it's good that undefined == null but some people don't realize.
  - wruza 5y ago
    I agree. If native apis didn’t return nulls in some cases, and undefined was named “undef” at least, null could be ditched. But then again, it’s only because js has no bad habit of treating the same of non-existence and undefinedness^. If not json (which has no undefined), we could ditch null. But it’s there and with === it leads to either object.someField === null || object.someFeild === undefined madness, or to a potential error if a programmer thinks that null can not be there. We could do an exception for null === undefined, but it’s against its spirit and will not be accepted. ^ languages that treat non-existent key as undefined are usually doomed to introduce Null atom in some form, or to work around that limitation constantly in metaprogramming
    - blacktriangle 5y ago
      null and undefined is one of the things Javascript actually got right imo. Undefined is what lets Javascript turn what other dynamic language would throw as a runtime error into a value. "I do not have a definition for the thing you want" and "the thing you want is known to be unknown" are two totally different concepts that languages with only null to lean on must collapse into a single concept.
      - 5y ago
e3bc54b2 5y ago
In my humble and admittedly little experience, its not what you intentionally write, but what gets unintentionally written and needs to be debugged later. Carmack-like people utilising this stuff for good are few and far between, for your everyday joe programmer this is a footgun, a very-nonobvious and non-intuitive one (hence footgun moniker) that they write in crunch, it slips past reviews because reviewers are just joes with couple extra years, if at all, and then whrn things break after deployment, its an absolute pain to debug.
- bostonsre 5y ago
  Yea.. "clever" devs can be a nightmare to have in teams. "I implemented all of that functionality in less than one hour" is great and all but it is just tech debt that needs to be re-factored later and costs ridiculous amounts of time to support and maintain until its re-written.
fenomas 5y ago
Yeah, a lot of these have nothing to do with JS. I have no idea what the site is trying to accomplish. I mean: !!!true In what language does that (or its equivalent) not evaluate to false?
- dolmen 5y ago
  In Go: https://play.golang.org/p/G8jOKtIj4AY https://play.golang.org/p/G8jOKtIj4AY
  - Sebb767 5y ago
    Can anyone explain this to me?
    - svieira 5y ago
      Looks like the `true` and `false` _bindings_ in Go are mutable and can be re-assigned. The same thing was possible in Python 2, IIRC: False, True = True, False # Have fun debugging!
      - Sebb767 5y ago
        Ah, I missed that line. Now I feel stupid ;)
    - Cthulhu_ 5y ago
      They're defining a const named true and false to their inverse values, shadowing the builtin true/false keywords.
    - carl_dr 5y ago
      !!!true is equal to false in JS, and in Go (and in any other language I can think of.) In that Go example above, the author is reassigning true and false to be their opposites.
    - JoeCortopassi 5y ago
      `!` is added to values in most languages as a shorthand for saying "give me the opposite boolean value of this. So `!true` would equal `false` Some people add two exclamation points as a shorthand to cast a value to a boolean. So if you wanted to see if something was 'truthy', you could say `!!truthyValue` and it would return ` true` instead of the value itself. Literally what your asking the language is "give me the opposite boolean value of the opposite boolean value of `truthyValue`" Now you can probably see why three exclamation points is silly, it's not giving you anything that a single exclamation point wouldn't give you. Both `!truthyValue` and `!!!truthyValue` evaluate to false, you are literally saying "give me the opposite boolean value of the opposite boolean value of the opposite boolean value of `truthyValue`" The example in Go is intentionally misleading because Go lets you reassign the values for `true` and `false`. It's going through all the same steps I described above, but it's starting with a value opposite of what you think it is
lkjoi23j3oijf 5y ago
In C# you don't have such a problem and 0.2 + 0.1 is exactly 0.3. Proof: https://dotnetfiddle.net/qTiq6U https://dotnetfiddle.net/qTiq6U
- viraptor 5y ago
  In every language where you can use a decimal the result will match exactly. That's... not what's discussed here and it's not a default in c# either.
  - lkjoi23j3oijf 5y ago
    Unlike other languages, in JS you don't have decimals... So you stuck writing a garbage code by multiplying all floating point numbers by a factor to avoid rounding errors.
    - esrauch 5y ago
      I don't think that's fair: C# has decimals but everyone uses floating point numbers by default so C# developers still need to know that 0.1+0.2 != 0.3
    - hajile 5y ago
      The last couple generations of POWER chips from IBM have implementations of decimal32, decimal64, and decimal128. To my knowledge, no other big-name, general-purpose CPU has these. To "implement decimal numbers" in .net on x86 hardware simply means writing a custom decimal implementation in software. JS had implicit integers since the beginning. It has had arrays of integers (what's necessary for fast decimal implementations) since BEFORE the release of WebGL a decade ago. It has also added BigInt this year. Just like .net, there's decimal libraries available if you know to use them. https://github.com/MikeMcl/decimal.js/ https://github.com/MikeMcl/decimal.js/ The real takeaway is that modern processors should definitely add hardware support for decimal numbers.
moron4hire 5y ago
Those last examples happen when you have variables containing those values. Without strict type checking, it gets really hard to know in all situations (especially when you're pulling values from a service) what you will have in there. And if a service changes, you won't have a lot of warning in your client code. So yes, these kinds of errors are very common.
zelphirkalt 5y ago
I am sure a reasonable person and educated computer programming person will be able to avoid these traps, by adhering to certain standards. However, you often have that other person on your team, who does not care about being careful and writes code like it is to be once written and never touched again. And that's where the danger creeps in.
- saurik 5y ago
  Entirely orthogonal to these operator semantics being unreasonable, that person should not be on your team: replace them with someone who cares.
holtalanm 5y ago
> Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. That is the whole premise of the site, though. They even say that these examples aren't common syntax or patterns before you start.
- some_random 5y ago
  The site is called "JavaScript Is Weird", not "Weird Javascript", even if they tell you that the examples aren't common they're still saying that this weirdness is unique to JS. Which definitely isn't true in the case of basic floating point precision problems
  - holtalanm 5y ago
    > The site is called "JavaScript Is Weird", not "Weird Javascript" am i being punkd?
    - sli 5y ago
      The former is a general statement about Javascript itself as a whole while the latter is describing a set of examples.
giancarlostoro 5y ago
Someone had linked on here a website that showed the 0.3 thing in practically almost every programming language and their output. I wish I could remember the domain / url cause it is interesting to compare languages defaults. I know most languages have ways to handle it correctly.
- onion2k 5y ago
  I know most languages have ways to handle it correctly. Including JS - http://mikemcl.github.io/decimal.js/ http://mikemcl.github.io/decimal.js/
  - dvlsg 5y ago
    There's a proposal to add a decimal type to the spec, too. https://github.com/tc39/proposal-decimal https://github.com/tc39/proposal-decimal Seems like it's a long ways away from being available, though.
- dvlsg 5y ago
  https://0.30000000000000004.com/ https://0.30000000000000004.com/
  - giancarlostoro 5y ago
    Yes this is it! Thanks for that, I do appreciate that they show multiple approaches in each language to showcase which one gives you the desired result.
deleted 5y ago
[deleted]
epidemian 5y ago
you're right in both points technically, but if that means that somehow these things don't make JS "weird" for people to learn/program, then i disagree > that's a floating point problem. Plenty of languages will have the same issue. yes, many (most) other languages do have the same floating point issues, but that doesn't make them less weird. JS numbers are IEEE floating point numbers, therefore floating point issues/weirdness are also JS issues/weirdness :) > Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. the verbatim code snippets in particular, yes, you're completely right. but the underlying problems that these snippets exemplify are still there on actual "real" running code. they just look less suspicious on the surface. > Just be moderately careful about casting things from one data type to another and all these problems go away. true. but still, these things can happen, and when they happen, they tend to sneakily manifest as weird UI bugs, like rendering "NaN" or "undefined" on the screen (we have all seen those... there's plenty of meme images about them too), instead of noisily breaking with an exception, which is way more noticeable and actionable for us programmers when doing introducing these bugs in the first place hehe. it's true that they are not the most common kind of bugs, i'll give you that, but when they happen, they can be incredibly frustrating in my experience, because you may only realize after they have been affecting user for a looong time (maybe years), but you just didn't know because JS decided it was a good idea to carry on after one of these nonsense operations like adding an array to a number, giving you nonsense results instead of useful (runtime) type errors. story time! i remember an ugly case of this which involved some search filters on a big-ish system. the JS code was quite generic in how it handled filters, and looked fine. for some time, all filters were single-value, as simple strings, but at some point the system started handling multi-value filters, which were encoded as arrays of strings. well, the programmers who implemented the UI for multi-valued filters just tried sending array of strings as filters to the existing filtering system, and it seemed to work correctly in the results it yielded, so they assumed the code was prepared for that too (it looked generic enough), and so they shipped the feature that way. it was only years later, when i was porting some of that code to typescript, that typescript complained about invalid type operations. i was converting between languages pretty willy-nilly and assuming the existing system worked correctly, so i suspected typescript was being dumb with that type error. but no, it was actually complaining about an actual bug. when passing arrays of strings as filters, the underlying filtering system was at some point coercing those arrays to strings by accident. so ['apples', 'oranges'] became 'apple,oranges'. the search results were always right when the multi-valued filters had only one value (because ['apples'] coerced to string is 'apples') and kinda right in some naive cases of multi-valued filters (because of how the text search engine worked), which was probably why the original programmers thought it was working correctly and didn't give it much more though or more thorough testing. but the search results were definitely not correct in most non-naive cases of multi-valued filters. so our users had been affected by this bug of multi-value search filters basically not working for years, and we only discovered it by accident when porting some of the JS code to typescript because typescript was kind enough to tell us about this nonsense operation statically, without having to even run the code. i wish that JS were also kind enough to complain about these nonsense operations, albeit at runtime. it would have made this problem obvious from the get go, and would have prevented the original programmers from shipping a broken feature to thousands of users. plot twist: although the story may make it seem that i was the competent programmer that figured it all out when porting the code to typescript, in reality "the original programmers" also included me (probably, i don't remember really), just some time before the typescript port :/
Tainnor 5y ago
I've been thinking for a while that modern languages shouldn't default to floating point computations. They're exactly the right thing if you do data stuff or scientific computing, but given how much of the internet relies on things like e-commerce and how often floating point is still misused for dealing with money, coupled with the fact that even many senior developers aren't fully aware of the subtleties of floating point, I don't understand why we keep making them the default. If a user does need to do scientific computing, they could use a "# use-floating-point" pragma or something so that literals get interpreted as floating point. Otherwise, we map them to rationals. Of course, doing rational arithmetic is much slower (for example, Gaussian elimination is exponential for arbitrary precision rationals, while it's famously O(n^3) for floating point), so there's a danger of people accidentally using it in triply nested loops etc., but I have a feeling that if you need to do that kind of thing you know that you might run into performance issues and you think twice.
- denton-scratch 5y ago
  > "# use-floating-point" pragma I haven't come across the "pragma" directive in a Javascript context. I guess it's another new feature (I have trouble keeping up these days).
  - Tainnor 5y ago
    I don't think they have it (although, you can do whatever you want with babel nowadays, I guess). It was a suggestion aimed at programming languages in general.
    - akiselev 5y ago
      The javascript equivalent would be an expression like 'use strict';
      - denton-scratch 5y ago
        I was being flip; I should have used a smiley, I guess. Sorry.
jandrese 5y ago
Knowing that the underlying representation will vary is CS101 material. It applies to almost every language because that's how the hardware works.
- BrissyCoder 5y ago
  Hardware doesn't exist in any meaningful way for 90% or professional programmers anymore. Way too much abstraction for that to be an argument.
  - denton-scratch 5y ago
    I don't agree. Even if you aren't programming microcontrollers, even if you're just building brochure websites for mobiles, you'll do it better if you understand hardware.
    - BrissyCoder 5y ago
      > you'll do it better if you understand hardware. Oh for sure. I agree. That's not what we're arguing though.
rileytg 5y ago
We have this on our interview test. It was the one almost everyone got wrong except for a couple people who ended up being really detail oriented and had deep knowledge (as opposed to broad). We consider >70% passing.
- mewpmewp2 5y ago
  I'd honestly consider these types of questions one of the poorest ways to test front end developers. The only reason I have learned some of that oddball stuff with JavaScript is because of some job interviews e.g. when I was earlier in my career, I used to Google things like "top 30 questions asked in a JS interview", etc, but I forget it after that until I'm about to look for another job. However I wouldn't do this type of learning any longer, since I wouldn't want to apply for a company asking these types of questions. In the end at work you should use ES6/TypeScript with linting, proper tests and these cases would never occur.

bruce343434 5y ago

Yup, garbage in garbage out. I'm not a huge fan of JS, but this sort of criticism is absurd.

wdroz 5y ago
I rather have the language say "Error, this is garbage!" than silently output garbage.
- madeofpalk 5y ago
  Which is why we use Typescript
  - AnIdiotOnTheNet 5y ago
    The fact that there has to be a different language on top of your language to make it same days all that needs saying really.
    - lotsofcows 5y ago
      I keep having this argument with my boss but he refuses to let me write machine code.
      - dangerbird2 5y ago
        If the good lord wanted us to code in assembly language, he'd have made transistors operate on mnemonics, not electric currents.
        lostcolony 5y ago
        If the good lord had wanted us to interact with transistors based on mnemonics, not electrical currents, he'd have implemented our brains in mnemonics, not electrical currents.
        akiselev 5y ago
        Nitpick: voltage potentials and ion channels. There's not much actual current flowing.
        AstralStorm 5y ago
        Nitpick over nitpick: synapses are not exactly electrical or ion current based, they have active transporters. If all electrical activity ceases, does memory survive? (Answer is very likely yes given cryonic experiments. Brain is protein, ion currents have tendency to auto fire on defrost.)
        akiselev 5y ago
        Ah, I was under the mistaken assumption that ion transport was a subset of ion channels but I see now the latter is passive only.
    - madeofpalk 5y ago
      Pragmatism of an runtime/ecosystem that highly favors backwards compatibility above all else.
    - deleted 5y ago
      [deleted]
    - Griffinsauce 5y ago
      This goes for all compiled languages?
      - AnIdiotOnTheNet 5y ago
        We invented compiled languages because of issues with writing everything in assembly. In other words, we invented C because assembly wasn't very good. Just like we invented TypeScript because JavaScript wasn't very good.
    - AnIdiotOnTheNet 5y ago
      Man do I hate my phone's autocorrect. For anyone confused as shit: The fact that there has to be a different language on top of your language to make it sane says all that needs saying really.
  - cygned 5y ago
    Typescript doesn’t save you from all the weird things happening at runtime. A missing check at a context boundary and you can have a wild time (been there).
    - kevinmgranger 5y ago
      Context boundary meaning where it interfaces with javascript?
      - cygned 5y ago
        The points where you parse JSON, for example.
        sli 5y ago
        This particular annoyance has made me a huge fan of Elm's (and other languages') JSON decoders, and specifically No Red Ink's JSON decoding pipeline. All the type safety I could ever want and no falling back to writing defensive JS to maintain safety at runtime.
- hajile 5y ago
  The sad truth is that this stuff was not in the first version of JS. It was added AT THE REQUEST OF DEVS (a decision Eich has said he regrets). Like most bad things, it's only around because a big company said so. Like all bad things in JS, there was a push to remove it at ECMA, but Microsoft had reverse-engineered JS into JScript and refused to go along with the changes to fix the weirdness.
- blacktriangle 5y ago
  The root of the problem is the original intent of Javascript. Javascript was intended to be a small layer of dynamism added to web pages that were mostly defined via HTML which were presented to a human for interpretation. When your user agent is a human trying to look up an address for a restaurant, they can look at a garbled piece of crap where the JS crashed and still maybe find what they were looking for in the rendered text. Limp along the best you can is a great failure strategy for Javascript's original use-case. Only now that we've turned Javascript into a general purpose programming language is this a failure. Even Javascript's weak typing makes sense in this case. Why automatically convert everything? Becausethe expectation was that inputs to your Javascript would be HTML attributes which are all strings. Automating type conversions from strings made sense. But once you move to larger scale programing, Javascript's weak typing is awful

blowski 5y ago

Exactly. Finding flaws in a language doesn't mean the language is bad, just that it has... flaws. The proof that JS is actually pretty good is that it has been used to build so many things. Like the old adage about economics, these criticisms are taking something that works in practice and trying to see if it works in theory.

anoncake 5y ago
No. Popularity does not indicate quality. Judging the quality of something by its popularity is a form of cyclical reasoning. Especially when there is an obvious alternative explanation, namely that JS is the only language you can in the browser without transpiling and for a long time the only one period. While the fact JS can be used to build all these things puts a floor on its quality, that floor is uselessly low.
- blowski 5y ago
  I'm not using popularity as the metric. "1 million identical websites were built with JavaScript" wouldn't say much beyond the first website. But that there is a very broad range of successful applications partly relying on JavaScript for their success undercuts the idea that JavaScript is inherently rubbish. Whether it has some subjective "quality" is a conversation best left for art galleries.
  - anoncake 5y ago
    If you say JS is "pretty good" how is that not a statement about its quality?
    - blowski 5y ago
      Fair point. I guess I could rephrase it as "JavaScript provides a lot of value".
  - joelfolksy 5y ago
    "The proof that JS is actually pretty good is that it has been used to build so many things." [French Narrator] 5 minutes later... "I'm not using popularity as the metric."

wartijn_ 5y ago

The site does say so in the introduction > Even if you're a JS developer, most of this syntax is probably, and hopefully, not something you use in your daily life. So I think you should look at this site more as something fun you might not have known if you're an js developer than as criticism of js. That being said, the !!"" isn't that weird of a syntax is it? I see and use the double exclamation mark all the time.

leoc 5y ago
> that weird of a syntax ought to be "that weird a syntax": it's 'so [adjective] a [noun]' not 'so [adjective] of a [noun]'. It's 'so much of a syntax' but that's because 'much' is a determiner not an adjective, which really makes a much difference. Or if you want to be plain-spoken you can ofc just say 'such a weird syntax'.
- KMnO4 5y ago
  English is as weird as JavaScript.
  - bryanrasmussen 5y ago
    no, it's fine - you just need the right education https://publicdomainreview.org/collection/english-as-she-is-spoke-1884 https://publicdomainreview.org/collection/english-as-she-is-...
- blowski 5y ago
  https://english.stackexchange.com/a/30012/7762 https://english.stackexchange.com/a/30012/7762
  - leoc 5y ago
    Yes, the quotation from dictonary.com exactly supports what I am saying. It's a piece of spoken dialect not standard English. It's as if I was after using hiberno-English constructions in a HN comment. Will you go on out of that.

nly 5y ago

> That's not really a JS problem, that's a floating point problem More accurately it's a binary problem. 0.1 and 0.3 have non-terminating representations in binary, so it's completely irrelevant whether you're using fixed or floating point. Any number that can be represented as the sum of powers of 2 and 5 have a terminating decimal representation, whereas only numbers that can be represented as the sum of powers of 2 have a terminating representation in binary. The latter is clearly a subset of the former, so it seems obvious that we should be using decimal types by default in our programming languages. Oh well.

xingyzt 5y ago
Floating bar numbers are an interesting way of giving terminating representations to more commonly used decimals. Each number is essentially a numerator and denominator pair, with some bits to indicate the position of the division bar separating them. https://iquilezles.org/www/articles/floatingbar/floatingbar.htm https://iquilezles.org/www/articles/floatingbar/floatingbar....
tpm 5y ago
It's not a binary problem, it's a particular binary representation problem. You can represent 0.1 and 0.3 such that it terminates. In Java for example just use BigDecimal (integer unscaled value + integer scale) and you are ok.
- josefx 5y ago
  The floating point standard defines various float types, the common float/double types are called binary32 and binary64. It also defines decimal types. > integer unscaled value + integer scale binary float does the same, just using 2^exp instead of 10^exp for scale.
simiones 5y ago
In pure mathematics, you can get perfect precision with non-terminating fractions. For example, 0.(6) + 0.(3) = 1 is true. The decimal (or binary) representation is just "syntax sugar" for the actual fraction - in this case, 2/3 + 1/3 = 1; or, if you prefer, 10/11 + 1/11 = 1, or 0.(10) + 0.(01) = 1. Note: I'm using a notation for infinitely repeating decimals that I learned in school - 0.(6) means 0.6666666...; 0.(01) means 0.010101010101...

SuchAnonMuchWow 5y ago

Some of them are stretched examples, others comes from other languages/constraints (floating point, octal, ...), but some other are legitimately weird and error prone: [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" [,,,].length // -> 3

FrontAid 5y ago
Both of these examples are well-known (and not unexpected) behaviours. I assume you already know why it behaves like that. If not, I can explain it. > [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" What would you expect instead? > [,,,].length // -> 3 Is there any use case where you would want to deal with sparse arrays?
- realo 5y ago
  [1,2,3] + [4,5,6] An addition operation over two numerical vectors of length 3. I would expect the result to match its inputs and provide a numerical vector of length 3. Thus: [5, 7, 9]
  - fenomas 5y ago
    The issue there is that arrays aren't first class types in JS, they're just objects with numeric property names. So if applying an operator to arrays spread the operation across all the elements that way, it would imply that the same should happen generally for all object properties, with whatever weird implications that would entail. a.foo = 1 b.foo = 'there' a + b // { foo: '1there' } ?
  - meowface 5y ago
    What language has this behavior by default?
    - DangitBobby 5y ago
      Fortran :)
- 5y ago

viraptor 5y ago

I think the situation is a bit different. This situation looks different in reality. The result may be (null-0)+"0", but the actual code will be foo()-bar()+baz(). And C will at least give you warning about types, even if NULL-0+"0" could give you an address. Plain JS without extra tooling would happily give you the unexpected result. Some other dynamic languages would at least throw an exception about incompatible types for -/+.

brobdingnagians 5y ago
We've had these exact same sorts of issues in PHP. It can go undetected for awhile and cause subtle bugs. A good type system helps a lot. I appreciate that Kotlin is more stringent than Java with no implicit conversions between Int/Long/Float/Double.
- deergomoo 5y ago
  I once lost most of an afternoon debugging an issue where orders in a PHP e-commerce system would very occasionally fail. Turns out several months before, someone was doing some refactoring, moved some methods around, but also changed a "==" to a "===" in the process. Generally a good idea, but it slipped through to production without anyone noticing or breaking any tests. The issue ended up being that a rare code path in a tangentially related method would cause that method to return a float instead of an int. This propagated through, eventually causing a check of 0.0 === 0 to fail where previously 0.0 == 0 passed.
  - irrational 5y ago
    The problem here is == was used in the beginning. Always use ===.
    - johnmaguire 5y ago
      Unfortunately "use X from the beginning" is rarely a solution when you're no longer at the beginning.
5y ago

z3t4 5y ago

Also things like +!![] is because while JS is dynamic it does have a very strict type system! ![] becomes a boolean +true becomes a number.

viraptor 5y ago
This is a result of the implicit type conversion feature rather than a strict type system.
simiones 5y ago
JS has a very weak type system, full of implicit conversions. In dynamic languages with strong type systems, like Common Lisp, such operations typically result in errors: (+ (not (not '()))) The value NIL is not of the expected type NUMBER. Similarly in Ruby: +!![] undefined method `+@' for true:TrueClass (NoMethodError) [Condition of type TYPE-ERROR] Interestingly, Python does the same thing as JS in this case, even though it is typically quite strongly typed. Edit: not quite the same, as the empty array is converted to False in Python, just as it is in Ruby (in CL, nil/'() IS the canonical false value); but still, Python outputs 0, it doesn't complain like the other two.
- epidemian 5y ago
  > Interestingly, Python does the same thing as JS in this case, even though it is typically quite strongly typed. [...] > Python outputs 0, it doesn't complain like the other two. yep, this is one of those Python weird bits. in Python, booleans are ints, True is 1 and 0 is False. and i don't mean it in a JS-ish way like "they can be converted to...". no, True is the integer value 1. in fact, the type bool is a subtype of int. if you think of types as sets of values, and subtypes as subsets of their parent set, that `book < int` relation suddenly makes a lot of sense ;) >>> +(not not []) 0 >>> (not not []) False >>> 0 == False True >>> 1 == True True >>> True + True 2 >>> True - False + True * 0.5 1.5 >>> isinstance(False, bool) True >>> isinstance(False, int) True >>> bool < int True so, if you accept that the operation `not []` makes sense to be defined as True (because `bool([])` is False), and that it makes sense for False to be the integer 0, then `+(not not [])` being 0 is just a logical consequence of that :) for the record, i do think it's weird for Python to define bools as ints, and to make all values define a boolean semantics via __bool__().

wruza 5y ago

The same for “== considered harmful”. I scanned the entire comparison table and the only unobvious or error-prone cases are those you never really do in programming. https://stackoverflow.com/a/23465314 https://stackoverflow.com/a/23465314 For me it’s only rows [[]], [0], [1], i.e. array-unfolding related, but all others are regular weak-typed comparisons like in perl and other dynamic semantics. <snip> Edit: just realized “if (array)” is okay, nevermind.

emteycz 5y ago
undefined and null sometimes make problems. IMHO it's good that undefined == null but some people don't realize.
- wruza 5y ago
  I agree. If native apis didn’t return nulls in some cases, and undefined was named “undef” at least, null could be ditched. But then again, it’s only because js has no bad habit of treating the same of non-existence and undefinedness^. If not json (which has no undefined), we could ditch null. But it’s there and with === it leads to either object.someField === null || object.someFeild === undefined madness, or to a potential error if a programmer thinks that null can not be there. We could do an exception for null === undefined, but it’s against its spirit and will not be accepted. ^ languages that treat non-existent key as undefined are usually doomed to introduce Null atom in some form, or to work around that limitation constantly in metaprogramming
  - blacktriangle 5y ago
    null and undefined is one of the things Javascript actually got right imo. Undefined is what lets Javascript turn what other dynamic language would throw as a runtime error into a value. "I do not have a definition for the thing you want" and "the thing you want is known to be unknown" are two totally different concepts that languages with only null to lean on must collapse into a single concept.
    - 5y ago

e3bc54b2 5y ago

In my humble and admittedly little experience, its not what you intentionally write, but what gets unintentionally written and needs to be debugged later. Carmack-like people utilising this stuff for good are few and far between, for your everyday joe programmer this is a footgun, a very-nonobvious and non-intuitive one (hence footgun moniker) that they write in crunch, it slips past reviews because reviewers are just joes with couple extra years, if at all, and then whrn things break after deployment, its an absolute pain to debug.

bostonsre 5y ago
Yea.. "clever" devs can be a nightmare to have in teams. "I implemented all of that functionality in less than one hour" is great and all but it is just tech debt that needs to be re-factored later and costs ridiculous amounts of time to support and maintain until its re-written.

fenomas 5y ago

Yeah, a lot of these have nothing to do with JS. I have no idea what the site is trying to accomplish. I mean: !!!true In what language does that (or its equivalent) not evaluate to false?

dolmen 5y ago
In Go: https://play.golang.org/p/G8jOKtIj4AY https://play.golang.org/p/G8jOKtIj4AY
- Sebb767 5y ago
  Can anyone explain this to me?
  - svieira 5y ago
    Looks like the `true` and `false` _bindings_ in Go are mutable and can be re-assigned. The same thing was possible in Python 2, IIRC: False, True = True, False # Have fun debugging!
    - Sebb767 5y ago
      Ah, I missed that line. Now I feel stupid ;)
  - Cthulhu_ 5y ago
    They're defining a const named true and false to their inverse values, shadowing the builtin true/false keywords.
  - carl_dr 5y ago
    !!!true is equal to false in JS, and in Go (and in any other language I can think of.) In that Go example above, the author is reassigning true and false to be their opposites.
  - JoeCortopassi 5y ago
    `!` is added to values in most languages as a shorthand for saying "give me the opposite boolean value of this. So `!true` would equal `false` Some people add two exclamation points as a shorthand to cast a value to a boolean. So if you wanted to see if something was 'truthy', you could say `!!truthyValue` and it would return ` true` instead of the value itself. Literally what your asking the language is "give me the opposite boolean value of the opposite boolean value of `truthyValue`" Now you can probably see why three exclamation points is silly, it's not giving you anything that a single exclamation point wouldn't give you. Both `!truthyValue` and `!!!truthyValue` evaluate to false, you are literally saying "give me the opposite boolean value of the opposite boolean value of the opposite boolean value of `truthyValue`" The example in Go is intentionally misleading because Go lets you reassign the values for `true` and `false`. It's going through all the same steps I described above, but it's starting with a value opposite of what you think it is

lkjoi23j3oijf 5y ago

In C# you don't have such a problem and 0.2 + 0.1 is exactly 0.3. Proof: https://dotnetfiddle.net/qTiq6U https://dotnetfiddle.net/qTiq6U

viraptor 5y ago
In every language where you can use a decimal the result will match exactly. That's... not what's discussed here and it's not a default in c# either.
- lkjoi23j3oijf 5y ago
  Unlike other languages, in JS you don't have decimals... So you stuck writing a garbage code by multiplying all floating point numbers by a factor to avoid rounding errors.
  - esrauch 5y ago
    I don't think that's fair: C# has decimals but everyone uses floating point numbers by default so C# developers still need to know that 0.1+0.2 != 0.3
  - hajile 5y ago
    The last couple generations of POWER chips from IBM have implementations of decimal32, decimal64, and decimal128. To my knowledge, no other big-name, general-purpose CPU has these. To "implement decimal numbers" in .net on x86 hardware simply means writing a custom decimal implementation in software. JS had implicit integers since the beginning. It has had arrays of integers (what's necessary for fast decimal implementations) since BEFORE the release of WebGL a decade ago. It has also added BigInt this year. Just like .net, there's decimal libraries available if you know to use them. https://github.com/MikeMcl/decimal.js/ https://github.com/MikeMcl/decimal.js/ The real takeaway is that modern processors should definitely add hardware support for decimal numbers.

moron4hire 5y ago

Those last examples happen when you have variables containing those values. Without strict type checking, it gets really hard to know in all situations (especially when you're pulling values from a service) what you will have in there. And if a service changes, you won't have a lot of warning in your client code. So yes, these kinds of errors are very common.

zelphirkalt 5y ago

I am sure a reasonable person and educated computer programming person will be able to avoid these traps, by adhering to certain standards. However, you often have that other person on your team, who does not care about being careful and writes code like it is to be once written and never touched again. And that's where the danger creeps in.

saurik 5y ago
Entirely orthogonal to these operator semantics being unreasonable, that person should not be on your team: replace them with someone who cares.

holtalanm 5y ago

> Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. That is the whole premise of the site, though. They even say that these examples aren't common syntax or patterns before you start.

some_random 5y ago
The site is called "JavaScript Is Weird", not "Weird Javascript", even if they tell you that the examples aren't common they're still saying that this weirdness is unique to JS. Which definitely isn't true in the case of basic floating point precision problems
- holtalanm 5y ago
  > The site is called "JavaScript Is Weird", not "Weird Javascript" am i being punkd?
  - sli 5y ago
    The former is a general statement about Javascript itself as a whole while the latter is describing a set of examples.

giancarlostoro 5y ago

Someone had linked on here a website that showed the 0.3 thing in practically almost every programming language and their output. I wish I could remember the domain / url cause it is interesting to compare languages defaults. I know most languages have ways to handle it correctly.

onion2k 5y ago
I know most languages have ways to handle it correctly. Including JS - http://mikemcl.github.io/decimal.js/ http://mikemcl.github.io/decimal.js/
- dvlsg 5y ago
  There's a proposal to add a decimal type to the spec, too. https://github.com/tc39/proposal-decimal https://github.com/tc39/proposal-decimal Seems like it's a long ways away from being available, though.
dvlsg 5y ago
https://0.30000000000000004.com/ https://0.30000000000000004.com/
- giancarlostoro 5y ago
  Yes this is it! Thanks for that, I do appreciate that they show multiple approaches in each language to showcase which one gives you the desired result.

deleted 5y ago

[deleted]

epidemian 5y ago

you're right in both points technically, but if that means that somehow these things don't make JS "weird" for people to learn/program, then i disagree > that's a floating point problem. Plenty of languages will have the same issue. yes, many (most) other languages do have the same floating point issues, but that doesn't make them less weird. JS numbers are IEEE floating point numbers, therefore floating point issues/weirdness are also JS issues/weirdness :) > Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. the verbatim code snippets in particular, yes, you're completely right. but the underlying problems that these snippets exemplify are still there on actual "real" running code. they just look less suspicious on the surface. > Just be moderately careful about casting things from one data type to another and all these problems go away. true. but still, these things can happen, and when they happen, they tend to sneakily manifest as weird UI bugs, like rendering "NaN" or "undefined" on the screen (we have all seen those... there's plenty of meme images about them too), instead of noisily breaking with an exception, which is way more noticeable and actionable for us programmers when doing introducing these bugs in the first place hehe. it's true that they are not the most common kind of bugs, i'll give you that, but when they happen, they can be incredibly frustrating in my experience, because you may only realize after they have been affecting user for a looong time (maybe years), but you just didn't know because JS decided it was a good idea to carry on after one of these nonsense operations like adding an array to a number, giving you nonsense results instead of useful (runtime) type errors. story time! i remember an ugly case of this which involved some search filters on a big-ish system. the JS code was quite generic in how it handled filters, and looked fine. for some time, all filters were single-value, as simple strings, but at some point the system started handling multi-value filters, which were encoded as arrays of strings. well, the programmers who implemented the UI for multi-valued filters just tried sending array of strings as filters to the existing filtering system, and it seemed to work correctly in the results it yielded, so they assumed the code was prepared for that too (it looked generic enough), and so they shipped the feature that way. it was only years later, when i was porting some of that code to typescript, that typescript complained about invalid type operations. i was converting between languages pretty willy-nilly and assuming the existing system worked correctly, so i suspected typescript was being dumb with that type error. but no, it was actually complaining about an actual bug. when passing arrays of strings as filters, the underlying filtering system was at some point coercing those arrays to strings by accident. so ['apples', 'oranges'] became 'apple,oranges'. the search results were always right when the multi-valued filters had only one value (because ['apples'] coerced to string is 'apples') and kinda right in some naive cases of multi-valued filters (because of how the text search engine worked), which was probably why the original programmers thought it was working correctly and didn't give it much more though or more thorough testing. but the search results were definitely not correct in most non-naive cases of multi-valued filters. so our users had been affected by this bug of multi-value search filters basically not working for years, and we only discovered it by accident when porting some of the JS code to typescript because typescript was kind enough to tell us about this nonsense operation statically, without having to even run the code. i wish that JS were also kind enough to complain about these nonsense operations, albeit at runtime. it would have made this problem obvious from the get go, and would have prevented the original programmers from shipping a broken feature to thousands of users. plot twist: although the story may make it seem that i was the competent programmer that figured it all out when porting the code to typescript, in reality "the original programmers" also included me (probably, i don't remember really), just some time before the typescript port :/

Tainnor 5y ago

I've been thinking for a while that modern languages shouldn't default to floating point computations. They're exactly the right thing if you do data stuff or scientific computing, but given how much of the internet relies on things like e-commerce and how often floating point is still misused for dealing with money, coupled with the fact that even many senior developers aren't fully aware of the subtleties of floating point, I don't understand why we keep making them the default. If a user does need to do scientific computing, they could use a "# use-floating-point" pragma or something so that literals get interpreted as floating point. Otherwise, we map them to rationals. Of course, doing rational arithmetic is much slower (for example, Gaussian elimination is exponential for arbitrary precision rationals, while it's famously O(n^3) for floating point), so there's a danger of people accidentally using it in triply nested loops etc., but I have a feeling that if you need to do that kind of thing you know that you might run into performance issues and you think twice.

denton-scratch 5y ago
> "# use-floating-point" pragma I haven't come across the "pragma" directive in a Javascript context. I guess it's another new feature (I have trouble keeping up these days).
- Tainnor 5y ago
  I don't think they have it (although, you can do whatever you want with babel nowadays, I guess). It was a suggestion aimed at programming languages in general.
  - akiselev 5y ago
    The javascript equivalent would be an expression like 'use strict';
    - denton-scratch 5y ago
      I was being flip; I should have used a smiley, I guess. Sorry.

jandrese 5y ago

Knowing that the underlying representation will vary is CS101 material. It applies to almost every language because that's how the hardware works.

BrissyCoder 5y ago
Hardware doesn't exist in any meaningful way for 90% or professional programmers anymore. Way too much abstraction for that to be an argument.
- denton-scratch 5y ago
  I don't agree. Even if you aren't programming microcontrollers, even if you're just building brochure websites for mobiles, you'll do it better if you understand hardware.
  - BrissyCoder 5y ago
    > you'll do it better if you understand hardware. Oh for sure. I agree. That's not what we're arguing though.

rileytg 5y ago

We have this on our interview test. It was the one almost everyone got wrong except for a couple people who ended up being really detail oriented and had deep knowledge (as opposed to broad). We consider >70% passing.

mewpmewp2 5y ago
I'd honestly consider these types of questions one of the poorest ways to test front end developers. The only reason I have learned some of that oddball stuff with JavaScript is because of some job interviews e.g. when I was earlier in my career, I used to Google things like "top 30 questions asked in a JS interview", etc, but I forget it after that until I'm about to look for another job. However I wouldn't do this type of learning any longer, since I wouldn't want to apply for a company asking these types of questions. In the end at work you should use ES6/TypeScript with linting, proper tests and these cases would never occur.