1.5 Same- Versus Different-Language Prototyping

1.5 Same- Versus Different-Language Prototyping

The field of prototyping is divided into two main philosophies. These revolve around the argument as to whether a prototype should be written in the same language as the final product ( same-language prototyping ) or a different language ( different-language prototyping ). In same-language prototyping, the advantages seem almost too good to pass up. The development team need only use one language, which implies one set of tools, one set of books, one learning curve, and one set of training. Not surprisingly, same-language prototyping is the more common of the two types.

The final prototype essentially becomes the product. The major disadvantage to this model of development is that during prototyping, the writing of garbage code that lacks any bells /whistles, efficiency, robustness, or extensibility is allowed, if not encouraged. After all, the purpose of prototyping is to test design ideas and requirements' feasibility, not to implement a final product. In this domain, many developers may be tempted to make statements such as, "I know this code lacks any of the above-mentioned features, but this is only the prototype. I'll be back later to rewrite this section of the application." Of course, six months later the project is running behind schedule, "later" never comes, and the garbage code is shipped with the product.

Another issue with same-language prototyping is that language issues may cloud a designer's judgment at a time in system development where software platforms are not supposed to be in the forefront. For example, C++ developers often run into design problems because their language is a multiparadigm language as opposed to a pure object-oriented language (e.g., SmallTalk). A multiparadigm language allows its users to develop easily in both the object-oriented and action-oriented paradigms . A pure object-oriented language coaxes its users to use the object-oriented paradigm. One disadvantage of using a multiparadigm language for object-oriented development is that the developers can easily fall back into a straight action-oriented development process. If a developer is using a pure language, he or she can guarantee the use of object-oriented development constructs. (Note: Do not equate "object-oriented" with "good." Our pure-language developer might be a lousy object-oriented developer and may thus end up with an unmaintainable system, but it will have been built using object-oriented constructs. It should come as no surprise that the object-oriented paradigm will allow its users to build bad systems. No technology will prevent this from happening.)

In different-language prototyping, we can swap the advantages and disadvantages discussed above. The overhead of two learning curves, set of tools, and so on can be prohibitive. Also, convincing your manager, and yourself, that writing 5,000 lines of code and throwing it into the trash can is a good thing. I will be the first to argue that the code was not interesting; it was the intangible design distilled from the code that was useful. However, it is still a psychological difficulty, especially in a corporate environment that still uses the amount of code written as a measure of productivity. The advantage of never " accidentally " shipping garbage code, coupled with being able to work in a pure object-oriented environment regardless of the application's target language, has been enough to win over many companies to this philosophy of prototyping. A typical language combination is SmallTalk for the prototyping and C++ for the target language of the application.