For those of you who are like me, doing everything you can to not get sucked in by election coverage today, here’s a writeup of an amazing talk about creating tools to leverage LLMs inside an IDE! This is such a fantastic talk by Colin Fleming (@colinfleming), author of the fabulous and indispensable @CursiveIDE plug-in for IntelliJ — this is one of the most popular editing environments for Clojure programmers, which I use on an almost daily basis. He gave this talk at the Clojure/conj conference two weeks ago — it was an experience report on using LLMs in his development process, and likely hints at how LLMs will be integrated into a future version of Cursive. It’s such a fantastic story, because he talks about problems he faced developing and maintaining Cursive, and specific ways LLMs helped, and the challenges that anyone creating dev tools using LLMs will inevitably face, with lessons that are applicable to anyone using LLMs. According to State of Clojure Survey 2023, Cursive is the #2 development environment for Clojure — behind Emacs, and ahead of VS Code. (Personally, I am so grateful for Cursive — I attribute it to having such a wonderful immersion into Clojure in 2016. I’m pretty sure it would not have been so joyful, so quickly, if I had to relearn emacs at the same time!) His story starts with describing how, earlier this year, JetBrains (maker of IntelliJ) started to force plugin developers to migrate away from Java threads to Kotlin co-routines — this is a major shift because since the very first version of IntelliJ in 2001, threads were the primary concurrency primitive. This affects almost every plugin developer: "Intellij is an extremely asynchronous system for performance reasons." "JetBrains is basically telling me that a lot of my [plugin] code is now legacy... The use of Kotlin is becoming more and more required... There is no way we can express proper structured concurrency and cancellation in Java. So the writing [on Kotlin] has on the wall for a while." Enter his problem statement, which he needed to figure out how to solve: "I now have 10 years of Clojure code... About a third of it, about 35,000 lines of Java code, is mostly legacy obsolete stuff I never touch these days. There's about 35,000 lines of newer Kotlin code, and there's about 35,000 lines of Clojure code as well." "I now have a problem. I have 10 years of Clojure code, and I don't want to spend another 10 years rewriting it. And this is where LLMs actually turn out to be amazing." He discovered that LLMs excel at code translation. "This shouldn't really be a surprise. The original 'Attention Is All You Need' introduced the transformer architecture. The example that they used was a [human language] translation problem. It was translating natural language rather than computer languages, but it's a very similar problem, and they're just astonishingly good at this." Fleming translated the Python Difflib library to Clojure this way, to support diffing and patching. (!!) He's also translated other Python libraries, such as Pydantic specs and AI API libraries to Clojure. "It also works in the other direction as well... I've been working a lot with AI APIs recently, so I've been using all of the tooling around AI, which is in Python. So a lot of the client libraries have Pydantic specs for the APIs, and I can just give those to the LLM and it will give me malli specs back." [Malli is one of the popular run-time schema/type checking libraries in Clojure.] (I think this is very cool. I’m a huge fan of the Guardrails library, which annotates Clojure functions to look more like TypeScript.) "These translations are never exactly perfect, but if I had to spitball a number, I'd say they're like 95% of the way there." So enter his initial use case: translate an entire namespace of Clojure code into Kotlin code — he can now do that 30m to 2 hours. @colinfleming: how much time do you think this saves you? i.e., how long would it have taken you without LLM assist? Source: youtube.com/watch?v=oNhqqiKu… 1/??