Is AI really a Mind?

Just a dab of thinking on Artificial Intelligence & Reality.

If we attempt to decompose the human mind into categories and properties, we get obvious members like language, creativity, understanding, synthesis, reasoning, knowledge, and many more things. However, this is like defining "what is an elephant?" from a high-definition, three-dimensional hologram. We get members like trunk, head, body, legs, and skin, - maybe even respiration, movement, and instinct.

But even if we made the hologram much more detailed, we just can't decompose an elephant exhaustively with only observations. What we miss is what is inside, not just the organs but how hidden systems work on the macro, micro, and even quantum scales, and we miss those enigmatic and inimitable things like consciousness and just "being alive". We might conclude an elephant is alive, but that doesn't properly capture what it means to be alive and what makes it alive. That is to say, there are qualities of an elephant - critical qualities - which we recognize are present, but we cannot measure or properly observe regardless of effort or scientific precision.

What makes this important is that if we reassemble our observations in an attempt to create an elephant, the resulting facsimile will not be an elephant. It would be missing those added things which we cannot measure. However, if we attempt to qualify this new golem using only our meager observations, we could confidently - and wrongly - conclude "this is an elephant". And we would say it while inherently knowing what we were saying is not so.

This is similar to our decomposition of the human mind. We have large (and small), true categories that, like the observations of the elephant, define the mind in a way that is nonrepresentational of the subject. Like making an elephant, if we reassemble our categories of the mind into some new creation, we might say "this is a mind" while knowing our very words fall inanely short of the truth.

But this is what we mistakenly do with AI. We observe the qualities of AI and map those to the categories we have made of the mind. We consequently observe "AI has the qualities of the mind" then leap to the false conclusion that this assembly of categories somehow is: a mind.

The very misstep we make in concluding "this is an elephant" we incautiously repeat with AI. Is it a mind? Is it alive? Is it conscious? Does it think? Or are we too easily ascribing higher-ordered, ethereal, and foundational qualities to a thing that demonstrates only the simpler, perfunctory, and easily measurable attributes of the human mind?

Is any AI a mind? Yes, but only in the same lacking sense that an airplane is a bird, or a car is a horse, or a painting is really a mountain. If it simulates the broad qualities of a mind, we might conclude it is a mind. But is AI a mind - a real, thinking, living, and conscious mind? Yes, but only in the silliest sense.

So, then, I can't help but wonder why we are so willing to make this frequent mischaracterization? Are we just victims of fiction writers or clickbait titles? Or is there something else that makes us want to see more where there is actually less? I don't know.

Waiting for Kestral

Kestrel is the ASP.NET Core web server. You can call its endpoints only after it has started. Using the IHostApplicationLifetime interface, you can register a callback for when the server starts & stops. This prevents workarounds like Wait() or Sleep() or Delay() that, honestly, we have all tried. The callback is nice and clean and is deterministic and reliable. 

Let's look at the IHostApplicationLifetime interface.

Triple Edge Constraints in Graph DBs

What is an Edge? Good question. An Edge defines the relationship between two Nodes. A Node is a thing, noun, or concept – like Store. In my diagram below, the Wants Edge in between the Store and Product Nodes. You would write it as Store–(Wants)->Product and it means to define which Store Wants which Product.

The puzzle here is the Must_Use Edge. In my diagram below, this Edge is between Store and Warehouse and it means to define which Warehouse a Store can use when ordering certain Products. This is special because it references three Nodes: Store, Warehouse and Product. To make this work, the Must_Use Edge must include a field referencing the relevant Product Id.

Adding this value is easy, but it means the Edge rows multiply by the number of Products in the catalog – and with some businesses that can mean hundreds of thousands of products. It also introduces a kind of inferred relationship that doesn’t have a standard representation when drawing a Graph. In the diagram below, I indicate the special relationship in red.

An Introduction to SQL Graph

Sometimes the easiest way to learn a new technology is to compare it to a technology you already know. Such is the case with Graph databases. When you hear about them or watch videos about them elsewhere they talk as if they can cure cancer and give you a foot massage all at the same time.

A list of online tools I use

Every developer has their list of tools. That list of things making me more productive. That list of things helping me remember, too. Today, I went through my list for my team & thought I would share. Who knows what my list will look like in another 3 or 4 years. Maybe no change at all. Who knows.

Utility scripts for SQL tables

The SQL Server sys.tables & sys.schemas tables are exceptionally handy to find & filter tables in the database. Quickly looping through a list of table commands to execute a delete, truncate, drop, update, disable constraint, enable constraint, or require data script is easy – just use a while loop, a cursor, or print the results to use in a larger script you are writing. Truth is, this little snippet helps you query for the tables, their schema and the boilerplate script syntax. I’ve used scripts just like this for years.

Here it is on GitHub: link.

An Assert Schema for SQL Server

In C#, we use Assert to make a claim and to do a few utility operations. For example, we use Assert.Equal(one, two) to claim that one and two have the same values. If this is not true, Assert.Equal() throws an exception that is typically used by Unit Test runners to highlight failing tests.

But in SQL Server, there is no Unit Test framework or runner. That doesn’t mean we can’t have similar behaviors to Assert in TSQL. We just have to write them ourselves. To that end, I have created a starter set of scripts to introduce Assert to SQL Server for database developers.

You can find it here: An Assert Schema for SQL Server (github.com)

A Kickstarter for features: It’s a Better kind of User Voice

For decades, I’ve watched users and developers long for capabilities in Windows and .NET that never happen. Sites like Connect and User Voice collect our ideas and votes yet backlogs rarely react.

I believe product teams often chase the next big feature, forcing themselves to ignore small, love-creating improvements or tweaks that would build tireless loyalty from their user base.

For this reason, I would like to propose a new idea. A way to solicit, not feedback, but ideas from a user or developer community in a way that gets results and creates wonder. 

Developer Evangelism’s Obvious Secret

Hi. So, here’s another entry from my notes as an Evangelist. So many snippets I wrote to myself, translated here to blog articles helping, I hope, anyone finding themselves where I was. This one is the role of empathy. Perhaps it is not as obvious as you assume?
For the sake of argument, and I think that’s a fine reason, let’s consider Developer Evangelist, Technical Evangelist, Developer Advocate, and any other variation of a Developer Relations title to be the same. For the most part, they are. For me, here, I will use Developer Evangelist because that’s the title I employed for just under a decade at Microsoft. And, I like it.

Three Reasons for Developer Evangelists to Engage

I would like to talk about the reasons for a Developer Evangelist to engage an audience. We already understand the three ways we can engage: online, personal and onstage.

As a reminder, online engagement has the greatest reach but the least impact, personal engagement has the greatest impact but the least reach, and onstage engagement is a combination of the two with varying results depending on skill, style, and approach.

But when as you prepare your talk, ask yourself why: why are you engaging in the first place. As you are driving to a conference or meetup ask yourself why: why are you engaging in the first place? I would assert there are three reasons for Developer Evangelism engagement.