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.