9 ms·
> inferred strong static typing “strong” compared to what? Go's duck-typing actually makes it weaker than a lot more type systems than you might expect, and co
by halosghost 11y ago
> inferred strong static typing
“strong” compared to what? Go's duck-typing actually makes it weaker than a lot more type systems than you might expect, and compared to something like Haskell or Rust, both of these type systems are incredibly weak. If you're comparing to C, then sure, but “strong” and “weak” typing mean nothing without reference to another language.
- stcredzero 11y agoGo's duck-typing actually makes it weaker than a lot of type systems you might expect For me, it's strong enough and very versatile. It's stronger than what you effectively get in, say, Smalltalk. (Which, technically is strongly typed, having only 1 type of Object.) Having Interfaces explicitly documented in 1 place, but usable through duck typing is genius language design, in my view.
- halosghost 11y ago“Strong enough for what I want” is fine. But the author's point is unclear. Strong compared to what? Did the author mean “strong compared to Smalltalk”? Did the author mean “Go and Swift are Equally Strong”? “Strong” and “Weak” don't mean anything in discussions of typing without a reference-point.
- catnaroek 11y ago“Strong” vs. “weak” doesn't mean anything at all. Let's stick to distinctions that actually make sense: (0) Statically typed [e.g., Java] vs. not statically typed [e.g., Python]. (1) Dynamically typed [e.g., Java] vs. not dynamically typed [e.g., Haskell]. Yes, Java is both statically and dynamically typed. (2) Safe for arbitrary resources [e.g., Rust] vs. only memory-safe [e.g., Python] vs. totally unsafe [e.g., Objective-C]. (3) Typeful [e.g., Haskell] vs. not typeful [e.g., Objective-C]. (4) Global [e.g., Standard ML] vs. local [e.g., Scala] vs. no type inference at all [e.g., Java]. (5) Reflective [e.g., Common Lisp] vs. not reflective [e.g. Rust]. (6) Fixed [e.g., Standard ML] vs. extensible on top of a fixed core [e.g., C++] vs. extensible and modifiable [e.g., Common Lisp].
- dllthomas 11y agoThis is a very good list. With respect to Haskell and dynamic typing, I am curious whether you had considered Typeable and Data.Dynamic in your analysis (and, in general, your thoughts on how they relate to the distinction being made).
- catnaroek 11y agoIf I understand correctly, and I might be wrong, `Typeable` and `Data.Dynamic` require dedicated support from GHC, and couldn't possibly be implemented entirely as user libraries. This makes them core language features in my book. So the language specified in the Haskell Report isn't dynamically typed, but the GHC Haskell dialect is dynamically typed.
- dllthomas 11y agoAh, yes, report vs ghc is sometimes a very important distinction. Your assessment sounds correct.
- tome 11y agoI believe the situation is that Dynamic only requires Typeable, and Typeable only requires unsafeCoerce plus the trust that bad instances are never created.
- catnaroek 11y ago> unsafeCoerce GHC-specific implementation detail. > the trust that bad instances are never created The only way I can trust it is if the compiler enforces it, at which point it isn't “just a library feature”.
- supster 11y agoIn this context, strong as compared to Ruby/Python/Javascript
- whitegrape 11y agoSeems odd to lump Python (which is pretty strongly typed) with Ruby and JavaScript (JS especially not being strong). Edit: Actually this whole thread makes it seem like we all have our own different definitions on what makes something "strongly typed" (or just confusion with strong and static). For myself, a language's type system's relative strength is all about how it handles (or doesn't handle) implicit type conversions.
- supster 11y agoI lump them since they are the traditional "dynamic scripting" languages popular in backend development. But I agree the strong/weak designations are actually not so neatly segmented.
- halosghost 11y agoThis is roughly my point. “Strong” and “Weak” are inherently relative terms; so, when used without a reference point, they will mean something different to different people. So, without a point of reference, the terms are not useful.
- whitegrape 11y agoEven being inherently relative, you still need to determine the underlying values with some metric (like implicit type conversions, or max deadlift). If you tell me someone's max deadlift is twice their bodyweight, that tells me they're strong, even if it doesn't tell me their relative strength compared to say Sigmarsson. If someone says "Language X generally forces you to be explicit with your type conversions" that tells me it's strongly typed. Is it more strongly typed than language Y? That depends on explicitness exceptions -- e.g. Java does implicit autoboxing and toString()ing when you're doing string concatenation, Go effectively type aliases primitives so that e.g. net.IP can implicitly convert to []byte, Python complains when you don't explicitly call str() on things but converts numbers pretty freely (like auto-converting to a bignum, whereas other languages might throw an exception or automatically and silently wrap-around to a much smaller number than expected).
- glhaynes 11y agoSwift's is true strong [Edit: I should have said "static"] typing. The compiler enforces it but saves you from having to explicitly specify it in unambiguous cases. So: let x: Int = 3 let y: Int = x and let x = 3 let y = x are identical; in both cases, x and y are both strongly-typed as Int.
- halosghost 11y agoYou are confusing static typing and strong typing. I understand that both Go and Swift are statically typed. My comment is about saying that Go and Swift have type systems which are really strong, but such an assertion means nothing unless you give a point of reference (i.e., “strong compared to X”) To clarify, type inference and strength (or strictness actually) of typing are completely unrelated. For example, Haskell, which is statically typed (and far stronger than most other languages out there—though certainly not the strongest) has incredibly good type-inference, so you rarely need to specify types.
- voidlogic 11y agoFWIW, duck-typing happens at runtime, what Go has is structural typing.
- stcredzero 11y agoI had no idea there was a formal definition of Duck Typing. Because if we merely "duck type" Duck Typing...if it looks and sounds like it...
- voidlogic 11y agohttps://en.wikipedia.org/wiki/Duck_typing#In_Go https://en.wikipedia.org/wiki/Duck_typing#In_Go