Dr. Bertrand Meyer founded and remains chief technical officer of ISE, a software company now in its sixteenth year. He participated in creating the definition of the Z specification language. He authored Object-Oriented Software Construction, often cited as the best book on object-oriented analysis and design. He invented the Business Object Notation (BON), a leading methodology for system design. He is perhaps best known for his Eiffel programming language and the related concept of "Design by Contract" that he effectively diffused.

This week. Dr. Meyer, will be answering questions in ITworld.com's Interviews Forum. Here's an excerpt from the interview in progress:

Q. When he spoke in ITworld.com's interview forum, Robert Martin expressed the opinion that dynamically (though strongly) typed languages like Python and Smalltalk would be the mainstream languages of the future, rather than languages like C++ and Java. To what extent do you share that opinion?

What is your take on the school of thought that claims that more bugs can be caught through using a good dynamically typed language and unit testing than through static typing? The argument is that, if you are using a dynamically (but strongly) typed, higher-level language, you'll typically need to write less code. This reduction in the size of the codebase decreases the incidence of errors in the first place (the more code, the more errors) and makes it easier to see flaws in logic (which are often the errors hardest to find and least likely to be trapped by a statically typed compiler anyway). The shorter coding time also allows for more time for testing and thinking.

A. The idea that testing is better than type checking doesn't match my experience. The general observation, which you will find strongly backed in the software engineering literature, is that it is not just better to find errors early: it is much better. The ratio of the cost of correcting an error found late over correcting it early may run into the hundreds or more. Testing comes late; compiling comes early.

I agree with the general observation that shorter code is better. Concision is a great virtue. But the way to make code significantly shorter is not to cut on typing (in either sense of the word). It's to use breakthrough changes in algorithms and data structures; a typical example is the move to a table-driven scheme from one that has everything programmed in the code. That's the kind of brevity that pays, not the APL or "Obfuscated C" style of minimizing the number of keystrokes. (I am constantly amazed at people who give variables, or even exported features in libraries, names like BtnClick. What possibly can the purpose be of saving a u, a t, and an o?)

Adding type information doesn't take much extra time, or result in much extra code. The benefit is not just reliability (in any project that I have seen, finding just one bug through type checks is worth all the supposed effort of adding type information, many times over); it's also readability and, hence, ease of maintenance, reuse, and modification. Type declarations make the text so much more clear.

Untyped or dynamically typed languages are OK for throwaway code, although in my experience with developing such code I have every single time wished in retrospect (even when I was initially happy with an untyped approach) that I had the benefit of static typing. For any significant development whose results are meant to stay around, I don't see why anyone would want to renounce the benefits of typing.

I think there may be some misunderstandings in this area because of traditional technology limitations:

• First, static typing may evoke the idea of a long edit-compile-execute cycle. But that's not necessarily the case. You can have a very incremental and extremely fast recompilation cycle with full type checking.

• Second, effective static typing requires an appropriate type system. If the type system is too restrictive and prevents you from expressing what you need -- or, conversely, if it is too lax and doesn't protect you (e.g., if you still have pointer arithmetic and the like) -- then static typing ceases to be such an attractive proposition. But this objection goes away with a well-designed type system.

In both cases, Eiffel has made sure to address the issue. The Melting Ice Technology of ISE Eiffel takes care of fast incremental compilation. The presence in the type system of mechanisms like constrained genericity, multiple inheritance, and assignment attempt ensures that the type system is flexible enough for many needs that have traditionally been used by advocates of dynamically typed approaches.

Click here to join the interview in progress!

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine