I would love to use Clojure but there are basically no jobs in my area with the language. Seems like the Nordics like Clojure but I'd need to move.

The very good backwards compatibility is attractive but as the result of the small community, there's also a lot of abandoned packages and fewer QoL packages (formatters, linters, etc); I know there are some but for example I had setup `cljfmt` in Emacs and it wouldn't work, didn't look further.

VS Code and its forks (Cursor, Antigravity, etc.) have Calva, a fantastic REPL with excellent linter Kondo. These are amazing tools; formatting is the very least of it. You don't need Emacs. I personally using VS Code + Doom Emacs. Also, many packages that look abandoned are simply mature. You can literally use ten year old packages.

I'm not a hot shot programmer, entirely self-taught but a decent architect who thinks hard about problems, and with LLM agents Clojure shines for me. There are some fantastic databases also starting with Datomic -- free now thanks to Nubank -- and everything inspired by it and the Clojure flavor of Datalog. These include Datalevin, Datahike, DataScript, XTDB. Datomic itself is probably best for enterprise though there's now an embedded version.

But I'm pretty convinced that most LLMs I've used are more reliable with Clojure (and Elixir) than with most of the popular languages, and I can say they use Datalog extremely well, seemingly much better than SQL despite the vast difference in corpus size. For one thing Datalog just gets rid of joins issues.

> I would love to use Clojure but there are basically no jobs in my area with the language

I created my own job :-)

(although there are Clojure jobs in my area)

Always a solution ofc!

cljfmt is included with both Clojure-LSP and CIDER, so if you have either installed it should work out of the box.

With LSP mode the standard `lsp-format-region` and `lsp-format-buffer` commands should work, and on the CIDER side `cider-format-defun`, `cider-format-region` and `cider-format-buffer` should also invoke cljfmt.

Hey! Thanks for creating the package =) I'll need to try the integration again.

I'll add a note to the cljfmt README to tell people about these commands, as your experience shows that it might not be obvious to people that they likely already have access to cljfmt in Emacs as a result of using LSP or CIDER.

There are still Clojure remote positions. Thankfully, I have used Clojure professionally long enough that my core ability shouldn't atrophy too much now that we have moved away from it at my current position. I am looking forward to Jank actually.

Thanks, I had to do the same.

I thought it was generally interesting but it needs to materialize into processes and tools people can use.

That's kind of the point. These things don't just happen, people start talking about it at a high level (this doc, conversations like this) and then dig in and solve the problems over time.

I know but still it was a bit too high level for my taste though I appreciate the effort!

Yeah I was looking for the next one!

Looking at their misrepresentations and over-exaggerations regarding Erlang it now seems like a long lead-up to a sales pitch. Their motivation to exaggerate deficiencies in existing approaches is to lend chapter 7 more rhetorical punch. All the same, I'm keen to hear what they have to say.

There are some use cases for very dynamic code, like ORMs; with descriptors you can add attributes + behavior at runtime and it's quite useful. Anyways, breaking metaprogramming and more dynamic features would mean python 4 and we know how 2 -> 3 went. I also don't think it's where the core developers are going. Also also, there are other things I'd change before going after monkey patching like some scoping rules, mutable defaults in function attributes, better async ergonomics, etc.

I don't believe that the taxes on it has that much of an affect on usage and is mostly just a rregressive tax on the already poor and desperate.

You'll just end up creating a black market (high tax has resulted in 1/3 of cigarettes being illegal in the UK) and home production (since anyone can make their own alcohol easily)

Tax rates have been going up on alcohol at least, just boil the frog.

And what does that achieve? It makes the poor poorer. The alcoholics will still drink but their families will have less.

What you do do is create a black market, because people will want to buy it cheaper elsewhere. That puts money into the hands of criminals.

Anyone can make alcohol unlike most drugs. It's remarkably easy to make. You just need patience, and raw materials: potatoes, fruit or whatever. You can make it in your back room. The problem is that it is not high quality, and can contain chemicals which can make you drunk.

Full support to the author, I hope they'll be able to keep making things that are interesting and outside the box like Decker and WigglyPaint. I hope they'll find solace in keeping at creative things.

I also wish LLM copies were not crowding out actual artists.

You're kind of building a stack of exceptional cases... Wonder what that is :D

The current meta is to use task groups and bubble up the exception that cancelled the coroutine/task.

> My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate

It really forces you to do outside-in testing; I usually describe the kind of API I want when chatting with the agents. For example, the CLI options, the routes that might be useful for an API, etc.

> I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ever need to add a feature.

Agreed, I don't know if there are good forcing functions to avoid complexity. The providers have a huge incentive to have you waste your tokens (for example when it re-outputs the complete file when you ask for a tiny change).

In "proper" TDD you you supposed go:

- write a test for method that does not exist, it just calls the method and nothing else

- write method that does nothing

- add/extend test that uses that method <-- this very loop starts

- modify method until tests passes

- go back to loop start until you're done

I always hated it. When I work with LLM i first massage interface that tests, then tests, then implementation until all these tests pass.

> for example when it re-outputs the complete file when you ask for a tiny change).

well with sonnet 3.5 and 4.5 (can't say about 4.6) it often will get stuck in a loop trying to update just the required parts and iether waste tons of tokens doing these updates or waste tons of tokens to a point where restring file from git is required. Tokens get wasted regardless.

I like tests, but I don't bother with TDD because it's so ceremonial. I design the API, or at least sketch it out (using a whiteboard or drafting some notes, and doing research). Then I iterate and refine. I only bother with tests once I can commit or when it's no longer viable to tests manually (edit-compile-run cycle). And a lot of time I follow the table pattern.

https://www.oreilly.com/library/view/simplicity/979888865170...

“Test Driven Design” is another way to frame it.