Okay, now suppose I wanted to annotate this from a view-source URI. Does that work?

And what about other media types, like images? I can add notes to those?

Answer: yes, but it's essentially the same situation that plain text media types have to be dealt with in.

I can add notes to plain text, right?

Answer: yes, but if viewing through via.hypothes.is, the sidebar isn't activated by default. However, hypothes.is profile pages shows that Hypothesis does work as an annotation store even for plain text, and if I manually activate the bookmarklet, I can view them "in-line" like normal.

... and I can annotate it, too, right?

typo; this should be "built"

Good example of a project for which we can say, "Okay, I know what it is—because you just told me—but not why it exists; you haven't explained what problem this is supposed to solve."

typo; this should be "provided"

solid.mit.edu is currently returning an expired certificate. This is the error that Hypothesis returns if you try to add or load annotations by entering the URL https://solid.mit.edu on via.hypothes.is.

I've said something similar about code comments. A programmer should suppress the instinct to write comments explaining how some piece of code solves whatever problem it solves. Instead, the comments should focus on detailing the problem itself. If you do a good enough job explaining the problem then many times people can arrive at your solution without needing any explanation. And in the cases where that isn't true, having understood the problem and with the code snippet at hand that solves it, they can work out the solution for themselves. Starting off by trying to explain the solution—and never getting around to the problem that motivated it—is a good way to make sure the comments aren't very useful to anyone.

There's a bug in Hypothesis (at least the sidebar client) such that it's possible to post annotations with comments to the the public, but if you want to highlight something and make it similarly public, then it's not possible...

I'm using this tag as a workaround. The annotation comment should be a Markdown-style quote (i.e. set off by an ASCII right-pointing angle bracket / less-than sign).

This seems to be a recurring theme in Walter's comments. See also https://news.ycombinator.com/item?id=25411476.

I've said in the past that many programming language macros that end up getting checked in to source control should have been written and executed as a text editor macro instead.

It reminds me of Kartik's take on "inappropriate compression".

• http://akkartik.name/post/habitability
• https://hypothes.is/a/LrwbbDo-EeuYDX-OwDWIiw

This is an interesting comment, and it's appealing to think it over. I wonder if the problem itself is a matter of perspective, and if the solution is a change in perspective?

Maybe new requirements should be treated as having a ternary attribute: known to have low impact, extent of impact not known, and known to have high impact.

Only in the case that new requirements are known to have low impact should the project try to evolve to accommodate them. In any other case, no one operates under any illusion that the project as it exists will be evolved. Instead, a new project is undertaken, and it starts out by essentially immediately cloning the "old" project to be dumped into the new project for use as a utility. Gradually the new project's functionality is brought up to meet requirements by both implementing new code, and in the place where easy wins are possible, by wrapping the old ocde. Eventually, this takes on the look of the strangler pattern, and the division between the project's new code and the old code disappears, along with the instruments for strangulation, as the old code is aggressively refactored and migrated to live as a proper first-class citizen.

This essay is flawed, but it's good. Particularly good are the comments it manages to present from Twitter—also often flawed themselves, but they really exhibit the value that people (like Geoffrey Litt https://www.geoffreylitt.com/2020/09/21/twitter-and-media-for-sketching.html) talk about when they say that composing for Twitter is worthwhile. It's better that this essay exists with its flaws than if it were never published.

Since this is a screed partially against web apps, and JS-the-language gets a lot of hate by the people who like essays like this one because of problems the see that are the doing of the cults in modern web development, I find this nugget of truth highly apropos as a retort to many people who'd endorse this essay for the wrong reasons.

Reminds me also of some recent remarks by Bob Nystrom in "Crafting Crafting Interpreters":

I don’t love Java [...] I found you can tame a lot of its infamous verbosity by simply not programming in 1990s enterprise Java style.

I've been thinking about his a lot lately, and I think the problem comes down to almost everyone (myself included) having adopted the wrong perspective and therefore the wrong practices. This is actually nice, because the "solution" is (almost) as easy as a change of perspective and the practices that follow.

The problem is the way that we think of our homepages and the way we think about how we should interact with them as the creator. Many people have a static site, and the way it works is that they first have to make conscious effort to write/create something "for their site" and then go to their site sources to make changes and then publish them. The majority of their computing is done outside this paradigm, though. Notetaking, for example. Others, rather than keeping a static site, are maybe using WordPress or something; maybe the hackers have created a homegrown CMS to their liking. But this still involves going to the site and making the change. Everyone has a homepage, but no one is truly thinking of their homepage in terms of being a real digital home.

If you have a static site, or even if you have some fancier dynamic thing going on, the nature of digital media means that it's easy to keep an always available local copy on your machine(s)—or at least it should be. For static sites, this is already very close to what's going on. I.e., even if you don't have a stable internet connection to reach your web host and go through the front door that the public goes through when, say, reading your latest blog post, well, lack of entry through that door is not exactly a problem, is it? You don't need to go through your hosting provider as a middle man. You already have direct access, locally.

The perspective change really involves two things:

1. the acceptance that pretty much all of your data should "belong" to a single namespace that represents where your personal computing takes place (your digital home)
2. and the recognition that your personal domain should be that namespace

The two areas where this change of perspective is difficult to reconcile with the real world involves (a) people who are using dynamic CMSes that aren't as easily "spun up" on their local machine, and (b) for stuff you want to keep private.

This is one place where groupthink comes in handy, though. Once people start realizing the need to actually live in their digital homes and this practice (or the attempts to adopt them) become more widespread, it introduces pressure to "correct" the tooling to accommodate this way of doing one's personal computing, so we don't have to stay on the trajectory we're currently on.

From https://news.ycombinator.com/item?id=16381988:

"My perspective is from wanting to create tools to support a "social semantic desktop" of which email is a subset of the items.

Also highly relevant:

https://www-archive.mozilla.org/blue-sky/misc/199805/intertwingle.html

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

Aaron Swartz's Open Library (operated by archive.org) was created with the motto "one webpage for every book ever published".

Here's an okay-ish introduction to Engelbart's vision:

https://www.youtube.com/watch?v=vdFejSdS9fs

And Bret Victor's commentary about Engelbart in "context" (very similar to Alan Kay's afterword at the top of this document):

http://worrydream.com/Engelbart/

Accurate, but narrating the day that he came to decide on a mission for himself and what that mission is is a recurring element in several of his speeches, interviews, and other works. [So he did say it once in an interview, but he said it many other times, too.]

Did PHP require you to write bad code with inscrutable types?

This highlights what's wrong with Webfinger as a spec (and why things like remoteStorage should not depend on it). Solid has its problems, but its heritage in linked (static) data is a a strength.

This is both a misrepresentation of the scenario described and obnoxiously out of touch. The microwave might sound like a stupid example at first blush, but it gets better if you think about it. In fact, I'd say it's a great example.

First, the "world's population" wouldn't be marking up their microwavables. It would be done once—by manufacturer.

Secondly, have you seen the kind of junk that normal people put up with regarding what's in the mass market? Using Alexa for example is often an exercise in frustration, and yet people have a use for it. (In fact, I'd bet that normal, non-technical people are more inclined to see Alexa as an attractive proposition pessimistic tech workers.) I've yet to see very many good use cases for QR codes, and yet they were super hyped up. Incidentally, this would actually be a good use case for them. And have you seen how shitty microwave "UIs" have become?

So you buy a thing, you put it in the microwave, and you scan the QR code, and it starts cooking. The QR code points to a URL, which points to a document, which the microwave fetches and adjusts its settings accordingly.

yeesh, pretty far outside HN's acceptable behavior guidelines

This is a good example of the "tunnel vision" that developers acquire--the product maintainers here are unable to empathize with their potential collaborators to the point that the collaborators can actually succeed at making a contribution to the project.

hjkl by accident actually works incredibly well on Dvorak (arguably better than on QWERTY, even), whereas wasd does not.

I think that the original 2013 essay on "end-user computing" is in places more persuasive than this 2019 perspective.

Spoken at 1:03:42 in the linked video

Around 8:50, Gilad begins talking about modules-as-specifications and no global scope.

The next generation of EPUB (rather, its replacement) should be a particular "profile" of HTML—let's call this "hbook", just to give us a convenient shorthand. The idea being that an hbook, like an EPUB, is a single file, but notably it gracefully degrades so it is viewable in "legacy" web browsers (i.e. web browsers that do not have explicit support for the hbook format), which is not the case with EPUB.

So an hbook is one long, well-formed HTML file, given some additional semantic structure. An hbook-aware reader can give an EPUB-like experience to the user, but when opened in a contemporary web browser that is not hbook-aware, falls back to appearing to the user like something they might find on Project Gutenberg.

For comparison, see "Designing Usable Hypertext Documents in Mosaic", published in ACM SIGUCCS proceedings in 1994.

Another good example of the need to eliminate implicit step zero.

Bonus question: suppose that this worked as well as it purported to back in 2007, with no hiccups (and I'm skeptical—usually there are always problems), but does it still work in 2020? (I could check, but I don't want to.)

s/expression/expressing/

This page was submitted to HN but got flagged.

I've wanted to use AI-powered voice assistants to work on code for a while. Last night just as I was about to get in the shower, it struck me again, and I spent an hour daydreaming—being able to still work while out for a walk, sketching things out in quasi-literate programming style.

It's not even that far off. Inform7's input language looks like English prose.

Rather than assertions like "The Kitchen is a room. The Dining Room is north of the Kitchen", you'd spec things like, "This program is called Nickel, and it' a static site generator. The Nickel class has a processPosts method and a processOtherPages method." You might go for a two hour walk and have a halfway working program and a nice design document fleshed out by the time you get back.

It's natural that you might be able to go home, work on the program using more conventional methods, and then feed source from the project repo back into the system for a more detailed model. Poking at things is the problem that IF parsers were actually created to handle. So the next day you might be working on it again while asking questions like, "check processPosts return type".

A one sentence retort to the kinds of comments that resemble the words in the title.

I've referred to this in a few places as software development's implicit step zero. See:

• How do displace JS
• my comment about static site generators and being "fit for mass consumption"
• triplescripts.org

I've seen critics of this post take this part the wrong way—viewing it as allegiance to the wrong side on the GUI vs CLI wars. It's a shame that those folks miss the point.

Jamie could have just as easily said here, "Siri/Alexa/Cortana/Mycroft, create a programming project with a Web form for me", and the point would be exactly the same.

The interesting thing is that in the next section, where he writes about "staring at [...] a blank editor page", he paints a picture very close to the phenomenon that I've heard so many programmers voice their complaints about—in interviews where they've been asked to solve a problem from scratch, as if their performance on that task reflected their abilities in refactoring and the "APIs and glue" part that a big part of software development involves.

The browser + JS have both of these covered.

Side note: repl.it and other cloud-based hosted services are an example of how /not/ to do it. Heed the plea for local-first software. There's something about the browser that makes people completely throw away their sense of what makes for reasonable expectations and anything they might know about traditional development workflows. Look at, say Digital Mars's download page or Ken Silverman's homepage, where they make available modest executables that consume plain text, output whatever it is they need, and work offline.

Not to mention, repl.it etc stray further into the land of magical abstractions that this post starts out railing against—more so than Eclipse. (And this is a good example of the amnesia I just described.)

What's more, shooting for the same workflow while having to work within the limitations of the browser sandbox actually ends up emphasizing the "ordinary files" mindset.

See also:

• How to displace JS
• triplescripts.org

The same goes for JS in a world obsessed with Node.

I fell for this—or, rather, the opposite of what Kay is saying. I thought programmers were especially good at thinking. I realized my mistake when I met another programmer at a volunteer event that had him drive our part of the group off-site. He was a terrible driver. I realized he must have been terrible at thinking about the kinds of things you have to think about to be a good (or merely adequate) driver. Up 'til that point, I'd believed my thoughtfulness on the road had a lot to do with the general thoughtfulness required of programmers to solve problems.

That's saying something. I don't know whether what it says is true or not, but it's certainly saying something.

The perversion has become the prescription.

Kind of like this exasperating exchange:

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

... or maybe they really did lack scruples in the way their actions suggested...

Yup, and the same goes for Web Annotations. The "I should have some control over whether and how people annotate things on my site" is the just the same old argument that was fought back in the early days of the web about preventing people from linking to (certain parts of?) your site.

To put it another way:

Web standards. Use them. In Firefox. In Gecko. To-day. Or invent a time machine and use them 10 years ago, just like any other Mozilla contributor was able to, since that's how long Firefox has been using the browser engine for its own UI—in fact, like I've said 2 other times already, it's been possible to use Gecko to do that for longer than the amount of time that Firefox has even existed.

I don't know how I can be any clearer about this. Although it doesn't seem like either of you actually care about the content of this back-and-forth, so much as you care about feeling like you've "won" it, no matter what it turns out to have actually been over. Right?

neat

Web "sites" are the problem.

As soon as people start building things to put online, they start concerning themselves with building a "site" and an experience that insists upon itself.

Nobody seems to know how to publish simple pages to the Web, and to be fair, the tooling/ecosystem is pretty bad.

This whole paragraph seems like (very thin) conjecture but reads as if it's research.

There are parallels here with open source and funding. Same problem, maybe. It's a sort of greed/frugality at play. Consider what's at the root of the OSS funding crisis:

"If we use this ready-made component, it will save us money."

So sure, you could use it, save $X, and then contribute some ε back upstream. But recall the motivation for this action in the first place—minimizing your costs. You know what's bigger than $(X - ε)? $X. So almost everyone chooses not to bother with the ε, even if they agree (logically or emotionally) with the value of partial reinvestment.

The same thing is going on here, except it's developer diligence.

See page notes about this publishing error.

See page notes about this publishing error.

There are two occurrences (highlighted here), where I slipped up and wrote "type-bound objects", which refers to something else entirely in the PL world, instead of "type-named objects", which is how I refer to them elsewhere. Oops.

There are no contact details in BlackLotus89's profile.

datproject.org's motivations are pretty closely aligned with the use case laid out here.

The post is all about musing over Mozilla's options for tracking protection, and my comment is all about false promises that Mozilla Corp made in the past, and whether they will or won't do anything in the future. My comment begins with an aside about Google's hegemony as a direct response to Ehsan's aside about Google's hegemony. It's weird to have by comment called out as being off-topic, but maybe the actual content of the post is an imperfect representation of the thoughts that Ehsan meant to express when he sat down to write it.

This is a great example of the "othering" that I called out (in the very post that Ehsan is replying to!).

When I was Mozilla-ing, Ehsan and I didn't work on the same areas of the project. IIRC, our interactions were limited to exactly one bug on Bugzilla. (I don't know what Ehsan works on nowadays, but at the time, he was responsible for Gecko's editor bindings—the code that controlled the behavior of text input elements, like the kind you see in form fields. And ultimately that bug didn't go anywhere.) Because of this, and because he doesn't recognize me as a coworker at MoCo, he immediately thinks of me as an angry user that Mozilla developers routinely deal with, rather than as a Mozillian myself. By entering this mindset, it's easier for Ehsan to be dismissive of my comment. Or in other words, the characteristic reaction to criticism that I mentioned in my first comment that was—and apparently still is—a super prevalent defense mechanism at Mozilla.

This is not the source code that anyone is talking about.

In the past when people were complaining about how integrating Firefox with a closed source service felt un-Mozilla-like, some reps and Mozilla devs on PR damage control tried to retort that the Firefox parts were open source. I.e., the code for the button that says "Save to Pocket" was open source. (Can you get more disingenuous?)

When Mozilla acquired Pocket the press announced that Mozilla "will open-source the code". It's a year and a half later, and that hasn't happened.

So no, the link to the GitHub organization here is not the Pocket source code. It's the code for the browser extension to integrate with Pocket—again, the source code for making the buttons that say "Save to Pocket"—which isn't new, because that was always open source (and trivial). To say that "the Pocket source code is now available" is misleading.