Search Ideas

Make Hiccdown reactive, like Reagent: a proc as the first element marks a component, as in [->(product) { [:li, product.name] }, @product].

The server keeps track of which components each page rendered, with which records, and gives each component's element the id dom_id(record), as turbo streams do. When a record changes (after_commit, checking that it actually changed), the server tells the pages showing it, over Action Cable. Each page then requests just that component, which renders in the viewer's own request, with their user, session, locale, time zone and CSRF token, and swaps it in with a turbo stream.

Rendering the component in the request that changed the record would save that round trip, but that request has none of the viewers' context: it would render for the wrong user, or have to rebuild each viewer's context and render once per viewer.

A first pass can skip checking whether a change affects what a component shows, as when a product's name changes on a page that only shows its price.

Done as of 3a304be, to be released in version 1.6.0, as described here. The id and classes can come in any order after the tag name, and two ids in one tag raise ArgumentError.

Known since #301, and accepted in #333: the alternatives, helper class methods (#1980) and separate display classes (#1982), were worse. Qualifying a helper method's name, like items_page rather than calling index, is the way around it.

They already do: turbo-rails gives frame requests its own minimal layout, and Hiccdown leaves it be. As of c5ce76f, to be released in version 1.6.0, a test checks that frame requests keep Turbo's frame layout even where ApplicationHelper#layout exists, and a system test (e71df95) loads a frame in a browser.

Doesn't reproduce as of e71df95. In the app in test/dummy, a form whose action redirects takes one POST and one GET in a headless browser, which a system test now checks.

Probably, and they're fixed. Hiccdown used to force a layout (layout: true, then layout: !request.format.turbo_stream?), overriding the layout method turbo-rails relies on, and turbo-stream requests failed with "no default layout" (fef00cb). cf92f06, in version 1.5.2, stopped forcing a layout. As of c5ce76f and 4a087e4, to be released in version 1.6.0, tests check that frame requests keep Turbo's frame layout and that turbo streams get none, and the app in test/dummy shows it in a browser.

A helper method that calls another action's helper method by name can get another helper's. Rails mixes every helper into every view, so calling index from ItemsHelper#create runs whichever helper's index Rails included last, such as PagesHelper#index:

1
2
3
4
5
6
7
8
9

module ItemsHelper
  def index
    [:ul, @items.map { |i| [:li, i.name] }]
  end

  def create
    index # PagesHelper#index, not ItemsHelper#index
  end
end

Action names like index, show and edit are in many helpers, and the Readme encourages helper methods calling one another.

Fixed as of 99b6280, to be released in version 1.6.0.

On Rails 8.1, Hiccdown's capture hands keyword arguments to the block as key-value pairs rather than as keywords. capture(text: 'foo') { |text:| text } raises ArgumentError: missing keyword: :text instead of returning 'foo', and a block that takes them as a hash, { |options| … }, gets [:text, 'foo'] instead of {text: 'foo'}.

Earlier versions of Rails pass keywords on to the block as a hash, which Hiccdown leaves alone.

Mostly, intercepting capture already took care of it: helpers of your own that pass a block on to Rails' helpers, or return Hiccdown, worked. Hiccdown given to Rails' helpers as content didn't, as in content_tag(:div, yield), tag.div([:span, 'foo']) or link_to([:span, 'foo'], path). As of 134deb9, to be released in version 1.6.0, it does.

Yes. As of 4fd7a0e, to be released in version 1.6.0, the layout named X lives in XHelper#layout, just as it would in layouts/X.html.erb, so the application layout lives in ApplicationHelper#layout. yield and yield(:title) work as in an ERB layout, and layout files keep working for a gradual migration.

Fixed as of 31cf174, to be released in version 1.6.0.

Fixed as of 9c46c61, to be released in version 1.6.0.

Hiccdown finds an action's helper method through params[:action] rather than the controller's action_name. When a controller runs without the router, as in ProductsController.action(:show).call(env), params[:action] is nil and rendering raises NoMethodError: undefined method 'to_sym' for nil instead of calling ProductsHelper#show.

Calling render with options only, such as render status: :not_found or render layout: 'admin', skips the action's helper method and looks for an ERB template instead. Without one, it raises ActionView::MissingTemplate:

1
2
3
4
5

class ProductsController < ApplicationController
  def show
    render status: :not_found # MissingTemplate, though ProductsHelper#show exists
  end
end

Naming the action works around it: render :show, status: :not_found.

Fixed as of c36fa5c, version 1.5.2.

Fixed as of ed8868b, version 1.3.1.

Understanding in the Age of AI:
https://libertythroughreason.com/understanding-in-the-age-of-ai/

This works if the tests are identical. What happens if idea A passes test 1 but fails test 2, while idea B passes test 2 but fails test 1?

Rational Decision-Making

It’s rational to adopt only those ideas which, as written, don’t have pending criticisms, and to reject ideas that do.

If an idea, as written, has no pending criticisms, it’s rational to adopt it and irrational to reject it. What reason could you have to reject it? If it has no pending criticisms, then either no reasons to reject it (ie, criticisms) have been suggested or all suggested reasons have been addressed already.

If an idea, as written, does have pending criticisms, it’s irrational to adopt it and rational to reject it – by reference to those criticisms. What reason could you have to ignore the pending criticisms and adopt it anyway? After all, the previous paragraph applies to pending criticisms, too.

See also:

• More details and reasoning
• Computational implementation

Rational Decision-Making

It is rational to adopt only those ideas which, as written, don’t have pending criticisms, and to reject ideas that do.

If an idea, as written, has no pending criticisms, it’s rational to adopt it and irrational to reject it. What reason could you have to reject it? If it has no pending criticisms, then either 1) no reasons to reject it (ie, criticisms) have been suggested or 2) all suggested reasons have been addressed already.

If an idea, as written, does have pending criticisms, it’s irrational to adopt it and rational to reject it – by reference to those criticisms. What reason could you have to ignore the pending criticisms and adopt it anyway? After all, the previous paragraph applies to pending criticisms.

See also:

• More details and reasoning
• Computational implementation

The evidential standard seems asymmetric.

You have said that there ultimately cannot be a purely behavioral criterion for consciousness, because what matters is an explanation of the underlying program (#5693). But at the same time, apparently rigid or “blatantly robotic” behavior is allowed to count as evidence against consciousness.

In the other direction, apparently flexible, sophisticated or sentient-like animal behavior does not seem able to count correspondingly in favor of consciousness, because it could always in principle have been produced by a nonconscious program.

If behavior alone cannot establish sentience because we need to understand the underlying processing, I don’t see why apparently robotic behavior should by itself count more readily toward insentience. Unless there is already an independent reason to think phenomenal experience requires universal creativity, the evidential standard seems to favor insentience in advance.

I agree that this is not “learning” in the special Deutschian sense of universal knowledge creation. I was using “learning” in the ordinary biological sense of experience-dependent changes in processing and behavior.

In fact, the passage you link makes that distinction explicitly: Deutsch allows that the robot’s useful change can be called learning, while denying that it constitutes genuine creation of new knowledge.

That distinction is actually part of my point. I’m not claiming continuity in universal creativity between humans and other animals. I’m pointing to continuity in the older, non-universal capacities (such as sensory, nociceptive, affective and ordinary learning processes). Whether those processes can support phenomenal experience is precisely what is under discussion.

I also wonder whether your note here should be a criticism rather than a comment. As I understand Veritula, an outstanding criticism makes the parent idea problematic and therefore not rationally adoptable, whereas comments are neutral.

A suggestion that an idea could be phrased more simply seems like a useful comment, but unless the wording actually makes the content of the claim ambiguous or substantively defective, I don’t see why it should count as a reason to reject the idea itself.

I initially wondered whether you were right that I could simplify this, but I think the distinction is necessary here. Writing “they … feel pain” would already assume part of the conclusion under dispute: that animal nociceptive processing is accompanied by phenomenal pain.

By “sensory, affective, nociceptive and learning mechanisms” I was trying to refer to processes we can identify without assuming that they involve conscious experience. The wording is less simple, but in this case I think the precision actually matters.