Really, this is an argument for self-containedness and not an argument against HTML and HTTP.

Granted, the Web doesn't handle compound documents very well (embedded graphics, unless they're SVG—and even then...). See https://blog.jonudell.net/2016/10/15/from-pdf-to-pwp-a-vision-for-compound-web-documents/.

Shouldn't the attribution info on this page ("admin", "July 26, 2021"...) be presented instead as Visual-Meta? Is Visual-Meta on the Web not important?

You're looking for https://www.youtube.com/watch?v=_cBGtvjaLM0

on the topic of interoperability one idea that I'm excited about is thinking about better ways to synchronize across existing cloud applications. I think there's a way in which if you're using one app and I'm using a different app and if we can establish a bridge between them, where let's say I'm editing a doc in google docs and your using Dropbox Paper or your preferred editor[...] that starts to create this more flexible feeling where the data's not locked in any individual app and it more kind of lives between the apps. And so one new project that I'm sort of embarking on now is trying to create tools that mediate that kind of synchronization across tools.

What if we used... files?

[nightmare involving a user-friendly bicycle]

There is a such thing as inappropriate use of abstraction.

For more on this https://news.ycombinator.com/item?id=27662074, and refer, for example, to NPM.

In software development itself, if you unleash a bunch of programmers on a problem and allow them to pursue their whims, you will observe that code tends toward bloat. This is not necessarily widely recognized. More broadly understood is the corollary to this that goes by the name Wirth's law, which states that software gets slower faster than hardware gets faster.

Outside of computer programming, there is a general awareness that organizations become less efficient with size. For the same reason that this happens, procedural bloat afflicts SOP just like code bloat happens with programmers.

There's a widespread belief that capitalism seeks out efficiency. With most organizations being capitalist enterprises, so the belief continues, they are an extension of this. You can see this show up in arguments about the gender pay gap. If we could cut costs just by hiring women to do the same job, they say, then we would. The veracity of the claims about the size of the pay gap notwithstanding, the claim that corporations would seize the opportunity to cut costs like this doesn't jibe with reality. Corporations are not observed to be a perfect extension of the law of capitalist efficiency. A corporation as an entity is not a perfectly rational actor operating in its own self interest, following both from the irrationality of the people who make it up and from instances of where they do behave rationally operating in their own individual self interests, counter to the organization's.

There is hardly ever a Taylor-like figure assigned to the problem of wrangling inefficiency.

Missing "Getting HTTP right" https://www.infoworld.com/article/2671157/getting-http-right.html.

Running the tests should be as easy as opening something in the browser.

How do we keep people from falling into the kind of rut that results in documentation like this?

I think it comes from an imposed milestone to document everything, so people end up phoning it in like this. In Graham Nelson's Narrascope talk (the one that was a followup to his broken promise that Inform 7 would be open sourced), you can see in his screenshots various passages filled with similar kinds of (frankly unhelpful) "prose".

Boooo...

Moved? https://tinlizzie.org/IA

See also, McCarthy's "ho, ho..." moment. https://hypothes.is/a/A_hmqoHZEeuEaEfF5uimPw

Antidotes:

• Carefully entrusting veto power to those who know the distinction between thoughtful caution as in the case of Chesterton's fence versus the kneejerk antidisestablishment response—similar to the case of the case of Rhesus ladders
• teaching the value of yes-anding over no-don'ting.

Is smoothsort stable? This quote seems to be saying it is, but elsewhere people say otherwise.

"A Constructive Approach to the Problem of Program Correctness."

Agree with the sentiment, disagree with the "remedy". (I realize it's not actually being proposed as such.)

colon-slash-slash was great in hindsight because there's sufficient entropy that if you want to do URL sniffing, you can get by with writing a really naive implementation that just looks for that sequence—you don't even have to worry about the "http" or "https" parts. In fact, I think it would be great if user agents came to grips with the dominance of HTTP and allowed links of the form starting with "://"—where the scheme name can be omitted entirely, and it is just presumed to be HTTP/HTTPS. (Use the same discovery method that browser address bars already use for working out whether "http" or "https" is the correct to go with.)

Huh?

This is really just making a strong case for the Web's notion of content negotiation, which receives pitifully little attention. The idea is that there should be some nugget comprising a cruft-free version of the resource's content itself, and it should be possible for you to specify, e.g., "No really, just elide all the JS and other accoutrements of the modern Web from the representation that you send me; basically, just give me the meat of it."

A thought by way of the Nelsonian school of hypertext:

Tim is quoted several times in this piece, which is to say that there is a larger body of content (say a recording of the interview, whether audio or a full transcript) from which this piece is borrowing snippets. Within the WWW worldview, that full record comprises a resource. Within the Nelsonian worldview of visible connections, at every place in the document where Tim is quoted, there should be an edge which the reader can traverse to reveal the unabridged record.

Not exactly an if-by-whisky, but (unrelated to the content of this article) worth serving as the launch pad for a series of examinations about why people feel compelled to couch their messages in this way—usually because the other "side" is using an appeal to emotion or appeal to reflex.

One thing I'd like forward-looking hypertext toolmakers to keep in mind is the ability for the tools to help people answer questions like "What led to legalanthology.ch hosting a copy of this document? Given a URL from one organization, is it possible to look at the graph of internal backlinks (let me focus narrowly on incoming edges originating from the same host)?"

This is where people with a tendency to participate in JS development frequently start to go off the rails. Exercise some restraint and tell that voice in your head that has been influenced by years in the community "no".

(PS: typeof checks need not and should not be written to use triple equals. Again, this is an example of where the dominant culture of modern JS development is a bad influence—pushing people towards doing things poorly. It's like radio and TV announcers who go out of their way to say "backslash" in URLs—"stop! you're going through extra effort just to get it wrong.")

Another broken link.

Broken link. See https://hypothes.is/a/JFM4yvuIEeuujaO6c6FwyA

You're looking for https://solidproject.org/self-hosting/css.

See also the sepsis inspector project.

or BYFOB.

With S4, we can do better.

How not to futureproof your work.

"Console application" is a Windowsism. Even the new Microsoft can't escape the strong pull of its legacy.

This URL is linked (in error) from the The Screening Room index.

You're looking for http://jonudell.net/udell/2006-10-01-the-screening-room-9-windows-live-writer.html

From Linus Torvalds Remembers the Days Before ‘Open Source’:

Torvalds counters that “I wouldn’t trust Lyle Ball’s recollection 100% about me… since my girlfriend-at-the-time (now wife) name was Tove, not Ute.”

Neat.

The incident described in this post provides a good case study for why the GitHub pull request process is not a good substitute for wikis.

Regarding missing 1993/1994 archives:

See https://lists.w3.org/Archives/Public/www-talk/2016JulAug/0005.html

See also https://www.w3.org/Proposal

Try https://www.w3.org/Administration/HTandCERN.txt

You are (probably?) looking for https://www.w3.org/Addressing/URL/Overview.html

Referenced from http://info.cern.ch/hypertext/WWW/Bibliography.html.

This page is now a 404, and the Wayback Machine (whose first access attempt is dated 2013) doesn't have a copy. (It was already a 404 by then.)

The document you are looking for can be found at https://www.w3.org/Conferences/IETF92/udi2.txt

Actually just 1 version here; the two are the same, with one URL available over plain HTTP and the other over HTTPS.

I have found reference, however, to "udi1.ps" and "udi2.ps". Unclear at this point what the difference is between them.

The quote that begins about halfway through this trailer in full is, "He tells a lie, and people go to track this down, and by the time you've responded to that, he's told three others. It's a sheer exercise in fatigue."

Speaker is Jelani Cobb.

Dubious claim. It doesn't even appear that those using it wrong are a substantial minority — as much as those with a commercial interest in manufacturing alternative facts would like for people to believe there are.

"2,097,152 = 2^21"

Great turn of phrase

Funnily enough, I've been on an intellectual bent in the other direction: that we've poisoned our thinking in terms of systems, for the worse. This shows up when trying to communicate about the Web, for example.

It's surprisingly difficult to get anyone to conceive of the Web as a medium suited for anything except the "live" behavior exhibited by the systems typically encountered today. (Essentially, thin clients in the form of single-page apps that are useless without a host on the other end for servicing data and computation requests.) The belief/expectation that content providers should be given a pass for producing brittle collections of content that should be considered merely transitory in nature just leads to even more abuse of the medium.

Even actual programs get put into a ruddy state by this sort of thinking. Often, I don't even care about the program itself, so much as I care about the process it's applying, but maintainers make this effectively inextricable from the implementation details of the program itself (what OS version by which vendor does it target, etc.)

Like people who can't wrap their head around the idea that evolution has nothing to do with any kind of purpose to produce humans. (Even starting from the position that humans are the "end result" is fundamentally flawed.)

Here: https://cacm.acm.org/magazines/1999/10/7806-technical-opinion-comparing-java-vs-c-c-efficiency-differences-to-interpersonal-differences/fulltext

"CSS"?

This is overall a good piece, although it does contain some errors, but this claim is probably the weirdest and wrongest.

"its"

"Demos"

"WebKit-derived"

"fewer"

See also a lightly differing follow-up (billed as a crosspost): https://www.w3.org/People/Berners-Lee/1991/08/art-6692.txt

interesting taxonomy; useful for communicating about a concerted effort towards a more document-oriented correction to the modern Web?

See https://www.w3.org/People/Berners-Lee/1991/08/art-6484.txt

See https://www.w3.org/People/Berners-Lee/1991/08/art-6692.txt

You're looking for https://www.rfc-editor.org/rfc/rfc5322.html

See https://www.w3.org/People/Berners-Lee/1991/08/art-6487.txt

"in tow"

"Cornell"

Lots of punctuation mistakes in these two "sentences"—one being that this isn't really two sentences, since the second is a fragment, but it could be fixed by swapping the period for a colon or em dash.

"it's"

"version"

See https://www.w3.org/LineMode/

Available here and here:

• https://www.w3.org/History/1989/proposal.html
• https://cds.cern.ch/record/1405411/files/ARCH-WWW-4-010.pdf

Actually reads:

I like the browsing style this should make possible. Intuitively right and potentially user-friendly. But it could be frustrating—how do we know we can get it right? Demo of existing systems? Invaluable tool for services

Content also available (including the original word processor file) from https://www.w3.org/History/1989/proposal.html

From CERN, a PDF scan of the original (includes the infamous handwritten note "Vague but exciting...": https://cds.cern.ch/record/1405411/files/ARCH-WWW-4-010.pdf

Referenced in an HN thread:

https://news.ycombinator.com/item?id=12793157

In the thread, William Woodruff mentions that LibreOffice is capable of displaying this file.

Huh?

Alt, you mean? (No Windows here; can't test, but it seems like that would be the right way to do it.)

I'm partial to the "Principle of Least Power" in the Axioms of Web Architecture document cited in the bibliography. (The language there better captures the thought and presents it more convincingly, in my opinion.)

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

Another transcript available here: https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_The_Computer_Revolution_has_not_Happened_Yet

Another copy here: https://www.youtube.com/watch?v=aYT2se94eU0

Another copy here: https://www.youtube.com/watch?v=oKg1hTOQXoY

I don't even think that's it. Plenty of people are willing to do with poor UX. (Look at GitHub.) The overriding factor is actually a consistently familiar interface. (Look at GitHub.)

Related: https://www-archive.mozilla.org/unity-of-interface.html

Makes sense. As I've said before, you should not fool yourself—"you have to create a compelling product before you can ever realistically even start thinking about selling people on a general platform".

The thing that most of these projects' fans think that these projects have going for them is the technology, but that's not really interesting to anyone except enthusiasts who spend all their time talking amongst themselves.

Perversely, the author starts off getting this part wrong!

The correct answer here is to adopt the same mindset used for print, which is to say, "just don't worry about it; the value of doing so is oversold". If a print org changed their layout sometime between 1995 and 2005, did they issue a recall for all extant copies and then run around trying to replace them with ones consistent with the new "visual refresh"? If an error is noticed in print, it's handled by correcting it and issuing another edition.

As Tschichold says of the form of the book (in The Form of the Book):

The work of a book designer differs essentially from that of a graphic artist. While the latter is constantly searching for new means of expression, driven at the very least by his desire for a "personal style", a book designer has to be the loyal and tactful servant of the written word. It is his job to create a manner of presentation whose form neither overshadows nor patronizes the content [... whereas] work of the graphic artist must correspond to the needs of the day

The fact that people publishing to the web regularly do otherwise—and are expected to do otherwise—is a social problem that has nothing to do with the Web standards themselves. In fact, it has been widely lamented for a long time that with the figurative death of HTML frames, you can no longer update something in one place and have it spread to the entire experience using plain ol' HTML without resorting to a templating engine. It's only recently (with Web Components, etc.) that this has begun to change. (You can update the style and achieve consistency on a static site without the use of a static site generator—where every asset can be handcrafted, without a templating engine.) But it shouldn't need to change; the fixity is a strength.

As Tschichold goes on to say of the "perfect" design of the book, "methods and rules upon which it is impossible to improve have been developed over centuries". Creators publishing on the web would do well to observe, understand, and work similarly.

Odd choice of a pairing between context and link destination. Again, this seems to come down to a misconception (or—less charitably, a misrepresentation—of how Web standards progress).

CADT most aptly describes the NPMers on GitHub, not the rudiments of the Web platform. (Or if anything, the types of folks pushing such misguided efforts as Gemini, ironically enough...)

Something which should be standardized, by the way. Signing up for an account on Neocities or Netlify should be just as readily available over a neutral, non-HATEOAS client as their bespoke APIs for updating content. (Their APIs, for that matter, should be deprioritized where vanilla HTTP would suffice.)

Furthermore, it's nice that reading from DNS is standardized, but proprietary control panels are anathema to the general accessibility (that is, to the general public) of this aspect of Internet infrastructure. The mechanisms for writing/editing DNS records should be just as standardized as the ones for doing lookups.

Right. Which is why the folks working on Web standards have endeavored to make stability a goal up to this point and beyond; the Web is one of (if not the) most stable piece of widely adopted computing infrastructure that exists. The author's conception of Web standards is at odds with reality.

Perhaps it's not possible. (Probably not, even.) It would be very much possible to build a web browser capable of handling this page, on the other hand, and to do so in a way that produces an appreciable result in 10 minutes of hacking around with the lowliest of programming facilities: text editor macros—that is, if only it had actually been published as a webpage. Is it possible to do the same for if not just this PDF but others, too? No.

Great. This is something that I advocate for technical people to put forth as a "serious" solution more often than I see today (which is essentially never). But next time, save it as HTML. (And ditch the stylistic "rubbish"; don't abuse "the sanctity of the written word by coercing it to serve the vanity of a graphic artist incapable of discharging his duty as a mere lieutenant".)

I have a rule that any response that begins with someone having typed out "Eh" is empty and/or junk. (The response here is no proof by contradiction.) In other words, one is free—or perhaps obligated—to meet the zero-effort dismissal with a similarly dismissive response.

(The author purports to address the following, but just uses some rhetorical flourishes and misdirection. In an effort to not let that go unnoticed and to hold his or her feet to the fire...)

How does this type of "we should" differ at all from saying "we should use HTML 4 with no JS" or "we should use EPUB"?

This is probably the least flawed claim in the entire piece.

Overall, I'm pretty happy with the level of scrutiny the claims here are being subjected to over on HN. https://news.ycombinator.com/item?id=27880905

(One of the rare times on HN in recent memory where a potentially attractive position on what could have been a contentious issue involving techno-pessimism related to the Web seems to thankfully be overwhelmingly opposed, in recognition that the arguments are not sound.)

The formatting of this link is messed up.

It was only 6 days ago that an effective takedown of this type of argument was hoisted to the top of the discussion on HN:

This latter error leads people into thinking the characteristics of an individual group member are reflective of the group as a whole, so "When someone in my tribe does something bad, they're not really in my tribe (No True Scotsman / it's a false flag)" whereas "When someone in the other tribe does something bad, that proves that everyone in that tribe deserves to be punished".

and:

I'm pretty sure the combination of those two is 90% of the "cyclists don't obey the law" meme. When a cyclist breaks the law they make the whole out-group look bad, but a driver who breaks the law is just "one bad driver."¶ The other 10% is confirmation bias.

https://news.ycombinator.com/item?id=27816612

This person is confused, though it's obvious and understandable to those who've been down the road before how it happens. Most mainstream languages that are taught to be "pass by reference" are actually of the "pass by reference value" sort. Lack of exposure to languages that actually implement pass by reference is the culprit. Of course if your experience is limited to C, C++, Java, and others that use the "pass by reference value" approach, then you'll come away thinking that "pass by reference value" is what "pass by reference" means and this is what any and every language "ALWAYS requires" when setting out to implement "pass by reference"—you just don't have the appropriate frame of reference to see how it could be otherwise.

This doesn't work well with scripts (and style elements) injected by the Hypothesis bookmarklet or the Wayback Machine's toolbar. On that note, it's pretty poor hygiene on their part to (a) inject this stuff in the body to begin with, and (b) not include at the very least a class attribute clearly defining the origin/role of the injected content. As I described elsewhere:

set the class on the injected element to an abbreviated address like <style class="example.org/sidebar/2.4/injected-content/">. And then drop a page there explaining the purpose and requirements (read: assumptions) of your injected element. This is virtually guaranteed not to conflict with any other class use (e.g. CSS rules in applied style sheets), and it makes it easier for other add-ons (or the page author or end user) to avoid conflicts with you.

Dealing with it this way is a mistake. The only reasonable thing to do is to tell the user to adjust their browser's default font settings or deal with it. (This seems to only affect Firefox's default UA stylesheet/preferences, not Chrome.)

Check out how the most recent iteration of the w2g streamline "client" https://graph.5apps.com/LP/streamline approaches styling.

This is important. See for example, the recent revelation that even with all the book digitization efforts, archive.org does not necessarily have imagery for a given volume's spine, even if the front cover and back cover were photographed!

The world could benefit from a curated set of bookmarklets in the style of Smalltalk ("doIt", "printIt", etc buttons) that you can place in your bookmarks bar (or copy into a bookmarks document and open in it in your browser), where the purpose would be to allow you to:

1. access a new scratch area (about:blank) for experimentation
2. make it editable, or make any given element on a page editable
3. let you evaluate any code written into the scratch space

scratch.js aims for something something similar, and though laudable it falls short of what I actually crave (and what I imagine would be be most beneficial/appreciated by the public).

Putting people first or persons first (i.e. egos first)? Because the latter is what you get under the current social paradigm.

I've also articulated this point, but in a negative context. This piece speaks of actor-indexed content in a positive light. I maintain that actor-indexed content is on the whole negative. It's a direct and indirect cause of the familiar social media ills and has wide-reaching privacy implications, which is bad in and of itself, but especially so when you realize that this in turn leads to a chilling effect where people simply opt not to play because it's the only remedy.

We'd do well socially to abandon the "game-changing" practice of indexing based on actor and return to topic-based indexing, which better matches the physical world.

Useful analysis.

You can say the same for any number of things that GitHub natives usually put their thumb on scale for in order to not count it among the costs of using GitHub. This type of "blindness" is a recurring issue that has come up every time I've tried to have a discussion about the costs of GitHub.

In fact, the reverse ("I won't interact with anyone who isn't using GitHub") is the default for many (most?) projects hosted on GitHub.

You can blame "GitHub-Flavored" "Markdown" for that.

Far too few programmers understand this, which creates a conversational nuisance. I'm not sure why, though. Charged with writing out explicitly the explanation for why it's true, you might come away thinking it's so because the issue is deceptively nuanced.

... but it's not that nuanced.

This should really not pose as big of a problem as it does, and yet I see the "cache miss" occur way too often.

Is it, though? From where I'm sitting, GitHub has been good for exactly two things. Getting the uninteresting one out of the way first: free hosting. Secondly, convincing the long tail of programmers who would not otherwise have been engaged with the FOSS scene to free their code, by presenting a shimmering city on the horizon where cool things are happening that you'd be missing out on if you were to remain stuck in the old ways that predate the GitHub era's collective mindset of free-and-open by default. That is, GitHub strictly increases the amount of free software by both luring in new makers (who wouldn't have created software otherwise, free or not) and rooting out curmudgeons (who would have produced software of the non-free variety) with social pressure.

I'm less convinced of the positive effects on "the choir"—those who are or were already convinced of the virtues of FOSS and would be producing it anyway. In fact, I'm convinced of the opposite. I grant that it has "changed the way [people] collaborate", but not for the better; the "standard way of working" referred to here by my measures looks like a productivity hit every time I've scrutinized it. The chief issue is that undertaking that level of scrutiny isn't something that people seem to be interested in...

Then you have GitHub's utter disregard for the concerns of people interested in maintaining their privacy (by not exposing a top-level index of their comings and goings to anyone who asks for it —and even those who don't—in the way that GitHub does, again, whether you asked for it or not).

It reminds me of The Chronicle's exhorting ordinary people to support the then-underway cause intended to banish Uber and Lyft from Austin, on ostensibly populist grounds, when in reality the cause was aimed at preserving the commercial interests of an entrenched, unworthy industry. I saw a similar thing with the popular sentiment against Facebook's PATENTS.txt—a clever hack on par with copyleft which had the prospect of making patent trolls' weapons ineffective, subverted by a meme that ended with people convinced to work against their own interests and in favor of the trolls.

Maybe it's worth coining a new term ("anti-rebellion"?) for this sort of thing. Se also: useful idiot

Like the parent comment by derefr, my actual, non-hypothetical practice is saving to the Wayback Machine. Right now I'm probably saving things at a rate of half a dozen a day. For those who are paranoid and/or need offline availability, there's Zotero https://www.zotero.org. Zotero uses Gildas's SingleFile for taking snapshots of web pages, not PDF. As it turns out, Zotero is pretty useful for stowing and tracking any PDFs that you need to file away, too, for documents that are originally produced in that format. But there's no need to (clumsily) shoehorn webpages into that paradigm.

If you do the print-to-PDF workflow outlined earlier in the thread, you'll realize it doesn't scale well, requiring too much manual intervention and discipline (including taking care to make sure it's filed correctly; hopefully you remember the ad hoc system you thought up last time you saved something), that it's destructive, and that it ultimately gives you an opaque blob. SingleFile-powered Zotero mostly solves all of this, and it does it in a way that's accessible in one or two clicks, depending on your setup. If you ever actually need a PDF, you can of course go back to your saved copy and produce a PDF on-demand, but it doesn't follow that you should archive the original source material in that format.

My only reservation is that there is no inverse to the SingleFile mangling function, AFAIK. For archival reasons, it would be nice to be able to perfectly reconstruct the original, pre-mangled resources, perhaps by storing some metadata in the file that details the exact transformations that are applied.

Yes. The problem also with relying on programmers' blogged opinions for advice and understanding is that a lot of the material is the result of people trying to work things out for themselves in public—hoping to solidify their own understanding by blogging—and it's not expert advice. Aspiring programmers further run the risk of mistaking any given blogger's opinion for deep and/or widely accepted truths. (And JS in particular certainly has lots of widely accepted "truths" that aren't actually true. Something about intermediate JS programmers has led to an abundance of bad conventional folk wisdom.) Indeed, spot-checking just a few of the links collected in the list here reveals plenty of issues—enough to outright recommend against pointing anyone in its direction.

On the other hand, the problem with the ECMAScript spec is that it has gotten incredibly complicated (in comparison to the relative simplicity of ed. 3). There is a real need for something that is as rigorously correct as the spec, but more approachable. This was true even in the time of the third edition. In the early days of developer.mozilla.org, the "Core JavaScript Reference" filled this hole, but unfortunately editorial standards have dropped so low in the meantime that this is no longer true. Nowadays, there is not even any distinction between what was originally the language reference versus the separate, looser companion for learners that was billed as the JavaScript guide. The effect that it has had is the elevation of some of the bad folk wisdom to the point of providing it with a veneer of respectability, perhaps even a "seal of approval"—since it lives on MDN, so it's gotta be right, right?

Better to use querySelectorAll and then filter based on figure designation (e.g. nodeValue.startsWith(" (Fig. 1) ")).

Unused!

(Caller should also probably look more like:

let system = new SystemB(document);
system.attach(document.querySelectorAll("script"))

... where the querySelectorAll return value's role is to act as a list of document figures, for the reasons described elsewhere https://hypothes.is/a/-n-RYt4WEeu5WIejr9cfKA.)

it looks like my comment got moderated out, and I didn't save a copy. Not going to retype it here, but the gist is that:

• Ward invented the wiki, not just the sliding panes concept.
• Sliding panes are a riff on Miller columns, invented by Mark S. Miller
• Miller columns are like a visual analog of UNIX pipes
• One obvious use case for Miller columns is in web development tools, but (surprisingly) none of the teams working on browsers' built-in devtools at this point have have managed to get this right!

Some screenshots of a prototype inspector that I was working on once upon a time which allowed you to infinitely drill down on any arbitrary data structures:

https://web.archive.org/web/20170929175241/https://addons.cdn.mozilla.net/user-media/previews/full/157/157212.png?modified=1429612633

https://web.archive.org/web/20170929175242/https://addons.cdn.mozilla.net/user-media/previews/full/157/157210.png?modified=1429612633

Addendum (not mentioned my original comment): the closest "production-quality" system we have that does permit this sort of thing is Glamorous Toolkit https://gtoolkit.com/.

Possibly true, but dubious.

Typo; should "philanthropic".

See https://en.wikipedia.org/wiki/Fragile_base_class

Should be "mistakes".

As an experienced user, this claim strikes me as false.

I often start in a graphical file manager (nothing special, Nautilus on my system, or any conventional file explorer elsewhere), then use "Open in Terminal" from the context menu, precisely because of how much more efficient desktop file browsers are for navigating directory hierarchies in comparison.

NB: use of a graphical file browser doesn't automatically preclude keyboard-based navigation.

something, something, Erlang

This could benefit from examples.

See also: woodworkers

Later, Why do we need new terminology?.

http://web.archive.org/web/20061210231152id_/http://akamai.infoworld.com:80/weblog/udell/gems/ju_mynewgig.mp3

http://jonudell.net/udell/gems/ju_mcgraw.mp3

http://jonudell.net/udell/gems/ju_burbeck.mp3

http://jonudell.net/udell/gems/ju_gemignani.mp3

http://jonudell.net/udell/gems/ju_rosenfeld.mp3

http://jonudell.net/udell/gems/ju_frost.mp3

http://jonudell.net/udell/gems/ju_idehen.mp3

http://jonudell.net/udell/gems/ju_HillMcFarland.mp3

http://jonudell.net/udell/gems/ju_linqMay06.mp3

http://jonudell.net/udell/gems/ju_singleton.mp3

http://jonudell.net/udell/gems/ju_martinez.mp3

http://jonudell.net/udell/gems/ju_rodgers.mp3

http://jonudell.net/udell/gems/ju_rayhill.mp3

http://jonudell.net/udell/gems/ju_dcstat.mp3

http://jonudell.net/udell/gems/ju_hudack.mp3

http://jonudell.net/udell/gems/ju_glushko.mp3

http://jonudell.net/udell/gems/ju_patrick.mp3

http://jonudell.net/udell/gems/ju_mayfield.mp3

http://jonudell.net/udell/gems/ju_xbrl.mp3

http://jonudell.net/udell/gems/ju_suber.mp3

http://jonudell.net/udell/gems/ju_fielding.mp3

http://jonudell.net/udell/gems/ju_windley.mp3

http://jonudell.net/udell/gems/ju_navizon.mp3

http://jonudell.net/udell/gems/ju_fahlberg.mp3