Clojurians Log v2

@mikethompson https://github.com/day8/re-frame2/blob/main/docs/specification/Pattern-WebSocket.md#worked-example--connection-machine link does not work

@partosqq https://github.com/day8/re-frame2/blob/main/spec/Pattern-WebSocket.md#worked-example--connection-machine

> The value of code is now $0 and it is disposable. I find joy in writing good code. I guess this is just not for me.

I find joy in writing good code too. But the AIs are now waaaaaay better and faster than me (if prompted correctly - which is a different kind of skill to coding) So writing good code is now a hobby. And, using AI, I'm doing things I could never ever, ever, have done before, This project (a rewrite of re-frame) is something I've really, really wanted to do for 10 years (since I originally wrote it) And now I can. Finally, I get to try out all the ideas I've had. I can't tell you how exciting it is. Different kind of joy. The beauty of this literally took my breath away: https://github.com/day8/re-frame2/blob/main/docs/specification/Pattern-WebSocket.md#worked-example--connection-machine

@vale it appears to have already worked. I have a CLJS implementation which validates the spec and has 20K lines of tests. And I have examples written for all the stadanrd benchmarks, like realword, 7Guis, TodoMVC, etc. Have a look at the implementation and see if you think it looks like slop? https://github.com/day8/re-frame2/tree/main/implementation My paradigm: if the LLMs make a mistake or produce slop it is my fault. The spec wasn't tight/good enough. rfc2119 and all that.

But maybe I'm missing something. Truely, I might be. This is an experiment. I'm all ears

I envy your experience. I've been playing around with Claude experimenting with a compiler. No matter how "tight" my specs were, the LLM would just ignore them when it ran into a wall implementing. Then it would write tests to "ensure" the incorrect impl. Then it would insist it was always meant to be that way and "another agent" ignored the specs. It was good enough to validate basic ideas, but as soon as things got complex, the LLM would try to cheat its way out instead of actually implementing the spec.

I find this works for me: https://github.com/day8/re-frame2/blob/main/docs/the-mayor-method.md

Very cool! So you used the mayor method + beaads to code the entire spec and it just goes through and does everything? Did you have to have any follow up prompts to fix things or is it getting it correct once it's finished?

also looks like you're reimplementing statecharts, haven't seen those in the wild outside my job 😛 any reason you didn't want to just use https://github.com/fulcrologic/statecharts

Yes, yet another reimplementation of statecharts. You'll find that this implementation is integrated deeply into re-frame2 and tooling, and is not a sidecar bolt on

So you used the mayor method + beads to code the entire spec and it just goes through and does everything?I was validating the spec as I went, so I had to do a fair bit of iteration. It wasn't one shot at all. Next time would be waaay easier, but I don't know how much easier. Is it one-shotable yet - I'm not sure. Getting closer. I'd guess it would take a couple of days and would burn though a weeks worth of a 5x plan, at a guess. (No tools) You'd then have to do quite a few Review for correctness Review for test coverage kind of passes. Most of my iteration recently has been in /tool and /skill. I really haven't touched /implementation or /spec much for a while.

I've found the better you can deconstruct tasks in a flow that'd aid with rapid feedback loops and flowing useful context around the better. Because of that I'm not using any fancy tools, more of a "workflow" that the LLMs follow for more difficult tasks that is similar to my personal way of deconstructing/debugging things. I'm also currently working on flowing context around in a much more controlled manner with statecharts. This is the most exciting thing for me so far.

You'll be surprised at how well re-frame2 supports these goals.

Following your logic, AI-first means that libraries like re-frame won’t be needed anymore. Who cares about the six dominoes in this spec-driven development approach? Who cares about building graphic user interfaces? Am I wrong?

ps: we deeply care about re-frame, we use it heavily.

I think you are both right and wrong. Yes, I think we are moving towards an API dominated communication. AIs don't need UIs, they need APIs. And clear specifications. So UI will be loosing "market share". But on the other hand, there is going to be a LOT of software written over the next few years. Because it is so easy to do now. So, UI will be loosing market share, but the pie will be growing. UI will still be important. And to build them, you need an architecture.

And @asier.galdos If you like re-frame you will love re-frame-2. I promise. It will be utterly familiar and also way better.

It is working with Reagent now and I'm working on the Uix and Helix adaptors at the moment

I don't doubt it, your work is always top-notch. I do worry about the future of our industry because the average Joe does not care about architecture (and they are now building software). I don't really know where we are going with this AI-first approach.

The brainless regurgitation of ai hype invented by CEOs who don't know how to code is a complete betrayal of lisp principles in essence. Instead of thinking fundamentally about languages and making simple (but not easy) macro systems that allow to express intent in a succint and deterministic ways, this is a concession towards string code generators, and undeterministic ones at that. It's ok, I guess. Though I'd suggest changing the name to Java-frame to follow the JavaScript tradition of lisp features in languages being overshadowed by corporate $billion-driven hype. You also get a free motto: It runs on 3 billion AI agents!

@asier.galdos you are right to question the mass hysterical behavior. However, you should understand that they are extremely sensitive about questioning superimposed dogma. This has always been the case with developors, we are an extremely religious crowd, but AI made it 2-3 times worse. This means me, you, and all the others who call the king naked, won't be granted the benefit of the doubt, won't be argued with in good faith, won't be afforded the same "maybes" and good faith concessions that we are willing to make for the sake of argument, etc. I haven't witnessed a single argument that hasn't started with anecdotal evidence of the "power of ai for everything" and "it's the future", and that doesn't have the author admitting 5 minutes later that their own particular use case of generating fizzbuzz in a controlled and heavily supervised scenario is almost solved. It's a hard path for the doubters

@asier.galdos I can remember being an assembler programmer and being annoyed about having to learn C. But value moved up the chain. This happens all the time in economics. One level gets commoditised and value moves to the level above. I believe we are seeing a transition up the chain again. code -> specs. But I could be wrong. And remember that "Architecture" is just another way of saying "Stuff which is hard to change later". There's always some stuff that is hard to change later, irrespective of your approach, including with AI, and THAT'S the new architectural decision. Coming up with a "spec" for re-frame meant I had to make a bunch of decisions about the way the spec -> code process would work. Those were architectural decisions.

@pavel.filipenco time will tell

Super excited about frames, SSR, and routing as state! Congrats 🎉

I doubt what you describe will happen unless the way LLMs operate is fundamentally changed. That or, brace for impact. cf https://x.com/johncrickett/status/2052002943780679697