4 ms·

The sort of "untyped" that your last sentence is referring to is a dead term, though. The only "untyped" language still in common use is assembler, and that's n

by jerf 2y ago

The sort of "untyped" that your last sentence is referring to is a dead term, though. The only "untyped" language still in common use is assembler, and that's not commonly written by hand anymore (and when it is, it's primarily running on numbers, not complex structs and complex values). There aren't any extant languages anymore that just accept numbers in RAM and just treat them as whatever. So increasingly, this objection is meaningless, because nobody is using "untyped" that way anymore. The way in which people do use the term, Python is only "optionally" typed, and a lot of real-world Python code is "untyped".

js2 2y ago
I think the objection is to the conflation of strong/weak with dynamic/static and it being unclear exactly what typed/untyped means, since it can refer to either. Python has always been strongly typed at runtime (dynamic), vs say JavaScript which is relatively weakly typed at runtime. Obviously lihaoyi was referring to static/dynamic when they wrote untyped (as made clear by the reference to type annotations) but kstrauser is objecting to using the term "untyped" since that can be interpreted to mean weak typing as well, which Python is not. $0.02 anyway.
- lolinder 2y ago
  Strong/weak is a meaningless dichotomy that could be replaced by nice/icky while conveying the same meaning. It just distinguishes whether I, personally, believe a given language has sufficient protections against dumb programmer errors. What counts as strong or weak depends entirely on who's talking. Some will say that everything from C on is strong, others draw the line at Java, still others aren't comfortable until you get to Haskell, and then there are some who want to go even further before it's truly "strong". Typed versus untyped is, on the other hand, a rigorously defined academic distinction, and one that very clearly places pre-type-hints Python in the untyped category. That's not a bad thing—untyped isn't inherently a derogatory term—but because untyped languages have fallen out of vogue there's a huge effort to rebrand them.
  - poincaredisk 2y ago
    ...but Python is obviously typed. It has types. In fact everything has a type, and even the types are of "type" type. It has type errors. Saying it's "untyped" invokes a wrong impression. Your usage is very non-standard in programmer circles. What's wrong with universally understood and well defined concepts of "statically" and "dynamically" typed languages?
    - lolinder 2y ago
      As I said in another comment [0], it depends on what definition of types we're using. But if we're going to pedantically jump down someone's throat correcting their usage (in this case OP's usage of "untyped"), we should at least use the most pedantically correct definition, which is the one used by academics who study type systems and which pointedly excludes dynamic checks. I have no problem with people using the other terminology in casual usage—I do so myself more often than not. I do have a problem with people pedantically correcting usage that is actually more correct than their preferred usage. I dislike pedantry in general, but I especially dislike incorrect pedantry. [0] https://news.ycombinator.com/item?id=42367659 https://news.ycombinator.com/item?id=42367659
    - c-cube 2y ago
      It's not "obviously" typed. Values in python have (runtime) types, sure. But contrast that with a statically typed language in which expressions (and functions) have types. Expressions in python do not have types at all (at least before annotations were added).
  - jyounker 2y ago
    Strong/weak typing is very specific thing. It refers to the ability to create invalid types within a language. In strongly typed languages it is hard to defeat the type system. In weakly typed languages it is easy to defeat the type system. Python is strongly typed (hard to escape the bounds of the type system) but (traditionally) dynamically typed (types are checked at runtime). C is weakly typed (easy to escape the type system), but statically typed (types are checked at compile time).
f1shy 2y ago
I could even argue that Asm is to some extent typed. Depends on the processor, but some cisc have operations for different types. But also the comment is correct: Python is strongly, dynamic typed.
- DougMerritt 2y ago
  Lisp CPUs had type bits stored with values, but I can't think of any typed CPUs still in use. What are you thinking of?
- kaladin-jasnah 2y ago
  Yes, agreed. I guess the typing would be for the size of the integer that you work with. For example, x86_64 assembly has different prefixes to indicate what part of a larger register you are using: 8 (lower), 8 (upper), 16 bit, 32 bit, and 64 bit itself. There are other "typed" operations, such as branching for unsigned vs. signed integers (think JA vs JG), or SAR vs SHR (signed arithmetic shift vs. unsigned arithmetic shift—one preserved the division logic of shifting for signed integers by repeating the MSB instead of adding zeroes when shifting). While I'm not too familiar with them (but have been meaning to learn more for years!!), SIMD instructions probably also have similar ideas of having different types for sizes of arrays.
munch117 2y ago
There's lots of programming languages still around with untyped elements to them. Javascript is one of them, with its string/number conversions and the way arrays are defined. Then there's all the stringly typed stuff. Make, CMake, Excel, TCL, bash. You're probably right that the original use of the term came from assembly vs. high level, but that objection is meaningless, because nobody is using "untyped" that way anymore.... What makes changing the meaning of "untyped" extra confusing is that dynamically typed programming languages often have types as 1st class objects, and they get used all the time for practical everyday programming. Calling these languages "untyped" is just wrong on the face of it -- they're full of types.
- lolinder 2y ago
  > changing the meaning of "untyped" extra confusing is that dynamically typed programming languages often have types as 1st class objects, and they get used all the time for practical everyday programming. Calling these languages "untyped" is just wrong on the face of it -- they're full of types. Just to be clear, it's the dynamically typed languages that changed the meaning of untyped. OP's usage is closer to the original and to the current usage of the terminology in the study of programming languages. Types and Programming Languages, one of the best regarded texts on types, has this helpful explanation: > A type system can be regarded as calculating a kind of static approximation to the runtime behaviors of the terms in a program. ... Terms like "dynamically typed" are arguably misnomers and should probably be replaced by "dynamically checked," but the usage is standard. In other words both are standard, but that's because the meaning of "types" has changed over time from its original sense and when it comes to the formal study of programming languages we still use the original terminology.
  - munch117 2y ago
    Just to be even clearer. In the time of the original use, there were only static types. Languages had very little in terms of UDT's. Even a struct in C was barely a type of its own. I don't recall the details, but there was something about struct member names not being local to the struct. Interpreted languages didn't have records or classes at all(*), and certainly not types as first class objects. We cannot really talk about how dynamically typed languages with rich type systems were originally labelled, back when they didn't exist at all. (*) I'm looking forward to someone pointing out an interesting counterexample.

by jerf 2y ago

js2 2y ago

I think the objection is to the conflation of strong/weak with dynamic/static and it being unclear exactly what typed/untyped means, since it can refer to either. Python has always been strongly typed at runtime (dynamic), vs say JavaScript which is relatively weakly typed at runtime. Obviously lihaoyi was referring to static/dynamic when they wrote untyped (as made clear by the reference to type annotations) but kstrauser is objecting to using the term "untyped" since that can be interpreted to mean weak typing as well, which Python is not. $0.02 anyway.

lolinder 2y ago
Strong/weak is a meaningless dichotomy that could be replaced by nice/icky while conveying the same meaning. It just distinguishes whether I, personally, believe a given language has sufficient protections against dumb programmer errors. What counts as strong or weak depends entirely on who's talking. Some will say that everything from C on is strong, others draw the line at Java, still others aren't comfortable until you get to Haskell, and then there are some who want to go even further before it's truly "strong". Typed versus untyped is, on the other hand, a rigorously defined academic distinction, and one that very clearly places pre-type-hints Python in the untyped category. That's not a bad thing—untyped isn't inherently a derogatory term—but because untyped languages have fallen out of vogue there's a huge effort to rebrand them.
- poincaredisk 2y ago
  ...but Python is obviously typed. It has types. In fact everything has a type, and even the types are of "type" type. It has type errors. Saying it's "untyped" invokes a wrong impression. Your usage is very non-standard in programmer circles. What's wrong with universally understood and well defined concepts of "statically" and "dynamically" typed languages?
  - lolinder 2y ago
    As I said in another comment [0], it depends on what definition of types we're using. But if we're going to pedantically jump down someone's throat correcting their usage (in this case OP's usage of "untyped"), we should at least use the most pedantically correct definition, which is the one used by academics who study type systems and which pointedly excludes dynamic checks. I have no problem with people using the other terminology in casual usage—I do so myself more often than not. I do have a problem with people pedantically correcting usage that is actually more correct than their preferred usage. I dislike pedantry in general, but I especially dislike incorrect pedantry. [0] https://news.ycombinator.com/item?id=42367659 https://news.ycombinator.com/item?id=42367659
  - c-cube 2y ago
    It's not "obviously" typed. Values in python have (runtime) types, sure. But contrast that with a statically typed language in which expressions (and functions) have types. Expressions in python do not have types at all (at least before annotations were added).
- jyounker 2y ago
  Strong/weak typing is very specific thing. It refers to the ability to create invalid types within a language. In strongly typed languages it is hard to defeat the type system. In weakly typed languages it is easy to defeat the type system. Python is strongly typed (hard to escape the bounds of the type system) but (traditionally) dynamically typed (types are checked at runtime). C is weakly typed (easy to escape the type system), but statically typed (types are checked at compile time).

f1shy 2y ago

I could even argue that Asm is to some extent typed. Depends on the processor, but some cisc have operations for different types. But also the comment is correct: Python is strongly, dynamic typed.

DougMerritt 2y ago
Lisp CPUs had type bits stored with values, but I can't think of any typed CPUs still in use. What are you thinking of?
kaladin-jasnah 2y ago
Yes, agreed. I guess the typing would be for the size of the integer that you work with. For example, x86_64 assembly has different prefixes to indicate what part of a larger register you are using: 8 (lower), 8 (upper), 16 bit, 32 bit, and 64 bit itself. There are other "typed" operations, such as branching for unsigned vs. signed integers (think JA vs JG), or SAR vs SHR (signed arithmetic shift vs. unsigned arithmetic shift—one preserved the division logic of shifting for signed integers by repeating the MSB instead of adding zeroes when shifting). While I'm not too familiar with them (but have been meaning to learn more for years!!), SIMD instructions probably also have similar ideas of having different types for sizes of arrays.

munch117 2y ago

There's lots of programming languages still around with untyped elements to them. Javascript is one of them, with its string/number conversions and the way arrays are defined. Then there's all the stringly typed stuff. Make, CMake, Excel, TCL, bash. You're probably right that the original use of the term came from assembly vs. high level, but that objection is meaningless, because nobody is using "untyped" that way anymore.... What makes changing the meaning of "untyped" extra confusing is that dynamically typed programming languages often have types as 1st class objects, and they get used all the time for practical everyday programming. Calling these languages "untyped" is just wrong on the face of it -- they're full of types.

lolinder 2y ago
> changing the meaning of "untyped" extra confusing is that dynamically typed programming languages often have types as 1st class objects, and they get used all the time for practical everyday programming. Calling these languages "untyped" is just wrong on the face of it -- they're full of types. Just to be clear, it's the dynamically typed languages that changed the meaning of untyped. OP's usage is closer to the original and to the current usage of the terminology in the study of programming languages. Types and Programming Languages, one of the best regarded texts on types, has this helpful explanation: > A type system can be regarded as calculating a kind of static approximation to the runtime behaviors of the terms in a program. ... Terms like "dynamically typed" are arguably misnomers and should probably be replaced by "dynamically checked," but the usage is standard. In other words both are standard, but that's because the meaning of "types" has changed over time from its original sense and when it comes to the formal study of programming languages we still use the original terminology.
- munch117 2y ago
  Just to be even clearer. In the time of the original use, there were only static types. Languages had very little in terms of UDT's. Even a struct in C was barely a type of its own. I don't recall the details, but there was something about struct member names not being local to the struct. Interpreted languages didn't have records or classes at all(*), and certainly not types as first class objects. We cannot really talk about how dynamically typed languages with rich type systems were originally labelled, back when they didn't exist at all. (*) I'm looking forward to someone pointing out an interesting counterexample.