4 ms·

I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conv

I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension. There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.

sysguest 3mo ago
> I don't recall anyone disliking types > where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension. hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?
- delta_p_delta_x 3mo ago
  That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.
  - MrJohz 3mo ago
    That's also true of Python, though, which is traditionally considered a strongly typed language. I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all. Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior. In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.
    - jbritton 3mo ago
      My understanding of weak typing is about allowing automatic type conversion. “3” + 1 === “31”, 1 + “3” === 4. Strong typing doesn’t auto convert.
      - Izkata 3mo ago
        Pretty much. There's probably better examples but using some of what's come up here so far: python is strong+dynamic, javascript is weak+dynamic, typescript is weak+static*, java is strong+static. * Maybe. Not quite sure about "weak" for this one, but I think it makes sense because you can just lie to typescript and then after compilation it just runs as javascript.
      - MrJohz 3mo ago
        This is one of the more common definitions, yes, but it's not used very consistently. The comment I replied to used a different definition, and I also commonly see the definition that weak typing is the ability to convert a type from one form to another (à la C). Like I said, if you're going to talk about automatic type conversion, then calling it "automatic type conversion" is probably the simplest option - strong vs weak typing doesn't really need to come into it. Then you avoid any definitional confusion.
_flux 3mo ago
There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression. But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime. Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like". It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.
- jt2190 3mo ago
  > Strongly typed and weakly typed do not seem to have good definitions. Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
  - dtech 3mo ago
    There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed. In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them. Example: const dogs: Dog[] = [] // A sound type system would error here, // but there's too many useful cases where you want to do this const animals: Animal[] = dogs animals.push(new Cat()) animals[0].bark() // runtime TypeError here
    - bennettpompi1 3mo ago
skybrian 3mo ago
[dead]
tgv 3mo ago
Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.
- kstrauser 3mo ago
  Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator. So: i = 23 # Create an int(23) object and store its address in i i = "foo" # Create a str("foo") object and store its address in i i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't. > Python's strong typing mostly boils down to some operator rejecting mixed types. Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.
  - tgv 3mo ago
    Saying a variable is of type pointer to any value instead of just any value doesn't make a difference for the semantics (except in some bad cases, like default parameter values). > It's also pragmatic... So it's almost like Javascript. That something is not a source of bugs, is not proof of strong typing. Python uses type information in some cases, that's it. E.g., it's trivial to load some record or file of the wrong type, and only find out much later. That's a real source of very unpleasant bugs.
- flossly 3mo ago
  Strongly typed is not a well defined term. But by most people definitions, Python certainly is NOT strongly typed. My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs. It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.
baq 3mo ago
haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5. for the record - I agree completely. (glad people are over the unicode thing!)
librasteve 3mo ago
[flagged]
tyingq 3mo ago
Last I tried, there's still often (not always) fighting with typing, mypy, pyright because of the dynamic nature you mention. I think the complaints about it are sometimes misinterpreted as "disliking types".
nsonha 3mo ago
> static, explicit typing the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.
fatata123 3mo ago
[dead]
deleted 3mo ago
[deleted]
munchbunny 3mo ago
> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.
knocte 3mo ago
> Python is strongly typed Get the f*ck outta here.
IshKebab 3mo ago
> I don't recall anyone disliking types. Lots of people disliked static typing Come on, that was very clearly what he was talking about. No need to be this pedantic.
epolanski 3mo ago
> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about. Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as propositions about program behavior like in ML, which highly influenced modern type systems, including TypeScript, albeit Ocaml, F# and the Rust type system belong to the ML family.

sysguest 3mo ago

> I don't recall anyone disliking types > where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension. hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?

delta_p_delta_x 3mo ago
That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.
- MrJohz 3mo ago
  That's also true of Python, though, which is traditionally considered a strongly typed language. I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all. Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior. In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.
  - jbritton 3mo ago
    My understanding of weak typing is about allowing automatic type conversion. “3” + 1 === “31”, 1 + “3” === 4. Strong typing doesn’t auto convert.
    - Izkata 3mo ago
      Pretty much. There's probably better examples but using some of what's come up here so far: python is strong+dynamic, javascript is weak+dynamic, typescript is weak+static*, java is strong+static. * Maybe. Not quite sure about "weak" for this one, but I think it makes sense because you can just lie to typescript and then after compilation it just runs as javascript.
    - MrJohz 3mo ago
      This is one of the more common definitions, yes, but it's not used very consistently. The comment I replied to used a different definition, and I also commonly see the definition that weak typing is the ability to convert a type from one form to another (à la C). Like I said, if you're going to talk about automatic type conversion, then calling it "automatic type conversion" is probably the simplest option - strong vs weak typing doesn't really need to come into it. Then you avoid any definitional confusion.

_flux 3mo ago

There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression. But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime. Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like". It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.

jt2190 3mo ago
> Strongly typed and weakly typed do not seem to have good definitions. Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
- dtech 3mo ago
  There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed. In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them. Example: const dogs: Dog[] = [] // A sound type system would error here, // but there's too many useful cases where you want to do this const animals: Animal[] = dogs animals.push(new Cat()) animals[0].bark() // runtime TypeError here
  - bennettpompi1 3mo ago

skybrian 3mo ago

[dead]

tgv 3mo ago

Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.

kstrauser 3mo ago
Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator. So: i = 23 # Create an int(23) object and store its address in i i = "foo" # Create a str("foo") object and store its address in i i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't. > Python's strong typing mostly boils down to some operator rejecting mixed types. Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.
- tgv 3mo ago
  Saying a variable is of type pointer to any value instead of just any value doesn't make a difference for the semantics (except in some bad cases, like default parameter values). > It's also pragmatic... So it's almost like Javascript. That something is not a source of bugs, is not proof of strong typing. Python uses type information in some cases, that's it. E.g., it's trivial to load some record or file of the wrong type, and only find out much later. That's a real source of very unpleasant bugs.
flossly 3mo ago
Strongly typed is not a well defined term. But by most people definitions, Python certainly is NOT strongly typed. My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs. It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.

baq 3mo ago

haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5. for the record - I agree completely. (glad people are over the unicode thing!)

librasteve 3mo ago

[flagged]

tyingq 3mo ago

Last I tried, there's still often (not always) fighting with typing, mypy, pyright because of the dynamic nature you mention. I think the complaints about it are sometimes misinterpreted as "disliking types".

nsonha 3mo ago

> static, explicit typing the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.

fatata123 3mo ago

[dead]

deleted 3mo ago

[deleted]

munchbunny 3mo ago

> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.

knocte 3mo ago

> Python is strongly typed Get the f*ck outta here.

IshKebab 3mo ago

> I don't recall anyone disliking types. Lots of people disliked static typing Come on, that was very clearly what he was talking about. No need to be this pedantic.

epolanski 3mo ago

> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about. Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as propositions about program behavior like in ML, which highly influenced modern type systems, including TypeScript, albeit Ocaml, F# and the Rust type system belong to the ML family.