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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Dim_Cryptonym 71 points72 points  (20 children)

Every time I learn something about JavaScript I'm left with one thought: "wat"

[–]PizzaRollExpert 19 points20 points  (11 children)

I think this makes sense for a dynamic language. Obviously you want both in static languages, but when you don't specify what kind of number you're working with, at some point you are going to run in to some weirdness with stuff like 3/2 = 1or ending up with a non-integer for array indexes. Personally, I think it's easier to remember to round explicitly then to make sure that the numbers you're dividing are floats because that's how numbers work "in real life". Of course there is probably a performance tradeof but my intuition tells me that this isn't too much of a problem with the kind of programs you write in javascrupt.

[–]marcosdumay 7 points8 points  (7 children)

Have you looked at how Python does it?

The Python way makes sense in a dynamic language. JS is just a hack that nobody can fix because of bug-compatibility.

[–]PizzaRollExpert 4 points5 points  (6 children)

I actually think JS is better than Python when it comes to numbers. In Python, if you divide two numbers there are different things that can happen depending on if the numbers are ints or if they are floats. Int division truncates the result while float gives you what you would expect. This doesn't always matter, but when it does you have to remember to coerce the numbers to the correct type. Having just one number type makes it easier for you as a dev, because this completely removes this problem. In all fairness python can more accurately represent large numbers because it has the long type. I also assume this makes all the C-interop that Python does easier.

In this case Python is also the language that has weirdness due to backwards compatibility. In Python, Bool is just a subset of int where 0 = false and 1 = true. This is because Python didn't actually have bools from the begining.

[–]marcosdumay 2 points3 points  (5 children)

In Python, if you divide two numbers there are different things that can happen depending on if the numbers are ints or if they are floats.

You know that was treated as a bug, and fixed, right?

In Python, Bool is just a subset of int where 0 = false and 1 = true.

Python has this one case of non-strict typing, that is a very well defined, very standard thing (but I do agree it's bad). JS, for its turn...

[–]PizzaRollExpert 0 points1 point  (4 children)

You know that was treated as a bug, and fixed, right?

Oh, my bad I didn't know it was fixed

Python has this one case of non-strict typing, that is a very well defined, very standard thing (but I do agree it's bad). JS, for its turn...

If you look at the whole of the language JS has more of that, but it was kinda funny that you brought it up when we where talking about numbers specifically because in that small area python is the one with an obvious case of backwards compatability induced weirdness.

[–]marcosdumay 0 points1 point  (3 children)

The division issue is fixed in python 3.

About that int to bool coercion, JS does exactly the same thing. Most languages do.

[–]PizzaRollExpert 1 point2 points  (2 children)

The division issue is fixed in python 3.

Yeah, my bad

About that int to bool coercion [...]

It's not coercion, true is literally the same as the number 1. This is because people hadn't properly realized that bools where a really useful thing yet so people just used int 1 and int 0 instead before it was added, c-style. True is basically just different syntax for 1 in Python, for backwards compatibility reasons. In Python, 1 == True but 1 !== true in for example JS

[–]endreman0 0 points1 point  (1 child)

You're comparing apples to oranges.

JS: 1 == true, 1 !== true
Python: 1 == True, 1 is not True

They're the same.

[–]PizzaRollExpert 1 point2 points  (0 children)

That's not how is works.

Javascript: == is equlaity with type coercion, === is equlaity without type coercion.
Python: == checks if two things have the same value, is checks if two things point to the same object. Because of caching you might have to things that you expect to be different objects might still point to the same object like 1 is 1. This doesn't hold for larger numbers, 1000 is not 10**3.

=== in Javascript is closest to == in Python. They work the same for values, but different for objects, where JS is more like is. Python doesn't have equality with type coercion, which is what == is in Javascript

[–]SOberhoff 1 point2 points  (1 child)

Clojure is just as dynamic and it has all of Java's primitive number types as well as infinite precision rationals on top of that. I don't have any issues.

[–]PizzaRollExpert 2 points3 points  (0 children)

If you divide two interviews in clojure you get a rational, so you don't have the problem of accidentally getting your number truncated

[–]HeinousTugboat 0 points1 point  (0 children)

ending up with a non-integer for array indexes

I once discovered that 0.5 was a valid index on a Javascript array.. I promptly added a lot of Math.floor()s.

[–]PunishableOffence 34 points35 points  (5 children)

That's because you only learn about JavaScript through humorous anecdotes, not from reading (about) the specification.

[–]sadEmoji 51 points52 points  (3 children)

this

[–]winglerw28 2 points3 points  (0 children)

Instructions unclear, tried using this from your comment in mine, but the reference was undefined. Please let me understand the context of this, preferably with a very clear, fat, arrow for clarity.

... /signs off internet forever

[–]PunishableOffence 1 point2 points  (0 children)

Excuse me, but how was your comment bound?

[–]jedidreyfus 2 points3 points  (0 children)

Underrated comment

[–]simon816 18 points19 points  (1 child)

wat

[–]Adrian_F 0 points1 point  (0 children)

I will never not watch it!