3,334 Matching Annotations
  1. Last 7 days
    1. 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 }.

  2. Jul 2025
    1. 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.
    1. 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.

    1. 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.

    2. 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.

    1. 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"[…]

    1. 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.

    1. 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.

    1. for example

      missing comma here

    2. URI (Uniform Resource Identifier)

      Ibid.

    3. 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 […]".

    4. <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.

    5. 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.

    6. 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.)

    1. 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.
    2. Making it easy for newcomers to understand where certain functions are coming from.

      This is an underrated (actually undervalued) affordance in any codebase.

    3. The two following snippets are completely equivalent in function

      Do they emit the same code?

  3. Jun 2025
    1. 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.
    1. 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".

    1. they’re scrappy personal tools

      This belies the inevitable would-be justifications for the technology choices behind these projects.

    2. 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?

    3. 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.

    4. 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.

    5. 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.
    6. 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.

    7. The requirements were driven by the needs of their specific department, not the needs of every doctor in the country.
    8. To do our best work and live our best lives, we need spaces that let us each express our unique potential.
    9. live our best lives
    1. 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.

    1. 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.

    2. 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.

    3. , “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'.

    4. 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.

    5. 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.

    Tags

    Annotators

    1. 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.

    2. 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.

    1. 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.

    2. 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:

      https://web.archive.org/web/20250614131832/https://miro.medium.com/v2/resize:fit:640/format:webp/1*WmQCEd5vo4ijVXrThaFSlA.png

    3. See this note for the same essay, only qualified by Guo's UCSD subdomain instead of his personal one:

      https://hypothes.is/a/22JaWMu5Eey2UvchosEz6Q

    1. 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

    1. 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».

    1. “because I said so”
    2. 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.
    3. 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.

    4. 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?

    5. 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.)

    6. 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".

    7. 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.)

    8. 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.

    1. 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.

    2. (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.)

    1. 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?

    Tags

    Annotators

    1. 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?

    1. Previously, however, the GUID (being the URL) changed too

      So why not just stop doing that? None of the churn was necessary.

    1. “The goal for all the reverse logistics stuff,” says Roberson, “is to keep things out of the landfill.”
  4. May 2025
    1. 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.

    1. 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?

    2. 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!

    3. 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.

    1. 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
    1. 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.

    2. 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.

    Tags

    Annotators

    1. 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".

    2. 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.

    1. 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.
    1. 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.

    1. 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.

    2. Although many of the hypotheses in this field are unproved

      Are they even well-formed hypotheses? That is, are they falsifiable?

    3. 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.
    4. 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.
    5. The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies.

      It's strange that this basic truth is something that has to be taught/explained. It indicates a failure in analytical thinking, esp. regarding those parts of the question which the quoted passage is supposed to be a response to.

    6. That dependency gets checked into your source tree, a copy of exactly the version you use. Ten years later you can pull down that source and recompile, and it works

      In other words: actually practicing version control.

    1. Zulip is just snappy. It’s not bulky like Slack or Matrix.

      I'm baffled how much mindshare Matrix was evidently able to gain (and maintain) given how crummy it is as a product and frustrating to use.

    1. This is:

      Cox, Brad J. “Message/Object Programming: An Evolutionary Change in Programming Technology.” IEEE Software 1, no. 1 (January 1984): 50–61. https://doi.org/10.1109/MS.1984.233398.

    Tags

    Annotators

    1. Mary Shaw's Towards and Engineering Discipline of Software

      The actual name of the paper referenced here appears to be "Prospects for an Engineering Discipline of Software". "Towards an Engineering Discipline of Software" is the last chapter/section.

    1. Consider a derivative: Slim Source Code

      … in the context of the problem described in "The Cost of Selective Recompilation and Environment Processing" (Adams, Rolf, Walter Tichy, and Annette Weinert. ACM Transactions on Software Engineering and Methodology 3, no. 1 (January 2, 1994): 3–28. https://doi.org/10.1145/174634.174637.)

    2. This is:

      Franz, Michael, and Thomas Kistler. “Slim Binaries.” Communications of the ACM 40, no. 12 (December 1, 1997): 87–94. https://doi.org/10.1145/265563.265576.

    1. *hugs*

      Infuriatingly, obnoxiously dismissive.

    2. weird limitations of the web

      Claims like these need supporting evidence. Are they really "weird limitations"? Or are they actually reasonable limitations—on developers' unending attempt to exercise what they feel as their manifest destiny to control the user's device and experience?

    3. developers are hamstrung

      So? To reiterate:

      Fuck "developers".

    4. In practice, we can't even get web apps to work on desktop and mobile, to the point where even sites like Wikipedia, the simplest and most obvious place where HTML should Just Work across devices, has a whole fricking separate subdomain for mobile.

      This is a terrible example.

      That is 100% a failing of the folks making those decisions at Wikipedia, not HTML.

    5. I don't want to have to read documentation on how my SSG works (either my own docs or docs on some website) to remember the script to generate the updates, or worry about deploying changes, or fiddling with updates that break my scripts, or anything like that.

      This flavor of fatigue (cf "JavaScript fatigue") is neither particular to nor an intrinsic consequence of static site generators. It's orthogonal and a product of the milieu.

    6. being "followed" isn't always a good thing, it can create pressure to pander to your audience, the same thing that makes social media bad.

      It can also create pressure to hold your tongue on things that you might otherwise be comfortable expressing were it not for the fact that there was available a meticulously indexed, reverse chronological stream of every sequence of words that you've authored and made ambiently available to the world.

    1. This could be an episode of the sci-fi series Black Mirror, but

      Mmm… half of what's described here is an episode of Black Mirror…

    1. Figure 5.

      The screenshot here (p. 33) reads:

      Introduction

      The intent of this paper is to describe a number of studies that we have conducted on the use of a personal computing system, one of which was located in a public junior high school in Palo Alto, California. In general, the purpose of these studies has been to test out our ideas on the design of a computer-based environment for storing, viewing, and changing information in the form of text, pictures, and sound. In particular, we have been looking at the basic information-related methods that should be immediately available to the user of such a system, and at the form of the user interface for accessing these methods. There will undoubtedly be users of a personal computer who will want to do something that can be, but not already done; so we have also been studying methods that allow the user to build his own tools, that is, to write computer programs.

      We have adopted the viewpoint that each user is a learner and have approached our user studies with an emphasis on providing introductory materials for users at different levels of expertise. Our initial focus has been on educational applications in which young children are taught how to program and to use personalizable tools for developing ideas in art and music, as well as in science and mathematics.

      It is titled "Smalltalk in the Classroom" and attributed to "Adele Goldberg and Alan Kay, Xerox Palo Alto Research Center, Learning Research Group". Searching around indicates that this title was re-used in SSL-77-2, but neither introduction in that report matches the text shown here.

      Searching around for distinct phrases doesn't turn anything up. Is this a lost paper? Is there some Smalltalk image around from which this text can be extracted?

    1. Nobody just says to do what you want. They always first demonstrate that they understand the standard arguments for tilting or not tilting, and then say to disregard them. That demonstration shows that they are above the other groups, not below them.
    2. We all play the game we think we can do better at.

      Is that actually true? Surely there are examples where people play the game that they're less suited for—where the decision is driven by desire?

    1. There are a number of ways to become G, but usually you do it by adopting a complainer mindset. You wake up in a bad mood. You find little flaws in everything you see in the world, and focus on those.

      I don't think that's right—

      My life experiences during the (now bygone) Shirky era and the loose school associated with it really inculcated (in me, at least) the value of small, cumulative improvements contributed by folks on a wide scale. See something wrong? Fix it. Can't fix it (like, say, because you don't have the appropriate authorization)? File a bug so the people who can fix it know that it should be fixed. This matches exactly the description of seeing the "little flaws in everything you see in the world, and focus[ing] on those".

      Looking at those flaws and thinking "this thing isn't as good as it could be" is a necessary first step for optimism. That belief and the belief in the possibility of getting it fixed is the optimist approach.

      When I think of miserable people (and the ones who make me miserable), it's the ones who take the attitude of resignation that everything is shit and you shouldn't bother trying to change it because of how futile it is.

    1. This is a new technology, people (read: businesses) want to take advantage of it. They are often ignorant, or simply too busy to learn to harnass it themselves. Many of them will pay you to weave their way on the web. html programming is one of the most lucrative, and most facile consulting jobs in the computing industry. Setting up basic web sites is not at all hard to do, panicked businesses looking to build their tolllane on the infoway will pay you unprecedented piles of cash for no more than a day's labour.
    1. You probably spew bullshit too. It’s just that you’re not famous, and so it may even be harder to be held accountable. Nobody writes essays poking the holes in some private belief you have.

      The at-oddsness of the two things mentioned here—spewing bullshit and private beliefs that someone could correct you about—is hard to skip over.

    2. most “experts”, in every industry, say some amount of bullshit

      This is my experience working with other people, generally. Another way to put it besides people not "priortizing the truth" is that they just don't care—about many things, the truth being one of them.

    3. Philosopher Harry Frankfurt described “bullshit” as “speech intended to persuade without regard for truth. The liar cares about the truth and attempts to hide it; the bullshitter doesn’t care whether what they say is true or false.”

      I don't think this is a good definition of liar. The bullshitter described here would be a liar if what they're saying is lie.

    1. This is:

      Bobrow, Daniel G, and Bertram Raphael. “New Programming Languages for AI Research.” Palo Alto, California, August 20, 1973.

    2. SMALLTALK (Kay 1973) and PLANNER73 (Hewitt 1973), both embody aninteresting idea which extends the SIMULA (Ichbiah 1971) notion ofclasses, items that have both internal data and procedures. Auser program can obtain an "answer" from an instance of a class bygiving it the name of its request without knowing whether therequested information is data or is procedurally determined. AlanKay has extended the idea by making such classes be the basis fora distributed interpreter in SHALLTALK, where each symbolinterrogates its environment and context to determine how torespond. Hewitt has called a version of such extended classesactors, and has studied some of the theoretical implications ofusing actors (with built-in properties such as intention andresource allocation) as the basis for a programming formalism andlanguage based on his earlier PLANNER work.and PLANNER73 are both not yet publicly available, the ideas mayprovide an interesting basis for thinking about programs. Themajor danger seems to be that too much may have been collapsedinto one concept, with a resultant loss of clarity.

      An early mention of Smalltalk.

    1. message-oriented programming language

      That's interesting. This paper is Copyright 1977 (dated June of that year) and is using the term "message-oriented" rather than "object-oriented".

      Rochus maintains that Liskov and Jones are the originators of the term "object-oriented [programming] language".

      Here's Goldberg in an early paper (that nonetheless postdates the 1976 paper by Liskov and Jones) writing at length about objects but calling Smalltalk "message-oriented" (in line with what Kay later said OO was really about).

    1. We're at the point in humanity's development of computing infrastructure where the source code for program texts (e.g. a module definition) should be rich text and not just ASCII/UTF-8.

      Forget that I said "rich text" for a moment and pretend that I was just narrowly talking about the inclusion of, say, graphical diagrams in source code comments.

      Could we do this today? Answer: yes.

      "Sure, you could define a format, but what should it look like? You're going to have to deal with lots of competing proposals for how to actually encode those documents, right?" Answer: no, not really. We have a ubiquitous, widely supported format that is capable of encoding this and more: HTML.

      Now consider what else we could do with that power. Consider a TypeScript alternative that works not by inserting inline type annotations into the program text, but instead by encoding the type of a given identifier via the HTML class attribute.

      Now consider program parametrization where a module includes multiple options for the way that you use it, and you configure it as the programmer by opening up the module definition in your program editor, gesturing at the thing it is that you want to concretely specify, selecting one of those options, and have the program text for the module react accordingly—without erasing or severing the mechanism for configuration, so if another programmer wants to change the module parameters to satisfy some future need—or lift that module from your source tree and use it in another one for a completely different program—then they can reconfigure it with the same mechanism that you used.

    1. I think that most of the complexity in software development is accidental.

      I feel no strong urge to disagree, but on one matter I do want to raise a question: Is "accidental" even the right term? (To contrast against "essential complexity", that is.)

      A substantial portion of the non-essential complexity in modern software development (granted: something that Brooks definitely wasn't and couldn't have been thinking about when he first came up with his turn of phrase in the 1980s) doesn't seem to be "accidental". It very much seems to be intentional.

      So should we therefore* highlight the contrast between "incidental" vs "intentional" complexity?

      * i.e. would it better serve us if we did?

    1. One of the problems with building a jargon is that terms are vulnerable to losing their meaning, in a process of semantic diffusion - to use yet another potential addition to our jargon. Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition.
    1. If a tool is developed to aid the production of software, its impact depends on the importance of the lifecycle phases it affects. Thus, a coding tool has the least impact while an evolution tool has the most impact.
    2. Unless techniques to create software increase dramatically in productivity, the future of computing will be very large software systems barely being able to use a fraction of the computing power of extremely large computers.

      In hindsight, this would be a better outcome than what we ended up with instead: very large software systems that, relative to their size—esp. when contrasted with the size of their (often more capable and featureful) forebears—accomplish very little, but demand the resources of extremely powerful computers.

    1. Rust was initially a personal project by Graydon Hoare, which was adopted by Mozilla, his employer, and eventually became supported by the Rust Foundation

      Considering this post is about Swift, describes Lattner's departure, etc., it would have been opportune to mention Graydon Hoare's departure re Mozilla/Rust and his subsequent work at Apple on Swift.

    1. I made it obscenely clear that there was not going going to be an RFC for the work I was talking about (“Pre-RFC” is the exact wording I used when talking to individuals involved with Rust Project Leadership)

      "Pre-RFC" doesn't sound like there's "not going to be an RFC" for it. It rather sounds like the opposite.

    1. I have never seen any form of create generative model output (be that image, text, audio, or video) which I would rather see than the original prompt. The resulting output has less substance than the prompt and lacks any human vision in its creation. The whole point of making creative work is to share one’s own experience - if there’s no experience to share, why bother? If it’s not worth writing, it’s not worth reading.

      I haven't been using LLMs much—my ChatGPT history is scant and filled with the evidence of months going by between the experiments I perform—but I recently had an excellent experience with ChatGPT helping to work out a response that I was incredibly pleased with.

      It went like this: one commenter, let's label them Person A posted some opinion, and then I, Person B, followed up with a concurrence. Person C then appeared and either totally misunderstood the entire premise and logical throughline in a way that left me at a loss for how to respond, or was intentionally subverting the fundamental, basic (though not unwritten) rules of conversation. This sort of thing happens every so often, and it breaks my brain, so I sought help from ChatGPT.

      First I prompted ChatGPT to tell me what was wrong with Person C's comment. Without my saying so, it discerned exactly what the issue was, and described it correctly: "[…] the issue lies in missing the point of the second commenter's critique […]". I was impressed but still felt like pushing for more detail; the specific issue I was looking for ChatGPT to help explain was how Person C was breaking the conversation (and my brain) by violating Grice's maxims.

      It didn't end up getting there on its own within the first few volleys, even with me pressing for more, so I eventually just outright said that "The third comment violates Grice's maxims". ChatGPT responded with the level of sycophantism (and emoji-punctuated bulleted statements) a little too high, but also went on to prove itself capable of being a useful tool in assisting with crafting a response about the matter at hand that I would not have been able to produce on my own and that came across as a lot more substantive than the prompts alone.

    1. all sanitization is done client-side which means Cloudflare never sees the full contents of the session token

      Then don't use the word "upload".

    1. Is my data kept private? Yes. Your chosen files will not leave your computer. The files will not be accessible by anyone else, the provided link only works for you, and nothing is transmitted over a network while loading it.

      This is a perfect use for a mostly-single-file browser-based literate program.

  5. Apr 2025
    1. Around the start of ski season this year, we talked about my plans to go skiing that weekend, and later that day he started seeing skiing-related ads.He thinks it's because his phone listened into the conversation, but it could just as easily have been that it was spending more time near my phone

      Or—get this—it was because despite the fact that he "hasn't been for several years", he used to "ski a lot", and it was the start of ski season.

      You don't have to assume any sophisticated conspiracy of ad companies listening in through your device's microphone or location-awareness and user correlation. This is an outcome that could be effected by even the dumbest targeted advertising endeavor with shoddy not-even-up-to-date user data. (Indeed, those would be more likely to produce this outcome.)

    1. I had the Android Emulator in my laptop, which I used to install the application, add our insurance information and figure out where to go. Just to be safe, I also ordered an Android phone to be delivered to me while I went to the hospital, where I used my iPhone's hotspot to set it up and show all the insurance information to the hospital staff.

      If only there were some sort of highly accessible information system that was designed to make resources available from anywhere in the world without any higher requirement besides relatively simple and ubiquitous client software. Developers might then not be compelled to churn out bespoke programs that effectively lock up the data (and prevent it from being referenced, viewed, and kept within arm's reach of the people that are its intended consumers).

    1. Software gets more complicated. All of this complexity is there for a reason. But what happened to specializing?

      This feels like a sharp left turn, given the way the post started out.

      Overspecialization is the root of the problem.

      Companies want generalists. This is actually reasonable and good. What's bad is that companies also believe that they need specialists (for things that don't actually require specialization).

    2. “But I can keep doing things the way that I’ve been doing them. It worked fine. I don’t need React”. Of course you can. You can absolutely deviate from the way things are done everywhere in your fast-moving, money-burning startup. Just tell your boss that you’re available to teach the new hires

      I keep seeing people make this move recently—this (implicit, in this case) claim that choosing React or not is a matter of what you could call costliness, and that React is the better option under those circumstances—that it's less costly than, say, vanilla JS.

      No one ever has ever substantiated it, though. That's one thing.

      The other thing is that, intuitively, I actually know* that the opposite is true—that React and the whole ecosystem around it is more costly. And indeed, perversely the entire post in which the quoted passage is embedded is (seemingly unknowingly, i.e. unselfawarely) making the case against the position of React-as-the-low-cost-option.

      * or "know", if the naked assertion raises your hackles otherwise, esp re a comment that immediately follows a complaint about others' lack of evidence

    1. The one recent exception is “Why Can’t We Screenshot Frames From DRM-Protected Video on Apple Devices?”, which somehow escaped the shitlist and garnered 208 comments. These occasional exceptions to DF’s general shitlisting at HN have always made the whole thing more mysterious to me.

      Geez. How clueless can a person be? (Or is feigned cluelessness also a deliberate part of the strategy for increasing engagement?)

    1. The JSON Resource Descriptor (JRD) is a simple JSON object that describes a "resource" on the Internet, where a "resource" is any entity on the Internet that is identified via a URI or IRI. For example, a person's account URI (e.g., acct:bob@example.com) is a resource.

      Wait, the account URI is a resource? Not the account itself (identified by URI)?

    1. WebFinger (RFC 7033) is a REST-based web service

      Nope.

      This is one of those instances where you can do a search-and-replace on REST to substitute "HTTP" instead.

    1. Given the constitutional underpinnings for copyright law as it exists in the US, this commenter's sense of the laws' spiritual intent isn't just off, it's actually in opposition to what the US is trying to effect.

  6. Mar 2025
    1. Variable links are often found in online newspapers, for example, where links to top stories change from day to day. The click command can be used to click on a variable link by describing its location in the web page with a LAPIS text constraint pattern. For example: http://www.salon.com/ # Start at Salon click {Link after Image in Column3}

      This is how RSS/Atom should be implemented in every feed reader, but, to my knowledge, never is. That is—

      If URL to the feed for alice.example.net can be found at <https://alice.example.net/feed.xml> and it is available via feed autodiscovery, it should not require the user to navigate to alice.example.net obtain the URL to the feed, and then paste that into the feed reader. Rather, when I'm looking at my feed reader, I should be able to merely indicate that I want the feed for alice.example.net. The feed reader's job, then, should be to do BOTH of the following:

      (The URL obtained via autodiscovery can be cached.)

      If ever the feed location changes, it should not require the user to then backtrack and go through the process again to obtain the feed URL. With the site alice.example.net itself being kept in the user data store, the feed reader can automate this process. A website could thereby update the URL for its feed whenever it wants—as often as every day, for example, or even multiple times a day—without it being a source of problems for the user.

      To make it even better, the Atom and RSS specs can be extended so that if the user actually pastes in the feed URL <https://alice.example.net/feed.xml>, then that's fine—the specs should permit metadata to advertise that it is the alice.example.net feed (which can be verified by any reader), and the client can store that fact and need not bother the user about the overly-specific URL.

    1. Neat. It's basically a browser with deep integration for Fastmail.

      (Not that Fastmail is neat—it's evidently got a bunch of jerks in charge—but I wholeheartedly approve of user agents operating in their users' best interests, and this qualifies. The fact that this is a site-specific browser made with no involvement of the site operator? A++++)

    1. Please note that if you plan on importing this file back into Hypothesis you will need to export to a JSON file.

      I'm kind of bummed that HTML exports don't contain sufficient information to act as a substitute for the JSON.

    2. To import annotations from a JSON file saved to your computer, select the “Import” button under the Sharing menu.

      That's neat, too.

    3. You can export any notes to which you have access in the Hypothesis apps.

      Neat.

    1. to build xz from sources, we need autoconf to generate the configure script

      Should you, though?

      (The author approaches things from a different direction, but it's worth considering this one, too.)

    2. while git repositories can be altered

      Huh? I think I know what this is supposed to mean, but the problem with it is that it's a different kind of nonsense.

    1. The most challenging part of gathering evidence is organising it.

      non-sequitur?

    2. For others, many of whom are voracious readers, the compulsion to read manifests as an exercise in confirmation bias: collecting fragments of ideas that validate existing worldview.

      This is always how I've valued songs and their lyrics.

      I'm aware of it.

    3. the algorithm

      please, stop

    1. If something has value, users should pay for it.

      Forget "value". That's a lateral shift in focus, and therefore a subtle change in subject. This is about costs. So rework the thought:

      If a "user"* is the cause of costs, then we should consider getting the user to pay for it—especially when the costs are big enough.

      (The answer to this is probably resource-proportionate billing for the accumulated expenses.)

      * or "consumer"

    1. Every time you run your bundler, the JavaScript VM is seeing your bundler's code for the first time

      And of course this fares poorly if the input ("your bundler's code") is low-quality.

      It's important to make an apples-to-apples comparison, so you don't end up with the wrong takeaway, like, "Stuff written in JS is always going to be inherently as bad as e.g. Webpack," which is more or less the idea that this paragraph wants you to get behind.

      It shouldn't be surprising that if you reject the way of a bad example, then you avoid the problems that would have naturally followed if you'd have gone ahead and done things the bad way.

      Write JS that has the look of Java and broad shape of Objective-C, and feels as boring as Go (i.e. JS as it was intended; I'm never not surprised by NPM programmers' preference to write their programs as if willingly engaging in a continual wrestling match against a language they clearly hate...)

    2. Every time you run your bundler, the JavaScript VM is seeing your bundler's code for the first time without any optimization hints

      This is really a failure of the NodeJS &co and is not something that's inherent to the essence of JS or any other programming language.

      It makes sense for Web browsers to throw away everything and re-JIT every time since the inputs have just streamed in over the network microseconds ago. It doesn't make sense for a runtime that exclusively runs programs that are installed locally and read from disk instead of over the network; the runtime could do one of (or both): - accept AOT-compiled inputs - cache the results of the JITting

    1. "with a text editor, with a web browser, standard stuff"

    1. (Shift+Left and Shift+Right) to go from one post to the next without having to click any links

      I just discovered this accidentally, and it's really annoying considering Shift+Left and Shift+Right are existing keyboard shortcuts on almost every platform to change the size of the selection (e.g. with selected text).

    2. WordPress uses a quirky subdirectory structure where it groups posts by year and then by month

      I don't see how 2025/01/10/foo-bar.html is any more or less "quirky" than 2025-01-10-foo-bar.html.

    1. We're overloading the class attribute with two meanings. Is "adr" the name of a class that contains styling information, or the name of a data field?

      What gives you the idea that class is for "contain[ing] styling information"? (This is rhetorical; I know the answer. This remark is a giveaway about the mental model of what HTML classes—NB: not "CSS classes"—are "for".)

    1. Git ships with built-in tools for collaborating over email.

      Just as a point of fact: many distributions' package repositories don't have a Git package that "ships with built-in tools for collaborating over email", which can be seen in the suggested steps given for the systems in this list—the distros do generally provide packages that back the git send-email command, but it's a separate package.

    1. human-knowledge-based chess researchers were not good losers. They said that ``brute force" search may have won this time, but it was not a general strategy, and anyway it was not how people played chess. These researchers wanted methods based on human input to win and were disappointed when they did not.

      Intuitively, it makes sense that brute force would win, which should not be a surprising result. (I suppose the surprise could be simply that there was enough computation available.)

  7. Feb 2025
    1. The component library: Dream and realityMcIlroy’s idea was a large library of tested, documented components. To buildyour system, you take down a couple of dozen components from the shelves andglue them together with a modest amount of your own code.

      Even though my comments elsewhere mention NPM, etc., I myself don't think they quite fit to what McIlroy (and Cox) were talking about. If I recall correctly, both mention configuring components in ways that are not generally seen with modern packages. McIlroy in particular talks about parameterization that suggests to me compile-time (or pre-compile-time) configuration, whereas the junk on NPM traditionally blobs all the behavior together and selects behavior at program runtime.

    2. Although it’s difficult to handle complexity in software, it’s much eas-ier to handle it there than elsewhere in a system. A good engineertherefore moves as much complexity as possible into software.

      Tangent: I've likened system designs for Web tech that requires deep control and/or configuration of the server (versus a design that lets someone just dump content onto a static site) to the leap in productivity/malleability of doing something in hardware versus doing it in software.

      Compare: Mastodon-compatible, ActivityPub-powered fediverse nodes that are required to implement WebFinger versus RSS-/Atom-based blog feeds (or podcasts—both of which you could in theory you could author by hand if you wanted to).

    Annotators

    1. A the same time, it is very desirableto place each feature of a program into a separate module, even though theimplementation of the features may be fairly interconnected.
    2. Programs that include many tests of the form if (xinstanceof C) ... are quite common but undermine many of the benefits ofusing objects

      See also: the trend of an overabundance of triple equals operators (===) in NPM programmers' code.

    1. Java and C avoid the extraneous work that Python does under the hood to make programming easier

      vague, wishy washy

    2. Simply choosing a more efficient programming language speeds up this calculation

      s/more efficient programming language/programming environments with more efficient implementations/

    1. can you imagine your GC being randomly interrupted by its own internal garbage collection?

      The author states this like it's prima facie absurd. But, I dunno, why not? It's neither inconceivable nor absurd (no matter the way the author goes about it in this particular post).

    1. The literature on p r o g r a m m ~ g methodologycontains numerous articles explicating the notion of type. For our purposes it isnot necessary to delve into the theology that surrounds the issue of precisely whatconstitutes a type definition. I will rely on the reader's intuitions.

      And so it goes with programs written for environments with dynamic and loose typing. (In fact, if you swap out the phrase "a type definition" with "this type", then you get what almost amounts to a manifesto for dynamic typing.)

    Annotators

    1. Pratt parsers are a really nice way to handle mathematical expressions like this vs. the usual recursive descent.

      People love to say stuff like this, but then you get things like Jonathan Blow's multi-hour live stream with Casey Muratori where they end up getting bogged down working it all out (while talking about how easy it is and how dumb it is that we even have a term for "recursive descent"). Whereas if they'd just gone with recursive descent, they could have implemented it and re-implemented it four times over by then…

    1. For URLs that are not intended to break, where does that intention reside andhow is it communicated to users?

      Unpopular opinion: all URLs should be "not intended to break". (Or, at the very least, that should be the assumed default unless otherwise specified.)

    2. t’s hard to talk about an identifier that “breaks.” Whendoes a string “break,” except perhaps when it sustains damage to its charactersequence? What really breaks has to do with the identifier’s reference role

      I like this approach to examination. It bears resemblance to the way that I admonish the public about content "changing". There's no such thing as resources "changing". There are only servers re-using identifiers and lying about their resources' identities.

    3. This is not to say that some naming practices still commontoday don’t create URLs that contain clues reflecting location information, justthat URLs may be just as indirect and location-free as any indirect identifier(e.g., URN or Handle).

      I like the way TBL put it in <https://www.w3.org/Provider/Style/URI>:

      "Most URN schemes I have seen look something like an authority ID followed by either a date and a string you choose, or just a string you choose. This looks very like an HTTP URI. In other words, if you think your organization will be capable of creating URNs which will last, then prove it by doing it now and using them for your HTTP URIs."

    4. Unfortunately, decoupling persistent identification fromaccess was an early decision made by designers of PURLs, URNs, and Handles.

      This could benefit from further elaboration.

    5. It turns out that whatpeople really want is the kind of convenient access to which they have becomeaccustomed on the Web. Instead, what we’re looking for are persistent actionableidentifiers, where an actionable identifier is one that widely available tools suchas web browsers can use to convert a simple “click” into access to the object orto a doorway leading directly to access (e.g., the doorway could be a passwordchallenge or object summary description page).

      Good description of the widely perceived value proposition of the (conventional, http(s):-based) Web—but as TBL explains, HTTP and HTML are incidental to true intent and purpose of the Web.

    Annotators

    1. Fittingly (or perversely) enough, this URL is referenced by Kunze in the ARK paper. It ends up trying to resolve to an archive.org-hosted URL, after the handoff from OCLC:

      <https://purl.archive.org/docs/inet96.html>

    1. At beginning of empty ZIP archive file.

      Note that the preceding remark that the spec "does not state explicitly be at the physical end of the file" applies as much (and more) to this part. Self-extracting archives have explicit support in PKZIP and other implementations.

    1. This is arguably an indicator that the a fixed schedule does not quite work out for me.

      OR:

      There is a sufficiently high mechanical barrier (in the sense of an imposition from the software itself).

    1. I generally try to apply Chesterton's fence when dealing with inherited code.

      "Chesterton's fence or Rhesus ladder?" is always a good question to have in mind.

    1. There is a great xkcd about how much time you may spend on automation before yielding negative returns.

      This seems like a weird way to put it. By spending even a microsecond on trying to implement automation, there are negative returns by default. It is only with sufficiently effective automation that the lines intersect and you end up on the "positive returns" side.

  8. pkwaredownloads.blob.core.windows.net pkwaredownloads.blob.core.windows.net
    1. If one of the fields in the end of central directory record is too small to hold required data, the field should be set to -1 (0xFFFF or 0xFFFFFFFF)

      This is a weird way to put it, since the very first note given in this section is that all fields unless otherwise noted are unsigned...

    1. I find myself revisiting now due to buggy behavior observed in jszip (discovered through Darius Kazemi's reliance on it for his Twitter archiver project).

      The problem is that jszip when given a ZIP with Zip64 data in the end of central directory record handles it poorly (presumably jszip simply doesn't have support for Zip64 despite being advertised as such)—except that that's even really the problem.

      The fundamental problem with jszip is that it doesn't support Zip64 (whether it says it does or not) and it makes an assumption that the last file header record in the central directory will be immediately followed by the end of central directory signature and when it encounters a file that violates this assumption its attempts to recover are odd. There's no good reason for jszip or any other software to make that assumption, though, since depending on it is in no way necessary to go ahead and successfully work with the files that are present.

    2. What if there is some local file record that is not referenced by the central directory? Is that valid? This is undefined.

      From an earlier private note (from 2021 July 20):

      A better way to phrase it: "What if there is some byte sequence that coincides with the sequence used for the local file header signature, but nonetheless does not comprise some part of a file record (i.e., one "referenced by the central directory")?

      And the answer, of course, is right there; it is not UB—that isn't a file record.

      Some block of data within the ZIP can only be considered to comprise a local file header iff it is referenced by the central directory. A byte sequence appearing elsewhere that collides with the file header signature is just noise.

    3. The "end of central directory record" must be at the end of the file and the sequence of bytes, 0x50 0x4B 0x05 0x06, must not appear in the comment.

      What happened to the central directory offset not being allowed to be located there?

  9. greggman.github.io greggman.github.io
    1. unzip and unzipRaw are async functions that take a url, Blob, TypedArray, or ArrayBuffer or a Reader.

      The silliness of method overloading. The problem this is trying to solve can be solved by the publisher providing a consistent interface no matter what the input parameter and the consumer choosing the right module to import.

    2. IMO those should be separate libraries as there is little if any code to share between both. Plenty of projects only need to do one or the other.

      This is an interesting comment, because the same logic can be applied to the author's criticism of the APPNOTE spec and his question of whether ZIP can be streamed or not.

    1. I realise that this entire premise falls flat once you include more "dynamic" page components like related content, recent content and so forth.

      In that case, your Web pages are changing more than they probably should be, anyway.

    2. People often talk about build times when referencing SSGs. That always confused me, because how often do you need to rebuild everything? I'm a simple guy, so I like to keep it very simple. To me, that means that when there's one piece of new content, we generate one new page and regenerate the relevant archive pages.
  10. Jan 2025
    1. Does such a community really exist? Where everyone cares? Or at least a supermajority? Or does it need to be built?
    2. The one place in the world you get this vibe is probably Japan. Most people just really care. Patrick McKenzie refers to this as the will to have nice things. Japan has it, and the US mostly does not.

      It's a little perverse to link to an inaccessible Twitter/X.Com post here in a post about this topic.

  11. Dec 2024
    1. I don't think the Firefox OS team was ever bigger than maybe 100 people at the absolute most, and I feel like it was closer to half of that. Admittedly it's been over a decade since I left, so my recollection could be wrong, but it was never "most of the resources" by any metric.

      ~50 people and "a tiny percentage of the overall staff" are such bad estimates that it's something you'd expect from the least clued-in segments of the peanut gallery, not someone on payroll. I struggle to come up with words to even react (let alone respond) to it, even in the written medium of online comment threads where you have time to compose your thoughts. It breaks my brain.

    1. Electron pioneered the category of “use web tech to make mediocre desktop software”

      Gecko? XUL?

    1. This is:

      Bogart, Christopher, Margaret Burnett, Allen Cypher, and Christopher Scaffidi. “End-User Programming in the Wild: A Field Study of CoScripter Scripts.” In 2008 IEEE Symposium on Visual Languages and Human-Centric Computing, 39–46. Herrsching am Ammersee: IEEE, 2008. https://doi.org/10.1109/VLHCC.2008.4639056

    1. HathiTrust has volumes 3-5, 9-13, and 39-40.

      UT says they have (some parts of) 47 and 48. I have confirmed it exists, but not totally clear on the completeness.

    1. [b1 ; e1 ] overlaps-start [b2 ; e2 ] , b1  b2 ^ e1  e2

      This can't be right. Sure, by this definition the relation "B overlaps-start R" holds, but so does "A overlaps-start R".

  12. Nov 2024
    1. All right, so it doesn't say here, but UT's physical copies at PCL include what I think is the whole series.

      HathiTrust's scans from the University of Michigan's collections go from volume 1 up to volume 13, but PCL has also vols. 14–17.

    1. As a gift for a family member who had a non-technical blog, I once gathered posts together, edited them, and turned them into a book.

      I've thought about and would really appreciate a platform like Lulu that would allow you to pay, say, 99¢ each to get printed copies of your favorite blog posts (standalone, not necessarily in book form), where a portion goes to the author. It shouldn't require creators to sign up for e.g. Patreon and consciously designate a priori what is and isn't "subscriber-only" content.

      Like, "I just like this thing that you wrote, dude. Let me get a print copy and also make sure you get a few nickels for it."

    1. NB: This is NOT the same as Ballou's Pictorial.

    2. 60, 63-68, 70-72, and 74-76

      Okay, seemingly missing from here, and not made up by any of the other sources listed here are volumes:

      • 61
      • 62
      • 69
      • 73
      • and 77(?)

      Anything else? (It doesn't say exactly when it stopped in 1893. Vol 76 was December 1892.)