Nice turn of phrase.

This was tired the second time it occurred in this piece. Three times is def. too much.

Not a fan of this piece, overall.

Cryptocoin hype/scams are dumb. Who cares.

Yes, those are the questions for people interested in pieces like this one. What are the answers?

Not really. https://web.archive.org/web/20150828195814/http://adamspitz.com/avocado/2011/05/05/open-source-is-not-enough/

What's with the Americanized punctuation style here?

Change my view: Hypothesis is suitable for this.

Here's one: suppose Alice reads a book and adds it to her library then learns through this system that Tom, Dick, and Mary have it in their libraries, too. Thing is, Tom finished reading it 6 weeks ago, Dick read it last summer, and Mary read it 12 years ago as an undergrad. Would this be a good reading group?

As a sort of "gutter bumper" approach, guiding you on what is and isn't accepted in the language, they're nice, but I can imagine as a child that it would have annoyed me when I wanted to express something and found that the "only" reason why I couldn't follow through on something was because they made something the wrong shape, keeping me from doing the thing, and not understanding.

Contrast this with the remark below about pattern languages being "a set of design rules that loosely define how a system should work, rather than a strict specification".

https://hypothes.is/a/QtqfWujBEey_TWdqwW7yQw

Turtles are reptiles.

Is "layer" the right choice here?

NB: this is culture-specfic

NB: these two metaphors are at odds. You can see this in the way that authors treat user agent overlays as intrusions into their space—a place for them to control, instead of e.g. a note clipped to the copy that belongs to the reader.

The owned-space one is definitely worse, but I fear that for many people it's now the default—for both those seeking control and those who are the indirect objects of control.

I don't know if this is true for anyone. It certainly seems like most people who are digital natives (or immigrants) rarely make the connection and end up missing out on some lessons from print that would actually be helpful.

This pie in the sky has been promised for the last 10+ years. It's not happening.

A lot of these ideas are junk. This one, though, is achievable. triplescripts.org.

ALGOL 2020

Fun fact: the amount of time between 2010—the year Dahl mentions here—and ES2015—aka ES6, where modules appeared—is less than the amount of time between ES2015 and today. And yet people act like modules are new (or worse, just over the horizon, but still not here). It's a people problem.

This is misleading/hyperbolic. The performance characteristics of WASM vs JS are nothing like a native binary vs the Bash interpreter.

See also: The Pinocchio Problem

Some incarnation of the Fly Pentop/Livescribe focused on this.

See also; plugging these: * A new publishing discipline * plain.txt.htm (An assembler)

The fact that the author is describing it in these terms is really evidence that the main achievement here is overcoming the limitations of his or her own mental blocks.

This is an excellent piece, even though the writing is (probably intentionally) in places too obscure.

Ibid

Probably not the best descriptor, owing to domain collision. Almost anything else would be better, e.g. "Gallery".

Dear Wanderer:

You're looking for http://pascal.hansotten.com/uploads/ucsd/ucsd/Richard%20Kaufmann%20-%20What%20The%20Heck%20Was%20UCSD%20Pascal.pdf

Also available on Vimeo https://vimeo.com/127605643

@5:50:

In this portion of the machine, we keep these brass matrices.

Throughout, "matrices" can be heard to be pronounced as "mattresses". Could this have something to do with the origin of the phrase "going to the mattresses"? It seems more likely than the conventional explanation that involves safehouses and literal mattresses, which strikes me as really dubious.

Compare "capicola" → "gabagool".

NB: I'm pretty sure this is referring to fact that the site was live, and it had open registration. The source code was not being worked on in the "open", even under lax definitions of that word.

Is "automated deployments" really the solution?

wat

gross

Much of the (apparent) progress (i.e. activity—whether it constitutes busywork is another matter) in the world of "JS Prime" (that is, pre-Reformation, NodeJS/NPM-style development) is really about packaging problems.

NodeJS development is often standards-incompatible with JS-the-language and other (actually standardized) vendor-neutral APIs.

"'JS' does not mean 'Node'"

Reality: this has a lot to do with the problems here.

Remedy: ignore the NodeJS toolchain bullshit[1], rip out the thing you're interested in, and stuff it into an ordinary page foo.hmtl.

1. https://pg.ucsd.edu/command-line-bullshittery.htm[2]

2. https://hypothes.is/a/22JaWMu5Eey2UvchosEz6Q

I wrote a thing about this sort of thing: https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html

It helps to be accurate (if we ever want to see these things fixed):

They didn't "bounce off JS". They "bounced" after seeing NodeJS—and its community's common practices.

Related: comments about deployability of PHP over in the comments about "The Demise of the Mildly Dynamic Website".

I can't help but think that currentgen programmers are misunderstanding Knuth and anachronizing him, with their being a product of the current programming regime where most never lived in a world without structured programming, for example, when we hear "literate programming", we attempt to understand it by building off our conception of current programming practices and try to work out what Knuth could mean given widespread modern affordances as a precondition, when really Knuth is just advocating for something that approximates (with ink and paper) currentgen tooling, and is therefore in fact more primitive than our reference point which we are trying to understand as being capable of being improved upon, but Knuth's LP is an improvement nonetheless of something even more primitive further still.

Good example of a "narrative elsewhere".

The joke being that both jQuery and COBOL were crummy right from the beginning, and now they're crummy and old, right?

What does this even mean?

I also find it laughable/horrifying the comparison between jQuery and greybeardism (or, elsewhere, a bicycle[1]). jQuery is definitely not that. It is the original poster child for bloat.

For all the people feigning offense at the "greybeard" comments at the thread start, it's much more common, unfortunately, to find comments like this one, with people relishing it when it comes to jQuery, because it confers an (undeserved) sense of quasi-moral superiority, wisdom, and parsimony, even though—once again—jQuery represents anything but those qualities.

1. https://news.ycombinator.com/item?id=31440670

jQuery is primarily a DOM manipulation library and incidentally smoothed over differences in browsers' DOM implementations. To the extent that there were any significant differences in browser's JS implementations, jQuery offered little if anything to fix that.

This is 70+% of the reason why I end up ripping out jQuery from old/throwaway projects when I start trying to hack on them. The jQuery object model is really confusing (read: tries too cute/clever), and the documentation sucks, relatively speaking, and the code is an impenetrable blob, which means reading through it to figure out WTF it's supposed to do is a non-option.

This happens to be true of many of the new/up-to-date Web developers I see, too.

Anecdote: I never really did StackOverflow, either as a reader or a contributor. One day several years ago (well after StackOverflow had taken off), I figured that since I see people complain about JS being confusing all the time and since I know JS well, then I'd go answer a bunch of questions. The only problem was that when I went to the site and looked at the JS section, it was just a bunch of jQuery and framework shit—too much to simply ignore and try to find the ones that were actually questions about JS-the-language. "I know," I thought. "I'm in the JS section. I'll just manually rewrite the URL to jump to the ECMAScript section, which surely exists, right? So I did that, and I just got redirected to the JS section...

This remark manages to make this one of the dumbest comments I've ever read on HN.

I'm having real difficulty understanding what is going on here and in what situations such cascading problems occur.

Is it a case of under-abstraction?

Does "what they need" here implicitly mean "a design that no one really benefits from but you can bill a client for $40+/hr for"? Because that's how Glitch comes off to me—more vocational (and even less academic) than a bootcamp without the structure.

What was that part about home-cooked meals?

This is where I think Glitch goes wrong. Why such a focus on apps (and esp. pushing the same practices and overcomplicated architecture as people on GitHub trying to emulate the trendiest devops shovelware)?

"Web" is a red herring here. Make the Web more accessible for app creation, sure, but what about making it more accessible (and therefore simpler) for sharing simple stuff (like documents comprising the written word), too? Glitch doesn't do well at this at all. It feels less like a place for the uninitiated and more like a place for the cool kids who are already slinging/pushing Modern Best Practices hang out—not unlike societal elites who feign to tether themself to the mast of helping the downtrodden but really use the whole charade as machine for converting attention into prestige and personal wealth. Their prices, for example, reflect that. Where's the "give us, like 20 bucks a year and we'll give you better alternative to emailing Microsoft Office documents around (that isn't Google Sheets)" plan?

See also An app can be a home-cooked meal along with this comment containing RMS's remarks with his code-as-recipe metaphor in the HN thread about Sloan's post:

some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.

Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.

And how future-proof was the result or how easy was it to make sure you could share it with others in a form that they could make use of (and not be dependent on you or some third-party or their internet connection)?

There's a related phenomenon/paradox: the superinferiority of "native" applications.

superfluous and ostentatious

this page should link to the flyctl CLI docs

When I created a blank app with flyctl launch, it gave me a fly.toml with 8080. The fly.toml cloned from the repo, however, already has it set to 8043.

It's possible that the quoted section is still correct, but it's ambiguous.

Also available here, from the Computer History Museum's channel on YouTube (parts 1 and 2): * https://www.youtube.com/watch?v=_oGq1RcM8B0 * https://www.youtube.com/watch?v=4ffAkshf2n8

Also available here: https://www.ayeconference.com/Articles/Whatssospecialaboutsw.html

This is supposed to be the justification for increasing code size. So what's the excuse for projects today? Software of today is not exactly known for adding more "error checking and correction". It feels more like growth for growth's sake, or stimulating some developer's sense of "wouldn't it be cool if [...]?".

No need to constraint yourself to comments, though. Why comments? We can do full-fledged, out-of-line doclets.

This is part of the reason why I advocate for language skins for comparatively esoteric languages like Ada.

Well, there could still be a weave step—same as there is like with triple scripts (to go from compilation form back to the original modules) or with Markdown, which should be readable both as plain text and in rendered form.

(NB: the compilation "object" format here would, much like triple scripts, be another form of human readable source.)

Do we have to wait for people to die before these kinds of digital fanclubs can materialize for people who aren't in entertainment?

Having trouble sourcing this quote? That's because some shithead who happens to run a popular programming blog changed the words but still decided to present it as a quote.

Raskin's actual words:

the fundamental reason code cannot ever be self-documenting and automatic documentation generators can’t create what is needed is that they can’t explain why the program is being written, and the rationale for choosing this or that method. They cannot discuss the reasons certain alternative approaches were taken. For example:

:Comment: A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique. :End Comment:

From "Comments Are More Important Than Code" https://dl.acm.org/ft_gateway.cfm?id=1053354&ftid=300937&dwn=1

This is a good case study for what I talk about when I mean the fancub economy.

Wouldn't it be better if gklitt were a willing participant to this aggregation and republishing of his thoughts, even if that only meant that there were a place set up in the same namespace as his homepage that would allow volunteers ("fans") to attach notes that you wouldn't otherwise be aware of if you made the mistake of thinking that his homepage were his digital home, instead of the place he's actually chosen to live—on Twitter?

I loved the Moto G (the original—from during the brief time when Google owned Motorola). I used it for 6 years. It's not even an especially small phone. Checking the dimensions, it's actually slightly smaller (or, arguably, about the same size) when compared to either the iPhone 12 Mini and the iPhone 13 Mini—which I'd say makes those deceivingly named. They're nothing like that one that Palm made, which is called, uh... "Palm", I guess. (Described by Palm as about the size of a credit card.)

Memory usage is a concern? wat

It's a problem, sure, if you're programming the way NPMers do. So don't do that.

This is a huge problem I've noticed when it comes to people programming in JS—even, bizarrely, people coming from other languages like Java or C# and where you'd expect them to at least try to continue to do things in JS just like they're comfortable doing in their own language. Just because it's there (i.e. possible in the language, e.g. dynamic language features) doesn't mean you have to use it...

(Relevant: How (and why) developers use the dynamic features of programming languages https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf)

The really annoying thing is that the NPM style isn't even idiomatic for the language! So much of what the NodeJS camp does is so clearly done in frustration and the byproduct of a desire to work against the language. Case in point: the absolutely nonsensical attitude about always using triple equals (as if to ward off some evil spirits) and the undeniable contempt that so many have for this.

on baggage: "package.json", for example, is not an ECMA standard

My argument: JavaScript is a future-proof programming language

Also (related moreso to Future-proof), Haxe? Dart?

Absent from consideration: * Gecko/XULRunner (check out the way that Zotero is built) * GtkJS

Both deserve a look

My reaction to the author's take on future-proof programming languages even before I got to this post (and this part in it) was that he should look at porting (or getting ported) the C# standard libraries (to JS—as part of my argument that JS the future-proof programming language Krinke is looking for).

Dear wanderer:

A copy of the content you're looking for can be found here: https://s3-eu-west-1.amazonaws.com/kosmos-social/media_attachments/files/105/949/240/042/806/220/original/0572af7c5d7f0191.png

Consider ways to build on the static node architecture that wouldn't require you to give this up:

• PGP blobs instead of plain text
• messages relayed through WebRTC when both participants are online
• you could choose to delegate to a message service for your DMs, to guarantee availability, just like in the olden days with telephones

Yes.

Interesting that this is written by a BSD guy.

This is really only a problem in languages that make the unfortunate mistake of allowing references to unqualified names that get fixed up as if the programmer had written this.mPoint or Foo.point. Even if you're writing in a language where that's possible, just don't write code like that! Just because you can doesn't mean you have to.

The only real exception is distinguishing locals from parameters. Keep your procedures short and it's less of a problem.

similar to my strawman for language skins

This old hat description captures something not usually brought up by CLI supremacists: GUIs as ways validate and impose constraints on structured data.

(NB: this is in response to the question Why not just use wordpress + wysiwyg editor similar to *docs, and you're done?.)

This is a good of an explanation as any for local-first software.

A natural response (to potatolicious's comment) is, "Well, somebody has to maintain these no-code Web apps, too, right? If there's someone in the loop maintaining something, the question still stands; wouldn't it make more sense for that something to be e.g. a WordPress instance?"

Answer: yeah, the no-code Web app model isn't so great, either. If service maintenance is a problem, it should be identified as such and work done to eliminate it. What that would look like is that the sort of useful work that those Web apps are capable of doing should be captured in a document that you can copy to your local machine and make full use of the processes and procedures that it describes in perpetuity, regardless of whether someone is able to continue propping up a third-party service.

There's plenty of irrationality to be found in opposing camps, too. I won't say that it's actually worse (because it's not), but it's definitely a lot more annoying, because it usually also carries overtones that there's a sort of well-informed moral and technological high ground—when it turns out it's usually just a bunch of second panel thinkers who themselves don't even understand computers (incl. compilers, system software, etc.) very well.

This is what makes it hard to have discussions about reforming the practices in mainstream Web development. The Web devs are doing awful things, but at least ~half of the criticism that these devs are actually exposed to ends up being junk because lots of the critics unfortunately just have no fucking idea what they're talking about and are nowhere near the high ground they think they're standing on—often taking things for granted that just don't make sense when actually considered in terms of the technological uppercrust that they hope to invoke. Just a kneejerk "browser = bad" association from people who can't meaningfully distinguish between JS (the language), browser APIs, and the NPM corpus (though most NPM programmers are usually guilty of exactly the same...).

It's a very "the enemy of my enemy is not my friend" sort of thing.

Flems does something like this:

To allow you to use Flems with only a single file to be required the javascript and the html for the iframe runtime has been merged into a single file disguised as flems.html. It works by having the javascript code contained in html comments and the html code contained in javascript comments. In that way if loaded like javascript the html is ignored and when loaded as html the javascript part is ignored.

https://github.com/porsager/flems#html-script-tag

I've referred to a similar (but-unrelated) architecture diagram for writing platform-independent programs as being a Klein bowtie. There is a narrow "waist" (the bowtie know), with either end of the bowtie being system-specific routines (addressed by a common interface in the right half of the diagram).

From https://news.ycombinator.com/item?id=31378614:

There's this tendency of languages to want to be the be-all end-all, i.e. to pretend that they are at the center of the universe. Instead, they should focus on interoperating with other languages[...] This is one reason I'm working on https://www.oilshell.org -- with a focus on INTEROPERABILITY

wrt the sentiment in the McHale tweet:

See Tom Duff's "Design Principles" section in the rc manual http://doc.cat-v.org/plan_9/4th_edition/papers/rc, esp.:

It is remarkable that in the four most recent editions of the UNIX system programmer’s manual the Bourne shell grammar described in the manual page does not admit the command who|wc. This is surely an oversight, but it suggests something darker: nobody really knows what the Bourne shell’s grammar is.

See also https://www.oilshell.org/blog/2022/02/diagrams.html

Chesterton's fence/Rhesus ladder

Reference to a Kiczales talking point, e.g. Why are Black Boxes so Hard to Reuse?.

This is a very odd place to apply the word "compression", since pretty much the opposite is happening: there's enough redundancy that a single signal error doesn't bungle the entire attempt to communicate.

I think the only thing I liked that got close to this was Keybase.

Consider a Sufficiently Smart Compiler/Runtime where a multiply-instanced class has the exact same runtime characteristics as code that has been hand-"tuned" to use a singleton.

This is a fine perspective as long as you're not penalizing people who arrive at 12:59:59 — "If you are on time, you are late" is a stupid mantra that, while my sample size is low, I've only heard from people who were themselves egregious time wasters and made the remarks as a way of honoring Ra.

(I'd argue further that anyone who arrives at any time between [13:00:00, 13:01:00) are doing okay, so long as they're wiling to accept that no one is obligated to wait for them. I.e. what "the meeting is at 1:00 PM" means is that everyone has permission to start the meeting at 13:00:00, whether you're there or not.)