TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Negative definitions can be useful

Some things are hard, perhaps "impossible", to define, and some properties are hard to demonstrate. The one I was thinking of just now was "consciousness". If someone tells you, "demonstrate to me that you are conscious", what can you do? We don't even fully know what conscious means, how can we demonstrate it?

We can work at it instead with progressive narrowing, either in the positive or negative case. We can all agree some random rock is not conscious, that excludes a lot of the possibility space. Are trees? No? That excludes even more and prevents an easy "has DNA" filter. I do have an easy filter though: I would tentatively accept a simple statement of "I am conscious" as strong demonstration of consciousness, and failure to do so a strong indicator of lacking consciousness. This rules out most animals, which, fine, and also rules out brain damaged humans who don't seem to comprehend speech let alone produce it, again, fine.

There's the interesting edge case of when a computer program says the same, is it conscious? No in general, I argue, because for most programs a programmer could go in and easily have it say whatever the programmer wants. Ok, it's a more sophisticated program like GPT3, and suppose it said that? GPT3 is rather complex, you can't easily go in and edit its output to be whatever for an input. So is it conscious? No again, but admittedly this can be considered breaking my filter and so I'd have to use a different criteria to rule it out. (The related negative "Thinking is what computers can't do yet" works well and it narrows year by year.) Still, it's a useful filter in most cases! Besides, I don't want to rule out consciousness from silicon anyway since even if somehow AIs can never have it, human ems surely would. At that far point, the filter can still be useful, for instance it would accept the character Data as conscious simply because he declared himself to be so and there's no easy way to make him as-a-program declare otherwise.

See Full Post and Comments

Recent Site Downtime

Sorry for the recent downtime. Did a big system update of my server, then left it overnight and didn't check it until recently. Apache crashed because it was trying to load multiple PHP versions at the same time, and the new update to PHP 8 broke a few things. (__autoload is no more, and using curly braces for string indexing is no more. And my config now lives in /etc/php/apache2-php8.0 instead of 7.4, so I had to port over my settings for sendmail_path, upload_max_filesize, and error_log.) Everything should be fixed now, at least here.

One more point in favor of rewriting away from PHP...

See Full Post and Comments

Why ASDF is confusing

At some point on everyone's Common Lisp journey, they're going to reach a point where they want to create a program composed of more than one file. They might even want to create a library! Unfortunately this can quickly become a head-banging exercise in frustration and confusion.

At the root of any confusion I think is a lack of familiarity with the way Lisp gets code into memory for executing -- and for good reason, because hardly anything else does things similarly, at least at the level of exposure that Lisp requires. If I'm right then working through the details and comparing with other languages should help with making ASDF (or the choice of not using it) less confusing. I'm even repeating some very basic things that are probably understood by any potential readers already.

The key difference is LOAD. I don't want to get into the subtleties of loading a source file vs. compiled file and the behavior of eval-when, though those are important for further understanding/avoiding other headaches, here I'm just bringing it up because LOAD is essentially the only way to bring in new code. From the description, it "sequentially executes each form it encounters". Intuitively you can picture this as sequentially EVAL'ing each form, so EVAL under the hood is doing the work, but LOAD is your user interface. Every sort of "package management" or "library management" or "code module management" system is just built on managing LOADs.

See Full Post and Comments