3 ms·

> I just don't understand why anyone would ever choose not to use types. Is there a language out there that gives you that choice? I expect you mean choose no

> I just don't understand why anyone would ever choose not to use types. Is there a language out there that gives you that choice? I expect you mean choose not to use strong static typing as per the original piece? Compatibility is a pretty good reason. I'd like to see Javascript die in the fiery pits of hell as much as the next guy, but its positioning means it is almost inevitable that some system will make it the only reasonable choice for you to choose if you want to build for that system. Typescript doesn't help. It adds static typing, but not strong typing.

junon 3y ago
Python and PHP both have type hints that are natively ignored by the language if present, but can be checked if you have enough of them, if that's what you mean.
- randomdata 3y ago
  No, I mean it lacks strong typing. C and C++ also lack strong typing even with static typing being a core feature and checked at compile time.
  - junon 3y ago
    There's no agreed upon definition of "strong" vs "weak" so you'll have to elaborate a bit.
    - randomdata 3y ago
      The only other use I'm familiar with where strong types are used to describe the equivalent of static types, but we've made clear distinction between the two here. What other definition is there? Usually: A strong type system does not allow types to change after being established. A weak type system allows types to change. This is also described in the original article.
      - 1-more 3y ago
        How is that different from static typing?
      - zabzonk 3y ago
        >A strong type system does not allow types to change so... like in c++?
        neverartful 3y ago
        No. C++ does allow types to change. That's exactly what casts are for.
        zabzonk 3y ago
        no. c++ allows you to convert a value of one type into a value of another type (in a very limited number of cases) but you cannot change the type of an object.
      - AnimalMuppet 3y ago
        C++ has casts. I don't regard those as making it a "weak" type system. I regard it as "strong type system with escape hatches", which is not the same thing. A strong type system should not be a straightjacket. (Languages that try to make types bulletproof tend to get used less than languages that allow escape hatches, and rightly so. The language designer never knows what the union of all use cases will be. Good language designers know that the user may have a case the designer didn't think of, and allow some flexibility to hopefully handle it.)
      - gpderetta 3y ago
        You can't change the type of an object in C++ so I'm not sure how your definition applies. Generally "strong" vs "weak" typing[1] is an ill-defined an mostly useless definition. [1] as opposed to static vs dynamic or safe vs unsafe.
        syndicatedjelly 3y ago
  - pavlov 3y ago
    C++ lacks strong typing? I'm curious what the type system is missing to qualify. Or do you mean that the C-based escape hatches like casting pointers make the type system inherently weak? You don't have to use them though...
    - robertlagrant 3y ago
      You don't have to make type errors either :-)
      - AnimalMuppet 3y ago
        Sure. But you have to deliberately use a cast; people rarely make deliberate type errors.
    - JonChesterfield 3y ago
      C++ has chosen a special place in the hellscape of language design by allowing you to silence the compiler using casts, where almost anything you do with the resulting object is undefined behaviour no diagnostic required. Said UB is observationally indistinguishable from miscompilation under some toolchains under some optimisation controls. It also has various bolt on weirdness like const doesn't mean the thing won't be changed by some other pointer so you can't constant propagate based on it, unless it's written on the global, at which point attempts to mutate it anyway may succeed under the usual UB challenges. Maybe that's a "strong" type system, but you'd only define it like that if you started by taking C++ as axiomatically reasonable.
prewett 3y ago
Static typing is already quite a help, as it makes whole categories of errors compile-time errors. > I'd like to see Javascript die in the fiery pits of hell as much as the next guy Part of the problem is that some of those "next guys" don't have the experience and/or vision to realize that it needs to die. Perhaps we should emulate Cato in our subsequent HN posts: And furthermore, I consider it necessary that Javascript be replaced with WebAssembly so that we can use well-designed languages in the browser.

junon 3y ago

Python and PHP both have type hints that are natively ignored by the language if present, but can be checked if you have enough of them, if that's what you mean.

randomdata 3y ago
No, I mean it lacks strong typing. C and C++ also lack strong typing even with static typing being a core feature and checked at compile time.
- junon 3y ago
  There's no agreed upon definition of "strong" vs "weak" so you'll have to elaborate a bit.
  - randomdata 3y ago
    The only other use I'm familiar with where strong types are used to describe the equivalent of static types, but we've made clear distinction between the two here. What other definition is there? Usually: A strong type system does not allow types to change after being established. A weak type system allows types to change. This is also described in the original article.
    - 1-more 3y ago
      How is that different from static typing?
    - zabzonk 3y ago
      >A strong type system does not allow types to change so... like in c++?
      - neverartful 3y ago
        No. C++ does allow types to change. That's exactly what casts are for.
        zabzonk 3y ago
        no. c++ allows you to convert a value of one type into a value of another type (in a very limited number of cases) but you cannot change the type of an object.
    - AnimalMuppet 3y ago
      C++ has casts. I don't regard those as making it a "weak" type system. I regard it as "strong type system with escape hatches", which is not the same thing. A strong type system should not be a straightjacket. (Languages that try to make types bulletproof tend to get used less than languages that allow escape hatches, and rightly so. The language designer never knows what the union of all use cases will be. Good language designers know that the user may have a case the designer didn't think of, and allow some flexibility to hopefully handle it.)
    - gpderetta 3y ago
      You can't change the type of an object in C++ so I'm not sure how your definition applies. Generally "strong" vs "weak" typing[1] is an ill-defined an mostly useless definition. [1] as opposed to static vs dynamic or safe vs unsafe.
      - syndicatedjelly 3y ago
- pavlov 3y ago
  C++ lacks strong typing? I'm curious what the type system is missing to qualify. Or do you mean that the C-based escape hatches like casting pointers make the type system inherently weak? You don't have to use them though...
  - robertlagrant 3y ago
    You don't have to make type errors either :-)
    - AnimalMuppet 3y ago
      Sure. But you have to deliberately use a cast; people rarely make deliberate type errors.
  - JonChesterfield 3y ago
    C++ has chosen a special place in the hellscape of language design by allowing you to silence the compiler using casts, where almost anything you do with the resulting object is undefined behaviour no diagnostic required. Said UB is observationally indistinguishable from miscompilation under some toolchains under some optimisation controls. It also has various bolt on weirdness like const doesn't mean the thing won't be changed by some other pointer so you can't constant propagate based on it, unless it's written on the global, at which point attempts to mutate it anyway may succeed under the usual UB challenges. Maybe that's a "strong" type system, but you'd only define it like that if you started by taking C++ as axiomatically reasonable.

prewett 3y ago

Static typing is already quite a help, as it makes whole categories of errors compile-time errors. > I'd like to see Javascript die in the fiery pits of hell as much as the next guy Part of the problem is that some of those "next guys" don't have the experience and/or vision to realize that it needs to die. Perhaps we should emulate Cato in our subsequent HN posts: And furthermore, I consider it necessary that Javascript be replaced with WebAssembly so that we can use well-designed languages in the browser.