2016-08-27 21:30 GMT-07:00 Steve D'Aprano <steve+pyt...@pearwood.info>:
> On Sun, 28 Aug 2016 12:31 pm, Juan Pablo Romero Méndez wrote: > > > 2016-08-14 7:29 GMT-07:00 Steven D'Aprano <steve+pyt...@pearwood.info>: > > > >> On Thu, 11 Aug 2016 06:33 am, Juan Pablo Romero Méndez wrote: > >> > >> > I've been trying to find (without success so far) an example of a > >> > situation where the dynamic features of a language like Python > provides > >> > a clear advantage over languages with more than one type. > >> > >> Python has more than one type. Don't confuse dynamic typing with weak > >> typing or untyped (typeless) languages. More on this below. > >> > > > > > > Sorry I was not clear, I was thinking in something along these lines: > > > > > https://existentialtype.wordpress.com/2011/03/19/ > dynamic-languages-are-static-languages/ > > > > (Warning: his pov is very different from yours) > > It is a great example of somebody suffering from the problem that when the > only tool he has is a hammer, everything looks like an nail. > > He clearly is immersed in the world of formal type systems and understands > their power. But now he sees everything from that single perspective. > > Now it is true that speaking in full generality, classes and types refer to > different things. Or to be perhaps more accurate, *subclassing* and > *subtyping* are different things: > > http://c2.com/cgi/wiki?SubTypingAndSubClassing > > Many languages treat them the same, but fundamentally they are different. > Oh, I don't think he is thinking in terms of OO "classes", I think he meant two different "kinds" or "varieties" of values (although kind has a technical meaning) In TypeScript terms what he is saying can be described like this: type Complex = { real: number, i: number } | { r: number, φ: number} const c1: Complex = { real: 1, i: 1 } const c2: Complex = { r: 1, φ: 0.5 } You have two values of the same type but different representation. > > (Note: for veteran Python programmers who remember the language before > types > and classes where unified in version 2.2, this is not the same thing! Prior > to 2.2, both "types" and "classes" related to *subclassing*, albeit in a > negative way for the built-in types: they couldn't be subclassed.) > > But the author of this piece ignores that standard distinction and invents > his own non-standard one: to him, classes are merely different > representations of the same data. E.g. his example of complex numbers, > shown as Cartesian (x, y) values or polar (r, θ) values. These aren't two > different "kinds of things", but merely two different ways of representing > the same entity. > > That's not a good way to think about (say) Python lists and Python bools. > Lists and bools are in no way the same kind of entity (except in the most > general category of "they're both objects"). > > It's not even a very good way of thinking about complex numbers. > > Viewed from his perspective of type systems, the author makes what I call > the food processor error. Food processors, blenders and other similar > kitchen appliances are often advertised as having "five speeds", or ten > speeds, or however many the machine is capable of, usually labelled > as "chop", "dice", "whip", "puree", etc. And, far too often: "OFF". > > Since when is "off" a speed? If a blender that is turned off counts as a > blending speed, then a simple bowl is a "one speed blender". You put food > in the bowl, and it doesn't blend at all. That counts as "off" speed. > > The author is making the same mistake. He thinks that a language which > lacks > static typing counts as static typing. "Off" is a speed! "Bald" is a hair > colour! "Raw" is a way of cooking food! > > In truth though, static and dynamic typing are very different. The author > is > fooled because you can emulate *one* part of dynamic typing in a statically > typed system by adding one extra type, "Any", or "Duck Type", or whatever > you want to call it. The static checker can then ignore anything declared > as Any type. > > But deferring type checks to runtime is only part of dynamic typing. The > other fundamental difference is: > > - statically typed languages associate types to variables; > - dynamically typed languages associate types to values. > > This difference is more significant than the "run-time/compile-time" and > its > one which often confuses people. That's not surprising: if I say "x is an > int", that's ambiguous whether I'm referring to the variable x or the value > currently assigned to x. If you don't see the ambiguity, then you're seeing > it purely from the perspective of either static or dynamic typing. > > In static typing, I somehow associate the name "x" with a tag that > says "this may only be used with ints". Perhaps I have to declare it first, > like in C or Pascal, or perhaps the compiler can infer the type, like in > Haskell, but either way, "x" is now forever tagged as an int, so that the > compiler can flag errors like: > > x = 1 > # ... code can run here > x.upper() > > The compiler knows that ints don't have a method "upper" and can flag this > as an error. In such static languages, it is invariably an error to try to > change the type of the variable (unless it has been tagged as "Anything" > or "Duck Typed"). > > x = 1 > x = "hello" # a type error, at compile time > > > But in dynamic typing, the type information isn't associated with the > name "x", but with the value 1 currently assigned to it. Change the > assignment, and the type changes. As a consequence, it is necessary to move > the type checks from compile time to runtime, but that's not the > fundamental difference between the two. > > As further evidence that the author has missed the forest for all the > trees, > consider languages which actually do have only a single type: > > - in assembly language, everything is just bytes or words; > > - in Forth, similarly, everything is just a 16-bit or 32-bit word; > > - in Hypertalk, every value is stored internally as a string; > > to say nothing of more esoteric languages like Oook, Whitespace and > BrainF*ck. > > > TL;DR: > > The author of that blog post ignores actual untyped languages, misses the > distinction between type information being associated with variables or > values, and invents his own idiosyncratic distinction between types and > classes while ignoring the standard one. > > > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
