<disclaimer> Appologies to all who arn't reading this thread. I'm going to cool off now! I think my rant is done. I'll post this for the few who actually might be interested and ask everyone else to jsut delete it!
</disclaimer> I wish I'd known that they were looking for Fortran expertise! I know Fortran inside and out... and have some great ways of documenting that old code - which can easily be interefaced to C so there is no reason to rewrite. What did people do? Just turf it? A really big problem in our field as I see it is the designer jeans problem. Something can be perfectly good and very useful yet it often gets turffed and replaced sometimes with things which are not all that much different, might have serious limitations, and are not proven... then they wonder why things don't work very well! I am reminded of my trip to San Francisco where I saw the Winchester Mystery Mansion and the hieress of the Winchester fortune spent the fortune renovating her mansion 24x7 because she thought she would never die if she kept renovating. Amasing! They left staircases going into rooms where there were no rooms. I always thought isn't this how systems look when we re-write and replace for reasons which are little different than adopting the new current fashion. As a for instance is I can call pretty much any Fortran code from C and pretty much any C code from Fortran. The absolute worst would be having to set up a socket or a pipe. GNU still supports Fortran and it appears to be alive and well! Now COBOL that is a different monster which should have been slain before it left Frankenstein's lab. But COBOL had number types which were not supported by other than PL/I. So IMHO the _only_ route out of COBOL was via PL/I. But now today... if we look at the history between the days of COBOL and what we have now... what languages really supported something that does what Packed Decimal did? Then lets take the newest latest and greatest floats: 128 bit. Does Python support them? How about which C compilers and which Fortran compilers? <rant> Here is a bitch that I have: In any 3rd generation language I can write a record into a file or read that record back out with a read or write statment which is pretty simple to code. Putting a record into a database is conceptually not much different than writing to a file. So Oracle for instance created "pre-compilers". Oracle supported Fortran. Last I looked they dropped it. But then if I look at "how" the precomplier actually performed its magic I want to go puke. But then I can look at the pre-compilers which are available with postgreSQL. There is a fortran precompiler there and it works. It also generates a call with over 1000 parameters! Imagine. It has to stack over 1000 addresses and make the call then blow off those 1000 addresses and moments later re-do it all over again! Why not just create a map and populate it and pass the address of the map? My lord in any Fortran compiler I used since 1970 it was trivial to pick up the address and dynamically build a map... if one wanted to do it that way. Dumb way to do it mind you but maybe okay for a precompiler. Or have the precompiler call a C service routine because C supports it. We went backwards. What should have been easy became a mess and I have several friends who are professional programmers and the tops in their feilds who would never dream of using a database because of this. As I see it... any 3rd generation language should be able to "read" and "write" into a database with no more difficulty than reading and writing into a file. Set up te cursor... do the select() then read and write the records from the table. Maybe I'm the idjot but I could never figure out an easy way. But then if I looked into what oracle for instance offered which was stored triggers and blah then I couldn't do the numerical analysis! For some unknown reason to me Runge Kutta numerical integrations don't code well in a stored trigger. So as I see it... in our field there is far too much salesmanship and far too much designer jeans. A lot of the old tools were put together the way they were put together for very good reasons... they did the job. I'll stand pat om my conviction that a lot of the new tools didn't do those old jobs very well. </rant> Oh here is one which directly addresses your comment about fortran used to drive devices. I have a calcomp pen plotter. The drivers were originally probably written for an IBM 360 and they used Fortran and its the WORST code I have ever seen! But it works and we put it into a number of minis and eventually I put it into into my PC under DOS and it worked just fine and later ran this under OS/2. That old stuff all works. This is IF I want to set up an OS/2 machine and network it in and you know... that is probably a better idea than converting it to Linux... which I can do because I'm pretty sure GNU fortran will compile that ugly code! So thanks... you actually gave me a good idea! But the point is this! It often would take less effort to just keep the old stuff running than to try to decode how the stuff was written and try to rewrite it! I have friends who are machinists and some have very expensive machines like that mill I commented on. They can't even use the new computers because things like parallel ports are gone. But for them they have tool paths and these are in krasy formats and they typically are not programmers. They need that backward compatibility or they lose their investment in the equipment which runs their shops. <rant> Yes - I know its a long comment and probably I'll get spanked for typing so much and being verbose in this list! But here is a case in point for me. I have a very fine map contouring package which is commercial and which I have rights to since before the days of DOS. It drives a Calcomp plotter. I wrote HP-GL drivers years ago so it can drive an HP-GL device too. So now I have my bitch with Microsoft. This all runs under DOS, OS/2 and NT up to about 4.0 But I don't think Microsoft has a fortran compiler now which can link with the .obj's from the days of DOS. In fact when I bought Microsoft Fortran version #6 I found they had two (2) incompatible compilers in the box... one for the DOS world and one for the windows world... but my point is back then I had to chuck the compiler and I'll not look at the mess now. Thing is I can't write a new library to support a new machine because I can't link it into the old code and I don't have all the old source code because some parts of the mapping package were object code only. So I don't think I can even use it any more. This is unless I set up a virtual machine or dust off old boxen. And get new boxen talking somehow to old plotters. Its a mess. This is one reason I figuratively told Billy Goat Gates he wanted his mess and problems far more than I do! We are all far better off staying in the linux world. At least we have backwards compatibility. Even in the linux world I can write the mapping system output to a pipe and drive new machines. In the windows world I can't. The _only_ way I can think of to handle that old mapping software for instance is to resurect the old machines and operating systems and write a new interface which can dump the output to a file and once that is done then... run the old code in a virtual machine. I still say its an ugly world! CD's are a tiny part of the mess. DRM will make the mess into a nightmare. Also the people who are pushing the DRM don't care about the mess. They don't have to deal with it. They arn't the programmers or the people who won't be able to look at baby pictures. All they are interested in is money. </rant> On Thu, Feb 24, 2011 at 08:26:38PM -0700, Ellen Mably wrote: > How funny was it when people were stressing out about Y2K and one of the few > languages I had used was Fortran which had been used to programme devices > without a thought for what to do about the turn of the century. Apparently, > there weren't many programmers around who still knew Fortran. . . > > -Technopeasant > > On 24 February 2011 18:51, Gustin Johnson <[email protected]> wrote: > > > If they were well known or named formats it would not be a problem. > > Simon's example is excellent. There is a sea of dead and extinct > > formats from the late 70s through the early 90's. I use the word > > format loosely, as some of these systems were one offs for people like > > libraries, school systems, and mid to large size companies. Perhaps > > you are lucky in that seismic data can be read 50 years later, but > > this is not the norm. > > > > How many of your digital files from the 80s or 90s can still be read? > > My dad has a box of floppies for his Apple IIc, that has databases and > > word processing files. How easy is it for him to get that data on to > > his modern PC? I have personally used utilities like strings to get > > data out of old formats (assuming that I was lucky enough to have data > > in a format that used good ol ASCII) for files I created myself and I > > am only 35. Most of my early university papers are mostly unreadable > > in modern word processors. Ironically, the ones I did in TeX/Latex > > would still be readable if I had kept them. > > > > On Thu, Feb 24, 2011 at 6:00 PM, <[email protected]> wrote: > > >> Obsolete formats? Please advise which. > > > > > > It happens to everyone in the end... even NASA had issues reading > > magnetic > > > tapes containing digitised high resolution images from the Lunar Orbiter. > > > > > > That is until some determined engineers got obsessed with the project: > > > http://en.wikipedia.org/wiki/Lunar_Orbiter_Image_Recovery_Project > > > > > > Simon > > > > > > > > > _______________________________________________ > > > clug-talk mailing list > > > [email protected] > > > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > > > **Please remove these lines when replying > > > > > > > _______________________________________________ > > clug-talk mailing list > > [email protected] > > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > > **Please remove these lines when replying > > > _______________________________________________ > clug-talk mailing list > [email protected] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
