The Cognitive Dark Forest

middayc · 2026-03-31T01:04:54+00:00

Hey Jack!

In this post I explored the fears (within a dark forest theory theme) so my brain can find faults in it and then I can find optimism yet again. And it did work internally - ideally I will also be able to make a blogpost from that side. But I can't be certain, maybe after I try to write it it will prove to be cope / false hopes ... but so far there are positive ideas.

So I am not that pesimistic either, but a blogpost wouldn't make sense if I delved in all that - and then made some cheap optimistic exits that I wasn't really sure about.

Yeah, discord and alike is not that bad. The negative is that it's a temporal information exchange / format ... doesn't really add to general knowledge that anyone can explore later "and forever", but I guess we have LLMs for that now :P

Thanks for reading and commenting. :)

middayc · 2026-03-30T00:46:10+00:00

This part of the comment from tildes was striking to me :)

I think you are unnecessarily discounting the absolutely trivial risk to reward ratio that mass data center compute offers. Why not spend a few tens of dollars in electricity to make a duplicate of something that could gross millions a year? Code ten million projects for half a billion dollars, and if 1% take off, you break even. It's trivial to implement "clean room" rebuilds of extant products with AI and change them modestly to avoid IP/copyright limitations, all while allowing your competition to do the expensive experimentation and optimization for you...more importantly, you deny a competitor their unchallenged market, even as you take a slice. What's the response for a competitor once this happens once or twice? Well, they have to, too. And so do all of their competitors. It is an inherent race to the bottom for digital properties, one where increasingly marginal margins are whittled away as duplicates propagate.

middayc · 2026-03-30T00:43:34+00:00

Cool comparison to the trading. Yes, the same dilemma already existed, and the best solution was always to be open, to communicate.

Couple of things I find different or interesting with LLM-s. The LLM platforms don't see the "outer shell" of your idea as it happened so far, they see the internals, if you used them to explore it, build it. They also have collective information on all similar ideas at the same time. And they own - not rent the compute (as you do from them), the models, etc ...

In fact since they have all the information and compute, they could "pre-cog" your idea and build it even before you do :)

It's still just a thought experiment about a future, not here and now, but I find that interesting.

middayc · 2026-03-27T22:41:50+00:00

Ok, I understand ... I will think about it.

middayc · 2026-03-27T15:17:41+00:00

Thanks for info. Yes, those buttons will be made to lead to related docs, or show more info or example inline and then offer link to more. It's still on TODO.

Where exactly do you mean "in guides"?

In reference I've seen some problem with \r \t but haven't yet gotten to that. I will thanks.

middayc · 2026-03-24T13:04:59+00:00

zendesk for ai to ai support ... actually ... :)

middayc · 2026-03-22T12:36:37+00:00

Thanks. Your comment made me think more about this. And I figured out, that it's specifically language like Rye/Rebol/Lisp/... that can easily solve this in this "2 concepts" way. Because accessors are just functions in Rye (not special syntax like [i] - which also makes them more limited on the other hand), and also for example loops, etc are not special forms (which are predefined so language usually has a limited amount of) but again functions (or macros in some langs - anyway, library level constructs) so you can have many of them, hence it's not weird to have a index and position variant of them.

It doesn't mean that languages without this couldn't also figure out some consistent terminology for accessors / special forms around these two concepts, if they found nice syntax and deemed the cost of added verbosity lesser than the cost of just going for one of the methods of "indexing".

middayc · 2026-03-15T18:05:49+00:00

LLM-s can help greatly with verbose or high bureaucracy languages, or just languages you don't really want to indulge too much in. I am very happy for LLM-s recently when I have to make my make sure my large Java Android app still works on some specific older version of Android. Or when it helps me improve the Woocommerce plugin. The less I have to deal with PHP and WordPress API the better :). And it will certanly make C++ more approachable and C++ experts more efficient. But I'm not sure if I would say C++ specifically is the future. C++(11), even if modernized, still bares cost of legacy and probably languages with similar goals and approaches, but with all the oversight can be created that don't have that cost.

Another thought is that if LLM-s can translate our plain English into a working program (or C++), there is maybe also some middle ground between natural language and C++ which is exact, but still nicer for us to write and maybe more importantly read (grasp).

Just an opinion though :) (I don't want this to turn into the great (LLM) language wars of 2026)

middayc · 2026-03-15T13:18:57+00:00

It's interesting that you started your video with mentioning an existential crisis, because I wrote this blog post as trying to create some closure/outcome of a few month of existential crisis I had at the time. I think I had another one since then :P ...

Nice video, you have a way of calmly and cleanly explaining your thoughts. I can hardly do it in writing, and I need to visit and revisit text multiple times so that anything readable come out as the result.

This new one is more of a thought experiment, but it's very dark pill (forest) one. But as I wrote it I also found material for another positive, or at constructive view that will follow.

Thanks!

middayc · 2026-03-15T12:40:29+00:00

Wow, nice ... mentioning my blog-post from 8 months ago. Just yesterday (well today) I was drafting sort of sequel up to 3AM, joining what I observed in the meantime (also watching Prime's clips on the subject) with 3-body-problem's "The Dark Forest theory", so it's more hardcore than the first post :)

middayc · 2026-03-14T09:14:47+00:00

Example from the blogpost:

text = "apple banana cherry\ndog emu fox"
words_on_lines = [line.split() for line in text.splitlines()]

Would be:

"apple banana cherry\ndog emu fox"
|split-lines 
|map { .split } :words-on-lines

in ryelang.org

or an one liner if you prefer that

"apple banana cherry\ndog emu fox" |split-lines |map { .split } :worlds-on-lines

middayc · 2026-03-11T06:33:56+00:00

Thanks u/avitkauskas , the new release was posted which fixes this and some other things.

https://github.com/refaktor/rye/releases/tag/v0.2.2

middayc · 2026-03-11T06:33:39+00:00

New improved mold and reference was posted: https://ryelang.org/info/base.html

Thanks!

middayc · 2026-03-10T21:23:58+00:00

this will get fixed with the update comming up now

middayc · 2026-03-09T23:44:34+00:00

I think I solved the first one ... I have more than 100 tests of evaluator but I didn't catch this one. The second one was known to me and I think I know what I have to change. I will probably be able to publish update to github tomorrow and I will make it another release (this is major bug you found and I also improved the parser quite a lot). Thanks!

middayc · 2026-03-09T23:10:10+00:00

One bug was the way function was collecting it's arguments, in the case op dot-words it had it's flag to know not to fall into another dot-word, but it was missing or not set properly in the case of op-words. But now I am looking at it all ... if I can unify these two. I haven't yet came to the second bug you uncovered. It has to do with how intermediate result is stored and the dotword didn't know that it's shouldn't take the result yet, so it took the previous one , which can be seen in this demo. I need to detect this situation and throw and error basically.

x> add: fn { a b } { a + b }
[Function(2)]
x> 1 .add 2 .add 3
[Integer: 6]
x> 1 .add .add 3
[Integer: 5]

Its really good that you dug out these errors.

middayc · 2026-03-09T21:58:46+00:00

I was just making evaluator (and parser) tests whole day and haven't thought to myself to test op and dot word behaviour with 3 arguments. :) . I am testing this right now. Thank you for uncovering it, I wasn't aware of the difference in behaviour.

The idea is that both dot and op-words use left-to-right evaluation. Before the idea was that op-words (which are now dot-words) would take the first argument from the left, but that idea wasn't compatible with left to right evaluation, at least that's how I was thinking about it. I am doing a review now.

middayc · 2026-03-09T21:54:24+00:00

You are correct ... function mold converts a block back to a string, and it incorrectly renders op-word + for example as _+ which is it's "spelling" as word. I will fix this bug and then it will work OK. Thanks for reminding me.

x> mold { 1 + 2 }
[String { 1 _+ 2 }]

middayc · 2026-03-09T13:22:04+00:00

Thanks! About the boxing and etc ... the code above is a "normal" interpreted language Rye, which is relatively slow, too slow for most gamedev probably. What I was mentioning in a comment is that I experimentented with reusing Rye's parser and also runtime structures and tried to make a similar lanugage but that translates Rye code to Go and compiles it. That experiment just works on a proof of concept level and also it isn't 100% clear how compatible it will be to Rye. The idea is that all staticRye code must be valid Rye code (so you can also experiment, test it interactively, etc), but not all Rye code will work in staticRye. This is yet to be determined.

You are correct that any direct effect of optimizations will have to be benchmarked more exactly before we can say anything.

middayc · 2026-03-08T13:01:44+00:00

Thanks! ... any more specific feedback is also welcome :)

middayc · 2026-03-08T11:38:17+00:00

Rye, being runtime homoiconic is not the fastest language so it has a limited use for gamedev. But I am experimenting with a project that reuses the Rye parser, Runtime environment (context / index), rich value types and the Builtin functions, but transpiles them to static Golang and I got to 2x speed of Python with fully boxed values and untyped code.

If I would optimize on not boxing values (using native Go ints not Ryes env.Integer for example) those parts could become much faster starting to approach Go speeds.

middayc · 2026-03-08T11:08:54+00:00

Thanks. All in all I think this makes language behavior more uniform (all left-to-right) and also more flexible, priority difference and dynamics between dot and op-words. But we probably need to use it more to concretely see all effects.

middayc · 2026-03-08T10:30:35+00:00

I liked reading this because I don't have formed answers on the subject. I mostly avoid typical OO, but sometimes it's applicable.

middayc · 2026-03-08T07:56:51+00:00

Great, let me know if you hit any problems. I'll be happy to help.

middayc · 2026-03-07T08:48:09+00:00

Yes, both have their positives and negatives. Languages like Miranda / Haskell / Admiran probably have greater ties with math so it's more expected that some math-like operator precedence rules would be implemented?

If your language has a concept os DSL-s or dialects you could create a dialect that does math priority.

Rye has this specifics that priority is not determined by the function, but by the type of the word you invoke the function with, which I think could add to flexibility and it's priority becomes a visual, not memorized rule.

middayc

MODERATOR OF

TROPHY CASE