henrymerrilees

Parent comment shouldn't have a problem with it, but beyond rhetorical purposes (as in the reply) we should! Shifting tax structure from an ongoing basis towards transactions incentivizes people to hang onto houses in circumstances where they otherwise would not. E.g. retirement-age downsizing that would otherwise increase supply of family-sized housing. SDLT in UK has this effect.

Bo you are a legend!!!

A bit of a garden path path sentence... I believe "maps" in "maps to" was being used as a verb.

So "noul"--short for Bernoulli as in the Bernoulli distribution--"maps to if-statements."

konami (enter for start)

Engineered with accountability in the sense that all human decisions are accountable to humans.

A key facet of the suggested risk is that these programs would attempt to mask whatever behavior would bring about the end of the world. A world in which AI doom could be detected before it’s too late and stopped by metaphorically running into rooms full of people telling people to unplug is less extreme than that in which doomers argue we are already living.

Alarm takes severity and scale. Forecasting double-digit odds of near-term human extinction on national television to a lay audience is more extreme than yelling to unplug rogue AI. For what it’s worth, the latter has already occurred numerous times at containable scales in leading labs, mitigated by the physical realities of computation, notwithstanding the competence of involved personnel. People running into rooms yelling is probably not a hypothetical.

Part of our general inability to reason about exponential growth is the inability to recognize that a supposedly exponential growth is actually sigmoid. The horizontal asymptote could just as well be 8b, so it is not a case against doomerism in itself, but as is the case with COVID, to say nothing discounting its horror, that number is far less.

There is no need to count exponentials—it would only be a matter of time. The need to sum multiple factors betrays the finite limits of what is actually sigmoid growth. Reasoning about specific effects is unfortunately subject to counter-evidence and so struggles for traction against abstract handwaving about exponential growth.

There is much uncertainty, certainly not exclusive to AI. The benefit of hyper-vigilance in each case must be weighed against the cost of indulging every similar panic.

Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality.

Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.

The relevant points have already been made: (1) LSP is a JSON-RPC protocol, not a CLI app, and (2) Language Servers that implement LSP often utilize AST manipulation, even the resultant manipulations are exposed to the client via character ranges.

Still, these links may be of interest:

TypeScript’s language-service implementation of the “Move to file” refactor: https://github.com/microsoft/TypeScript/blob/main/src/servic...

Documentation for how `typescript-language-server` exposes that refactor as an opt-in code action: https://github.com/typescript-language-server/typescript-lan...

`ast-grep`, an AST-based search and transformation tool that may be closer in spirit to the cli functionality you describe, albeit more general-purpose: https://github.com/ast-grep/ast-grep

Disclaimer up front: I've only read ~10/23 RVSoC draft chapters that were made available as a part of SP2025 E154, so don't take me as any kind of authority on the remaining 13, which I can't wait to get my hands on!

In the preface on xx-xxi:

```

This book took three years of development and another year of production. There are many more important topics in computer architecture and SoC design that were omitted from this edition for schedule reasons; we hope to address them in a future volume:

* Multicore

  * Multilevel cache coherency
  * Synchronization
  * Interprocessor communication

* Microarchitecture

  * Superscalar
  * Out-of-order
  * Deeper pipelines

* RISC-V Extensions

  * Vector
  * Hypervisor
  * Debug
  * Trace

* Verification

  * Functional coverage metrics
  * Hardware emulation

* SoC Design

  * Intellectual property block design and integration
  * AXI interfaces
  * Accelerators
  * Memory controllers
  * Network-on-chip

* SoC Implementation

  * Timing and power optimization
  * Clock gating
  * Clock domain crossings
  * External interfaces

```

It's definitely processor-centric but I wouldn't say "about RISC-V microprocessors" catches it either. The book is certainly structured around the core, but arguably so too is SoC design, at least at an introductory level. RVSoC uses a real SoC design (CORE-V Wally), and each aspect is covered at a length more or less proportionate to the complexity of its implementation in Wally. Admittedly, Wally's peripherals are fewer and simpler than you might find out in the wild. Wally itself is 80-90% core by lines of RTL (horrible complexity metric I know, sorry).

Another way to look at the book is that it picks up where Digital Design and Computer Architecture (by the same Harris and Harris) leaves off. DDCA is used to teach the E85 course at Harvey Mudd; RVSoC is used to teach E154 (SoC design). DDCA builds up to a simplified RV32I-subset pipelined core. If RVSoC started with peripherals without fully elaborating the core, it would leave both readers of both books and students of both courses with a gap in coverage on core design compared to the depth of the remainder of both books.

Both are very detailed. With RVSoC at 859 pages in print and 1135 after the digital supplement, the core-related chapters are not by any means stealing airtime from the other components of the SoC, you could strip out every core-related page and still have a modestly-sized textbook. While not by any means an encyclopedic reference for SoC design, I found it to be a wonderful bridge from more elaborated microarchitecture into SoC.

I hope they are able to get that future volume out!

(edit: quote formatting)

Why even post this?