4 ms·

Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than othe

Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than others) and they have casts that allow programmers to circumvent the type system (but so does Ocaml with its Obj.magic, and Haskell with its unsafeCoerce). The strong/weak distinction isn't particularly valuable in the first place, but it becomes especially useless if you try to shoehorn C/C++ into the "weak" category.

nabla9 3y ago
I disagree. Firstly, Ability to circumvent type system means it's a weak type system. In in C and C++ you can take pointer to anything and cast it into anything. The memory model in both languages is just one or more contiguous sequences of bytes. https://en.cppreference.com/w/cpp/language/memory_model https://en.cppreference.com/w/cpp/language/memory_model Secondly, What you call "functional/academic language snobbery" is accurate language that every software engineer benefits from using and understanding. Being professional is not snobbery or elitism.
- jemfinch 3y ago
  You're issuing a correction for your original post, then? Haskell can circumvent the type system with unsafeCoerce and cast anything into anything else, therefore it (by your definition) is weakly typed. Same thing with Ocaml and Obj.magic. Practically every strongly typed language has a mechanism for circumventing the type system: C: (type) casts C++: reinterpret_cast and friends Haskell: unsafeCoerce Ocaml: Obj.magic Golang: unsafe.Pointer Rust: std::mem::transmute SML: MLton doesn't provide one, but SML/NJ provides Unsafe.cast. So I guess MLton's flavor of SML is strongly typed, but SML/NJ's is weakly typed. Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones.
  - nequo 3y ago
    > Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones. Here is a definition: a language is weakly typed if and only if it has implicit type conversion. JavaScript is weakly typed: > "3" * "4" 12 Haskell is not: ghci> "3" * "4" <interactive>:1:5: error: • No instance for (Num String) arising from a use of ‘*’ • In the expression: "3" * "4" In an equation for ‘it’: it = "3" * "4" Neither is OCaml: utop # "3" * "4";; Error: This expression has type string but an expression was expected of type int C++ is weakly typed: #include <iostream> int main() { int x = 7; bool y = x; std::cout << x << "\n"; std::cout << y << "\n"; return 0; } which prints 7 1 Haskell and OCaml are not weakly typed: ghci> let x = 7 in let (y :: Bool) = x in print y <interactive>:4:32: error: • No instance for (Num Bool) arising from a use of ‘x’ • In the expression: x In a pattern binding: (y :: Bool) = x In the expression: let (y :: Bool) = x in print y utop # let x = 7 in let (y : bool) = x in Printf.printf "%B\n" y;; Error: This expression has type int but an expression was expected of type bool
    - wizzard0 3y ago
      does operator overloading turn c++ and others into the weakly typed language? does typescript-like type checking (which barks on 1+”1”) with “disallow emit on error” turn javascript into the strongly typed one?
      - nequo 3y ago
        > does operator overloading turn c++ and others into the weakly typed language? Polymorphism is not the same as implicit type conversion. For example, in Haskell, `*` is defined for both integers and doubles so 3 * 4 and 3.0 * 4.0 both work without type conversion. But JavaScript converts strings to numbers in "3" * "4". > does typescript-like type checking (which barks on 1+”1”) with “disallow emit on error” turn javascript into the strongly typed one? I think so. And this is not surprising. TypeScript is a different language from JavaScript (even if it’s a superset of it).
      - funcDropShadow 3y ago

nabla9 3y ago

I disagree. Firstly, Ability to circumvent type system means it's a weak type system. In in C and C++ you can take pointer to anything and cast it into anything. The memory model in both languages is just one or more contiguous sequences of bytes. https://en.cppreference.com/w/cpp/language/memory_model https://en.cppreference.com/w/cpp/language/memory_model Secondly, What you call "functional/academic language snobbery" is accurate language that every software engineer benefits from using and understanding. Being professional is not snobbery or elitism.

jemfinch 3y ago
You're issuing a correction for your original post, then? Haskell can circumvent the type system with unsafeCoerce and cast anything into anything else, therefore it (by your definition) is weakly typed. Same thing with Ocaml and Obj.magic. Practically every strongly typed language has a mechanism for circumventing the type system: C: (type) casts C++: reinterpret_cast and friends Haskell: unsafeCoerce Ocaml: Obj.magic Golang: unsafe.Pointer Rust: std::mem::transmute SML: MLton doesn't provide one, but SML/NJ provides Unsafe.cast. So I guess MLton's flavor of SML is strongly typed, but SML/NJ's is weakly typed. Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones.
- nequo 3y ago
  > Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones. Here is a definition: a language is weakly typed if and only if it has implicit type conversion. JavaScript is weakly typed: > "3" * "4" 12 Haskell is not: ghci> "3" * "4" <interactive>:1:5: error: • No instance for (Num String) arising from a use of ‘*’ • In the expression: "3" * "4" In an equation for ‘it’: it = "3" * "4" Neither is OCaml: utop # "3" * "4";; Error: This expression has type string but an expression was expected of type int C++ is weakly typed: #include <iostream> int main() { int x = 7; bool y = x; std::cout << x << "\n"; std::cout << y << "\n"; return 0; } which prints 7 1 Haskell and OCaml are not weakly typed: ghci> let x = 7 in let (y :: Bool) = x in print y <interactive>:4:32: error: • No instance for (Num Bool) arising from a use of ‘x’ • In the expression: x In a pattern binding: (y :: Bool) = x In the expression: let (y :: Bool) = x in print y utop # let x = 7 in let (y : bool) = x in Printf.printf "%B\n" y;; Error: This expression has type int but an expression was expected of type bool
  - wizzard0 3y ago
    does operator overloading turn c++ and others into the weakly typed language? does typescript-like type checking (which barks on 1+”1”) with “disallow emit on error” turn javascript into the strongly typed one?
    - nequo 3y ago
      > does operator overloading turn c++ and others into the weakly typed language? Polymorphism is not the same as implicit type conversion. For example, in Haskell, `*` is defined for both integers and doubles so 3 * 4 and 3.0 * 4.0 both work without type conversion. But JavaScript converts strings to numbers in "3" * "4". > does typescript-like type checking (which barks on 1+”1”) with “disallow emit on error” turn javascript into the strongly typed one? I think so. And this is not surprising. TypeScript is a different language from JavaScript (even if it’s a superset of it).
    - funcDropShadow 3y ago