Did I write a good (efficient) program?
in [Cobol]
|
From: Richard on 1 Apr 2008 02:00 On Apr 1, 3:40 pm, Robert <n...(a)e.mail> wrote: > On Mon, 31 Mar 2008 12:10:23 -0700 (PDT), Richard <rip...(a)azonic.co.nz> wrote: > >On Mar 31, 1:44 pm, Robert <n...(a)e.mail> wrote: > > >> Efficient is Cobolese for fast. In the Good Old Days we had to hold the machine's hand, > >> showing it how to go fast. Concern for speed became THE criteria driving design. > > >No. Often saving space was just as big a concern. Fitting the client's > >product and customer files onto one 4 MegaByte disk drive was as > >important as having the daily invoice run take less than 24 hours. > > I would think you'd oppose arbitrary size limits such as fixed length arrays. Why do you think that I would 'oppose' anything, let alone do so in the absense of any context ? Fixed length arrays are useful, variable, or unrestrained, structures are useful, but not necessarily for the same problem. Some problems have actual limits, some have arbitrary constraints. > >> 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 ? > For instance, defining fixed length strings and arrays because they believe > variable length is too slow. That came out during a recent discussion about ODO. > I can't recall _anyone_ claiming that ODO is 'too slow'. In most cases they were completely indifferent to whether it was faster or slower. They just made stuff work and left it to the CPU to get it done. You seem to have this idea that every argument is either black or white. If they don't flock to follow what you do then they must be doing the extreme opposite. > >> ignoring the fact that the Pentium 4 on our > >> desktop is 2,000 times the speed of a 370/158. > > >Well, it does seem that you were alone in wanting to save a few > >nanoseconds on SEARCH ALL. You previously wanted to convince others to > >use pointer based lists because you claimed they were faster than > >tables (when my testing showed them not to be). > > The principal advantage of lists over arrays is no practical limit on size.. They can grow > to millions of entries. Other advantages are variable length entries (e.g. words) and the > ability to splice a new entry into the middle. That may be so, but it is often unrequired. In any case lists made with pointers are so 80s. Modern stuff is done with lists (with the list mechanism dealing with the grubby details), tuples and dictionaries. > >It may well be that you program "as though the year is still 1973", > >but others may not be doing so. > > In 1973 everything (except files) was fixed length. We used fixed length strings, numbers, > arrays, records and blocks in files. Now, outside Cobol, most things are variable length. You just make up nonsense out of vauge generalizations and pontifications. In the early 70s, when tapes were master files it was quite common to use variable length records, either with repeating groups or multiple record types. The 'modern' way is with normalised data, removing the variability. In fact 'outside Cobol' much has _always_ been 'variable length' and much has been 'fixed length'. For example in C strings have a terminator and are 'variable length' but only within a fixed length declaration or allocation. > The next Cobol standard proposes adding 'any length' data items and arrays.. The Old Guard > are opposed. In what way are the 'old guard' opposed ? They are most likely completely indifferent, but that doesn't seem to be on your binary scale of things where it must be 'rabid support' or 'opposed'. In fact I have used 'any length' and found it useful.
From: Michael Mattias on 1 Apr 2008 08:44 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? You need a "yes" answer to all three questions to have well-written 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. YMMV. -- Michael C. Mattias Tal Systems Inc. Racine WI mmattias(a)talsystems.com
From: Anonymous on 1 Apr 2008 10:29 In article <57qIj.23163$0o7.2366(a)newssvr13.news.prodigy.net>, Michael Mattias <mmattias(a)talsystems.com> wrote: >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? > >You need a "yes" answer to all three questions to have well-written 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. Where has this been talked about before... ahhhh... from <http://groups.google.com/group/comp.lang.cobol/msg/5f032ffb073f4861?dmode=source> --begin quoted text: (T)hat is a Major Source of Debate, I believe... the more that code caters to hardware functions the more efficient it is... and the less structured/maintainable/portable it is. You makes your choices, you takes the results. [snip] All that aside I rarely concern myself with what others think... no matter what one does there are those who will say that one is a hidebound dinosaur and others who will say that one is a slave the the flavor-of-the-month. If program-runs perform next-assignment else perform code-like-hell until damned-thing-works... don't get much plainer than that. --end quoted text DD
From: Howard Brazee on 1 Apr 2008 10:43 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.
From: Michael Mattias on 1 Apr 2008 12:04
"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? MCM |