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 549105
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by RareBreed
by satsujinka on Thu 17th Jan 2013 01:04 UTC in reply to "RE[6]: Comment by RareBreed"
satsujinka
Member since:
2010-03-11

Of course it is a generalization, however, it's a perfectly valid one. There are very concrete reasons to prefer strong typing to weak typing in nearly all cases.

If anything, complex models dictate strong typing. If simply to give you appropriate guarantees and sign posts for navigating the model. It's simple models in which adhering to rules isn't so important. For example, your cat is a simple model having just 4 properties to vary on (plus animal type, if we're dealing with other animals.)

A strongly typed language is a strongly typed language, no matter when the enforcement occurs. Static types merely help catch violations sooner, but you're still not allowed to violate the system if we check later.

Reply Parent Score: 2

RE[8]: Comment by RareBreed
by ndrw on Thu 17th Jan 2013 02:15 in reply to "RE[7]: Comment by RareBreed"
ndrw Member since:
2009-06-30

No generalizations are valid. Especially when there are whole groups of people thinking otherwise (here: for very concrete reasons prefer weak typing to strong typing in nearly all cases).

Strong typing works extremely well with abstract single-function objects (a number, a string, a list, a set) and fails *badly* at any attempt of modeling real objects. In a way, you have admitted that yourself - a "cat" from my example would be an "Object" type, distinguished only by its fields, not the type.

Strong typing implies enforcement, otherwise it wouldn't be "strong". Preferably at compile time, and at least at runtime, although many advocates of strong typing would disagree with that. The problem with your example is that Python doesn't even enforce types at runtime - a "type" (class) is just a method of reusing implementation. At runtime the interpreter is only interested whether the field/method you're accessing is defined or not - something that may and does change at any the time.

Reply Parent Score: 2

RE[9]: Comment by RareBreed
by kwan_e on Thu 17th Jan 2013 02:50 in reply to "RE[8]: Comment by RareBreed"
kwan_e Member since:
2007-02-18

No generalizations are valid.


I see what you did there.

Reply Parent Score: 2

RE[9]: Comment by RareBreed
by satsujinka on Thu 17th Jan 2013 02:56 in reply to "RE[8]: Comment by RareBreed"
satsujinka Member since:
2010-03-11

Your cat example was simple, so it deserves a simple implementation. If you'd wanted me to model the complete biological workings of a cat; that'd be an example of a complex model that would very much have components that differ in type. And I'd almost certainly want them to be strongly typed; no using a lung as a leg!

All current development models fail horribly at modeling the real world. Weak typing gives you no leverage here. Dynamic typing gives you no leverage. Structured, functional, or object oriented paradigms give you no leverage. The world is a messy graph that you can't simplify into something nice and neat.

Python is a strong language. There isn't any debate about this. It's simply a fact.

Reply Parent Score: 2

RE[8]: Comment by RareBreed
by kwan_e on Thu 17th Jan 2013 03:07 in reply to "RE[7]: Comment by RareBreed"
kwan_e Member since:
2007-02-18

If anything, complex models dictate strong typing.


If we go meta and take a look at this whole conversation (which has gone on since the invention of those terms...

The fact that you can categorize something as strong or weak typing, but differentiate it from compile-time or run-time typing, and differentiate it from static and dynamic typing, and the conflation with OO, says something about the inherent flaws of any kind of language typing.

Really the conversation should be about:

Strong, compile-time, static typing vs
Strong, compile-time, dynamic typing vs
Strong, run-time, static typing vs
Strong, run-time, dynamic typing vs
Weak, compile-time, static typing vs
Weak, compile-time, dynamic typing vs
Weak, run-time, static typing vs
Weak, run-time, dynamic typing.

Reply Parent Score: 2

RE[9]: Comment by RareBreed
by satsujinka on Thu 17th Jan 2013 05:22 in reply to "RE[8]: Comment by RareBreed"
satsujinka Member since:
2010-03-11

Sadly, that's not even a comprehensive listing of possible type systems...

Of course, Gödel's incompleteness theorems apply to type systems. So any type system is going to be incomplete or inconsistent. Generally speaking, the most extreme strong type system is going to be incomplete and a very weak type system (say that has no types) is going to be inconsistent. Compile/runtime follows the same sort of pattern (in that compile time checked systems will filter out some "valid" programs and runtime checked systems will have some inconsistent programs [corner cases where there's no way to figure out how to operate on what we have].)

Static and dynamic are the outliers here. Instead of being a characteristic of the expressiveness of a type system, static/dynamic is more about the actual expression of the types. They're more akin to SVO vs SOV vs VSO vs ... sentence structures then they are to choices in strong/weak or compile/runtime.*

*Dynamic languages are often conflated with runtime type checking, but this is technically unnecessary. Runtime checking is easier than compile time for dynamic languages (due to names/variables having no defined type,) but (for example) many lisp compilers have done compile time type checking en route to optimization.

Reply Parent Score: 2