2,977 Matching Annotations
  1. Jun 2021
    1. There’s an old saw about how you carve a statue of an elephant – you start with a big block of stone and remove all the stone that doesn’t look like an elephant. Easy!

      You Just Chip Away Everything That Doesn’t Look Like David

      (Found while looking into this, since it's said to be an "old saw" here, but I'm much more familiar with the draw the rest of the fucking owl from the modern meme-o-sphere.)

      It's an instructional sketch for "How to draw an owl" in two steps.  The first step contains some roughed-in ovals, an is labelled "Draw some circles".  The second step shows a completed artistic rendering of an owl perched on a branch, and it is labeled "Draw the rest of the fucking owl".

    1. I tried all the different static site generators, and I was annoyed with how everything was really complicated. I also came to the realization that I was never going to need a content management system with the amount of blogging I was doing, so I should stop overanalyzing the problem and just do the minimum thing that leads to more writing.

      Great way to put it. One thing that I keep trying to hammer is that the "minimum thing" here looks more like "open up a word processor, use the default settings, focus on capturing the content—i.e. writing things out just as you would if you were dumping these thoughts into a plain text file or keeping it to, say, the subset of Markdown that allows for paragraph breaks, headings, and maybe ordered and unordered lists—and then use your word processor's export-to-HTML support to recast it into the format that lets use their browser to read it, and then FTP/scp/rsync that to a server somewhere".

      This sounds like I'm being hyperbolic, and I kind of am, but I'm also kind of not. The process described is still more reasonable than the craziness that people (HN- and GitHub-type people) end up leaping into when they think of blogging on a personal website. Think about that. Literally uploading Microsoft Word-generated posts to a server* is better than the purpose-built workflows that people are otherwise coming up with (and pushing way too hard).

      (*Although, just please, if you are going to do this, then do at least export to HTML and don't dump them online as PDFs, a la berkshirehathaway.com.)

    2. I could write something to do that for me, but then I'd just end up with a static site generator anyway.

      I'm not sure this is true! The intended use has a lot more influence over how people do things than people think!

    3. I've looked at GitHub Pages/Jekyll, all the cool kids seem to be doing that? It seemed kind of complicated

      I can't wait for the people pushing GitHub Pages and building products/integrations on top of it to realize this, but I'm not sure they ever will.

    1. Why do people start smoking? Surely they know it's addictive, expensive, and bad for you

      Because of of the responses that this got, this makes for a great example of people's inability to get the question right before trying to get the answer right.

    1. Avoid 'global magic' or things that are defined outside of scope where they are not visible.

      From the commentary in the video "Workflow: Universal project folder structure"

      "I can intuit that this has something to do with[...]"

      "I look at this folder[...] and I get some sense[...]"

      "It's got this package dot bin thing, oh okay, so that means there's also a special command that I can run with this[...] you understand there is a command here"

    1. it's more convenient to to just write down the properties that you have right next to the class as you write it
    1. This would be good as a bookmarklet--when viewing an image, you invoke it, and it writes over the image with the details of the underlying structure.

      See also: "Select a window, click the 'flip' button to see what is 'behind' the window, as a metaphor to see what the application is doing"

  2. May 2021
    1. select * from users

      We can preview the data, and since that looks good, let's add a table to the canvas to display it. When we do this, it helpful pre-fills the data from our last query.

    1. many people have attached sensors

      This differs from LDN, where the the annotation service is squarely under the control of the document author. This is also using sensor attachment in a different sense that the way it first appears above. The application is more akin to RSS. With RSS, the links exist in some other "document" (or something like it; generall can be modeled as OPML, even if it's really, say, an sqlite store).

    2. So she writes an explanatory note for Jack, links the note to the Parallel Compiling report, and then links the note to Jack's mailbox: in this open hypertext system, a mailbox is simply a publicly readable document to which the owner has attached a sensor.

      Okay, so this is back to looking like LDN, except the (novel?) idea that after sending the annotation to the annotation service responsible for annotations to the report, her final annotation gets sent to that that annotation service corresponding to a different document—Jack's mailbox. Interesting!

      (Maybe this is explicitly laid out as a possibility in one of the several pieces associated with LDN and I just never noticed?)

    3. a hypermedia server might use sensors to alert users to the arrival of new material: if a sensor were attached to a document, running a new link to the document would set off the sensor

      Linked data notifications?

      (I like the "sensor" imagery.)

    1. Surely RDF already has something like this...? I tried looking around briefly but couldn't find it.

    1. transformative

      Conjecture: (almost?) every instance of reimplementation by anyone should be considered fair use on the basis that it is ipso facto transformative.

    2. consistent withthat creative progress that is the basic constitutional objective of cop-yright itself
    1. Bonus points if it can walk the user through the upstream contribution process

      I've done absolutely no actual work in this part, but this is what the third part (the C) in the "ABCs of triple scripts" is supposed to be about.

    2. that involves looking up where to find Guix's source code, `git clone`ing it, finding the Guix revision I'm currently on with `guix describe` so I can check out the same one for consistency's sake, `make`ing it, `guix environment guix`, using `pre-inst-env`, etc

      This is a direct response to the question, so it makes sense to write it out, but Spitz's piece (linked earlier) Open source is not enough describes the problem adequately.

    1. This is eventually supposed to be the default client on graph.5apps.com.

      TODOs, bugs, and ongoing development notes are organized in a semi-private Hypothesis group—invitation is required, but invitations open to anyone with the link. That includes you; here's the link to join the group: https://hypothes.is/groups/y6v5zd8n/streamline-w2g-client

    1. A w2g <cite> tag identifies/distinguishes itself in css by have a w2gid propert

      If you look at the incomplete graph.js implementation, you can see that it's actually using a class instead. This is good! However, I advocate for class names that happen to also be a hostname + resource (i.e., like URL, but omitting the http:// part).

      (I suppose that, alternatively, if someone wanted to use a shorter class name, such as "w2g-tag", then graph.js could be configured to allow for that, but it would need to be explicit configuration on the author/publisher's part.)

    1. _parseDefinition

      Revisiting this some months later while thinking about programming in general, I realize that that what I want from a nextgen magic development environment are are live comments.

      Take this _parseDefinition method, for example, and now compare it to the RSCAssembler's getRR method. The latter has a comment (with an interesting diagram), and the former does not. Suppose even that there were a comment for the _parseDefinition method—it might contain a snippet that's meant to be sample input to help visualize what the method is doing—there would still be the matter of needing to simulate the program in your head. Really, what I want is to be able to write out a snippet and then while reading the code here, anyone can mouse over each statement in the method definition and see what effect it has—say a caret moves along, pointing at the scanner "tip", and visually chunking the tokens.

      One should also be able to dynamically modify that snippet—let's say they wanted to "link" the live, scrubbable execution to a particular point in Fig. 1 (the fixT entry instead of fixP, for example)—in this case that snippet should "take over" the live comment, so we can concretely visualize execution of it instead. We should go further than that, even, and not even require the reader know which part of Fig. 1 is actually handled by this section of the code. We should be able to dynamically discover, based on the Ctrl+Space activation, that _parseDefinition is used to handle the fixP, fixD, and fixT lines, and then then reader can point to them (like the difference between a command-line interface where you have to know what you're allowed to do and how to say it, compared to a graphical interface that visually communicates the program's affordances).

      The closest I've seen to this are the Moonchild editor :https://harc.github.io/moonchild/ and REPLugger :https://github.com/Glench/REPLugger.

    1. Here's a novel(?) way to explain it that should appeal to those who claim that the host revealing the goat behind door #3 doesn't "matter":

      You are given the choice of 3 doors to pick from. Someone else is given the compulsory opportunty to "bet" against your pick. (Stop here and think of your odds of getting it right compared to their odds of beating you.)

      Now, the host reveals door #3. Your adversary originally had 2/3 odds of winning, and indeed this is where the door #3 revelation doesn't "matter": your adversary's odds that you were wrong are still 2/3. Let's mix up the game, though: suppose the host gives you the opportunity to switch places with the person betting against you—so if you switch then your adversary gets stuck with whatever your original guess was, and in the event that your original guess was wrong, then you actually win the game. This is exactly the balance of odds presented to you in the original formulation.

    1. What do we know that no-one else does? What’s a non-obvious controversial true fact? How does our system exploit this?

      Widely relevant questions beyond even the selected topic.

    1. there’s an ancient and powerful technology at work here
    2. It’s more productive to work with fewer but larger documents that bundle many bits and pieces together. If I send you a link to a section called out in the TOC, it’s as if I sent you a link to an individual document. But you land in a context that enables you to find related stuff by scanning the TOC.
  3. Apr 2021
    1. it is so because nobody owns it, we all own it. It can't go bankrupt, it can't pivot to be something else, it can't lose all its best features when a new product manager is promoted and wants to make a statement. Things that every proprietary system will do and eventually disappear.
    1. Documents should offer the same granularity.

      That neither content creators nor browser vendors are particularly concerned with the production and consumption of documents, as such, is precisely the issue. This is evident in the banner that the majority of the work has occurred under over the last 10+ years: they're the Web Hypertext Applications Technology Working Group.

      No one, not even the most well-intentioned (such as the folks at Automattic who are responsible for the blogging software that made Christina's post here possible), see documents when they think of the Web. No, everything is an app—take this page, for example; even the "pages" that WordPress produces are facets of an application. Granted, it's an application meant for reading the written word (and meant for occasionally writing it), but make no mistake, it's an application first, and a "document" only by happenstance (i.e. the absence of any realistic alternative to HTML & co for application delivery).

    1. You can do less with media that’s merely digitized than with the real thing
    2. Though its format can be copied and manipulated, HTML doesn’t make that easy.

      In fact, HTML makes it very easy (true for the reasons that lead Mark to write that it can be copied and manipulated). It's contemporary authoring systems and the typical author-as-publisher and the choices they make that are what makes this difficult.

      The future of rich media lies in striving to be more like dead media (or at least mining it for insights by better understanding it through thoughtful study), rather than the misguided attempts we've been living inside.

      (This is something that I've done a 180 on in the last year or so.)

    3. It’s designed so that whoever produced the video controls how it appears, and how it’s used.

      It is exactly that "timid" ("tepid"?) attempt at dynamism that has led to these circumstances.

    1. Ideally, GitHub would understand rich formats

      I've advocated for a different approach.

      Most of these "rich formats" are, let's just be honest, Microsoft Office file formats that people aren't willing to give up. But these aren't binary formats through-and-through; the OOXML formats are ZIP archives (following Microsoft's "Open Packaging Conventions") that when extracted are still almost entirely simple "files containing lines of text".

      So rather than committing your "final-draft.docx", "for-print.oxps" and what-have-you to the repo, run them through a ZIP extractor then commit that to the repo. Then, just like any other source code repo, include a "build script" for these—which just zips them back up and gives them the appropriate file extension.

      (I have found through experimentation that some of these packages do include some binary files (which I can't recall offhand), but they tend to be small, and you can always come up with a text-based serialization for them, and then rework your build script so it's able to go from that serialization format to the correct binary before zipping everything up.)

    1. Edit

      Why does the Edit link point to /contact/edit, but the Unpin link point to /derp/contact/unpin?

    1. Publicly display the number of users and posts on your About page.

      What is this referring to? Can't tell without diving into the source.

    1. localhost:8080/derp/
    2. shortcodes

      Link to docs on this.

    3. our guide

      "the write.as guide"?

    4. Dates are shown

      Inconsistency here between "Dates are shown" and "No dates shown" (and "Latest posts listed first", for that matter).

    5. Only you may read this blog (while you're logged in).

      Change the "mood" (?) here for unselected options so that it's quasi-subjunctive(?) so we'd say e.g. "Only you will be able to read this blog [...]". (Should probably also eliminate ambiguity about "while you're logged in qualifier".)

    1. herp

      This links me to /derp, which returns a 404 ("This page is missing. Are you sure it was ever here?")

    1. view post

      When dark mode is enabled, both this link and the "now" link appear as blue-on-black, which is too hard to read.

    1. qo1uj5qae3

      For "untitled" posts, this should probably be the post date, or maybe something like "April 20, 2021 (qo1uj5qae3)", where the autogenerated ID is de-emphasized (greyscale or something).

    1. ```go package main import “fmt” func main() { fmt.Println(“Hello, world”) }

      gaps between lines is off here.

    2. ```go

      No close fence?

    3. ![Cosmic radiation](https://i.snap.as/T05UTpx.jpg)

      Since a lot of this is guaranteed to be seen as arcane magic, maybe this is an opportune place for the UI hooks for a conversational/palette-based UI? Maybe >> to set it off?

    1. one more

      "one"?

    2. -g

      bad hygiene; unnecessary

    3. install LESS compiler

      This step prompts me for superuser privileges (it shouldn't; probably installing lessc as a global utility (it shouldn't)) and then still fails.

    4. Need to eliminate the overlap between this page and the Getting Started page.

      See also: https://hypothes.is/a/DyLhNKLsEeufFONBnjpvDw

    5. make build

      These aren't declared as phony targets in the Makefile.

    6. generate some assets and successfully run an instance

      How about a writefreely probe command that performs basic checks for this stuff?

    7. github.com/writeas/writefreely
    1. @2:00+ Subscribe widget not shown on index pages. Should be replaced with an inline deep link that addresses the widget on the actual post (shown in the video immediately afterward) by a fragment identifier.

    1. Take inspiration from the mailto URI scheme here; ideally, we should be able to re-use almost exactly the same style of URL construction.

    1. I'm very interested in this, but it's a lot of work — at least if you want to get it "right" (and I do). That would involve:

      • parallel implementations with perfect feature parity, one each in golang (for the backend) JS (for ProseMirror, which may itself need to be hacked to support our alternate impl? don't know—I haven't dived deep on ProseMirror at all, but I have some reasonable suspicions, based on some familiarity with marijnh's past work)

      Having looked into this before for my own reasons, I would probably not use any existing library from the Go or JS ecosystems. I'm pretty sure what I found the PowerShell folks settled on was the best at the time. Written in C#; would need to be ported. I expect this to be at least a couple months work, full time.

      (Not a good first bug, or even a good undertaking right now—which is why I hadn't already done it on my own.)

    1. Your data on herp is always free.

      Is this the kind of claim we want to be making at the WriteFreely level? Ideally, this statement is true on all instances, but I fear a cavalcade of hacked together versions powering instances where various promises like this get broken.

    1. Try it

      This "link" (and the "Make default editor" button) are "broken" (presumably because I don't have a pro account, but there is no clear call-to-action here).

    1. This matrix is confusing. I'm not sure I get it even now. (What's the last line "user + blogs + posts" about?)

    1. let unindented = node.textContent.replace((/^ /mg), "")

      This would greatly benefit from something like Glen Chiacchieri's REPLugger. See:

    2. this document contains minimal commentary about the structure of the object file--allowing the pseudocode speak for itself

      I have to admit that I'm totally making excuses here. Really, at the time of publication, I was just eager to get something out there, and I was (and am) not entirely motivated or sure of how to fully document the subject in the "literate" style. (Although it has to be said [see Kartik on Knuth] that it's possible no one else, even LP practitioners, really grok how to use LP, either.)

    3. Our aim is to describe an "assembler" for the RSC object file format

      Okay, so the real goal of this publication is supposed to highlight the application of a new method literate programing. I think the obscurity of the chosen subject matter (and, unintentionally, the length of the text) compromises this goal.

      Better, probably, would be something like the ZIP file format (sans compression), or maybe the under-appreciated Unix ar file format? The latter also has some nice properties that would make it tangentially relevant, too. (An archive containing only plain text files in Unix ar format is itself plain text.)

    4. // p q u v ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? // +-----+ +-----+ +-----+ +-----+ +---------------------+ +-----+ // | (4) | |a : 4| |b : 4| |op: 4| | unused : 12 | |id: 4| // +-----+ +-----+ +-----+ +-----+ +---------------------+ +-----+ // 31 28 27 24 23 20 19 16 15 4 3 0 // // p = 0, q = 0

      I'm pretty satsified with these bit-level diagrams.

    5. Tokenizer.IMPORTS = Tokenizer.KEYWORD_GROUP_BOUNDARY = 128;

      This would probably be better as:

      Tokenizer.KEYWORD_GROUP_BOUNDARY =
      
      Tokenizer.IMPORTS = 129;
      
    6. let units = parseInt(glider.content.charAt(glider.position), 16); value = ((value << 4) >>> 0) + units;

      I think these two lines give away the "surprise". The bit-shifting could at the very least benefit from an explanation.

    7. align

      I think I'd prefer in a future revision a name like orient instead of align.

    1. I made it look like a page on Github

      Everyone should "take control" of their project like this. I've said it before. The tools are already there, with GitHub pages. It should be the norm to link to e.g. ghost.github.io/foo instead of github.com/ghost/foo, and for the former to give the viewer everything that the latter gets them (except for anything that would require auth).

    1. This project will be great for instruction and portable reproducible science

      This is what I'm aiming for with triplescripts.org. Initially, I'm mostly focused on the reproducibility the build process for software. In principle, it can encompass all kinds of use, and I actually want it to, but for practical reasons I'm trying to go for manageable sized bites instead of very large ones.

    1. please use it only for bug reports

      This is a good place to prompt people to use Write.as itself as a way for voicing other kinds of feedback.

    1. I'm using this tag fo keep notes about the changes that need to be made now that Writefreely exists in its own organization on GitHub. See https://discuss.write.as/t/moving-the-writefreely-repo-on-github/2568

    1. @29:39

      In the Smalltalk community, I always had the reputation as the guy who was trying to make Smalltalk more static so it was more applicable for industrial applications. In the Microsoft environment, which is a very static world, you know, I go around pushing people to make everything more dynamic.

    1. [INAUDIBLE]

      "text"

    2. [INAUDIBLE] graphics

      "vector graphics"

    3. It was designed for secretaries and secretaries don't need to know about apps. What they want to know is about document because their job is to create documents.
    1. Should be able to use this to keep track where/when a piece was actually published

      This requires some expertise (which I don't have) and/or some market research. How are writers actually writing? Do they use Microsoft Word and then email it or...?

      How about a Twitter thread? A poll, similar in spirit to usesthis.com?

    1. Because everyone else is doing it, and content management systems programmers love to copy "features" from one another
    1. @7:40:

      We're aware that some students might actually revel in the gymnastics of a sophiscated writing and retrieval system like this. Now, we don't want to subordinate the material to the system, nor is the system merely being used to provide an alternative to a classroom experience. What we are striving for is to make a flexible system with lots of interesting material so that we may serve the needs of a genuinely contemporary student.

    1. A hypertext link to a document ought to be specified using the most logical name as opposed to a physical address
    1. Sun’s API (to our knowledge) will not call up the task of determining which great Arabic scholar decided to use Arabic numerals (rather than Roman numerals) to per-form that “larger integer” task.

      Not sure of the significance of this sentence.

  4. Mar 2021
    1. Here is what McCarthy said about it later in an interview

      This telling is also relayed in the Dragon Book (subsection "Bootstrapping", 11.2 Approaches to Compiler Development), which ends up citing, in a roundabout way, McCarthy's paper on LISP for HOPL I (1981).

    2. ho, ho, you're confusing theory with practice
    1. revist

      Typo; should be "revisit".

    2. d-blocks

      As noted above (see https://hypothes.is/a/oHvCzI1DEeuC9IvJw8DOYw), g-blocks are most appropriate.

    3. = () =>

      This construction is actually illegal in the triple script dialect. It needs to be parenthesized, as in:

      foo = ((bar) => { /* ... */ })
      
    4. "// export"

      Should be /// export for the same reason as above. (See https://hypothes.is/a/oHvCzI1DEeuC9IvJw8DOYw.)

    5. "// <script>" and "// </script>"

      Should be using //? here, now that g-blocks are a thing.

    6. before

      "before"? We only just mentioned it!

    7. carriage return followed by linefeed: ASCII 0xA 0xD

      Of course, this should say 0xD 0xA and not the other way around.

    1. we found that students who had taken high school computer science were often worse off than those who hadn't

      Interesting but also not surprising to anyone who has met firsthand the problem of trying to change programmers' minds in the face of established inertia.

    1. Backlinks

      I'm surprised that Hypothes.is doesn't support this.

      The quintessential use case should be Nelsonian "visible connections" between legal texts—all judicial opinions, petitions, briefs, etc ever filed that cites/quotes a piece of some other text, discoverable from the text cited.

    1. the debased term of REST

      Great descriptor.

      (Also, did I just accidentally run headlong into my own personal epiphany about what it means, in the terms of internet culture, to describe something as "based" and exactly how that term came to be via its relation to other words? "Based": inverse of "debased".)

    1. What system lives at reddit.com? You don't need to have downloaded a binary application in order to use that service

      This neatly captures the divide between mobile apps and websites. They both seek to solve a problem with their respective approaches each being rooted in near diametrically opposing philosophies.

    2. It's a pet peeve, but I wish that people would stop describing their HTTP RPC APIs using the term "REST".

      The only solution is probably to advocate for moving away from "REST" entirely—for all parties. Mend the discord by coining two new terms and clearly articulate the two meanings that should be attached to them.

      ("Indian" is another word like this, but that did not get fully deprecated. This is resulted in lots of confusion. "'Indian'? Like Native Americans?" "No, Indian as in 'from India'" "Oh, all right." A similar thing is happening with "open source".)

      This probably involves making the terms (or at least one of them—so long as it's the right one) somewhat cool. Maybe the non-REST term should be AROH (pronounced like "arrow") for "Application RPC Over HTTP".

    1. I was pretty annoyed with myself for having fallen for the trap of not documenting my own systems, but not sure how I could have remembered all of the Hugo-isms

      I've explained such a system, and promised Andy Chu an example that I've yet to be able to complete, but it comes down to this:

      A website is fundamentally a document repository. One of the first documents that you should store in that repository is one which explains, in detail, the procedures for provisioning the host powering the site and how content gets published. (Even better if it's so detailed that the procedures exhibit a degree of rigor such that a machine can carry them out, rather than requiring manual labor by a human.)

    2. I wanted to parrot some bullshit I picked up on Hacker News for likes

      Self-reflection and intellectual honesty is the shit. You don't have to commit yourself to your past errors.

    1. to Justify this point here. The "until statement" has been added to faci

      It would be too much of a digression to justify this point here

      I'm stealing this.

    1. There are currently three implementations of the ActivePapers concept: the Python edition, the JVM edition, and the Pharo edition

      There is only one reasonable approach, and it's not even mentioned as an option here: the browser edition. (I.e., written to target the ubiquitous WHATWG/W3C hypertext system.)

    1. lecture and recitationor rather, grace of living in historical times, lecture (here, in the French sense, reading) and transcription (or even more specifically, grace of living post-Post, lecture and reimplementation).

      Maybe something is wrong with my brain at the moment, but this is almost totally incomprehensible to me.

    1. multi-dimensional erector set that we're going forever

      "A multi-dimensional erector set that will go on forever..."

      No, unfortunately not forever.

    1. speak

      Interesting that Cheyer is/was at Samsung. In my work experience, Samsung (at least its semiconductor division) is the company I've seen most in need of Doug's methodology and the one that was least amenable to it. The way I would sum up the environment at SAS is one where folks aren't even aware of how much low-hanging fruit could be had with just plain ol' "B-level" thinking, in Doug's terms, let alone Doug's exhortation to strive for C-level.

    1. does the hypothesis team use hypothesis in any way when they're building hypothesis

      This is something I "confronted" TBL and the Solid group about recently: complete lack of dogfooding—they're all using GitHub and Gitter and whatnot, not their own tools. (Natural question arises: "if you aren't even using your own tools in your own work, how/why should we believe you when you say it will be good for us?") It's a phenomenon that I've seen commonly summarized as "X for thee, not for me".

      It also reminds me of McCarthy's response to Steve Russell's proposal to actually implemeent eval: "ho, ho, you're confus[ed]".

    1. Drag and drop

      Unfortunately, the drag-and-drop event handler overrides the ability to drag-and-drop a URL into the text input.

    1. We need a new generation of SSGs that use custom elements, and are easier to learn, with reduced complexity and simpler installation.

      Agreed on the "new generation of SSGs"; disagree on the approach that relies on custom elements.

      Having written tons of XUL and XBL (the forebears to Web components), I think they're great for their use case, but documents on the Web are a different use case. Documents (like this one) should still be documents—not late-bound portholes plugged by the browser. To really explore this space, XSL (or something like it in spirit) is still a better way to achieve the effect desired (even if XSL itself is gnarly and unattractive).

      Hypothesis is unable to cope with annotating this page, for example, because as far is it's concerned, there is no content on it.

      Build steps aren't all bad. Most of what the industry has produced in the way of tooling for the "frontend", and the threshold of acceptability those in the industry have tacitly established by use of workflows that incorporate that tooling, on the other hand, is fails to satisfy reasonable expectations.

      Food for thought: consider a website that employs a static site generator that itself lives as just another piece of content available on the site—only meant primarily for the reference needs of those authoring the site content, rather than the public at large. I.e., the website as a true dynamic knowledge repository for the associated organization, and one such piece within that repository being an active paper documenting/describing how the site is put together—to such a degree of rigor that the processes and procedures described in the paper can be performed by machine, rather than needing to be carried out by a human operator.

    2. The sidebar cuts off the page content here:

      The "Stackless." box overlapping the main text of the page on https://tutorials.yax.com/articles/the-yax-way/3.html

      Using a half-width (1080p / 2) window in Firefox.

    1. “If your goal is to teach beginners, then teach standard tooling.

      The irony is that there is very little that is "standard" about their favored approach. In fact, where there are standards, the community associated with the tools in question actually diverges from the standards.

      ("Standard" being what TC-39—including the browser makers—settled on, and NodeJS/NPM and related tools being very non-standard, advocating for incompatible abstractions. NPM, Webpack, and Babel are no more standard than TypeScript, which is no more standard than, say, ASP.NET...)

    1. FOR FREE

      Change to lowercase in the source and style with caps using CSS?

    2. Deploy your website from GitHub by authorizing a hosting service to copy your files.

      Some questions non-technical (and even technical) people might ask:

      • why am I signing up for so many services?
      • can't a just "deploy" my site on GitHub?
      • if I use a non-GitHub platform to deploy, do I really need a GitHub account? couldn't I just deploy from a folder on my computer?
    3. Give your project a name and website title.

      Too much duplication between this line and the "Give a website title" heading.

      How about, "Give some details", and, "Fill out some details about your website, including its title, a description, etc"?

    1. “These websites are built with standard web technology, the same used by any skilled web developer. But at Yax.com, it's bundled so anyone can use it without coding. Check back often as we add more website templates!”

      The font size here is almost illegible tiny on my screen in combination with the other style applied.

    2. Click the

      This is pretty jarring! I know it's supposed to be cute. It should be noted, though, that the button that appears inline here is not styled the same as the ones below.

      If the style were fixed, and there were a click handler added here that scrolled down and highlighted buttons in question, then the gimmick might prove useful.

    3. Tiny Sites Framework Forest Designer Showcase

      These links appear to point to fragments for non-existent IDs.

    1. The image here is blown up (oversized to take up too much space, and the jagged pixelated edges are showing).

    1. Try Yax Websites Tutorials Pricing Blog

      The hover effect on these menuitems puts them in light grey on a white background--very low contrast.

    2. Bandwidth

      The tooltip here is cut off at the top and on the left. (Using Firefox.)

    1. Around 9:15:

      "I'm telling you, that I don't know what to do. I'm completely lost."

      "Then you need a guide"

      [...]

      "Why don't we just start at the beginning?"

      The frustration of non-linear presentation in a nutshell.

    1. The original document file (I think - I can't test it)

      On HN, William Woodruff writes:

      Interestingly, I can open this just fine in LibreOffice 5. The alignment is slightly off, but the graphics appear just fine.

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

    Annotators

    1. * https://github.com/snaptoken, the engine behind https://viewsourcecode.org/snaptoken/kilo. The key new feature here seems to be that fragments are always shown in context that can be dynamically expanded by the reader.

      I think this example reveals a problem with attempts at literate programming in general, including something responsible for many of the things that Kartik brings up in his critique.

      The only way to do literate programming is top-down. According to Kesteloot, the only decent way to do any programming is top-down, and bottom-up straight up doesn't work. I think he's wrong on the latter point (for reasons intrinsic to what follows), but not because I disagree with him about top-down design being superior.

      The reason why literate programming hasn't caught on is because programmers aren't sufficiently interested in escaping their mind shackles. Too many of the programmers who are exploring the space, including Knuth, are bottom-up programmers and they either refuse or are unable to escape the trap of doing things in a bottom-up way, which actively works against literate programming.

      In the kilo example, in fairness, they've taken somebody else's code and tried to turn it into a literate program, so (AFAIUI) the final result matches antirez's original published source for kilo.

      Go in and replace the main implementation with a proper top-down rendition, progressively filling in the functions that are called, and then ask a programmer who is a fan of the idea of literate programming and agrees with Kartik's points what's wrong with it. Their reason almost certainly is going to hinge on efficiency. But that's the rub! They're subconsciously, even while acknowledging the shortcomings of the Knuthian approach, still themselves making arbitrary decisions to satisfy the compiler, not for the sake of readability! In fact, in this case, they're actively working against readability.

      Literate programs, with few exceptions, have to be designed and written top-down, even at the function/method level.

  5. Feb 2021
    1. The Webfinger endpoint is always under /.well-known/webfinger, and it receives queries such as /.well-known/webfinger?resource=acct:bob@my-example.com. Well, in our case we can cheat, and just make it a static file:

      Another anti-endorsement for protocols that require this level of power.

    1. In thinking about the best way to capture the essence of the editorial style in this piece and others from The New York Times in recent memory, I've settled on this: "carefully heavy-handed"—full just the right kind of subtext (which, funnily enough, can be considered a motte-and-bailey).

      Not unlike the Manhattan eruv, or a case of a co-worker at the office thinking they're clever in their use of passive aggression, it makes me wonder who they think they're fooling. Is this thought of as some sort of board game and there's an unsavvy rulekeeper to be hoodwinked? That sitting in the backseat with a finger hovering half an inch from their sibling's cheek while exclaiming, "I'm not touching you!" is sufficient to keep the adults from turning around and saying to cut the bullshit?

    1. <:https://via.hypothes.is/https://www.colbyrussell.com/LP/debut/plain.txt.htm>

      If you do view this document on via.hypothes.is as suggested and you notice some extra script cruft here near the "bottom" of the text, know this: this is in fact not part of the original document, but instead part of the support code that gets inserted by Hypothesis. This could be avoided by more care on the part of Hypothesis. Refer to a series of posts by me from last week (motivated by this case):

      If you're writing bookmarklets or Web extensions or you run a tool like the Wayback machine that requires you for some reason to inject "invisible" elements into the page, then don't just assume they aren't going to show up (especially if adding them to the body and not the head).

      Always include a style attribute on the injected element to mark it "display: none". Always—even if it's a "script", "style", "link", "meta", or whatever other element that makes you think you don't "need" to.

      If you really want to be a pal, also 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.

    2. c0 0000 00

      The "size", defined by the expression `varsize + strx + comsize + (pc + nofimps + nofent + nofptrs + 1)4; (varsize includes type descriptors*), where these names match those used by the code generator ORG.Mod. Used by the module loader for determining how big of a hole needs to be used to accommodate the module in main memory when imported by another module or invoked to service a user command.

    3. 01

      The version/class of the object file format used here. Special class 0 is used for the bootloader.

    4. b765 6d6c

      The module "key"—a signature computed by the Oberon compiler, used for verification by the linker.

      Note that this is stored as a little-endian 32-bit word. This is the native byte order. (Signed integers use two's complement arithmetic.)

    5. 4865 6c6c 6f00

      NUL-terminated module name, as ASCII.

    6. <:http://projectoberon.com>

      This syntax has been adapted as a variation of the <URL:[...]> convention from RFC 1738 (refer to its Appendix).

      The form appearing here is a more general derivation, which (a) allows the omission of the "role" atom† ("URL" in RFC 1738), with clients instructed to intepret the omission to mean that "URL" is implied; (b) better accommodates more recent conventions that omits both this atom and the colon separator entirely, encoding instead just the URL, as in <https://example.com>; (c) doesn't lead to interference with the HTML5 parsing algorithm. The latter is crucial for compatibility with mainstream browsers--the leading colon prevents the the bracketed plain text from being interpreted as HTML.

      Maybe if we were to spec this out, we'd allow an alternative for plain links of the form <@https://example.com/> (which permits no "role"--and is therefore only used where "URL" can be inferred)?

      We also want there to be a way to denote links not meant for direct navigation, but rather things that you would otherwise use the Link HTTP header or the link HTML element for. Some candidates:

      † NB: '"role" atom" is terminology of my own choosing. The RFC's authors only ever refer to it as a "prefix".

    1. In this case, is recommended that URLs be preceeded with a prefix consisting of the characters "URL:"

      It's not clear that this ever became common--most use in the wild seems to omit the "prefix" entirely.

      At https://www.colbyrussell.com/LP/debut/plain.txt.htm, I adopt an alternative "concise" form that permits the "URL" atom to be omitted, while still allowing for the colon to be left in, for reasons explained in an annotation left there:

      doesn't lead to interference with the HTML5 parsing algorithm [...] crucial for compatibility with mainstream browsers--the leading colon prevents the the bracketed plain text from being interpreted as HTML

      The idea is that the form with the leading colon should be treated equivalent to the form that omits the prefix entirely, except it may be used in contexts sensitive to parsing constraints as described above.

    1. software design on the scale of decades

      A nice turn of phrase that I really like. It goes well with the observation about the fragility of most software that is created.

  6. Jan 2021
    1. WHILE n > 0 DO Files.Read(R, ch); SYSTEM.PUT(p, ch); INC(p); DEC(n) END ; (*strings*)

      This reads string data one character at a time into the module's "address space". So why is the on-disk format for RSC string data aligned by word? The cost of instructions executed by the CPU for a call to Files.Read for a single extra NUL byte is going to be more expensive than padding up to the nearest word boundary here, in the module loader, instead of in laying them down that way by the compiler's ORG module--and that's without even considering the additional cost for disk IO!

    1. 雅兴

      On the Yax landing page right now, the steps are labelled in Chinese:

      The top part of the yax.com landing page, showing label "雅兴"

  7. flak.tedunangst.com flak.tedunangst.com
    1. You can run an open CORS relay

      Use a bookmarklet + BYFOB

    1. What's really inexcusable (hello, from anagram year 2021) is that a "proper server or test environment" should even be required. There's no inherent virtue in this. We should have the appropriate infrastructure by now that allows this to be handled using nothing more than a commodity document viewer—i.e. a web browser. The notion that you should need to drop down and run a daemon—and that this is the "proper" way it should be done—is totally backwards.

    1. replacement web browsers will still support everything

      This does not follow.

    2. It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad.

      Unfortunately true! Daniel Kehoe has been working on an antidote to this at yax.com, which he refers to as the "stackless" way of development.

    1. You cannot get a simple system by adding simplicity to a complex system.

      True and succinct in a way that lets it serve as a good memetic mindworm.

    1. belief in the Rule of Least Power, a principle that choosing the simplest and least powerful language for a given purpose allows you to do more with the data stored in that language

      Hell, yeah!

  8. Dec 2020
    1. A bad literate program is worse than no literate program at all.

      Definitely. The way I wrote this in my own notes once upon a time was:

      Conjecture:¶ Attempting to write a literate program and landing somewhere off the mark produces a program that is worse than if it were written in the ordinary tradition.

    1. All engineers really want to do is write components.

      One of the perils that most programmers are probably familiar with, especially in the early years.

    1. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two.

      This is great and a restatement of the laconic truth that the slowest build toolchain is the one that the user is never able to coax to successful completion.

    1. (Reproduced from the inaugural note to the Hypothesis group for triplescripts.org)

      Hello, triplescripts.org!

      Hypothesis is the official channel for feedback and community discussions related to triplescripts.org. And don't forget that we have a wiki at wiki.triplescripts.org (but please avoid using the Mediawiki "Talk" pages—use Hypothesis instead).

      To use Hypothesis for feedback, create an account at https://hypothes.is if you haven't already, get the browser extension or bookmarklet, and join the triplescripts.org group. (The last step is critical; make sure you're sending your annotations to the correct group and not the hypothes.is's default "Public" stream.) This is a semi-private group in the sense that you need to use the invitation link, but it's open to almost everyone willing to abide by the community rules. For more info, refer to the page on community values on the triplescripts.org wiki. Feel free to use the invitation link to invite others.

      As we progress in settling on a set of community processes and practices, they will gradually be documented both on the wiki and the official pages here on triplescripts.org.

      Our thanks to those at 5apps, Hypothesis, and Miraheze for hosting the services essential our project and many others.