Linked by Thom Holwerda on Mon 14th Jan 2013 23:15 UTC, submitted by MOS6510
General Development "Programming languages are living phenomena: They're born, the lucky ones that don't die in infancy live sometimes long, fruitful lives, and then inevitably enter a period of decline. Unlike real life, the decline can last many, many years as the presence of large legacy codebases means practiced hands must tend the code for decades. The more popular the language once was, the longer this period of decline will be."
Thread beginning with comment 549190
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Comment by RareBreed
by satsujinka on Thu 17th Jan 2013 20:57 UTC in reply to "RE[10]: Comment by RareBreed"
satsujinka
Member since:
2010-03-11

Then why does the second page of what you linked explicitly say it's not weak typing? Why does Wikipedia's page say Python is strongly typed? Why do all of c2's pages on typing say Python is strongly typed?

No, I'm afraid you're wrong. Python is strongly typed. It's just checked at runtime.

How would most type systems fail to classify a cat properly?

data FurType = Short | Long | Medium
data Color = Black | Orange | White | Tabby | ...
data Cat = Cat { hungry :: Bool, fur :: FurType, color :: Color, ... }

mycat = Cat True Short Black ...

It isn't that cat's are hard to design a strong model for. It's that there's no point in doing it because it's irrelevant. The following is just as sufficient for this.

(True,"short","black",...)

Reply Parent Score: 2

RE[12]: Comment by RareBreed
by ndrw on Fri 18th Jan 2013 17:01 in reply to "RE[11]: Comment by RareBreed"
ndrw Member since:
2009-06-30

Then why does the second page of what you linked explicitly say it's not weak typing?


Easy enough to check:
"Weak typing is not really a fair description of what's going on in Python."

Which is fair given that Python uses types for implementation reuse and error reporting. This of course doesn't stop me from adding a method "bark()" to an existing class "cat".

Why does Wikipedia's page say Python is strongly typed?


It also says that Lisp is strongly typed (a language specifically designed for making all non-primitive values untyped). The reason they give is that it doesn't do type coercion, which is IMHO a stupid way of defining "strong typing". But I will accept that, so if you wish, we may end the discussion here.

How would most type systems fail to classify a cat properly?

data FurType = Short | Long | Medium
data Color = Black | Orange | White | Tabby | ...
data Cat = Cat { hungry :: Bool, fur :: FurType, color :: Color, ... }

mycat = Cat True Short Black ...


Interesting (really!). But note that Haskell's type system is definitely not what people would call "most type systems".

And even Haskell can't make a "cat" object sometimes hungry, sometimes not. (True, this goes deeper than the type system in Haskell).

Reply Parent Score: 2

RE[13]: Comment by RareBreed
by satsujinka on Fri 18th Jan 2013 22:38 in reply to "RE[12]: Comment by RareBreed"
satsujinka Member since:
2010-03-11

http://c2.com/cgi/wiki?WeakAndStrongTyping
http://c2.com/cgi/wiki?TypingQuadrant
http://en.wikipedia.org/wiki/Weak_typing

Type coercion is a generally accepted criteria of strong/weak. Not the only one, but it's an easy to use tool.

Strong/Weak: Does the type of a value change? Or, is type checking even done?

Type systems are weak if the answers fall closer to "all the time and never" and type systems are strong if "never and always". Irrespective of when the checking is done. Mind you, this is a gradient. The exact point when a language ceases to be strong and becomes weak is fuzzy (and may effectively change depending on what subset of the language we're talking about.)

IMHO, adding cat.bark() isn't weak, so much as open typing (not sure this is an actual phrase, but I've heard people describe class systems as "open" when you're allowed to add things after definition.) Since it's not really that cat is no longer a Cat, it just got new abilities.

And as you say yourself, Lisp's data abstractions are untyped. But when there are types (e.g. primitives, functions, macros,) pretty much all Lisps use strong typing (some even insert static typing when they can.) In this case, it's sort of a value judgement. Is untyped the same as weakly typed? After all something that is untyped doesn't even have a notion of type to change, but it may have a structure that does get checked (which amounts to type checking.)

Reply Parent Score: 2