This is the talk page for discussing improvements to the Type system article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2, 3Auto-archiving period: 12 months |
This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||
|
Fundamental confusion about what types are in programming, and what are static and dynamic types
editLet'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)
- 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)
No Typing
editAnyone reading this article is likely to believe that all programming languages have type checking. They don't (eg Rexx). This article would be improved if it mentioned this (and why one might want to not carry out type checking). Then this article would cover the subject comprehensively. Eg an article describing why whales migrate would be incomplete if it failed to mentions that some wales off the West Coast of America no longer migrate. FreeFlow99 (talk) 18:36, 11 November 2021 (UTC)
- I think I would describe REXX as an extreme example of a dynamically-typed language. REXX has one data type, the character string. This also holds for for example Tcl and many command-line interpreters. REXX has the build-in function DATATYPE which will return NUM if its argument conforms to the syntax defined by REXX for numbers, and CHAR otherwise.[1]. What's more, I think the built-in arithmetic operations in REXX are required to raise a condition when given nonnumeric arguments (but I'm not sure). I would call this a run-time type check. Should the article say more about this?
- The lead section of the article already explains that type checking "can happen statically (at compile time), dynamically (at run time), or as a combination of both". The section Type system § Static and dynamic type checking in practice talks about the various trade-offs between the varying degrees of static and dynamic type checking.
- (A perhaps more extreme example of a language with a single data type would be B where the only data type is the machine word.)
- —Tea2min (talk) 12:28, 12 November 2021 (UTC)
- And STOIC and FORTH I think, but it is such a long time since I used STOIC I don't remember. Certainly everything that was passed between procedures/functions did so on the stack (as words I think). I don't think there was any static or dynamic type checking.
- In any case, the pros and cons of not having type checking, (or having minimal type checking), eg improved performance, or reduced bureaucracy/clutter ought to be included I think. One plausible argument against type checking is: if it only spots errors in programs written by the sort of person who would multiply a man's shoe size by his name, ie the sort of person who doesn't think clearly enough to be allowed to write software that others would rely on, we can expect that person will still manage to multiply a man's shoe size by his bank account number. FreeFlow99 (talk) 15:58, 12 November 2021 (UTC)
- This style of thinking is exemplified by 'free and bold estimation', as in the dimensional analysis from physics (see George Gamow's books 'One Two Three... Infinity', 'Thirty years that shook physics' (quantum mechanics), or 'My world-line' (relativity)) and the thinking of other creative thinkers (Gamow was influential in the thinking behind the genetic code). The mathematical rule would be that you may not add the differing units, but that you may multiply them.[a] Once the resultants are of the same type of composite unit, you may add them. --Ancheta Wis (talk | contribs) 13:38, 18 September 2022 (UTC)
- In any case, the pros and cons of not having type checking, (or having minimal type checking), eg improved performance, or reduced bureaucracy/clutter ought to be included I think. One plausible argument against type checking is: if it only spots errors in programs written by the sort of person who would multiply a man's shoe size by his name, ie the sort of person who doesn't think clearly enough to be allowed to write software that others would rely on, we can expect that person will still manage to multiply a man's shoe size by his bank account number. FreeFlow99 (talk) 15:58, 12 November 2021 (UTC)
- ^ 'Two Candlesticks * three cabdrivers = Six CandlestickCabdrivers'
Link to nothing
editUnder 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)
- I removed it, thanks for pointing it out. MrOllie (talk) 01:27, 9 August 2023 (UTC)