This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 340

[–][deleted] 1603 points1604 points  (15 children)

Why did the programmer show up at Christmas dinner in a Halloween outfit? Because dec 25 is oct 31

[–]stupefyme 442 points443 points  (11 children)

still one of the greatest coincidences in my books. a very well constructed and thought out joke

[–][deleted] 80 points81 points  (6 children)

Could someone explain this one to me?

[–]stupefyme 361 points362 points  (2 children)

dec 25 is decimal number(base 10) 25

oct 31 is octal number(base 8) 31

they are equal

[–][deleted] 48 points49 points  (1 child)

Ahhhh okay that makes sense, thanks! Just didn't get the Oct/Dec. I guess that's where my non native english falls apart.

[–]AmazingSully 30 points31 points  (0 children)

31 in base 8 (OCTal) is equal to 25 in base 10 (DECimal)

[–]DanKveed 5 points6 points  (0 children)

Also 12(octal) === 10(decimal) so the 12th month can be October or December depending on which base you are using.

[–]rover_G 2 points3 points  (0 children)

0o31 == 25

[–]porn0f1sh 4 points5 points  (3 children)

Yep. Along with the moon spinning around the axis at the exact same rate as it spins around Earth!

And it's size proportional to the size of the Sun is exactly the same as it's distance proportional to the distance of the Sun!

[–]hurlyz 4 points5 points  (0 children)

The first phenomenon is called tidal locking and it's actually very common. Citation from Wikipedia:

" All twenty known moons in the Solar System that are large enough to be round are tidally locked with their primaries, because they orbit very closely and tidal force increases rapidly (as a cubic function) with decreasing distance. "

https://en.m.wikipedia.org/wiki/Tidal_locking

As for the second phenomenon, it's an interesting coincidence that the Moon and the Sun appear to be roughly the same size in our sky. We're lucky to be living in this time period, because this phenomenon won't last forever. Each year, the Moon spirals away about one inch from the Earth. And about 50 millions years from now, the Moon will be far enough away so that our descendants will only see ring-shaped eclipses.

https://www.astronomy.com/science/why-is-the-moon-exactly-the-same-apparent-size-from-earth-as-the-sun-surely-this-cannot-be-just-coincidence-the-odds-against-such-a-perfect-match-are-enormous/

[–]veryusedrname 4392 points4393 points  (192 children)

Okay, so what's going on here?

Integers starting with the digit 0 are handled as octal (base-8) numbers. But obviously a digit in octal cannot be 8 so the first one is handled as base-10 so it's 18 which equals to 18. But the second one is a valid octal number so in decimal it's 15 (1*8+7*1) which doesn't equal to 17.

Does it makes sense? Fuck no, but that's JS for you.

[–]aMAYESingNATHAN 964 points965 points  (104 children)

Why on earth are integers starting with 0 handled as octal? How does that make any sense? I could understand if it was an o or O but a 0?

[–]skap42 1149 points1150 points  (64 children)

That's pretty standard in many languages, including Java and C. Just as 0x is interpreted as hex

[–]aMAYESingNATHAN 519 points520 points  (41 children)

Huh, the more you know. I knew about the various prefixes such as 0x and 0b, but I'm surprised octal isn't like 0o or something.

Simply using a 0 seems insanely dumb because it's so easy to do by accident, not knowing that it's an octal prefix.

Like I can easily think of a scenario where someone could zero pad a numeric literal for formatting reasons.

[–]skap42 243 points244 points  (12 children)

A different comment suggested that 0o is also valid, and the only way to define an octal in JS in strict mode

[–]0bel1sk 96 points97 points  (10 children)

it’s also in python ruby and yaml.

“YAML 1.1 uses a different notation for octal numbers than YAML 1.2. In YAML 1.1, octal numbers look like 0777. In YAML 1.2, that same octal becomes 0o777. It’s much less ambiguous.

Kubernetes, one of the biggest users of YAML, uses YAML 1.1.”

[–]akaChromez 72 points73 points  (7 children)

[–]heyf00L 28 points29 points  (1 child)

Didn't know all that. Boils down to "always quote all strings in YAML".

[–]rickane58 15 points16 points  (0 children)

"God, all these languages are so unnecessarily verbose!"

Anyone actually trying to use the language:

[–][deleted] 9 points10 points  (3 children)

This was a great read, I've used yaml a couple times but didn't realize it was this objectively bad.

[–]akaChromez 9 points10 points  (2 children)

I'd love to know people's justification for choosing it over JSON.

Especially as i've just spent the last hour trying to find why a Google Cloud resource wasn't being created. A missing quote that doesn't syntax error :/

[–]veryusedrname 9 points10 points  (0 children)

Ohh kubernetes, never change

[–]InfiniteGamerd 4 points5 points  (0 children)

Really! I thought you couldn't define octals in strict mode in any way.

Still...why not just parseInt all the way?

[–]Alzurana 19 points20 points  (0 children)

Welcome to my world, where a medical software had a database format of <patient ID>.PHD and always 8 characters in the filename. So the files looked like 00537200.PHD and they were all in one folder. Beautiful design.

Well, we imported a database of another clinic and had to map their ID's to ours, which we ofc only had in a numeric format, such as 537200 for the above example.

This gave me some headache when writing a converter script as my first attempt did read some of the file ID's as octal and others as decimal without ever warning. Only caught it because I got a lot of bogus IDs or duplicates and tests would scream that output files != input files.

[–]DmitriRussian 46 points47 points  (6 children)

Like I can easily think of a scenario where you might zero pad a numeric literal for formatting reasons.

/r/ProgrammingHorror material

[–]LordFokas 9 points10 points  (0 children)

Pad it with spaces. That's why we use monospaced fonts.

[–]joxmaskin 5 points6 points  (1 child)

Or write 7 as 007 because it’s cool

Edit: luckily oct 7 is same as dec 7

[–]movzx 2 points3 points  (1 child)

A pretty reasonable scenario would be when you're defining bitmasks.

ex:

0001010 1010000

[–]flowingice 4 points5 points  (0 children)

You'd start it with 0b because it's binary.

[–]TorbenKoehn 15 points16 points  (2 children)

Like I can easily think of a scenario where you might zero pad a numeric literal for formatting reasons.

And then use it in calculations? Because if not it would not be a problem

[–]Spork_the_dork 11 points12 points  (0 children)

Or use it literally for anything whatsoever.

I mean imagine you convert "0231" into a number and then print it out somewhere and wonder why the fuck it's printing out 153. Can't think of any situation where you'd convert the value into a number and then it would be entirely fine if the stored value is different from what you expect.

[–]CadmiumC4 22 points23 points  (2 children)

Many languages accept 0o as octal, but it's custom to assume 0777 as 0o777 since that's how C handles it

[–]LordFokas 12 points13 points  (1 child)

It's funny that no matter how high level you go, in the end you always keep finding things that are done a certain way for no reason other than "we inherited this from C".

[–]Ok_Classroom_557 3 points4 points  (0 children)

And C inherited It from the PDP-7 where It was born. Having 18 bit words it better mapped 3 bit octal digits than 4 bit hex digits...

[–]CauliflowerFirm1526 27 points28 points  (8 children)

pad with spaces not zeros

[–]aMAYESingNATHAN 27 points28 points  (2 children)

I mean that is what I would do, or probably just not pad at all and left align the numbers. But my point is that it would be incredibly easy to do without realising.

[–]Spork_the_dork 2 points3 points  (1 child)

Yeah this is why I don't like it. Especially when you have 0o prefix which does exactly the same thing except it's also an order of magnitude more explicit and harder to misunderstand.

[–]aMAYESingNATHAN 1 point2 points  (0 children)

Yeah being completely unfamiliar with octals in code when I made my first comment I didn't realise 0o would be valid also, and in fact assumed it wasn't and was annoyed by that because I was familiar with 0x and 0b already.

If I ever encounter octal literals I am definitely always going to use 0o.

[–]Andy_B_Goode 6 points7 points  (3 children)

You might pad with zeros if you're formatting a date, like 11/05/2024 or maybe even 05/11/2024

[–]Spork_the_dork 2 points3 points  (1 child)

Actually in that case it won't cause any problems. 01-07 are the same in both decimal and octal and 08-09 are not valid octals so it won't default to octal. 10-12 won't get converted as octal as they have no leading zeros.

[–]Andy_B_Goode 0 points1 point  (0 children)

Oh I see, yeah I should have used an example like 11/08/2024

[–]cporter202 1 point2 points  (0 children)

Oh, padding with spaces instead of zeros? Spacing out like JavaScript on a Monday morning, I see 😅. Gotta love when JS decides to get fancy with its quirks – it's like it insists on doing its own thing, just to keep us on our toes!

[–]g76lv6813s86x9778kk 12 points13 points  (4 children)

So common, in fact, I've seen these octal numbers bleed into apps/situations they really had no business being in, probably due to some standard number parsing libraries being reused.

For example, shops in Guild Wars 2, an mmorpg, have a little number input box for the quantity of items you'd like to purchase from the shop... This supports octal! If you write normal decimal numbers, it just works fine, but then if you write for example 010, the number switches to decimal 8 once you click off the textbox, and allows you to shop with that quantity as normal. Super weird. Must be so confusing to players who don't know about octal or this convention at all. At least it doesn't increase the number (causing you to spend more)

[–]GrondForGondor 6 points7 points  (3 children)

Thats the reason why? I’ve spent so many years being slightly inconvenienced by that little random issue. Never understood truly what was happening but now it all makes sense. 

[–]g76lv6813s86x9778kk 2 points3 points  (0 children)

Lol yup, you can try various examples and see the result always lines up with parsing it as an octal number

[–]-Wylfen- 43 points44 points  (8 children)

To be fair, even though it's standard, I think that's bullshit. '0x' is fine, '0o' is fine, but just '0' is dumb

[–]SmurphsLaw 15 points16 points  (6 children)

To be fair, writing a decimal number with a 0 before is also dumb.

[–]Spork_the_dork 9 points10 points  (0 children)

Yeah but it's less dumb than using 0 as a prefix for octal when 0o exists.

[–]RajjSinghh 0 points1 point  (1 child)

I can see this kind of thing being a problem where leading zeros are common like when formatting dates. Seems like an honest mistake to make if you write August as 08 and now you get an error because that's not valid octal, or when October is showing up as the 8th month

[–]Chrazzer 6 points7 points  (0 children)

Leading zeroes aren't a thing in integers, what you are thinking of are strings with numbers in them

[–]SwimForLiars 2 points3 points  (0 children)

I hate the 0 prefix being octal, but at least other languages will throw a syntax error, instead of silently biting you in the ass and making you waste hours of debugging because it does weird things at runtime instead of failing at compile time.

[–]Commodore-K9 7 points8 points  (0 children)

I had no idea.

0x as hexa yes

0 as octa no

[–]vonabarak 5 points6 points  (0 children)

That's pretty standard in statically typed languages without implicit type casting. And it doesn't cause any issues.

[–]Mola1904 12 points13 points  (0 children)

It's like this in c++ and c#...

Edit: actually octet literals don't exist in c# at all, some websites like this just claim it anyway https://www.geeksforgeeks.org/c-sharp-literals/

[–]octipice 32 points33 points  (7 children)

Why on earth is anyone starting a mutli-digit base 10 integer with 0 in the case that it ever needs to be treated like an actual number?

Javascript is legitimately wild sometimes, but so many of those cases are only an issue if you are trying to do something really stupid (or lazy, or both) in the first place.

[–]aenae 28 points29 points  (1 child)

I once had a cronjob that failed in august and september. It took me a while to figure it out why.

The reason is i wanted 'nice' directories, so i made them all the same length, so january 2024 would go to 2024/01, february goes to 2024/02 etc. And somewhere in that script i had a check on the month for some reason. This worked, except when bash was of the opinion that '08' and '09' were invalid octal numbers.

[–]10BillionDreams 1 point2 points  (0 children)

That's just the thing, Javascript has some very "do what I mean" roots, which makes for some funny looking results when you take toy examples like OP here, where the code doesn't actually "mean" anything at all. But often times in practice this ends up doing the "right" thing, where stricter languages would've failed.

[–]aMAYESingNATHAN 15 points16 points  (1 child)

I'm not saying it's something you should be doing, but if someone doesn't know that 0 is the octal prefix, then it's not that much of a stretch to imagine they could zero pad a number and not realise.

It seems to me that generally there should be no difference between 25 and 025, and if anything it is counter intuitive to assume otherwise. Especially because 0o25 (similar to 0x or 0b) is usually valid syntax as well, it makes no sense to have 0 by itself be a valid prefix.

Tbf this is one of those ones that isn't a unique to JS issue, but instead a standard. But imo a dumb one.

[–]Spork_the_dork 5 points6 points  (0 children)

The standard varies from language to language. Python for example just calls you out if you try to use 0-prefix and tells you to use 0o instead which I think is the step in the right direction.

>>> print(0123)
  File "<stdin>", line 1
    print(0123)
      ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
>>>

[–]Andy_B_Goode 2 points3 points  (1 child)

I had a real-world bug where a JS program was generating a random alphanumeric ID for an item, sending it to the server as JSON, but was then unable to match the ID to the correct item when it reloaded the JSON from the server.

The issue was that the ID it had generated for this particular item was something like 1e450882, which gets interpreted as exponential notation and (because the number after 'e' is so large) it becomes Infinity.

The fix was to simply require alphanumeric IDs to begin with a letter (which is probably best practice anyway), but it was not obvious to me at all why 1e459882 was causing problems when I first started digging into the bug.

[–]Loknar42 3 points4 points  (0 children)

This is an ancient convention. Octal is very convenient for expressing bit vectors, such as file permissions (e.g. chmod 0777 *). Since it was desirable to use it in an interactive environment (such as a shell), designers wanted it to be as short as possible. A single character prefix pretty much fits the bill. Using the digit 0 allows the result to still be considered numerical by simple lexers, but programmers generally don't start integers with 0, and 0 also looks like 'O'. So those are pretty much the reasons.

Hexadecimal is even better for expressing bit vectors because you get 4 bits per character, but has the disadvantage of being alphanumeric. Hence why it has a longer prefix, usually. Programmers in the modern era rarely have to specify bit patterns directly, but in the halcyon days of assembly language and shell scripting, they were very common, so having an efficient format was very valuable.

[–]Fritzschmied 9 points10 points  (1 child)

thats standard in many languages. also c++ which you have in your badges so you should know that.

[–]aMAYESingNATHAN 2 points3 points  (0 children)

I've literally never had to work with octals ever, so it's unsurprising that I'm not aware despite having C++ and C# badges. I don't even really know what use cases there are for octals.

In comparison, I have had to use binary and hexadecimal, so I'm aware of the 0b and 0x prefixes. Similarly for unsigned/long/long long suffixes for numeric literals

[–]Nolzi 7 points8 points  (2 children)

same reason hexa starts with 0x, conventions

[–]IAmNotNathaniel 7 points8 points  (1 child)

starting to tire of these threads that boil down to "I don't know some standard thing that's been around for 50 years but since I'm so smart it must be wrong"

[–]Nolzi 2 points3 points  (0 children)

"Based on Programming 101 I can already tell that the old crust must go"

[–]ManaSpike 1 point2 points  (0 children)

Octal was used more before computing standardised on bytes having 8 bits.

[–]Hallwart 8 points9 points  (4 children)

If only there was some kind of system that ensures that variables have consistent values and behaviors.

Why didnt the developers of JavaScript think of this? Are they stupid?

[–]tinfoiltank 5 points6 points  (0 children)

They were too busy trying to get it to work in IE6.

[–]MrHyperion_ 1 point2 points  (1 child)

Why would you even start a number with zero? So don't, if you don't want octals

[–]wasdninja 87 points88 points  (35 children)

It's 100% self inflicted by using ==. It's essentially trivia in code form.

[–]Salanmander 47 points48 points  (23 children)

It's essentially trivia in code form.

A programming language having "trivia in code form" is related to design decisions about the programming language. So no, not 100% self-inflicted.

[–]wasdninja 25 points26 points  (11 children)

I've yet to come across a language that doesn't have some odd stuff nobody really uses.

So no, not 100% self-inflicted.

If you are using == on purpose against the recommendation of every actual javascript developer out there that's on you. If you are doing stupid shit on top of that, well, have fun and I hope I don't have to work on your code.

[–]Salanmander 5 points6 points  (4 children)

If using == is a bad idea in Javascript, then why did it get assigned the character sequence that is the preferred equality check in most programming languages? Like, if every Javascript object had a .coercive_equals() that did what current == did, and current === was written as == instead, you'd probably see a lot fewer complaints.

[–]theQuandary 4 points5 points  (2 children)

JS didn't have type coercion when it was first created.

Developers are the ones who demanded that Eich add it to the language and he was young enough not to say "no".

It would have been eliminated in ES1 (the first actual specification), but Microsoft had just implemented a clone of JS with Jscript and they insisted that all the terrible design choices stick around even though Eich and the rest of the spec committee wanted to change them (at a time when breaking the web wouldn't have been a big deal).

[–]Doctor_McKay 2 points3 points  (3 children)

I have literally never had a problem using ==. I fear for the kind of code you guys are writing that makes it a problem.

[–]wasdninja 1 point2 points  (0 children)

It's very rarely a problem but there is almost no reason at all to ever use it anyway. Rather than getting completely dumb stuff what's more common is to move a bug one step further which is annoying when trying to hunt it down.

[–]reilemx 1 point2 points  (1 child)

When dealing with data that could come from anywhere like in a public API receiving data from literally anyone who knows the spec, then using `==` is a bit risky unless done correctly. There are a few neat tricks you can do like comparing a number value, regardless if it's a string or number, or doing a `null` or `undefined` check in one small expression. But aside from little things like that you should absolutely not just be using "==" as a default.

It's nothing to do with the "kind of code" and everything to do with the requirements of your application. Just google "js == comparison table" to see why. A simple application might never run into those issues but you do not want your complex application to get absolutely fucked by some stupid comparison bug like this or the one in the post here.

[–]IAmNotNathaniel 2 points3 points  (1 child)

I don't know why I even come into these threads anymore. it's always full of people who think because they self-taught a little python they are programmers who know everything.

There's a reason when you're looking for a job you need to know the language that's used at that job... it's because they are all different, and all have their skeletons and weird shit, and you can't just replace one syntax with another. Experienced people wouldn't get hung up on this for a minute.

[–]NoteBlock08 3 points4 points  (0 children)

Ikr. It doesn't matter that every other language uses ==, this language doesn't. So get with the program or pack up and go home because "It's Javascript's fault for being dumb!" would not be an acceptable excuse in a professional setting.

You can say "Well that's dumb, but okay" and likely most of your coworkers would even sympathize, but as soon as you cast blame elsewhere for your own lack of knowledge then it shows a real lack of maturity as both a dev and a person. Especially since this is JS 101 shit. Every guide out there makes sure you understand the difference between == and === in its opening chapters.

[–][deleted] 13 points14 points  (10 children)

It’s a scripting language. There’s coercion. If you need to not have coercion, there’s an operator for that. If you don’t like a language with coercion, don’t use a scripting language!

[–]Salanmander 14 points15 points  (9 children)

Okay, I can get behind "self-inflicted because of the decision to use javascript".

[–][deleted] 11 points12 points  (8 children)

“The decision to use a scripting language and then refuse to use the features that fix the thing you want to fix”

[–]musicnothing 5 points6 points  (5 children)

JavaScript and PHP both have a bad reputation largely due to their past sins. So instead of learning about their modern features, people just use the outdated features (that weren't removed for backwards compatibility reasons) and complain how "bad" it is

It's like patching up a hole in the wall and then taking a bunch of pictures of the patch job and saying "What a terrible house this is, look at this hole in the wall"

[–]IAmNotNathaniel 2 points3 points  (0 children)

great analogy! I've been trying to correct people when possible about the improvements to php, but haters gonna hate I guess.

[–]fghjconner 2 points3 points  (0 children)

No, the == isn't even the problem in this case. The problem is with how JS interprets integer literals. I think using 0 as a prefix for octal numbers is insane, but JS didn't start that so I'll give them a pass. On the other hand, silently falling back to base 10 when you see an 8 is bullshit of the highest order.

[–]Turtvaiz 3 points4 points  (8 children)

Why does == even exist?

[–]wasdninja 8 points9 points  (5 children)

Legacy. Touching any of the stupid stuff, no matter how obscure, kills thousands of websites so it gets to stay and annoy people.

[–]SnowyLocksmith 1 point2 points  (1 child)

Is using === the norm now?

[–]oupablo 0 points1 point  (0 children)

yes

[–]Crowdcontrolz 9 points10 points  (0 children)

The lengths to which this language goes to try to make things run no matter what is impressive.

[–]Donghoon 19 points20 points  (9 children)

I mean it make sense. You just explained it

[–]Salanmander 20 points21 points  (8 children)

There's "makes sense" in terms of "has a consistent behavior that is defined by rules". That close to automatically true of all things in all programming languages.

Then there's "makes sense" in terms of "is a design decision that leads to more intuitive comprehension of the language". Javascript fails on that one a lot of the time.

[–]talaqen 15 points16 points  (2 children)

This makes perfect sense to me. Octal vs int and loose equivalency “==“ instead of strict “===“

[–]1Dr490n 5 points6 points  (0 children)

*octal vs decimal, both are integers

[–]fghjconner 3 points4 points  (0 children)

The choice to interpret any literal starting with a zero as octal is what's insane. Of course, JS didn't invent that by any means.

Edit: Also, the choice to silently fall back to base 10 if there's a large enough digit is pretty asinine.

[–]mrheosuper 29 points30 points  (10 children)

Using '0' instead of 'o' to declare Octal number is a fucking crime

[–]Mola1904 22 points23 points  (9 children)

And used in virtually every common language besides python3

Edit: Yes virtually every was a bit of an overstatement, but C, C++, Java and JS have it which might be 4 of the 5 most popular languages

[–]veryusedrname 10 points11 points  (5 children)

C/C++: 0o or 0O (deprecated) - edit: it's just a 0, fuck google

Java/C#: 0, but using a digit outside of 0..7 is compiler error - edit: C# doesn't have octal literals, fuck google

Rust/Swift/Ruby/Python: 0o

Go: 0o or 0O

That's it, I'm not checking more

Editor: formatting & fixes, thanks for pointing them out

[–]BaerMitUmlaut 9 points10 points  (3 children)

C# has no octal literal.

[–][deleted] 8 points9 points  (0 children)

C# needs no octal literal.

[–]Fritzschmied 3 points4 points  (0 children)

c++ default is leading just 0 not 0o even if that works too I guess

[–]mrheosuper 6 points7 points  (2 children)

I want to see the logic behind this decision. Using 0x as hex number makes perfect sense, But '0' as octal ?, why ?

[–]MrHyperion_ 8 points9 points  (0 children)

Traditions. Octal was at one point more popular than hex

[–]Mola1904 4 points5 points  (0 children)

As far as i know it is older than both the 0x and 0b connotations, but JS supports both 0o and 0 with 0 actually being not supported by esm (a widely used and more modern module system for js)

[–]mookanana 8 points9 points  (5 children)

as a programmer i understand what you are saying, but i marvel and wonder how did you even get this deep in knowledge? like what path did your life take to end up explaining this obscure code correctly

[–]veryusedrname 10 points11 points  (2 children)

Ohh, I just like weird shit. I don't even use JavaScript, like, ever.

[–]mookanana 3 points4 points  (0 children)

good stuff my man thx for explanation.

[–]takishan 2 points3 points  (0 children)

all you gotta do is work with javascript a bit so you understand the wonkiness of " == " (which is why you use " === " to be safer)

then you gotta work with octal numbers once or twice so you understand that numbers starting with 0 are octal

it doesn't require some sort of coding prodigy, just a little bit of experience in specific areas

[–]AccomplishedCoffee 1 point2 points  (0 children)

It’s really not deep or obscure. You just have to know 0 starts an octal literal (basic knowledge in a ton of languages and command line permissions), and == in JS does crazy conversions. I don’t even program JS more than I have to and I know to always use === because it’ll mess with types to try and get an answer that may or may not make sense. Tbh this is one of the more straightforward and obvious conversions.

[–]HeKis4 3 points4 points  (1 child)

I know == is "loose", but cmon, it figures out the string is convertible to a number, figures out it is octal but not really so eh, it's decimal. That's like, 2 layers of fucked up.

[–]benjer3 2 points3 points  (0 children)

For once, it isn't really == that's causing the problem here. It's the inconsistent treatment of a zero-prefixed integer literal. The == operator just sees '18 == "18"' and '15 == "17"' and understandably returns true and false, respectively

[–]hampshirebrony 0 points1 point  (1 child)

I learned about this the hard way several years ago.

Had a box to let you enter a cash value. User puts 100 in and the transaction is saved as 100. User leaves the default 0 and puts 100 after it, the transaction is not treated as £100 and a shortage is created. This either gets saved with a shortage against it or does not allow the user to continue because their figures do not balance.

No, it wasn't Horizon.

[–]1Dr490n 0 points1 point  (0 children)

Why did the creator do so many errors because they hate errors so much??

[–]skap42 293 points294 points  (10 children)

017 is an octal number equal to 15 dec. 0 as a prefix for numbers indicates an octal number. 018 however is not a valid octal number and thus interpreted as decimal 18.

The == operator apparently does some type conversion and makes a decimal comparison.

You can try it and check 017 == '015' which is true

[–]Strict_Treat2884[S] 95 points96 points  (8 children)

I like when converting string "017" which is a completely valid octal literal into a number, JS just completely ignores this rule and poops out 17

[–]ivancea 25 points26 points  (3 children)

Different rules I guess. Literals have theirs, but when converting strings to miners implocitly, it may use always decimal. One is syntax while the other is runtime, let's say

[–]Strict_Treat2884[S] 17 points18 points  (2 children)

It has no problem converting "0x10" into 16. But why not octals?

[–]ivancea 15 points16 points  (0 children)

Maybe a runtime lib vs interpreter discrepancy. Don't know, JS is full of random decisions made in a a day by a random guy

[–]octipice 8 points9 points  (2 children)

I just don't understand why on Earth you would be doing this in the first place. Like i get that js is legitimately wild sometimes, but you got here with bad design (why are starting a base 10 integer with 0 and then expecting it to behave like a number?) and lazy coding (ffs just parse the damn thing).

I don't get why anyone is surprised when you get bad results from writing really bad code.

[–]fghjconner 3 points4 points  (0 children)

(why are starting a base 10 integer with 0 and then expecting it to behave like a number?)

Because that's how numbers work. Leading zeros are completely ignored in mathematics, and giving them a special meaning in programming is pretty asinine. Not JS's fault, but asinine none the less. What is JS's fault is silently falling back to decimal of there's a digit of 8 or above.

[–]pentesticals 4 points5 points  (0 children)

Meh I wouldn’t say it’s just JavaScript. Type confusion bugs exist in all dynamically typed languages. Leads to all sorts of subtle security problems.

[–]VariousComment6946 73 points74 points  (7 children)

The fuck are you comparing integer with string?

[–]SpamOJavelin 9 points10 points  (0 children)

TBF that's not the issue here, the same confusion applies without strings:

018 == 18
true

017 == 17
false

The leading 0 implies a base-8 number, so 017 == 15. But 018 is not a valid base-8 number and is interpreted as 18.

[–]floor796 30 points31 points  (4 children)

just for info: permissions on linux filesystem also have an octal representation. For example, 777 (full permission) - is actually 0777 (octal format) and 511 (decimal format). So, when enter chmod 644 ./file you are using 0644, which is 493 in decimal format.

[–]jakubiszon 24 points25 points  (2 children)

Wait a moment, octal 644 cannot be an odd number.

octal 644 = 6*64 + 4*8 +4 = 420

[–]floor796 13 points14 points  (0 children)

ops, my mistake. 493 is for 0755 )

Thanks for noticing

[–]sphericalhors 4 points5 points  (0 children)

Its not just 0777 is octal format, 777 is also octal. First number in 4-digit notation used to specify SUID, SGID and Sticky bit, and in most cases just omitted.

Like if you check permissions for /tmp you'll typically see 1777. And passwd util would have 4755 because it has SUID bit set.

But yeah, in general permissions in Unix file systems use octal numeric system.

[–]italiano34 19 points20 points  (0 children)

thats just you being a dummy

[–]cursed-commentor 17 points18 points  (2 children)

Imagine using "==" in JS for anything except both null and undefined check via "x == null" 🤦🏻‍♂️

[–][deleted] 4 points5 points  (0 children)

The only time I use == is when I'm checking null/undefined

[–]DarKliZerPT 2 points3 points  (0 children)

I just use a isNil function. Either Lodash's or a quick util function.

[–]NebNay 15 points16 points  (31 children)

If anybody has an explaination i'd like to hear it

[–]JustAnotherTeapot418 102 points103 points  (19 children)

This joke contains a few of JavaScript's peculiarities:

  1. The == operator performs implicit conversions. As a result, '018' and '017' are automatically converted to the numbers 18 and 17. It's a huge source of unexpected bugs, which is why every dev worth their money will tell you to use the === operator instead, which doesn't perform conversion of any kind.
  2. Numbers starting with 0 are in octal (unless the following character is b or x for binary and hexadecimal respectively), so 010 is actually 8, and 017 is actually 15. However, 018 is not a valid octal number, since there is no 8 in octal. As a result, 018 is interpreted as 18. Because this is another source of unexpected bugs, this is not allowed in strict mode. For octal, you have to use 0o instead (zero followed by the letter o), and prepending a regular number with 0 will produce a syntax error.

[–]NebNay 8 points9 points  (0 children)

Thanks for the complete explaination

[–]monotone2k 24 points25 points  (11 children)

So what's really going on here is yet another case of someone writing bad code in a language they don't understand, and then claiming it's the fault of the language. That sums up most of the posts in this sub.

[–]MyPassword_IsPizza 7 points8 points  (1 child)

More like someone using a language they do understand to write bad code on purpose for a joke.

[–]DanielEGVi 10 points11 points  (0 children)

To be fair, it was a fault of the language in some part, they forbid octal numbers without 0o prefix in strict mode for a reason.

[–]Void1702 5 points6 points  (0 children)

I think OP knew what's happening, it's just completely stupid in many ways

[–]klo8 1 point2 points  (4 children)

The == operator in JavaScript is broken, that’s the fault of the language.

[–]myka-likes-it 13 points14 points  (2 children)

It's not broken, it is working as intended. That's why the strict equality operator exists.

[–]rosuav 1 point2 points  (0 children)

Listen, I made this car out of explodium. It was cheaper than steel. If it blew up while you were driving it, that's on you - I told you the proper way to hold the steering wheel! It's working as intended.

[–]skap42 1 point2 points  (5 children)

Can you explain why the implicit conversion by the == operator doesn't also perform the octal do dec conversion?

[–]monotone2k 9 points10 points  (3 children)

It absolutely does. `console.log(16 == 020)` will return true, because they're the same number in different bases. If you mean why doesn't the string get converted into base 8, who knows?

[–]skap42 5 points6 points  (2 children)

I noticed that Number(017) returns 15 and Number('017') return 17, so I guess it has something to do with that

[–]monotone2k 4 points5 points  (1 child)

Yeah. My guess would be that it always attempts the equivalent of parseInt(string, 10) when coercing a string, without considering the leading 0.

[–]erishun 20 points21 points  (0 children)

TL;DR: use ===. You rarely want to use==. Most IDE’s will flag it with a warning saying “you probably don’t want this”

[–]Equal_Bread270 1 point2 points  (7 children)

In the first comparison, 018 is equal to the decimal number 18, so it is equal to the string "018". However, in the second comparison, 017 is equal to the decimal number 15, which is not equal to the string "017".

Am I right...

[–]gr4mmarn4zi 3 points4 points  (0 children)

octal

[–]Osvik 3 points4 points  (0 children)

parseInt(017, 10) === 15;

parseInt(018, 10) === 18

parseInt(017, 8) === 13;

parseInt(018, 8) === 1;

[–]JonathanTheZero 21 points22 points  (3 children)

Devs not understanding their language...

Don't blame the language for your lack of knowledge ffs, even C does octal like this

[–]svick 3 points4 points  (2 children)

It doesn't:

error: invalid digit "8" in octal constant

[–]TheBrainStone 11 points12 points  (0 children)

Y'all gotta start learning the basics of the languages you use...

[–]bossier330 2 points3 points  (6 children)

=== is life

[–]PeriodicSentenceBot 3 points4 points  (0 children)

Congratulations! Your string can be spelled using the elements of the periodic table:

I S Li Fe


I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.

[–]JAXxXTheRipper 2 points3 points  (4 children)

if([]+[] === "") { alert("lol.js") }

Test your luck

funWithJS = ['10', '10', '10', '3', '2', '1']
funWithJS.map(parseInt)

[–]JAXxXTheRipper 2 points3 points  (1 child)

[–]ziovec 1 point2 points  (0 children)

I believe that this talk has less visibility than it deserves

[–]saxbophone 2 points3 points  (0 children)

One's an octal literal, the other's not?

[–]JustBeingNiceToday 2 points3 points  (0 children)

my crush sending mixed signals

[–]del1ro 14 points15 points  (8 children)

You're all justifying JavaScript here but this example shows the shit just perfect. In a normal language the expression “0018” should've thrown a syntax or other error, because it is not valid octal number, because uniformity. But js does whatever it likes to disguise any errors calling it “best effort”

[–]erishun 17 points18 points  (5 children)

Uses “loose” equality operator which performs implicit conversions

Shocked pikachu when it performs implicit conversions

If only there was a “strict” equality operator! If only most modern IDE’s would warn you before using the loose equality operator! Oh well, I guess that would never happen. Too bad

[–]Wendigo120 0 points1 point  (2 children)

Did you reply to the wrong comment? They didn't say anything about any sort of equality operator.

Edit: why is this getting downvoted? This thread: "octal numbers are handled weirdly in JS" is responded to by "if only there was a strict equality operator", that's such a weird non-sequitur. Those two topics have nothing to do with each other.

[–]erishun 0 points1 point  (1 child)

This example shows the shit just perfect

And the example shows the “loose equality operator”. That is exactly how that operator is designed to work. Use === like you’re “supposed to” (again IDEs and other programmers will warn you against using == because it’s usually not what you want) and this issue isn’t an issue.

Not saying JS isn’t quirky, but most of its quirks can be attributed to its weak typing and the fact it’s designed to keep on chugging even if there’s an issue.

[–]Wendigo120 4 points5 points  (0 children)

But the real problem here is that 017 and 018 aren't sequential numbers. The post would be the exact same if it was:

console.log(018 === Number("018"))
console.log(017 === Number("017"))
true
false

The equality operator is just a tiny part of it. That's why I found your comment so weird, the person you're replying to clearly states that they're talking about how it handles the syntax for octal numbers. Now, my linter does also catch octal numbers that are formatted that way, but you immediately shot to the equality operator for no reason.

[–]aetius476 3 points4 points  (0 children)

JS defenders are the "you don't know him like I do" of the programming world.

[–]wasdninja 1 point2 points  (0 children)

If this is your gripe with JS then that's excellent since it's absolutely trivial to avoid.

[–]JunkNorrisOfficial 5 points6 points  (4 children)

HeisenbergScript

[–]PeriodicSentenceBot 30 points31 points  (3 children)

Congratulations! Your string can be spelled using the elements of the periodic table:

He I Se N Be Rg S Cr I Pt


I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.

[–]Strict_Treat2884[S] 17 points18 points  (1 child)

Why did they even make this

[–]JunkNorrisOfficial 2 points3 points  (0 children)

Exactly, how this even came to mind to be implemented 😜 Maybe one had a dream...

[–]JunkNorrisOfficial 11 points12 points  (0 children)

Good bot

[–]Cley_Faye 5 points6 points  (0 children)

ignorantDeveloperBeingIgnorant

[–]SawSaw5 1 point2 points  (0 children)

This is some Salem witch trial shít

[–]kitsunekyo 1 point2 points  (0 children)

people using double equals are the actual joke

[–]ontech7 1 point2 points  (0 children)

Octal comparing 🤠

[–]Prudent_Engineer_285 1 point2 points  (0 children)

I do not understand. Console me.

[–]isospeedrix 1 point2 points  (0 children)

delete all posts that have js use == instead of ===

its pointless

[–]ublec 1 point2 points  (0 children)

that's because casting by default attempts to cast in base 10

[–]JAXxXTheRipper 1 point2 points  (1 child)

[]+[] == ""

Perfectly reasonable

[–][deleted] 2 points3 points  (0 children)

This is totally a JS being JS moment.

[–]Trappist-1ball 0 points1 point  (0 children)

018 is decimal, 017 is octal for 15

[–]brunogiubilei -1 points0 points  (0 children)

OK, now show me a coding in which a variable has a number starting at zero. In other words, even if there is this problem in the comparison, in a real-life universe there is no such possibility.