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.
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]".
Dan's slides are here: https://docs.google.com/presentation/d/1PT2Q1snyn5z-zRlZbKZr9ykIxSq6NRKDcPnk2UJPx4c/present?includes_info_params=1#slide=id.g4a3a5071a1_4_44
ho, ho, you're confusing theory with practice
Drag and drop
Unfortunately, the drag-and-drop event handler overrides the ability to drag-and-drop a URL into the text input.
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.
The sidebar cuts off the page content here:
Using a half-width (1080p / 2) window in Firefox.
“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...)
FOR FREE
Change to lowercase in the source and style with caps using CSS?
Deploy your website from GitHub by authorizing a hosting service to copy your files.
Some questions non-technical (and even technical) people might ask:
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"?
“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.
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.
Tiny Sites Framework Forest Designer Showcase
These links appear to point to fragments for non-existent IDs.
The image here is blown up (oversized to take up too much space, and the jagged pixelated edges are showing).
Try Yax Websites Tutorials Pricing Blog
The hover effect on these menuitems puts them in light grey on a white background--very low contrast.
Bandwidth
The tooltip here is cut off at the top and on the left. (Using Firefox.)
The GitHub link in the top bar points to the wrong URL. It should be https://github.com/yaxdotcom/stackless-community.
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.
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://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.
by
typo (should be "my")
Simply try to do something about a problem, and many people will think you are responsible for the problem’s existence.4
This is "The Copenhagen Interpretation of Ethics".
See also: occurrences of "copenhagen interpretation of ethics strikes again" on Hacker News
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.
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?
<: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.
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.
01
The version/class of the object file format used here. Special class 0 is used for the bootloader.
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.)
4865 6c6c 6f00
NUL-terminated module name, as ASCII.
<: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:
<@!https://example.com/foo> (extending the syntax further)<:link:https://example.com/foo> (i.e. a link URI, no special syntax)† NB: '"role" atom" is terminology of my own choosing. The RFC's authors only ever refer to it as a "prefix".
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.
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.
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!
雅兴
On the Yax landing page right now, the steps are labelled in Chinese:
You can run an open CORS relay
Use a bookmarklet + BYFOB
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.
replacement web browsers will still support everything
This does not follow.
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.
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.
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!
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.
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.
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.
(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.