• ray10k (unregistered)

    Code highlighting could have saved the day, but I suppose the computers at the time just didn't have the capacity for that, no?

  • (nodebb)

    The analysis is complete and utter bullshit.

    Block statements in TP4 are, as always in Pascal, demarcated by begin and end keywords. Braces are 100% exclusively for comments. There are also paren-star and star-paren delimiters for comments, and normally to nest comments you put braces around paren-star comments or vice versa.

    And the assignment operator in Pascal is :=, not a plain =.

    -2/10 Must try.

  • M (unregistered)

    Agree to bullshit: Turbo Pascal for rocket control firmware ?

  • nate (unregistered)

    Would be interesting to know which language it really was, because the code snippet and explanation in the article are utter nonsense. (Neither does the code even remotely look like Pascal, nor had any Pascal version any ambiguity between block and comment boundaries.)

  • Frank Malcolm (unregistered)

    That is just WRONG. Or laughable.

    I don't know who Remy Porter is, but he obviously doesn't know very much.

    I suppose an apology would be too much to expect?

    Oh, he already included one in the HTML comments, sort of:

    Now, I'm no Pascal expert, and I remember needing to use begin and end twenty years ago, when I last touched it, but this is the code which Simon supplied, so we're going to roll with his explanation, but please, do take to the comments to explain your Pascal expertise.

    Bit of a nonpology, if you ask me.

  • Little Bobby Tables (unregistered)

    In addition to Steve The Cynic's comment, which may or may not be accurate (I wouldn't know, my Pascal has not been exercised since 19xx), the real WTF is the comment itself.

    Effectively, sans the waffle, the comment does nothing more than just repeat the line of code beneath it.

    "It's too big so we're dividing it by 2." Gosh, that's helpful.

    That's the real reason why it's Simon T.'s last day of employment.

  • Kaewberg (unregistered)

    Best comment: #; (Scheme syntactial (comment) That (comments (out one) expression) !) This is not commented

  • RLB (unregistered) in reply to Steve_The_Cynic

    Yup. Goodness knows what it is, but a real language it isn't. Here, thought experiment: what if, in this language, you want to comment out a line of code? And you do it using braces? What is the resulting line? It's a comment! It's a block! No, it's a super-not-a-real-language!

    And even were it not bovine excrement bunked up by someone who has never actually programmed in more than one language, TRWTF would still be the equally bovinely excremental suggestion that anyone writing missile code would let Turbo Pascal anywhere near it. Even if Ada had not been mandated from up on exaltedly high, there would have been several specialist, designed-for-pain-and-safety languages available. Original Pascal... maybe. Probably not even that. But Turbo Pascal? It wouldn't even have been allowed to write the accounts package.

  • Not great clues (unregistered)

    I don't know what that language is, but that's NOT Turbo Pascal. From where did the author get the impression you can use curly braces for both comments and code blocks in Turbo Pascal?!

  • LCrawford (unregistered)

    I could say that this code block could be excused as real Pascal if it had been translated from C and the dev forgot to BEGIN-END those braces, except that it was being translated from FORTRAN and would not have had braces to begin with.

  • (nodebb) in reply to Little Bobby Tables

    Re: the comment: it does explain why we want to take half. The reasoning is several buckets short of coherent, but the comment is more than just "reduce the roll by half" followed by roll := roll / 2;

  • Moschops (unregistered) in reply to Frank Malcolm

    "I don't know who Remy Porter is, but he obviously doesn't know very much."

    I don't know who Frank Malcolm is, but he's demonstrated such poor logic that I'm surprised he can operate a keyboard.

  • Erik (unregistered) in reply to RLB

    Googeling "curly brackets as comment", leads to https://community.dynamics.com/nav/w/designpatterns/195.comments-curly-brackets .

    So there is at least one language where curly brackets can be used both to create a block and to create a comment.

  • Your Name (unregistered)

    Shun the frumious Bandersnatch! Pascal without BEGIN/END is an abomination and must be terminated by vorpal sword.

    That said, the code example would still work and be just as (non-) mind boggling if the BEGINs and ENDs were edited in. You could have the same error with the classic c style /* … */ or any other paired comment markers where a comment-begin marker may reside inside the comment.

    If I remember correctly, FORTRAN comments originally used to start at a specific position of the line and go to the end of that line (72nd position or so?). Those would be immune to this sort of error. Which just goes to show that the computing world continually went down the dump after card punchers were abolished.

  • Erik (unregistered) in reply to Erik

    NM. Misread the second bad example

  • (nodebb) in reply to Little Bobby Tables

    I wouldn't know, my Pascal has not been exercised since 19xx

    Just noticed this. Mine hasn't either, not since BEFORE 1995.

  • OhThe Pain (unregistered)

    There is so much wrong with this story

    • Delphi and not Turbo Pascal had curly brace comments
    • Assignments were always := and not = in Pascal
    • Rocket trajectories would be vectors, not scalars. (Gee what if the wind came from the North or South?)
    • A parabolic trajectory ending 5 m from the launch pad means that the rocket is very much smaller than 5 m long (IE small for a rocket)
    • The story says this code was ported from a mainframe, meaning this code itself never flew on a rocket.
    • The rocket control code would either be hard coded or run on some sort of RTOS, precluding things like TP or Delphi (But Ada perhaps?)

    It's as if the story was deliberately exaggerated for some reason.

  • ichbinkeinroboter (unregistered) in reply to Erik

    OMFG!! That is madness... and I am a career MS person (never touched NAV though)

  • Noble Coward (unregistered)

    Rubbish article. The worst about it is that it actually makes a tiny little amount of sense, if written in proper Pascal: if roll < 0 then begin {we're adjusting the roll here cos it's too high so we are going to take just half roll := roll / 2; zcdem := zdem { add gravity } end else begin {roll is clockwise} … end

    And TRWTF is of course, that (just like C /* */ comments), Pascal comments do not nest.

    Other rubbish in the article: I doubt an entity involved with designing missiles would use Turbo Pascal for a guidance system. At the time, I think there would have been two choices: JOVIAL or Ada. Also, to my best knowledge there is no such thing as FORTRAN 68. Algol68 sure (and if it had been a British missile I suppose some version of Algol68 could have been involved), but FORTRAN would be IV, 66 or 77. (I don't recall the later versions.)

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Erik

    I looked at your link and see no indication of curly braces being used as anything but a comment. The example given was clearly of commenting out multiple lines of code.

    So I also join the chorus of "Pascal always required BEGIN and END!" Sure, there's that silly way to get BEGIN and END by using #define in C, but that doesn't work the other way. C also does have the equivalent to this, when you use /* / to do block comments, and one line also uses / */, but the compiler complains about that, and that's what #if 0 is for.

    I did do a bit of WTF at the mention of TP4, since I remember using TP5 back in the day, with no good reason to still use TP4.

    So the submission is a cute idea, but I can't think of it realistically happening. Besides, the compiler would still complain about mismatched } eventually, if it wasn't nest counting the { from the comment.

  • Charlie (unregistered) in reply to OhThe Pain

    When I was writing code for missile control, it was running on TSX-11, which is a RTOS for DEC minicomputers. Kids today refer to those old DEC minis as "mainframes" because they haven't ever seen a real mainframe and can't be arsed to learn the meaning of a word before using it. They should get off my lawn.

  • Harrow (unregistered)

    Simon T's error has absolutely nothing to do with curly-braces used as 'begin' and 'end'. It is a simple unclosed comment error which does not involve the 'block-defining curly-braces at all.

    An unclosed comment plus an inadequate test suite is hardly a remarkable circumstance and not worthy of presentation anywhere on this site. Even in an actual language within a believable story.

  • Smash (unregistered)

    Gotta agree with the myriad of people saying this is nothing but fabricated nonsense. Nothing in this supposed TP4 code even resembles Pascal's syntax. The other points like OhThe Pain's "too small to be a real rocket" also make a lot of sense.

    I've had more believable stories coming out of a lawyer's mouth.

  • Dave (unregistered) in reply to Harrow

    Sure, we all cause expensive explosions every day...

    I suggest the people who are a bit sceptical about this story read Ignition!, the history of rocket fuels. Whenever you make a mistake in rocketry, idiot or otherwise, things go bang. I doubt anyone senior in the field hasn't been responsible for at least one test like that.

  • 🤷 (unregistered)

    Who would win?

    A multimillion dollar project, thoroughly tried and tested vs One curly boi! }

  • (nodebb) in reply to Charlie

    They should get off my lawn, too, except that I live in a fifth-floor apartment and the weird plant growing in the drain hole of the balcony doesn't count as a lawn. I got a tour of the "server room" of a company I worked at in the summer of 1987, and they had an IBM 4381, cited as "mid-range" but part of the System/370 mainframe family.

  • Calli Arcale (unregistered) in reply to OhThe Pain

    Small rockets do exist, and usually get their marching orders (so to speak....) from a computer in the aircraft/ship/ground/whatever. So a minicomputer or such doing the calculations isn't really out of the ordinary....

    ...except I've not heard of one that accounts for roll. Most missiles, especially small ones, once they depart the launcher are pretty much on their own. Mavericks are video guided and can be steered remotely, so those maintain communications with the launcher. I suppose those might want the launcher to be informed of the rocket's roll rate -- but hoo boy would that be an expensive missing curly brace. :-D Does somebody who knows store types have a better guess? ;-)

    5 meters from launch site on a parabolic arc is possible for larger vehicles if it launched basically straight up. (It has happened. The results are usually very expensive, even if there isn't a warhead!) Otherwise, if this is something rail or tube launched, that almost sounds more like a failure to start the engine. It'd have to be an extremely quick screwup to actually plow into the ground 5 meters away, given how fast a small missile accelerates. I'm not thinking there's any kind of a parabolic arc at all here. Either it failed to ignite and just blorped out of the launcher to bellyflop downrange, or it just augured itself in immediately.

    I find myself really wanting to know where that roll rate is coming from. Actual roll rate? Predicted roll rate? What is the code executing on? When they divide by two, does it mean the actual roll is excessive, or that there's an error in the detected roll rate? It smells of a kludge, either way.

  • Eric Gregory (github)

    Had nobody heard of unit tests or learned how to step through code in a debugger?

  • Sole Purpose of Visit (unregistered) in reply to Harrow

    Oh, I don't know. Nothing at all in the OP, as presented, is remotely plausible, but:

    1. I don't know of any safety-critical software (which, if you replace "safety" with "lethal," applies to military) that doesn't insist on code coverage in testing. Naturally, you can't get 100% code coverage, but the bits that are red-lit are squinted at by many, many eyeballs. This example, btw, would be easy to spot for any decent tool: empty conditional brackets are Not Good.
    2. I would fire, no, tar and feather, any testing team that didn't test something as basic as reversing the direction of an important domain-specific vector.
    3. Stupid as the non-defence that "the wind was blowing from the wrong direction" might be, one has to wonder at an expensive set of hardware tests that only operate from a fixed point in a fixed direction.
    4. Most importantly, whatever the actual programming language is, the idea that you can't match parentheses is ... I can't actually find the words for this. Try, just try, to imagine the lexer and parser combination that won't spot the mis-match. I can't.

    It's not like the infamous /* ... */ errors that used to occur (may still occur, for all I know) in C/C++. This stuff isn't pre-processed. If it was, the begin ... end version of parenthesis usage wouldn't work, either.

    Gaaah. Needz Moar Explanation.

  • Sole Purpose of Visit (unregistered) in reply to Steve_The_Cynic

    You should probably offer that weird plant to Remy.

    It's clearly better quality than whatever he's smoking.

  • (nodebb) in reply to Calli Arcale

    ...except I've not heard of one that accounts for roll.

    RIM-116 Rolling Airframe Missile? Roll is an integral part of how it operates.

  • (nodebb)

    I guess Simon performed some heavy obfuscation on his article before submitting, in the hope that his (previous?) employers won't hold it against him. Pascal, missiles, roll and mainframes probably played no role in the real story.

    I have a similar story of a huge fark-up I was involved with. Even 13 years later, I probably wouldn't post it here without some serious doctoring, or else I would end up jobless and unemployable.

  • Bart (unregistered)

    IIRC that won't compile in TP4, since TP4 doesn't support nested comments like {start{nested}end}. FreePascal in TP mode won't compile it: "Fatal: illegal character "'}'" ($7D)", thats the } before else. Even if nested comments were supported by TP4 then all the code after the entire code shown here would still be a comment, so the compiler would complain about "Fatal: Unexpected end of file", when it came to the end of that file.

  • Gumpy Gus (unregistered)

    It was quite possible to goof up comment in Turbo Pascal.

    The plain Standard pascal used (* and *) as comment delimiters. Turbo added a tonload of useful extensions, plus the use of {} as comment delimiters. don't recall if you could mix them or nest them, or both, probably not.

    There are far worse problems with the code. Assuming roll is a real variable, you should be comparing it to a real constant, so that should be roll < 0.0. Well, no, logically that makes no sense, there is nothing special about a left roll, unless the aeronautical engineers have specificially designed the erodynamics or the roll inducers to be asymettrical.

    Also dividing by 2 is almost certainly not the right thing to do. There should be some heavy-duty equations ahead of this computing the commanded roll, involving multiple integrations. Halving the left-going roll rate is almost certainly a kludge that will make the real equation writers blanch. Note that the roll command by this point has taken into account things like past direction, past angles of attack, wind, control-surface positions, rate of change in all three axes, velocity, desired rate of change, and target position. Taking a fully-informed roll command and arbitrarily halving it is 99% likely to be completely wrong.

  • Frank Malcolm (unregistered) in reply to Moschops

    Hi Moschops,

    I didn't write all of what appears under my name. The first lines yes, but the later comments and the stuff in the grey box have been added by someone else. Regards, Frank

  • Gerry (unregistered)

    As a current Pascal (OK Delphi) programmer, I suspect the code was more like:

        if roll < 0 then
    begin
      {we're adjusting the roll here cos it's too high so we are going to take just half
      roll := roll / 2;
      zcdem = zdem; { add gravity }
    end
    else
    begin
    {roll is clockwise}
      …
    end;

    I suspect this is recounted from memory.

    Note, I also code in C#, and have never got confused with the syntax when swapping languages. IDE shortcut keys however...F9 and F5 swap there meaning from Delphi's Run and Set breakpoint to VS Set breakpoint and Run

  • sdfwerwrr23 (unregistered) in reply to Frank Malcolm

    I don't know who Remy Porter is, but he obviously doesn't know very much. You must be new here.

  • Decius (unregistered)

    It almost makes sense if you use comma delimiters instead of braces, and if you use something that handles negative roll instead of dividing by two.

  • Dan (unregistered)

    If this was DoD, they pretty much required all code to be written in Ada, not Pascal. My dad had a contract to do something for them many years ago, and of course, used Ada. This isn't good Ada syntax either, though. Most likely, this is a regurgitation from faint memories, as the original code was likely classified originally and therefore not in the OP's possession after all these years. TRWTF probably is, entirely, the unclosed comment that effectively killed the block of code. Everything else wrong with the submission is likely from brain rust.

    And if this was the late 80's, then no, nobody ever heard of 'unit tests'. I doubt if Ada (or even Pascal, for that matter) would easily support unit testing, as the language did not have macros or other easy switching machinery. For that matter, I'm pretty sure that multi-source-file Pascal programs were implemented in a compiler-specific fashion for each compiler that bothered to implement it at all.

  • david (unregistered)

    I commanded an anti-tank missile battery during Gulf War One, and now I am a QA/developer for a major-league Investment Bank. This story is the biggest load of you-know-what since the Sergeant-Major told us "the transport will be here in 10 minutes".

  • dan (unregistered) in reply to ray10k

    Turbo pascal didn't get syntax highlighting until a few versions later. IIRC v7, but it's been a long time for me too...

  • Old dog (unregistered) in reply to Dan

    And if this was the late 80's, then no, nobody ever heard of 'unit tests'. I started programming in '81 and I assure you that unit testing was mandatory at the insurance company I worked for and it wasn't new either. Can't imaging that the DOD wouldn't have required it either.

    Regardless the whole article is full of holes

  • old timer (unregistered) in reply to Gumpy Gus

    The plain standard pascal used (* *) comments for machines that didn't support { } characters. The equivalent standard c trigraphs would be ??< and ??>

  • old timer (unregistered) in reply to Dan

    Ada didn't (doesn't?) allow/support block comments, precisely because of the problems illustrated here. Ada was used for development where people wanted to avoid errors, precisely because Ada avoids that kind of problem illustrated here,

  • old timer (unregistered)

    ... And if it was turbo pascal, the logical thing to assume would be that the original error, on translation from FORTRAN, was something like

    If condition then statement1; statement2;

    Or If condition1 then if condition2 then statement1 else statement2;

    Other possibilities include the "embedded comment problem" : since the digraphs as originally defined were for the support of standard printers, some dialects of Pascal permitted comments of the form (comment} or {comment)

  • old timer (unregistered)

    cripes, what's the markup for code?

    comments of the form ( * --- }

  • Little Bobby Tables (unregistered) in reply to Dan

    In 1987, we did use what were effectively unit tests for each module of code. We had a simulation. We used it to design the algorithms, which we then implemented in Ada. Into the Ada modules, we got the developers to feed in the files containing the test data, and got them to make sure the numbers coming out matched what they were supposed to. A little clunky and fiddly, but it worked for us. And it worked for the system we designed as well. Very proud we were when it passed its sea trials with flying colours.

  • (nodebb) in reply to Charlie

    "When I was writing code for missile control, it was running on TSX-11" -- or straight RT-11..... There were quite a few situations where RT was certified approved, but TSX was not..... Fond memories.

  • markm (unregistered)

    Aside from the un-closed comment error, the intended code still looks like a WTF to me. If 'roll' is negative, it's too big???

    The only way I can make sense of this is if 'roll' is a signed integer type, scaled so 360 degrees of clockwise roll is scaled to the whole range of positive integers. That is, for a 16 bit integer, 0 degrees is 0, x degrees is x*32768/360, and your highest legitimate roll is 32767 or one step short of rolling the whole 360 and winding up back at zero - but at that rollover step, your internal scaled value becomes 32767 + 1 = 0x7FFF + 1 = 0x8FFF = -32768. 'roll' is negative because the variable overflowed.

    But then, how would dividing by two fix it? This seems to be saying that if it rolled clockwise to 360 degrees, or counterclockwise to -0.01 degree, you divide and set it back to 180 degrees! It seems to me that, if the comment was correctly terminated so the code "worked as intended", the result of hitting this condition would be that the missile rolled onto its back and crashed.

  • Bart (unregistered) in reply to markm

    No, roll is not an integer since the / operator in Pascal will result in a floating point variable on the left hand side of the equation. If roll were in anteger, the code would therefore not compile at all.

Leave a comment on “A Comment on the Military Industrial Complex”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article