I'm getting a deja vu with this question

What would be its purpose?

reply to messages that contain links with a list of previous conversations that contained the same link

Interconnecting conversations seems very useful. I'm new here so I do not dare to answer technical requests concerning the community.

the question doesn't concern the community, it's just a "request for future of code adjacent technologies that may be useful to solve this problem" 🙂

Love the idea of resurfacing previous conversations automatically.

I wonder if we could somehow implement a backlinking system. Wiki links like this [[syntax]] could cause the bit to auto-reply with… something. 🤔

I could index wiki links in my archive (example marianoguerra.github.io/future-of-coding-weekly/history/weekly/2022/05/W5/share-your-work.html#2022-05-23T15:49:14.120Z)

I could turn that syntax into a link to a page showing all the backrefs

maybe the bot could bring the backrefs here (or the link) when asked to

Interesting. I already use the archive fairly often. Would be pretty cool to build index pages for each wikilink with all relevant messages.

I’m working with a developer to build a similar system for Discourse.

If the idea is to use "Futuristic" technologies, I'm tempted to say it would be plenty cool if it was written in Smalltalk or something. Maybe Pharo? :D

if it was easy and cheap to deploy as a server I would, I'm not sure it is 😕

my main candidates right now are unison and darklang

I suspected as much. I like the options you listed, too. :)

I recently built a simple system like this at work. I use Slack’s extension system to get messages as they come in, which are sent to a web endpoint where some basic python parses the event and (in my case) forwards it on to the rest of the system. It shouldn’t need much more than the slack extension, web endpoint, and access to slack history data.

Definitely go ahead and use whatever tech, but an affordable solution would be to use something like Google Cloud Functions which I use atm and haven't hit the ceiling on the free tier despite a very active Slack.

The idea is to try some future of coding related tool

In that case I’d second Unison, you’ll need a Slack extension regardless afaik, but Unison is so fun to work with.

I have a twitter bot made with the precursor to webcode observablehq.com/@endpointservices/twitter-bot thats a serverless tech so its exceedingly cheap to do event driven stuff (and it supports live debugging which you will quickly realise you will want when doing webhook stuff). Happy to twitch it too, observable supports multiplayer coding.

I'd be curious to see how Tom Larkworthy's approach does with something I'd use 🙂

I forgot I just used zapier to do the tweeting for that bot, I am able to do a full low level API integration too but I just didn't bother. I once did a production slack bot using BPMN workflows: futurice.com/blog/a-detailed-look-at-camunda-bpmn-application-development too. It was that experience that made me decide it was far quicker using zapier.

What is it?

thanks for the comment. i’m a bit reluctant to answer ‘what’ directly, since

• i’m interested in what you make of them without much framing
• as ‘sketches’ they really are open for interpretation/insight

but thanks for asking; here’s a bit more orientation & i can elaborate more if you want

• these are three sketches from a broader set, just to give the flavor of them
• each one is just a unicode text file open in a Vim editor. anything ‘special’ beyond basic navigation is annotated in the file.
• a general theme is me trying to get a better grasp on the spatial & physical nature of text editing
• sketch #1 is about embedding multiple spatial dims in a single vertical dim. no macros are involved, i’m just using “*” and “#” to ‘jump to next/prev match’ on different labels to ‘move’ in ‘view space’ along spatially embedded axes. each ‘frame’ is found in a different part of the file.
• sketch #2 is roughly about ‘direct manipulation’ of code/data/environment. idk if you’re familiar with Vim, but all editor commands can be recorded as plaintext macros & replayed on command. i’m just going a step further and saving macros in the doc/executing them from the doc
• sketch #3 is a birds eye view of an afternoon prototyping session; gives some sense of the ‘sketchbook’ feel of the approach
• overall, this approach (i.e., sketching directly in Vim plaintext) is the first concrete instance where i can recognize a semblance of the inchoate thing i’ve been incubating. it also captures more ‘computer nature’ than some of the pen & tablet experiments i’ve seen, though that’s def a place i want to converge on at some point

Looks super tantalizing!

From the FAQ:

But in many cases pure computation is only a (relatively small) part of what software does. Most applications are stateful: they sit there, idle or semi-idle, and wait for some sort of input from the external world. When that happens they change their state in response (and usually also perform some I/O). Think, for example, of desktop, web or mobile application, which respond to user input, or some types of server applications, which respond to requests issued by the client across the network.

A lovely summary of this. I feel like a TON of languages and development tools try to pretend that state isn’t a thing. That there isn’t a giant array of bytes sitting around waiting to be messed with in memory somewhere, and that The System(tm) will handle everything correctly. Very prevalent in my main domain, which has been iOS / Android development for… well, too long, heh. This seems interesting to me!

This seems very promising in the smart contracts space, where everything is data structures reacting to events. I just wonder whether the code generation can be made to explain itself.

I like to imagine that DNA is somehow self-generating, self-documenting code - if only we figured out how to compile the docs 😉

Yes! It might also be interesting to recognize that the usual text/code is merely another representation of the ast, which in turn is a representation for a deeper meaning; which may be beneficial to treat as the "real" source of truth.

Exactly. The work we're doing focuses on the real-time editing of the AST on a canvas. The text is just how the AST is persisted to/from disk.