Microdata addresses this.

Try this one: http://ccs.mit.edu/wp_toc.html

K, but the installation comes from a context that the app vendor already controls—the entire surface of their own site—so...

Even so, do what you want with your browser UI, but like... there are crazy levels of navel-gazing here.

This turn of phrase always struck me as confusing. (Still does, actually.) Maybe I lack the cultural context where "free [as in] beer" is illuminating rather than confounding. It raises questions, though—what cultural context is the one where this is a logical and widely understood sequence of words?

Complimentary beer nuts, sure, but the beer isn't free—that's why the nuts are: because they're trying to sell more beer.

When and where was "free [as in] beer" ever a thing?

This is:

Caplan, Priscilla. Support for Digital Formats. Library Technology Reports 44, 19–21 (2008). https://journals.ala.org/index.php/ltr/article/view/4227

Did Adrian White become Adrian Brown? That's what the byline in DPTP-01 actually says.

Traveler:

You are probably looking for this: https://www.nationalarchives.gov.uk/aboutapps/fileformat/pdf/automatic_format_identification.pdf

Does this mean that Drew is going to step back, then? He is after all yet another white guy himself who has few (or none) of the characteristics described, so...

The term "virtue signalling" was probably played out 5 years ago, but geez—it's hard to see this as anything except an opportunistic version of exactly that. Like greenwashing being wielded by people with ulterior motives, this seems like a straightforward case of an intellectually bankrupt attempt to conspicuously dress up one's argument in the most politically unimpeachable cause and claim that it comes from a place of wanting the best for society when ultimately a self-serving motive underlies the thing. This is very cheap and very tacky.

I'm not a vanguard for the FSF per se, but when I think about the community norms and attitudes that are most exclusionary and turn people away, it's the sort of stuff that Drew and his fans are most often associated with. Stallman at least e.g. views Emacs as something that "secretaries" can be taught. Drew's circle tends to come across as having superiority complexes and holding strong opinions about computing that stops them just short of calling you a little bitch for not being as hardcore as they are...

I didn't realize Mr. DeVault was such an admirer of NPM.

Their fault, really. What does the FSF have to do, and how much and how often do they have to do it, to make clear that this isn't their position? The culprit is right there in the sentence: the word "assume". It's not unforgivable to not be certain, but the number of people I've interacted with who insist that this is the FSF's position are exasperating.

Not Google Podcasts.

In my port of judell's slideshow tool, I made these built-ins. (They're bindings that are created in the ContentStereotype implementation.)

In that app, the stereotype body is just a return statement. Perhaps the ContentStereotype implementation should introspect on the source parameter and check if it's an expression or a statement sequence. The rule should be that iff the first character is an open param, then it's an expression—so there is no need for an explicit return, nor the escaped backtick...

This still gives the flexibility of introducing other bindings—like the ones for _CSSH_ and _CSSI_ here—but doesn't doesn't penalize people who don't need it.

I'm having trouble determining the source of this purported error. This PDF appears to have copied the content from the version published on kurzweilai.net, which includes the same "erratum". Meanwhile, however, this document which looks like it could plausibly be a scan of the original contains no such error: https://documents.theblackvault.com/documents/dod/readingroom/16a/977.pdf

I wonder if someone transcribed the memo with this "amd" error and that copy was widely distributed (e.g. during the BBS era?) and then someone came across that copy and inserted the "[sic]" adornments.

A subset of Ted Nelson's envisioned transcopyright system

wat

There's nothing implicit about it. Type annotations are explicit.

This is Olivia A. Davidson.

I have real trouble seeing that as saddening.

It isn't as if anyone is going around making the the free version arbitrarily defective. The reseller is putting in work to add value and getting paid a buck for it (literally).

It would perhaps be upsetting, too, if they were going after folks somehow. But I don't see this in the rendition above.

(In reality, a buyer would probably be fine if they took the Project Gutenberg version, bought the reseller's digitally reformatted one, extracted the TOC data and error corrections, and then slapped that onto the free version and sent it back upstream to Project Gutenberg or someone else who is distributing free copies. They would be legally in the clear, so the reseller, then, stands to make as little as $1 for their investment in that work, so in that case it seems imminently fairly priced.)

I'm not sure how this solves the problem specifically, since there will still be thousands of entries (one for each tweet) in the status/ directory...

(Unless I'm not grasping something and the problem truly is the matter of having 2^16 subdirectories in particular—without similar concerns for ordinary files.

That does raise questions about how someone would run into the original problem in the first place; vanilla ZIP has a fundamental limitation of 2^16 - 1 total files. Is Twitter using the ZIP64 extension?

Contra [1], the ZIP format was brilliantly designed and natively supports a solution to this; ZIP was conceived with the goal of operating under the constraint that an archive might need to span multiple volumes. So just use that.

1. https://games.greggman.com/game/zip-rant/

The book is: Der große Report - Die besten Internetadressen. 2000. Data Becker.

The context is 10,000 URLs, not "sites". The URL for "Wikipedia" leads to a document that is on its own not entirely interesting. It would be the URLs for individual articles that should make the cut, unless "URL" is being used as a euphemism here.

Well, they're not supposed to be ephemeral. They're supposed to be as durable as the title of whatever book you're talking about.

Need to rope this in to the delayed conversation with chubot about prehistoric ANPD thinking.

That goes against the design of URLs and also confused/annoyed me when I first landed on this blog, so...

I see this a lot—and it seems like it's a lot more prevalent than it used to be—reasoning from a proxy. Like trying to suss out how competent someone is in your shared field by looking at their GitHub profile, instead just asking them questions about it (e.g. the JVM). If X is the thing you want to know about, then don't look at Y and draw conclusions that way. (See also: the X/Y problem.) There's no need to approach things in a roundabout, inefficient, error-prone manner, so don't bother trying unless you have to.

C'mon. It's right there:

Follow the instructions given in the WebGL specifications' Context Creation sections to obtain a WebGLRenderingContext, WebGL2RenderingContext, or null; if the returned value is null, then return null;

(Not that it should even be necessary to resort to checking the spec—relying on an assumption of a non-null return value here should raise the commonsense suspicions of anyone.)

I agree that this approach is bad. I hate that this exists. The differences between doctype-triggered standards and quirks mode was bad enough. This is so much worse—and impacts you even when you're in ostensible standards mode.

Huh? Why? Why even waste the time? Just go fix your code.

"... you keep using that word"

I don't think that has been shown here? The zip.js stuff breaking is one thing, but the poor error detection regarding off-screen canvas doesn't ipso facto look like part of a larger pattern.

Answer: because they care about Web compatibility. If they delay X because Y is not ready, then that's ΔT where their browser remains incompatible with the rest of the world, even though it doesn't have to be.

This is a huge reach.

Although it's debatable whether having mismatched support is a good idea for a vendor, arguing that it breaks the commitment to compatibility is off. Construct broke not because something was removed, but because something was added and your code did not handle that well.

Two things: * Why would it have mentioned anything? It wouldn't have. It hadn't shipped yet. * MDN is not prescriptive; it's written by volunteers

The second = sign is completely superfluous here. Only one is necessary.

Well, the biggest problem is that anything can ever lead to a blank screen because Construct isn't doing simple error detection.

This is why I don't get people who bristle at the thought of writing a cover letter. What the fuck. Just write a paragraph or two saying why you want this job, specifically—why you think you'll find it rewarding and how it fits with your professional interests. Is it that hard? I'll take this a thousand times over vs pruning, rearranging, and emphasizing line-item crap from my employment history, awards I was given 20 years ago, etc.

We should be starting with the cover letter and handing that over to someone who's competent to review it (not a generic, know-nothing human pattern matcher) and then move on to hardcore testing for aptitude in a testing environment that matches as closely as possible the actual work environment where you're going to be expected to get things done on a day-to-day basis.

Why not? Do it. It is literally their job.

The alternative: "smart" resumes that are something like contact cards plus an agreement from employers to put way less stock into resumes and less organizational infrastructure towards keeping classic HR droid positions filled with people that ultimately themselves don't do very much for the company.

So from the applicant's perspective, you don't worry about creating a resume for this job. It feels more like handing out a business card with your contact info to someone who needs it, except in this case instead of it being contact info (or rather, in addition to the contact info), it contains other stuff, too.

Ugh.

Surely that's meant to say "GB"?

WTF

It might "help" but it defeats the entire purpose of the recordkeeping endeavor.

If you don't care about the recordkeeping aspect and are just using Git to sync stuff between machines, then you're not really using Git and should stop trying to use it and use something else. (A better option, of course, is to think about it long enough to understand why recordkeeping is good and then take the time to write commit messages that don't suck and not treat it as an arbitrary and pointless hurdle. It's not pointless; there's a reason it was put there, after all.)

This is why git add is git add. The students should have been told not to add anything to the repo except for the source files they're actually changing. A good rule of thumb: if the change was made by a human, and the human was you, then you can commit it; if the change was made by a machine, then don't.

This is only a problem if they were doing git config --global. Considering these were shared machines, then they shouldn't have been.

Except, of course, branching and merging mean that this hurdle isn't a necessary one. Git was designed from the beginning so that this would be a non-issue (or at least not as bad as what this class experienced); that's where the D in DVCS comes from, after all...

(And I thought that's where this was going—! Rather than just giving people the solution—in this case branches/remotes—and telling them to use it, then what you do is you let them experience the problem firsthand and then can appreciate the solution and why it's there. Really surprised that's not where this ended up.)

I had a fever dream* in 2020 or 2021 that involved an epiphany for a clear way to integrate Git's data model into mass market computing systems (a la Mac OS and its Finder) in a way that was digestible to normal people. I've basically forgotten it. I think it was something like:

1. use heuristics to figure out when someone is using the "[...]_draft", "[...]_final", etc, ad hoc versioning antipattern
2. offer to make the directory a versioned one

On systems like Mac OS where everything is tightly integrated, you wouldn't need to limit yourself to offering this in the Finder. Any time someone used the system-wide standard file save dialog in a way that exhibits the thing described in #1, the system could use the desktop notification subsystem to get the user's attention and offer to upgrade their experience. No interaction with the Git porcelain (as we know it) necessary.

I fear that MS might do this first but bungle it (i.e. unthoughtfully) and also promote/upsell GitHub to you during the ride.

* not really

It looks like it's this one: Itty Bitty Computing Machine http://aaronbloomfield.me/docs/sigcse-2011-p371.pdf

doi:10.1145/1953163.1953273

Nice use of w3doc.css. Looks good!

Yes, of course. That's another intentional feature.

Well, since you don't want to support it, then you aren't required to do that. (And good thing, because that would limit the format severely.)

It means you don't need to! (And why would you try? You have already found one, and you know there is only one, so to try to find more is to try to do something that you know is impossible.)

It means if you have a ZIP file (something that you know is a valid ZIP file) and you have found more than one end of central directory record, then there's something wrong with the method you used to find them (because there can by definition be only one).

Okay, fine. Don't use them (don't use broken software, generally—unless you're comfortable getting broken results).

I don't take the spec to mean that you can reliably stream any arbitrary ZIP bytestream. If you are the producer and the consumer, though, then you can bend the format to your will to enable streaming.

See Firefox's JAR handling for an example.

Justine Tunney covers the genius of the ZIP format in her Redbean talk (@55:31) https://youtu.be/1ZTRb-2DZGs?t=3331

See also: the brokenness of most schemes to cross-compile applications (including producing cross compilers).

Rob's clear thinking here definitely had an influence on why Go's compiler is one of the few to have a sane cross-compilation story.

This is:

S. Mirhosseini and C. Parnin. “Docable: Evaluating the Executability of Software Tutorials”. 2020. https://chrisparnin.me/pdf/docable_FSE_20.pdf

See Hinsen, "software rot".

This is the second time this appears in this paper.

Previously: https://hypothes.is/a/Mm9whNQFEe2J6Y97btVQBQ

The ambiguity (i.e. non-machine-readability) of tutorials described in this paper is a good example to demonstrate both what it means for something to be an algorithm and what it means to "code" something.

You're looking for https://news.ycombinator.com/newswelcome.html

Isn't that pretty interesting? You'd think it would be the other way around.

In fact, what if it is the other way around? What if the failure of classic/legacy Web feeds has to do with power users' insistence on calling it "RSS"?

What? That's an insane comparison. This is like the total opposite of that comment; ActivityPub is super complicated.

This is bad protocol design. It violates (a variation of) the argument for the Principle of Least Power.

Also not to be confused with the notion from the area of information theory of Kolmogorov complexity. (At least not directly—but that isn't to say there is no relation there.)

Pretty nuts that Safari isn't open source. I thought for sure that Edge was going to be fully open source, both before and after the Blink conversion. Why even build closed source browsers in 2023?

If you are allowed by someone to owe them money, then what are you getting revenge for...?

the export blind spot effect, when tutorial creators do not anticipate steps where novice tutorial takers may have difficulty

I call this "developer tunnel vision".

In other words: spam

The purpose of SublimeText is not to be "relevant" or "compete" against VSCode in the social media influencer sense of relevance and competition. It is to be a text editor that makes the author money both directly and indirectly (i.e. by selling licenses and being the kind of text editor that the author themselves uses to make software).

This is such bizarre article and headline. It's almost clickbait.

This is folly.

Identifiers are public information.

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-806

Whether it was from a drugstore or not, that $40 in 1962 was like $400 today...

Premature generalization is the root of all evil?

Calling out the X/Y Problem.

Most people who think they need a database really just need a cache? See jwz on the Netscape mail client:

So, we have these ``summary files,'' one summary file for each folder, which provide the necessary info to generate that message list quickly.

Each summary file is a true cache, in that if it is deleted (accidentally or on purpose) it will be regenerated when it is needed again

https://www.jwz.org/doc/mailsum.html

Why would you pick Python for this?

That's not a position supported by the opinion itself. It claims (explicitly) that there are.

from https://web.archive.org/web/20061108162904/http://www.stifflog.com/2006/10/16/stiff-asks-great-programmers-answer/

... but instead replacing all the cognitive load that would have gone to that task instead to reasoning about AWS infrastructure...

... which, as it turns out, is exactly what Yegge said he thought was going to happen in his response to the question that Linus was answering.

from https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/june/don-t-get-me-started-the-silent-majority-why-visual-basic-6-still-thrives

from https://news.ycombinator.com/item?id=22616667

from https://news.ycombinator.com/item?id=8439611

Consider also a change to the conventions of UGC, where service operators give control of the objects (URLs) "owned" by a given user over to them, the owner. You should be able to connect your account with a request servicer like Cloudflare. You upload a document specifying how a worker should handle the request to your servicer of choice, inform the website operator that you'd like to route your requests through the servicer, and you're good.

No they don't.

This conflates the runs-in-a-browser? property with the depends-on-mobile-code? property.

mm... not really

This is such a good title.

Just be honest about your scumminess, instead of trying to be cute.

What if someone exploited this for a conversion strategy—and it was planned that way all along?

Startup A receives VC investment. They spend it wooing creators to their platform, and those creators are able in turn to make a profit. The startup doesn't take a cut. The signs that they are going to crash and burn appear. Suddenly, 6 months before even the most pessimistic critics would have guessed, the startup announces that it is the end of their incredible journey. They warn everyone that in two weeks it will flip to read-only, and then 4 weeks after that it will go dark. Everything goes nuts. The creators were relying on the platform themselves to make money. No platform means no money. Suddenly a solution appears: Startup B. They offer more or less a drop-in replacement for Startup A's highest revenue-generating users. The only catch is that Startup B's plans cost money. Startup C also appears, along with Startup D, each catering to a different segment of stalwarts who haven't signed a deal with B. In fact, B then announces that they're investing in C and D, in order to promote a healthy ecosystem. Somehow A appears and says that they're investing in C and D, too. Meanwhile, A's sunset never happened—a month after the site went read-only, it's still in read-only mode. Then A announces low-cost paid plans, flips back to read-write, and opens for new signups, having successfully converted the most lucrative clients to the more expensive plans with B since they knew it was in their best interests to maintain continuity of revenue no matte the costs.

Yes.

Does that dislike extend to the reformatting of old publications e.g. when you pick a new template for your site? I'd guess not, but I'd argue that you should at least consider not doing that, either.

... unless...?

Better analogy: in real life you can't actually unpublish something. At best you can go around trying to snatch up copies and then burn them. More realistically, you can published a new edition with corrections to errata incorporated, but—notably—the "bad" version will always be *Blah Blah Blah, first ed." The existence of the second edition doesn't erase the first one from people's bookshelves.

It's on the Web and how poorly orgs' information architecture is carried out that foo.example.com/bar can be one thing one day and then another thing entirely the next day. If we used URLs like <https://mitpress.mit.edu/Zachary, G. Pascal. Endless Frontier: Vannevar Bush, Engineer of the American Century. 1st ed. MIT Press, 1999.> would this be as big of a problem? Would doing so nudge born-digital documents in the same direction?

Edit it, sure. But don't clutter the ability to unambiguously refer to the previous version (by the same name it was given initially) as a way to distinguish it from later versions.

In my experience the file-and-folder model is the reason behind so much URL breakage. People don't seem to realize that even if you have foo/bar/ and foo/baz/, then that doesn't mean that you need to have a view that involves bar/ and baz/ among other things contributing to the "clutter" perceived when gazing upon something called foo/ (and that foo/, in turn, cluttering up whatever it's "inside").

It's this perceived clutter and the compulsion to declutter that leads to people moving stuff around in the pursuit of a more legible model.

There's a lot wrong with Google Docs, but the fact that documents stick around is not one of them. Documents should stick around.

No.

Nah. The latest URI should be a (temporary) redirect to the canonical URI of whatever the latest version is.

"Don't change your URIs" and "don't stop maintaining your documents" is contradictory.

If Kartik has a published document at /about in 2022 and then when I visit /about in 2023 what it said before is no longer there and it says something else instead (because he has been "maintaining" "it"), then that's a URI change. These are two separate documents, and the older one used to be called /about but now the newer one is.

It's actually the expectation that /stormforce/closings.shtml should mutate, reflecting recency that is anathema to the project here...

The tone immediately makes me question the credibility/reliability of the information in this piece. (Perhaps, though, I made a mistake in not realizing not to expect too much from a site calling itself "allaboutlean.com"...)

Not unlike shopping carts and the modern grocery store (Piggly Wiggly), footnotes, and page numbers, this is something that had to be invented.

Notably, though, it is not a market product.

Bart asked me about what it is that I think causes NPM to be so bad, generally (or something like that), and I responded with the one-word answer "insecurity".

I think "striving for acceptance" is a better, more diplomatic way to put it.

Imagine if they answered "Google Docs, and then pick 'HTML' when you save it".

It's the sort of thing that seems obviously wrong on its face, but in practice is more expedient and not egregiously worse than the accepted alternative.

See https://web.archive.org/web/20050305223533/http://www.nesc.ac.uk/esi/events/Grand_Challenges/proposals/Memories.pdf.

(From https://web.archive.org/web/20050305223533/http://www.nesc.ac.uk/esi/events/Grand_Challenges/proposals/.)

Based on https://empslocal.ex.ac.uk/people/staff/pjbrown/public_html/annotation/jodi_dec.html, this paper is from 2003.

This is an unfinished form of the paper that's available (without broken inline images) here:

http://diglib.stanford.edu:8091/diglib/pub/reports/commentor.html

Try http://infolab.stanford.edu/pub/papers/extract.ps

Available at http://diglib.stanford.edu:8091/diglib/pub/reports/brio-chi95.html

Now at http://hci.stanford.edu/~winograd/papers/acm97.html

A draft(?) version with inline comments by Winograd: http://hci.stanford.edu/~winograd/papers/annotations.html

It's here: http://www.dlib.org/dlib/august95/stanford/08roscheisen.html

Available at http://diglib.stanford.edu:8091/diglib/pub/reports/commentor.html

Traveller:

Try https://dougengelbart.org/content/view/114/ instead.

Alternatively, try cajoling yourself to invert the "[kind of like] the present, but cruder" thinking and frame the present in terms of the past—with present systems being "Engelbart, implemented poorly".

wat

'k, but we should also be able to see (a) that it has been edited, (b) what was edited, (c) how to unambiguously refer to a particular revision. To not offer the ability to do so is to take advantage of something that is technically achievable given the architecture of the Web but violates the original intent (i.e. to give someone a copy that looks like this at one point and then when they or someone else asks for that thing at a later date to then lie and say that it really looks like that).

WTF? This has fuck-all to do with RSS.

Mmm... how? It's just linear, unless I'm missing something.

You don't need to do that.

Also: this problem is not specific to podcasting. It affects everything to do with RSS, generally.

read: links to

This makes it sound like a hack/workaround, but to want to do otherwise is to want to do something that is already on its face wrong. So there's no issue.

This shouldn't even be an argument. package-lock.json isn't free. It's like cutting all foods with Vitamin C out of your diet and then saying, "but you can just take vitamin supplements." The recommended solution utterly fails to account for the problem in the first place, and therefore fails to justify itself as a solution.

Uh... what? This is a total shifting of the goalposts.

Excellent summation.

Give this one another go and think it through more carefully.

Emphasis: last sentence

The common perception of the Web as a sui generis medium is also harmful. Conceptually, the most applicable relevant standard for Web content are just the classic standards of written works, generally. But because it's embodied in a computer people end up applying the standards of have in mind for e.g. apps.

You check out a book from the library. You read it and have a conversation about it. Your conversation partner later asks you to tell them the name of the book, so you do. Then they go to the library and try to check it out, but the book they find under that name has completely different content from what you read.

I abhor tardiness and agree that being early is good advice, but this is a fucking stupid saying.

Being on time is on time.

(I mean this generally—not specific to the setting of this article.)

"30 minutes", immediately followed by "45 minutes"... What?

If you don't want version control, then that's your choice, but admit it (ideally out loud for others to hear, but failing that then at least to yourself) that that's what you're about.

Funny (and ironic) that you should ask...

I myself have been asking lately, what problem does the now-standard "Run npm install after you clone the repo" approach solve? Can you state the NPM hypothesis?

See also: builds and burdens

I'm not going to make the same defenses that folks on HN prefer.

But the problem with Casey's worldview is that it provides no accommodations for the notion of zero-cost abstractions.

I didn't realize recursive descent was part of the standard grugbrain catechism, too, but it makes sense. Grugbrain gets it right again.

Not unrelated—I always liked Bob's justification for using Java:

I won't do anything revolutionary[...] I'll be coding in Java, the vulgar Latin of programming languages. I figure if you can write it in Java, you can write it in anything.

https://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

This goes on to provide a bunch more info with the express purpose of making it possible to 1. Print out this page, and then 2. Recreate the whole thing by hand if you wanted to, using only the printed page as reference.

Could easily add a section that describes a bookmarklet that you could use to transform the "live" (in-browser) document into something formatted like the one at "This page is a truly naked, brutalist html quine" https://secretgeek.github.io/html_wysiwyg/html.html.

Note that if you add any highlights using Hypothes.is to any of the CSS code blocks here, it will break them.

If you're looking for Stavros's "no-bullshit image host", that's https://imgz.org/

NB: there may be a race condition here? In which case, running into errors should be (one) expected outcome.

ETOR probably stands for Estimated Time of Restoration

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

This is stated like unanimous agreement is a foregone conclusion.

The Web is for content. Just because people do build in-browser facsimiles of mobile-style app UIs doesn't mean that the flattening of content and controls into a single stream is something that everyone agrees is a good thing and what should be happening. They should be doing the opposite—curbing/reigning it in.

You mean your promise—the position of the Web Hypertext Application Technology Working Group.

Have you considered that the problem might have been you and what you were trying to do? You're already conceding failure at what you tried. Would it be so much worse to say that it was the wrong thing to have even been trying for?

You mean developers will gain.

Fuck developers.

Jesus fucking Christ. Fuck this shit.

This isn't new. Also: good—application developers shouldn't be the only ones holding the keys to the kingdom when it comes to making stuff available on the Web. Authors* and content editors should have those keys.

* in the classic sense; not the post-millennium dilution/corruption where "authors" is synonymous with the tautologically defined "developers" that are spoken of when this topic is at the fore

On HN, the user bitwize (without knowing he or she is doing so) summarizes (the first half, at least) of the situation described here:

The appeal of JavaScript when it was invented was its immediacy. No longer did you have to go through an edit-compile-debug loop, as with Java, or even an edit-upload-debug loop as with a Perl script, to see the changes you made to your web-based application. You could just mash reload on your browser and Bob's your uncle!

The JavaScript community, in all its wisdom, reinvented edit-compile-debug loops for its immediate, dynamic language and I'm still assmad about it. So assmad that I, too, forgo all that shit when working on personal projects.

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

Basically, ignore almost everything that Modern JS practitioners tell you that you need to be doing. You're halfway there with this experiment.

One of the most interesting and high-quality JS codebases that has ever existed is all the JS that powers/-ed Firefox, beginning from its conception through to the first release that was ever called "Firefox", the Firefox 3 milestone release, and beyond. To the extent that there was any build system involved (for all intents and purposes, there basically wasn't), the work it performed was very light. Basically a bunch of script elements, and later Components.utils.import calls for JSMs (NB: not to be confused with NodeJS's embarrassing .mjs debacle). No idea what things are like today, but in the event that there's a lot of heavy, NodeJS-style build work at play, it would be wrong to conclude that it has anything to do with necessity e.g. after finally reaching the limits of what no-build/low-build can give you (rather than just the general degradation of standards across Mozilla as a whole).

The best possible outcome for everyone likely includes a world where MS open sourced (at least as much as they could have of) Trident/EdgeHTML—even if the plan still involved abandoning it.

Ooh... this might benefit from improvement. I mentioned to Rochus the benefits of direct (no build step) runnability in the vein of Python or JS, and he responded that he has already done this for Oberon+ on the CLI/CLR.

For the same reasons that direct runnability is attractive, so too might be the ability to copy and paste to mix both syntaxes. (Note that this entirely a different matter from whether or not it is a good idea to commit files that mix upper and lower case; I'm talking about friction.) Then again, maybe not—how much legacy Oberon is being copied and pasted?

I agree, of course, with the criticism of the price point. As I often say, $9.99/month (or even $4.99/month) is more expensive than premium email—and no matter how cool you think your thing is, it's way less important than email. You should always return something for ~$20, especially if you already have a free tier. (When I say "for $20" here, I'm talking about a one time payment, or on a subscription basis that maxes out at $20/yr.)

The following musings are highly specific to the market for what's being sold here.

Paying $20 should get you something that you aren't bothered about again for the next year. Maybe to make it even easier, enable anyone to request a refund of their $20 for any reason within the first 7 days. This gives a similar feel to a free trial, but it curbs abuse and helps target serious buyers in the first place. In the event that 7 days is not enough time even for people to convince themselves that they need it, maybe keep open the ability to use a severely limited version of the service for the remainder of the year. E.g. you can continue to log in and simulate what you'd get with the full version, but it's only accessible to you because you can't publish them and/or share links with anyone who doesn't have access to your account.

Despite being a Rust apologist and the fact that this paper makes Rust look better than its competitors, Steve Klabnik says this paper is quite bad and that he wishes people would stop referencing it.

For Oberon+, try https://oberon-lang.github.io/

The W3C actually chartered a CSV working group for CSV on the Web. Their recommendation resolves ambiguities of the various CSV variants, and they even went on to supercharge the format in various well-defined, nice-to-have ways.

Huh? This sounds like it's saying the opposite of what was said two paragraphs earlier.