March 14, 2001, 5:27 PM — When Robert Martin talks, programmers listen.
XP! Patterns! UML! Java! C++! OOD! SE! For most of the last 30 years, Martin has worked full time at the center of modern programming practice. His specialties and concerns have been exactly those of the silent majority of professional developers: How do I use STL? Should our team practice extreme programming? Which analysis methodology is effective?
Throughout his career, Bob has been a working programmer himself, informing his "outreach" as an author, editor, publisher, manager, entrepreneur, pundit, and trainer.
Last week, Martin talked to ITworld.com's Cameron Laird and readers in the ITworld.com Interviews forum about the programming languages of the coming decade and other topics. Here's an excerpt:
ITworld.com: Does language make a difference? Your emphasis on code hygiene and expressiveness is welcome. Why, then, do we spend so much time working in C and C++? If an organization comes to you with a coherent set of requirements, and says it's willing to trust you about what language will help it best meet its goals, what advice are you likely to give?
Robert Martin: Language certainly makes a difference; but any language can be written well.
I don't mind C or C++. There are certainly cases where those are the best languages for the job. DSP code, if not written in assembler, is probably best written in C. Hard embedded realtime apps are well done in C++. And many Web apps or MIS/IT apps are nicely done in Java.
However, I think there is a trend in language that will become more and more evident as the decade progresses. I think we are seeing an end to the emphasis on statically typed (type-safe) languages like C++, Java, Eiffel, Pascal, and Ada. These languages force you to declare the types of variables before you can use them.
As this decade progresses I expect to see an ever increasing use of dynamically typed languages, such as Python, Ruby, and even Smalltalk. These languages are often referred to as "scripting languages." I think this is a gross injustice. It is these languages, and languages of their kind, that will be mainstream industrial languages in the coming years.
Why do I think this? Because these languages are much easier to refactor. What's more, they have virtually zero compile time.
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.
But there is another cost: The cost of compilation and deployment. If you want to compile a program in C++, you must give the compiler access to all the declarations it needs. These declarations are typically held in header files. Each header file containing a declaration used by the program must be compiled by the compiler. If you have a program with N modules, then to compile just one of them you may have to read in all N header files. With a little thought you'll realize that this means that compile time goes up with the square of the number of modules.
