As an old card thumper with more error messages to his debit than he can ever count, I have some impressions.
What is good or bad in programming is dependent on what you need to do. I have solved some real-time data acquisition problems where a multi-tasking operating system's services were simply to slow to respond, so we had to lock some files in memory and write our own, faster, read/write routines in assembler. For other, number crunching problems, we had to be concerned with the efficiency of loops, to minimize the number of read/write operations, even to the extent of constructing and managing our buffers. In the old days of the IBM 650, in the late 1950s, we would calculate where the read/write heads would be on the drum after an operation to select the location where the result would be stored. Going from explicit op codes and addresses to a language with symbolic addresses and mnemonic operations speeded up getting results or crashes, but deprived us of altering a bad instruction from the keys. A real assembly language helped us to find and fix errors more efficiently. It was good training. But I have always believed that structured thinking is far more important for a programmer than structured languages. I retired before object oriented programming became popular, so I need to refrain from commenting on it. But I note that VB seems limited to Windows and to applications where efficient code is much less important that getting something that works. I, too, have been grateful for graphic routines I could call from FORTRAN. I even wrote a few . Back when I was in the oil patch, we were concerned with extracting the maximum useful information from an instrument that produced 250,000 measurements per sample. We used principal component analysis to search for significant combinations and to get rid of false correlations from rounding error. Got a big program almost finished when one of the old timers much higher up wanted to know why we didn't use the general stat package the company had purchased. I said it wouldn't work, but the fellow insisted on a test. We were about a third way through reading the first data set when the program barfed and said too much data, cut it back. The man said "Why not?" I said the purpose of the project was to see if some non-intuitive linear combinations of variables might be significant. He shook his head. Don't think he ever understood. His eyes glazed over when I tried to explain the math to him. But I did turn out some interesting titles, like "Minimum Multiplication Matrix Manipulations in Marginal Main Memory" and "A Generalized Gnomonic Projection of the Spheroid on the Sphere." The latter saved my employer from tying up a big mainframe complex for a week or so. Ah, what wit and wisdom lies buried in company archives. We produced results in FORTRAN, and the code was almost completely independent of operating system. Choppy At 01:22 PM 10/10/06, Dustin wrote: >I tend to agree. As far as VB and its impact (good and bad), I think >it's really hard to understate it.
