• LCrawford (unregistered)

    COMPLEX * 16: FRIST

    The FORTRANNER still hasn't transitioned to mixed case because their hammer-print line printer only supports upper case!

  • LZ79LRU (unregistered)

    Ah, FORTRAN. Call me crazy but I like it. Than again I consider x86 Assembly to be a fun toy language to fool around with in my spare time. So I might just be crazy.

  • dpm (unregistered)

    Shouldn't that be 132 columns wide? (I admit it's been a while)

  • (nodebb)

    But but but... any common programming language can print to 132-column paper.

  • DeafFromLinePrinters (unregistered) in reply to dpm

    132 column fanfold green bar papers still haunts me. As does FORTRAN. The idea that someone may be using Oracle in addition to FORTRAN makes me shudder.

  • ochrist (unregistered)

    Real Programmers do List Processing in Fortran. Real Programmers do String Manipulation in Fortran. Real Programmers do Accounting (if they do it at all) in Fortran. Real Programmers do Artificial Intelligence programs in Fortran.

    https://www.pbm.com/~lindahl/real.programmers.html

  • LZ79LRU (unregistered) in reply to ochrist

    No. Real programmers do all that in Excel. For it is the goods own tool.

  • Re: Cancel the Cancel (unregistered)

    It doesn't have to be in Fortran to be on fan-fold paper. It could be more a matter of the entire application system being architected around batch processes.

  • (nodebb)

    The real WTF is, of course, that we're still using FORTRAN. That's because the customer still insists on their reports being produced on fan-feed line-printer (chunka-chunka-chunka) paper 122-columns wide etc. etc.

    No, no, NO! TRWTF is not knowing that you can use ANYTHING to print á la chunka-chunka-chunka -- that is, if you know how printing works ...

  • Jay (unregistered)

    Couldn't you just put a conditional formatting formula on an Excel sheet and call it a day?

  • AP (unregistered) in reply to dpm

    I think you're right. I recall 132 also with the green-bar paper and perforations. When I was younger, the old programmers would print out a program on one of these guys so they could, in good conscience, go take a smoke break while it was printing... for 20 minutes or so.

  • NoLand (unregistered)

    I think, it's well in the spirit. You know, back then when real programmers were paid per LOC…

  • (nodebb)

    I'll second Bananafish in that you can print to things that don't look like modern printers. I have some code here that prints to an industrial label printer--raw mode, simply a byte stream. Works fine.

    That being said, this isn't quite as evil as it at first looks--at least in the old days Fortran had short limits on significant characters in labels. You had to use yucky names like this. I don't know if it's still that way since I haven't touched it in almost 40 years.

  • Dale (unregistered) in reply to d-coder

    I was thinking the same thing, and it's certainly true. However, there was a mainframe era convention for line printers where the first character of each line was in fact a control byte to the printer, and not actually printed. SPC => a normal line; "1" => skip to new page, "2" => skip to next half page; "+" => don't advance to the next line, allowing over-striking. if that's not being taken care of by a port, then any output with digits in the first column can cause literally reams of output.

  • Andrew Klossner (unregistered) in reply to d-coder

    Yes, 132 columns. But the FORTRAN printer record was 133 columns wide. The first column was the carriage control character -- '1' to throw a new page, '0' to skip a blank line, space to not skip any lines at all, '+' to overwrite the previous line. If you didn't realize this and blindly printed a lot of numbers that started '1', you would use up a lot of paper.

  • mihi (unregistered)

    it would make sense to check for the first character in case there are many options sharing the same character (like later in the example), yet you would want to use ELSE IF to avoid checking the character again if you already found amatch.

    Lookup tables or hash tables would be another option, but probably nothing you would do in FORTRAN.

  • (nodebb)

    Huh... when was that written?

    I am working on an actively developed industrial Fortran code base, and I haven't seen a common block in a while, except when touching really old code that sits on a "what works works" basis in separate repositories. Modern-day Fortran has no need for common blocks, even if it wants to use globals.

    That aside, how did they manage to use a common-block variable in the parameter list? If I try that, it gives me a compile time error about conflicting attributes.

    As for the string stuff... Fortran has no real strings and predates the "0-terminated character array" convention of C. So Fortran's multi-dimensional-array minded solution is to have fixed-length character arrays, padded with spaces. This convention extends to comparison: In Fortran

    'hello' == 'hello   '

    is .true.. So all those comparisons == 'STR1NG ' are probably not checking, what the programmer thought the are checking. That said, our own codebase had things like data(1:4) == 'true', when just data == 'true' would have sufficed, and likely have been more correct.

    As for the rest... The cryptic variables seem to mirror the names in the database, so the cryptic names probably make sense in the context, or were badly named in another place, not the Fortran code, originally.

    But yes, that subroutine screams writing some subroutine to do the recurring stuff. And the long else-if chain could be replaced by a SELECT CASE for better readability. But given the context that was given, and the overall Syntax, it is entirely possible their compiler doesn't even support it. According to IMB's documentation, the SELECT CASE syntax was only added as of Fortran 90.

    So to get to TRWTF: Insisting on using extremely outdated compilers for all the wrong reasons.

  • (nodebb) in reply to mihi

    Yes, but, unless there's some really clever optimisation, you will be checking the first character again for each of the subordinate IFs. What you really need to do is check the first character and then check the second character onwards inside theIF`.

    Addendum 2023-05-09 05:15: Missing backquotes. Sorry.

  • hasseman (unregistered)

    Aah, printing. Using ESC codes to move printhead around. Superscript and subscript. Chemical formulas. All in Fortran and on line printers. All using ESC codes to get things right :-)

  • Erhan (unregistered)

    There are already couple of really useful instrinc Fortran functions for such operations. Apparently Matt’s replacement was not particularly familiar with whole capabilities.

    Last but not least, instead of subroutines, functions approach would make more sense.

    Best.

  • (nodebb) in reply to LCrawford

    their hammer-print line printer only supports upper case!

    That's real old school. IBM sold mixed case line printers for many years.

  • J. Random Hacker from the Internet (unregistered)

    The question is, are we talking FORTRAN 77, which is the thing haunting the comment section, or modern Fortran, which, more or less like C and C++, has new standard versions every few years, free-form syntax, OOP, built-in parallelism, whole-array operations and other conveniences? Judging by the mention of the COMMON block, I'll guess it's the former. In Fortran ≥ 90, one would implement that in a safer manner using modules.

  • TheCPUWizard (unregistered)

    Real computer paper comes on rolls!!!!!! [as I sit at my ASR-33 teletype]

  • Argle Bargle (unregistered) in reply to LorenPechtel
    Comment held for moderation.
  • Prime Mover (unregistered)

    Crikey, this one must have been one of mine. It must date from many years ago, because I cannot remember posting it. And here it is, appearing in TDWTF in the middle of a week of my holiday, which is why it's only now it reaches me.

    I know it's one of mine because I recognise the code signature, starting as it does with AASTAT.

    There's still some good money in FORTRAN, as I have discovered to my advantage recently, but I don't know for how long.

  • Craig (unregistered)

    There are still commercial code bases in Fortran that are so substantial that they're never going away, because they would cost way too much to rewrite in a more chic language.

Leave a comment on “I (fort)RAN So Far Away”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article