37 Matching Annotations
  1. Last 7 days
    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

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

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

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

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

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

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

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

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

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

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