5 ms·

That particular code is idiomatic to anyone who worked with 2D bitmap graphics in that era. pt == point, r == rect, h, v == horizontal, vertical, BSR(...,1) is

That particular code is idiomatic to anyone who worked with 2D bitmap graphics in that era. pt == point, r == rect, h, v == horizontal, vertical, BSR(...,1) is a fast integer divide by 2, ORD4 promotes an expression to an unsigned 4 byte integer The algorithms are extremely common for 2D graphics programming. The first is to find the center of a 2D rectangle, the second offsets a point by half the size, the third clips a point to be in the range of a rectangle, and so on. Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case. (Mac Pascal didn't have macros or inline expressions, so inline expressions like this were the way to go for performance.) It's like using i,j,k for loop indexes, or x,y,z for graphics axis.

DanHulton 9mo ago
Xyz makes sense because that is what those axes are literally labeled, but ijk I will rail against until I die. There's no context in those names to help you understand them, you have to look at the code surrounding it. And even the most well-intentioned, small loops with obvious context right next to it can over time grow and add additional index counters until your obvious little index counter is utterly opaque without reading a dozen extra lines to understand it. (And i and j? Which look so similar at a glance? Never. Never!)
- kaibee 9mo ago
  ijk are standard in linear algebra for vector components. > (And i and j? Which look so similar at a glance? Never. Never!) This I agree with.
  - eimrine 9mo ago
    What if not ijk? I know only uvw.
    - jiggawatts 9mo ago
      Pretend to be a physicist and use μ and ν.
  - zeckalpha 9mo ago
    i came from imaginary numbers which were extended to make quaternions.
    - jibal 9mo ago
      i, j, k comes from FORTRAN's implicit types -- by default, names starting with I-N are integers and all other names are real.
      - jcelerier 9mo ago
        this is much older ; Joseph Fourier was already using "i" and "j" for indices in the 1800s. See page 209: https://www.google.ca/books/edition/OEuvres_de_Fourier_Th%C3%A9orie_analytique_d/safvAAAAMAAJ https://www.google.ca/books/edition/OEuvres_de_Fourier_Th%C3...
        jibal 9mo ago
        The context is i, j, k as indices in programs. No doubt FORTRAN was influenced by prior use such as you cite. But in no case does i used as an index come from i designating an imaginary number, which is what I aimed to refute.
        zeckalpha 9mo ago
        Representing dimensions as indexable rows and columns of vectors or matrices was done on paper in the 1800s.
- jonahx 9mo ago
  > but ijk I will rail against until I die. > There's no context in those names to help you understand them, you have to look at the code surrounding it. Hard disagree. Using "meaningful" index names is a distracting anti-pattern, for the vast majority of loops. The index is a meaningless structural reference -- the standard names allow the programmer to (correctly) gloss over it. To bring the point home, such loops could often (in theory, if not in practice, depending on the language) be rewritten as maps, where the index reference vanishes altogether.
  - vilos1611 9mo ago
    I respectfully disagree. The issue isn't the names themselves, it's the locality of information. In a 3-deep nested loop, i, j, k forces the reader to maintain a mental stack trace of the entire block. If I have to scroll up to the for clause to remember which dimension k refers to, the abstraction has failed. Meaningful names like row, col, cell transform structural boilerplate into self-documenting logic. ijk may be standard in math-heavy code, but in most production code bases, optimizing for a 'low-context' reader is not an anti-pattern.
    - jonahx 9mo ago
      If the loop is so big it's scrollable, sure use row, col, etc. That was my "vast majority" qualifier. For most short or medium sized loops, though, renaming "i" to something "meaningful" can harm readability. And I don't buy the defensive programming argument that you should do it anyway because the loop "might grow bigger someday". If it does, you can consider updating the names then. It's not hard -- they're hyper local variables.
      - vilos1611 9mo ago
        In a single-level loop, i is just an offset. I agree that depending on the context (maybe even for the vast majority of for loops like you're suggesting) it's probably fine. But once you nest three deep (as in the example that kicked off this thread), you're defining a coordinate space. Even in a 10-line block, i, j, k forces the reader to manually map those letters back to their axes. If I see grid[j][i][k], is that a bug or a deliberate transposition? I shouldn't have to look at the for clause to find out.
crazygringo 9mo ago
> Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case. You seem to be missing my point. It's not about improving "clarity" about the math each line is doing -- that's precisely the kind of misconception so many people have about comments. It's about, how long does it take me to understand the purpose of a block of code? If there was a simple comment at the top that said [1]: # Calculate top-left point of the bounding box then it would actually be helpful. You'd understand the purpose, and understand it immediately. You wouldn't have to decode the code -- you'd just read the brief remark and move on. That's what literate programming is about, in spirit -- writing code to be easily read at levels of the hierarchy. And very specifically not having to read every single line to figure out what it's doing. The original assertion that "This code is so literate, so easy to read" is demonstrably false. Naming something "pt" is the antithesis of literature programming. And if you insist on no comments, you'd at least need to name is something like "bbox_top_left". A generic variable name like "pt", that isn't even introduced in the context of a loop or anything, is a cardinal sin here. [1] https://news.ycombinator.com/item?id=46366341 https://news.ycombinator.com/item?id=46366341
- deleted 9mo ago
  [deleted]
- jefftk 9mo ago
  It all depends on how much context the reader has. For some audiences a comment explaining bounding boxes would be helpful; for others your example comment adds nothing that isn't immediately apparent from the code. Part of figuring out a reasonable level of commenting (and even variable naming) is a solid understanding of your audience. When in doubt aiming low is good practice, but keep in mind that this was 2D graphics software written at a 2D graphics software company.
- BowBun 9mo ago
  I think at certain calibers of work, like graphics programming in lower level languages, the best you can do is be readable and clear to others who are experts in your field. In other words, you aren't the target audience. There is likely no way to write this specific kind of code in a way that satisfies all audiences. I'm willing to concede then that the 'best' way to write this type of code is determined by the ones writing it, not us with standard views on software.

DanHulton 9mo ago

Xyz makes sense because that is what those axes are literally labeled, but ijk I will rail against until I die. There's no context in those names to help you understand them, you have to look at the code surrounding it. And even the most well-intentioned, small loops with obvious context right next to it can over time grow and add additional index counters until your obvious little index counter is utterly opaque without reading a dozen extra lines to understand it. (And i and j? Which look so similar at a glance? Never. Never!)

kaibee 9mo ago
ijk are standard in linear algebra for vector components. > (And i and j? Which look so similar at a glance? Never. Never!) This I agree with.
- eimrine 9mo ago
  What if not ijk? I know only uvw.
  - jiggawatts 9mo ago
    Pretend to be a physicist and use μ and ν.
- zeckalpha 9mo ago
  i came from imaginary numbers which were extended to make quaternions.
  - jibal 9mo ago
    i, j, k comes from FORTRAN's implicit types -- by default, names starting with I-N are integers and all other names are real.
    - jcelerier 9mo ago
      this is much older ; Joseph Fourier was already using "i" and "j" for indices in the 1800s. See page 209: https://www.google.ca/books/edition/OEuvres_de_Fourier_Th%C3%A9orie_analytique_d/safvAAAAMAAJ https://www.google.ca/books/edition/OEuvres_de_Fourier_Th%C3...
      - jibal 9mo ago
        The context is i, j, k as indices in programs. No doubt FORTRAN was influenced by prior use such as you cite. But in no case does i used as an index come from i designating an imaginary number, which is what I aimed to refute.
        zeckalpha 9mo ago
        Representing dimensions as indexable rows and columns of vectors or matrices was done on paper in the 1800s.
jonahx 9mo ago
> but ijk I will rail against until I die. > There's no context in those names to help you understand them, you have to look at the code surrounding it. Hard disagree. Using "meaningful" index names is a distracting anti-pattern, for the vast majority of loops. The index is a meaningless structural reference -- the standard names allow the programmer to (correctly) gloss over it. To bring the point home, such loops could often (in theory, if not in practice, depending on the language) be rewritten as maps, where the index reference vanishes altogether.
- vilos1611 9mo ago
  I respectfully disagree. The issue isn't the names themselves, it's the locality of information. In a 3-deep nested loop, i, j, k forces the reader to maintain a mental stack trace of the entire block. If I have to scroll up to the for clause to remember which dimension k refers to, the abstraction has failed. Meaningful names like row, col, cell transform structural boilerplate into self-documenting logic. ijk may be standard in math-heavy code, but in most production code bases, optimizing for a 'low-context' reader is not an anti-pattern.
  - jonahx 9mo ago
    If the loop is so big it's scrollable, sure use row, col, etc. That was my "vast majority" qualifier. For most short or medium sized loops, though, renaming "i" to something "meaningful" can harm readability. And I don't buy the defensive programming argument that you should do it anyway because the loop "might grow bigger someday". If it does, you can consider updating the names then. It's not hard -- they're hyper local variables.
    - vilos1611 9mo ago
      In a single-level loop, i is just an offset. I agree that depending on the context (maybe even for the vast majority of for loops like you're suggesting) it's probably fine. But once you nest three deep (as in the example that kicked off this thread), you're defining a coordinate space. Even in a 10-line block, i, j, k forces the reader to manually map those letters back to their axes. If I see grid[j][i][k], is that a bug or a deliberate transposition? I shouldn't have to look at the for clause to find out.

crazygringo 9mo ago

> Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case. You seem to be missing my point. It's not about improving "clarity" about the math each line is doing -- that's precisely the kind of misconception so many people have about comments. It's about, how long does it take me to understand the purpose of a block of code? If there was a simple comment at the top that said [1]: # Calculate top-left point of the bounding box then it would actually be helpful. You'd understand the purpose, and understand it immediately. You wouldn't have to decode the code -- you'd just read the brief remark and move on. That's what literate programming is about, in spirit -- writing code to be easily read at levels of the hierarchy. And very specifically not having to read every single line to figure out what it's doing. The original assertion that "This code is so literate, so easy to read" is demonstrably false. Naming something "pt" is the antithesis of literature programming. And if you insist on no comments, you'd at least need to name is something like "bbox_top_left". A generic variable name like "pt", that isn't even introduced in the context of a loop or anything, is a cardinal sin here. [1] https://news.ycombinator.com/item?id=46366341 https://news.ycombinator.com/item?id=46366341

deleted 9mo ago
[deleted]
jefftk 9mo ago
It all depends on how much context the reader has. For some audiences a comment explaining bounding boxes would be helpful; for others your example comment adds nothing that isn't immediately apparent from the code. Part of figuring out a reasonable level of commenting (and even variable naming) is a solid understanding of your audience. When in doubt aiming low is good practice, but keep in mind that this was 2D graphics software written at a 2D graphics software company.
BowBun 9mo ago
I think at certain calibers of work, like graphics programming in lower level languages, the best you can do is be readable and clear to others who are experts in your field. In other words, you aren't the target audience. There is likely no way to write this specific kind of code in a way that satisfies all audiences. I'm willing to concede then that the 'best' way to write this type of code is determined by the ones writing it, not us with standard views on software.