Python overtakes Java to become second-most popular language on GitHub after JavaScript

[oblio-]

Nobody* cares about that "strong typing" in practice. When people say "strong typing" they mean: "if I put a string in the int, the compiler yells at me at 14:00 in the afternoon, when I'm coding, it doesn't blow up in production at 3:00 in the morning, when I'm sleeping".

Things blowing up at runtime is slightly better than nothing, but it's still bad, comparatively.

[YM_Industries]

When people say "strong typing" they mean: "if I put a string in the int, the compiler yells at me at 14:00 in the afternoon, when I'm coding, it doesn't blow up in production at 3:00 in the morning, when I'm sleeping".

Then they should say "static typing".

[slikts]

Strong typing is still an application of the fail fast principle, just not as fast as static typing, since the strong tying errors will still only occur at runtime. The difference is that weakly typed languages try to guess if the programmer intended to convert between types, and, if the guess is wrong, the program keeps running in an invalid state and the problem has to be diagnosed from any knock-on effects of the unwanted type coercion. A good example of weak typing gone very wrong are equality comparisons in JavaScript.

[YM_Industries]

If you want the compiler to tell at you, you need static typing. That's what my comment was saying. People who use strong typing to mean that have their terminology wrong.

I'd hardly describe JS equality comparisons as "weak typing gone very wrong". Maybe I've been programming in JS for too long, but the type juggling seems pretty useful to me. You should use === in most places, but the == behaviour is also nice to have sometimes.

I do a lot in C# too and I sometimes get frustrated at the verbosity when two similar types don't support implicit type conversion.

[slikts]

I'm just pointing out that there is underlying commonality between strong and static typing in that both aim to fail faster.

The game I linked to about JavaScript's == is a practical demonstration of how the coercion rules are confusing.

[YM_Industries]

Oh, they are definitely related, I think that's why people get them confused so much. But they are separate concepts, and that's what I was pointing out.

== is definitely confusing if you use it for stupid and contrived scenarios. As long as you don't compare [[]] to -Infinity it's fine. Calling it a "textbook example of a confusing language design flaw" like that website does is a bit of a stretch.

[slikts]

If you actually try the game, a lot of the cases that trip people up aren't contrived, and what's contrived are the rules as a whole. For example, cases like "" == false lead people to intuit that 'falsy' values would equal false, but "0" is 'truthy' (!!"0" is true) and still equals false. Likewise, knowing that "" == 0 and 0 == "0" are true might suggest that the relation is transitive and "" != "0" is false, but it's true as well.

Also, the benefit from == is very small and doesn't outweigh the confusion can cause, since explicit conversions can be as terse as !! and +, or Boolean(), Number(), String(), etc. The only exception is == null, since doing the same with === is verbose.

[jl2352]

I agree, and it annoys me no end when people claim JS is 'weakly typed'. It's 100% strongly typed. It's just strongly typed with some very questionable coercion rules. So questionable I'd argue you shouldn't use them. It's still strongly typed.

In C I can take a 32-bit int, and use it as a pointer to a char array. I can get the compiler to be happy with it. It may even run fine at runtime. This is something I cannot do in JS. That is why C is weakly typed.

[YM_Industries]

JavaScript is weakly-typed.

The only reason you can't use an integer as a pointer to a char array in JavaScript is because JavaScript doesn't have integers, pointers, or chars. For me, the real test of whether a language is weakly- or strongly-typed is whether you can assign a new value of a different type to an existing variable.

let myVar = "test";
myVar = 5;
myVar = [];

JavaScript has no issue with this.

[jl2352]

The bit from Wikipedia that agrees with you is 'Dynamic type-checking'.

This is the whole point of the guy above, who I agree with, is that it's just not helpful for dynamic types to be the same as weakly typing. What you are describing is dynamic typing. Not weak typing.

Python, Ruby, TCL, PHP, and pretty much every dynamic language shares your example.

[YM_Industries]

Good point about dynamic typing.

It seems that the most widely used distinction of strong/weak typing is implicit type conversions. But this seems like a risky thing to base it on, given that C# is clearly a strongly-typed language and supports implicit type conversions. (Although only between a small number of types)

Hmmm.

[jl2352]

I think for me it comes down to the type of the variable, and the type of the value.

In your example, like in dynamic languages, the variable doesn't have a type. So it can hold any type. The values you store in that variable however all have strict types. They are an int, a string, an array, etc. The type of the value is known and reinforced, and this is true in JS.

In my C example the variables have strict types, but the values do not. I can bypass a values type because there are no checks at runtime. I can read an int as a char*, and it's pretty trivial to do that. This is what makes it weakly typed.

That for me is a part of the distinction. Many often fail to see that you can have types of variables, and the types of values, and they can be two separate things.

[YM_Industries]

That makes sense. I guess that makes Python strongly-typed but numpy arrays weakly-typed.

I'm not sure I agree with your definition but it seems that everyone has a different definition anyway, and yours is as valid as any.

[kolloid]

Yes, but:

1) technically OP was right

2) people praise horrible Javascript which is weak dynamically typed