3 ms·

All of the modern dynlangs (e.g. Python, Ruby, Clojure) enforce type safety. Well, a lot of them. Some are weakly typed, and IMO weak typing is genuinely dama

All of the modern dynlangs (e.g. Python, Ruby, Clojure) enforce type safety. Well, a lot of them. Some are weakly typed, and IMO weak typing is genuinely damaging whereas I'll concede some room for the static/dynamic debate. Example: What's "1" + 1? Answer: In JavaScript, it's "11". In PHP, it's 2. Meaning it's possible that it could mean two different things in the same file.

dllthomas 12y ago
"Meaning it's possible that it could mean two different things in the same file." If you're spanning languages, that's not unusual. I have Haskell code with C in quasiquotes. What's x /= 2?
dragonwriter 12y ago
That's not a weak typing artifact, its an artifact of the fact that different languages use operators with the same name but with different semantics. (And the fact that you can have PHP and JS, which are different languages, in the same file.) You could have the same issue with languages with indisputably strong, static typing with different semantics if there was a way of embedding them in the same file.
- bunderbunder 12y ago
  Language that value strong type-safety guarantees won't respond to a request for "1" + 1 by quietly coercing one value to the other's type and moving along as if nothing strange happened. They'll generate a type mismatch error because adding an integer to a text string is undefined operation.
  - dragonwriter 12y ago
    Perhaps (though, discarding the emotional language of "quietly" and "as if nothing strange happened", there's all kinds of things in strong, statically-typed languages that aren't much different structurally from that, though if they did it would usually be by way of an operator working on a typeclass which included a total, rather than partial, conversion function to support the operation, so that the semantics of addition of string and whatever numeric type it was supported with would be well defined for all strings, rather than being only defined for particular strings; then again, its not like Haskell doesn't have functions that crash on values of an appropriate type but unsuppored specific values, so maybe not), but, in any case, f a b (or f(a,b) or (f a b) or a op b, depending on the syntax of the languages involved and the kind of function/operator at issue) having two different meanings in two different languages (specifically, two that can be included in the same file), which was what was complained about that example, isn't something that only occurs with that example, and it certainly can occur in strong statically-typed languages without even considering hypothetical constructs.

dllthomas 12y ago

"Meaning it's possible that it could mean two different things in the same file." If you're spanning languages, that's not unusual. I have Haskell code with C in quasiquotes. What's x /= 2?

dragonwriter 12y ago

That's not a weak typing artifact, its an artifact of the fact that different languages use operators with the same name but with different semantics. (And the fact that you can have PHP and JS, which are different languages, in the same file.) You could have the same issue with languages with indisputably strong, static typing with different semantics if there was a way of embedding them in the same file.

bunderbunder 12y ago
Language that value strong type-safety guarantees won't respond to a request for "1" + 1 by quietly coercing one value to the other's type and moving along as if nothing strange happened. They'll generate a type mismatch error because adding an integer to a text string is undefined operation.
- dragonwriter 12y ago
  Perhaps (though, discarding the emotional language of "quietly" and "as if nothing strange happened", there's all kinds of things in strong, statically-typed languages that aren't much different structurally from that, though if they did it would usually be by way of an operator working on a typeclass which included a total, rather than partial, conversion function to support the operation, so that the semantics of addition of string and whatever numeric type it was supported with would be well defined for all strings, rather than being only defined for particular strings; then again, its not like Haskell doesn't have functions that crash on values of an appropriate type but unsuppored specific values, so maybe not), but, in any case, f a b (or f(a,b) or (f a b) or a op b, depending on the syntax of the languages involved and the kind of function/operator at issue) having two different meanings in two different languages (specifically, two that can be included in the same file), which was what was complained about that example, isn't something that only occurs with that example, and it certainly can occur in strong statically-typed languages without even considering hypothetical constructs.