forums.silverfrost.com

[weaverwb]

Hi all,

Programming languages: FORTRAN, various kinds of Basic (best for quick and dirty programs), Aion 7 (an expert system language); occasional C, C++ (I don't like assembly languages, however they're renamed), java rarely.

In ancient history, assembly, algol and pascal. The later two, as well as Aion, insist on declaration. It is actually from those languages that insisted on typing that drove me away from it.

The declaration statements and the rule-of-thumb about one page code are tied together to some degree. For a lot of us, the more pages you have to juggle to understand a procedure, the harder it is. Lengthy declarations extend the pages; they obfuscate important declarations by surrounding them with a forest; and, if you don't have some default typing scheme, make you flip back and forth between the code and the declarations. Kinda like trying to read a book when you have to keep flipping back to the glossary or dictionary. My declarations are usually saved for important variables that, even though they follow the implicit typing scheme, need commenting for clear understanding of the code.

Certainly there is no point to artificially break up code that is clear as it is. Sometimes one has a very sequential method that trudges on with little branching or logical complexity. But even if it sequential, it often improves the readability to intermix comments and calls to subroutines. This way one has an upper-level program: e.g., First we're going to do a setup for the program; then we do step a, which calculates the widgets; then we do step b which sorts the widgets; then, depending on b, we either do c, invert the widgets or d, calculate an adjusted set of widgets, etc. Each step has one or a few calls to some well-named/commented subprograms.

I often write programs of thousands or tens of thousands of lines of code. A current project I'm working on --spectroscopic data reduction -- currently is about half done and contains 3360 lines of code (not counting comments, blank lines, etc., spread across 128 subprograms. That is about 25 lines of code per subprogram and six lines of declarations. There are two or three subprograms that spread over two pages or more and those are the ones I have the least faith in (although they seem to be working). They are complex because I don't understand them fully enough to make them shorter. Like Mark Twain said at the end of a letter --" I'm sorry but I didn't have the time to make this shorter"--

A second, more mature program, having to do with non-local thermodynamic equilibrium radiative transfer in turbulent plasmas, currently has about 5000 lines of code in only 26 subprograms. These are way too long and are really difficult to debug or to add new physics to. My only excuse is that some routines grew as we learned more about the physics. I've seriously considered taking a month or so and rewriting it into smaller, better organized routines. These also have about one line of declaration to five lines of code.

I would say that other fields I've written software for, such as ops analysis, dp, huge rule-based programs that compute benefits for millions of people, pretty much conform to these kinds of numbers.

I'd say the one page rule of thumb is primarily a human limitation to what one can hold completely in one's head at one time. Beyond that, you're probably thinking of it at multiple levels...various levels of summary or outline. It seems, for many of us, to let the code reflect that mental organization.

You keep mentioning efficiency. I've written lots of real-time code, concurrent code, and code that must run tens of thousands of times an hour. My approach, in the 'modern' computer era, has always been to insist on clarity of code first. If the hardware can't keep up, buy more hardware. It is almost always cheaper that software that cannot be maintained or passed on. I have a counter example to this but it is much more complex to discuss and would extend this lengthy post to an intolerable length.

[sparge]

[technophobe]

Hi Weaverweb,

I keep mentioning efficiency because for the problem I'm trying to solve this is quite a serious issue. I'm trying to develop a code that will solve transonic flow around a moving airfoil. The code is to be used on a laptop computer so the option of buying better hardware isn't an option.

The code uses an ADI scheme which sweeps through the domain and solves my equations. I want to strike a good balance between grid density and efficiency. If I can speed up the calculations slightly then I can introduce more points into my grid and improve the accuracy of the solution.

I have had several codes in the past that, by tweaking a few things here and there, have gone from 2-3 hours runtime down to 20-ish minutes. These codes had been written inefficiently (by me!) and through learning more about programming I made them more efficient and managed to greatly reduce the runtime. If I could even save a tenth of a second in each sweep then it'd be a good thing.

besides - I ask my boss: 'you can have this done either fast or you can have it done right'

he says: 'both'
Cheers,
Bren

[Keith Waters]

[weaverwb]

Would that be a computer program to prove Fermat's Last Theorem, then?

Ha! I deserved that!('')

No, I just have some code that would take about a year to run completely and discussions of it drags in design methodologies and such..

Our famous boss seems to have the standard boss answers from the 1960s. I assume you're using the profiling tool; another advantage to having smaller routines: they make locating the inefficient parts easier. Getting an order of magnitude improvement by tweaking a few things is pretty astonishing. I would hope that these experiences have led to a programming style that could never have such improvements.

As per using implicit none as an algorithm design aid during programming, a true computer weenie would say you should do the design before you start the coding but I agree that in the real world, problems are often too complex to properly understand before you actually try to code them.

I've never said that folks shouldn't use implicit none if it helps them; what burns me are folks who proclaim that everyone should work this way and worse, languages that insist on it. I note occasional hints that some folks think that Fortran should do away with implicit typing. Some of us find the typing of every variable little more than an annoying waste of time. A good language should be supportive of a wide range of programming styles, supporting our individual, idiosyncratic strengths and weaknesses in solving problems. For some of us, remembering ijklmn is no problem and we find no other use in typing each and every variable.

OBTW, using one line per variable just leads to long, Cobol-style front ends, which are also great for obfuscating the important variables. A page of declarations, for me, is guaranteed to hide any important declaration. I've even been known to put 'standardized' local variables in an include to further keep things as clean looking as possible. This way I know that each of the visible, declared variables is important.

[sparge]

[weaverwb]

[sparge]

[JohnCampbell]

I'm not sure what your arguments are suggesting, but two useful points.

1) IMPLICIT NONE or /IMPLICIT_NONE is a very useful coding environment.

2) The use of a MODULE for many parameter and global variable declarations assists in reducing the declaration overload at the start of a routine.

If you have, in a long and round about way suggested differently, I would strongly disagree.

John

[weaverwb]

Sorry about the length of things which may have obfuscated my basic point; I'll try to summarize:

Programming is a craft. the best tools are those that permit the craftsman to express himself in ways that best suit him.

Folks that insist that there is only one correct style may be managers who wish that all programmers are the same and can easily be replaced or, imho, worse, software folks who actually believe it (for a list of most of the fads I've had to live through, see "Great Software Debates" by Alan Davis. Perhaps the chapter "Software Lemmings" introduces it well.)

Fortran programmers should be especially sensitive to this as the current fad is that all code should be C++ (although I sense a transition to Java. A 'Death March' project I bailed from about 6 years ago is trying to convert a near-real time system that handles about 30 million people to Java. In this case, my prognostication was wrong -- I said, when I left, that the project would take five years, cost $10^6, and the result would be a slower response time. It is now six years, has cost several x $10^6, and they are pretty much where they started, using the old code which works fine. They have only successfully converted about two programs out of a couple hundred.).

For me, IMPLICIT NONE is not a useful coding environment for reasons that I explained. I find it a very inefficient environment.

There are sensible reasons, given above, why newbies should be told of their choices so they can decide for themselves. One reason I didn't list is the fear that they'll grow up and try to impose these preferences/fads on everyone through modifications to programming languages.

MODULEs are nice and I like using them, however, I think the primary issue is the declarations of local variables.