8 ms·

I still think the way Common Lisp handled typing was very convenient: Typing was basically dynamic, but one could use static typing in specific places, and one

by krylon 10y ago

I still think the way Common Lisp handled typing was very convenient: Typing was basically dynamic, but one could use static typing in specific places, and one could even tell the compiler if this was for speed or for safety. I like the idea of a hybrid type system where statically typed and dynamically typed parts coexist, OTOH, I can imagine it being difficult to implement.

bandrami 10y ago
Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) but zero type checking for variables (a variable can have as its symbol-value literally any value at any time), other than the type hints you provide (which by the spec the compiler is free to ignore). I think a lot of static type systems don't sufficiently appreciate that those are two different questions.
- krylon 10y ago
  Somewhere on the Internet - I think on the c2.com wiki - there is a discussion on type systems that organizes them on two axes, static vs dynamic and strong vs weak. Static vs dynamic refers to how much the compiler/interpreter knows about the types being used before execution. Strong vs weak refers to how easy or difficult it is to subvert the type system, e.g. by casting pointers or using unions. That discussion was an eye-opener for me regarding type systems; to this day, I cringe when somebody calls, e.g. Python or Javascript a "typeless" languange.
  - paddyoloughlin 10y ago
    Strong vs weak is essentially meaningless. There is no generally agreed upon definition of what the distinction means.
    - kbenson 10y ago
      Just because there is some controversy over it doesn't mean it's meaningless. In this case it just means that it's not as descriptive as we would hope, and it's better used to describe as aspect of a language, as they are often strongly typed in some aspects and weakly typed in others.
      - jstimpfle 10y ago
        Bravo! So much hair-splitting and (deliberate?) misinterpretation of context on the internet. We need more counters done your way to keep discussions focused: Factual and to the point.
      - paddyoloughlin 10y ago
        First, my post said 'essentially meaningless', which is to say 'possibly not completely, but for the most part, meaningless'. Second, the context here is whether or not the type system of a language is strong or it is weak. I stand by my assertion that describing type systems as strong or weak typing is essentially meaningless. It's so far from descriptive that all 'strongly typed' ever really means is 'I like this feature' and 'weakly typed' means 'I do not like this feature'. There are alternative, accurate ways of talking about what people think they are trying to get at when they use the terms strong and weak in relation to languages. They should be used instead.
  - kbenson 10y ago
    This is a well known distinction, talked about in many places[1]. Python would be dynamic and strongly typed, Perl would be dynamic and weakly typed, at least WRT numerical and string types, which is why it uses different operators to distinguish between those types of operations (compared to Python's use of + for for numerical addition and string concatenation. Perl could also be said to be strongly typed WRT scalars and arrays, so it depends on your point of view. There is some controversy over the strong/weak terminology, IMO mostly because almost no language is clearly strong or weak based on the definitions generally used[2]. I find it useful to think about whether things are done implicity, or whether you need to specifically convert types. Perl will happily add "1" and "1" to get 2, because the + operator forces it to be interpreted as a numeric type. Python will not, and expects you to convert to a numeric type first. Of course, exceptions to the rule abound. 1: http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak http://stackoverflow.com/questions/2351190/static-dynamic-vs... 2: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
    - catnaroek 10y ago
      Okay, so you're saying that: (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions.
      - kbenson 10y ago
        > (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. If it were true that everything is a string, then yes, you probably could say it's strongly typed. It's laughable, but it is. Some single celled organisms are animals, as well. Assembly is generally the strongest typed language you can get. But it's not true. Bash supports associative arrays. #!/bin/bash declare -A array_var array_var=( ["foo"]="11" ["bar"]="22" ); echo "$array_var"; # Empty line echo "${array_var[foo]}"; # 11 scalar_var="baz"; echo $scalar_var; # bar array_var="quux"; echo "$array_var"; # quux echo "${array_var[foo]}"; # 11 That said, I'm not sure if you can actually access the array container itself (I don't use bash for actual programming), so I'm not sure how it handles comparisons and operations between the types, if it's even possible. It may be Bash is strongly typed (I'm not sure), but we can't make that determination by assuming it has a single data type. Also, even if it was a single data type, there are interstitial types that exist for doing numeric operations, and I'm not sure how to consider those with respect to this concept. > (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. > > (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. You're making very strong assertions based on my comment when I made sure to to say "almost no language is clearly strong or weak based on the definitions generally used", and even provided examples where the same language could be considered both strongly and weakly typed, depending on what aspect you were referring to. "Strong" and "weak" are themselves relative terms, so make no sense unless comparing to something else. That may be a shared reference language, or the perceived common level of languages with respect to what is being discussed. I replied to the sibling of my original comment with some info about how I think about this. It's rarely useful to think of a language as entirely strongly or weakly typed, but certain aspects of it may or may not be (again, relative to some benchmark). > There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions. Well, treating the same datum as a number and a string in different places is exacerbated by implicit conversions, which allow that behavior to succeed. I wouldn't say it's independent, I would say one depends on the other. Really, whether they are well defined terms or not, I think it's still still useful to use them with some disambiguating context, as they express a concept otherwise hard to convey (if it was easy to convey, they wouldn't be so ambiguous in the first place).
- hcarvalhoalves 10y ago
  > Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) Out of curiosity: if I'm not mistaken, this was an implementation detail of LISP machines [1], and allowed bytecode-level optimizations. [1] https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
  - krylon 10y ago
    I vaguely remember reading that this did not originate on Lisp machines, but they supported this at the hardware level, making it a lot faster. (Like I said: "vaguely"! This is third- to fourth-hand knowledge, at best.)
junke 10y ago
Agree. However: s/was/is/g s/could/can/g Premature burial is a little bit scary, I take it you are doing this because Halloween is near.
- Roboprog 10y ago
  Languages never die. But companies stop making new projects with them - for some number of 9s percent of companies. E.g. - FOOGOLTRAN is a five-nine dead language, if 99.999% of new projects don't use it.
  - Roboprog 10y ago
    I guess as long as a language is used in at least 11% of projects, it can avoid being "one-nine" dead :-)
  - sillysaurus3 10y ago
    I like this definition of language deadness. It seems especially useful when restricted to one decade.
- krylon 10y ago
  Thanks for the correction! ;-)
ddfisher 10y ago
This is exactly what mypy allows, actually! (Except for speedups -- types currently have no effect on runtime behavior, and it turns out they wouldn't make a big difference anyway.) The hybrid type system concept is called "gradual typing", and it's actually powered by some somewhat-recent developments in programming language theory. See this seminal paper by Jeremy Siek in 2006 if you're interested in the details: http://scheme2006.cs.uchicago.edu/13-siek.pdf http://scheme2006.cs.uchicago.edu/13-siek.pdf [Source: I'm a mypy core developer.]
- krylon 10y ago
  That sounds sweet! It's been a while since I did anything in Python (at work, for various reasons, I mostly use Perl when I can, C# when I have to). But the next time I do something with Python, I'll make sure to check it out!

by krylon 10y ago

bandrami 10y ago

Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) but zero type checking for variables (a variable can have as its symbol-value literally any value at any time), other than the type hints you provide (which by the spec the compiler is free to ignore). I think a lot of static type systems don't sufficiently appreciate that those are two different questions.

krylon 10y ago
Somewhere on the Internet - I think on the c2.com wiki - there is a discussion on type systems that organizes them on two axes, static vs dynamic and strong vs weak. Static vs dynamic refers to how much the compiler/interpreter knows about the types being used before execution. Strong vs weak refers to how easy or difficult it is to subvert the type system, e.g. by casting pointers or using unions. That discussion was an eye-opener for me regarding type systems; to this day, I cringe when somebody calls, e.g. Python or Javascript a "typeless" languange.
- paddyoloughlin 10y ago
  Strong vs weak is essentially meaningless. There is no generally agreed upon definition of what the distinction means.
  - kbenson 10y ago
    Just because there is some controversy over it doesn't mean it's meaningless. In this case it just means that it's not as descriptive as we would hope, and it's better used to describe as aspect of a language, as they are often strongly typed in some aspects and weakly typed in others.
    - jstimpfle 10y ago
      Bravo! So much hair-splitting and (deliberate?) misinterpretation of context on the internet. We need more counters done your way to keep discussions focused: Factual and to the point.
    - paddyoloughlin 10y ago
      First, my post said 'essentially meaningless', which is to say 'possibly not completely, but for the most part, meaningless'. Second, the context here is whether or not the type system of a language is strong or it is weak. I stand by my assertion that describing type systems as strong or weak typing is essentially meaningless. It's so far from descriptive that all 'strongly typed' ever really means is 'I like this feature' and 'weakly typed' means 'I do not like this feature'. There are alternative, accurate ways of talking about what people think they are trying to get at when they use the terms strong and weak in relation to languages. They should be used instead.
- kbenson 10y ago
  This is a well known distinction, talked about in many places[1]. Python would be dynamic and strongly typed, Perl would be dynamic and weakly typed, at least WRT numerical and string types, which is why it uses different operators to distinguish between those types of operations (compared to Python's use of + for for numerical addition and string concatenation. Perl could also be said to be strongly typed WRT scalars and arrays, so it depends on your point of view. There is some controversy over the strong/weak terminology, IMO mostly because almost no language is clearly strong or weak based on the definitions generally used[2]. I find it useful to think about whether things are done implicity, or whether you need to specifically convert types. Perl will happily add "1" and "1" to get 2, because the + operator forces it to be interpreted as a numeric type. Python will not, and expects you to convert to a numeric type first. Of course, exceptions to the rule abound. 1: http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak http://stackoverflow.com/questions/2351190/static-dynamic-vs... 2: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
  - catnaroek 10y ago
    Okay, so you're saying that: (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions.
    - kbenson 10y ago
      > (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. If it were true that everything is a string, then yes, you probably could say it's strongly typed. It's laughable, but it is. Some single celled organisms are animals, as well. Assembly is generally the strongest typed language you can get. But it's not true. Bash supports associative arrays. #!/bin/bash declare -A array_var array_var=( ["foo"]="11" ["bar"]="22" ); echo "$array_var"; # Empty line echo "${array_var[foo]}"; # 11 scalar_var="baz"; echo $scalar_var; # bar array_var="quux"; echo "$array_var"; # quux echo "${array_var[foo]}"; # 11 That said, I'm not sure if you can actually access the array container itself (I don't use bash for actual programming), so I'm not sure how it handles comparisons and operations between the types, if it's even possible. It may be Bash is strongly typed (I'm not sure), but we can't make that determination by assuming it has a single data type. Also, even if it was a single data type, there are interstitial types that exist for doing numeric operations, and I'm not sure how to consider those with respect to this concept. > (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. > > (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. You're making very strong assertions based on my comment when I made sure to to say "almost no language is clearly strong or weak based on the definitions generally used", and even provided examples where the same language could be considered both strongly and weakly typed, depending on what aspect you were referring to. "Strong" and "weak" are themselves relative terms, so make no sense unless comparing to something else. That may be a shared reference language, or the perceived common level of languages with respect to what is being discussed. I replied to the sibling of my original comment with some info about how I think about this. It's rarely useful to think of a language as entirely strongly or weakly typed, but certain aspects of it may or may not be (again, relative to some benchmark). > There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions. Well, treating the same datum as a number and a string in different places is exacerbated by implicit conversions, which allow that behavior to succeed. I wouldn't say it's independent, I would say one depends on the other. Really, whether they are well defined terms or not, I think it's still still useful to use them with some disambiguating context, as they express a concept otherwise hard to convey (if it was easy to convey, they wouldn't be so ambiguous in the first place).
hcarvalhoalves 10y ago
> Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) Out of curiosity: if I'm not mistaken, this was an implementation detail of LISP machines [1], and allowed bytecode-level optimizations. [1] https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
- krylon 10y ago
  I vaguely remember reading that this did not originate on Lisp machines, but they supported this at the hardware level, making it a lot faster. (Like I said: "vaguely"! This is third- to fourth-hand knowledge, at best.)

junke 10y ago

Agree. However: s/was/is/g s/could/can/g Premature burial is a little bit scary, I take it you are doing this because Halloween is near.

Roboprog 10y ago
Languages never die. But companies stop making new projects with them - for some number of 9s percent of companies. E.g. - FOOGOLTRAN is a five-nine dead language, if 99.999% of new projects don't use it.
- Roboprog 10y ago
  I guess as long as a language is used in at least 11% of projects, it can avoid being "one-nine" dead :-)
- sillysaurus3 10y ago
  I like this definition of language deadness. It seems especially useful when restricted to one decade.
krylon 10y ago
Thanks for the correction! ;-)

ddfisher 10y ago

This is exactly what mypy allows, actually! (Except for speedups -- types currently have no effect on runtime behavior, and it turns out they wouldn't make a big difference anyway.) The hybrid type system concept is called "gradual typing", and it's actually powered by some somewhat-recent developments in programming language theory. See this seminal paper by Jeremy Siek in 2006 if you're interested in the details: http://scheme2006.cs.uchicago.edu/13-siek.pdf http://scheme2006.cs.uchicago.edu/13-siek.pdf [Source: I'm a mypy core developer.]

krylon 10y ago
That sounds sweet! It's been a while since I did anything in Python (at work, for various reasons, I mostly use Perl when I can, C# when I have to). But the next time I do something with Python, I'll make sure to check it out!