https://doi.org/10.1145/234286.1057836.
This appears to be an error, as doi:10.1145/234286.1057836 today leads to a chapter in HOPL II for "A history of C++: 1979–1991" (and indeed the authors have linked to it under the appropriate entry elsewhere in the works cited section of this paper).
This is:
Cox, Brad J., Steve Naroff, and Hansen Hsu. 2020. “The Origins of Objective-C at PPI/Stepstone and Its Evolution at NeXT.” Proceedings of the ACM on Programming Languages 4 (HOPL): 82:1-82:74. https://doi.org/10.1145/3386332.
Git-based wikis like Gollum
by which the author means the types of wikis that aren't wikis.
The monorepo has a total uncompressed size of 69.3 GiB, a fairly substantial figure. To put things into perspective, the Linux kernel repository, known for its vastness, currently stands at 55.8 GiB.
This perhaps puts things "in perspective", but somehow in a way that the author avoids attaining the (or, if you prefer, demonstrating) the corollary self-awareness that one would expect (having had things put into perspective, and all).
Computers mediate every aspect of our lives
Now that's some solipsism.
I wish people's works were more online—more accessible (preferably, with stable, citable URLs). But to say that the people themselves should be more public in the sense that the author means here is just a continuation-without-lessons-learned of the modern (Facebook and onwards) social networking era.
It's great if all of a person's contributions to, say, mailing lists are preserved and available—and aren't just holes, missing from the record.* That's different from whether or not it's great to be able to click on that person's name, find a profile page for them, and then encounter an exhaustive, reverse chronological feed of all of their activity across all mailing lists. Mailing lists rarely enable this, but virtually every modern social network does, and they're actually built around it.
The former is topic-based indexing, and the latter is actor- (person-) based indexing. Actor-based indexing is bad, and we know that it's bad.
Actor-based indexing is like running into someone you know (or a stranger, even) at the post office and then, through some mechanism where their physical presence wired to some metaverse data source, being able to perform some tap/gesture at the virtualized floating bubble over their heads that lets you see all the public places where you would have seen them earlier that day if you had been at any one of those, and then having a log of every interaction for the day prior, and the day before that, and so on, stretching back over their entire life, including the grocery store, the restaurant, the houseparty they were at, their work, etc. This would be bad. That means it's not good. And it's not good "online", either, for the exact same reasons.
* as unfortunately, many Mastodon (and other ActivityPub-powered) interactions turn out; Mastodon happens to achieve the worst of both worlds!
Brock, Lynn: Colonel Gore's Second Case
This is available at UT PCL:
https://search.lib.utexas.edu/permalink/01UTAU_INST/3307f/alma991020623129706011
garbage-collected languages
That's "garbage-collected language implementations" (or, in this context, just "garbage collection").
Programming languages are languages. They're notation. They're inert. They can't have garbage collectors.
The presence of GC is a memory management implementation strategy—a choice—of a given programming language implementation. C, for example, is neither a "garbage-collected language" nor a "non-garbage-collected language".
GCC doesn't have a garbage collector for C programs, and neither does Clang, but GCC and Clang are not "C"; C is a programming language, and GCC and Clang are programming language implementations. You could write a C implementation in the vein of SpiderMonkey or the compiler/runtime from the golang.org toolchain (one designed to parse and run programs written C instead of JS or Go) if you wanted to.
Every time I encounter Python I know I’m about to lose an entire day in build/dependency hell.
I don't know. All I know is that any time something depends on Python I end up wasting an hour figuring out how to set up its own entire VM or some shit just to sed a Makefile.
the sense of “everyone but me is in on the joke, there is a Thing that I don’t understand myself but is the most important Thing, and I must approximate or imitate or cargo-cult the Thing, and anybody who doesn’t is bad.”
I mentioned Rhesus ladders in another comment (https://hypothes.is/a/gvP9DmJfEeyj-zfV0Z4Zsw) and also the relationship to Chesterton's fence in reply to a comment from someone else (https://hypothes.is/a/r7YFemJgEeymEnOBlFNH5A), but this captures the spirit of my comments elsewhere about false diagnoses perfectly.
Suggestion:
Given a URL, check whether a page (specified by another URL or by file upload) links to that URL, and if so where/how.
there’s no reason not to use it in HTML tools
Not quite.
The first problem is that the build breaks on non systemd systems such as macOS. Since libsystemd is not available, you cannot build from or cross compile to Linux. You must build from a Linux system.
You can, you just can't easily do it with with clang or GCC.
This is a long-standing problem with compilers that the Zig folks and the Go folks have thankfully recognized as silly and decided to approach in a different way within their respective ecosystems.
No such user.
NB: "davidy123" is vid
The latter is significantly cleaner, since the "archival" version actually uses my blog feed instead of the original HTML. The feed reader version strips out all the unnecessary display gunk
He looked at me incredulously and said, “Fortran is a compiler. It’s a computer program like any other. Only it happens to take source code as its input, and puts out machine code.” There was a long pause, then I said, “Someone wrote that program?” I was stunned. I don’t know where I thought the compiler came from — Mount Olympus, maybe?
Crenshaw's humility notwithstanding, I'm frequently caught off guard by frequent interactions with people whose conversational posture reveals that they have a similar conception of software like, say, Windows—their comments a manifestation of a seemingly total unwillingness to confront the fact that, no, some observable behavior in software isn't just how computers work, but that someone—a human programmer—sat down and decided to make it work that way—that it isn't just some natural property of computers that someone has coaxed out of one, and that other instances of software creation are not mere parlor tricks. They're procedures. They have to be conceived of and then worked out and (ideally) made airtight against a whole range of conditions.
The fact that the above SVG still works after two decades is a testament to the durability of the format.
It's rather more a testament to the durability of W3C standards generally—something that is now under attack by WHATWG member orgs.
Of all the tactics inspired by Nat Eliason, this is my favorite. As you’re writing, put “TK” anywhere you aren’t sure of a detail, or where you need to add more context later. One of the main reasons we stop writing or fall out of flow is getting stuck on some detail giving me trouble, and by dropping in a TK to come back to it later, I can maintain the flow. Why TK? Think of it as “To Come.” It reminds me to add more context later. That letter combination doesn’t appear in any English word, so when you CMD+F for it after you’re done writing, you’ll only find the instances where you used it as a place marker.
This entire section is plagiarized from Eliason. Bizarre.
unless you’re an Evan Wallace level programmer — heads up, you’re not — the only way around it is to migrate to lower-level languages with more granular memory management
This doesn't follow.
It's way easier for a mediocre programmer to tune the naive implementation of a program in order to sidestep some of the GC costs than it is for the same programmer to pick up and capably wield a "lower-level language" that requires manual memory management. Anyone with the skills to do the latter is going to be capable of the former.
I'm using typescript for my Bike Outliner 2's new extension system. It's great in every respect, except to take full advantage you need to setup a node dev environment and perform a build step.
This is the question which you should really be asking yourself when considering literate programming as a solution, because it’s the question to be asked when looking at any proposed solution. What are you trying to accomplish?
It's recursion:
Note that in addition to the followup that the author has added to this article (in Feb 2025), he has written a subsequent Tutorial on CWEB article.
The goal in writing is to write for the reader. This is hard even under the best circumstances. Rewriting literate programs enjoys the worst aspects of both rewriting prose and rewriting code.
Probably the biggest hindrance to literate program today is that no one cares about preserving knowledge. Silicon Valley tech-bros don’t care about the humanities and believe that knowledge could never be lost (and, even if knowledge were lost, who cares anyways?).
defeats the purpose
Does it defeat the purpose, or is it a form of redundancy?
When programming, it’s not uncommon to write a function that’s “good enough for now”, and revise it later. This is impossible to adequately do in literate programming. It happens a lot more with explanations, and you see this in Crafting Interpreters where Nystrom refactors portions of code into new functions. This is impossible to adequately do in Knuth’s WEB (or CWEB) approach.
I’m not sure that Nystrom was even aware of the notion of “literate programming” when he wrote his book
I would argue the only example of a successful literate program is Bob Nystrom’s Crafting Interpreters
Same.
First write the problem statement
I'm amazed by the number of programmers who, having already written down how the problem gets solved, attempt to document/comment their code and don't realize that this is what should be their fundamental concern—what problem does this solve?
This is a question that the music industry faced head-on, and they came up with EULAs
huh?
For those who don't know, Warner Bros keeps this anachronistic website online
In Rust, the tooling can answer a lot more questions for me. What type is cookie_token? A simple hover in any code editor with an LSP tells me, definitively, that it’s Option<String>.
It's common enough to wonder about function behavior on null, undefined, etc., so consider "an LSP" (read: editor plugin) that could synthesize these annotations and insert the appropriate disclosure/disclaimer at the head of the function like this.
What could be more beneficial to a user of free software than ensuring that its codebase is clean and comprehensible for study
Sheon Han proposes something similar in Wired in February 2023: Software Criticism. https://www.wired.com/story/software-criticism/
The problem with this page is that the author is playing fast and loose with the words "parser" and "parsing". It's also not totally honest (or is yet again confused) about e.g. what the IETF RFCs say about parsing high precision numbers.
The idea that the permanent record of the internet could hinge on the ethics of one stranger behind a server rack is deeply unsettling.
It doesn't. No one should be relying on archive.is to fill this role today. It's like never putting a passcode on your phone and just treating it accordingly—as an insecure/untrustworthy device—or proactively working to revoke a leaked API key as soon as you discover that it has been leaked and just assuming that a malicious actor has already come across it and is planning to put it to use even if they haven't already done anything.
It is however not being done as an open source project & there are other options out there if that's something you need your software to be. It does rely on open source libraries & a number of modified plug-ins for which their changes are being provided to comply with their code licensing requirements. Ultimately I don't want to spend the time to run a properly done open source project when there's no guarantee of any assistance vs the overhead involved & my time management isn't great so spending more time on project management isn't imho a good use of my time.
my personal experience, which is that whenever I write what I think about a subject, it always turns out that my thoughts do not hold up on paper? No matter how confident I am in my thoughts, they reveal themselves on the page as little but logical holes, contradictions, and non sequiturs.
Pre-emptive note: it seems logical that the very next paragraph references Paul Graham directly; my very next move was going to be to connect the writer's self-reported experiences here with Graham on writing, had it not been the case that that job was already done.
As I've said before: I'm not in the same boat with Graham on the writing-is-thinking stance. The difficulty with seeing my own thoughts fixed in words after an initial pass is not in their inadequacy or their being a source of illusory and fleeting comfort with said illusion now made stark for everyone to see, but a mixture of (a) a lack of "punch", and/or (b) the places where a dishonest broker could exploit the yet-to-be shored up wording to suggest/assert the presence of some weakness in thought regarding the thing being argued for, where such purported weakness would be the real illusion.
The lack of satisfaction I feel when trying to capture my thoughts in English (my first language) isn't too far off from the lack of satisfaction at being able to comprehensively express a simple declarative in another language only because of the fact that don't know, say, the right word for the noun in that language. It doesn't lead me to agonize about how well-supported my observations about a backhoe are just because I've never been introduced to the word for backhoe in that language.
I had no choice but to create a bot. Here's Secretly Public Domain
Following the demise of botsin.space (cf https://muffinlabs.com/posts/2024/10/29/10-29-rip-botsin-space/), the author evidently has the bot now posting to https://mas.to/@SecretlyPublicDomain instead.
Traveller:
You are looking for https://mas.to/@SecretlyPublicDomain.
21,441
I find it strange that this number differs from the one given on the previous page ("Totals...[…] 21,533").
Point 4.c. does indicate that "102 claims were rejected", but this is not the same the difference observed (which is 92), and it's stated that the 102 rejected claims come from "a survey [i.e. sample] of some 10,000 renewal applications".
The U.S. copyright office wrote in 1961 that fewer than 15% of copyrights from 1924-1961 had been renewed.
This is a curious claim that I cannot substantiate. After looking around, I see the same claim in Wikipedia's article for Copyright renewal in the United States, but the cited source (Fishman, Stephen; 2010. The Public Domain: How to Find & Use Copyright-Free Writings, Music, Art & More) doesn't appear to provide a robust citation. (On page 287 in Chapter 15, Fishman writes, "The Copyright Office estimates that only about 15% of pre-1964 published works were ever renewed", unaccompanied by a footnote.) One also notices that 1961 and 1964 are not the same year.
I stumble across a similar claim ("a 1961 report from the U.S. Copyright Office estimates that 85% of the books never had the copyrights renewed") on lcgsco.org, which disappointingly turns out to be the website for "Larimer County Genealogical Society", with no link to the report in question.
The Copyright Office does make available its historical archive of annual reports at https://www.copyright.gov/history/annual_reports.html. Could its annual report be the one referred to? Searching for the string "renewal" in the 1961 annual report turns up two noteworthy occurrences (out of a reported nine):
on page 2, a claim related to renewals mentioning a "15 percent" figure
on page 16, a description of "Studies 29–31 [… including …] 31. Renewal of Copyright"
The full sentence on page 2 where the "15 percent" figure appears is actually that "The year's increase in registrations was nearly 3 percent, this was counting a 15 percent decrease in renewal registrations, the result of the corresponding decrease in original regisrations 28 years previously." This is, troublingly, not the same thing as fewer than 15% of copyright registrations until 1961 being renewed. (It is not even the same as only 15% of registrations up for renewal in 1961 being renewed.) It is a 15% decrease in renewals relative to the prior year, i.e., number of renewals in 1961 compared to the number of renewals in 1960. If this is the report that the is meant to be the source for those claims of 85% non-renewal, it then it fails verification.
I have also come across a reference for renewal figures in a 2008 article in D-Lib Magazine (Peter B. Hirtle, "Copyright Renewal, Copyright Restoration, and the Difficulty of Determining Copyright Status"). Footnote 4 there cites the same Study 31 (attributed to a Barbara Ringer). Interestingly, it is not cited as a way to substantiate the 15% claim, but instead that "only 7% of registered copyrighted books" were renewed. It's not clear from context whether that claim is meant to be about the full range of potential renewals up to 1961, or merely the subset of works up for renewal in 1961.
At the time of this comment, I have not yet looked into Study 31 itself. I expect it to contain answers.
g a 15percent decrease in renewal registration
I've come across lots of claims online (e.g. https://lcgsco.org/the-majority-of-books-published-before-1964-are-free-of-copyrights/ and the current revision of the Wikipedia article on copyright renewal in the United States) that "A US Copyright Office study in 1961 found that fewer than 15% of registered copyrights had been renewed". I haven't been able to substantiate this claim, however.
Could this passage be the source? It clearly doesn't line up with the claim.
“We think there’s no normal way to act on a 911 call,” said the lead investigator, Jessica Salerno, a social psychologist at ASU. Given the gamut of human emotion, she explained, anyone claiming to know the right and wrong way to speak during an emergency has seen too much television.
It's nuts that this has to be said.
The clear hidden wink and nudge is “clearly this means she’s obviously 100% a plant from that side!” What else was said in that speech? Maybe show a whole 3-4 minutes? But that would be boring and you can’t do the whole show a fast snip and then wink wink at your audience about “aha but we all know what this really means don’t we folks!
/u/Choperollo describes something for which we have no name and would not be accurately described as a dogwhistle but still shares some similarities and is now common/prevalent enough that we would perhaps benefit from being able to refer to it by name to discuss it.
I am just a hobbist. I enjoy using the cutting edge technology and framework just for fun. Now the fun is going to cost me money. I do not make any money with my service.
This is belied by earlier admission about how he's putting the library to work, at his work (and which even uses the word "professional"!).
Tweetback looked promising but it seems to have rotted slightly. Or perhaps my node.js config wasn't in good condition? Either way it didn't work out of the box for me
Since GPLv3 split "the GPL", a lot of programmers (and companies) categorically refuse to get GPL code on them anymore.
I have not come across that. I have only come across an allergy to GPLv3 in particular. And all those companies are seemingly happy to continue shipping GPLv2(+), as the next sentence indicates re Apple.
Before this, copyleft was simple and let programmers ignore most of the legal issues around software licensing. We had a universal receiver license acting as a terminal node in a directed graph of license convertibility, and had a simple binary decision: "is this license GPL compatible or not?" If it is, treat it like the one license we're familiar with, if not ignore it. And we're done, we don't have to be lawyers. But with GPLv3, you now have to police all your contributions because "it's GPL" doesn't mean "my project can use it".
I dunno. "Is this licensed as GPLv2-or-later (or compatible)?" still works (and is really the same question that was being asked all along)—nothing really has changed (except for the proliferation of projects that are a GPL for which the relevant answer is "no"—but, still, the question didn't change).
This page is a great example of why I don't use GitLab.
WTF.
judgment
"settlement"?
a confidential resolution of all claims and will have no further public comment on this matter
Why shouldn't the resolution be available for reading at archive.org?
From an optimistic perspective:
~10 articles per month sounds like the perfect publishing pace for a blog, and more academics should be blogging.
What if the submissions to the aforementioned low-quality journals were just a bunch of 6 pagers that were actually originally intended for syndication to the author's website and also just happened to also get wider distribution in those suck journals?
And a separate question: might it be conceivable that this could turn out to be an effective way to actually bootstrap high-quality research output and a healthy ecosystem of professional/academic blogs (in the vein of the parable of the pottery class https://austinkleon.com/2020/12/10/quantity-leads-to-quality-the-origin-of-a-parable/)?
Response #1
It would be nice to be able to have good subject lines. I'm thinking that if you register your form, then you should also be able to register a template string that can be used to build a good subject line (like "Riku key request for riku@x.colbyrussell.com"—built from Riku key request for ${email}).
In my first year of college, I was biking back through campus one lovely fall day when I saw a large group of fellow students gathered enthusiastically around a truck from the California burger chain In-N-Out. Maybe they craved a taste of home. But in Michigan, where I was from, there are no In-N-Outs. I’d never heard of it. Feeling excluded from the burger party, I biked off in a huff to eat my lunch in the dining hall alone. I remember thinking, I’m not standing in line for a burger! What was my problem? As an 18-year-old, I certainly didn’t want to think of myself as feeling that I did not belong in college. And I definitely didn’t want to think that an In-N-Out truck could trigger that feeling. How ridiculous that would be.
the look of quiet mortification on his face
We all dodged a bullet
a near Jia Tan level
This is frankly a really good phishing email. Breaking it down: It greets the user personally with their NPM username. This makes it look personalized, so people are more likely to trust it. People are used to the idea of changing passwords for security. With that in mind, at a glance the idea of changing your two-factor auth credentials "for security reasons" isn't completely unreasonable. NPM has always been kinda weird compared to other open source package repositories, so them requiring something strange like that reads as reasonable. It sets a deadline a few days in the future. This creates a sense of urgency, and when you combine urgency with being rushed by life, you are much more likely to fall for the phishing link. It links to a website (I'm assuming it's on npm.help), and that website is used to get the two-factor credentials somehow and then start publishing new packages with the exploit code.
What many analyses fail to highlight is that NPM has been sending a lot of really pushy emails about two-factor authentication settings over the last couple years.
Perversely, this cargo culted best practice led to worse security.
These kinds of dependencies are everywhere and nobody would even think that they could be harmful.
Even though some of the affected versions are currently being removed from npm, some are still available. So please use overrides in your package.json.A malicious package can still be pulled in if another dependency requires a vulnerable version range. Use the overrides feature in your package.json to force a specific, safe version of any package across your entire project.
Perhaps the most irresponsible thing of the last week is that among possible mitigations, to give priority to exercising even more features of the poorly conceived package.json-based system, especially where it is redundant (but inferior) to a mitigation scheme that consists of checking the given source code revision into the revision control system.
This omission is especially absurd in relation to stuff like the has-ansi package, which hasn't had a substantial change in years.
It works as well as you’d expect an operating system to work in a browser.
The author also keeps saying "operating system" like this as a euphemism for "desktop environment" or "graphical shell", which is kind of annoying.
Often times, I’ll want to refer to different pages at the same time. So I’ll CMD + click “a couple times” while browsing around and before I know it, I have 12 new tabs open – all indistinguishable from each other because they share the same favicon.PostHog.com has the same problem – especially as the site has grown from supporting a handful of paid products to over a dozen.As I looked for ways to solve this explosion of pages, I started to question many of the typical patterns that marketing & docs websites have today.Long-form scrolling. Oversized footers. Absurd whitespace.These website encourage scrolling, but just to get people to the bottom of the page? And then what?Why are we doing this? What if we just made better ways to consume content?That’s the idea behind the new PostHog.com.
The absolute last thing I want here is to delegate decisions about interaction style and the implementation of application-level affordances to the person supplying the content.
always happy to have me on team photos to add some colour and progressiveness to the image
it was all a scam, that everyone else knew it was all a scam
Is there a word/encyclopedia entry for this? We need it.
There's some additionally complexity because of something called the "lexer hack". Essentially, when parsing C you want to know if something is a type name or variable name (because that context matters for compiling certain expressions), but there's no syntactic distinction between them: int int_t = 0; is perfectly valid C, as is typedef int int_t; int_t x = 0;. To know if an arbitrary token int_t is a type name or a variable name, we need to feed type information from the parsing/codegen stage back into the lexer. This is a giant pain for regular compilers that want to keep their lexer, parser, and codegen modules pure and plantonically separate, but it's actually not very hard for us! I'll explain it more when we get to the typedef section, but basically we just keep types: set[str] in Lexer, and when lexing, check if a token is in that set before giving it a token kind
It's strange how much appeal "the lexer hack" has for being such a bad solution to the problem.
The most reasonable thing is to just not care about whether your lexer can distinguish between whether an identifier refers to a type or to another sort of identifier. Just report that it's an identifier. In practice, this doesn't very much change how you have to implement the parser, and the symbol table can remain local to the higher-level parser machinery where it was always going to be anyway.
The lexer hack sucks.
You can see where we're going. If our goal is to minimize copying, it would be better to copy a fundamental type once than to generate a pointer, copy that, then dereference that pointer to get the underlying value. That is the crux of this subtle optimization trick.
This isn't subtle. It's intuitive and obvious, being presented as if it's non-obvious. I kept waiting for the punchline.
I guess you can get here if your main mode of thinking is dealing in opaque "best practices" like "use references because it makes your code faster".
I video taped the interview in order to document any divergences
This struck me as an obviously good idea the first time I came across something similar where Wikileaks published their recording of an interview of Julian Assange by some large news organization (who published their own copy that they owned the rights to).
we couldlearn from the history and design a better file format:• Each part of a format must be unambiguously located. Itis a bad idea to rely on fragile signature searching.• Conflicting data resolution should be clearly defined,ideally by avoiding redundant data in the first place.• Leave room for backward-compatible feature extensions.Make it clear whether an extension is enabled or not.• Fields that are allowed to be silently ignored should notcontain security-sensitive data. For example, the extrafields in ZIP should not contain filenames and sizes.
Ideally, one would (above all) maintain compatibility with at least ISO/IEC 21320-1:2015 and, as a baseline concern, follow the lead of the design of PNG and specify a means by which to identify definitively (a) whether a data block at a given offset is a ZIP-level "chunk" versus random noise, and if so (b) the extent—i.e. size—of said chunk, so that implementations know how to confidently determine the chunk boundaries to skip over them, even if they don't have intrinsic knowledge the offsets and bitwidths of the fields in that struct.
Normalize the ZIP file. To exploit ZIP parsing ambiguities,the attacker usually needs to carefully manipulate the fieldsof a ZIP file, which cannot be achieved by a regular ZIParchiver. Most ambiguities will disappear if the ZIP file isfirst extracted and then repacked. Therefore, if we care aboutonly the contents but not the integrity of the whole ZIP file,we can normalize the ZIP file by extracting and repacking itbefore processing.
This really seems like the best strategy—to ensure that Parser2 sees content the same way that Parser1 sees it, you can effectively give Parser2 Parser1's powers by having Parser1 "talk" to Parser2 by way of a specially prepared input. (It just happens to be the case that that input also looks like a ZIP archive.)
This does require some validation of the suitability for Parser1 and Parser2 to work together, but it's not any more difficult than the previous task at hand whereby you expect/require Parser1 and Parser2 to behave exactly the same for all inputs. The task is made slightly easier. And to this end, a test suite (derived from the work from this paper) could be distributed for the purpose of benchmarking implementations for compatibility matches.
This could be facilitated by the appropriate libraries/packages all being patched to support a "normalize" (i.e. "repack") operation (and for this to be the norm among all implementations) explicitly for this purpose.
there is no de facto standard
This is simply not true. The de facto standard is "the behavior of PKZIP, circa 30 years ago". Conveniently, PKZIP happens to be shareware (at least the versions of interest here). One confounding factor, as documented by Jason Summers's blog, is the difficulty of getting your hands on bonafide PKZIP originals. https://entropymine.wordpress.com/2019/07/27/will-the-real-pkz110-exe-please-stand-up/
The ZIP64EOCDR can be located based on the ZIP64 EOCDL, or bysearching for its signature
TheZIP64 EOCDL can be located by a fixed offset from the regu-lar EOCDR, or by searching for its signature
someparsers assume that the EOCDR immediately follows thecentral directory with no gap between them, and thus use thecentral directory size to determine its position
Dear wanderer:
You are looking for https://support.pkware.com/pkzip/application-note-archives.
ZIP is just not a very well defined format
The purported ambiguity in the implementor's notes is overstated. With exactly one exception, all of the concrete criticisms I've ever come across (including, unfortunately, some of the specific ones woodruffw echoed in the Astral blog post earlier this month) come down to implementors just flat-out doing the wrong thing (e.g. disregarding the central directory entirely), or, when presented with the choice of:
doing the obviously correct thing, versus
taking a really, really, really obtuse position that a particularly strained reading justifies an implementor's decision to do certain things (like trying to infer the position of the central directory instead of just using the field that is explicitly labeled for that purpose—bonus points if accompanied by complaints that the field is "redundant")
... they go for the latter, out of a seeming inability to say, "Whoops, how silly of me," and just fixing their damn (mental model and corresponding) implementation.
These design considerations meant that the ZIP standard is complicated to implement, and in many ways is ambiguous in what the "result" of extracting a valid ZIP file should be.
Not really. The correct behavior is, well, correct. There are just a lot of people who either succumb to taking (frankly bizarre) shortcuts or stubbornly insist on reading the spec the wrong way.
multiple End of Central Directory headers
This surely means "multiple End of Central Directory records". To reject archives with multiple headers would mean accepting only archives that contain a single file.
The correct method to unpack a ZIP is to first check the Central Directory of files before extracting entries
I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation
It's here: https://news.ycombinator.com/item?id=44955771
(NB: there is no more detail in the referenced comment than what is stated here.)
WE DO NOT BREAK USERSPACE
If only full-stack developers actually cared about the user who is sitting in front of a Web browser (i.e. end users) as much as they cared about the "users" of their APIs who are sitting in front of a text editor (i.e., programmers).
a server can send a header as a continuation of the previous header by adding leading whitespace
Go’s ZIP archive extraction starts looking from the start of the compressed data.
What a waste of total bandwidth and disk space everywhere.
What until you're motivated to articulate what you thought the value proposition of NPM-style build-time package fetchers actually ever was and then eventually settle into the realization of how little disk space has been saved in the whole scheme, how much bandwidth has been wasted on thousands of redundant package fetches, and the immeasurable amount of human toil and the resulting hit to the world's creative output from overlay version control systems instead of just leaving the version control to the DVCS that you're using.
There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.
Of course, this is another example where people say "JavaScript" and mean "NPM".
Git can be configured to automatically convert LF to CRLF on checkout and CRLF breaks bash scripts.
The last time I looked, around 8 years ago, of the multiple settings that Git offers wrt line endings, there was no combination of any of any of them that would do the most reasonable thing, and all of the advice and documentation around use of these settings were wrong. The best course of action was to use the defaults and just deal with it.
Image dimensions in EXIF metadata are cursedThe dimensions in EXIF metadata can be different from the actual dimensions of the image, causing issues with cropping and resizing.
It's strange that EXIF even includes such properties—what's wrong with the image's existing dimension fields?
APPNOTE section 1.4.
This section doesn't appear in all revisions of the APPNOTE. Notably, it doesn't appear in revision 1.0, nor does it appear in 6.2.0, which is the basis for the ISO standardized ZIP spec.
Python's zipfile interprets it as relative to the EOCDR
Huh? For the reasons above, I would be very, very surprised if this were true and Woodruff isn't just confused. This would make it incompatible with the vast majority (virtually all) ZIP-producing software. (Is there any implementation which actually works this way?)
Unfortunately, the ZIP specification is ambiguous about the nature of this offset: it's not described as either absolute (i.e. from the start of the ZIP) or relative (i.e. from the EOCDR's own offset).
It would take a very strained reading to end up with a misunderstanding aligning with the latter behavior (and it's very unfortunate that the "relative"/"absolute" terminology was chosen here, as where "relative" appears in the spec, it is used to mean almost the exact opposite of how it's used here—the relativity of the "relative offsets" mentioned in the spec are explicitly described as being relative to the start of the "disk" (which in almost all cases constitutes the only "disk" comprising the archive—i.e. it's the offset from the start of the file).
I don't think I've seen a single person bring up the classism inherent in dictating gentlemanly manners.
Here, or in general?
I do think about this a lot. This is a nice, succinct way to put it. (Critique, though: "classism" is not the best way to put it. For better or worse, "privilege" is probably one of the best words we have for this. Separately: Since "privilege" became a staple of common rhetoric, I've mused a lot about trying to convince people to minimize the focus on "privilege" (to avoid the familiar kneejerk reactions from those hearing it who have associated it with overuse), with the intent to be to sway people instead by speaking about privilege without actually using the word "privilege" and speaking exclusively in terms of affordances*.)
See: https://hypothes.is/a/TCB5zClKEeyrIOu9mp-5TA and tag:"privilege vs affordance". (NB: Hypothes.is doesn't linkify the tag in the preceding annotation correctly.)
find out that I didn't have the whole picture, the problem was messier than it first appeared, and there were perfectly valid reasons for the code being that way
I've tried using a hiking metaphor to describe a similar phenomenon (specifically, and perversely, as a preface when trying to explain second panel syndrome.
When you own your domain name this is trivial.
It's not. It assumes that if you have your own domain, you're also able to configure/patch the server to be an active participant in the Webfinger protocol—you can't do anything to add Webfinger support to your static site, for example. This is one reason that makes Webfinger a bad protocol.
Hence the difficulty in people seeing the point of getting Solid for just one app.
I explained in a post to Mastodon somewhere that the issue lies in trying to sell, to users, the infrastructure.
For Solid to succeed, it needs to get into the hands of people, and to get into the hands of people, it needs an app that incidentally uses Solid—you're never going to convince the majority of end users to adopt Solid on its merits. They need to experience it—something that TBL should be acutely aware of, since this is what drop adoption of the WWW.
Students read each sentence out loud and then interpreted the meaning intheir own words—a process Ericsson and Simon (220) called the “think-aloud” or “talk-aloud” method. In this 1980 article, the writers defend thisstrategy as a valid way to gather evidence on cognitive processing.
Speaking (or typing, as in the case of transcription) has a substantially negative effect on my ability to process the same amount of information as silent reading.
Later, the authors of this paper state that subjects who were "uncomfortable" with reading out loud had the option to read silently.
I don't doubt the conclusions of the paper, but I suspect that reading aloud actually has a deleterious effect, especially for those who are performing the act of reading without showing signs of having achieved the comprehension desired.
I use a jekyll/CI/static hosting workflow, and even though I make a zillion git commits a day, somehow branching, editing, PRing, and merging one to my website seems like friction.
This is at the root of the infamous "Blogging vs. blog setups" comic https://rakhim.org/honestly-undefined/19/.
The fact that this is true is also the entire basis for wikis. It is reasonable to find it irksome that people, perversely, refer to Git repos full of Markdown documentation as "wikis"—which they aren't. They are fully the opposite.
I don't think the current affinity for third-party dependencies is particularly harmful
You should. It is.
I feel betrayed that hype did not lead me to Java sooner. Java is fun to write, productive, and gets an unfair reputation among new developers as a dinosaur.
See also lkesteloot's Java for Everything.
However, the high-quality, widely-available free software that is most likely to get beginners hooked on programming – to turn users into programmers – are almost always written in a UNIX style. That's why my article focuses on this culture.
Note that while this isn't true now in 2025, it wasn't exactly true in 2013 when this post was written, either. Eclipse, IntelliJ, and NetBeans are all popular IDEs that were free and (in both senses) at the time this post was written.
This is:
Guo, Phillip. 2013. “The Two Cultures of Computing.” Blog. December. http://pgbovine.net/two-cultures-of-computing.htm.
How about we use Python to process real-world data and then draw a few charts? Okay sure, let's fire up our trusty 1960s-era text editor (not Microsoft Word) and write some code. Wait, first we need to install the proper add-on libraries such as NumPy and Matplotlib. [an hour of troubleshooting later, especially for Windows users ...] Okay, let's write some code. [type, type, type] Yeah, isn't this fun and intuitive? Python makes it all so easy ...
Note how the Select declares the property id="lines". That makes lines a reactive variable.
That's a strange way to put it. Surely this makes lines refer to the Select element—and the properties (such as lines.value below) are just natural, first-class properties of that element?
If not, and there's something else going on here, that's an unforgivable overloading of the "id" attribute, which is already intrinsically significant in XML for orthogonal purposes. This needs to go.
You shouldn’t need a React-savvy front-end developer to help you make routine changes to your site.
Yeah. Web authoring is really just desktop publishing—except in its current state, foiled by the JavaScript industrial complex.
the JavaScript industrial complex
Great turn of phrase, but it's weakened by the choice to shoehorn React in as a dependency.
These annotations com from the use of https://github.com/dwhly-proj/DailyJournal which sends you an email, waits for your reply, then posts it as a top-level annotation targeting the dummy URL http://my.journal and tagged with DailyJournal.
Our video annotation capability works for public YouTube videos that have either human or machine-generated transcripts. The video you’ve selected does not have one or is a private video or is not a YouTube video.
@dwhly docdrop.org is broken.
I declare that IMGUI performance is pretty gosh darn good! Some readers might have predicted IMGUI to be significantly worse as RMGUI. Instead we see numbers that are in the same ballpark.
Maybe, this is true, but it's not a conclusion we can draw from these tests. In choosing programs to benchmark, he selected notorious behemoths to pit against the IMGUI set—which, it should be noted contains stuff like Dear ImGui and EGUI, which aren't even apps.
And later, in the Windows benchmarks, he shows that the two apps—the only apps—in the IMGUI set actually perform worse than the others. The fact that RAD Debugger has a heavier power draw than clunky Electron apps of all thinks like VSCode should be considered evidence conclusive in the other direction.
@58:18
I'm very anti- this whole, like, NPM thing that happened where all these web people like— not only is their program like not a mathematical object, it's like defined by things not even on their computer—out in the world that might change at some point or go away. That's the worse possible reality, and so I think you want in source control, ideally, everything that you're using.
Software interfaces are much too rigid for that. I vaguely remember Alan Kay speaking about more lenient interface mechanisms - if anyone has a reference to share, please leave a comment!
Kay has certainly spoken about such things (albeit not to my knowledge in any way that illuminates a generalizable approach that solves the problem). I'll elide a reference to anything specific (and the prerequisite side quest to track it down), and instead include a reference to Sussman at Strange Loop: We Really Don't Know How To Compute
the few we have impose unpleasant restrictions
NB: Unpleasant restrictions consist of things like, "You cannot read files from the user's local disk outside the file(s)/folder(s) that the user has given the software permission to access, and the person who authored it can't write to arbitrary locations on the user's disk"—both of which are imminently reasonable (and relate to things which you would hope would go one to be addressed (and the quicker, the better) if it were the case that the environment didn't already provide protection against these sorts of things).
This is more like an earthquake destroying a house than like fungi or bacteria transforming food
Relatedly, Brad Cox quibbles about the inappropriate application of the word "maintenance" to these situations.
What I call software collapse is what is more commonly referred to as software rot: the fact that software stops working eventually if is not actively maintained. The rot/maintenance metaphor is not appropriate in my opinion because it blames the phenomenon on the wrong part. Software does not disintegrate with time. It stops working because the foundations on which it was built start to move.
both sides
Third option: acknowledge that you chose the wrong foundations to build upon, and just because the present structures have proven to be (what I'd have argued was a predictable) failure, that that doesn't mean that there is no foundation upon which these things can be built while delivering the sort of stability desired.
What is also sorely missing is a straightforward way to package an application program with all its dependencies in such a way that it can be installed with reasonable effort on all common platforms.
Assuming the "common platform" is something reasonable (i.e. depends only a runtime that can be expected to be present on all machines) this is as straightforward as zip -r ./package.zip research/.
(The problem isn't figuring out how to do it. It's getting people to stop sleepwalking along with all the "best practices" that are outright inimical to the reproducibility/replicability goals. Almost everyone—including to an extent the author of this post—is unwilling to cast aside their attachments.)
function Shop() { this.construct = function
Even before class declaration statements appeared in ES6, this was the wrong way to define methods.
AbstractBuilder is not used because JavaScript does not support abstract classes
Sure it does.
More work is clearly required. But it will only happen if larger parts of the scientific community agree that it is worth doing
Yeah. It's a major social problem. Not so much a technical one.
Outside of science, approximately nobody cares about reproducibility.
Now let's consider two popular recipes for reproducibility
Imagine if there were a readily accessible World Wide Wruntime that anyone with any commodity computing device could use to run arbitrary code (and its corresponding documentation) written by other people...
Alice: I couldn't compile your code. Look at this error message! Bob: It works for me! You use Debian 12? I still run Debian 9. That's surely what makes the difference. But I also have good news: I managed to run your code on my machine. The only problem is that... I get 0.8 nm. Alice: I use libode version 3.4. The documentation says it must be compiled with gcc 10 or later. You probably have an older gcc. Bob: Uhhh... Well... I will have to install a virtual machine with Debian 12, and you with Debian 9. Shall we meet again in a week?
Proposal for a much more interesting piece of writing: "The Sacrifices We Choose Not To Make"; cf:
Everything I write in these posts will be a normal, 64-bit, Windows program. We'll be using Windows because that is the OS I'm running on all of my non-work machines
Terrible pedagogy.
It's trivial for someone who has only a single device to get their hands on a Linux image and run it in a lightweight VM if they're coming from Mac or Windows. The preceding sentence doesn't hold true for any other permutation of { Linux, Mac, Windows }.
paying a hundred bucks a month
Yeesh.
Many JavaScript websites will advise you to never use the “==” and “!=” JavaScript operators, because when they compare variables containing different data types, JavaScript will coerce one of the operands to a matching type, sometimes in unexpected ways. We can thank the early days of JavaScript for this feature, when it was trying to be extraordinarily forgiving of sloppy code. I’m not going to list all the odd results that can arise from JavaScript’s operand coercion, because there are more than enough examples on the web already. To avoid unexpected type coercion, and thus unexpected matches and/or mismatches, the usual advice is to always use strict equality operators (“===” and “!==”). I disagree.
This is part of a deeper instinct in modern life, I think, to explain everything. Psychologically, scientifically, evolutionarily. Everything about us is caused, categorised
We have a word "pathologize" for this, but the author doesn't use it anywhere in this piece. The general thrust behind the word's existence was an implicit understanding that to pathologize X is generally the wrong approach to trying to explain or address X. Because it doesn't really explain anything—you just sort of bottom out (or hit a wall, pick your metaphor); it operates on the same principle behind the degenerate behavior that Feynman observed and criticized about how people think that knowing the name for something is a substitute for understanding that thing, or, when asked to explain magnets, he asked the questioner what they thought they were asking and explained that there's really not an answer (of the sort they thought they wanted) for anything else that they think they understand better than magnets but didn't ask about.
Apps reacting Let's check how different applications react to this file.
It's notable that the author left out the canonical implementation (PKZIP).
I'd also expect them to have at least tried to test the ZIP support in Mac OS Finder and the Windows shell.
technically both the offset of the Central Directory and the size of the Central Directory are redundant when you consider that the End of Central Directory Record should be, well, at the end of the Central Directory. In a proper ZIP file the following equation should be true: position_of_EoCDR - size_of_CD == offset_of_CD
Not true—they're not redundant; it is not correct to assume that this relation holds.
The only correct way to compute the offset is to use the field with information about the offset. It is not correct to do otherwise.
Our next step is to open source the codebase (Q3 2024).
The drive-through-only design gets rid of spaces that don't directly generate revenue.
The URL for this page (https://www.beet.tv/2009/10/webs-inventor-sir-tim-bernerslee-double-backslashes-were-unnecessary.html) betrays the author's (editor's?) inability to grasp what TBL says even while they are the ones trying to piggyback off his comments for attention.
[…] People on the radio are calling it "backslash backslash"[…]
I’ve been unable to obtain a .txt form of the source code
Apart from the formatting characters, this should be easy to do—the simplest OCR to ever implement.
I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust
Interesting outcome. Rarely (basically never) do you see "it's more verbose to write in $LANG2 what would be written in fewer lines if you were using $LANG1" touted as a positive.
for example
missing comma here
URI (Uniform Resource Identifier)
Ibid.
that people use as Web addresses
"Web address" is so awkward as a term. Better to just make it concrete, anyway, by providing a familiar example like "The URLs that appear in the address bar in a Web browser […]".
<Bob> <is a> <person>. <Bob> <is a friend of> <Alice>. <Bob> <is born on> <the 4th of July 1990>. <Bob> <is interested in> <the Mona Lisa>. <the Mona Lisa> <was created by> <Leonardo da Vinci>. <the video 'La Joconde à Washington'> <is about> <the Mona Lisa>.
The syntax highlighting here is very strange. It seems to follow the rule that the first atom inside a set of angle brackets is bold, and the subsequent atoms (if any) are not.
This ability to have the same resource be in the subject position of one triple and the object position of another makes it possible to find connections between triples
There's probably a better way to put this.
the Mona Lisa is the subject of one and the object of two triples
The natural way to phrase this would be "the subject of one triple and the object of two". (There should probably be a "both" thrown in there, too, to make the sentence structure even more predictable.)
Allows for code to become “portable” between files since the code can carry most of its external dependencies inside of itself, making refactoring a bit easier.
Making it easy for newcomers to understand where certain functions are coming from.
This is an underrated (actually undervalued) affordance in any codebase.
The two following snippets are completely equivalent in function
Do they emit the same code?
three
* 1.5504
regular changes in the ReadTheDocs build setup also required regular time investment on our part to make things work
D’s static reflection and code generation capabilities make it an ideal candidate to implement a codebase that needs to be called from several different languages and environments (e.g. Python, Excel, R, …). Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it. With D, none of that is necessary.
including 10s to download the crates every time
What are overlay SCMs supposed to actually achieve again?
When I try to imagine what an optimistic far future will be like, say 100 or 200 years from now, my best answer so far is, “like today but more evenly distributed.”
This is a better, but more verbose way to state what I summarized as "evenly distributing yesterday's future".
they’re scrappy personal tools
This belies the inevitable would-be justifications for the technology choices behind these projects.
Upgrading tools would frequently break compatibility with existing data. And it was difficult to make different tools interoperate if they couldn’t agree exactly on the format of their underlying JSON data.
Why should the app even know let alone care about which version of the serialization format is in play?
if the user knows a little bit of JavaScript, they can tweak user scripts written in Tampermonkey directly in the browser
I'm confused about why this namechecks a proprietary clone of Greasemonkey instead of just, you know, mentioning Greasemonkey.
Malleable software does not imply everybody creating all of their own tools from scratch.
This is a superfluous clarification.
(Maybe if it appeared nearer to the earlier discussion of situated software?)
"Malleable software" implies the opposite, right on its face.
Modifying a serious open source codebase usually requires significant expertise and effort. This applies even for making a tiny change, like changing the color of a button . Even for a skilled programmer, setting up a development environment and getting acquainted with a codebase represents enough of a hurdle that it’s not casually pursued in the moment.
every layer of the modern computing landscape has been built upon the assumption that users are passive recipients rather than active co-creators. What we need instead are computing systems that invite every user to gradually become a creator.
Is "creator" the right word here? There's lots of software that falls outside of what is the subject of this paper that enables creators. Indeed, it has been a common refrain in criticisms of the FOSS movement that for the types of software that creatives need and/or simply desire to use the proprietary apps tend to have no equals.
The requirements were driven by the needs of their specific department, not the needs of every doctor in the country.
See situated software.
To do our best work and live our best lives, we need spaces that let us each express our unique potential.
live our best lives
it("basic reviver with multiple features"
At this point, when you're writing things like this, it's worth re-examining what in the hell you've got all this stuff underneath that you don't even understand and you're certainly not using correctly.
"It basic reviver with multiple features"? That makes no sense.
model recovery
Great term of art for e.g. scraping.
All languages considered fully object-oriented feature encapsulation,polymorphism, and inheritance.
Inheritance seems to be the odd item out in this list—inheritance is not essential for OO.
It is easy to see how interchangeable parts could help in manufacturing.But manufacturing involves replicating a standard product, whileprogramming does not. Programming is not an assembly-line business buta build-to-order one, more akin to plumbing than gun manufacturing.
It's strange that there is a ready metaphor that isn't used—
The practice not of manufacturing parts (which is readily automated), but the labor that goes into designing the machines that enable the automation but for which there is no known way to automate the design work itself.
, “No Silver Bullet Revisited ,”American Programmer Journal (November 1995),http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/
As I mentioned in another annotation, Cox's article in American Programmer was actually published with the title '"No Silver Bullet" Reconsidered'.
It appears that we have few specific environments (factory facilities) forthe economical production of programs. I contend that the productioncosts are affected far more adversely by the absence of such anenvironment than by the absence of any tools in the environment… Afactory supplies power, work space, shipping and receiving, labordistribution, and financial controls, etc. Thus a software factory should bea programming environment residing upon and controlled by a computer.Program construction, checkout and usage should be done entirely withinthis environment. Ideally it should be impossible to produce programsexterior to this environment…Economical products of high quality […]are not possible (in most instances) when one instructs the programmer ingood practice and merely hopes that he will make his invisible productaccording to those rules and standards. This just does not happen underhuman supervision. A factory, however, has more than humansupervision. It has measures and controls for productivity and quality.18
Hsu again cites only Mahoney for this, and the passage here is presented as one quote, but it's actually a quote within a quote: first Bemer and then Mahoney. The original Bemer quote ends with the second sentence ("I contend that the production costs are affected far more adversely by the absence of such an environment than by the absence of any tools in the environment…" which ends prematurely here but ends with a parenthetical "e.g. writing a program in PL/1 is using a tool"), and the remainder is Mahoney's commentary.
The Bemer source is:
R.W. Bemer, "Position Paper for Panel Discussion [on] the Economics of Program Production", Information Processing 68, North-Holland Publishing Company, 1969, vol. II, p. 1626.
yet in spite of,but possibly precisely because of this, becoming the most widely used object-orientedprogramming language in the industry,8 thus making it the most likely OO language ofchoice for managers
This is such a strange thing to see in a paper from 2009.
The source cited as support is a book from 1995.
Some might find this example hard to believe. This really occurred in some code I’ve seen: (defun make-matrix (n m) (let ((matrix ())) (dotimes (i n matrix) (push (make-list m) matrix)))) (defun add-matrix (m1 m2) (let ((l1 (length m1)) (l2 (length m2))) (let ((matrix (make-matrix l1 l2))) (dotimes (i l1 matrix) (dotimes (j l2) (setf (nth i (nth j matrix)) (+ (nth i (nth j m1)) (nth i (nth j m2))))))))) What’s worse is that in the particular application, the matrices were all fixed size, and matrix arithmetic would have been just as fast in Lisp as in FORTRAN. This example is bitterly sad: The code is absolutely beautiful, but it adds matrices slowly. Therefore it is excellent prototype code and lousy production code.
Strong Python vibes.
This article was originally published in 1991.
Specifically, it's:
Gabriel, Richard P. “LISP: Good News, Bad News, How to Win Big.” AI Expert 6, no. 6 (1991): 30–39.
all too late I read a paper that explains why the Web beatXanadu. Its an article by Richard Gabriel and written in 1987 and called 'Good News, Bad News, and How to WinBig, and Why the Thing that Does the First 50% Flashilly Wins'
Wikipedia says it was written in 1989. Gabriel says it was published in 1991. Presumably the latter refers narrowly to the actually publication when it was cut down to 9 pages for AI Expert in June 1991.
Ted is referring to the "The Rise of Worse Is Better" section that appears in the version published on Gabriel's site but that was simply called "Worse is better" in the version that AI Expert published.
The header image here doesn't load. But I made sure that it was archived. If and when Medium stops syndicating this article, you can find a copy of the image that was used here:
See this note for the same essay, only qualified by Guo's UCSD subdomain instead of his personal one:
This is:
Gabriel, Richard P. “LISP: Good News, Bad News, How to Win Big.” AI Expert 6, no. 6 (1991): 30–39.
... and a copy (in HTML) can be found at https://www.dreamsongs.com/WIB.html
No Silver Bullet Revisted American Programmer Journal
Note that the actual title as it appeared in the American Programmer Journal is «"No Silver Bullet" Reconsidered».
“because I said so”
Irony (cf https://hypothes.is/a/BeEXTkk3EfCERutnCr7MPw)
Get them to buy into the fact that bullshit (read: diagnosing and debugging weird things) is a part of life in the world of computers.
No.
From Ted Nelson's "Computer Lib Pledge":
- The purpose of computers is human freedom.
- I am going to help make people free through computers.
- I will not help the computer priesthood confuse and bully the public.
- I will endeavor to explain patiently what computer systems really do.
- I will not give misleading answers to get people off my back, like "Because that's the way computers work" instead of "Because that's the way I designed it."
- I will stand firm against the forces of evil.
- I will speak up against computer systems that are oppressive, insulting, or unkind, and do the best I can to improve or replace them, if I cannot prevent them from being bought or created in the first place.
- I will fight injustice, complication, and any company that makes things difficult on purpose.
- I will do all I can to further human understanding, especially through the new visualizing tools of interactive computer graphics.
- I will do what I can to make systems easy to understand, interactive wherever possible, and fun for the user.
hopefully you recognize the other kinds of “bullshit” a researcher will encounter: weird pseudo-code in a paper with parameters that seem defined by magic that you need to implement, or pieces of code that need to be extracted from something else, or someone’s ill-documented source code that worked yesterday but doesn’t today. If you live at the edge, you need to learn how to deal with bullshit. The general coping skills that let you deal with the bullshit, as well as specific computer-science coping skills, are hard to come by. If these aren’t taught early, in relatively low-stakes, easy-to-fix environments, it will only be worse later on.
Guo's addendum (mentioned in an earlier annotation) addresses this: so many readers seem to have come away from Guo's piece with weird assumptions that he's not in the process of trying to teach his student any of this stuff and that he is instead just trying to set things up for them. That's not what he's doing, and that's not what upsets him.
Scientific progress is made by building on the hard work of others and that, unfortunately, requires a certain perseverance.
What of the lack of perseverance of "the others"—to contribute their work in a way that can be integrated? Wouldn't it be a lot more productive if everyone aimed their perseverance at dealing with the problems that fall out of their own contributions—work that they are intimately familiar with—rather than trying to grapple with problems in N of the M components that they are building on and don't have the same level of familiarity—and for this effort to be duplicated by everyone else trying to build on top of it, too?
research is about the long game
Indeed—which should really cast the norms around scientific computing in stark light as being clearly the wrong way to go about doing things. (Which itself isn't to say that there's anything special about scientific computing here—there are plenty of programmers (working on open source or otherwise) that get things just as wrong. Most of them, even. It's virtually everyone.)
It is inevitable because we work with other people who are not software developers who have been trained in the best possible procedures.
This doesn't nail it either. There are lots of people who are software developers who have (or at least have been told or have convinced themselves) that they have been trained in the best possible procedures. Adar obliquely acknowledges "open-source developers", but in a strange way that seemingly implies software endeavors that aren't FOSS are better "incentivized to keep documentation up to date or the software running".
The problem isn’t that there is some magic invocation that makes this work, the problem is that the next thing you download will need (what looks like) a completely new magic invocation.
My initial reaction was to the "This is inevitable" part that follows, before backing up and focusing on this sentence, to which my response was originally going to be, "Is it? No, it isn't." That is, until I skimmed Guo's addendum/update (which I'd never seen before) in one of the two copies I kept of the piece which this piece by Adar is a response to. And indeed, it seemed, based on a surface-level reading of that addendum that Guo largely agreed. But then a close reread of that proves that there isn't any explicit or implicit agreement on Guo's part about the diagnosis offered here. And I don't think the diagnosis is correct.
And now to focus on the next part:
This is inevitable. It is inevitable because
I don't think it is. (If nothing else, it hasn't been proven.) Even from the perspective of the author, this falls squarely in the "accidental complexity" versus "essential complexity" bucket.
(And to pick up a thread of mine from earlier this year, I wonder if we have perhaps made a mistake in focusing too much on the notional of incidental (or "accidental") versus inherent (or "essential") complexity, and whether or not we should be trying to address the fact of incidental versus intentional complexity—which surely exists. And that isn't to say that's the culprit everywhere, but to reiterate: it surely exists and surely accounts for some of what's going on.)
If you look at most learning objective frameworks you’ll find that there’s a spectrum from the factual (type “git clone”), to procedural (if you see this error message, make the following fixes; if you see this other error message, make these other fixes)
I don't see how the examples offered are helpful in conveying the distinction. The instruction to "type git clone" seems procedural.
Based only on my inference of what is actually intended by "factual" versus "procedural" (without first checking the link here), I'd guess that, "The command for copying a Git repository's contents to the local machine is git clone" would be a real example of a factual (versus a procedural) lesson style.
My initial reaction was to the "This is inevitable" part that follows, before backing up and focusing on this sentence, to which my response was originally going to be, "Is it? No, it isn't." That is, until I skimmed Guo's addendum/update (which I'd never seen before) in one of the two copies I kept of the piece which this piece by Adar is a response to. And indeed, it seemed, based on a surface-level reading of that addendum that Guo largely agreed. But then a close reread of that proves that there isn't any explicit or implicit agreement on Guo's part about the diagnosis offered here. And I don't think the diagnosis is correct. And now to focus on the next part: This is inevitable. It is inevitable because I don't think it is. (If nothing else, it hasn't been proven.) Even from the perspective of the author, this falls squarely in the "accidental complexity" versus "essential complexity" bucket. (And to pick up a thread of mine from earlier this year, I wonder if we have perhaps made a mistake in focusing too much on the notional of incidental (or "accidental") versus inherent (or "essential") complexity, and whether or not we should be trying to address the fact of incidental versus intentional complexity—which surely exists. And that isn't to say that's the culprit everywhere, but to reiterate: it surely exists and surely accounts for some of what's going on.)
Too meta, too messy, too personal, and too much detail.
(NB: this actually comes from export of my annotation of Eytan Adar's piece "On the Value of Command-Line “Bullshittery”" originally published on Medium. See https://hypothes.is/a/zmhLwkkqEfCyyo_A6dOGrw for the original annotation. I used the aforementioned export to annotate the annotation—i.e., to add a true, first-class (though perhaps second-rate) annotation, rather than a reply.)
A major purpose of this style is Malleable Software, or software that is more supportive of change, reusability, and enhancement.
Is this the first occurrence of this term?
LLMs can write a large fraction of all the tedious code you’ll ever need to write. And most code on most projects is tedious. LLMs drastically reduce the number of things you’ll ever need to Google. They look things up themselves. Most importantly, they don’t get tired
Does this mean arguments against verbose "boilerplate" languages are going to be given less credence?
Previously, however, the GUID (being the URL) changed too
So why not just stop doing that? None of the churn was necessary.
“The goal for all the reverse logistics stuff,” says Roberson, “is to keep things out of the landfill.”
But algospeak isn’t just a communications issue: It’s a labor issue. The people who truly live and die by algorithmic ranking choices are the people whose ability to put groceries on the table is directly tied to whether a social media platform suppresses their videos or text.
Pfft. Lame.
without welfare
The earlier breakdown involved being dependent on the bus for transportation into the city and relying on the library for entertainment. Is the bus subsidized? Is the library?
there are ways to purchase bulk food at cost through their channels that can lower one’s food bill to laughably low levels — my wife and I presently spend perhaps $300 per month on food
Before I got to the end of this sentence I was expecting to see something like $70 per person.
$300 per month on food is "laughably low"? You can eat cheaper in the city!
They’d merely need to content themselves with a manner of living that would be more in line with that of their own great-grandfathers than the life so often depicted on reality television, TikTok, Instagram, and whatever else.
Quintessential boomer shit.
both conventional solitary tools toenhance their personal productivity, and a newclass of facility, coordination tools4, to address thecoordination problems which develop when largen u m b e r s of individuals need to cooperate on ac o m m o n task
Interesting problem decomposition with shades of Engelbart re https://dougengelbart.org/pubs/papers/scanned-original/1960-augment-133181-Special-Considerations-Individual-re-Information.pdf.
Hey, traveler. You're looking for https://dl.acm.org/doi/pdf/10.1145/948093.948095.
For example, the syntactic analysis stage builds a conventional expression tree, but this tree is expressed as objects—instances of various classes relevant to compilation: Class, Method, Message, Selector, Argument, etc. […] The code for these operations is encapsulated inside each object, and is not spread throughout the system so changes are easily made. And all these specialized classes rely heavily on reusable code inherited from more primitive classes like Object, HashTable, Symbol, Token, and LinkedList.
This is an interesting claim, given that one of the common criticisms of the classic, inheritance-heavy style of classic OOP is precisely that it leads to code that is indeed "spread throughout". Adele Goldberg commenting on the legacy of Smalltalk made a well-known quip, "In Smalltalk, everything happens somewhere else."
It's notable that although there many common word sequences between this paper and the later, similarly titled one that appeared in IEEE Software (1984), this passage doesn't appear to be present (based on a quick skim—I could be missing something), and the closest corresponding statements are significantly reworded.
This is:
Cox, Brad J. “The Message/Object Programming Model.” In Proceedings of Softfair: A Conference on Software Development Tools, Techniques, and Alternatives, 51–60. Arlington, VA: IEEE Computer Society Press, 1983.
In Hints and Principles for Computer System Design, 2020, Lampson describes his original 1983 paper (https://dl.acm.org/doi/10.1145/800217.806614) as being "[r]eprinted with some changes in IEEE Software".
This is:
Lampson, B.W. “Hints for Computer System Design.” IEEE Software 1, no. 1 (January 1984): 11–28. https://doi.org/10.1109/MS.1984.233391.
Programs Are Models That RunPrograms have much in common with models, in particular they are abstractions of a system that makecertain properties explicit and hide, or abstract away, other properties. But programs have a specialproperty that most kinds of models do not – they can automatically produce the actual computation theymodel.
detailedfunctional descriptions of hardware tothe extent that the instruction set of thecomputer can be emulated
This presupposes that you'd settle on opaque sequential blobs of said instructions as the preferred archive format—a consequence of the cultural milieu of the writer, and not the product of careful thinking and logical decisionmaking.
A common measurement of code bulk is to count the number of lines of code, and a common measure for software productivity is to count the number of lines of code produced per unit time. These numbers are relatively easy to collect, and have actually demonstrated remarkable success in getting a quick reading of where things stand. But of course the code bulk metric pleases almost no one. Surely more than code bulk is involved in software productivity. If productivity can really be measured as the rate at which lines of code are produced, why not just use a tight loop to spew code as fast as possible, and send the programmers home?
The modern incarnation of the fallacy of bulk-is-better is judging the quality of a project (esp. a component) by being overly concerned with whether it is more or less "active" than some other project.
The question posed here is an obvious response for when you encounter instances of the bulk-is-better mindset (although it's not as easy to automate as Cox suggests here).
I've often mused about the thought of pulling a Reddit* and automating some level of churn within a codebase for a project that's hosted on e.g. GitHub for the sole purpose of making sure that it appears "active".
* A story about the early days of Reddit has become well-known after the creators volunteered some information about the early days when they made use of a bunch of "fake" accounts to submit links that the creators had aggregated/curated for the purpose of seeding the site.
Although many of the hypotheses in this field are unproved
Are they even well-formed hypotheses? That is, are they falsifiable?
Most would agree that software productivity is low; lower than we'd like certainly, and probably lower than it needs to be. It is harder to agree what productivity is, at least in a quantifiable sense that would allow controlled experiments to be defined and measured scientifically. What is software productivity? Or much the same thing, How do you measure it? In measuring something, one hopes to understand the factors that influence it, and from these to discover ways to control it to advantage. This is the goal of Software Metrics, the study of factors influencing productivity by measuring real or artificial software development projects.
Software does not need dusting, waxing, or cleaning. It often does have faults that do need attention, but this is not maintenance, but repair. Repair is fixing something that has been broken by tinkering with it, or something that has been broken all along. Conversely, as the environment around software changes, energy must be expended to keep it current. This is not maintenance; holding steady to prevent decline.