samuell

> it's not like there's a lack of groups out there trying.

Indeed. And those who knows how to implement this, might also be the ones with capabilities to deploy it on a large scale (via bot nets or whatever).

What about state actors, suddenly getting a possibility to plant backdoors in millions of websites, etc.

You don't have to be too imaginative to see the "economics" of this.

I switched to ProcessWire [1] a couple of years ago, and haven't been happier.

It succeeded to do what Drupal tried but never managed to do:

It is both extremely stable and extremely flexible at the same time.

By having an extremely generic and small core, combined with an extremely powerful programmatic API (basically jquery for data from the CMS, but better), you don't need fiftyeleven modules to achieve some basic tasks.

[1] https://processwire.com (don't get put off by the .com. It is open source).

The Objective-Smalltalk paper looks super interesting also, from my brief skim in Zotero! Will have to dig into it more properly next week.

Yea, I think I kind of know this in theory, but tend to mix them up sometimes as a non-native English speaker. Good to try to iron out those common mistakes though for sure.

Interesting advice, gotta look into that, thank you!

Nailed it

I think you are right, and I should have done a search on that before. Found now that FBP inventor cites someone Weinberg from 1975 about them (though FBP is supposed to be from around 69-70, so might be a somewhat parallel discovery):

> Now what are "IN" and "OUT" that our pseudocode receives IPs from and sends them to? They are not the names of connections, as this would tie a component's code to one place in the network, but are things called "ports". "Portae" means "gates" in Latin, and ports (like seaports) can be thought of as specific places in a wall or boundary where things or people go in or out. Weinberg (1975) describes a port as

"... a special place on the boundary through which input and output flow... Only within the location of the port can the dangerous processes of input and output take place, and by so localizing these processes, special mechanisms may be brought to bear on the special problems of input and output."

https://www.jpaulmorrison.com/fbp/concepts_book.shtml

Still, I'm amazed at how it took so long before they became mainstream in data flow oriented libraries and DSLs.

And it seems J.P. Morrison was also highlighting Named ports as particularly useful, which is also perhaps what I should have highlighted in my initial comment above.

It's gotten better lately it seems, but a lot of tools skipped that part, which now requires tons of specialized syntax just for routing of multiple parallel streams.

---

Thank you for kind words!

Thanks for sharing! I would love for some go to source for this type of insider info from the people who actually have tried. (The best I've found so far are some guys on Twitter/X like Alex Fateev (https://x.com/superalesha) and AJ (https://x.com/ItsmeAjayKV))

I'm personally sitting on an extremely limited Geforce GTX 1660 6GB, and would like to see how far one could go even with such a crappy card.

At least it was quite amazing to see the difference between CPU-based and even this crappy GPU-based inference when trying out some tiny models in jan.ai. It's still like orders of magnitude faster at least.

I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:

    player2.reveal -> player1.observe
    player1.reveal -> player2.observe

That is, enabling data flow connections between individual inputs/outputs, and not just between components, which otherwise is too limiting, and typically causes a lot of extra syntax to handle that routing otherwise.

Wrote about it in the context of workflow systems way back (https://livingsystems.cc/posts/workflows-dataflow-not-task-d...)

---

Edit 11:12 CET: I realize that “named ports” better captures what I had in mind here, as elaborated in a comment below.

Looks like a really cool project, especially for quick no-setup use cases.

If you prefer to keep things local and open source, and your agents' notes do fit in issues, you might want to check out Epiq too, which is a local but distributable issue board synced via an event log mechanism to ensure consistency when syncing across repos:

https://ljtn.github.io/epiq

Seems they might have discoveref the language of G*d:

"[...] he has given a law to which they must conform."

- Psalms 148:6 (CJB)

:)

Now do the combinations of them.

I hope @jolaflow can chime in here eventually, but from a brief look, my impression, besides the fact that Epiq is based on git as opposed to beads where it is optional, is that Epiq seems to be much more optimized for interactive collaboration between the user and the agents.

The graph visualization in beads surely is a neat thing for showing things, but the replay feature in Epiq should provide a similar understanding of what happened.

But again, it seems to me Epiq is the tool that better allow the user to jump right in and collaborate with the agents on the board.

(Again, this is from a brief look, so I could be missing things).

Sorry, I might not have been clear, but the tool and blog is by @jolaflow (my brother) and I'm so far mostly involved as a reviewer and early adopter, but glad you like it. I might be biased, but I think the tool provides something really useful for agentic coding and hoping it can grow into a thriving open source project.

Yeah, I think as a general direction we need to allow a useful collaboration with the agents on the issue board.

This is btw why Epiq was developed, to keep the board as code, git-backed, distributed (via an event log mechanism), and with the ability to replay the board, to see what agents actually did:

https://ljtn.github.io/epiq

Indeed. A google/brave search on that founder generated nada.

Yea. A google on that founder generated zero results.

I read it, but OK, I misunderstood.

Let's not make this a Nordic conflict. We, the Nordic countries need to stay brothers and sisters with each other as we have done for centuries (not without sometimes serious squabbles, but still). Not even a European countries conflict. It is the EU as an institution that has started growing and reaching way beyond the will and welfare of the people.

I also stumbled upon this site, which on a first glance looks really thorough. Interested to hear if folks have comments on it though:

https://walkinglabs.github.io/learn-harness-engineering/en/

I have had a similar experience regarding tiling window managers. Been trying i3, but everything becomes just super complicated, and I learned I somehow actually appreciate having a feel for windows moving around, and having the freedom to open a small mini terminal above all the others for some quick tasks etc.

For me, XFCE (On Linux Mint currently) turned out to be the answer. Has configurable keyboard shortcuts for pretty much anything you need, like tiling to top/right/bottom/left, corners, moving or resizing windows etc.

To me, that is the best of both worlds - a normal window manager with keyboard shortcuts for tiling the windows when you want.

> Why not put issues alongside the codebase?

That's the idea of Epiq: https://ljtn.github.io/epiq/

> In my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work.

I think Epiq does a decent job of addressing this.

Take a look at the second animation on the page above. It even lets you "scrub" your way through the timeline to very quickly glance at what an agent (or junior developer) did to your code recently.

  "For with much wisdom comes much sorrow;
     the more knowledge, the more grief."

Ecclesiastes 1:18

I found it a bit curious that Mojo seems more readable, while at the same time less compact, than Rust.

At least according to my small experiment:

https://x.com/smllmp/status/2055602226240893043

I liked the connection of the central dogma of biology (DBA to RNA to Proteins) with Lisp programs.

I connected that to streaming flow-based programs though, as opposed to cell-to-cell signaling which shares many characteristics with, Erlang style, fire-and-forget message passing:

https://livingsystems.cc/posts/flowbased-vs-erlang-message-p...

Yea, I like the quiz feature a lot. It feel more efficient than both the podcast one (which mostly creates a very superficial high level talk on a level I typically already grasp), and the flashcard one in my experience.

A self-hosted git-based issue tracker like Epiq [1] seems more relevant by each day going forward.

[1] https://github.com/ljtn/epiq

Thank you for sharing!

Small off topic thing: I recommend removing the bit in the URL from ?si=... and forward, unless you want Google to track every user who clicks this link to your share.

For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).

Yes, this kind of thing seems to happen quite often. Popular posts spurring further posts on a theme.