vdupras

What I mean by a penalty of threaded code isn't related to whether words are implemented in native code or not. For example:

: square dup * ;

is going to generate a square word that does 2 calls, regardless of whether "dup" and "*" are native words or not.

The equivalent in C:

int square(int x) { return x*x; }

will generate code that contains no call, even if your C compiler is not a very optimized one.

With STC, it becomes possible for an elaborate Forth to inline "dup" and "*", but STC is less popular on the 8-bit architectures you mentioned because it's much less compact.

It's in that context that I mention that threaded code entails a speed tax. It's those 2 calls.

Of course, in your Forth system, you could rewrite "square" in native code to get rid of the penalty, but then it's not threaded code anymore, it's native code.

There is no middle ground. Mentioning "Greater China" isn't neutral. It's precisely the idea of considering "Greater China" as neutral that is de facto siding with the PRC.

No, this is Apple being confident that the USA will drop Taiwan and that this and that siding with China is the "responsible" thing to do.

There are options, yes, but the path to options that could be said to compete with, let's say, C, is narrow.

If you use Indirect or Direct (ITC, DTC) threaded code, there's no way out: you're going to call every word. You can use Subroutine Threaded Code and inline some code (that's what I do in Dusk OS), but you still have to choose the words you're going to inline. Typically, you're going to end up with words that "calls" more than your typical C code.

And then, you might very well realize that being fast as C everywhere isn't all that important and that all the inlining you've been placing everywhere isn't worth the tradeoff, so you'll scale back on it and keep speed optimizations for bottlenecks.

So, again, yes it's possible, but the path to it is narrow. I don't know of a Forth that can say that it compiles code expressed as Forth (as in ": foo bar baz ;") that compiles native code that can compete with C, speed wise. Do you?

american: you're the historical quirk!

canadian: no, you're the historical quirk!

native american: you're both historical twerps.

I've never written Forth as part of a team. I suppose it's difficult with an average team. But then I try to imagine what a small team of good Forth programmers could do and I'm thinking it would be a quite powerful team.

If I piqued your interest, might I interest you in the introductory series I wrote: https://tumbleforth.hardcoded.net/

This challenge comes with rewards. Forth has superpowers that can't be found elsewhere.

But its definitely not for everyone. I'd say that the status quo of Forth being an obscur niche is fine, just fine. If you need convincing, if you aren't spontaneously curious about Forth, then it's likely not for you.

That's what I would call the "Forth challenge", that is to grow out of stack juggling.

When you look at the Forth code of a beginner, yes it's full of stack juggling, of "@" and of "!". When you look at code from more experienced Forth programmers, there's much less of it.

The challenge is to build your way out. There's no fixed way to do this, because the best path to do so is generally dependent on the task at hand.

Needless to say, most programmers fail this challenge.

Calling it "the best" is assuredly shortsighted. One only has to go back a little while in history to find very effective ways to tax the ultra rich. The one big caveat is that choosing one of these ways require a bit of historical perspective, which we assuredly lack.

Oh, that's what you get by being unaware of the cellphone brands. I was all excited thinking "hey, they found a way to hack phones through, I guess, screen firmware by setting a special sequence of pixels? How frakking cool!". How disappointed I was...

It's kind of like antisemitism. It used to be about Jews, now it's about Israel.

So, is it time to wish for TACO?

I think the broad idea isn't to directly, for example, program a floppy disk drive (to boot a PC from BIOS) driver from such a front panel (a gargantuan task), but to gradually bootstrap your way up there.

For example, you could build yourself a makeshift hex keyboard and load a driver for that keyboard onto an ATmega. Good! from that point on, you can enter bytes faster.

Then, you hook a few seg7 together to have some kind of display. Even better!

... and so on, until you can drive that FDD.

It's not a crime if the state allows it, right?

Fortunately, they're copycats, plural, so it won't be a hegemonic force.

America is in terrible shape. The world without it as the World Police/Bully is not necessarily worse.

I'm not arguing that humans are not adaptable, I'm just pointing out a fallacy in your original argument. Whether humans are adaptable or not is another matter.

You wrote "humans are good at adaptation, case in point, mass extinction survival". I reply "they weren't human then". The relevance is direct.

Drew's moral grandstanding is at odds with HN culture, so of course it's never going to be well received here. And to a point, HN is right to reject it because it's pointless: fascism is obviously coming and nothing can stop it.

Nothing can stop it, not because those evil men are too powerful, they're clowns. Nothing can stop it because, as Orwell says, modern man is inadequate for modern times.

> Modern man is rather like a bisected wasp which goes on sucking jam and pretends that the loss of its abdomen does not matter

Yes, obviously, but our ancestors weren't human then.

Yeah, I wouldn't have phrased it like in the article either. What I'd say is that Forth is more about naming processes than variables.

No, I'm arguing that having more "blocking" time is not a function of time (early days of programming), but a self-inflicted choice. Yes, choosing C in the 80s meant self-inflicting yourself with "blocking" time, but there was the choice of Turbo Pascal, or Forth or whatever. Plenty of great choices that ran really fast on those old machines.

Do I mean that one should choose Pascal today? No, compiling C code today is really fast and has practically no "blocking" time. But you can still inflict yourself "blocking" time if you want, with languages like Rust.

Are things clearer now?

Certainly, but that depended on your own choices in technologies. This condition is not time-dependent. You can inflict yourself the exact same condition by choosing Rust.

That is both a sweeping generalization and plainly wrong. The "much earlier" days of programming had blazing fast compilers, like Turbo Pascal. The "earlier" days had C compiler that were plenty fast. Only languages like C++ had this kind of problem.

Worst offenders like Rust are "today", not "earlier".

Is 2C by 2050 twice as bad as 2C by 2100, or is it worse? How "off the chart" are we w.r.t the worst of the worst predictions made by IPCC in their latest reports?

It seems to me that nowhere in any prediction did anyone say that we would get as bad an outcome as soon as this.

Absence of necessary urgent change tend to inspire doomerism.

I might be going further than most, but my personal take is that it happened when Woz stopped being involved: https://lists.sr.ht/~vdupras/duskos-discuss/%3CZ4p_GHsw5arWG...

The rest is just a downhill trend.

I'm sure there was such experts weighting on the future of Soviet Russia in 1989.

50 years. How myopic do you have to be to even try to answer that question, especially framed thus? Six years ago, someone trying to predict how the world is today would have been deemed completely crazy.

Our collective future has "mediocrity" written all over it.

And when you think about it, LLMs are pretty much, by design, machines that look for truth in mediocrity in its etymological sense.

What is unusual is for gold to perform better than stock indexes, which it has been doing by a significant margin in the past year.

It's 20% of the execution time. All these instructions use the same number of cycles.