|
|
Re: Strong versus Weak Typing
|
Posted: Feb 12, 2003 8:35 AM
|
|
> So i think arguing that week-typed languages are more
> "productive" languages that strong-typed ones just
> because they require less typing is a word of
> non-sense, IMO.
Python, Perl, Ruby, and similar languages save on finger typing in other ways, by having built-in collections, regular expressions, function objects, etc. Dynamic typing is a cornerstone of the approach, though.
> [...] here i second all those strong-typed evangelist
> when they say : the more errors you find earlier, that
> is during compile time, the better it is! It may
> require the compiler to do much extra work of type
> checkin ... but i simply don't care, if it produces
> fast-running byte-code.
Here's how dynamic-typing evangelists handle those concerns, and offer advantages besides:
- Unit Testing: Aggressive testing, especially unit testing, to verify inputs and outputs, catches as many or more bugs as static types.
- Higher-level types: often you don't *need* to write a new class, because existing classes and/or language mechanisms do the job simply and concisely. Perhaps it's a matter of the type of problems "system" and "scripting" languages address.
- Efficient Enough: it isn't necessary in many cases for a program to be lightning fast, as long as it's efficient enough for its purpose. GUI rendering has to be fast, but code that performs actions based on GUI events can take a second or so without a user noticing.
- "Duck Typing": See <http://c2.com/cgi/wiki?DuckTyping>. One of the frustrations of static typing is to have two classes from two different sources that have similar interfaces but inherit from no common types. For example, Java 1.4 added a CharSequence interface; before that, the only way to write a library that operated on Strings, StringBuffers, and char arrays was either to pass them as Object (as the GNU regex library does), overload and reimplement methods for all known types (as I think ORO does), or to create an adaptor (as Apache Regex does). On the other hand, a Python or Ruby object doesn't have to inherit from X; it merely has to implement enough of X's methods (ideally all) in order to be X-like enough to be sustitutable, in the Liskov sense.
- Ease of Refactoring: Because of Duck Typing, changing the type of an argument or a return value from a simple type to a more complex one is a lot easier in a dynamically-typed language. In a statically-typed language, you have to change all code that uses that type, if it and the old type don't share an interface, or if the usage declared the concrete type. You'd also have to change the type of any variable or collection that held the argument or return value without using it directly.
Dynamic typing isn't right for every task, by any means. However, it can build complex systems in some domains, as Zope proves. I think they're especially useful in web development because the Web is all about loose coupling, self-describing data, and converting structured text into internal data structures and back.
|
|
Previous Topic
