Not like a static site generator, that's for sure. Normal people don't a step in between input source code and the output. They don't want a difference between input and output at all. Programmers want a compilation step, because they're programmers.

Dubious.

Modula and Oberon should have been codenames rather than independent projects.

C programmers balk and cry, "JavaScript!"

NB: "Engelbart"

One of my favorite turns of phrase about programming. I come back to it multiple times a year.

Jonathan Blow recently revisited this topic with Casey Muratori. (They last talked about this 3 years ago.)

What's a little absurd is that (a) the original discussion is something like 3–6 hours long and doesn't use recursive descent—instead they descended into some madness about trying to work out from first principles how to special-case operator precedence—and (b) they start out in this video poo-pooing people who speak about "recursive descent", saying that it's just a really obnoxious way to say writing ordinary code—again, all this after they three years ago went out of their way to not "just" write "normal" code—and (c) they do this while launching into yet another 3+ hour discussion about how to do it right—in a better, less confusing way this time, with Jon explaining that he spent "6 or 7 hours" working through this "like 5 days ago". Another really perverse thing is that when he talks about Bob's other post (Parsing Expressions) that ended up in the Crafting Interpreters book, he calls it stupid because it's doing "a lot" for something so simple. Again: this is to justify spending 12 hours to work out the vagaries of precedence levels and reviewing a bunch of papers instead of just spending, I dunno, 5 or 10 minutes or so doing it with recursive descent (the cost of which mostly comes down to just typing it in).

So which one is the real chore? Doing it the straightforward, fast way, or going off and attending to one's unrestrained impulse that you for some reason need to special-case arithmetic expressions (and a handful of other types of operations) like someone is going to throw you off a building if you don't treat them differently from all your other ("normal") code?

Major blind spots all over.

There is, actually. Look at Google Docs, Office 365, etc. Those are all an end-run around the fact that webdevs are self-serving and haven't prioritized making desktop publishing for casual users a priority.

The webdev industry subverts users' ability to publish to the Web natively, and Google, MS et al subvert native Web features in order to capture users.

The users are there.

I think this is too pithy. It's hard to make out what applies to which actors and what's supposed to be good or bad; in order for me to understand this, I have to know a priori Kartik's position on division of labor (it's bad), then work backwards to see what the equations are saying and try to reconstruct his thinking. That's the opposite of what you want! The equations are supposed to be themselves the explanatory aide—not the thing needing explanation.

Looking at the screen captures, one thing I like about HIEW is that it groups octets into sets of 32 bits in the hex view (by interspersing hyphens (-) throughout). Nice.

Geez. What?

I'm not even sure Brent actually believes this so much as that he felt the need to post a defense. Or maybe he really does believe it. But it needs no defense.

And the a couple months went by and Apple introduced Swift—decidedly not a scripting language—and eventually Brent bought in almost all the way.

This suggests that the source code wasn't available before the NFT auction. It's been public domain for 30+ years.

Often when I think about the problem of disruptions, environmental distractions, &c. which often results in total productivity death, I'm reminded of Licklider's "getting into a position to think" quip. It's not what he meant when he said it, and when I read him, I understand what he meant, but I somehow always forget and instead most strongly associate it with the process of eliminating disruptions.

Yeah, no.

It's not that difficult.

Scan backwards for the magic number. If you find it, keep scanning and look for other occurrences. If you only found one, then congratulations: you're done—you found the end of central directory record.

The fact that metadata defining the bounds of the comment block are in the end of central directory record at a fixed offset makes this super easy: for each candidate record, assume that it's a well-formed record and compute the boundaries of the comment block. Also compute what would be the boundaries of the start and end of the central directory record. If any of the boundaries are somehow illegal (e.g. they lie past the end of the file), then clearly this candidate is not the right one. If the offset of any candidate record lies within the boundaries of the comment block defined by an earlier candidate record, then the earlier record takes primacy and the later record should be eliminated as a candidate. Of the candidates that remain, choose the one nearest the end. That's it.

How could this possibly pose a problem...?

Inspired by https://en.wikipedia.org/wiki/Template:Should_be_SVG.

See https://w3c.github.io/csvw/.

This would be a good candidate for WebCSV (also known by the more official but definitely worse name CSVW).

Note that this registry omits things such as NOTIFY and M-SEARCH from SSDP (part of the UPnP spec and described on the Cloudflare blog as "poorly standardised"[1] but used nonetheless for various devices, such as Roku[2]).

1. https://blog.cloudflare.com/ssdp-100gbps/

2. https://developer.roku.com/docs/developer-program/dev-tools/external-control-api.md

This is RFC 2774.

[Laughter] Said, "Yeah, okay. It's a miracle." And I said, "Actually, it's not— you know, even if somebody's copying something, it doesn't mean it's not a miracle. It could still be a miracle. I'm not precluding a miracle there. I'm just saying somebody copied.

NB: this isn't logically consistent.

Well, that's something you chose, not something imposed upon you.

So sidestepping the sorts of things that result in dark blue text with red links on darkish green backgrounds?

Here's one: "But why?" In other words, "What problem does this solve?"

The author describes in this article a pathological instance of what I've been calling "orthogonal version control systems".

And I think this whole story was made up in jest, but it's basically the principle behind NodeJS/NPM's package.json design—subvert your project's source tree and well-founded version control discipline with your own cockamamie scheme.

Okay. What do we think about Victorian life?

JS is used pervasively with Gnome. As prior art, JS had always been a major part of the Firefox codebase—the app was built with XUL widgets and XBL, which was essentially JSX and Web Components before those ever existed. With a lot of focus on making JS engines fast after Google introduced V8 with Chrome, Gnome started looking at alternative suggestions to GTK-with-C for app development on Gnome. About a year or two before GitHub released Atom, the Gnome folks convened and said that JS was going to be not just a tier-1 language for GTK, but the language that the project would push for Gnome desktop app development. By then integration was pretty mature and had proven itself.

This upset a lot of people on Planet Gnome, though, and they basically revolted. Gnome as a project ended up putting out Gnome Shell, but sort of softened the prior commitment to JS. Too bad. Instead what we got was NPM and Electron, which in addition to tending to bring things bad enough on their own have also gone on to infect the places where you'd have traditionally encountered JS (i.e. web development).

Most people who boot into a Gnome desktop and open up Firefox and then proceed to opportunistically rail in online forums against "JS" (when what they mean is "the NodeJS community and the way that NPM programmers do things") are either unaware of the state of affairs, or are aware but constantly forgetting—i.e. acting and speaking indistinguishably from the sort of people who don't know these things. It's weird. JS isn't slow. It isn't bloated. (Certainly not in comparison to, say, Python.) You can write command-line utilities that finish before equivalent programs that are written in Java do, and if you avoid antipatterns peddled as best practices (basically everything that people associated with Electron suggest you do), you can make desktop apps snappy enough that no one even knows what's happening behind the scenes.

It's a massive shame that the package.json cult has cannibalized such a productive approach to computing.

Great pitch.

Hey, traveler. You'll be interested in: * https://archive.org/details/wholeearthreview00unse_9 * https://wholeearth.info/p/whole-earth-review-spring-1987

Huh?

I'd call this quaint in hindsight, but it was obvious with basic levels of foresight that Firefox OS was going to fail.

lol, what?

You're almost there, buddy. You're so close.

This whole thread feels like an apolitical art project from the types of people who hang out in /r/SelfAwareWolves.

Interesting that the way this is framed tries to give it an incredibly positive spin. In reality, you might as well say, "Look how many bugs we're able to write (and still get people to use the project)."

Fuck. I just noticed that this line was in here!

Use stable interfaces instead of unstable ones at the appropriate software boundaries. It's a shame that this needs saying.

Untrue. It is not the presence of these things that "can be outright dangerous". If the programmer is reckless—doing things he or she shouldn't be—then certainly things can get dangerous. But it's a basic responsibility of the programmer not to be reckless.

This is:

Taivalsaari, Antero, Tommi Mikkonen, Dan Ingalls, Krzysztof Palacz, Antero Taivalsaari, Tommi Mikkonen, Dan Ingalls, and Krzysztof Palacz. 2008. “Web Browser as an Application Platform: The Lively Kernel Experience.”

Boy, this is hard to read. I know Marcel has blogged about this, so I won't mention my usual prescription that every academic article needs to be accompanied by a blog post. But I do wish every academic article were required to come with a single page cover sheet that authors are required to fill out and that starts with the words "check this out" or something else of the author's choosing if it can be shown to be equally compelling. It should not be subject to the template that the journal uses.

This is:

Weiher, Marcel, and Robert Hirschfeld. 2019. “Standard Object out: Streaming Objects with Polymorphic Write Streams.” In Proceedings of the 15th ACM SIGPLAN International Symposium on Dynamic Languages, 104–16. DLS 2019. Athens, Greece: Association for Computing Machinery. https://doi.org/10.1145/3359619.3359748

I'm not seeing it.

I call this implicit step zero.

Side note: I have for a long time (>10 years) been an advocate for the unbundling of browser history and bookmarks from the browser itself—not unlike the way Firefox was extracted as a standalone app from the Mozilla project. Firefox just didn't go far enough. I shouldn't have separate app-managed browsing histories for both Chrome and Firefox. (Syncing is not the answer here.) Each should just read and write to the same place on my machine. Same story for bookmarks. Same story for downloads. (Download management, that is—downloads can be written wherever, but when a download is initiated, it should be managed by the system download manager.)

Dude, just embrace the Web already.

(NB: By "the Web" I really do mean the Web (URLs, etc) and not browser-based tech like HTML, JS, and CSS.)

... or an ocean of utility, even. See: https://en.wikipedia.org/wiki/Map–territory_relation.

Sure, imposing hierarchies on data that doesn't fit is a problem, but file systems support symbolic links. And there's the seldom-exercised option of having multiple hard links, too.

The same is true of most personal sites, generally; the gamedev metaphor can be adapted to blog software vs using Twitter. (Twitter would always win.)

Bush. As We May Think. The Atlantic. 1945.

This is confused. You are every bit as able to do that as with the medium described in As We May Think. What you can't do is take, say, a copy of an issue of The Atlantic, add links to it, and expect them to magically show up in all copies of the original. But then you can't do that with memex, either, and Bush doesn't say otherwise.

Actually, you can.

A user on HN writes on the topic of blogging that they've reverted a publishing regime where they "just create github gists now" and "stopped trying to make something fancy". They're not wrong to change their practices, but it's a nonsequitur to give up maintaining control of their own content.

The problem to identify is that they were building thing X—a personal website probably with a traditional (or at least fashionable) workflow centered around a static site generator and maybe even CI/CD—but they never really wanted X, they wanted Y—in this case GitHub Gists (or something like it). Why were they trying to do X in the first place? Probably some memetic notion that this is what it looks like when you do a personal website. Why is that a meme? Who knows!

Consider that if you want a blogging workflow built around a gist-like experience, you can change your setup to work that way instead. In other words, instead of trying to throw up a blog based on some notion that it should look and feel a certain certain blog-like way, you could just go out and literally clone the GitHub Gists product. Along the way, you'll probably realize you don't actually want that, either. How important is it, really, that there's a link to the GitHub API in the footer, for example?

The point is, though, that you shouldn't start with trying to imagine what your work should look like based on trends of people blogging about blogging setups that they never use and then assume that you'll like it. Start with something that you know you like and then ask, "What can I get rid of in a way that dropping means either that my experience doesn't suffer or is actually improved?"

See also: - Blogging vs. blog setups. - New city, new job, new... website?

Truth.

If you're going to write a plugin for an IDE, prepare for your hello-world to be days of learning and pages of code just to do the hello-world.

Now, I would love someday to do a plug-in for IntelliJ that understands all of the custom stuff for my game code. Right? You know, I would love to, but you know that's that's a project.

Crazy. Consider how this compares to sharing the same stuff via blog posts + RSS.

Mm... These should be table stakes.

"Meticulous" (and calling these "micro-optimizations") is a really generous way to label what's described here...

I dunno. That strikes me as a weird perspective. You should be able to expect that it will do at least as much as a standard email client (which can do a lot—at a minimum, reading/viewing existing messages and searching through them and the ability to compose multiple drafts that can be sent when you go back online).

Given what the Mastodon frontend is like, it would be pretty concerning if that weren't true.

Huh? This comes across as nonsequitur.

This raises questions about how much the original approach made for good DX in the first place (and whether or not the new approach would). That is, when measured against not using a framework.

The whole point of these purported DX wins are supposed to be that—DX wins. When framed in the terms of this post, however, they're clear liabilities...

The Web already is what it is, at least—and what that is is not an imitation of the old. If anything, it ought to be more like the old, cf Tschichold.

Things like citability are crucial, not just generally, but in that they are fundamental to what the Web was supposed to have been, and modern Web practices overwhelmingly sabotage it.

This is, like THE foundational keystone document to the problem I'm trying to communicate for "builds and burdens".

@14:55

Clever. I also like the framing of MIT's "Missing Semester" https://missing.csail.mit.edu/

@1:24:40

Starting from main isn't actually a good way to explain a program almost ever, unless the program is trivial.

Nah. Wrong.

This is:

Hsu, Hansen. 2009. “Connections between the Software Crisis and Object-Oriented Programming.” SIGCIS: Michael Mahoney and the Histories of Computing.

Hsu only cites Mahoney for this, but the original McIlroy quote is from "Mass Produced Software Components".

Firefox seems to impose a limit (at least in the latest release that I tested on) of a length* of 2^16 i.e. 65536. You can test this by creating a bookmarklet that starts javascript:"65525+11/// followed by 65512 other slashes and then a terminating quote. If you modify it to be any longer, the bookmarks manager will reject it (silently failing to apply the change). If you select another bookmarklet and then reselect the one you edited, it will revert to original "65525+11" one.

* haven't checked whether this is bytes or...

This snippet removes some of the empty a elements to make the headings anchors instead:

javascript ([ ...document.querySelectorAll("a[name] +h1, a[name] +h2, a[name] +h3, a[name] +h4, h1 +a[name], h2 +a[name], h3 +a[name], h4 +a[name]") ]).map((x) => { if (x instanceof HTMLHeadingElement) { var link = x.previousElementSibling; var heading = x; } else { var link = x; var heading = x.previousElementSibling; } link.parentElement.removeChild(link); heading.setAttribute("id", link.name); })

The HTML encoding of this document contains several errors, some of which substantially affect the way it's read. This fixes one of those problems in Appendix II:

javascript ([ ...document.querySelectorAll("op") ]).reverse().forEach((op) => { let f = document.createDocumentFragment(); f.append(document.createTextNode("<OP>"), ...op.childNodes); op.parentElement.replaceChild(f, op); })

The problem show be apparent on what is, at the time of this writing, line 4437:

html <code>IF ?w THEN ?x<OP>?y ELSE ?z<OP>?y</code>

(The angle brackets around the occurrences of "OP" should be encoded as HTML entities. Because they aren't they end up getting parsed as HTML op elements (which isn't a thing) and screwing up the document tree.)

This is:

Buckland, Michael K. 1997. “What Is a ‘Document’?” Journal of the American Society for Information Science 48 (9): 804–9. https://doi.org/10.1002/(SICI)1097-4571(199709)48:9%3C804::AID-ASI5%3E3.0.CO;2-V.

This reads like a total non-sequitur at this point in the post.

The Wayback Machine should provide an easy way for website authors to upload archives that can be signed and validated with the same certificate you're serving on your domain, so you neither you nor the Internet Archive needs to waste more resources than necessary having the Wayback Machine crawl your site in the ordinary way.

At the expense of still breaking everyone's links.

If you know you're going to do this, publish all your crap at <year>.<domain> now. Or even <domain>/<year>/. Oh wait, we just partially re-invented the recommendations of a bunch of static site generators.

Better advice: don't touch anything once you've published it. (Do you really need to free up e.g. /articles/archive-your-old-projects articles from your namespace? Why?)

This is, unfortunately, not the dumbest thing Liam has written that I've come across.

Microsoft had a demo of this. It got shelved.

You're probably looking for https://riku.miso.town/.

I've mentioned it before, but what I find interesting is the idea of really parsing shell (scripts) like a conventional programming language—e.g. where what would ordinary be binary invocations are actually function calls i.e. to built-ins (and all that implies, such as inlining, etc).

What about actual concurrency (i.e. on a real-world CPU using e.g. x86-64 SMP) and not just a simulation? This should yield a speedup on lexing, right? Lexing a file containing n tokens under those circumstances should then take about as long as lexing the same number of tokens in a language that only contains a single keyword foo—assuming you can parallelize up to the number of keywords you have, with no failed branching where you first tried to match e.g. int, long, void, etc before finally getting around to the actual match.

Russ's regular expression article series makes for a good example when demonstrating the Web's pseudomutability problem. It also works well to discuss forward references.

NB: Russ talking here about flattening the NFA into a DFA that has enough synthesized states to represent e.g. in either state A or state B. He's not talking about CPU-level concurrency. But what if he were?

Mm, no.

There are CLAs, and there are copyright assignments, and there are some companies that have CLAs that contain a copyright assignment, but they don't "usually" include a copyright assignment.

Wait, why is sub-linear growth a requirement...?

Doesn't it suffice if there are some c₁ and c₂ such that costs are characterized by U(x) = rᵤx + c₁ and returns are V(x) = rᵥx + c₂ where rᵥ < rᵤ and the business had enough capital to reach the point where U(x) < V(x)?

Vannevar Bush on this phenomenon:

Communication: Where Do We Go From Here?

"We are in danger of building a Tower of Babel"

To be fair: it's not an example of particularly good writing. As Roy himself says:

["hypertext as the engine of hypermedia state"*] is fundamental to the goal of removing all coupling aside from the standardized data formats and the initial bookmark URI. My dissertation does not do a good job of explaining that (I had a hard deadline, so an entire chapter on data formats was left unwritten) but it does need to be part of REST when we teach the ideas to others.

https://web.archive.org/web/20080603222738/http://intertwingly.net/blog/2008/03/23/Connecting#c1206306269z

I'm actually surprised that Fielding's dissertation gets cited so often. Fielding and Taylor's "Principled Design of the Modern Web Architecture" is much better.

* sic

Controversial opinion: response bodies should never have been allowed for POST requests.

See also: Roy's lamentations in "On software architecture".

Another day, another series of bombastic Dalewyn shitposts.

This is:

Dahl, Ole-Johan, and Kristen Nygaard. “SIMULA: An ALGOL-Based Simulation Language.” Communications of the ACM 9, no. 9 (September 1966): 671–78. https://doi.org/10.1145/365813.365819

No way. Not too late for a better porcelain that keeps the underlying data model but discards the legacy nomenclature entirely.

it is

extremely frustrating

The experience is so bad, I don't know why Mastodon even bothers trying to synthesize and present these local views to the user. I either have to click through every time, or I'm misled into thinking that my instance has already shown me the entire discussion, so I forget to go to the original.

If you remove the word "Mastodon" from this sentence, this insight holds for a lot of things.

The ar format is underrated.

Compelling offer when you try draw upon your experience to visualize the opportunity cost of proceeding along the current path by focusing on the problem described, but it's basically a shell game; the solution isn't a solution. It rearranges the deck chairs—at some cost.

... which may have really happened, per se, but it didn't wholly incorporate (subsume/cannibalize) conventional desktop publishing, which is still in 2023 dominated by office suites (a la MS Word) or (perversely) browser-based facsimiles like Google Docs. Because the Web as it came to be used turned out to be as a sui generis medium, not exactly what TBL was aiming for, which was giving everything (everything—including every existing thing) its own URL.

Interesting distinction.

I don't think that arises from honesty. I'm pretty sure most people saying "RESTful" don't have any clue what REST really is. I think they just think that RESTful was cute, and they're not trying to make a distinction been "REST" and "RESTful" (i.e. "REST... ish", or "REST-inspired" if we're being really generous). Not most of them, at least.

I really hate this phrase. It's probably one of the leading causes of misunderstanding. It's unfortunate that it's used here.

It didn't, though. It became a label applied to Web service APIs, despite having nothing to do with REST.

It's probably not REST, anyway.

"could be relevant" (if you don't really understand it)

There are better ways to put this.

Good way to put it.

the label¹, at least

1. "REST", that is

More appropriate might be "extracted from (the use of) UNIX pipes".

I don't know if that's totally accurate. "Could", maybe.

We could ask, I guess, but.

I don't think this is the best way to describe it. He was first interested in extracting an abstract model from the implementation of the Web itself (i.e. how it could be and was often experienced at the time—by simply using it). His primary concern was using that as a rubric against which proposals to extend HTTP would have to survive in order to be accepted by those working on standardization.

"The biggest of these misconceptions [about REST] is that [Fielding's] dissertation directly addresses the problem of building APIs."

For example (another HN commenter you can empathize with), danbruc insists on trying to understand REST in terms of APIs—even while the correct description is being given to him—because that's what he's always been told: https://news.ycombinator.com/item?id=36963311

This is:

Ciortea, Andrei, Olivier Boissier, and Alessandro Ricci. “Engineering World-Wide Multi-Agent Systems with Hypermedia.” In Engineering Multi-Agent Systems, edited by Danny Weyns, Viviana Mascardi, and Alessandro Ricci, 11375:285–301. Lecture Notes in Computer Science. Cham: Springer International Publishing, 2019. https://doi.org/10.1007/978-3-030-25693-7_15.

I'm against this, because on net it has probably been more harmful than beneficial.

At the very least, if the mapping is going to change—and it's known/foreseeable that it will change, then it should be returning 3xx rather than 200 with varying payloads across time.

A very nice property—

These are not strictly subject to the constraints of e.g. Git commits, blockchain entities, other Merkel tree nodes.

You can make forward references that can be fulfilled/resolved when the new thing actually appears, even if it doesn't exist now at the time that you're referring to it.

Better still: separate messages by double linefeed (i.e., a blank line in between each one). It only costs one byte and it means that human-readable JSON is also valid in all readers—not just ones that have been bodged to allow non-conformant payloads under special circumstances (debugging).

... since HTML/XML is not part of the JS grammar (at least not in legacy runtimes, i.e. those at the time of this writing).