Re:Are dynamic languages going to replace static languages? ...
by lolinder on Wednesday August 04, 2021 @12:33PM
(#28063022)
> I contend there is no such thing as "weakly-typed" because it suggests it exists in opposition to strongly-typed systems - but instead I feel "weakly-typing" should be considered the absence of type-correctness checking by either the compiler nor the runtime
This doesn't feel like a very useful definition. What languages would fall under the category of "weakly typed" by your definition? I can only think of C, and even that is only true for a subset of the language (when you're messing about with pointers).
> Remember that implicit conversions should never (ostensibly) throw any exception or cause any errors because implicit conversion should always succeed because it should only be used to represent an obvious and safe narrowing-conversion.
> const fun = (x, y) => (x + y) / y
> fun(1, 2)
1.5
> fun("1", 2)
6
No exception? Yes. No error? Nope, implicit conversion absolutely just caused an error. If I got that "1" from an input field and forgot to cast it to an int, I want to be told at the soonest possible juncture, I don't want to rely on me noticing that the result doesn't look right. As it is, "weak" feels like a good word for the types here. They don't hold their form well.
Re:Are dynamic languages going to replace static languages? ...
by pydry on Wednesday August 04, 2021 @06:37AM
(#28059432)
Weakly typed / strongly typed are not really useful terms - there are too many separate definitions, all of which are pretty much equally valid.
Re:Are dynamic languages going to replace static languages? ...
by blacktriangle on Wednesday August 04, 2021 @08:39AM
(#28060292)
I thought we were all agreed that the strong - weak type axis was to what degree the language automatically converts types?
Re:Are dynamic languages going to replace static languages? ...
by igouy on Wednesday August 04, 2021 @12:34PM
(#28063040)
'Indeed, the phrases are not only poorly defined, they are also wrong, because the problem is not with the “strength” of the type checker but rather with the nature of the run-time system that backs them. The phrases are even more wrong because they fail to account for whether or not a theorem backs the type system.'
29.5 Types Versus Safety
"Programming and Programming Languages"
https://papl.cs.brown.edu/2020/safety-soundness.html#%28part...
JavaScript's more forgiving, and often surprising, implicit conversions are still rigidly-defined .
Remember that implicit conversions should never (ostensibly) throw any exception or cause any errors because implicit conversion should always succeed because it should only be used to represent an obvious and safe narrowing-conversion. A narrowing-conversion necessarily involves data-loss, but it's safe because all of the data needed by the rest of the program is being provably retained.