This link is a 404. Why did Roy start doing this?

Example of when "proprietary" is not an antonym of "open source".

Another approach, inspired by the <label> element, would be to encode these selectors as separate <link> elements in the head. You could write your links as normal, and then add these <link rel="selector" for="foo" href="XXX[...]X" /> to your document (where foo is the ID of the <a> element, and the href value is selector).

Neat.

The answer is: linking party pays. I.e., after 30-ish years of the Web put into practice, what has emerged is that it is the linking party's responsibility to ensure:

• that the material remains available (by keeping a copy around, or arranging for the same thing by delegating to a third-party), and
• there is some reliable way to establish provenance (which can be handled in tandem with delegation to same third-party, as with availability)

These are only necessary if these two (availability and reputable provenance) are actually desirable properties. But in the event that one or the other or both is desired, the rule is that linking party pays.

This is the only realistic one—and the only way to reconcile the vast pre-Web corpus that is ostensibly meant to be ingested to occupy a first-class status on the Web.

It still ~requires some amount of versioning (though not necessarily with the cooperation of the publisher, from whom it would be prudent to assume harbors a mildly adversarial outlook; cf Wayback Machine, Perma.cc, etc).

It's almost like a pick two/impossible trinity.

You can either have: - a resource that stays up-to-date (e.g. by a convenient URL that always points to the most recent revision, i.e. documents are mutable) - links that don't break

You can't have both.

If you choose the latter, your document can never change--not even to say the current version is out of date. This also means using unique ("versioned", you could say) URLs--one for every revision, with it only* being possible for later revisions to point to earlier ones, almost like a Git-like DAG.

If you choose the former, you're gonna be breaking your links (and those of others, too).

* The workaround would be to include in rev A (which predates rev B) a URL to a non-existent resource, and you preregister your commitment to deposit a document (rev B) there. Not possible in systems which rely on content hashes, but imminently doable under the norms of the way URLs get minted. (Still doesn't fix the problem of have a clean and up-to-date URL like /pricing or /about/team, though.)

I don't understand this.

Presaging lightweight wikilinks? (Or at least WikiWords?)

The page https://www.w3.org/DesignIssues/Multiuser.html#3 links here (to #GenericLinking).

Since this page currently returns 404, try https://www.w3.org/History/19921103-hypertext/hypertext/Products/Microcosm/Microcosm.html.

Why it's pointless to insist that links should have been bidirectional: it's unenforceable.

Try * http://www.html-tidy.org/ * https://github.com/htacg/tidy-html5

Obnoxious.

As someone recently pointed out on HN, it's very common nowadays to encounter the no-one-knows-else-what-they're-doing-here refrain as cover—I don't have to feel insecure about not understanding this because not only am I not alone, nobody else understands it either.

Secondly, if your code is hard to understand regarding its use of this, then your code his hard to understand. this isn't super easy, but it's also not hard. Your code (or the code you're being made to wade into) probably just sucks. The this confusion is making you confront it, though, instead of letting it otherwise fly under the radar.* So fix it and stop going in for the low-effort, this-centric clapter.

* Not claiming here that this is unique; there are allowed to be other things that work as the same sort of indicator.

And by the way, if you ever do do anything good with it, it'll just become a cesspool of people posting Donald Trump memes and complaining about what movie didn't have the right people in it on Twitter. That's what your inventions will be used for, right? Not advancing humankind and producing some kind of good future for everybody.

... says the guy who has dedicated his life to video games.

Previously: https://hypothes.is/a/tCHXEvj-Eey1N3dRiP4I4Q

Nice property. It would be nice if HTML Tidy could do the same.

This is the earliest known reference to HTML's class attribute that I've found in a public document so far: 1995 May 6 in draft spec 02 (i.e. the third revision) of the HTML 2.0 spec.

This postdate's Håkon W Lie's original CSS proposal (from 1994 and which doesn't mention classes) and predates the first CSS draft specification (dated to 1995 May 31 in one place and which mention's HTML's ability to subclass in order to "increase the granularity of vcontrol" [sic]).

The "subclassing" word choice here is interesting. It matches the model eventually suggested in HTML 3.x, but at the time of this draft, HTML was in a draft specification stage (third revision — "02") for HTML 2.0

I'm interested in the discussion that led to this.

You sure about that, Dan-from-25-years-ago?

You're looking for this, I think: https://www.w3.org/People/Connolly/9703-web-apps-essay.html

If you manage to find a copy of this (or already have one) please let me know!

It's always funny/interesting to read these not-quite-projections about overhyped tech from a far enough vantage point, but this sounds a little like what I've advocated for in the past, which is resurrecting Google Gears.

If the thesis is sound, then logically we should expect the instances where people have decided to "use terribly slow scripting and techniques" to produce better programs; the not-slow (non-"scripting") stuff to be worse.

You can only pick one:

• software is worse because hardware improvements mean that what were previously noticeable inefficiencies are no longer noticeable
• programs that are written in low-level languages and don't as much incur runtime overheads are better on average because they're written in low-level languages that aren't as wasteful

We have that. It's the Web platform. The hard part is getting people to admit this, and then getting them to actually stop acting counter to these interests. Sometimes that involves getting them to admit that their preferred software stack (and their devotion to it) is the problem, and it's not going to just fix itself.

See also: Lorie and the UVC

Is this not just a new name for what was already described in the 1960s as the "software crisis"?

This calls for a perspective shift: that "random Python program" is your browser.

Notice with the line about Tom and Huck being boys, the bottom-up description sounds unnatural.

not what semver is actually about

https://github.com/ganelson/inform

You accidentally a word.

This piece would benefit from better editing—e.g. its use of pronouns with an unnatural (or too-far-away) antecedent, dubious phrasing like "all the more", etc.

still widely held today

traditional compilation foils "symmetric authoring"

I can't get behind the call to anger here, even if I don't approve of Apple's stance on being the gatekeeper for the software that runs on your phone.

Elsewhere (in the comments by the author on HN), he or she writes:

The biggest problem I try to convey is that you have no way of knowing you'll get the rejection

No, I think there were pretty good odds that before even submitting the first iteration it would have been rejected, based purely on the concept alone. This is not an app. It's a set of pages—only implemented with the iOS SDK (and without any of the affordances, therefore, that you'd get if you were visiting in a Web browser. For whatever reason, the author both thought this was a good idea and didn't review the App Store guidelines and decided to proceed anyway.

Then comes the part where Apple sends the rejection and tells the author that it's no different from a Web page and doesn't belong on the App Store.

Here's where the problem lies: at the point where you're - getting rejections, and then - trying to add arbitrary complexity to the non-app for no reason other than to try to get around the rejection

... that's the point where you know you're wasting your time, if it wasn't already clear before—and, once again, it should have been. This is a series of Web pages. It belongs on the Web. (Or dumped into a ZIP and passed around via email.) It is not an app.

The author in the same HN comment says to another user:

So you, like me, wasted probably days (if not weeks) to create a fully functional app, spent much of that time on user-facing functions that you would have probably not needed

In other words, the author is solely responsible for wasting his or her own time.

To top it off, they finish their HN comment with this lament:

It's not like on Android where you can just share an APK with your friends.

Yeah. Know what else allows you to "just" share your work...? (No APK required, even!)

Suppose you were taking classes and wanted to know the rubric and midterm schedule. Only rather than pointing you to the appropriate course Web page or sharing a PDF or Word document with that information, the professor tells you to download an executable which you are expected to run on your computer and which will paint that information on the screen. You (and everyone else) would hate them—and you wouldn't be wrong to.

I'm actually baffled why an experienced iOS developer is surprised by any of the events that unfolded here.

Not to dispute "deathanatos"'s (presumably) thorough refutation, and although the Wat behavior remains the default for compatibility reasons, but most of these problems are fixed with a single pragma.

Odd way to describe it! You could easily have said "Chrome 1.0" or "Firefox 1.x-level" (or even "Firefox 2.x" or "Firefox 3"), since JS didn't really change between 2000 and 2010. (ECMAScript 5 was standardized in 2009 but not bene, that's December 2009. IE 8 didn't introduce ES5, and it definitely wasn't available in IE at the tail end of the year. Full ES5 compliance didn't even really show up in browser until 2012-ish, not even Chrome—the one browser that had short release periods at the time.)

Corollary: Spolsky (at least at the time of this article) didn't really understand types, having about the same grasp on computing fundamentals as your average C programmer.

The thing that gets me about takes like this is that it's all the stuff below the Web content layer that accounts for what makes all this stuff harder than it needs to be.

What's the hard part about distributing content (static or not, but let's go with static for simplicity)? It's registering a domain, updating DNS, and keeping a Web server up—all systems that have nothing to do with the "infernal" trio and also generally programmed in what are typically described as saner languages and their traditions. It's either that, or it's relying on somebody else, like GitHub Pages, and integrating the implementation details/design decisions for their value-add into your workflow.

To "build a platform" is ambiguous, but it sounds a lot like "creating a server-side application to serve non-static content and handle associated requests". Is the infernal trio to blame for the difficulties of that, too?

So run a typechecker on the code to check your work if you want type checking. That is what TypeScript does, after all. And it's been around long enough that people shouldn't be making the mistake that a runtime that support dynamic types at runtime means that you can't use a static typechecker at "compile time" (i.e. while the code is still on the developer workstation).

With this comment, the anti-JS position is becoming increasingly untenable. The author earlier suggested C as an alternative. So their contention is that it's easier to write bug-free code in C than it is in JS. This is silly.

C hackers like Fabrice Bellard don't choose C for the things they do because it's easier to write bug-free code in C.

Perfect synopsis of /r/programming

The author might as well have written, "I have no idea what I'm talking about and rely on pattern matching based on social cues I have observed."

What is the relationship between "arcane code" and "code that you'd have to recompile"?

Where does it say they're "going with web-like scripts"? (And what is "more traditional code"?)

This note (and most modern JS programmers' code) could benefit from the eradication of its aversion to this.

Nah. OOP is just "messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things". Inheritance not needed.

Bob Nystrom used something like this while writing Crafting Interpreters. He wrote a post about its bespoke build system.

https://journal.stuffwithstuff.com/2020/04/05/crafting-crafting-interpreters/

a literal "missing step"

• https://wiki.triplescripts.org/wiki/Implicit_step_zero
• https://en.wikipedia.org/wiki/Missing_stairstep

I'm not sure that the narrative implied by these statements is accurate.

Reminiscent of Helping my students overcome command-line bullshittery

Nothing particular to what's described here, but this gives me an idea for a design of an efficient IME that doesn't require manually adding the brackets or even starting with an a priori intention of linking when you begin writing the to-be-linked phrase. The idea is that you start typing something, realize you want to link it, and then do so—from the keyboard, without having to go back and insert the open brackets—at least not with ordinary text editing commands. Here's how it goes:

Suppose you begin typing "I want to go to Mars someday", but after you type "Mars", you realize you want to link "go to Mars", as this example shows. The idea is that, with your cursor positioned just after "Mars", you invoke a key sequence, use Vim-inspired keys b and w (or h and l for finer movements) to select the appropriate number of words back from your current position, and then complete the action by pressing Enter.

This should work really well here and reasonably well in the freeform editor originally envisioned for w2g/graph.global.

I disagree that this is harmful. Striving to linearize things has payoffs. The resistance to doing so, on the other hand, is definitely what I would call harmful (to "communication", as the author put it, esp.).

Have you ever delivered (or witnessed) a lecture in non-linear time? You can't. Because you can't help but grapple with the inherent linearity arising from the base substrate of our existence, eventually.

That's probably not a bad conclusion—if you insert the phrase "one of" before "the closest". (And there's no bias fueling my agreement; I don't work with the JVM).

For my bet, the Web platform is still the better option, though, and it has to do not just with its current ubiquity, but the factors that have led to that ubiquity, including versatility and relative ease of implementation (cf Kling et al).

Yes! This is essential. Ask, "What does this probably actually require?"

in other words, it captures too many irrelevant details whose effect sums to null (and in the best case should be replaced by NOP).

See also DSHR on preservation, along with Rothenberg and Lorie (independently).

See Hinsen's https://rescience.github.io/ten-years/

I dunno. I think the common argument that the Web was not intended to be an application delivery platform is both (a) ignorant of basic facts in subtle ways that are materially relevant to the particular use case described here and (b) poorly applied to this use case, given those particulars.

I don't like most traditional Web apps or what passes for best practices in the contemporary culture. I don't write them, and I'm not defending them.

But we're talking about scientific literature here. I'll dispute the general argument as it applies to the specific use case under discussion by pointing out that a document-centric platform is in fact exactly the correct tool for the job in this case. The only thing that could be better is if you were able to write your paper more or less as you ordinarily do for journal publication and then feed the journal article into a machine able to comprehend the methods at a deep level and then simulate what it describes. We don't have that, though. But we can to author documents that are a little more explicit instead. This is not a terrible consolation prize. So we really should start seizing the benefits of the current circumstances, lest the Web platform actually turn into something unsuited for this. (Which, perversely, is most likely to happen as a result of pursuing the vision of making it more suited for traditional software development.)

Again—by all means, don't compile to asm.js (or WASM, or from TypeScript, etc.). Put it to use on its strengths and in the spirit of its original vision.

Better yet, not compiling to asm.js at all. Just WYGIWYG (What You've Got Is What You Give [Me, Too]).

I agree. And this very reason (along with the complexity, mentioned in the following paragraph) is what should disqualify VirtualBox.

The virtual machine manager you should use is the one you assumed would be available when you published this post (and that you were correct about, and that I am using right now to read it): the Web browser.

There's some sleight of hand here, which treats "when no one uses it in daily life anymore" as a given. That (folks continuing to use it) is the stability of the Web platform.

Besides, even if we suppose that people have stopped using it (dubious), the entirety of what constitutes "the 2013 Web platform" is not necessary—only the parts that are actually used for computation and I/O. That's much smaller.

Fortunately, the 2013 platform is a subset of the later one.

"can't is too strong a word here"

The truth of this has consequences not just for the metaissue of recomputation, but the entire raison d'etre of doing performance studies to begin with.

"The greatest performance improvement of all is when a system goes from not-working to working"

X for thee, not for me

This kills the crab.

Category error; C, C++, and Fortran are programming languages, not tech stacks.

Perverse!

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

See https://activepapers.github.io/

Applicable as criticism for: - marketing analytics for "data-driven" campaigns - the sort of resume-driven development that is fashionable on Github - naive code reuse, generally

Good formulation! All scientifically relevant information—this demands that the programs themselves be "stored in stable and well-defined open file formats". This is precisely what is missing (both the mindset and the practice).

I suspect, though, that the author themself has missed this and is thinking of the "software environments" (that he later refers to in this conclusion) as being outside this purview. But it need not (and should not) be.

Not true. The standardized Web platform is not just more stable than Python, it's probably one of the most stable platforms in existence. It just moves (read: improves) slowly.*

Most people don't recognize this, because they pack the stable, standardized parts all in the same mental bag as the shiny, non-standardized parts (like Flash, for an example of decades past, or experimental vendor-specific stuff for a more evergreen problem), then end up getting bit in a similar way and blaming the environment rather than communal tendencies towards recklessness.

It also turns out that the Web's original academic underpinnings are deeply aligned with the goals of researchers looking for a way to work together—even if the final puzzle piece (ECMA-262) didn't come into existence until later in the decade when the Web first appeared. It's still old enough that it passes the litmus test proposed here.

* for good reason; after all, look at the evidence

My conclusion: the scientific computing community—and many Python programmers, generally—have done themselves a disservice by standardizing on Python. The problems that have been shown to arise here and in similar cases comes down to an impedance mismatch between what these programmers want Python to be and what Python actually is.

Another insight comes from observing the way in which folks from the affected group have tended to approach the problem—wading in with a sort of undisciplined, YOLO mindset and then thrashing when they've gotten in over the heads because it turns out that a lack of discipline permeates the actions of everyone else, too—which includes, crucially, those they look for to be disciplined so that there's something that can be relied upon.

Food for thought: although I'm not a Java programmer it's not hard to see that had they standardized instead on the JVM (doesn't necessarily have to be Java—could be a Python lookalike), then this would have almost certainly served them better here on the matter of stability and had the nice benefit of sidestepping the performance issues that Python is known for.

The "every problem in computing can be solved with another layer of hacks" school of thought.

This is still not the best way to put it. Decisions come at the expense of writing code. This maintenance work is something else.

Good point.

We can go further. Suppose I have a project written in TypeScript, and your affinity for TypeScript is well-known. Only—surprise!—I'm actually using TypeScript 1.x from n years ago. Are you still happy?

https://newspeaklanguage.org/

This is not strictly true, but it's not the worst thing in the world to pretend that it is.

This seems to be the position adopted by many developers. More than is reasonable. #3 and #4 probably account for most developers.

This one, it looks like: https://blog.khinsen.net/posts/2017/01/13/sustainable-software-and-reproducible-research-dealing-with-software-collapse/

Cited by https://link.springer.com/content/pdf/10.1007/s00287-018-01134-1.pdf

See also: Fielding

REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release.

That's a pretty deficient workaround, given the obvious downsides. A more robust workaround would be to make the cart stateless, as far as the server is concerned, for non-logged-in users; don't depend on cookies. A page request instead amounts to a request for the form that has this and this and this pre-selected ("in the cart"). Like with paper.

That seems like unnecessarily tight coupling. Surely there's a better level of abstraction that's higher than "emulate the hardware platform".

Huh?

nope

There's a fundamental misunderstanding (alternatively, misdirection) about what the source of breakage is. JS is not an SDK, and neither is the Web platform. Whatever worked in the old "JavaScript version" will work in the new one.

See http://silverspaceship.com/inner/imgui/

Now imagine, as a performance optimization, a lib where you can write in IMGUI style, so you write the same amount of code, but behind the scenes, the lib is managing things, so it's actually free to do all the retained mode heavy lifting.

We just invented declarative programming.

Interesting remarks, given the Muratori school on profligate misuse of computing resources by modern developers.

Game Developer. September 2005.

This describes one of the most pleasing hacks I've ever come across. I just now tracked it down and added it to my bookmarks. (Not sure why it wasn't already there.)

You could also conceive of going one step further. When your app (doesn't actually have to be a game, though admittedly it's much easier for you if it is) is compiled with tweak.h, it gives it the power to paint the source file on the screen—so you don't actually have to switch over to your text editor to save it, etc. Suppose you want to provide custom inputs like Bret Victor-style sliders for numeric values. You could edit it in your text editor, or you could derp around with it in-app. Tweaking the value in-app should of course both update it wrt the app runtime but also still write the file to disk, too, so if live reloading is turned on in your text editor, whatever changes you make inside the live process image gets synced out.

Hey, traveller. You're looking for https://web.archive.org/web/20070824202955/http://www.mollyrocket.com:80/forums/viewtopic.php?t=159&sid=cb913629aa8310947c0476848a8824dd

See Too DRY - The Grep Test.

But even allowing for grep is too lax, in my view. It's too high a cost. If I've got some file open and am looking at some Identifier X, I should be able to both deterministically and easily figure out exactly which file X lives in.

Violating this is what sucks about C's text-pasting anti-module system, and it's annoying that Go's "package" system ends up causing similar problems. I shouldn't have to have a whole-project view. I should be able to just follow my nose.

I think it is the beneficiary of a network effect—it's just driven by a professional class, and not end users.

Also: ho-hoism; see McCarthy to Russell on eval

Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is understood to mean literally that and taken no further—so you can have as much spookiness as you like, and so long as the value is not directly accessible (visible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

That is, there are two aspects to variables: visibility and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly prohibiting direct visibility across boundaries.

I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

(What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)

• The Web has suffered bloating
• This page, therefore, is simple:
• All that's involved here is a de novo language that was created in such a way that this page has to be generated from a separate, canonical source file written in that format

This is silly set of statements to make in series.

Just make the published form of this document the canonical representation—treat it as suitable for reading and editing alike (since it is).

A similar mistake is being made here as the one that precedes the reminder that there is no such thing as a fast programming language—only a given implementation can be called fast.

There's a weird (read: "weirdly obvious") category error here. NodeJS is not a language. (This wouldn't be so notable if the comment didn't go on to say "The key point is writing to an interface and not an implementation.")

The puzzle piece that fits the shape of the hole here is "JS". JS is the language, NodeJS is one of its implementations—and chubot knew both of these things already, so it's odd that it was expressed this way. Plus, there's a lot more diversity of JS implementations than exist for e.g. Python...

I don't see how avoiding Python "will just make your site worse"—whether right now, or ever. Is there supposed to be something inevitable about Python?

I'm having trouble parsing this.

Suppose that instead of shell commands, the snippets were JS, and the README, rather than being named README.markdown or README.txt, were actually named e.g. README.txt.htm. it wouldn't be basically like an executable README—it would actually be executable. You could double click it to open, and then read through it and use it to actually do the stuff that the README is documenting (like build the project in question).

See https://discuss.write.as/t/only-30-users-listed-in-users/6317 ("My site has 37 users now, but only 30 users are displayed[...]"; later: "Well. the 2nd page displayed when users got 60").

Huh? Modules are ES6 aka ES2015.

Even most ostensible FP practitioners who swear they don't.

Walter Bright described similar issues with the Digital Mars compiler in a recent NWCPP talk "Adding Modules to C in 10 Lines of Code", albeit Walter's compiler sounds like it was far easier to fix.

It's funny that this happens with compilers. Wirth's Oberon compiler (module ORP) also depends on static state. But compilers seem natural to me to be something that you want to allow multiple instances of—it's not even among the list of things I'd expect people to make excuses for (cf https://kentonshouse.com/singletons).

RSS may not have been "designed to work with comments in mind", but Atom supports them: https://www.xml.com/pub/a/2004/06/16/dive.html

This is an excellent property. It's not a weakness.

• https://www.object-oriented-security.org/lets-argue/singletons
• https://dl.acm.org/doi/pdf/10.1145/62084.62095
• https://gbracha.blogspot.com/2008/02/cutting-out-static.html
• http://www.erights.org/

Worth noting that almost every C program is impaired by a similar limitation in the C language (despite the disclaimer that follows this passage about the use of the preproccessor), and many programmers' thought processes suffer because of it—no consideration for the presentability of code (even when not in languages that are affected by this limitation!)

This is a 404.

That's bug 442099, comment 19, i.e. trying to substantiate the opinionated claim that "an operator at the front" is better for human factors.

The problem of multiple import forms plagues ECMAScript today. Additionally the lack of "immediate" visibility of "where an imported identifier was declared" continues to plague Golang, to an extent even worse than described here for Modula-2 (because at least when you're iteratively jumping through the file with naive text search, you'll eventually reach the Modula-2 import statement, even though it involves wrapping around after reaching the bottom). It's explicit at some point. With Golang, on the other hand, having not been sufficiently wounded by the problems of C, the team designed it such that it has magical name resolution, making it tedious to carry out (as a human) the process that the compiler uses.

the problem with Golang that I described

Dissent: On Understanding Data Abstraction, Revisited

This is the dirty secret of the neo-OSS era—that it's mostly devops shovelware (to a degree that makes it look like Sturgeon was being conservative)

But having commit access and the having ability to fiddle with bugs are two orthogonal sets of privileges...

Surprise: going all in on GitHub—including abandoning traditional practices governing bugtrackers in favor of GitHub's anemic project management tools—has a negative impact.