TL;DR https://claudemd.dev is where you can find guidelines to make your vibe coding more effective
If you haven't used claude code, I highly recommend you check it out. You may have used other AI tools in development, but being a cli with a refined "plan" step has revolutionized my development workflow. The fact that I can dispatch three prompts to run concurrently, and reliably trust the actions being taken feels incredible. I am spending less time thinking about code and more about the higher level direction of the code.
If you want claude code to be more reliable in its output, it can further be directed by using CLAUDE.md files. These files are included in the plan step and significantly improve the quality of its output. What makes a useful CLAUDE.md is similar to a well written style guide [1]. By providing a set of guidelines for what patterns to follow, the LLM can be more focused when building its plan. In a sense, a CLAUDE.md can be thought of as a "language semantics" for your codebase or directory for how to "compile" your thoughts into actions. Fortunately, you don't need to write your semantics in BNF [2], but the completeness of your semantics matter nonetheless. Without forethought, an LLM will happily come up with its own plan for your codebase.
I thought of and published https://claudemd.dev last night with the idea that sharing these files will improve the quality of code that we will be writing for this next abstraction of software development.
I like yaegi [1] for go because it is an interpreter for the go language (almost fully supported, generics need some love). The most important part for me is being able to keep all my language tooling when switching between interpreted/compiled code. Also, there is little needed distinction between what is going to be interpreted and compiled. Once you start including libraries it gets dicey and the need for including the libraries in the compiled part is necessary. There is also a blog post that comes along with it describing how it was built! [2]
I have really fallen in love with LISP recently, specifically clojure. A strong type system is really needed for it to make me feel like I can confidently develop with it.
That's on quicklisp, not Coalton. Honestly, quicklisp is one of the worst parts of CL nowadays (right after the lack of coroutines[1], which is by far the worst offender.) It should have been replaced a long time ago. ASDF3 provides a lot of flexibility, and quicklisp uses maybe 15% of its capabilities. There are reasons why it's still so bad, but it gets less and less excusable each year :(
[1] Does anybody know how to ping Kartik Singh about the coroutines implementation in SBCL? Apparently, he made an experimental port of the green threads implementation from CMUCL, but I can't find it anywhere online, nor any obvious way to catch anyone involved. Is the mailing list the only way?
Thank you!! I was very interested in `convert-thread-to-coroutine` - I saw it on the ELS presentation, and when I went spelunking in the CMUCL codebase, I found the prototypes for `fork` and `resume`, but (probably because CMUCL is single-threaded?) nothing that would suggest how that `convert...` should look like.
Why is there so little interest in green threads/coroutines in CL community? cl-cont really isn't something to point to when asked about C10K problem... or yield/yield*... or async/await...
There's great interest for it, not little. The challenge is who can do compiler programming, add a production ready implementation as contrib SBCL package, and maintain it?
Hm, my impression is based on the lack of posts or articles with people demanding this to be a feature. I searched, and it just doesn't seem to come up in discussions, and when it does, it's invariably about cl-cont and problems with it.
The first implementation doesn't need to be production-ready. And the maintenance burden (along with polishing the implementation and porting to other architectures) could be shared by a few people and done over time. Having a starting point in the form of CMUCL code (already adapted to SBCL!) is the perfect opportunity for everyone interested to chime in: enough voices in favor could convince someone capable to continue the work. Yet, there are literally just 3 comments under the ESL presentation video, and it's not mentioned anywhere else...
It's mentioned on X and Discord plenty, but you're right about cl-cont.
The first few steps would be building on top of this work and reaching out to the SBCL maintainers via the mailing list to see what it takes to get this merged in.
