Day the second. Where does the time go.

Today I most materially followed some of jlamothe's helpful moomails.

In particular, I seem to have managed to break jlamothe's
room-connector at a crossroads (#66139), which is their intended room
connexion spot.

I had to rejig my exits for suitability.

An exit not having a look_msg property can be given a new one like
this:

@property #51781.look_msg "There is a puddle of darkness here. It
looks swimmable."

This can then be verified

>@props #51781 => {"look_msg"}

and read.

>;#51781.look_msg
"There is a puddle of darkness here. It looks swimmable."

However, for whatever reason this doesn't seem to have worked for me,
since

>look #51781
This puddle seems more dark than wet. Demons couldwrite
 letters with this stuff.

which was my original message (but doesn't imply exit names very
clearly).

Normally look gets set

>@describe #51781 as There is a puddle of darkness here. It looks
 swimmable.

which I've just done. Thing is this seems independent of .look_msg to
me.

I guess time will tell.

Also key was

>@rename #51781 to puddle of darkness,puddle,darkness,swim

which makes #51781's name be "puddle of darkness" with the aliases
puddle, darkness and swim.

On the mastodon, I was talking to @iacore@mastodon.de, whom has been a
friend of mine for a while. We talk about machine learning. Today
iacore was asking about the #lispyGopher #climate (Wednesdays, 000UTC
on https://anonradio.net:8443/anonradio .

We talked about how to search for episode descriptions, which is to
look up the tag #lispyGopher (new episodes) or #lispyGopherShow (old
episodes).

This led to us talking about Erik Sandewall, obviously. Iacore thinks
that programs transcend individuality, since any version of the
program, given the same state will be the same (or something), so they
can all work together.

On the other hand, erisa thinks in order to learn and grow, programs
need to understand they are a unique individual and separate from
other instances of the software they may have been cloned from.

My rationale is that it's more human to say:

In the past, I have tried to solve this problem and these are the ways
that I have found to work, I believe subject to these preconditions.

Rather than attempting to make true statements that would be universal
truths about the code of programs.

Back to the other topic, the LispyGopher Climate topic I decided on is
Living and growing programs.

My byte about this is that this approach is suitable when either we
have low confidence about what the final goal is, or we have low
confidence in our ability to plan our way to the final goal.

Maybe some mixture of both. This is compatible with what Kent says,
that lisp is like the joke- at Harlequin we make the hard stuff easy
and the easy stuff hard.

In particular, to synthesise my reading of Interactive Programming
Environments and personal experience, lisp takes a multi-pronged stab
at increasing the coarseness of program granularity, and hence if a
program is like a big pile of rocks, a pile with the same number of
rocks gets you higher if the rocks were bigger, all else being
equal. I think this is why Kent is resistant to people using low level
facilities when higher ones are obviously available.

Sandewall has an article somewhere, "Lisp as an extremely high level
language".

In contrast, I guess Kent is clearly right that MOO is a low level
language, more of a protocol.

However it has the attractive form:

On one hand we @create objects, and on the other hand we @edit
<object>:<verb>; s into existence, verbs by definition getting called
like this:

>take cucumber roll from stream

Direct object: cucumber roll Preposition: from Indirect object: Stream

which is the command to take some sushi out of jlamothe's sushi stream
at sushi paradise.

Verbs are made out of just sequentially calling other verbs, more or
less. It's a command language, like a shell script.


Alright I feel I've gone on and on. I wanted to write at least
something for day 2.