Those that use a language without a ''proper'' type system are (or can accidentally be) liars, and should implement types into the source comments if held at gun point and forced to work with an ''improper language''. See also WeakTypesLie and LooseTypesSuck. * Small quibble: One can't accidentally be a liar. All lies are untruths, but not all untruths are lies. To lie, you have to believe that you are not telling the truth AND you have to actually not be telling the truth. ''How is it called if you believe you are not telling the truth, but doing so? Isn't that also a lie (if only an intended one)?'' Put the type system (or hopefully some of it) into the source comments. Or at least, one should.. because all languages need ''truth''. $var = 'hello'; // type: string $iMain = 5; // anything starting with "i" will be an integer in this program // this function ONLY DEALS WITH INTEGERS (oh shit, it's a function? or procedure? I forgot) function foo($i) { $i[0] = 'h'; $i[1] = 'i'; // oops, I like to lie // hehehe I'm a liar pants on fire print $i; } // this function DOES NOT RETURN ANYTHING, IT IS NOT A FUNCTION (IT'S A PROCEDURE) function bar($i) { return 'hi'; // I like to lie // hehehe I'm a '''liar''' pants on '''fire''' } ---- Many low level languages do this. For example, AssemblyLanguage and ForthLanguage primarily use machine words (cells), so typing is by convention. In Forth, this is expressed via "stack comments" which take the form ( stack before -- stack after ). It is up to the programmer to obey and enforce the comments, via careful programming and thorough testing. e ---- This page was started because an opinion is (a ''strong'' one.. maybe even a ''right'' one) that type systems keep code readable, sterile, sane, and integral. They allow humans, not just compilers, to check over and keep code sane. As Dijkstra put it - once upon a time doctors (professional surgeons) did not believe in sterility because real doctors and real men performed surgery without cleaning/boiling their utensils. If one had to keep his utensils sterile then he obviously ''wasn't very competent'' nor was he ''skilled'' because real surgeons could perform surgery with any utensil. Similarly, arrogant programmers have an attitude that code does not have to be kept sterile because real programmers can code correctly using assembly language or PHP with no sound type system. * On hygiene, intellectual and otherwise *** http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1054.html ''Empirical studies showed that hand-washing helps. There's no equivalent for a "scriptish" style, at least not across all domains. Thus, your analogy is weak at best. And I find your "arrogant" comment, well, arrogant. And, you keep stating it over and over, making this slothful-versus-anal fight last forever. Until there is empirical evidence, the arrogant one is the one who claims objective net advantage before the proof arrives. (Incidentally, I don't really like PHP's type system either. I'd prefer no types to half-assed types: TypelessVsDynamic) --top'' [You'd prefer no types? Really? You mean in PHP you'd rather there were only undifferentiated bit strings of arbitrary size (i.e., a blob), and would prefer to identify what a particular blob means purely by choice of operator? To add two integers you'd have to do something like '4 +I 3', and to add two floats might be '4.2 +F 3.5', and so on. Of course, it would mean something like '4.2 +I 3.5' would return an unpredictable result -- which would depend what the internal representation of a float becomes when interpreted as an integer. Are you sure you don't mean you'd prefer a different form of DynamicTyping?] ''It would take a while to describe the comparison operator system I'd personally prefer. However, I will point out that one usually does not have to distinguish between integer and floating arithmetic. If two integers (nums with no decimal places) are added, the result should '''always''' be an integer. (Whether existing engines do that or not is another matter.) And something besides "+" should be used for string concatenation. Further, 4.2 +I 3.5 is poor form. It should be rewritten as something like round(a) + round(b).'' [I'm sure 4.2 +I 3.5 is bad form. It was an illustration, not a suggested syntax. I wrote that you'd have to do something ''like'' it, not that you'd have to do it. So... You'd like something closer to the metal than C, but not as gnarly as AssemblyLanguage or as, uh, Forth-ish as Forth? Interesting. I'd never have taken you for that much of a low-level, down-and-dirty kind of programmer. Do you secretly harbour a desire to be an EmbeddedSystems coder? Is writing reports and business apps just the day job, and you long for the romance and swashbuckling adventure of washing-machine controllers and engine management units?] * I find it odd that you compare a scriptish style to C and assembler. In the latter one is often dealing with fixed-length byte items, but a scriptish style does not. It is dealing mostly with strings as its atomic unit, not bytes. * [It was meant to be funny, but obviously wasn't. See below. It would be more accurate to describe your ideal system as one consisting of a single type -- character string -- rather than typeless.] * The difference is splitting academic hairs. It's a one-handed man clapping. It is almost analogous to a table with a single column. Technically it may still qualify as a "table", but we are not using it in such a fashion. It's a set for all intents. * [No, it isn't, unless calling a cat a dog is "splitting academic hairs."] * At best, a UselessTruth. * {Perhaps it would be a UselessTruth if every possible 'single type' were identical. However, that is very far from the case. Single type means you still need to pick that type and its basic operators, whereas Typeless would imply there are no types to pick. The choice of this type and the operators associated with it - be it string or lambda or blob or combinator or anything else - impacts the language rather significantly.} {Eh? He said "nums with no decimal places", so obviously his 'typeless' approach has enough of a type to distinguish decimal-place bit-patterns from other bit-patterns. Perhaps he's aiming for EverythingIsa string. That's not quite so close to the metal as you describe here.} [I know what he meant. My tongue was firmly embedded in cheek when I wrote the above.] That is "characteristics of numbers". Numbers can have a lot of characteristics: decimal place quantity, positive, odd, by-tens, etc. etc. etc. Such can be represented as types if one wants to shoehorn their world view into types (EverythingIsa), but that is not the same as *being* types and only being types. I find a set-theory-based "feature" view more flexible and scalable. Stuff has features, and a list (set) of all possible features usually does not fit well into type systems because type systems get unbearably messy and difficult to maintain if they drift too far from trees. Why should "integerness" be treated significantly different than "positiveness" or "even-ness"? Why have one be inside the formal type system and the other be out? It is a design DiscontinuitySpike. Byte the bullet and go attribute sets all the way for consistency. (Perhaps take this to SetsVersusTypes.) --top {Nothing about TypeTheory requires types in a TypeSystem be exclusive; they can overlap as much as sets - even more so, given possibility for dualities that sets alone lack (type can relate to intersection or union or subset or superset depending on context and semantics). I've worked with languages where 'prime integer' or 'even positive integer' can easily be declared as a type for a variable. I'll agree that most production-language type implementations aren't quite as flexible as is desirable; they tend to aim for easier implementation or guaranteed termination at some loss of generality (and in some ways are 'simplistic' for it - when they force someone to work around the type system rather than with the type system), though they often guarantee the goal of TypeSafety.} A sufficiently-powerful "type system" that can handle lots of variations of features well will more or less trigger GreencoddsTenthRuleOfProgramming. * [No, a type system, regardless of power, will not resemble a database. A type system, however, may be used to define what can be contained in a database. At worst, it might trigger GreenspunsTenthRuleOfProgramming.] * ''It probably can, but the conflict would probably be over "should".'' * [Huh?] * {Top seeks a conflict. If he can't gain one by arguing that type systems aren't powerful enough, he'll attempt to create one by arguing the type systems will be too powerful. Afterwards, he'll have his cake and eat it, too.} * Expecting and seeking are two different things. And I'm sure type systems *can* be very powerful. However, that doesn't necessarily make them human-friendly. TuringTrap. Gee, you guys love painting me with such wonderful colors. --top * [Is your opinion of advanced type systems based on extensive experience and in-depth research?] * {Top is right that people ''can'' make type systems that are simultaneously powerful and far from human friendly. However, I'm baffled as to why he seems to think that's a valid argument in the context of whether we "should" build powerful type systems. Will he later argue against whether we "should" wear clothes because they aren't ''necessarily'' human-friendly and that we ''could'' create them so they suffocate or strangle or poison us? Or is he just spreading his peculiar brand of hypocritical and irrational FUD? I guess we'll find out in our next installment of N''''''onStopNonSenseFromTop.} * I'm tired of your repeated rudeness. My point is that "effective" validation/type-checking/feature-tracking will most likely come down to personal preference and psychology. Nobody can objective prove that any given approach to validation/type-checking/feature-tracking is better than the other. Shouting your opinion louder and louder is not a substitution for proof. We can stick gajillion rules into a programming language or we can stick gajillion rules into a database or a combination of both. Databases are easier to sift in my opinion when you got lots and lots of stuff. I don't know about you, but for me its easier to sift, search, and print reports of bunches and bunches of rules if they are in a database instead of a text language. (The text language may be needed for some algorithms, but cataloging their existence and perhaps dispatching info can still be in the DB.) That is me. Your brain may appear smaller or bigger in the rear-view mirror. --top * {Hmmm... It seems Top doesn't really comprehend the relevant distinction between TypeSystem and language. Will Top build rules in his database as a TypeSystemThroughComments?} * [Top, here's a thing to try: Take a non-trivial application you've developed, and re-examine it to see if there are areas where you can use the database more. Endeavour to reduce the amount of "text language" content to its absolute minimum, even if it makes the program less efficient or less readable. The goal, here, is to reduce the amount of "text language" to the least it can possibly be. Then, examine '''all''' the remaining "text language", whether it is in the database or in external application source files. What characteristics of the database model, the database language and the "text language" make it impossible to represent these in the database? What interesting characteristics and/or commonalities do you note about the remaining "text language"? In what ways could you change the database model, the database language, or the "text language" to represent more, or all, of the "text language" constructs in the database without any "text language"? At what point does representing an application entirely in the database become unreasonable? Why? Imagine that there exists a database system where general-purpose programs can be represented entirely in a database without "text language". In terms of readability, maintainability, grokkability, consistency, data integrity, and any other criteria you see fit (especially those relevant in your usual domain), compare and contrast this representation with an equivalent representation described purely by a "text language", and that described partially by a "text language" and partially by a database. What is the ideal mix of "text language" and database representation? Why?] * I've discussed this a bit somewhere around here already, but forget where. If one "goes all the way" with tablizing an app, it basically reinvents a language interpreter. If not for efficiency and standardization, this wouldn't necessarily be a bad thing (related: AdvantagesOfExposingRunTimeEngine). If we tilt the lever slightly away from pure-DB and a bit more toward text-language-only, say about 65% of the way toward the table, we get a "domain-specific language interpreter". The sample app I did for PayrollExample is basically just this very thing. ExpertSystems of the 80's style were kind of this also. As far as what is "convenient" in a tablized format versus text code, it is probably subjective. My personal feeling/preference is that Boolean and mathy expressions, and nitty-gritty IF statements without a large-scale pattern are often easier to work with as text code instead of tablized rules. To me its clear that bunches of rules for columns (validation, base "types", ranges, descriptions, reg-ex's, etc.) belong in some kind of DataDictionary instead of text tags. But some like such info as text for whatever reason that escapes me. Some tables only allow digits in text "code" fields, but it is still stored as text. Is this a "type" integer that is quoted in SQL, or something else? Why hard-tree such distinctions? What is allowed and whether the SQL gets quotes around the item or not are somewhat unrelated. (Remember, an app developer does not and perhaps should not care whether the underlying DB uses Floats, Integer, etc. They only want to know what to send to it. That is vendor-specific stuff.) * [That's a good start. Think about it more, work on the questions you missed, and try going "all the way", so to speak. Better yet, implement your ideal DBMS and associated language(s). It's fun, interesting, and you'll learn a lot. You might even create something you can sell, and at the very least you'll have a working model to demonstrate and test your ideas.] {In any case, 'by-tens' and 'decimal place quantity' aren't characteristics of numbers, but rather of the ''representation'' of numbers.} Since anything we model in the computer is merely a representation, such should go without saying. {Incorrect. Everything we model must be represented, but we don't model only representations.} ---- Compare with ProofAnnotationsForBubbleSort ! ---- MayZeroEight CategoryLanguageTyping, CategoryTypingDebate