johnson@p.cs.uiuc.edu (10/13/89)
I'm a Smalltalk programmer. All Smalltalk programmers are maintenance programmers. That's because we take reuse seriously. The average Smalltalk programmer spends 75% of the time reading code and only 25% of the time writing code. Although this might seem like an unproductive use of time, Smalltalk programmers also have a reputation of being extremely productive, and the two are related. The fastest way to get good code (as all the readers of this news group probably know) is to reuse it. Reusing code requires understanding it. Understanding code requires at least reading the documentation, and sometimes reading the code. Thus, any system that is successful at reuse will make everybody who uses it a maintenance programmer. Ralph Johnson
chittamu@umvlsi.ecs.umass.edu (Satish Kumar .C) (10/16/89)
In article <130200014@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > >Reusing code requires understanding it. Understanding code >requires at least reading the documentation, and sometimes >reading the code. I beg to differ. Reusing code requires understanding the *function* of the code and not the code itself. If you know precisely what the code is supposed to do, then you can reuse it without reading thro' the implementation of it. If reusable code requires us to read thro' its implementation, then in my opinion it is not truely reusable. It defeats the very purpose of having package specification and module interfaces. Reuse is fine. I am strong advocate of it. But not when I have to read thro' the code. The only thing I would necessarily need to read is the documentation describing the purpose of the code. -- -Satish. chittamu@cs.umass.edu
johnson@p.cs.uiuc.edu (10/20/89)
chittamu@umvlsi.ecs.umass.edu begs to differ with my claim that reusing code requires understanding it, which sometimes requires reading it. He says that we should not have to read code, but only need to understand the function of the code. This is an idealist's position. Documentation is almost never good enough. Some people spend most of their time running experiments on libraries trying to figure out what they do. Others junk the libraries. The systems that are most successful for reuse usually make source available, because every so often the users need to look at the code. I know several companies that refuse to buy libraries of components unless they get source. It might not be impossible to make libraries that are completely useable only from the documentation, but it sure is hard. An entirely different line of argument is that there is no difference between programs and program specifications. Either a program specification is complete (it specifies everything of interest about the program) or it is partial. If it is complete, then it is a program. It may be written in a language that we don't know how to compile efficiently, but that is just the inadequacy of our compiler technology. (I *know* about undecideability, and it does not change my position.) If it is partial then there will be things we need to know about the program that is not in the specification. People who must put up with low-level languages can find it hard to see that complete program specifications are just another way of programming. However, I program in Smalltalk at as high a level as possible. The result is that my programs look a lot like the formal program specifications that I have read. Of course, I don't think that Smalltalk is as abstract as it should be, but it is one of the better existing languages for programming at a very high level. Smalltalk has lots of practical problems that can make it inappropriate for commercial use. However, it is possibly the best system for software reuse. In my opinion, everybody who is seriously interested in reusable components should study Smalltalk to see what it did right. The browser is an extremely important reason why Smalltalk is good for reuse. It assumes that code is readable. I think this is important, and people who expect to sell components without providing source should ponder what they must do to overcome the fact that their users won't be able to read their code. Ralph Johnson -- University of Illinois at Urbana-Champaign