owlstuffing

The Roman Empire lasted about two to three centuries in its unified form before it began to seriously fragment.

Indeed, high trust requires more than homogeneity.

Because history treats them as a package deal. Tokugawa Japan saw foreign faces as existential threats. The Ottomans built trust only within ethnic/religious silos (millets). Rome demanded a trinity of assimilation: Latin language, Roman customs, and worship of state gods (later emperor cults).

Today's civic nationalism experiment rejects this link, yet no society has sustained high-trust diversity without such enforced unity. Rome threw everything at assimilation: shared language, values, identity above tribe, and state religion. It still fragmented.

So Western nations face an unprecedented gamble: Can they maintain cohesion without these historical levers? History offers no successful precedents, only warnings.

True, but there’s a key difference -- those earlier waves, despite being seen as "outsiders" at the time, still came from the same civilizational foundation. Europeans, whether Irish, Italains, Germans, or Poles, shared a common history shaped by Christianity, Greco-Roman influence, and broadly similar cultural norms. The friction was real, but over time, assimilation worked because there was enough cultural overlap to make it possible.

The post-1965 immigration wave brought in people from entirely different civilizations -- with no shared history, values, or worldview. That isn’t just "non-homogeneity," it’s civilizational fragmentation. And unlike the 19th and early 20th century European immigration, there’s no historical precedent where that level of deep cultural divergence integrates at scale -- not in Rome, not in Byzantium, not anywhere.

Societal trust levels tend to correlate with cultural and racial homogeneity. The erosion of trust within Western civilization reflects this trend, particularly in the United States following the Immigration and Nationality Act of 1965 (Hart-Celler Act).

But this is hardly unique to the modern era. Consider ancient Rome: as the Empire expanded, it absorbed vast, culturally diverse populations. Over time, this growing diversity--combined with weak integration mechanisms--gradually strained social cohesion and undermined trust in institutions.

It’s a recurring pattern throughout human history.

Reminds me of a book, Mailing May[1], I read to my daughter and now my granddaughter. A true story of a family on a budget who sent their daughter to see grandma as mail cargo on a train. Cute story.

https://www.amazon.com/Mailing-May-Michael-Tunnell/dp/006443...

But in this case the passes are manual!

I didn't say there aren't acceptable reasons to reach for the print statement, there are. But for the vast majority of codebases out there, if good debugger tooling is available, it's a crime not to use it as a primary diagnostics tool. Claiming otherwise is indeed ignorant if not irresponsible.

Their comment conflates debugging with logging.

Professional debuggers such as the one in IntelliJ IDEA are invaluable regardless of one's familiarity with a given codebase, to say otherwise is utter ignorance. Outside of logging, unless attaching a debugger is impractical, using print statements is at best wasting time.

While this modification may contribute to layoffs, the general declining economy is the real culprit — the layoffs started long before the tax code change.

Well… React apps are a category of huge blobs of who-knows-what-but-it-works code.

In fact, I would be surprised if AI were to generate code as rube-goldbergery as React would have you write. Shrug.

Or, if you are an AI:

“I prefer the em dash — it’s my calling card.”

Nice!

I’m currently using manifold-sql with duckdb for this.

Languages should strive to type safely inline SQL and other structured data.

With Java the manifold project achieves this via compiler plugin. The manifold-sql[1] module provides inline, type safe, native SQL.

1.https://github.com/manifold-systems/manifold/blob/master/man...

If this interests you, I highly recommend Luca Boasso’s oberonc project for the JVM[1].

1. https://github.com/lboasso/oberonc

Right. Oracle should reconsider the naming here: stable -> lazy

Downhill fast since JB hastily exited its offices in St. Petersburg and Novosibirsk. It’s no coincidence.

Cool tool, even cooler when paired with the manifold project for SQL[1], which has fantastic support for type-safe, native DuckDB syntax.

1. https://github.com/manifold-systems/manifold/blob/master/man...

Agree 1000%

There’s a Java compiler plugin[1] that muscles in operator overloading pretty comprehensively, and works with all LTS JDKs.

1. https://github.com/manifold-systems/manifold/tree/master/man...

I suppose so, since your use of “we” includes both America and China et al.

> We never stopped manufacturing, we just stopped employing people.

That’s a misleading oversimplification. While it’s true we haven’t stopped manufacturing, we did offshore a massive portion of it--especially after the Open Door Policy with China and subsequent free trade agreements. That shift didn’t just change where things are made; it fundamentally altered corporate incentives. Once production moved overseas, the need to invest in domestic labor--training, benefits, long-term employment--shrank accordingly.

Outside of government, this shift also coincides with the decline of pensions and the rise of the 401k.

Career growth has always been a shared responsibility between employees and employers. In white-collar fields--especially medicine and engineering--education has long been frontloaded, with formal schooling as the main on-ramp.

Blue-collar jobs, by contrast, have relied more on trade schools, mentorship, and hands-on training. These pathways have steadily eroded since the 1980s.

Much of this traces back to the Open Door Policy with China and the broader Free Trade Agreements that followed. These moved massive segments of industry offshore--along with the structures that once incentivized long-term employee development through education and skill-building.

Revitalizing domestic industry could reintroduce competition among employers, which in turn could restore the pre-1990s incentives for long-term investment in the workforce.

Skimmed, nice writing style, on reading list. Finishing Ch. 22 before I put this down.

> No types barking

No thanks

And. . . Java does not have conditional compilation.

Well, if your language gains traction that plan may not succeed. For your sake, I hope that's the case :)

You do, that's the point here. You need ifdefs in this example to selectively compile the same code with different compilers, or different language levels with the same compiler. In either case C3 will fail while parsing a newer feature with an older compiler or lang level.

Imagine v2.0 introduces a new feature that requires a parser change—one that v1.0 wouldn't be able to parse.

  $if $defined(C3_V2_PLUS):  
      // new feature
      fn f = \ -> foo(); // this won't parse in v1.0
  $else
      Callback f = ...;
  $endif

This is also an issue if a future version of C3 introduces language level support, allowing newer compilers to compile code as if it were written for an earlier version. While this approach works well when teams standardize on a specific version’s feature set, they may still want to take advantage of performance improvements in the latest compiler.

That said, this is a niche case and not something I’d consider a dealbreaker.

That strategy will backfire when the grammar changes in a later release. A pre-parse step is necessary for code that targets different compiler releases.

Ah. The top-level lang description claims “No preprocessor”, but my definition of that word doesn’t appear to be the same as yours :/