Structured thinking is critical in program design. Structured programming techniques are intended to force some structure on sloppy thinkers.
With the mapping program we met as a team for a couple of hours in the mid morning and reviewed code that was tested the day before, and then continued designing in an abbreviated logical language we called pidgin. Then subroutines were assigned to individuals to code and test. When we were satisfied with a routine, it replaced a tab or dummy routine called by the next higher module. We limited our subroutines to a page of code and most of a page of declarations. We had rules for variable names that made clear what was global, what was common to a few routines, and what was local to the subroutine. There were some interesting numerical problems, like designing code to decide it a point was inside or outside of a polygon of great circles. In other programs it was sometimes necessary to generate very efficient code, as for instance for real time data acquisition, where each packet had to be processed before the next arrived. For some of these I coded the bit manipulations in FORTRAN, then recoded in assembler for speed. Thus if the program ever had to be ported to other hardware, it could be tested with the more general FORTRAN code. There is a world of difference between a large program that must be maintained by people not around when it was written and private code to test an algorithm or approximation. But I still believe it is easier to teach enough programming to someone who knows the task in depth than to communicate the problem adequately to a programmer with little or no background in the underlying science. I ran into some problems with early versions of VAX/VMS in real time that first showed up at NASA, where satellite data needed to be received and stored before the satellite moved out of range. The same fix worked for both of us. It's fun to recall some of this, and I might enjoy getting involved in current work. Choppy At 11:22 AM 5/2/2008, Fernando Vilas wrote: >On Friday 02 May 2008 10:59:44 Alvaro Zuniga wrote: > > >Yes! People trained in structured programming make all the >difference. Modern >languages have extensive libraries of common ADTs, so only a cursory >knowledge is required there, unless you're writing the library. That sounds >like blasphemy, but you only need so many people on your team in most >environments that understand why to chose a red-black-tree over a singly >linked list in certain cases. The rest will ask the subject matter expert, >and that leaves them free to specialize in other areas. > >Peer reviews also help tremendously. They are the equivalent of sending your >patch to the -dev list of a project to make sure it's good enough to commit >to the repository. The more experienced members of your team can guide you >when you need to put in a little more structure, or develop some esoteric >data type. _______________________________________________ General mailing list [email protected] http://mail.brlug.net/mailman/listinfo/general_brlug.net
