need for cheaper throwaway tests

A strength of boring tech that relies on the traditional folders-of-files approach, incl. e.g. the byproducts of using office suites.

That doesn't describe anything. It's a grid of GitHub avatars. What am I supposed to be seeing?

In other words, singletons are harmful.

In saner bugtrackers like e.g. Bugzilla the community is empowered to step in and triage bugs. GitHub infamously chose to go for a "simpler" system with fewer frills, pomp, and circumstance. Perversely, this has the opposite of the intended effect. The net result is that for the community to have these powers, the project owner has to explicitly grant them to individual users, which is considered to be a lot more heavyhanded/ceremonial than how it works on bugzilla.mozilla.org.

I'd have no problem, for example, stepping in and enforcing these things if it weren't the case that it were such a chore to go through the ceremony and getting approval to police this kind of stuff. GitHub's lackluster approach to user privacy, of course, doesn't help.

Signal trades on some other stuff of dubious* merit, like the "guarantees" of SGX, and does other user-hostile stuff: requiring a PIN, doing user data backups without permission, locking out third-party clients... (What's worse is that the latter is excused as being the only way to reliably enable the undesirable "enhancements").

* Even calling it merely "dubious" here is pretty generous.

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.

Okay, so the original source seems to be Proteus (A Journal of Ideas). Specifically, vol. 3, iss. 1. (Thanks to Nikos Katsikis by way of Neil Brenner for helping track this down.)

Also available here under the alternate title "Livingry" from BFI: https://www.bfi.org/about-fuller/big-ideas/livingry/

See also, from Brooke Allen's "How to hire good people instead of nice people" https://brookeallen.com/2015/01/14/how-to-hire-good-people-instead-of-nice-people/:

I won’t get between you and your dreams. If you have a dream, I need to know what it is so we can figure out if this job gets you closer. If you don’t have a dream then that’s fine, as long as you really want one and you’re not addicted to wishing and complaining.

Also available here (as a scanned PDF; original source unclear): https://designsciencelab.com/resources/HumanitysPath_BF.pdf

I can't parse this. Ravasio says any typo is probably her fault. The best I can come up with is "an enormous amount of energy", which doesn't make sense as a typo, but does sort of sound the same.

I don't think this is a good definition. The example, at least, is a bad one. That resource could still exist (the same way a .docx that lives in the Documents directory and has been uploaded but later had the file host go down would still exist)—it just wouldn't be resolvable by URL.

I don't think this is a good example. I'd call it bad, even. It's self-defeating.

This page is excellent for an example of HTML being an adequate substitute for traditional office formats.

Yeah, why has this become so normalized? It's gotten to the point where people will respond to something by posting nothing but an attempt at false attribution by rewording the other—typically in the most convenient, pithy, hackneyed, and strawmannish way—and then putting quotes around it while drowning in plaudits from those who already agree—often for reasons no better than shameless tribal affiliation.

The basic precondition to summarizing the other's position in order to refute it is that the other side actually agrees that it's an accurate summary of their position. If you don't have that, then you don't have anything.

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

This presupposes something that I see frustrates many people who are the main audience for pieces like this.

Is this step #1 or not? Where did those people come from? I see way too many people wave their hands on this part, which is silly, because this is the part that people are most interested in.

The thing I really admired about Chris Lattner in an interview I listened to during lockdown was the fact that (one of?) the first things he mentioned about success was the role that luck played in his life. There's a tacit admission there that, although he's Chris Lattner and a really smart guy and clearly deserving of his success because of the foregone facts we now have access to, even if you reset everything but didn't manage to replicate the exact circumstances, then things might not actually work out like they did the first time. It's a tacit admission that replicability is not just not guaranteed but that results are almost akin to a crapshoot.

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.

Meanwhile, when I reported an error (broken link) in Cloudflare's documentation to a developer there, I was told "I'm sorry that our workflow doesn't work for you, but relaying typo reports through e-mail doesn't scale well on our end," just before snidely signing off with a lame attempt to upperhand: "I guess we'll have to get by without your reports."

Ibid

This wouldn't be so annoying to read if it weren't the case that this was solved like 15+ years ago by the right tool for the job: wikis.

I see the "neo-OSS era" or "New Social era" of today to stand in sharp contrast with what I've previously referred to as the Shirky era. In the world of software development, the regressions from the transition from the Shirky era to the present, monumental though those regressions are, have been quietly underreported (seemingly hardly even perceived). We've seen the rise and consolidation of open source project management around a centralized (and perversely, closed source) service provider that's more of a social network and valued for that reason than it is a decent bugtracker or wiki. It calls things wikis that aren't, not just diluting the word but instead transforming it into something that is by now effectively meaningless—along with encouraging awful mixing of support requests and freeform discussion with bugtracking (but that's beside the point).

The big hallmark of this era: obtuse publishing pipelines that seek to replicate the compiler-input →compiler → compiler-output workflow, pushed heavily by new programmers who first encountered compilers during this era and encouraged by others who bafflingly insist on applying this poorly chosen hammer to the non-nail-shaped problem. Why? What I can make out:

1. the omnipresent and inescapable influence of Ra

2. a desperation for legitimacy at a time when low-level system programming has been in decline

3. people just genuinely unable to perceive the effects of complexification, like the way some people cannot enjoy cilantro, or the way others cannot accurately track the passage of time without external help

It'd be nice if we could get back to a place where we understood that the point of all this stuff is to make things easier—particularly in the here and now, and in some mythical, never-reached promised land where travelers are perpetually kept away by the YAGNI demons.

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.

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