Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] OT: Static/dynamic typing
 Bill de hÓra wrote: > >... > > I don't for a moment dispute the usefulness of types, just /static/ > typing. Static typing as aid to programmer effectiveness is something of > a myth, tho' it's very handy if you're a compiler or a runtime. Systems > do get build with dynamically typed languages and seem to work fine; > notably these languages are notoriously productive. When I am creating new code, dynamic type checking almost always allows me to be more productive than static type checking. As Jonathan says, when you are changing or refactoring code, static type checking can more often catch your mistakes. Since maintenance lasts longer than initial development this would seem like a clear win for static type-checking except that it can often bloat and complicate the code and thus provide more opportunities for bugs to creep in. Here's what Robert C. Martin has to say: """ As an industry we became enamored of type-safety in the early '80s. Many of us had been badly burned by C or other type-unsafe languages. When type-safe languages like C++, Pascal, and Ada came to the fore, we found that whole classes of errors were eliminated by the compiler. This safety came at a price. Every variable had to be declared before it was used. Every usage had to be consistent with its declaration. In essence, a kind of "dual-entry bookkeeping" was established for languages. If you wanted to use a variable (first entry) you had to declare it (second entry). This double checking gave the compiler vast power to detect inconsistency and error on the part of the programmer, but at the cost of the double entries, and of making sure that the compiler had access to the declarations. With the advent of agile processes like extreme programming (XP), we have come to find that unit testing is far more important than we had at first expected. In XP, we write unit tests for absolutely everything. Indeed, we write them before we write the production code that passes them. This, too, is a kind of dual-entry bookkeeping. But instead of the two entries being a declaration and a usage, the two entries are a test and the code that makes it pass. Again, this double-checking eliminates lots of errors, including the errors that a type-safe compiler finds. Thus, if we write unit tests in the XP way, we don't need type safety. If we don't need type safety, then its costs become very severe. It is much easier to change a program written in a dynamically typed language than it is to change a program written in a type-safe language. That cost of change becomes a great liability if type safety isn't needed. """ * http://www.itworld.com/AppDev/1262/itw-0314-rcmappdevint/ I think it is pretty well understood that for programming in the small, dynamic type checking wins. I think it will be another five or ten years before we have a clear answer about programming in the large. We need more programmers to move back and forth between the two types of developments, working on very large programs, and report their findings. Current anecdotal evidence goes both ways: some people claim that dynamic type checking helps in the large and others claim it hurts. Paul Prescod 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
