Did I write a good (efficient) program?
in [Cobol]
|
From: Pete Dashwood on 1 Apr 2008 16:41 "tlmfru" <lacey(a)mts.net> wrote in message news:96uIj.44130$QC.26319(a)newsfe20.lga... > > Richard <riplin(a)azonic.co.nz> wrote in message > news:ee588146-8f0f-44cf-9674-51a4037ecdf9(a)s37g2000prg.googlegroups.com... > On Apr 1, 3:40 pm, Robert <n...(a)e.mail> wrote: >> >> As >> >> machines got faster, we kept doing it out of habit and because no one > told us to stop. We >> >> now program as though the year is still 1973, >> >>> >Who are the 'we' that you speak of ? Are you making another of your >>> >infamous 'universal truths' about 'all Cobol programmers', or is it >>> >just yourself that is a 'royal wee'. >> >>> 'We' refers to those who pre-optimize code before there is evidence it > needs to be >>> optimized. > >>Just you then is it ? > > That's uncalled-for. Any programmer worth his thinking cap does this sort > of thing automatically - for instance, making sure that calculations that > don't beed to be inside a loop are moved outside it; or using a single > variable to hold the results of a complex calculation rather than > reiterating the calculation itself ... and so forth. > I agree that most of us who have any experience of programming do try and make things more efficient as we write, often in the ways you note above, and it is irrespective of whatever language we are using. But we also need to recognise that modern optimisers can do this job for us and often do it better than we can. Today, this isn't as important as it once was. It is also likely that in any exchange between Robert and Richard there are going to be statements on both sides that are "uncalled for"... :-) As long as it isn't mean or vicious, and nobody is blinded to the actual value of their posts, I see no harm in it...:-) Part of the normal rough and tumble on Usenet... Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 1 Apr 2008 17:07 -- "I used to write COBOL...now I can do anything." "Michael Mattias" <mmattias(a)talsystems.com> wrote in message news:57qIj.23163$0o7.2366(a)newssvr13.news.prodigy.net... > You know, I've always used three tests to decide if code is well-written: > > 1. Does it work? > 2. Is it *relatively* efficient? > 3. Is it maintainable? > Yep, same priorities I have always observed also... However, in the light of my experience over the last decade or so, I would qualify these criteria with: "applies only to Procedural Code." OO Code has a different set... 1. Does it work? 2. Is it small and complete (encapsulated)? 3. Can I reuse and extend it easily? Efficiency is taken care of by keeping components small, and using optimizing compilers. Maintainability is not a consideration as long as the interface is simple or non existent. I like to use internal properties (via GETTERs and SETTERs) to modify behaviour of components, as this avoids needing parameter interfaces, but it isn't a hard and fast or black and white rule, and it is certainly arguable... I have found it works and can completely eliminate maintenance. These days I write stuff, thoroughly debug it, then forget about it. I don't plan to "maintain" encapsulated functionality, and, so far, I have never had to. I also don't need to regression test new functionality because it cannot affect existing functionality, which continues to function as it always has. OO encapsulation is a form of "ringfencing" for systems. To modify existing functionality does NOT mean modifying a base class. It means extending (through inheritance) or over-riding existing behaviours. Again, only the parts of the system that invoke the modified functionality need to be tested as the rest of the system is isolated from the changes. This is, obviously, a different world from COBOL, which was conceived as being "easily maintainable" in the days when that was important. > You need a "yes" answer to all three questions to have well-written code. Yes, but the question set is different between Procedural and Object Oriented code. > > While 'works' is non-negotiable, I'll often often trade 'ultimate > efficiency' for maintainability; e.g., "ultimate" efficiency can often be > best achieved by using lots of GO TOs; but this comes at a maintainability > cost I am generally not willing to pay. > > All done, but need more efficiency? My rule for optimizing may help: > First you make it work; only then can you make it work better. Emphaticaly agreed :-) For both Procedural and OO... Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 1 Apr 2008 17:44 "Michael Mattias" <mmattias(a)talsystems.com> wrote in message news:B2tIj.20982$xq2.2197(a)newssvr21.news.prodigy.net... > "Howard Brazee" <howard(a)brazee.net> wrote in message > news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8(a)4ax.com... >> On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias" >> <mmattias(a)talsystems.com> wrote: >> >>>1. Does it work? >>>2. Is it *relatively* efficient? >>>3. Is it maintainable? >>> >>>You need a "yes" answer to all three questions to have well-written code. >> >> Of course, the industry has changed considerably - which has changed >> how we grade these. > > I don't about "industry" but I have always weighed 'maintainability' very, > very heavily: When was the last time you saw a program which NEVER was > upgraded/enhanced/changed? > I have dozens of them :-) They're called "components"... Each of them represents encapsulated basic functionality that simply doesn't change. They are building blocks, just like atoms or bricks; you don't modify the structure of the atoms to make a different molecule; you just combine different atoms differently (or add some new ones). Components that access or maintain data are most likely to be "volatile". That's why I use an n-tier approach to system architecture. Components in the DB access layer are virtually "cannon fodder" and can be replaced or extended very quickly. (In fact, I am currently evaluating tools that will automatically generate these components whenever I change the DB design...There are some staggering tools available...) It was this that led me to consider interfaces very carefully. Most of the time, if you change an interface (maybe add another parameter or parameter value) it has a serious effect and requires regression testing. If you can avoid changing the interface you can avoid much of this grief. As Object Classes can be forced to generate automatic methods for accessing and setting their internal properties, this means I can change parameters without changing interfaces. This allows me the option to "activate" existing functionality that was built in by "up front" design (part of a GENERAL rather than SPECIFIC solution, or to add new behaviours by overiding or extending existing methods in a new subclass. (This allows "evolutionary" design rather than "up front" design.) I can use either or both design approaches, and I never need regression testing. (It would be VERY difficult to implement such an approach, WITHOUT using Object technology...) Only the control elements that invoke the new or modified functionality need to be tested. Pete. -- "I used to write COBOL...now I can do anything."
From: Michael Mattias on 1 Apr 2008 19:21 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:65folmF1f605pU1(a)mid.individual.net... >> I don't about "industry" but I have always weighed 'maintainability' >> very, very heavily: When was the last time you saw a program which NEVER >> was upgraded/enhanced/changed? >> > I have dozens of them :-) > > They're called "components"... Applications programmers (eg, moi) don't think in terms of "components"; strangely enough, we think in terms of "applications." I guess that explains as well as anything why it is 'systems' programmers are the ones who just couldn't cut it in applications. MCM
From: Pete Dashwood on 1 Apr 2008 20:37
"Michael Mattias" <mmattias(a)talsystems.com> wrote in message news:ZrzIj.36801$J41.3240(a)newssvr14.news.prodigy.net... > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:65folmF1f605pU1(a)mid.individual.net... >>> I don't about "industry" but I have always weighed 'maintainability' >>> very, very heavily: When was the last time you saw a program which NEVER >>> was upgraded/enhanced/changed? >>> >> I have dozens of them :-) >> >> They're called "components"... > > Applications programmers (eg, moi) don't think in terms of "components"; > strangely enough, we think in terms of "applications." > > I guess that explains as well as anything why it is 'systems' programmers > are the ones who just couldn't cut it in applications. > :-) I build Applications from components; probably comes from using Meccano with my Dad when I was a kid (before they invented Lego). I have tried doing it the way you do, but I like the component based approach better. "Chacun a son gout" as the Irish say... Pete. -- "I used to write COBOL...now I can do anything." |