Talk:Type system

message: Let's start with the confusion first:
    These types formalize and enforce the otherwise implicit categories the programmer uses for algebraic data types
The above claim is false in the sense that it only applies to a group of programming languages, but not all of them.  It is easy to see how this would go unnoticed since programming languages popular with the industry today would indeed fit nicely into this description.  However, it's important to also mention that initially, types in programming weren't perceived as formalization of algebraic data types (the idea of such is a much more modern construct), but, as optimization instructions for compilers specifying storage requirements.  This was the position of ALGOL authors, and, to a large extent, this is the position of many languages that predate ML / Miranda family of languages.
I also don't see why annotations like, for example, instantiation mode in languages in Prolog family would be treated differently from types (functionally, they serve the same purpose: to ensure program's correctness, and, perhaps, to hint the compiler about optimization opportunities). This is while more mainstream languages, like C, for example, can have a lot of modalities added to definitions, indicating whether or not a function needs to be inlined, whether or not the memory allocated to a struct needs to be padded with zeros to be a multiple of some number, whether a function needs to implement a particular calling convention and so on.  Similarly, Java's and C++'s checked exceptions and a lot of other such mechanisms, which all fall under the category of "ensuring program's correctness by providing more information at the time of its definition".  I don't see a reason for why would they be excluded from the type family.  I think, it needs to be stated that the "types as in type theory, a sub-field of mathematical logic =/= types in programming", however, closely related, especially in the context of a lot of modern languages.
Bottom line, I think the quoted statement is (unintentionally) biased towards particular interpretation of what types mean, but it's not general enough to properly reflect the much more diverse reality.
There's another very popular confusion: statically typed languages and dynamically typed languages.  A lot of people believe that these things exist, and use this terminology routinely.  However, there's no real definition that would support such separation.  In fact, if you were to follow whatever claims made by the people believing that a particular language is statically or dynamically typed, you'd easily discover a contradiction.  There's another way to interpret what "static" and "dynamic" means, when applied to types.  Unfortunately, I cannot quote a source, but the idea isn't mine: it makes it simple and unambiguous, and useful at the same time.  Static types are types known at any time before the program is executed (eg. compilation time, or syntax checking time etc.), while dynamic types are the types known at the time of execution time.  Thus, for example, a statement in Java of the form List<Integer> x = ...; will assign the static type "List<Integer>" to variable "x", but may assign type "ArrayList<Integer>" at run time.  Thus making the distinction meaningful and useful. 109.67.57.250 (talk) 21:38, 3 September 2019 (UTC)
replies: text: I wrote the first version of that sentence with "data types" but someone added the "algebraic" which I agree changes the meaning badly. Feel free to change this back, I don't have the inclination to get involved in edit wars. TobyK (talk) 17:39, 4 June 2022 (UTC)
thread_title:  Fundamental confusion about what types are in programming, and what are static and dynamic types 

message: Under See Also, there is a link to "Typing Rules" which is a page that does not exist. 69.120.241.110 (talk) 16:16, 8 August 2023 (UTC)
replies: text: I removed it, thanks for pointing it out. MrOllie (talk) 01:27, 9 August 2023 (UTC)
thread_title:  Link to nothing