It's weird that in 2021 this canard associated with conflating libre and gratis is still showing up.

she became wise for a world that's no longer here

This might just be true for Tim's grandma, but something people neglect generally is that you can find just as much bad advice elsewhere—where wisdom from another time is not the reason. Some people just have no idea what they're talking about—and they're never going to be subjected to a fitness function that culls the nonsense they dispense.

(NB: RWI — Real World Interpretation)

But they don't. They get re-issued (https://hypothes.is/a/FWEDwInLEeyhtVeF1gArUw) and their associated identifier (URI) gets re-used for the new version, and the original issues get routinely "disappeared". This is a failure to carry out TBL's original vision for the Web in practice–where every article is given a name that can be systematically (mechanically) resolved, or if not that, then at least used as a handle to unambiguously refer to the thing.

Related(?): Free Software, the Internet, and Global Communities of Resistance

Perversely, this link is a 404.

The problem with this, generally, but esp. affecting wikis in particular, is that you end up with orphaned and irrelevant/out-of-date annotations.

Hypothes.is should select an appropriate link relation (in the vein of what it now does with canonical) and scope the annotation appropriately—even if the user does not actually have his or her browser pointed at the exact revision that is "current".

This tool should be a "codebook"—a downloadable document meant to be stored in an offline copy e.g. on the user's local disk, a la PDF (except still actually HTML, as here). I shouldn't need to "go to" anywhere to use it; that should only be necessary to get it the first time.

Look to Lettersmith's README for inspiration about the best way to present this.

This is a recurring grievance of mine with the way most people approach writing documentation. Closely related: code comments should explain the why, not the what (or worse the how—which just ends up rehashing the code itself).

Too many people try to launch right in and explain what they're doing—their solution to a problem—without ever adequately outlining the problem itself. This might seem like too much of a hassle for your readers, but often when the problem is explained well enough, people don't actually need to read your explanation of the solution.

Nah.

This is also, more or less, how Git works, albeit it at a different granularity. In Git, you want your working directory to include a series* of files. The Git "database" knows about a bunch of different file contents (blobs) which could be in your working directory, then the Git command-line tool puts such a collection together from a tree of those parts. With the Nelson-inspired "thought legos" described here, the files themselves comprise a list of more granular objects further still, arranged in a specific order* to form a document.

* This might be considered another difference: we generally don't think of a directory of files as being ordered—we do make use of various machine-sorted views, e.g. inside a file explorer, but that ordering is not inherent to the model itself, just how a given client chooses to display it.

Let's just all agree that Cocoa should be the cross-platform interface toolkit. The time is better than ever, given the Oracle v. Google decision, and considering that SwiftUi has materialized, Apple is less likely to regard it as "theirs", anyway.

Netflix is not particularly "Webby", though...

Should be https://w3id.org/people/essepuntato/papers/rash-ads2017.html

Should be https://w3id.org/people/essepuntato/papers/rash-ads2017.html

Should be https://w3id.org/people/essepuntato/papers/rash-ads2017.html

You are looking for https://w3id.org/people/essepuntato/papers/rash-ads2017.html

This sort of thing comes up a lot and results in really stupid discussions—almost as stupid as the late '90s/early '00s tendency to distinguish between "programming languages" and "scripting languages". Say hello to category error. (Worse, i once ran across someone insisting that inert sequences written in e.g. declarative languages cannot be referred to as "code".)

The distinction people want to make in the case of HTML versus other languages tends to be *markup languages" as distinct from languages that are regularly used for doing von Neumann-style computation. Sometimes, then, people will offer up up a reference to the term "Turing-complete", but this is off, because often things are accidentally Turing-complete.

I think this can be tamped down by using a more descriptive and more accurate term, and by avoiding "programming language" altogether when trying to make categorical distinctions. We could call them "algorithmic languages", for example, which would be shorthand for "languages whose primary intent is to be used to encode stored programs featuring algorithmic control".

Something to consider regarding TBL's comments in the Axioms of Web Architecture:

If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.

https://www.w3.org/DesignIssues/Principles.html#PLP

One example: Google Scholar. Tabs and tabs of pages with the title "View article" (e.g. https://scholar.google.com/citations?view_op=view_citation&citation_for_view=v5LctN8AAAAJ:4TOpqqG69KYC).

This paper is from the Proceedings of the Eighteenth Conference on Hypertext and Hypermedia (HT '07) https://doi.org/10.1145/1286240.1286303.

See "From PDF to PWP: A vision for compound web documents" https://blog.jonudell.net/2016/10/15/from-pdf-to-pwp-a-vision-for-compound-web-documents/

I'd argue that the property described is not a property of the Web, to its discredit. Udell's piece gives a good overview of why it would be desirable if it were, contra Nelson et al.

Huh?

See more of Ted on files in "The Tyranny of the File", Datamation, 1986 December 15.

Desirables: * data export * data import (POSSE/PESOS) * collaboration (wiki/fanclub, annotations)

The author omitted cognitive errors and stupid macho bullshit.

I've looked a lot into the file-saving problem over the years. Tom describes the problem in a succinct enough way:

Let’s say you’re building a graphics editor and someone can save their work as file.svg. If this were a desktop application, they could press ⌘s to save again. Or you might even auto-save to the file. You can’t do this on the web: every time you save a file, it’ll go through the same “Save as…” workflow, which asks you to choose a location and confirms if you overwrite an existing file.

The reality is that this is cumbersome, but it's not a showstopper. Any application author caring to let you run local-first applications where you own the data can do so.

The effect that the new file system API is likely to have is to see it abused to the point that lots of people lose even more control of their data and (because of that) others are wary of granting permissions at all, due to overbroad privilege requests. The status quo, even cumbersome as it is, is actually more of an enabler for user-controlled, local-first applications and strong data ownership "rights".

The API designers should step back from the current kitchen sink design for file access and narrowly address the specific ergonomics issues described in the quoted bit relating to ⌘s and file overwrites.

(One workaround that I've come up with to the file overwrite problem is to pack up opaque "checkpoint" files and educate the user that the correct way to work is to save them all to a common directory. You generate a unique name each time, so while even though the user must explicitly do a little bit of a dance with the system filepicker dialog, they are never prompted with the "[Are you sure you want to overwrite...?]" warning. The dance with the filepicker is also minimal, since the browser remembers the last location, so it more or less amounts to an explicit notification that the app is saving new data with an optional way for the user to seize control and write it elsewhere if they choose. When it comes time to open up a previous project, rather than picking a single file, they point at the directory containing all the checkpoint files. The app reads these in and reconstructs the state. [Side note: the ZIP format's internal data structures work passably for this. The concatenation of the content of all the checkpoint files files comprises the ZIP bytestream.] It sounds janky, but on reflection this is really only true because it violates some expectations about how things should work based on familiarity with other workflows. Doing things this way means also that you can get version history almost for free—something that otherwise takes a lot of intentional and clever design and generally only shows up in mature apps with lots of engineering resources. But, to repeat, using this "ZIP-chunks" approach, you get it as a byproduct of having to work within the constraints of the browser sandbox. Sometimes constraints are useful for creation.)

Try unnecessary use of Node.

And in environments without tangle and weave, you can get pretty far by just making sure to write code top-down.

Very unfortunate design choice.. This was always a rough spot dealing with XBL.

The effect of handling open source the way it's popularly practiced on GitHub does not get nearly enough scrutiny for its role in e.g. maintainer burnout. Pretty much every project I see on GitHub does things that are obviously bad—or at least it should be obvious*—and neither are they sustainable, nor even a particularly good way to try to get work done, assuming that that's your imperative. It is probably the case, however, that that assumption is a bad one.

* I've slowly come to realize and accept that this stuff is not obvious to lots of people, because it's all they know—whether that means that that should affect whether its negative consequences are obvious is something that I'm inclined heavily to argue that "no, it shouldn't affect it; it should still be obvious that it's bad even then", but empirically, it seems that my instinct is wrong.

Obscurantism belongs to Ra.

Need better evidence for cosmic unfairness and against the just-world fallacy?

's a shame that such a high earner can't/doesn't spot their error in associating $33,000 of "annual post-tax household income" with "$33,000 USD/month" (even after encountering surprising results that one would expect would cause them question themselves).

I wonder how many people who could benefit from the suggested $39,600 donation wouldn't have made the same mistake (and could go on to create that much value many times over to humanity—maybe even greater than that amount to the donor themselves, indirectly).

Then it sounds like you're in full agreement that step 1 should be "become a user". So why is this comment written as if it dissents? (The question should be worded "Under what circumstances would step 1 be anything other than 'become a user'?", to avoid sounding like criticism of what is actually a shared belief.)

When people err on the side of advising for things to be overly DRY, I prefer to counter it by advocating for TRY (Try Repeating Yourself). Only after you've actually tried the copy-and-paste approach and have run into actual (vs imagined) issues should you refactor more for the DRY side.

See also: "A little copying is better than a little dependency." * https://go-proverbs.github.io/ * https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s

Here: https://www.teamten.com/lawrence/programming/keep-things-brutally-simple.html

No. Actual lesson: don't do crazy shit; if you're trying to code defensively against this, then your code is too hard to understand, anyway, and you've got bigger problems. (See also: overuse of triple equals and treating it like an amulet to ward off unwanted spirits.)

wat

No. Actual lesson: know your types.

This is where widespread awareness of annotations would be useful. A service like Hypothes.is inherently functions as a sort of hub for relaying gossip about a given resource.

the need for an ombudsman or viable "fanclub economy"

https://xkcd.com/1205/

https://xkcd.com/1319/

Isn't this piece a longwinded way of saying that the adage "If you want something done right you have to do it yourself" is accurate?

Tailorism requires Taylorism. If you fail at the latter, you'll never be able to reason accurately about the former.

He made the mistake of not realizing that ninety percent of everything is crap. ("Everything" includes jobs filled by people who may or may not have any competence in spite of their insider status.)

I learned from Scott Alexander that these systems are "anti-inductive".

A memo to myself last week on this topic: people—even smart ones—still have trouble wrangling the implications of natural selection.

Natural selection does not mean survival of the fittest. It means survival of the good enough.

There was more to it than that, but funnily enough, there's this part:

Dan Luu writes of Twitter and companies generally that they should continue to hire so long as it makes financial sense, and what makes financial sense is defined by an equation where savings at the margin is one component

Understanding this is important, not just for the reasons that Dan mentions in the linked ("I could do that in a weekend!") piece, but because it gives companies a budget for inefficiency.

Companies can make non-optimal decisions. (Deleterious ones, even.a^1 a^2)

Instant death is not really a thing, although most misunderstandings demand that it is (as in the case of the parable of the "non-existent" 20-dollar bill). This is the timeless fallacy.

When i was working this into a starter for a potential standalone piece, i drafted the following passage, hoping to use it as an intro:

This is not a piece about biology. It is not even a piece about humans' understanding of biology. It is a piece about humans and humans' inability to grapple with particularly counterintuitive concepts (like natural selection).

i also jotted down the phrase "cognitive fluency".

Market domination is not even a precondition. Of course, non-market-dominance plus bad decisions won't beget dominance, but so-so organizations can continue to be so-so for a really long time.

No.

This is a great piece of writing with an extremely unfortunate title. On review, it's shown to describe a model with fairly rigorous definitions.

Key word "was". Perversely, now it's a 404.

Should offer the ability to use a Solid pod or remoteStorage or S4.

Huh?

There are serious problems with the linked article.

It appears that the slide pictured in this post (incl. typos) is an inaccurate (fake) copy of what was actually presented in 2003. Either the author or someone else seems to have fabricated it for some reason, perhaps to sweeten the circumstances to better support the author's original contributions to this topic. (Quoted; see below.) Or maybe not, but it's beside the point—which is that the slide as pictured is not an accurate facsimile of the original, but is misleadingly presented as if it might be lifted straight from the source material.

The choice to use this fabricated material for this article and the false claims in it—claims not actually confirmed by the sources that it cites—amounts to what would be considered serious misconduct elsewhere.

Here's the original contribution from the author of this post:

Imagine if the engineers had put up a slide with just: “foam strike more than 600 times bigger than test data.” Maybe NASA would have listened. Maybe they wouldn’t have attempted re-entry. Next time you’re asked to give a talk remember Columbia. Don’t just jump to your laptop and write out slides of text. Think about your message. Don’t let that message be lost amongst text.

This is the main conclusion of the post, and it's a recapitulation of some earlier statements:

Thirdly, there is a huge amount of text, more than 100 words[...] the single most important fact, that the foam strike had occurred at forces massively out of test conditions, is hidden at the very bottom. Twelve little words which the audience would have had to wade through more than 100 to get to. If they even managed to keep reading to that point.

These statements are misleadingly presented in the article as if is they are representative of Tufte's findings. Trying to confirm this reveals that it is not. Worse, unfortunately, is that it can be disconfirmed; the position laid out in the sources cited runs counter to what is purported here to be be a summary of those sources' findings.

The author of this piece would have us believe that Tufte and the investigation board wants us to create better, terser slideshows for these high-risk/high-impact situations—a position that could be described as lean in even more: PowerPoint harder. That cannot be further from the truth.

The position Tufte lays out is that the choice to rely on a series of slides these circumstances represents a serious cognitive lapse. The report of the investigation board itself is critical of the organizational culture where misuse of PowerPoint is "endemic". (Bizarrely, the article actually uses this salient quote—and proceeds to bulldoze past it to present its counterconclusion.) Tufte's notes quote a followup report by a subsequent group that had harsh things to say about an organization that continues in a manner where "instead of concise engineering reports, decisions and their associated rationale are often contained solely within Microsoft PowerPoint charts or emails." The cited sources go on this fashion at length. What they don't do is support the claims or original advice presented in Thomas's "Death by PowerPoint: the slide that killed seven people" article that prescribes the opposite.

i've seen the same thing happen with slides created for wafers entering the Abnormal Lot Processing System at Samsung. The point is to err on the side of containment to prevent defects from shipping, but what happens is that engineers end throwing together inscrutable data with no narrative throughline. It's a fair bet that for any given lot that enters the system, the person submitting the associated documentation themselves doesn't actually understand what's going on—either the thing at issue that led to ALPS in the first place, or an understanding that ALPS is just a series of checks and balances to make sure that the scientific process is being adhered to.

This sounds like exactly what motivates most authors of crummy PowerPoint slide decks to do the things that they do—and exactly why the results are most frequently chaotic, not clear.

Found here: https://www.nature.com/articles/442140a

The distinctive cognitive style of PowerPoint

That is definitely not the fucking problem. If anything, the judgment that this is "a huge amount of text" is the problem. Why was PowerPoint chosen in the first place? A: because government-adjacent engineering organizations, it seems, abhor having to read and write, so they create PowerPoint slides instead, as if this sidesteps some problem. What it ends up doing is creating them.

The fucked up thing is that the author of this blog post seems to have taken it upon themselves to insert this personal synthesis into the piece. I cannot find support for the implied claim that this ("thirdly") point is among the conclusions that Tufte arrived at after checking the material that Tufte himself has provided on the page dedicated to this topic on his website https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB (linked by the author of this piece). And of course, this is unsurprising, since this opinion (the one original to the author of this piece—that there being "a huge amount of text" is a problem) runs counter to the the conclusions that Tufte actually presents...

What's more, it looks like the author of this piece (or someone else) didn't even extract these slides from the originals, but instead chose to recreate them! I find this perplexing and an indication of extremely bad judgment, given that entire basis of this critique are the particulars of the organization and presentation of the material in question...

What the fuck.

What if people lack the sense of self-confidence, the sense of self-worth[...] that enables a person to be curious in the first place?

Because I think a lack of curiosity comes from--or a lack of the capacity to be curious--comes from an incredible amount of insecurity. The desire to have power or be power hungry in the first place, it seems to me, is stemming from this profound fear of not being secure, of not having a secure sense of being. And that is affected by this undermining of the institutions and things that you spoke about, Kmele. So how do you deal with that? As a person if you don't have the sense of self-worth internally, how are you going to be curious about the world? How are you going to be allow yourself to feel safe enough to be vulnerable with others and therefore to be intemate with others?

There are way too many dipshits who are way too happy to come out of the woodwork when this topic is brought up to try to drop an FYI wisdom nugget on you about how github.com will let you skip a few of these steps and do the edit/commit thing directly in your browser. Great job on almost entirely missing the point, morons. Let's be excruciatingly clear:

If, at any point, "submit a PR" comes up during an explanation of how to do a run-of-the-mill edit on your project's wiki, then your project does not have a wiki.

From the homepage:

Repla is a macOS app that can[...]

That's like the complete opposite of "just give me a document that I can double click to open from disk and view in my browser"...

I suspect VS Code's non-native look has actually contributed to the uptake from a subset of its users. A fullscreen terminal-based editor like Vim is also non-native as far as widget sets are concerned, but pleasantly so in at least one respect. When Chrome was released, when you asked people what they liked about it, sure they'd say it was fast and whatnot, but for a non-trivial segment of the world, they just liked how visually slim it was. They appreciated how little chrome was actually in Chrome. VS Code managed to reap dividends on its imports of the same approach to its "shell", even while not being particularly fast. (People point to VS Code as an example of a snappy Electron app, and they're not wrong insofar as the comparison goes to other typical Electron apps; on an absolute, non-weight-class-adjusted scale, though, VS Code is still pretty clunky—people just ignore it because of how slim it appears in comparison to IDEs like MonoDevelop[1].)

1. https://upload.wikimedia.org/wikipedia/commons/0/01/Monodevelop-main-window.png

This complaint reflects an obsession that also explains a continual interest in today's news. It's not quite FOMO. Rather, it's an agitation that no one is producing anything which you can miss out on!

This is not something that should be lamented. Technological progress should be cumulative (along witth non-technological progress, for that matter).

Grids like these are user-hostile—a clear choice to prioritize aesthetics over experience. In order to see what any given app does, I have to either:

1. Figure it out by the name alone
2. Click each one to fetch the relevant info (and wait for it to load)
3. Mouse over each item to read the title text

People are so quick to point out the lack of interest for people (and programmers, esp.) to pay for software. If this were distributed as HTML, maybe a way to hack around this unfortunate cognitive hangup would be to frame it as If you're buying an ebook: the manual for the software. It just so happens that this manual can be interpreted by a machine.

Meanwhile, not only does the scope of this tool not merit the Big Sur requirement, it doesn't even require a Mac. It interaction style is so free of intracies that it could be developed (and distributed) as a single HTML file with a text input and some script blocks.

Around @11:16:

"What made HyperCard the ubiquitous product it was in the early 90s... was the fact that it was included free with every Macintosh sold. So anybody could use it to create somethnig, then share their creation with somebody else with the confidence that the other person would be able to run it."

So that was in that day. What is the box today?

Let me ask it another way: What is available on every computing device[...]?"

I would encourage us all to find ways to make the system immediately available to users.

#restofthefuckingowl

It's conceivable that people would find it overly cumbersome having to deal with this when prototyping from a REPL—enough to consider it a bad experience to keep them from trying.

A live IDE could recognize that the user probably doesn't want that to happen for a given object, since it only just appeared a little while ago, so it should offer some fixup to save time for the user.

Not the first time I've seen this sort of thing, but certainly the most egregious instance I know of. (What the hell was going on when 'hhjinks' typed that out and hit "reply"?)

I know people are really fond of this talking point, but it doesn't hold up.

if you come to work at my sandwich shop, and you show up every day to make sandwiches, and then payday comes and I stiff you, then I have definitely stolen from you.

The strongest retort to this is that this would be an instance of fraud, since in the sandwich shop we probably came to an agreement beforehand that I would pay you e.g. $15 per hour, but in the case of IP, this is incomparable because we never agreed to anything. This is pretty straightforwardly addressed by the observation that we live in a society where IP laws are in effect, so regardless of how any one person feels about IP in the abstract, we're all bound by the rules that are known at the outset. Because your decision as the creator to move forward and create the thing was predicated on an understanding that the rules are such as they are, then I actually do have an obligation to observe them just the same as my obligation not to stiff you for making my sandwiches. I don't get to start a game of Parcheesi with you under the pretense that we're going to play fair and then reveal midway through that I won't be governed by all the rules on basis that I don't believe that they're entirely justified. Fairness cannot follow from false pretense.

The one way that it would be fair would be if I made my position known from the beginning and then everyone agreed to play anyway under my augmented ruleset, but it's important to observe that the obligation lies with me. What this doesn't mean, in a society with IP laws, is that it would be sufficient for me to declare (e.g. in a manifesto posted to my blog, or in an Internet message board comment, or whispered into the night) that I don't agree with IP and then proceed to fill up on all the stuff that I'd like. What proceeding with my augmented Parcheesi ruleset looks like is disengaging from the society where IP law is in effect and moving to Russia or Shenzhen or the habitat I've set up on the edge of Schiaparelli crater.

Morrissettesque irony

I have deleted /index.html. Right now, if I visit https://crussell.ichi.city, then the server returns a 404 (but it successfully(?) gives a directory listing). This is not a problem for e.g. https://crussell.ichi.city/bookmarklets/, which similarly lacks an index.html

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.colbyrussel.com"—built from Riku key request for ${email}).

It would be nice to have actual timestamps on these. The general approach is to include this as title text at least. ("At least", because I'm sure there's some semantic way to represent it, but I'm not sure what it is.)

probably don't want enumerable IDs

Maybe for new accounts, inline the manual here.

This should be a button. (GET should be idempotent and free of side effects.)

it would be nice to make this a link for easy copy and paste from the context menu. (You can use an event handler in JS to admonish the user not to click it and then cancel the event—or just copy it to the clipboard.)

Neat hack. Could be combined with something like a local (or statically hosted) yub to prevent leaking private information.

Later the industry began to call them "patterns" (cf Gabriel).

Another unanchored thought I've had on these matters is coming around to viewing namespace collision as a feature, not a bug. If a programming system is designed to allow you to link against a given module and more or less ignore any and every transitive dependency that this will bring in—because the programming environment makes it excessively easy to do so—then that's a pretty strong reason to consider whether or not that approach to information hiding is actually an anti-feature.

On the other hand, if during your work on a program you have to reconcile the names used within the system (i.e., such that no two module names collide), then it subtly encourages you to make sure you are able to account for every module that your program depends on.

People reflexively assume that this would make it cumbersome (or even intractable) to work on a program any larger than a toy, but empiraclly we can observe that a single, shared namespace can, by and large, scale way better than these protests would lead us to believe. It's not out of the question that a project might reach, say, 100kloc with very little friction arising as a consequence of this sort of forced reckoning. (And it's worth considering of the friction that it does impose: is it any worse than the costs we've observed over the last ~10 years from the systems that set out to solve this problem?)

John Nagle is fond of making the observation that there are three fundamental and recurring questions that dominate one's concerns when programming in C.

More broadly (speaking of software development generally), one of the two big frustrations I have when dealing with a foreign codebase is the simple question, "Where the hell does this type/function come from?" (esp. in C and, unfortunately, in Go, too, since the team didn't take the opportunity to fix it there when they could have...). There's something to be said for Intellisense-like smarts in IDEs, but I think the criticism of IDEs is justified. I shouldn't need an IDE just to be able to make sense of what I'm reading.

The other big frustration I often have is "Where does the program really start?" Gilad Bracha seems to really get this, from what I've understood of his descriptions about how module definitions work in Newspeak. Even though it's reviled, I think Java was really shrewd about its decisions here (and on the previous problem, too, for that matter—don't know exactly where FooBar comes from? welp, at least you can be reasonably sure that it's in a file called FooBar.java somewhere, so you can do a simple (and cheap) search across file names instead of a (slow, more expensive) full-text search). Except for static initializers, Java classes are just definitions. You don't get to have live code in the top-level scope the way you can with JS or Python or Go. As cumbersome as Java's design decision might feel like it's getting in your way when you're working on your own projects and no matter how much you hate it for making you pay the boilerplate tax, when it comes to diving in to a foreign codebase, it's great when modules are "inert". They don't get to do anything, save for changing the visibility of some symbol (e.g. the FooBar of FooBar.java). If you want to know how a program works, then you can trace the whole thing, in theory, starting from main. That's really convenient when it means you don't have to think about how something might be dependent on a loop in an arbitrary file that immediately executes on import, or any other top-level diddling (i.e. critical functionality obscured by some esoteric global mutable state).

Something happened that caused people to get mixed up about the idea–expression distinction. The single function as a module model is fine, but that doesn't justify the concrete technical decisions behind (e.g.) node_modules. The original development practice of just pasting the relevant code into your project should not have been sacrificed to satisfy the format/conventions of deficient tools. If function X is lifted from some other quasi-authoritative source, then the tools themselves should be improved to deal with that—not force humans to carve each of these modules up into their own repo, etc.

The design of the lix package manager for Haxe rests upon the right idea—taking the code into your repo mitigates "software erosion".

That's the explicit goal of triplescripts.org in its early stage—eliminating "implicit step 0" from software development.

Alan Kay at OOPSLA 1997: "It should travel with all the things that it needs".

See also: - Open Source is not enough - Actually portable executables - Package distribution is source distribution

A fork: https://www.colbyrussell.com/bookmarklets/creator.html

Worth considering why these private notes are not first-class Hypothes.is annotations already (even if not marked public)!

... assuming you're a Rubyist and you have gem and ruby installed.

Bob Nystrom is fond of avoiding LOC measurements in favor of number of semicolons.

Bad link (currently points to @chrisaldrich's profile page)

typo?

Wanderer:

You are looking for http://akkartik.name/about

Good use of XSLT to style an otherwise boring—and unfriendly—XML document (even though I dislike some of the specifics, like the font-size override).

The template is here: https://feeds.buzzsprout.com/styles.xsl

Why did we decide that every static site generator should invent their own ad hoc templating system again, instead just using XSLT, which is already standardized (and browser-native)?

A few comments: - I had no idea that Mac OS Server once upon a time supported wikis and that it was so featureful (includes blogs, too!). For everyone on HN and alike who are prone to saying that it needs to be easier to run a server for normal people, someone would do well to just outright copy the apparent experience showcased here. - The edit-mode transition (you can see it around @9:20) is simple and subtle and nice.

A substantial subset of the personal homepage contingency associated with blogging advocacy "movement" doesn't understand this.

Just like GitHub makes things a non-starter today, unless you've bought in to it the way non-technical people bought in to walled gardens like Facebook and excluded everyone else.

The Ui, for one.

GitHub's accessibility even wrt programmers leaves much to be desired for anyone who was familiar with highly productive workflow before GitHub came along and apparently handicapped everyone's ability to conceive how things could be any better.

See also vgr on tools: https://www.ribbonfarm.com/2022/02/10/tools/

You're looking for https://web.archive.org/web/20150310003402im_/http://core0.staticworld.net/images/article/2015/03/marriott-ord-booking-100571886-large.idge.jpg

"... unfortunately"

useful pattern

The web app accessible from the subscriptions page maintains persistent state (browser features are reimplemented in code-on-demand payloads), so it will suffice to invoke the bookmarklet once, and then it stays resident, even across "page" "loads". So one approach would be to have the user navigate to the subscriptions page, select the subscriptions, invoke the bookmarklet, automatically navigate to the first show, have them invoke the bookmarklet again, automatically navigate to the previous page and then to the next show, have them invoke the bookmarklet again, and repeat until we've gathered everything. This would make for on the order of N clicks, where N is the number of subscriptions.

Alternatively, it looks like the show pages are sufficiently RESTful (in the true sense), so we could just fire off a bunch of XHRs and parse the responses...

Also available at <https://archive.org/details/hartoriginal1965>.

This URL is referenced by Ted himself in his upload (to the Internet Archive) of the seminar "Hard and Fast Thoughts for a Softcopy World":

<https://archive.org/details/HardAndFastThoughts1966>

Meanwhile, a copy has already been available through IA, too:

<https://archive.org/details/nelson-file-structure>

(...albeit uploaded independently by Erica Fischer and not Ted.)

shouldn't

Also, this would be a good trick to use to realize "README.html":

If folks were really committed to improving the developer experience, [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html

This is also a ripe place for the toolbench pattern to manifest.

The README can both appear to take care of the ABCs and also act as the entry point to any other shell stowed away in the project. For example, in atticus.js, the README contains a line that says to run the tests "use tests/harness.app.htm on the project repo". We could kick off the build process, open up Contribute.app.htm, squirt the contents of README.txt.htm over there, and then display that to the user, making that region "live" (so actually getting to the test runner and running the tests is even easier).

Unused.

Should have probably written "this entire section (including the preceding code block and the one that follows)".

"to speak"

"blocks containing our flavored pseudocode"

Good opportunity here for the command-posting (postMessage-based) CLI paradigm.

It's not just job postings. There are a related set of problems that should be solved here.

The best thing that could happen for jobseekers in technical roles would probably be a guerilla effort to eliminate HR and internal recruiters from the job posting →interviewing → hiring pipeline as much as possible.

What should this look like? A company that actively canvases for "leads" by talking directly to the prospective applicants' would-be coworkers and that compensates them for (a) high-quality, realistic, no-BS job postings that "route around" the fluff that comes out of the other parts of the org (b) information and involvement that leads to actual hires. By the time an application actually gets to the traditional handlers, it should be more or less a done-deal ready for being rubber-stamped.

What's the source of the money faucet here? Start with existing referral programs. Maybe ask the hiree themselves to pledge a percentage of their first X paychecks (and then help them during salary negotiation to get more from the company—e.g. sign-on bonuses—than they otherwise would have gotten themselves, so it's covered).