How's [0] or [1] for historical sources?

It's not surprising that Google doesn't turn these up, the golden era of this complaining was pre-WWW.

[0]: https://www.ee.torontomu.ca/~elf/hack/realmen.html [1]: https://melsloop.com/

Have you not noticed that the story you reference is so well know because... literally every single developer thinks people like Mel are crazy?

Mel or Terry Adams are the exception to the rule... Having that image of greybeards only come if you have never worked with one in real life, sorry you are biased.

What? Mel is regarded as deserving massive respect, not as crazy. If a developer thinks Mel is nuts, they are coming from a perspective I don't understand.

And yes, the shift to higher level languages like C, FORTRAN, etc., was regarded by some as pandering to the new generation that didn't want to actually learn programming.

With some truth, in my opinion. I think higher level languages bring huge benefits, so I'm not bemoaning their existence. But it still weirds me out when there's a professional developer that doesn't have at least a cursory knowledge of assembly. AI programming assistance (which I'm sure will be very different than today's 'vibe coding') does seem like a similar state change. I certainly don't object to it in principle, it will probably be a large productivity improvement.

But I'm sure that with it, there will be the loss of fundamental knowledge for some people. Like digital artists who never learn the properties of real paint.

how would you encode a program like

    function f<T>(x: T) { return x; }
    function g(x: number) { return { a: f(x), b: f(x.toString()) }; }

in sat?

if that's easy, how about length and f in:

    function append<T>(xs: list<T>, ys: list<T>) {
      return match xs {
        Nil() -> ys,
        Cons(hd, tl) -> Cons(hd, append(tl, ys)),
      };
    }
    function flatten<T>(xs: list<list<T>>) {
      return match xs {
        Nil() -> Nil(),
        Cons(hd, tl) -> append(hd, flatten(xs)),
      };
    }
    function map<T, U>(f: (T) => U, xs: list<T>) {
      return match xs {
        Nil() -> Nil(),
        Cons(hd, tl) -> Cons(f(hd), tl),
      };
    }
    function sum(xs: list<number>) {
      return match xs {
        Nil() -> 0,
        Cons(hd, tl) -> hd + length(tl),
      };
    }
    function length<T>(xs: list<T>) { return sum(map((_) -> 1, xs)); }
    function f<T>(xs: list<list<T>>) {
      return length(flatten(xs)) === sum(map(length, xs));
    }

hm-style inference handles polymorphism and type application without a complicated sat encoding

I wonder how well Proton would work for it...

It looks like colorForth runs in qemu or bochs according to documentation, so Proton/wine wouldn't be required.

Not counting, of course, the 30,177 suicides by American veterans in the wake of the global war on terror.

https://costsofwar.watson.brown.edu/sites/default/files/pape...

Beyond the Git history, is there any write-up of the different capability designs you've gone with?

I'm interested in implementing a safe low-level language with less static information around than C has (e.g. no static pointer-int distinction), but I'd rather keep around the ability to restrict capabilities to only refer to subobjects than have the same compatibility guarantees Invisicaps provide, so I was hoping to look into Monocaps (or maybe another design, if there's one that might fit better).

I summarize past attempts in https://fil-c.org/invisicaps

Test suites: https://github.com/riscv-software-src/riscv-tests

Formal model: https://github.com/riscv/sail-riscv

Are there even close to 2% of Debian users using a DEC Alpha?

popcon.debian.org reports 3 alpha installations and 261750 amd64 installations. Assuming comparable opt-in rates there are less than 0.002% of the users using alpha.

The other mentioned architectures hppa, m68k and sh4 are at a similar level.

isn't std::unordered_map famously slow, and you really want the hashmap from abseil, or boost, or folly, or [...]

It does feel like somebody forgot that "from the first sentence or two of the email, you can tell what it's about" was already a rule of good writing...

Maybe they remembered that a lot of people aren't actually good writers. My brother will send 1000 word emails that meander through subjects like what he ate for breakfast to eventually get to the point of scheduling a meeting about negotiating a time for help with moving a sofa. Mind you, I see him several times a week so he's not lonely, this is just the way he writes. Then he complains endlessly about his coworkers using AI to summarize his emails. When told that he needs to change how he writes to cut right to the point, he adopts the "why should I change, they're the ones who suck" mentality.

So while Apple's AI summaries may have been poorly executed, I can certainly understand the appeal and motivation behind such a feature.

I feel too many humanities teachers are like your brother.

Why use 10 words when you could do 1000. Why use headings or lists, when the whole story could be written in a single paragraph spanning 3 pages.

I mean...this depends very heavily on what the purpose of the writing is.

If it's to succinctly communicate key facts, then you write it quickly.

- Discovered that Bilbo's old ring is, in fact, the One Ring of Power.

- Took it on a journey southward to Mordor.

- Experienced a bunch of hardship along the way, and nearly failed at the end, but with Sméagol's contribution, successfully destroyed the Ring and defeated Sauron forever.

....And if it's to tell a story, then you write The Lord of the Rings.

Sure, but different people judge differently what should be told as a story.

"When's dinner?" "Well, I was at the store earlier, and... (paragraphs elided) ... and so, 7pm."

Now, that's very true! But it's a far cry from implying that all or most humanities teachers are all about writing florid essays when 3 bullet points will do.

There’s a thread here that could be pulled - something about using AI to turn everyone into exactly who you want to communicate with in the way you want.

Probably a sci-fi story about it, if not, it should be written.

And AR glasses to modify appearance of everyone you see, in all sorts of ways. Inevitable nightmare, I expect.

I think people read texts because they want to read them, and when they don't want to read the texts they are also not even interested in reading the summaries.

Why do I think this? ...in the early 2000's my employer had a company wide license for a document summarizer tool that was rather accurate and easy to use, but nobody ever used it.

The obvious use case is “I don’t want to read this but I am required to read this (job)” - the fact that people don’t want to use it even there is telling, imo.

You sometimes need to want to quickly learn what's in an email that was written by someone less helpful.

Eg sometimes the writer is outright antagonistic, because they have some obligation to tell you something, but don't actually want you to know.

Even bending over that far backwards to find a useful example comes up empty.

Those kinds of emails are so uncommon they’re absolutely not worth wasting this level of effort on. And if you’re in a sorry enough situation where that’s not the case, what you really need is the outside context the model doesn’t know. The model doesn’t know your office politics.

I think humans are quite well capable of skimming text and reading multiple lines at once.

And you trust AI to accurately read between the lines?

This is a pretty damning example of backwards product thinking. How often, truly, does this happen?

Never heard of terms of service?

No one cares about the terms of service. And if they actually do, they will need to read every word very carefully to know if they are in legal trouble. A possibly wrong summary of a terms of service document is entirely and completely useless.

Are you regularly getting emails with terms of service? You're, like, doubly proving my point.

Yes, I regularly get emails about terms of service updates.

My theory was that strategically, Google wants to make AVIF ubiquitous to promote adoption of decoders for it in mobile devices; AVIF losing to JXL is a "whatever" on Google's part, but AV1 losing to H265 means another decade of royalties for YouTube.