• (cs) in reply to RandomEngy

    RandomEngy:
    I think you mean "wary", not "weary".  Wary means you're cautious or suspicious about it.  Weary means you're tired of it.  Thus he was wary of the code beforehand and then weary of it after working with it for a while.

    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.

  • (cs) in reply to rogthefrog
    rogthefrog:
    Of course the real WTF here is that he used magic numbers.

    This:
    mtx5cod              : array[0..7] of string;

    Should properly be rewritten as

    <font size="2">const SEVEN: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..SEVEN] of string;
    </font>

    (my pascal syntax is rusty and I don't know if that would even compile, having a non-literal in an array declaration). BUT IT WOULD BE MUCH CLEANER.


    It is actually worse than that. He used magic types. This:
    dodex2 = array[0..11] of string[2];
    Should clearly have been:
    strTWO = string[TWO];
    dodexTWO = array[ZERO..ELEVEN] of strTWO;



  • (cs) in reply to FORTRAN slinger

    FORTRAN slinger:
    Never coded for fun, just for dosh.
    I just don't enjoy coding unless it's on a green screen monitor, and you have to count the indentation spaces.

    Monitor? Sissy... It's not programming unless you're loading punch cards and replacing vacuum tubes.

  • (cs)

    And everything *was* clear.

    It was clear why the original programmer was no longer on the project. AND it was clear that Andy needed to get his resume in order, but FAST.

    I've seen worse ... but not awake ...

  • amped (unregistered) in reply to dubwai
    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.

    I think you meant a 'moot' point :P
  • Anonymous (unregistered) in reply to rogthefrog
    rogthefrog:
    Of course the real WTF here is that he used magic numbers.

    This:
    mtx5cod              : array[0..7] of string;

    Should properly be rewritten as

    <font size="2">const SEVEN: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..SEVEN] of string;
    </font>

    (my pascal syntax is rusty and I don't know if that would even compile, having a non-literal in an array declaration). BUT IT WOULD BE MUCH CLEANER.


    This also contains the WTF of tying the name to the value.

    Should be

    <font size="2">const TWENTYTWO: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..<font size="2">TWENTYTWO</font>] of string;
    </font>



  • ftp (unregistered) in reply to FORTRAN slinger

    Wow, that's impressive.  It makes a certain amount of sense though, given the background.

    Original code written with no OS -- variables stored in fixed memory locations.

    If you throw out the original code, regenerate it with a decompiler, modified the machine generated variable names to your best guess, then port it to a hardware-independent implementation so that the meaning of the fixed memory locations are lost, then I can see how that happened.

  • (cs)

    Why does it have to HURT?!

  • aa (unregistered) in reply to christoofar

    This reminds me of the code written by a co-worker. They project had been switched from VB Access to Delphi, and they'd had 3 days of Delphi training.

    Obviously, none actually knew what they were doing. But this one, topped them all. He had written everything in one procedure and the list of parameters was about as large as the one in this thread. The implementation lasted for 2500 lines. Again, one procedure !!

    I was fortunate enough to be working only next to their team (as opposed to "with them"), and simply be friends with some of them. They even attempted to debug the monster... I think they gave up on any hope after some eight months, and they used the code buggy as it was. That happened because the project manager didn't want to hurt the feelings of the guy who had written the beast.

  • (cs) in reply to Kaizer
    Kaizer:

    FORTRAN slinger:
    Never coded for fun, just for dosh.
    I just don't enjoy coding unless it's on a green screen monitor, and you have to count the indentation spaces.

    Monitor? Sissy... It's not programming unless you're loading punch cards and replacing vacuum tubes.



    The punched card reader was under the terminal, stacked with the bootstrap cards just in case the new leading-edge hard disk upgrade failed.  The thing was, that the card reader had to be connected and switched on, else the IPL sequence would fail.

    Bloody hard disks were more trouble than they were worth - always crashing after performing the manual head align procedure - o'scope and 1/8" allen key.  Ah, memories.


  • (cs) in reply to Name?
    Anonymous:
    Kids, what's the problem?

    This is how things were done when I was young. You had to be a PROGRAMMER in order to write a program, not some mouse-pusher, gui-clicker pansy. And when you had to write a PROGRAM in quiche-eater Pascal you made at least sure that it was structured like FORTRAN. For men, not for quiche-eaters.


    Every time I read a comment like this, I remember a great article...

    A recent article devoted to the macho side of programming
    made the bald and unvarnished statement:

        Real Programmers write in FORTRAN.

    Maybe they do now,
    in this decadent era of
    Lite beer, hand calculators, and “user-friendly” software
    but back in the Good Old Days,
    when the term “software” sounded funny
    and Real Computers were made out of drums and vacuum tubes,
    Real Programmers wrote in machine code.
    Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
    Machine Code.
    Raw, unadorned, inscrutable hexadecimal numbers.
    Directly.

    Lest a whole new generation of programmers
    grow up in ignorance of this glorious past,
    I feel duty-bound to describe,
    as best I can through the generation gap,
    how a Real Programmer wrote code.
    I'll call him Mel,
    because that was his name.


    Read the rest.  It is worth it... http://catb.org/~esr/jargon/html/story-of-mel.html
  • (cs) in reply to RevMike
    RevMike:
    Anonymous:
    Kids, what's the problem?

    This is how things were done when I was young. You had to be a PROGRAMMER in order to write a program, not some mouse-pusher, gui-clicker pansy. And when you had to write a PROGRAM in quiche-eater Pascal you made at least sure that it was structured like FORTRAN. For men, not for quiche-eaters.


    Every time I read a comment like this, I remember a great article...

    A recent article devoted to the macho side of programming
    made the bald and unvarnished statement:

        Real Programmers write in FORTRAN.

    Maybe they do now,
    in this decadent era of
    Lite beer, hand calculators, and “user-friendly” software
    but back in the Good Old Days,
    when the term “software” sounded funny
    and Real Computers were made out of drums and vacuum tubes,
    Real Programmers wrote in machine code.
    Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
    Machine Code.
    Raw, unadorned, inscrutable hexadecimal numbers.
    Directly.

    Lest a whole new generation of programmers
    grow up in ignorance of this glorious past,
    I feel duty-bound to describe,
    as best I can through the generation gap,
    how a Real Programmer wrote code.
    I'll call him Mel,
    because that was his name.


    Read the rest.  It is worth it... http://catb.org/~esr/jargon/html/story-of-mel.html



    Well worth the read.  Nice one.
  • (cs) in reply to Craig H.

    Anonymous:
    This really is bad.  The fact that anyone said "It should be very clear" Is mind boggling.  I can only image how awful the rest of the code looks.  I would be a little more forgiving if the variable names were readable, but this just makes my head hurt.

    Lets just hope they don't include files that used these global variables.

    Swhts srong wth th vrbl nms?  dm_mn, evthg wth y s jst bch, bch, bch!

  • (cs)

    Some of these variables look like they would probably be fairly meaningful if you understood the original context. This is Atari code that uses a DSP to do something; I suspect that's part of why it was "hard to port" in the past.

    Note also "midi_cmd". Very definitely hardware-specific. It has to do with a DSP, and some local hardware, and pulses, seconds, and milliseconds. "attfac" is probably an attrition factor.

    I think it's bad, but not as bad as it looks at first blush.

  • Suomynona (unregistered) in reply to dubwai
    dubwai:

    RandomEngy:
    I think you mean "wary", not "weary".  Wary means you're cautious or suspicious about it.  Weary means you're tired of it.  Thus he was wary of the code beforehand and then weary of it after working with it for a while.

    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.



    You said "irregardless" on purpose didn't you. How irrespecitve.

  • (cs) in reply to Mike J
    Anonymous:
    dabocla:
    Anonymous:
    That's not code, that's art..


    I don't know about that.  But I guess to someone,  anything could be considered art.
    Well, GG Allen used to dump on stage, spread it on himself, then throw it at the audience and THAT was considered art. ... Considering that, it seems that GG Allen was probably the author of this code....
    Well now, here's the result of one GG Allen show; it's actually almost as much fun as reading this strip of code: http://www.austinchronicle.com/issues/dispatch/2001-01-26/music_live9.html
  • Suomynona (unregistered) in reply to Suomynona
    Anonymous:
    dubwai:

    RandomEngy:
    I think you mean "wary", not "weary".  Wary means you're cautious or suspicious about it.  Weary means you're tired of it.  Thus he was wary of the code beforehand and then weary of it after working with it for a while.

    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.



    You said "irregardless" on purpose didn't you. How irrespecitve.



    Irrespective!

    Damn. That damn captcha changed the spelling of my post!! Damn!
  • (cs) in reply to K-otik

    Blah. In the old days a ton of code used to be like this. I work with legacy stuff all the time that is almost as bad. This one is just made extra special juicy because of all the graphics data.


  • (cs) in reply to aa
    Anonymous:
    ...I think they gave up on any hope after some eight months, and they used the code buggy as it was. That happened because the project manager didn't want to hurt the feelings of the guy who had written the beast.
    Personally, I would have hurt more than his feelings.
  • (cs)

    <font size="2">

    Alex Papadimoulis:
    "Don't worry," the original programmer reassured him, "everything should be clear."


    It is clear.
    Clearly a piece of shit.</font>
  • (cs) in reply to mrsticks1982

    <font size="2">

    mrsticks1982:
    {attenuation bezogen}

    ahh, this makes it all clear now ?!?!


    Maybe the original developer was German.
    I believe "bezogen" kinda means "applied to" in german.
    So I guess that clarifies 0.0002% of it....</font>
  • (cs) in reply to RevMike

    RevMike:
    Anonymous:
    Kids, what's the problem?

    This is how things were done when I was young. You had to be a PROGRAMMER in order to write a program, not some mouse-pusher, gui-clicker pansy. And when you had to write a PROGRAM in quiche-eater Pascal you made at least sure that it was structured like FORTRAN. For men, not for quiche-eaters.


    Every time I read a comment like this, I remember a great article...

    A recent article devoted to the macho side of programming
    made the bald and unvarnished statement:

        Real Programmers write in FORTRAN.

    Maybe they do now,
    in this decadent era of
    Lite beer, hand calculators, and “user-friendly” software
    but back in the Good Old Days,
    when the term “software” sounded funny
    and Real Computers were made out of drums and vacuum tubes,
    Real Programmers wrote in machine code.
    Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
    Machine Code.
    Raw, unadorned, inscrutable hexadecimal numbers.
    Directly.

    Lest a whole new generation of programmers
    grow up in ignorance of this glorious past,
    I feel duty-bound to describe,
    as best I can through the generation gap,
    how a Real Programmer wrote code.
    I'll call him Mel,
    because that was his name.


    Read the rest.  It is worth it... http://catb.org/~esr/jargon/html/story-of-mel.html

    Anyone else have a hard time reading that?  Almost as painful as today's WTF.Â

  • (cs) in reply to Kodi
    Kodi:

    Anonymous:
    Kids, what's the problem?

    This is how things were done when I was young. You had to be a PROGRAMMER in order to write a program, not some mouse-pusher, gui-clicker pansy. And when you had to write a PROGRAM in quiche-eater Pascal you made at least sure that it was structured like FORTRAN. For men, not for quiche-eaters.

     

    Bet this post was from the orignal coder of this crap. [<:o)]

    Bet this post was by someone who forgot to turn on his sense of humor (or -- worse -- don't even know that Real Programmers Don't Eat Quiche Don't Use Pascal

    RevMike:
    Anonymous:
    Kids, what's the problem?

    This is how things were done when I was young. You had to be a PROGRAMMER in order to write a program, not some mouse-pusher, gui-clicker pansy. And when you had to write a PROGRAM in quiche-eater Pascal you made at least sure that it was structured like FORTRAN. For men, not for quiche-eaters.


    Every time I read a comment like this, I remember a great article...

    Read the rest.  It is worth it... http://catb.org/~esr/jargon/html/story-of-mel.html

    The initial poster more than likely knew of the story of Mel since googling "Real Programmers" in google yields both Real Programmers Don't use Pascal and The Story Of Mel (much more readable than the Jargon-formatted one) as the two first results on front page.

  • (cs) in reply to dubwai
    dubwai:

    RandomEngy:
    I think you mean "wary", not "weary".  Wary means you're cautious or suspicious about it.  Weary means you're tired of it.  Thus he was wary of the code beforehand and then weary of it after working with it for a while.

    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.

    I think you meant "Nevertheless, this programming would make any coder weary."

  • Benjamin Franz (unregistered) in reply to whojoedaddy

    "My Eyes!  The goggles, they do nothing!"

  • (cs)

    Actually folks, as a life long Pascal coder, I can EASILY explain this abortion.

    1. The Pascal for Atari compiler market went seriously soft when no-one bothered to write one, leaving the available choices exceedingly slim.  You took what you could, lived withit and coded around the bugs.  I remember coding around PLENTY of compiler bugs for various pascal implemenations (including for mainframes-waterloo pascal really stunk) in the early days.  Symbol length varied compiler to compiler, and Turbo Pascal 3 was RENOUNED for its long identifier lengths at 25 characters.  The compiler itself required that text not exceed 1024 characters per cr/lf pair.

    2. In the old days, you did not have 10mb stacks, you MIGHT have 16k.  Globals were an absolute must.  You just did not have the stack space otherwise.  Good organization of data in the structures btw.

    3. many earlier pascal compilers were single file affairs, excluding the possible support of include files.  Not usually useful as they would obscure proper line numbers when reporting errors, and thus tended to be avoided.  As such, you tended to bunch stuff up and group declarations by type to save space.  Remember the old editors folks?  It wasn't pretty, and you sure could not load a 2mb file either.

    To be true, while the layout is exceedingly ugly, and the guy is plainly too lazy to use the enter key when he should (he might possibly have needed to remove them to get enough room for the full source in his editor, or the compiler itself), the code IS clear enough to someone familiar with reading pascal.  He has defined 3 labels to use with gotos, which is a shame, but even I used 2 or 3 in my past before I focused harder on my flow control skills.  There is a LOT of strong data typing here, admittedly confusing for a C programmer, but VERY familar to a pascal coder.  Clearly the guy was working a constrained memory arena and was squeezing every byte he could get (note the lack of the packed keyword, which in theory would have improved memory usage, but was notoriously useless in older implementations, or the default in some cases making it unneeded in declarations). 

    This is pretty obviously a game, because it contains midi code for music. You don't see people wasting effort on that for spreadsheets and such... Stop key is esc, pause is the space bar... Based on the reference to bots, I'm guessing it is sprite based game of some sort.  If I had code to go with it, I would have very little problem infering the rest.  If it is not a game, then based on the midi code, perhaps a guitair tutor or the like...

    I have definitely seen WORSE written code, but the layout definitely sucks, making it hard to read.  I've read a LOT of pascal code, so it is second nature to me.  I ported a land reservation system for the oil & gas industry from basic to pascal, and in the day and time, coding like this was just they way it worked.  At least it is all top down, and that makes things a LOT easier to deal with, you always knew if you were looking for a symbol that it was declared ABOVE from where you were reading.  Basic and C both lack that simplicty.  Object pascal still retains that fact, but with things like Delphi doing most of the object declaration at the top of the code, with implementation to follow, it LOOKS like a 2 pass compiler (but isn't - if you write straight procedures, you find that the object declaration is just the ultimate 'forward' declaration statement)

    I sure would not want to have to move it forward mind you (ok, I might, but I would wanna be WELL compensated)...  Changing all those polling loops to event handlers with state transitions.. Ick.

  • mov ax, 4c00 (unregistered) in reply to Xepol
    Xepol:
    ...


    Hear hear, a Real Programmer that is not above eating Quiche!
  • (cs)

    Wow, I hope you guys don't take this as a standard example for atari coders.

    We're usually much worse ;)

    George

  • (cs) in reply to FORTRAN slinger

    Scary....

    Even more scary is that I can tell it is a music program of some sort (references to MIDI and notes etc).

    Wayne

  • a0a (unregistered)

    .. no, I mean.. that's still readable.. where are the db $66 prefixes ? :)
  • anonymous (unregistered) in reply to Athas

    I once saw a bug that was caused by a variable being maliciously local.  It went roughly like this:

    doStuffUntilTheyPressEscape()

    {

       char c;

       do {

          doStuff();

          c = getButton();

       } while ( c != 27 );

       return 0;

    }

    The problem?  While getButton returns a value (an int, but let that pass), it always returns NULL (not an int, but let that pass too).  The code for the key that was pressed was actually returned in the global variable c.  Somehow this wasn't spotted until a paying customer complained about the hang.

     

    I think you've found my former co-worker's lost twin.  I wish I'd kept a copy of that project.  It could have kept this site happy for months.

  • Hieronymous Coward (unregistered) in reply to Xepol
    Xepol:
    This is pretty obviously a game, because it contains midi code for music. You don't see people wasting effort on that for spreadsheets and such... Stop key is esc, pause is the space bar... Based on the reference to bots, I'm guessing it is sprite based game of some sort.  If I had code to go with it, I would have very little problem infering the rest.  If it is not a game, then based on the midi code, perhaps a guitair tutor or the like...

    I think it's more likely to be some bit of software for communicating with a particular piece of audio hardware via MIDI - the Atari ST (I assume that's what's being referred to here) was quite famous for having MIDI ports, but had no on-board MIDI-like synthesiser hardware.

    The DSP is presumably contained within the external hardware, as while the Atari Falcon possessed a rather nifty Motorola DSP, code for that was generally in a ZOMGWTF multiple-columns-of-code assembler format. Plus isn't too well supported by emulators, as far as I'm aware...

    Still, no excuse for such hideous code! There were perfectly good C compilers available, and unlike early PCs you had a big, contiguous block of memory to play with - no arbitrary segmentation or limits on where executable code could be...

  • solidstate (unregistered) in reply to Hieronymous Coward

    I can't find the isTrue()'s return variable.

  • Enders (unregistered)

    A very intresting way of declaring an array

    bt_styl: array[false..true] of integer;
        ltr: array[false..true] of char;

    Now the 2 dimensional arrays

    2bt_styl: array[false..true, false..true] of integer;

  • (cs) in reply to Enders
    array[false..true]


    wait... an array from the range of false to true?

    Would that include Undefined, Null, FileNotFound and/or 42?
  • :pizza: (unregistered) in reply to Anonymous
    Anonymous:
    rogthefrog:
    Of course the real WTF here is that he used magic numbers.

    This:
    mtx5cod              : array[0..7] of string;

    Should properly be rewritten as

    <font size="2">const SEVEN: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..SEVEN] of string;
    </font>

    (my pascal syntax is rusty and I don't know if that would even compile, having a non-literal in an array declaration). BUT IT WOULD BE MUCH CLEANER.


    This also contains the WTF of tying the name to the value.

    Should be

    <font size="2">const TWENTYTWO: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..<font size="2">TWENTYTWO</font>] of string
    </font>



    Nah
    <font style="font-family: courier new;" size="2">TWENTYTWO: int = 22;
    // later
    </font><font style="font-family: courier new;" size="2">TWENTYTWO:= 7;
    // later still
    </font><font style="font-family: courier new;" size="2">
    mtx5cod              : array[0..<font size="2">TWENTYTWO</font>] of string
    </font>
  • smelliot (unregistered)

    For me, the WTF could have stopped after "...porting a Pascal-based system running inside of an Atari-emulator to a more modern platform."

    A more modern system like what- an Apple2c?

    www.lamecode.com

  • (cs) in reply to Suomynona
    Anonymous:


    Damn. That damn captcha changed the spelling of my post!! Damn!


    Sadly I'm willing to believe that too.
  • (cs)

    Half the time I come here to read the posts my head ends up hurting. 
    Yet I keep coming back for more.
    Why do I do this to myself ...

  • (cs) in reply to amped
    Anonymous:
    Actually, the intended word is probably 'leery' which is a synonym of 'wary'.  This seems to be a common thing in these here lakes regions.  But that's a mute point.  Irregardless, this code would make any developer blurry-eyed.

    I think you meant a 'moot' point :P

    No.  I mean what I write and I write what I mean.  "Aren't those the same thing?" you ask.  No.  They are not.

  • Bitnapper (unregistered) in reply to rogthefrog

    I hope you're being sarcastic. :|

    I mean, what would you gain from it ?
    If you would ever need to change the size of the array, you would have to change the name of the constant too... I would rather name the constant something that looked more like "ARRAYMAX"
    Then, you can change from
    const ARRAYMAX: int = 7
    to
    const ARRAYMAX: int = 12
    without the need for a global S&R

    My two cents...

  • (cs) in reply to Enders
    Anonymous:

    A very intresting way of declaring an array

    bt_styl: array[false..true] of integer;
        ltr: array[false..true] of char;

    Now the 2 dimensional arrays

    2bt_styl: array[false..true, false..true] of integer;



    What's better is that it could have been simplified:

    bt_styl: array[Boolean] of Integer;
    ltr: array[Boolean] of Char;

  • (cs)

    This sort of thing reminds me why, in college, the computer science department forbid the Computer Science majors from taking Fortran classes.

    The official policy was that you could take them, but they would not count toward your degree in any way.

    The unofficial policy was that CS majors simply could not take those classes. The teachers of them would drop you from the classes if you tried.

    They would teach Fortran to the engineers, but not to the Comp. Sci's. Can't have the Computer Science people's brains polluted by that garbage, now can we?

     

  • Andy O. (unregistered) in reply to BlackTigerX

    Well, may be I didn't quite catch the sarcasm in your reply.

    I began coding in Basic and later in Assembler on a C64 and never produced such things. And the C64 did have no OOP, too.



  • (cs) in reply to Otto
    Otto:

    The unofficial policy was that CS majors simply could not take those classes. The teachers of them would drop you from the classes if you tried.

    That's hilarous. [8-|]

  • (cs) in reply to Gene Wirchenko

     

  • (cs) in reply to Manni

    Manni:
    Simply removing the vowels does NOT a good variable name make. Maybe this guy came from the DOS world and doesn't think the language supports variable names longer than 8 characters?

    My bet is that this started life as an Assembler for  Atari program, and was then ported to Pascal.  (Assembler only has global variables, and generally limits identifers to very short names.)  My first C program (A port of an Assembler for Z-8000 program) looked a bit like this.

     

     

  • creaothceann (unregistered) in reply to dhromed
    Anonymous:
    You think that's bad?  At least all the globals are in one easy-to-find spot, and Pascal is a very tightly typed language that doesn't allow you to cast from one type to another!

    Thankfully Delphi and other dialects allow typecasts.

    RevMike:
    http://catb.org/~esr/jargon/html/story-of-mel.html

    Gotta support Textfiles: http://www.textfiles.com/humor/REAL/mel-prog.txt

    dhromed:
    array[false..true]

    wait... an array from the range of false to true?

    Would that include Undefined, Null, FileNotFound and/or 42?

    Boolean is of course defined as an enumeration:
    type Boolean = (False, True);

    ... and array declarations can use their ordinal values.

  • Lewis Jones (unregistered) in reply to Kaizer

    Anyone else have a hard time reading that?  Almost as painful as today's WTF.Â

    Switch your Browser encoding to UTF-8 and it will clear up.

  • (cs) in reply to KenW

    KenW:

    What's better is that it could have been simplified:

    bt_styl: array[Boolean] of Integer;
    ltr: array[Boolean] of Char;

    Unless, of course, the compiler was buggy or not fully implemented (which happened a lot in the old days, esp. for pascal).

    I suppose C programmers would also be freaked out by the somearray : array ['A'..'Z'] of somedata; too...  It was always handy to have MEANIFUL indicies -> the boolean idicies is still the most useful one outside the integer set (which did NOT have to be zero based... )

Leave a comment on “Don't Worry, Everything Should Be Clear”

Log In or post as a guest

Replying to comment #50883:

« Return to Article