The Argument For Machine Consciousness

The modern argument for machine consciousness can be paraphrased as follows:

  1. We know lots about how electro-mechanical systems work.

Therefore:

  1. Let us believe that consciousness is also an electro-mechanical system (because if it is, then we will be able to understand it).

Therefore:

  1. Machines can be conscious

One can sympathise with giving belief (2) a research budget. But to confidently assert that conceivable consequences of (2) – such as (3) – are facts about the world, is bluster. Writing bluster into our legal and moral thinking would be a mistake.

I suppose the motivation for (2) is, we always want to believe we can understand things. And, impatiently, we also want to believe things can be understood well enough just with the current state of our knowledge, insights and tools.

But gung-ho optimism based on unevidenced confidence does not have a good record and can do more harm than good.

At the current time, the negative I hope we can avoid is:

Large corporations will use stories about machine consciousness and machine legal status to transfer legal risk away from themselves, making it easier for them to prioritise profitable machinery over human lives.

A example will be when a corporation denies legal liability for a robot or self-driving car which injures a passer-by, by saying it was the robot's fault, not theirs.

A better, more logical, move in the early 21st century would be to first acknowledge that

  1. The current state of our knowledge, tools and insights does not suffice to understand what consciousness is or how it works.

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. Non-circular answers to “which design is architectural?” are less common. Here's one:

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.