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.
> 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.
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.
To a graphics programmer this can feel like call for comments to explain that
i++
increments the loop variable. A newbie to programming might find such a comment useful, but to people who are maintaining such a piece of code that would be distracting line noise.
It all depends on who your professional peer is that you are writing the code for. It's totally fine to write for a peer who is familiar with the domain, as it's fine to write for a beginner, for pedagogy, such as in a text book.
To help understand, you need to see this code as math. Graphics programming algorithms are literally math.
You're asking for training wheels comments, which just get in the way for those who are familiar with the domain.
I'm sure a few graphics programming engineers might want calls to react useState(), useEffect(), etc. to be documented in a codebase, yet a react programmer would scoff at the idea.
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.
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!)
> 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.
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.
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.
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.
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.
Shpongle albums are split up into normal-sized tracks. Most CD players, media players, and streaming services support gapless playback of albums, at least for subscribers. When a Shpongle album is played with gapless playback enabled, it sounds like one long song.
I don't have a Spotify link handy, but here's a YouTube Music example:
All the bus/memory timings are the same with this guy's hack. So it's not a big surprise that 10 print "hello world!" :print "!" : goto 10 doesn't have any perceived performance difference. Maybe if you made a purely arithmetic benchmark in assembly that could be done all within a few registers, like Fibonacci, you might see some difference.
Fun fact: The PowerMac G5 CPU cooling fan controllers have a failsafe mode: If the OS doesn't communicate with the fan controller, the fan controller assumes the worst: that the CPU is switched into the most power-hungry mode possible. To prevent potential damage to the CPU, after about 30 seconds, the cooling fans are cranked up to extraordinarily loud levels.
Apple didn't document how to control the fans. It took Microsoft a while to reverse-engineer the fan controllers. During that time period, using the G5s as Xbox dev kits required putting up with extraordinarily loud fans.
I'll add that initial dev kits are typically released 18 months before the console launch, that means they are built using technology that is one generation behind the hardware that the actual console will use. In the old days before Moore's Law ended, that meant that the console had to have a much more expensive CPU and GPU, to try to match the expected performance of the console hardware. These days, with only marginal improvements in CPU and GPU from generation to generation, this is much less of an issue.
Pure capability-based access control, where capabilities are communicable, but not forgeable "references with rights" to objects. While this is interesting, it's not really unique: other L4 kernels also have it, and Capsicum (but not POSIX capabilities) implements something like it on Unix. But even here, seL4 has some unique twists, such as the way IPC replies are handled, which allows policies that prevent "unsolicited" replies.
A unique approach to memory management, where after boot-time, the kernel does no memory management, and even kernel memory is managed completely by user-level code. In fact, the kernel has no heap. Instead, when the user requests an operation that requires kernel memory (e.g. creating an address space, which requires memory for page tables) the user provides the memory explicitly to the kernel. This sets seL4 apart not just from monokernels, but from other L4 kernels as well.
Support for passive servers: one of the most exciting recent features, these are server processes that run on scheduler time "donated" by the client. Among other things, this can be used to make sure that non-critical clients will not monopolize services needed by critical clients.
IIRC seL4 is also the fastest L4 kernel for most use cases - and its worst-case execution time is bounded, at least on older CPUs which have published timing data.
It's at the same time pure microkernel and performant and usable in real world (not just a research project).
The memory management, scheduling and IPC are implemented in an interesting and novel way (compared to your typical mainstream OS) and allow for quite different OS design.
In particular, capability-based IPC and memory management could provide a robust base for a secure OS from the ground up, instead playing whackamole in an aging POSIXish design.
Sadly (tho I understand the rationale), most approaches to building a full OS on top of (L4 in general) are "run userspace Linux in an isolated container", which kind of ignores all the power underneath.
When the www came out I use to get there through gopher. I preferred gopher until I was able to get an ip address. The ip address made it possible to get images with text. Perviously there were separate downloads.
Welcome to the World Wide Web there is no top or bottom.
Which distinguished it from gopher.
> A forgiving text-based format that was trivial to author, serve, and display. And evolve with forward/backwards compatibility.
I'm not disagreeing, but that's certainly a less often heard characterization of SGML ;) and also, not sure evolution of the HTML vocabulary past 4.x, or lack thereof, supports this point considering there are entire universes of additional syntax such as CSS and philosophical schools of thoughts only there to avoid having to write plain markup attributes. The metaphor also is apt, since, like the universe, CSS syntax seems to expand faster than the speed of light.
The web could have plausibly existed as early as FTP did. Which would have been 1972. Plenty of documents from that era had URL-like manual links of the form "pub/foo/bar.txt at MIT-AI", and many FTP servers supported anonymous login and
were fast enough for real-time text document retrieval.
It is kind of embarrassing that it took 20 years to invent URLs and browsers.
He's covered the decline of BBBY many times in his newsletter, explaining the financial details and shaking his head each time.
His Monday April 24th, 2023 newsletter, titled "Bed Bath Moves Beyond", covers the situation once again. It ends:
"Bed Bath saw that its retail shareholders wanted to throw their money away, and that its sophisticated lenders wanted to get their money back, and realized that there was a trade to be done that would make everyone, temporarily, happy. So it did the trade. It’s amazing. The lawsuits are gonna be great."
Reddit recently announced changes to their APIs pricing and features that will probably lead to the abandonment of most third-party Reddit clients. Users of those clients are upset.
Can someone provide a tl;dr that specifically explains why this is going to harm the site? I know there were some communications problems with third party clients, but from my reading of the announcement it just sounds like they're going to start enforcing their previously documented but unenforced API rate limits on free accounts and they're providing a service to charge for bulk access. What else is changing that has everyone upset? The developers commenting from the big clients such as Apollo didn't seem to provide any info on if/how their clients would be broken. I didn't even see any comments suggesting the clients would break. It's mostly just anger about the opacity of the announcement.
I understand people being wary, especially in light of how Twitter changed their API years ago, but I'd love some more concrete info and specific complaints about this change in particular.
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.