The Argument For Machine Consciousness

Modern arguments for machines having consciousness can, I suggest, be paraphrased as follows:

  1. (Suppressed premiss) We do not know what consciousness is or how it works
  2. We have, on the other hand, lots of ideas about how electro-mechanical systems work

Therefore:

  1. Let us believe that consciousness is an electro-mechanical system, because if it were we would be able to understand it.

But incidentally, (3) also happens to imply

  1. Machines can be conscious.

I have no disagree with the observations 1 & 2, but 3 has nothing to motivate it other than the firm conviction that, whatever our current state of knowledge happens to be, it must be good enough to understand anything we really want to understand.

A better move than step 3 would be simply to repeat observation 1 and say we don't know what it is or how it works. This rather undercuts step 4; perhaps step 4 is best left behind in the science fiction stories it came from.

There is nothing that it is like to be a computation

Whatever it is like to be a bat, there is nothing that it is like to be a computation.

A computation is the abstract form. Whether embodied in pencil on paper, or in neurons in an organism, the computation is the abstract — disembodied — structure, not the embodiment.

Software: Which Design is Architectural?

“Not all design is architectural” is widely repeated, but non-circular answers to “which design is architectural?” are less common.

A design or decision is architectural if it impacts the system as a Whole, not merely in part.

(from @visarch 2004, http://www.bredemeyer.com/pdf_files/WhitePapers/ArchitectureAsBusinessCompetency.PDF )

C# nullable refs and virtual vs abstract properties

Consider:

public class InitialStep2Sqlite : ScriptMigration
{
    protected override string UpPath => "Sqlite2.Up.sql";
    protected override string DownPath => "Sqlite2.Down.sql";
}

public abstract class ScriptMigration : Migration
{
  protected virtual string UpPath {get;}
  protected virtual string DownPath {get;}

  protected override void Up(MigrationBuilder mb) 
    => mb.RunSqlFile(UpPath);
  protected override void Down(MigrationBuilder mb) 
    => mb.RunSqlFile(DownPath);
}

which, compiled under nullable enable, says “[CS8618] Non-nullable property 'UpPath' must contain a non-null value when exiting constructor. Consider declaring the property as nullable.”

Changing the property's virtual to abstact removes the warning.

The lesson: If your non-null proof of a property depends crucially on the subclass making it non-null, then making the parent property abstract not virtual is the correct statement of intent.

Generally, if a parent Member depends on the subclass for correctness – if the parent can't provide a correct implementation itself – then, logically, its correctness requires it to be abstract not virtual.