(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Friday, August 18, 2006
Dynamic is the opposite of Static, not of Explicit
I recently read a post where the author said he does not care for Ruby's dynamic typing.
When people start talking about types in programming languages, the terms fly around in a rather fast and loose manner. Here's a rather extensive and balanced discussion: the article on Type Systems in Wikipedia.
Notice that Ruby is dynamically typed (it's types are determined at run time and can change at run time), strongly typed (it does not allow an operation to succeed on arguments which have the wrong type), and type-safe (it does not allow operations or conversions which lead to erronous conditions).
(There's another school of thought about how to name the properties of type systems. More on that at the bottom.)
Proponents of explicit types may say that Ruby is not type safe because it is possible to compile programs that contain errors which will not be detected until the program is run and the erroneous condition is detected.
Statically typed languages such as C# can detect a class of such errors at compile time. Some Ruby enthusiasts argue that they do not like the boilerplate associated with explicit typing and feel that the extra error checking does not outweigh the additional overhead.
Both arguments are mistaken. Sorry about that. If Explicit and Implicit were the issues, we could add Type Inference to Ruby and it would have the low overhead of implicit types as well as some extra error-checking (work on Soft Typing for languages like Scheme and Erlang aims to provide compile-time checking for implicitly typed languages). However, type inference is a feature of statically typed languages.
The trouble is that Ruby is dynamically typed. Specifically, Ruby contains extensive dynamic meta-programming constructs. Type inference works with statically typed languages. The compiler must be able to infer the type or set of types possible for any variable.
Consider a Ruby application that modifies classes and objects at run time. The simplest example is Ruby's built-in accessor methods: attr_accessor :foo is a class method that actually creates two instance methods at run time, foo and foo=. What happens when attr_accessor is called with a variable as its argument, like attr_accessor my_attribute?
If the type inference engine later looks at a call such as bar.blitz = 'bash', how does it know whether attribute_accessor was ever called with 'blitz' or :blitz as an argument? Dynamic meta-programming makes the type inference problem undecidable.
A lucid argument is that Ruby's dynamic typing makes it difficult to detect type errors statically. The correct counter-argument is that Ruby's style of dynamic typing makes it possible to use dynamic meta-programming, such as Ruby on Rails' ActiveRecord, not that Ruby's implicit typing is more productive.
Once you've made these arguments, you can decide for yourself whether the benefits of dynamic meta-programming do or do not outweigh the advantages of static type checking.
(Updated to use the expression "dynamic meta-programming" to distinguish features like define_method from static meta-programming features like macro systems, courtesy of the well-informed Lambda the Ultimate).
p.s. Ward's Wiki seems to use the term static typing to mean the same thing as explicit and strong typing. I prefer that the term static means that it doesn't change. The same wiki seems to use the term dynamic typing to mean the same thing as implicit and strong typing. It includes the possibility that a program is what I would call strongly, statically and implicitly typed: the checking is done at run time but the types of variables never change. The commentary suggests the phrase semantic dynamic typing for the quality of dynamic typing that encompasses dynamic meta-programming. If you like these terms, please substitute "semantic dynamic typing" for "dynamic typing" above.
p.p.s. And there's another argument that dynamic meta-programming, like macros, should be considered harmful. I'm saving my reply for a rainy day.
I recently read a post where the author said he does not care for Ruby's dynamic typing.
When people start talking about types in programming languages, the terms fly around in a rather fast and loose manner. Here's a rather extensive and balanced discussion: the article on Type Systems in Wikipedia.
Notice that Ruby is dynamically typed (it's types are determined at run time and can change at run time), strongly typed (it does not allow an operation to succeed on arguments which have the wrong type), and type-safe (it does not allow operations or conversions which lead to erronous conditions).
(There's another school of thought about how to name the properties of type systems. More on that at the bottom.)
Proponents of explicit types may say that Ruby is not type safe because it is possible to compile programs that contain errors which will not be detected until the program is run and the erroneous condition is detected.
Statically typed languages such as C# can detect a class of such errors at compile time. Some Ruby enthusiasts argue that they do not like the boilerplate associated with explicit typing and feel that the extra error checking does not outweigh the additional overhead.
Both arguments are mistaken. Sorry about that. If Explicit and Implicit were the issues, we could add Type Inference to Ruby and it would have the low overhead of implicit types as well as some extra error-checking (work on Soft Typing for languages like Scheme and Erlang aims to provide compile-time checking for implicitly typed languages). However, type inference is a feature of statically typed languages.
The trouble is that Ruby is dynamically typed. Specifically, Ruby contains extensive dynamic meta-programming constructs. Type inference works with statically typed languages. The compiler must be able to infer the type or set of types possible for any variable.
Consider a Ruby application that modifies classes and objects at run time. The simplest example is Ruby's built-in accessor methods: attr_accessor :foo is a class method that actually creates two instance methods at run time, foo and foo=. What happens when attr_accessor is called with a variable as its argument, like attr_accessor my_attribute?
If the type inference engine later looks at a call such as bar.blitz = 'bash', how does it know whether attribute_accessor was ever called with 'blitz' or :blitz as an argument? Dynamic meta-programming makes the type inference problem undecidable.
A lucid argument is that Ruby's dynamic typing makes it difficult to detect type errors statically. The correct counter-argument is that Ruby's style of dynamic typing makes it possible to use dynamic meta-programming, such as Ruby on Rails' ActiveRecord, not that Ruby's implicit typing is more productive.
Once you've made these arguments, you can decide for yourself whether the benefits of dynamic meta-programming do or do not outweigh the advantages of static type checking.
(Updated to use the expression "dynamic meta-programming" to distinguish features like define_method from static meta-programming features like macro systems, courtesy of the well-informed Lambda the Ultimate).
fin
p.s. Ward's Wiki seems to use the term static typing to mean the same thing as explicit and strong typing. I prefer that the term static means that it doesn't change. The same wiki seems to use the term dynamic typing to mean the same thing as implicit and strong typing. It includes the possibility that a program is what I would call strongly, statically and implicitly typed: the checking is done at run time but the types of variables never change. The commentary suggests the phrase semantic dynamic typing for the quality of dynamic typing that encompasses dynamic meta-programming. If you like these terms, please substitute "semantic dynamic typing" for "dynamic typing" above.
p.p.s. And there's another argument that dynamic meta-programming, like macros, should be considered harmful. I'm saving my reply for a rainy day.
Comments on “Dynamic is the opposite of Static, not of Explicit”:
<< Home
Any language can have a type inferencer applied to it. In some cases what you'd like to have happen is the infrencer determines a set of possible types, and the assigned type becomes a "variant record" where the actual type in any instance of one of the variants.
This doesn't help all type checking at compile time, but it can at least point out the "dangerous" cases without giving up entirely. This can also be used for code generation... the code generator can choose whether to produce the most general code, or to produce multiple paths of code for two or more of the variants, e.g. "if this instance is an integer then follow the code path for integers, otherwise follow the code path for the general case."
This doesn't help all type checking at compile time, but it can at least point out the "dangerous" cases without giving up entirely. This can also be used for code generation... the code generator can choose whether to produce the most general code, or to produce multiple paths of code for two or more of the variants, e.g. "if this instance is an integer then follow the code path for integers, otherwise follow the code path for the general case."
the infrencer determines a set of possible types, and the assigned type becomes a "variant record" where the actual type in any instance of one of the variants.
Yes, this is how Hindley-Milner deals with polymorphism. That being said, I do not see the obvious application of this technique to Ruby's define_method method.
I am opne minedd, however. I would love a language that lets me have my cake and eat it too!
Yes, this is how Hindley-Milner deals with polymorphism. That being said, I do not see the obvious application of this technique to Ruby's define_method method.
I am opne minedd, however. I would love a language that lets me have my cake and eat it too!
Finally, a sensical argument. While the vernacular of terms describing programming languages is probably doomed to ambiguity, there still is serious discussion to be had.
This hits home to a point I've been trying to make: You can't have em all. For some situations, static, explicit code is the nicest most maintainable solution. In other situations, the associated boilerplate is needlessly verbose and actually gets in the way of a clean solution.
For an encore: Is there a middle, all-encompassing ground? A hypothetical programming language that is as explicit as you want it to be with no unfortunate limiting side-effects?
I don't think that holy grail exists. Simply allowing explicit types, or not, as a choice, results in such a mix and match language that someone well-versed in code probably won't understand code in the same language written by someone with a different style. That's no good.
This hits home to a point I've been trying to make: You can't have em all. For some situations, static, explicit code is the nicest most maintainable solution. In other situations, the associated boilerplate is needlessly verbose and actually gets in the way of a clean solution.
For an encore: Is there a middle, all-encompassing ground? A hypothetical programming language that is as explicit as you want it to be with no unfortunate limiting side-effects?
I don't think that holy grail exists. Simply allowing explicit types, or not, as a choice, results in such a mix and match language that someone well-versed in code probably won't understand code in the same language written by someone with a different style. That's no good.
Here's something to blur the lines -- MetaOCaml (http://www.metaocaml.org/) and other multi-stage thingies.
I'm puzzled by trust in type inference that many people who usually code in systems without it have.
Type inference works only with type systems too simple for the real world. Even the most advanced type inference systems like OCaml's (which is already provably *undecidable*, you can hang type inference engine with a 3-line expression) require a lot of type annotations and typecasts in real programs.
No matter how smart your type inference engine is, you couldn't type-infer even Java code (even without reflection). Mentioning type inference and Ruby in a single sentence is really weird.
Type inference works only with type systems too simple for the real world. Even the most advanced type inference systems like OCaml's (which is already provably *undecidable*, you can hang type inference engine with a 3-line expression) require a lot of type annotations and typecasts in real programs.
No matter how smart your type inference engine is, you couldn't type-infer even Java code (even without reflection). Mentioning type inference and Ruby in a single sentence is really weird.
<< Home
