Loose Types Suck

A language without a proper type system (allows too many) lies, outright. Truth non be told.

Now that is completely untrue. One cannot lie while keeping mum. A language without a type system cannot lie about types.

A person with no manners can lie about having manners.

They may try, mouth too full canna' enunciate or lie.

And they kick puppies also.

I did not do that on purpose. I had a tag that said I kick puppies in some cases by mistake. You just didn't check my pockets for the tag that I carry (which sometimes is erased since it is in pencil and replaced with other tag notices that no one really reads often).

It is arguable whether or not wimpy languages have a real type system.. so lets call them loose types instead of no types although jokingly a loose type is such a lie causer that it can be considered virtually no type system. Type systems involve declarations by a human and I barely buy the fact that dynamic languages are proper type systems.. for example why not declare that your variable is dynamic when you need one while using a stricter type by default, if we really want safety? The answer is because websites and software are meant to break. Bugs are a good thing. Just write more unit tests to catch them.. even though type systems offer automated partial unit tests so you can focus on other things instead.

Do not talk to PHP, he will lie to you through his teeth. I've known PHP for a while and I don't trust him. He tells lies all the time and never admits the truth. http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Examples-Of-Strong-Typing-Advantages

Php has a type system. Each variable carries around a hidden "type flag" with it (whether you use it or not). Thus, it does not fall into "no types" category. Perl would be closer.
The usual name is a "type tag". "Type flag" exists only in one contributor's personal vocabulary. In many languages with DynamicallyTyped variables -- e.g., both PHP and Perl, so Perl is not "closer" -- it's not variables that carry type tags, it's values that carry type tags. In many languages, and in particular those that are StaticallyTyped, type information is only manipulated at compile-time; at execution time, machine operations are performed on values without associated type information, because during compilation the type system and code generator have pre-ensured that there is a TypeSafe correspondence between the machine operations and the values they manipulate.
- Type tags are unknown by the human because he didn't declare them.. well with time type tags on the values can be learned by the human as he gets used to the gotchyas of the language.. but this is a poor excuse for a type system. It's almost like telling a liar the truth after he's told a lie and giving him little sheets of paper (tags) to put in his pocket when he is lying. Whether people see these sheets that warn he is lying means these people have to dig into his pockets and verify what his lie is and the consequences of it. If people consider this a proper type system then pigs can fly. Let's call it a loose wimpy type system ;-)

Mentioning PHP in this context suggests it is untyped, which is untrue. PHP implements DynamicTyping. In its own way, the PHP type system is predictable and therefore TypeSafe. By contrast, CeeLanguage is WeaklyTyped -- it is possible to subvert the type system (via casts) and cause unpredictable behaviour. AssemblyLanguage has essentially no type system. (But see TypedAssemblyLanguage)

Please see the above article about PHP to see why PHP is not predictable in a real world shopping cart. Saying "No Types" is a humorous exaggeration of a language which doesn't even care that you declare and tell truths about types. Some languages give errors at run times about your lying undeclared types.. which is better, but still allowing you to lie slightly before you run (or walk) the program.

In your shopping cart, PHP behaved 100% predictably. It behaved as it was designed to do when presented with an implicit string-to-numeric conversion and the string contains non-numeric characters. It will always give the same results given the same inputs and conditions. A WeaklyTyped system is one where the use of an incorrect type results in a core dump, corrupted memory, lockup, or other behaviour that can't be predicted by man or machine -- at least, not without unusual and detailed knowledge of the environment upon which the system runs, such as processor state and the contents of system RAM at the point of failure.

[Actually, WeaklyTyped systems can (and, for deterministic systems, usually do) fail or succeed predictably - in manners predictable by both man and machine. Whether the failure is 'catastrophic' can also be controlled, based on the exception handling mechanisms of the language. 'WeaklyTyped' only means that the language + TypeSystem makes no guarantee of TypeSafety even upon passing a program. Now, there are two ways this can happen: (a) The TypeSystem itself is unsound (which is defined as a TypeSystem that doesn't provide TypeSafety), or (b) the Language provides mechanisms of dodging the TypeSystem (e.g. statements of 'assumption', such as reinterpret & static void* casts, or even as something as simple as assuming that a pointer always points to a valid memory location). Both can hold true simultaneously, of course.]
True. I was specifically thinking of the behaviour of CeeLanguage. I should have written "CeeLanguage is a WeaklyTyped system where the use of an incorrect type ... etc."

But most PHP programmers do not know of this behavior since he was never taught it through the type system, it is just a guessing game or random luck that he has found a manual page that states this behavior exists, if those manual pages are even written yet. It's like saying that a kid is not lying if he eats a candy apple and tells his parents he did not have an apple. After all, he had a candy apple, not an apple. It depends on your definition of lying and WhatIsaType?.

No, it depends on your expectations of DynamicallyTyped scripting languages like PHP, particularly when you employ implicit typecasting to convert user-entered strings to numeric values. What did you expect to happen when a user entered a bogus or unusually-formatted price, as will inevitably happen? Scripting languages like PHP often fool beginners into thinking they're "safe" because they're simple and easy to learn, but for generating production code they're actually dangerously-sharp cutting tools that may save an experienced developer some time and effort, but can easily injure careless, naive, and inexperienced programmers. In short, why weren't you sanitising and checking all user input?

Because we are humans. I do sanitize and check input, but some things slip. If something slips, it is better to be warned with "this can't be converted to an integer" than it is for the type to become some random thing that PHP decides it to be. A type system wouldn't allow a comma inside an integer. In PHP we have no way of knowing whether or not we intended it to be an integer... so PHP says ok so this isn't an integer even though we intended it to be an integer, hence LooseTypesSuck. If there are ways to save humans time, and we are doing high level programming.. why go back to coding in assembly?

Not that I'm defining PHP in particular, by the way... There's plenty not to like about it, but this particular kvetch isn't it.

Casting is also the start of a lie, but sometimes lying is needed.

Huh?

Casting is a way to partially escape the type system, hence it is the start of a lie. Sometimes casts are extremely dangerous since you are telling the program (and yourself, on paper) that this(isNotThis).

However, it can also be powerful.. and assembly (lying) is even sometimes required to get the ball rolling - such as operating systems which sometimes require a bit of assembly.

So... Assembly language is "lying", and "lying" is also your synonym for unchecked type conversion? Hmmm...

Eventually one will have to deal with the CPU. Types exist exactly for the reason that we are not programming in assembly. Whether a string or an integer is a string or an integer in PHP is not clear to the human when reading code. hence LooseTypesSuck. The computer may convert them to its form of types when it interprets it, but types are for humans.. not computers. The computer doesn't know of what a type is, only they are really useful for humans. It can be argued that a "bit" is a type so all languages have a type system since they all deal with bits. More importantly, types are for humans and they give humans warnings. When no warning is given if I utilize a string as a numerical value which contains commas, this is not a type system. It is a no type system that just doesn't give a rats.

NoTypeCheckingLies? is similar to WeakTypesLie and TypeSystemThroughComments.

I will write a language with no types, because all variables are boolean, i.e. one bit. No arrays, that's cheating. What should I name it?

CellularAutomaton

Maybe SwitchLanguage?? or BitBanger?

Consider also the BrainFuck language. no, cells in BrainfuckLanguage aren't boolean, and the name is already taken.

Several EsotericProgrammingLanguages like this exist. For example, http://esolangs.org/wiki/BitChanger and http://esolangs.org/wiki/BitFlip and http://esolangs.org/wiki/Bitwise_Cyclic_Tag. http://esolangs.org/wiki/Boolfuck and http://esolangs.org/wiki/Smallfuck have even been shown to be TuringComplete! See also the functional programming languages IotaAndJot, which use bits differently.

Bad Language Versus Bad Concept

Loose typing can make a language compact, easy-to-read, and flexible if "done right". PHP and JavaScript did it all wrong in my opinion, relying excessively on type flags, operator overloading, and zero-based indexing. Thus, please don't extrapolate loose-typing problems from PHP to everything. Dynamic typing done right in both the language design and app coding is like well-written, compact poetry. -top

[What does zero-based indexing have to do with strong and weak typing? Additionally, why would it be a problem, especially considering how rare actually indexing arrays can be when you have foreach loops, maps, filters, and so on? PHP doesn't support operator overloading; JS does but minimally (I believe it only ever applies to the + operator, and even then only for either numeric addition or string concatenation). What particular problems of these languages did you actually have in mind? I'd suggest that the oft-unpredictable (and in PHP's case non-commutative) weak equality operator == would be one major culprit worth noting. -DavidMcLean?]

One cannot lie while keeping mum. Yes one can, it's called a lie by omission.

MarchZeroEight

CategoryLanguageTyping, CategoryTypingDebate