59 Matching Annotations
  1. Dec 2020
    1. font-size:10pt

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

    Annotators

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

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

    2. font-size:10pt

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

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

  2. solid.mit.edu solid.mit.edu
    1. 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.

    1. Show me a program's code but not its tests, and I shall continue to be mystified. Show me its tests, and I won't usually need its code; it'll be obvious.

      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.

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

    1. this anecdote is one of the reasons that I've strongly resisted adding macros to D

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

    1. projects go quietly bad when they experience some sort of new requirement that gets underestimated in terms of its architectural impact

      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.

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

    2. a technology solution to a problem that doesn’t need any technology, just a little bit of common sense.

      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.

  3. Nov 2020
    1. I’m not always connected to a stable internet connection

      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.

    2. I really do mean everything

      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

    3. Linking to the book’s Wikipedia entry would be my preference but very few books have an entry

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

  4. Oct 2020
    1. computers could be the vehicle for dramatically improving this capability

      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/

    2. Douglas Engelbart once said in an interview

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

  5. Sep 2020
    1. I started off in PHP. It was wild. Anything could be anything.

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

    1. Since this is static file hosting, the query string is being ignored. So all Webfinger requests will return the same data. This in violation of the spec, but I'm not aware of how else to implement Webfinger using static files.

      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.

    1. the world's population spend their days semantically marking up All The Things to get the most of their web-enabled microwaves

      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.

    2. all this semantic web stuff was one of soulless dorks

      yeesh, pretty far outside HN's acceptable behavior guidelines

  6. Aug 2020
    1. After looking at the sprawling dependency tree, and the effort it would take to set up a build environment --- which might not even give me the same output as the original binaries, which are working perfectly fine except for the part I want to change

      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.

  7. Jul 2020
    1. hjkl makes about as much sense on Dvorak as wasd.

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

    1. Everything was small and my heart sinks for Linux when I see the size [inaudible]. The same utilities that used to fit in eight k[ilobytes] are a meg now. And the manual page, which used to really fit on, which used to really be a manual page, is now a small volume with a thousand options... We used to sit around in the UNIX room saying "what can we throw out? Why is there this option?" It's usually, it's often because there's some deficiency in the basic design -- you didn't really hit the right design point. Instead of putting in an option, figure out why, what was forcing you to add that option. This viewpoint, which was imposed partly because there was very small hardware ... has been lost and we're not better off for it.

      Spoken at 1:03:42 in the linked video

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

  8. Jun 2020
    1. That should do it.

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

  9. May 2020
    1. 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".

  10. Apr 2020
    1. Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin.

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

    1. if we were to hand Anon the entire lunch_app source code they would likely still struggle

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

    2. But Anon the intern needs to be able to open up Programming™ and click ‘New Web Form’

      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.

    1. Provide a standardized environment - as a VM, perhaps, or using something like repl.it or ideone - perhaps a similar software designed specifically for education. Use a language that teaches the fundamentals of the paradigm you’re interested in, like Scheme or Python.

      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:

    1. I found you can tame a lot of its infamous verbosity by simply not programming in 1990s enterprise Java style.

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

  11. Feb 2020
    1. I have met hundreds of programmers in the last 30 years and can see no discernible influence of programming on their general ability to think well

      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.

    2. When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good.

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

    1. lashed back on the system when their "babysitters" where taken away

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

  12. Jan 2020
    1. 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.

    1. Using standardized web tech for the Firefox UI is not "in the realm of possibility". It is possible. Full stop. It has never not been the case.

      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?

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

    1. In the 19th century

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

  13. Jan 2019
    1. it's bringing you enough value that you ought to be able to spare the effort of doing the basic due diligence

      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.

  14. Oct 2018
    1. type-bound objects

      See page notes about this publishing error.

    2. type-bound objects

      See page notes about this publishing error.

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

  15. Sep 2018
    1. If someone as a solution for this or if perkeep could be expaned (or has the option somehow hidden somewhere) I would be very happy if somebody could point me in the right direction

      There are no contact details in BlackLotus89's profile.

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

    1. has nothing to do with what I’m writing about

      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.

    2. We have no shortage of bitter users, each with their own pet peeves on what they think Mozilla should have done right. And they all see all Mozilla developers

      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.

    1. Seems like at least some of the Pocket source code ins now available on GH.

      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.