Clojurians Log v2
hyperfiddle 2025-03-23
I fed the Electric Clojure v3 tutorials (as of 2025-03-23) into an LLM and asked it to write some .cursor/rules guidelines for Electric Clojure v3 (+ some manual intervention) because Claude keeps trying to write v2 code instead of v3 due to its knowledge cut-off. Here you go, guys: https://github.com/theronic/clojure-prompts/blob/main/electric-clojure-v3-rules.mdc
Apologies up-front because there will be mistakes, but corrections are welcome 🙂. The clojure-prompts repo also contains general Clojure coding principles for LLMs which are more about usage and less about whitespace conventions, which most style guides tend to focus on. For effective AI usage, you'll also need some architecture guidelines for your LLM to effectively plan out and work on larger applications.
I found the files interesting to skim, and I'm reading the Electric 3 one. I will comment on the Electric 3 one only. I'm not familiar with how this kind of files work. I'm going to comment on it as if it was a fast-paced introduction to Electric 3 for a very attentive and sharp (but not omniscient) programmer that was frozen in time since mid 2024 and only knew about Electric 2, and otherwise knows Clojure well. This idealized programmer can learn well from terse reference material as long as all the information is there and presented in a reasonable progression, without too many forward references. Also I'm doing this because it's fun to me but stop me if you don't think it's useful.
> - *Signals, not streams*: Electric models signals (like mouse coordinates) rather than streams (like mouse clicks). I know where this is coming from, but I don't think it is helpful as is, without more elaboration. Our programmer already knows this from their familiarity with Electric 2 or missionary (and I suspect a missionary .mdc would help greatly). If they didn't, they would be unlikely to get the point. They would need help narrowing down the meaning of "signal" vs "stream" here, since those terms are being used with very varying meanings in programming and other disciplines.
- *Platform interop forces site*: Interop with platform-specific code (like DOM or Java) forces expressions to a specific site."site" has never been defined or mentioned up to this point. Adding "(i.e., client or server)" would clarify what is meant. Maybe this is overkill if the AI knows Electric 2, and maybe AIs are OK with getting this clarified later.
Thanks, I’m driving atm., would you mind editing on gh and opening a PR? Or come and edit local if the unwrapped md is easier to edit that way?
I'm not sure this would be useful; I'll ask Claude and maybe open a PR once I learn what these files are supposed to contain. :)
It may be overkill. I’ve tried feeding Claude the Missionary source code and it didn’t help much with usage. I d foresee distilling detailed rules into condensed rule files
I'll continue with some prose comments here while I edit the .mdc: the electric tutorial initially talks about "differential collections", but that is white lie to ramp up the user gently into the concept of table. I think the .mdc should go straight to the concept of table instead, pointing the AI to stay tuned for the introduction of e/amb later?
Ha yeah I tried and I kind of bluescreened trying to explain tables in a way fit for a reference as per my first reply, which means I don't understand them (and their relation to incseqs) well enough. I'll keep reading and playing with Electric before I try and teach AIs anything about it.