Is this what the tech world achieves in practice?

This raises an (un?)interesting issue: if ASU's ranking improves, but its reputation does not—because the news never reaches those who have internalized its status as a party school—what then? You can imagine someone returning to school now, picking ASU, and then showing up to a job interview or landing within a pool of coworkers or an after-work social event where attendance is dominated by B players who remain uninformed. It's not hard to imagine someone "losing" so many arguments on the basis that that person went to ASU, ASU is for dumb people, and ipso facto they are wrong.

So exclusion is the answer: we should seek to exclude the types of people for whom this strain of intellectually lazy argument is an attractive weapon, and ideally also exclude those who respond positively to its use.

This is not a well-written blog post.

(That isn't to say it contains no insights or that the insights are not true. Only that it is not well-written.)

Myers, Brad A. “The Case for an Open Data Model,” August 1998. http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-153.pdf

Important to note that what's also left out of this picture of software design being left up to designers is the staggering amount of software with positively bad UI and UX that people have forced on them all day in the form of e.g. awful enterprise software. The notion that the masses somehow need designers' (proper designers) involvement in software is just flatly contradicted by reality.

And on that note there's also the matter of choice—if you were to hire a designer who did something you didn't like, you'd get rid of them. Among all the software that people interact with every day, whether it's terrible enterprise junk or an iOS app designed with a self-anointed designer, there isn't one in which the user actually hired anyone to do the UI. The publisher/whomever just makes the thing and says, essentially, "here you go; take it or leave". That's what's really on offer in the world made too favorable to designers and not malleable enough to users.

No. Throwing the NPM world into insanity. The author of the Guardian article got this right. (The slug is literally npm_left_pad_chaos.) There's no excuse for this sort of equivocation.

Of all the stuff in the world, JS is the one thing that's closest to having the robustness values desired in this blog post. TC-39's motto is literally "Don't break the Web".

So stop building within those systems (i.e. on crummy foundations).

I think this is too curt of a dismissal. The browser environment, while not suitable for computationally expensive, long-run experiments, is certainly adequate for a great many things that could be "solved" by targeting it, even though they currently are not. Things like converting a simple assembly listing into a 512-byte program.

(Compare: https://www.colbyrussell.com/LP/debut/plain.txt.htm.)

This is a real problem/the real problem.

This is an interesting remark from the vantage point of 50 years in the future.

Worth pointing out that this (Tomcat) comprises a component in and of itself. It is because this component was available that this step can be dashed off as "[just] importing Tomcat"—rather than "write a program that binds to port 80 and returns a 404 for any resource requested".

I believe it, but I would have liked to have seen a reference for this claim.

It would be nice to hear a 20-year retrospective from Lampson on this, in light of the creation and rise of e.g. npm and other npm-like "language package managers". (He doesn't really acknowledge this in his 2020 omnibus report Hints and Principles for Computer System Design.)

You use only a small fraction of the features of each component, and your program consumes 10 or 100 times the hardware resources of a fully custom program, but you write 10% or 1% of the code you would have written 30 years ago.

This is:

Lampson, Butler W. “Software Components: Only the Giants Survive.” In Computer Systems: Theory, Technology, and Applications, edited by Andrew Herbert and Karen Spärck Jones, 137–45. Monographs in Computer Science. New York, NY: Springer, 2004. <doi:10.1007/0-387-21821-1_21>.

A different take on the "pick two" quip ({on time, within budget, bug-free})

This is:

Lampson, Butler. “Hints and Principles for Computer System Design,” November 2020. https://www.microsoft.com/en-us/research/publication/hints-and-principles-for-computer-system-design-3/.

The trend here wouldn't be so bad if, in practice, public libraries didn't become such hostile environments for the two classic use cases for libraries—that is, "places to: a) read quietly; b) study". It's unfortunate, then, that they have (at least in my experience).

Hear, hear! This is a great response to anyone calling for regulation aligned with Google's Web Environment Integrity proposal (and similar forms of DRM): "Regulation? Okay, let's regulate you—so you cannot do this thing you're trying for."

It's like how copyleft was invented to allow the GPL to use copyright to work against the prurient interests of those normally wielding it.

Very concerning. "DRM the Web" is a very apt descriptor for what's at the end of that link. I seem to have missed the news.

Yes, it does look like that, which is a little frustrating/baffling already, but the bug is "xmlStrlen is 2–30 times solwer than glibc strlen". That's a well-defined issue. Respond to that, not the context (which is out of scope). The bug is not, "help us speed up our application".

I'd rather we focus for now on maximizing it to its current potential as a more convenient digital equivalent for pre-Web physical resources. Just getting people to embrace URLs—truly embrace them—is a big enough task itself. It's been 30+ years, and not even Web professionals and other (ostensibly smart) people on the periphery (e.g. techies) reliably get this stuff right. Indeed, they're often the biggest offenders...

I'd argue that this is a good thing. I think the tech industry's navelgazing does perhaps some of the worst harm wrt the problems articulated earlier.

Pretty fucked up, actually! It's true. And it's probably why software engineers (incl. e.g. CACM folks...) do such a poor job of managing their digital document depositories and generally fulfilling the potential of the Web as it was meant to be.

This is:

Hendler, James, Nigel Shadbolt, Wendy Hall, Tim Berners-Lee, and Daniel Weitzner. “Web Science: An Interdisciplinary Approach to Understanding the Web.” Communications of the ACM 51, no. 7 (July 1, 2008): 60–69. https://doi.org/10.1145/1364782.1364798.

Amazon doesn't, however, as TBL has already noted, make its A/V media available as first-class Web resources. (What's the URL for a recent blockbuster available for streaming through Amazon's Prime Video program?)

It was really "UDI" (Universal Document Identifier) even before that. See:

Berners-Lee, Tim, Jean-François Groff, and Robert Cailliau. “Universal Document Identifiers on the Network,” 1992.

Also: computing generally.

This one:

Marco, Matthew Tangco. “The Form of the Web Browser and Its Social Effects.” PhD Thesis, Georgetown University, 2011. http://hdl.handle.net/10822/552929

Not to be confused with https://www.w3.org/History/1989/proposal.html

See also: https://www.w3.org/History/1990/WWW/FIND/Hyperizing_FIND.wn/

Traveller:

You may benefit from this link, instead https://www.w3.org/History/1991/HTRejected.wn/WNDocument.wn

(Not sure if it's actually the same as what's supposed to be available here.)

Note that as of this writing, the site at that link now identifies the same file as "Word for the Macintosh document (v4.0)". I think the MacWrite II diagnosis is more plausible. No idea what changed.

Good and sensible.

This could* pretty trivially be converted into a triple script.

* and should be

A good(?) case study in why these "papers" should be... papers (and not six-pagers* with directories of source code that exist "over there").

cf https://www.colbyrussell.com/LP/debut/

* 19 in this case

Chris (incl. his intuition) isn't wrong—static sites really do exist and are special. Consider: - files "served" from the local filesystem, i.e. what you get if you access a collection of resources saved to disk and opened in your browser - how much can be captured by a crawler (e.g. Wayback Machine) - bounded limits of computation: serving an HTML artifact (or some other static resource) is guaranteed to terminate

See also:

So, time to update the website, but the first wall I hit was that I:

1. Forgot how my over-engineered SaaS was supposed to be used (no documentation because I built it myself and was lazy)
2. Forgot how to follow the esoteric Hugo conventions (has documentation, but it's not easy to parse at a glance)

I was pretty annoyed with myself for having fallen for the trap of not documenting my own systems, but not sure how I could have remembered all of the Hugo-isms, especially since I don't update this site very often and don't do static site generator work outside of this.

https://web.archive.org/web/20210331182731/https://corytheboyd.com/posts/2020-03-09

(Previously: https://hypothes.is/a/U742AodQEeu5T2dEN4YdWQ)

Nope (re: offline). You're confusing "browser-based" and "Web-based" (sort of the way people confuse statically typed" versus strongly typed*). They're different. You can have a fully offline browser-based interface. Most common browsers are every bit as amenable as being used as simple document viewers as Preview.app or Microsoft Word is. The browser's native file format is just a different sort—not DOCX, and not PDF (although lots of browsers can do PDF, too; you can't write apps in PDF, though—at least not in the subset supported by typical browsers). Instead of Office macros written in VBA, browsers support scripting offline documents in JS just like online documents. You can run your offline programs using the browser runtime, unless they're written to expect otherwise.

This is:

Wang, April Yi, Andrew Head, Ashley Ge Zhang, Steve Oney, and Christopher Brooks. “Colaroid: A Literate Programming Approach for Authoring Explorable Multi-Stage Tutorials.” In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, 1–22. Hamburg Germany: ACM, 2023. https://doi.org/10.1145/3544548.3581525.

This is an error/defect on the part of the author.

This misses the point of LP—the true "fundamental theorem of LP" is basically that the compiler should be made to accept the preferred form.

Should be "there"

The server isn't redirecting requests at the apex domain to www..

"Fixing" the RSS-vs-Atom problem: brand Atom as "RSS3" (sexy)—and make sure there are accommodations (read: plenty of RFC 2119-style MUSTs, MUST NOTs, etc) for podcasts while you're at it.

The "Standard Ebooks toolset" should just be... an ebook. That your browser can execute. (Because it's a ubiquitous runtime target that requires no setup...)

Question: what even is the "NPM hypothesis"? I.e. what is the value proposition, stated in the form of a falsifiable claim?

Should be "crannies"

What if console services (i.e. services offered by the system software for hardware game consoles) offered an asset cache?

Notice the total lack of addressability of this piece of content (in re the submission "The GMP library's repository is under attack by a single GitHub user" at <https://news.ycombinator.com/item?id=36380325>)

picolog.blue is missing

... because the server is configured like that.

(This is not a property of the language.)

Dynamic languages are not a prerequisite to this.

Good example of how when people are talking about a thing, they're often not really talking about it—they're saying something about themselves, their environment, how they do things, etc.

See also xkcd 1172: Workflow

This looks to be imagined.

This is the basis of the article. It would be nice if, in all the words here, it were actually substantiated.

Okay, now this is the problem statement(s). I don't see that the notice is doing these things (telling someone otherwise or "actively misinform[ing] their patrons"). It looks like it's totally in step with what is actually true.

Who—outside of this article—is saying anything like that?

I missed the part where the writer established that this was the case. What law are they referring to?

wat

You upend your values before attaining the near-infinite money (in order to attain it).

This is exemplary and deserves to be more fashionable than it is in 2023.

This is so weird; why isn't the Etherpad project wiki an Etherpad instance?

This is:

Wright, Alex. Cataloging the World: Paul Otlet and the Birth of the Information Age. New York, NY: Oxford University Press, 2014.

Nice turn of phrase—"platitudinous proclamations" (p. 88)

Remember: forms are just forms.

If they don't provide a form that is sufficiently "inert", then anyone (including FSF) can create their own.

"ChatGPT will say things that aren't true" seems perfectly adequate. I don't understand why this dumb debate—over the definition of the word lie—is even happening (to the extent, if any, that it actually is...)

Not even close.

JS succeeded because it was well-designed, period. There were many, many contenders in the early days—despite popular historical revisionism to the contrary. All of them failures.

This is:

Hilse, Hans-Werner, and Jochen Kothe. Implementing Persistent Identifiers: Overview of Concepts, Guidelines and Recommendations. London: Consortium of European Research Libraries, 2006.

It would be even worse if no such error message appeared: a URL may also be unstable in that it now points to a different resource that has replaced the earlier one.

Since this is yet another piece of journalism that covers a set of cases before the courts with citing the cases in question by name, here they are: - Students for Fair Admissions v. Harvard - Students for Fair Admissions v. University of North Carolina

Language runtimes that don't ship by default on Windows have historically been harder to install than utilities like gzip in my experience.

You can swap "lawyers" here for just about anyone—including (or "especially"?) software developers.

See also: cars.

My last comment here, the this hate, along with the fetishization of === over ==, is one of the most overblown aspects (and arguably: outright just incorrect stances) about language design when it comes to JS.

This has nothing to do with JS. It's not a language-level concern; the same would be true with any other language. Python, Ruby, Scheme, C#... pick literally any other language. It's a totally orthogonal issue.

Weird. TraceMonkey and JagerMonkey are just codenames for different approaches for fast execution/evaluation of JS in SpiderMonkey. They're not holistic JS language implementations unto themselves in the vein of, say, CPython vs IronPython.

In other words, the "problem" is the opposite of "fragmented runtimes"—it's that JS runtimes are so strictly committed to compatibility at the language level (to a degree not seen in any other widely deployed tech that I can think of). There are clear downsides (such as the sentiment expressed here), but there are also massive upsides. On net, the alignment is a huge win.

This is true, but also pretty huge non-issue. The only way it could possibly be an issue is for someone who just objects to the notion of function-valued expressions generally (fans of Pascal, maybe? I dunno) or someone who against all good sense believes that a pair of parens should result in the introduction of a new scope (weird).

You already know why: the semipredicate problem. (In other words, for a similar reason why you might want a number type to be nullable even though you already have 0.)

This criticism is not just ignorant. It's stupid.

A passive failure to make a special case ("optimise") for array operands in binary expressions with + is not the same thing as actively optimizing for "two comma-seperated[sic] strings without a comma in the middle".

Mmm... no. It often is—to the world's peril—but it's not the architecture that makes this so. It is a choice of node operators to return some resource X when a given identifier is referenced on day d[0] and to return resource Y on day d[1].

On the contrary. It is the lack of stability that makes (reliably) linking virtually impossible. How do stable links make linking more difficult...?

They already are.

It doesn't. It leads to no more (or fewer) resources than otherwise. It does lead to an "explosion" of identifiers.

Think about the silliness of casting aspersion on the notion of "[many] resources, each with its own distinct identifier". The fundamental premise of the Web is that this is a good thing; if you have a slew of resources, you should be able to (unambiguously) refer to them by identifier.

Response: the question is malformed. The problem lies in the belief that it's possible for content to change. It can't. If it appears to, then it is only because the server is returning a different resource than whatever was previously available. Don't reuse identifiers for different resources. Mint a new identifier.

This is:

Evans, M.P., and S.M. Furnell. “The Resource Locator Service: Fixing a Flaw in the Web.” Computer Networks 37, no. 3–4 (November 2001): 307–30. https://doi.org/10.1016/S1389-1286(01)00204-3.

It's my contention that this is a matter of people misusing the URL (and the Web, generally); Web pages should not be expected to "update" any more than you expect the pages of a book or magazine or a journal article to be self-updating.

We have taken the original vision of the Web -- an elaborately cross-referenced information space whose references can be mechanically dereferenced -- and rather than treating the material as imbued with a more convenient digital access method and keeping in place the well-understood practices surrounding printed copies, we compromised the entire project by treating it as a sui generis medium. This was a huge mistake.

This can be solved by re-centering our conception of what URLs really are: citations. The resources on the other sides of a list of citations should not change. To the extent that anything ever does appear to change, it happens in the form of new editions. When new editions come out, nobody goes around snapping up the old copies and replacing it for no charge with the most recent one while holding the older copies hostage for a price (or completely inaccessible no matter the price).

not an example of something gone wrong with DNS

I don't understand this criticism at all.

There are a lot of papers cited in this presentation that aren't cited explicitly and in detail in the associated "transcript": https://web.archive.org/web/19980215203333/http://www.parc.xerox.com/spl/projects/oi/towards-talk/transcript.html

(E.g. Wirth "On the Design of Programming Languages" @25:00.)

It would be nice/useful to go through the video, grab the moments where these are referenced (incl. screenshots of the slides), and collect them into an orderly works cited rider doc.

Hey, traveler. Try this instead:

https://web.archive.org/web/19980215203333/http://www.parc.xerox.com/spl/projects/oi/towards-talk/transcript.html

Not sure why this is detached from the thread it belongs to, but it appears to be this one:

https://mastodon.social/@shriramk/110556924858987180

By a reasonable guess, no matter what the actual (vs stated) requirements are, they'll be overstated.

Do they? (This is almost certainly a coordination problem, right?)

Isn't that just drawing from another exhaustible resource? Think end game. Don't we converge on an equilibrium where we are no longer able to exploit the outsized gains?

Related: see the "web of documents" tag on Hypothesis.

Again: we're way past that—and it's not broadly accessible simulated word processors that got us there. (It's actually Web developers themselves.)

I think that's a good thing, for the reasons described here: https://hypothes.is/a/TF6N6AxHEe6qM_dG0VlZzw. We should stop treating the Web as a sui generis medium and elevate it to the same status as material that appears as written word made for print.

I don't even think that these arguments are that compelling. In the first place, URLs are explicitly stated to be unreliable indicators of content—they are opaque. https://hey.look.a.verylegit.link/filehost392index-ip-stealer!.xlsx.docm.exe is as valid a URL as any PURL, or the URL to this very blog post.

Most of the other points come across like more application of the double standard.

We're past this, though, even in the world of "proper" Web development. Look at anything you consider to be "of" the Web. Take this blog post as an example. There's a double standard at play, considering that if you peer at the page source, it's by and large worse than the sort of thing that you'd have gotten out of Frontpage, Dreamweaver, etc. 20 years ago. And this isn't even an SPA or other Google Docs-like creation of the sort that this post focuses on.

I think the key here is "[...] published on Google Docs". Consider instead: "Something radical can be prepared with Google Docs". There's nothing stopping anyone from using Google Docs in the same way that traditional desktop word processors are used—by working on your stuff and then saving a copy to your own disk (using Google Docs's "File" menu). Pick your own format—DOCX, ODT, etc., but note that HTML mostly works quite well...

In fact, it being on your own disk is beside the point; you can put the thing anywhere—it doesn't have to stay "on" (read: in) Google Docs. Put it online if you want. (I refer again to https://crussell.ichi.city/food/inauguration/.))

I'm not entirely sure that's true. I'd wager that's incidental; the main goal seems to be to give people access to a word processor in the form of a Web app, and the fact that they've figured out a way to make money on it is... not coincidental, but certainly "serendipitous" or "fortunate" (in the way that it's fortunate to be able to make money off any kind of software created for some other reason than to make money).

I dislike the use of "doc" as nomenclature here. "Document" works perfectly fine.

See also: Zawinski's Law.

The writing here is super obscure. I don't like it.

See also:

Google Docs is one of the best ways to make content to put on the Web.

https://crussell.ichi.city/food/inauguration/

I feel, in some circumstances, the opposite way.

The problem, as Feynman pointed out, is that it's very easy to fool yourself.

So much of software development practices are driven by people loosely (read: unrigorously) reasoning about things. Few people form hypotheses for which we can articulate some means of proving or disproving what is being claimed.

This is a very useful but underutilized property. It allows you to e.g. announce in advance that a resource will exist at some point in the future, and thereby effectively receive "updates" to the linking document without requiring changes to the document itself.

By and large, this is what 23 years of software trends in browser-based development have given us, unfortunately.

Another good jumping off point for why document mutability should be considered harmful. https://hypothes.is/a/N_gPAAmQEe6kvXNEm10s7w

This is:

Fielding, Roy T., and Richard N. Taylor. “Principled Design of the Modern Web Architecture.” In Proceedings of the 22nd International Conference on Software Engineering, 407–16. ICSE ’00. Limerick, Ireland: Association for Computing Machinery, 2000. https://doi.org/10.1145/337180.337228.

This is a good launching point for my contention about Modification Considered Harmful.

I'll go further and say that, wrt the original goals of the Web—and the principles we should continue to strive for today, despite widespread practice otherwise—Modification (should be) Considered Harmful.

Git has the right idea. Hypermedia collections should also be append-only (not different resources masquerading under the same name).

This is highly dubious—you're talking about two completely different resources at that point.

If I send you a link to a page on a dynamic site written in PHP like standardebooks.org, and then I send you a link to the GitHub repo showing the source of the script responsible for intercepting the request and responding with the page that you actually see when you visit the first URL, are those really two different representations of the same resource? Or two different resources? It's the latter.

There is a desire to rectify/reconcile this with WebDAV, because you want to be able to "address", say, cart.php—which is in principle not a bad thing (it's very much a good thing, really)—but merging two resources into the same namespace is not the solution, and bad hygiene should not be excused.

This appears to be among the only uses of this phrase wrt AJAX.

This is:

Fielding, Roy T., Richard N. Taylor, Justin R. Erenkrantz, Michael M. Gorlick, Jim Whitehead, Rohit Khare, and Peyman Oreizy. “Reflections on the REST Architectural Style and ‘Principled Design of the Modern Web Architecture’ (Impact Paper Award).” In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, 4–14. ESEC/FSE 2017. Paderborn, Germany: Association for Computing Machinery, 2017. https://doi.org/10.1145/3106237.3121282.

A thought: this kind of support should be in the purview of the Wikimedia Foundation. They have an ample endowment, and in 2021, their revenue was $162 million vs $111 in expenses. They could outright pay for every copy that the World Book sells, or cover the costs of a give-one-get-one program.

Some ways that this could work out to enrich the commons: a licensing deal where the photographs in World Book become available under CC-BY-NC-ND (i.e. gratis to share) two years after publication and then CC-BY-SA (sufficiently permissive so that it would allowed to be imported into Wikimedia Commons) after, say, five years following initial publication.

See also: emerging from the theater when there's still daylight, or pulling off your skates and walking around in your own shes when leaving the rink.

I've revisited this post a lot. Here's a relevant link to discussion between the author of this post and Mark Adler:

https://github.com/madler/sunzip/issues/7

In light of Mark's insistence of certain things, Greggman's hedging seems more reasonable. I'm still of the opinion that Mark is wrong, though; Greggman had it right the first time.

This is "MSC:CV RESPONSE TO MOTION FOR NEW TRIAL Defendants' Opposition to Plaintiff's Motion for Trial Setting"

awful

Terrible name choice! EscapeText (or EscapeTextForHTML if you want to be really verbose) is the most correct (and less footgun-y) way to refer to this.

I wonder how many security problems the name EscapeHtml will lead to...

The Web, you mean.

NB: This refers to the the musical artist, not the (non-existent) Madonna, Texas.

This is an ordinary bug and not worthy of note in a document about the relative strengths and weaknesses of WebDAV (or any other protocol); it's not an inherent consequence of WebDAV as designed...

should have been "[...]a=23189,00.asp"

should have been http://www.pcmag.com/print_article/0,3048,a=23189,00.asp

i.e., s/1=/a=/

should be "IETF"

should be "IETF"

This page is dense with references. It's an excellent candidate for marking up and connecting to the other documents it references, Xanadu-style

what the FSF (GPL) calls "preferred from for modification"

should be "W3C"

except TBL did imagine them -- browsermakers (outside CERN) didn't

that's a feature (not a bug)

should be "HTTP"

should have been "[...]a=23189,00.asp"

should be "IETF"

Files which render themselves when published (e.g. templates or other scripts) will be rendered when accessed from a mounted WebDAV volume. This is because WebDAV clients issue a GET (it's an extension of HTTP, after all) to hand you your data. You can't simply mount a WebDAV share and start editing PHP files, for example. Until a data type is provided for source code-based documents, this will remain a problem.

This is a node-/organization-level information architecture problem.

If /foo.php is a script that generates a Web page, then separate identifiers need to be assigned for each resource (one for the document itself, and one for the script that generates it). It is a failure of the node not to distinguish between the two. A separate content type would not solve this problem—it would just appear to cover it up (as well as create new ones).

Traveler,

Try https://web.archive.org/web/20021019234705/http://www.pcmag.com/print_article/0,3048,a=23189,00.asp

Locking: Locking protects web team members from overwriting each other’s changes. When two or more people are working on the same file, WebDAV ensures that they compare or merge changes before writing to the file.

Git solved this problem in a much cleaner and respectable way: it's an append-only log. The only thing left is to "flatten" the two namespaces into a single one. On first inspection, this seems like it would re-introduce the need for rewrites (and locking?), but this can be cleverly solved by preregistration of forward references. Locating the current "head" can be resolved in log2(n) time wrt number of "revisions" (and can also be avoided in many cases, besides).

How does WebDAV work? Each of your colleagues — whether they’re in Bangalore or Bangor — mounts a WebDAV volume located on the shared web server to his or her desktop. They can then access its files as they would any other networked volume.

This is a pretty unsatisfying description of what WebDAV (and the underlying spirit) actually offers.

Mounting a remote host like a local disk is not without its (limited) use and convenience, but it's neither the intent nor the extent behind the spirit of WebDAV.

I think there's a category error here.

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

There are several points where there is a gesture/reference to something on the screen ("This is a headline", "Here is a talk"...) where what's shown on the screen is doing the heavy lifting.

Don't just say, "here [it is]", though. Mention the presentation and author by name when speaking. The screen is a complement.

Consider: there's no reason in principle why this entire presentation couldn't be a "blogcast" (a blog post in audio form).

This accounts for ~all programmers. It's not just a matter of people presenting themselves as having credentials that are just backed up by monkey-see-monkey-do IT cargo cultism. Programmers write bugs.

It's not really clear what this section has to do with the overall talk. How is this (specifically the part about all programmers creating bugs) mitigated or addressed by the contents of this talk?

There's a hard transition after this point, but it comes in such a way that makes it seem like what's next is something that will expound in some detail upon this point.

This def. needs to be more fully developed.

Maintaining access to past works due to any number of reasons including file format lock-in (even when the software in question is open source) is actually a huge deal.

(It is my contention that this accounts majorly for a bunch of the problems in e.g. the NPM ecosystem.)

This whole thing could stand to be more fully developed. I don't have any specific advice, it just seems unclear and feels like a nonsequitur upon reaching the end and moving on to the next topic.

I have a lot to say about this, but I'll be succinct and just say, "don't conflate a language with a particular community that uses that language—even if that community has achieved culturally dominance".

What does this mean, though? Concretely, I mean. (Could stand to qualify/quantify this.)

I was surprised to find about a ~month ago that LÖVE is written in C++. Its scripting support is Lua-based.

Not sure that this is a good argument. The fact that someone is using $LANG in such a way (for "conquest") doesn't have any bearing on how you have to use the language.

Coming from a place of evaluating an argument on soundness and rationality, the conclusion/advice given (use Lua) is only about half a step removed from PL hipsterism—at least when evaluating the reasons actually stated. (There may be a stronger argument here, but it's obscured by this one.)

Maybe not necessary for the intended audience but might benefit from distinguishing between bonafide forks vs what GitHub has done to the word.

Isn't that a contradiction?

Note that these two things are at odds. Literate programming (to a high standard—higher than Knuth's standards, viz [1]) is probably the single best thing that enables the former, but it works against the latter.

1. http://akkartik.name/post/literate-programming

huh?

lame

See also: http://www.ariadne.ac.uk/issue/31/web-focus/

Try https://www.w3.org/Provider/Style/URI

In a book? Yes.

You mean price guide books? If so, yes.

Yes.

Yes.

Yes.

rsync.net would be really great for repo hosting if you could trivially pair it with something else to get public repos. You can't, though.

This pretty much the basis for Kartik's criticism in Literate Programming: Knuth is doing it wrong.

Thought experiment: what if you elevated the documentation to first-class status rather than as low-stakes generated artifacts that can be blown away and regenerated? What if you modified your compiler to consume the documentation and produce the same binary as the one produced by what you now consider to be your source code?

See https://hypothes.is/a/QZJW9PPLEe2LeiNwpwbj6A

In other words, it risks undermining the intent of the API design.

Cox published a copy of this text on his homepage:

https://web.archive.org/web/20021109120553/http://www.virtualschool.edu/cox/pub/92ByteWhatIfSilverBullet/index.html

Confusingly, he labels it there "What if there's a Silver Bullet... And the Competition Gets it First?"—which seems to be the title of an ~~entirely different article (... and which itself is confusingly named 92ByteWhatIfSilverBullet, even though it is described as "An editorial for the Journal of Object-oriented Programming in June 1992. Republished in Dr. Dobb's Journal in Oct 1992.")~~

Huh?