From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: dnew@zloty.fv.com (Darren New) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/12 Message-ID: <5vbo0e$ht9@newshub.atmnet.net>#1/1 X-Deja-AN: 271907341 References: <5v1gua$fkk@newshub.atmnet.net> <341787a6.0@news.uni-ulm.de> <5v9bnn$jbb@newshub.atmnet.net> <3418f6db.0@news.uni-ulm.de> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-12T00:00:00+00:00 List-Id: In article <3418f6db.0@news.uni-ulm.de>, Joerg Rodemann wrote: > >Darren New (dnew@zloty.fv.com) wrote: >> In article <341787a6.0@news.uni-ulm.de>, >> Joerg Rodemann wrote: >> >Well, you really must have huge screens...I myself prefer having to editor > ^^ two >> >windows: one for the spec and one for the body. > >> But that's because *your* spec and body are separate, don't you see? >> Having the spec and body intermingled so the bits of the spec relevant >> to the bits of the body it's specifying are next to each other makes >> it unnecessary to have "huge screens". If your average body is maybe >> ten lines long, and your spec is maybe five lines long, and they're >> always next to each other, why do you need a big screen? > >Do you think this is realistic? Sure I have lots of short methods. But I also >have some really huge ones. Well, me too, of course. But I find I tend to write lots of small routines with OO programming, Lisp, and FORTH, and larger routines with other types of programming. But you conveniently axed out the part about Emacs. Why do you take the three solutions I offer to a problem, axe out two, then complain that the third doesn't solve every problem? :-) >method bodys and I have the honor to change them... By the way: have you >already looked at lots of Java code? It is often already difficult to >FIND the specification visually. And den code often is not short at all. >No 5 line spec and 10 line method body. *shrug* Just my experience. Maybe >I am doing it all wrong? Give me some divine insights. I find most of the Java code that's long is doing too much in one routine, for my tastes. Long routines wind up looking like C libraries instead of OO classes. I break up Java code into fairly small chunks too. >Concerning JavaDoc: sure I had a look at it, but I did not fit my expectations >as a tool to work with while developping. Fair enough. I have seen any number of tools that will parse Java/C++/etc and provide the kinds of things you might be looking for. They just happen to cost a few hundred dollars. >> >How are you migrating a small project to a big one, when your team decides >> >the tool/class you wrote is suitable? Or if it simply keeps growing? > >> We hand it to the customer and say "Here, this is what you paid for." ;-) > >Say, the costumer comes up to you and tells you: "Well, pretty nice thing >you built. Lots of good. But now we want it do have feature x, y, z. Sure >you can do that, can't you? We saw something like that in product B so >of course this should not be to serious for you?" Do you then have the guts >to tell them that this approach is often very risky? It's usually not my decision. Fortunately, in the company I'm at now, YES, the engineering department says "how much do you want to expand it" and then gives different estimates. In earlier companies, that was always a problem, yes. We migrates small programs to big one over many years and many changes in operating systems and laws and business rules. >What I meant with my comment was that if you think you can program in the >small you must be sure it will stay that way. You might get into serious >trouble if you use such code in a big project. I know it is sometimes >very easy to argue "Well, I will just build this little tool for me, so >I need not care about proper design and implementation. It just has to work." >This is something what I call a "quick hack". And these things cause lots >of problems... It depends on how crutial the tool is for your work. The tools *I* use to make my emacs programming easier don't need to be used by anyone but me, no matter how large the project gets. If it's generally used, then yes, of course it has to be done right. What's your point? And yes, I know the difference between an internal tool and a class that's likely to wind up in a production environment, and I code the two differently. What's your point? --Darren