Claude & Clojure It's no secret that I use Generative AI, specifically Claude Sonnet, to assist with the Ooloi project. I use it for writing Clojure tests TDD fashion, for generating Clojure code, for generating documentation, READMEs, architectural design documents and much more. Above all, I use Claude for exploring architectural strategies before coding even begins. It's somewhat reminiscent of pair programming in that sense: I'd never just task GenAI with generating anything I wouldn't scrutinise very carefully. This approach works very well and allows me to quickly pick up on good design patterns and best practices for Clojure. Claude & Python Overall, working with Claude on Clojure code works surprisingly well. However, this is not the case when I try to involve Claude for coding in Python, the main language I use as an AWS Solutions Architect. Generative AI struggles with creating meaningful Python tests and code – especially tests, which rarely work at all. This hampers its use as an architectural discussion partner and a TDD assistant. In fact, I've given up trying to use Generative AI for coding in Python. DifferencesI have a deep background in Common Lisp and CLOS, dating back to the 1970s. I've written Common Lisp compilers and interpreters, as many Lispers did in those days. The standard practice was to write a small kernel in assembler or C or some other low-level language, and then use it to write an optimising compiler on top of it to replace the kernel in an iterative fashion, sometimes using transformations of source code based on lambda calculus. (I still remember that paper by Guy Steele.) I see Common Lisp essentially as a big bag of good-to-haves (a really excellent one, mind you). As such, it was designed by committees over a period of decades. Clojure, on the other hand, is much tighter and rests solidly on consistently applied computer science design principles. Common Lisp is pragmatic and eclectic and thus somewhat sprawling in design. Clojure, in comparison, is smaller and much more focussed, even opinionated in nature, and for clear reasons. People attracted to Common Lisp and Clojure tend to be pretty well versed in computer science, especially Clojurians who generally have a good understanding of functional programming and immutable data structure concepts. Thus, the public code "out there" on sites like GitHub tends to be fairly advanced and of high quality. Python is an entirely different ballgame. It's one of the most commonly used languages today, and the public code base is absolutely enormous. This also means that the quality of that public code varies considerably. Also, Python is not functional at heart, and its data structures aren't immutable: side effects is the name of the game. Python programmers, though much greater in number than Clojure programmers, range from script kids to computer scientists. Thus, public Python code is much more all over the place and of varying quality. This may make it harder for a large language model to reason about. I wondered whether these differences accounted for the discrepancies in the usefulness of Claude and other LLMs as coding assistants in Clojure and Python. Asking ClaudeSo I decided to ask Claude 3.7 itself. I shared the Clojure codebase with it and asked why it thought results were so much better for Clojure than for Python. This is what it said:
It then continued, quoting the code base:
I guess this answers my question about Clojure vs Python. It's not just the functional and immutable aspects of Clojure, it's also specifying the domain stringently through design, architectural discussons, specs, and tests. The Ooloi project in particularWith all that out of the way, I then went on to describe how I use Claude as a discussion partner before code is generated, and the TDD approach I'm using where the tests of course describe the domain. Claude was almost embarrassingly enthusiastic:
I continued: "I also use Claude to create ADRs, READMEs, introductions for newcomers, Dev plans, etc. I'm quite open about this; transparency is paramount in an open-source project, and the idea is to facilitate collaborators' understanding of the Ooloi project as much as possible. This means that adherence to best practices, the use of sane architecture, abstracting away the complex stuff without compromising on performance or flexibility, etc, all are central." Claude responded:
We then went on discussing open-source strategies, tutorials and onboarding materials for contributors and much more which I'll spare you from for now. Finally, I asked it to summarise its views on Ooloi as a project:
Now, this level of enthusiasm and praise from an anthropomorphic-presenting LLM (essentially a glorified Markov chain) always makes me deeply suspicious – I'm absolutely allergic to toxic positivity, especially the kind from the USA – so I asked it "Are you sure you're not overly enthusiastic just to please me?". It replied:
I then asked Claude 3.7 to comment on my journey from Common Lisp to Clojure and on the influence from Common Lisp and CLOS on Ooloi:
And finally, I just couldn't resist asking: "What would Rich Hickey say?"
I guess that hypothetical assessment is good enough for me at this point. Still not quite sure that Claude isn't giving me a friendly reach-around, though... ;)
0 Comments
 It's been five months since my last update on Ooloi – or FrankenScore, as it's still known in its pre-release incarnation. This silence wasn't planned; rather, it happened because life got in the way. A demanding day job, a significant career change – we had to liquidate Delegat AB and I had to find a new job as a principal-level AWS Cloud Architect – and other responsibilities all conspired to slow Ooloi's momentum. I won't bore you with excuses – sometimes one simply must pause to change course, and I really needed to devote all time and mind space to finding what I hope is my final employment. Now that I've secured a great position with HiQ in Stockholm, I can return to Ooloi with full force. Where We StandDespite the public quiet, work has continued, albeit at a more measured pace. The foundational architecture – that robust, high-performance platform for ACID-compliant transactions – remains solid. I've made incremental improvements to the core API, particularly in how it handles complex musical structures through our vector path descriptor (VPD) system. The polymorphic API is now fully mature, offering a consistent interface whether used internally in the backend or remotely by the frontend. This uniformity will prove invaluable both for our own development and for future JVM plugin creators, who'll benefit from the significant abstraction it provides. File persistence using Nippy has been fully implemented, creating a solid foundation for saving and loading pieces. This might seem a mundane milestone, but anyone who's worked with complex software knows that solid persistence mechanisms are like plumbing – unglamorous but absolutely essential, and you certainly notice when they're missing. File persistence, like high-quality printing, should be implemented early in the development cycle as they can be devilishly difficult to just tack on later. They also provide an acid test for the whole architecture. A Bit of ReflectionFive months of relative silence offers time to think. Perhaps there's value in stepping back from the constant pressure to show visible output. In such moments, the architecture is refined not through frantic coding but through careful consideration. The journey from Igor Engraver to Ooloi spans decades, and a few months of slower progress hardly register on such a timescale. What matters is that the vision remains clear and the foundation solid. After all, the whole purpose of the Ooloi project is not to "disrupt the market". Like Octavia Butler's ooloi aliens, we're neither aggressive nor competitive. What is important, however, is doing this right using modern tools. The idea is to create an architecture and a platform that'll last and that musicians and publishers will want to use. It's also to provide a powerful environment that can be easily extended through any JVM language. Ooloi has a tight, lean and efficient core, organically and seamlessly augmented by a flora of plugins for any vertical. This would include jazz, early music, tablature, etc - but also commercial plugins to support things like virtual instruments, extremely intelligent playback, or perhaps GenAI used for musical purposes. The idea is to shift the initiative to the users, not to a central committee trying to anticipate user needs. Ooloi is designed for flexibility and efficiency. Uniting these two aspects sucessfully requires careful architectural design. (And a language like Clojure for the core and the JVM for the plugins.) Community BuildingWith the core architecture stabilising, I'm thinking more about community. Ooloi is intended as an open-source project, a collaborative effort that will benefit from diverse perspectives and expertise. The extensive documentation work completed earlier – including the architecture decision records, READMEs, and technical specifications – was not merely for my benefit. It prepares the ground for future collaborators, creating a clear map of the territory for those who will join us. The website, this blog, and the growing collection of documentation all serve as beacons for those who might be interested in contributing. They signal our commitment to transparency and proper communication – essential ingredients for any successful open-source project. Looking ForwardSo what comes next? The gRPC layer for communication between frontend and backend remains a priority. This is the bridge that will allow the beautiful architecture we've built to manifest in a usable form for musicians and composers. Following that, the initial frontend work – that "Hello World" window that will serve as proof of concept – beckons. While the backend architecture is undoubtedly important, it's through the frontend that users will experience Ooloi. Getting this right is crucial. The SMuFL integration for standard music font layout continues to progress, ensuring that Ooloi will render beautiful notation with consistency across platforms. Challenges and OpportunitiesEvery project faces challenges, and Ooloi is no exception. Time constraints remain the most significant hurdle, as this is still predominantly a one-person effort with limited hours available. There's also the natural tension between getting it right and getting it done. The perfectionist tendency can be both a blessing and a curse in software development. While it drives us towards excellence, it can also delay progress if not properly balanced. The task here is to create a platform for music processing and notation. This balance has to be exactly right so that contributors can treat Ooloi like a music notation OS rather than just a bunch of API endpoints. I think the balance is right; it's looking very promising. Yet within these challenges lie opportunities. The time spent refining the architecture will pay dividends in the long run, creating a more solid foundation for future development. A Call to Potential CollaboratorsAs Ooloi progresses toward its eventual public release, I'm increasingly aware of the need for collaborators. If you're a Clojure programmer with an interest in music notation, or a musician with programming skills, your perspective could be invaluable. While we're not yet at the point of opening the repository – though a "soft release" isn't out of the question – I welcome conversations with those who might be interested in contributing once we do. The journey from FrankenScore to Ooloi – from private project to open-source collaboration – will be richer for having diverse voices involved from the early stages. Closing ThoughtsFive months of comparative quiet doesn't mean I've abandoned ship; it simply reflects the natural ebb and flow of a project undertaken alongside life's other commitments. Ooloi continues to grow, perhaps not as swiftly as in those heady initial weeks, but with steady purpose nonetheless.
I'm reminded of how musical compositions themselves develop – sometimes in great creative bursts, other times through careful refinement of existing material. Both approaches have their place. To those following Ooloi's progress, thank you for your patience. The work continues, and updates will come more regularly as we approach the milestone of public release. The vision of a modern, efficient, and elegant music notation system – one built on sound architectural principles and open to community collaboration – remains as compelling as ever. Until next time (which will be considerably less than five months hence), / Peter  When I started programming in Lisp in 1979, after reading an article in BYTE Magazine, I hardly imagined that 45 years later I'd be embarking on a new Lisp adventure. Yet here we are, with FrankenScore (to be renamed Ooloi upon open-source release) – a modern music notation software built with Clojure. It's a project that brings together all my lifelong passions: music, programming, and the pursuit of elegant solutions to complex problems. The Path from Common Lisp to Clojure My journey with Lisp began in an era when optimising Common Lisp compilers were cutting-edge technology. I cut my teeth implementing Common Lisp interpreters and compilers (as one did in those days), delving into the intricacies of a truly original programming language. This experience shaped my understanding of what a powerful, flexible programming language could be. And now in 2024 I find myself in the world of Clojure, a modern Lisp dialect that runs on the Java Virtual Machine. The transition feels both familiar and novel. Clojure's emphasis on immutability and its handling of concurrency through Software Transactional Memory (STM) aligns with the functional programming principles I've long appreciated in Lisp. But it's not just about the language. The ecosystem around Clojure – the JVM, the interoperability with Java libraries, the rich set of tools and frameworks – provides a robust foundation that we could only dream of back in the Common Lisp days. CLOS Thinking in a Clojure World One of the more interesting aspects of this transition has been adapting CLOS-style thinking to Clojure's more data-centric approach. CLOS, with its powerful multiple inheritance and method combination features, encouraged a certain way of modelling problems. In FrankenScore, I've found myself reaching for these familiar patterns, but implementing them in Clojure's more functional style. For instance, the use of Clojure's protocols and multimethods, combined with hierarchies and the Methodical library, allows us to achieve CLOS-like polymorphism. It's a different approach, but one that feels natural once you embrace Clojure's philosophy. Clojure's deliberate avoidance of traditional object-oriented features felt immediately familiar and refreshing. It resonates with CLOS's approach, which many, including myself, have long regarded as transcending traditional OOP. Composition over inheritance, a principle I always valued even in the CLOS days, is not just a best practice in Clojure but the very fabric of its design philosophy. This alignment between CLOS's advanced features and Clojure's functional paradigm makes the transition feel natural and even inevitable. Changes in ThinkingPerhaps the most significant shift has been in embracing Clojure's emphasis on immutable data structures and pure functions. While these concepts weren't foreign in Common Lisp, they're central to Clojure's design. This shift encourages a style of programming that's inherently more thread-safe and easier to reason about – crucial for a complex application like FrankenScore. Another major change has been adapting to Clojure's more minimalist standard library compared to Common Lisp. This has led to a greater appreciation for carefully chosen, interoperable libraries and a more modular design approach. SimilaritiesDespite the differences, there are of course similarities in the overall approach. The emphasis on interactive development, the power of macros for domain-specific languages and the elimination of boilerplate code, plus the satisfaction of working in a dynamic, expressive language – these are all as present in my Clojure work as they were in my Common Lisp days. Moreover, the focus on solving complex problems through abstraction and composition remains. Whether it's CLOS or Clojure, the goal is still to create systems that are powerful, flexible, and pleasant to work with.  Closing ThoughtsThis journey from Common Lisp to Clojure, from Igor Engraver to FrankenScore/Ooloi, is both challenging and rewarding. It's a testament to the enduring power of Lisp's ideas and the continued evolution of programming languages.
As I continue to develop FrankenScore, I'm captivated by the possibilities that Clojure and its ecosystem offer. While creating a powerful music notation software is the immediate goal, the project's scope extends far beyond that. It's an exploration of the synergies between music, technology, and open-source collaboration – a playground where these elements intersect and interact in novel ways. To those considering a similar journey, I'd say: embrace the change, but don't forget the lessons of the past. The parentheses may look familiar, but the world inside them is ever-evolving.  A recent question in the Clojurians Slack channel caught me off guard when I was asked to compare FrankenScore to Sibelius. This request for a direct comparison not only made me pause but also brought back memories of Igor Engraver's rivalry with Sibelius – a competition that once saw Sibelius's own CEO defect to our side. However, that was a long time ago. Now, as FrankenScore carries forward Igor's legacy, I was challenged to articulate our unique value proposition in this new era. Here's how I responded: NN:
Hey, that looks promising! What are the advantages it will have compared to Sibelius? Peter Bengtson: Wow, that's actually a pretty multi-faceted question. While we're still in development and can't yet offer a feature-by-feature comparison with Sibelius, I can highlight some key advantages we're aiming for:
Importantly, as an open-source project, FrankenScore will be free to use. Many music departments struggle with excessive license costs. For those interested in more details, ooloi.org contains a wealth of information about the project, its goals, and its technical underpinnings.
 An Architecture Decision Record (ADR) is a point-in-time document that records architectural decisions and the reasoning behind them. And since communicating architectural ideas clearly to collaborators is extra important in open-source, I've just added a bunch of ADRs to the Documentation page.
They cover various aspects of the FrankenScore architecture, from high-level design decisions to specific technical choices. They are:
 In the past weeks, I've been focused on FrankenScore's core architecture. I'm not rushing to open-source this; instead, I'm taking my time to craft a solid platform that will do the heavy lifting for future users and collaborators. All the complexities involving data representation and manipulation in a multi-threaded environment must be solved so collaborators can concentrate on the essentials. Clojure is ideal here, just as Common Lisp was the clear choice for Igor Engraver back in 1996.
Key developments: 1. The API is now fully polymorphic and can be used in the same way internally in the backend as in the frontend. There is a system of pointerless vector path descriptors (VPDs) implemented for this purpose that all API operations can accept as part of their polymorphic setup. I wouldn't be surprised if core collaborators will use the API for internal purposes as well, as it is highly efficient and exposes the underlying functionality in an abstract, domain-specific way. There should be little need to go directly to the underlying data structures, at least not for speed - and certainly not for expressivity. This also bodes well for plugin development in other languages than Clojure, which is an important feature. 2. This beast is fast. Clojure's STM facilities ensure high-speed ACID-compliant transactions with automatic retries. They are also composable. This means that plugins can bombard the backend with hundreds of thousands of mutation requests, for instance to implement MusicXML, with the same efficiency as the pure Clojure backend. 3. Piece Manager Implementation: There's now a Piece Manager, providing functions for storing, retrieving, and resolving pieces from IDs. This allows for multiple clients to work simultaneously on the same piece in a distributed arrangement. The FrankenScore backend can run in the cloud with multiple people collaborating on the same piece. Multiple pieces can be open simultaneously to allow copy-and-paste operations between them. My next steps involve implementing file persistence (saving and opening music files), as well as tackling printing. These are foundational features, not mere add-ons. Persistence forces a clear definition of the data model and enables easier testing. Printing isn't just about output; it's about representation and serves as a sanity check on the entire system design. Both will likely inform further refinements of the core architecture, potentially revealing oversights or opportunities for optimisation. Additionally, sequencing is a crucial part of the core platform. And by sequencing I mean support for converting musical representations to timed sound events - though not necessarily via MIDI; a software synth may use direct means of control, for instance. The core sequencer can be used by plugins to generate MIDI, or to input MIDI, but the actual MIDI implementation will be done in the plugin layer. But that's a whole blog post of its own.  Finale is finally being discontinued. The reason is simple and technical in nature: after 35 years, its codebase has become exponentially more difficult to maintain, and it's now reached the point where the returns of any effort spent on it have diminished to the point where they have vanished entirely. There is a crossgrade to Dorico being offered at a fairly low price, and the Finale installer will work for some time yet, but there will be no more updates, and in a year's time Finale will be completely dead as new installations no longer can be activated. After that it's only a question of time until operating systems change beyond the point where they'll support old code no longer updated for them. Read more here: https://www.finalemusic.com/blog/end-of-finale-new-journey-dorico-letter-from-president/ This composer's take on the situation and on the available alternatives is interesting. It's clear that not much has changed in the way of user-friendliness and note entry methodology even in more modern programs, and that the learning curve still is steep. In a way, that's great news.  FrankenScore is our current working title. It's fitting for now, as I'm essentially stitching together old ideas with new ones in a highly charged electrical atmosphere somewhere in a metaphorical Transsylvania. But as the project progresses, it's clear this isn't just resurrecting or recombining; it's the creation of something rather different. When we go open-source, the project will become Ooloi. For those unfamiliar with Octavia Butler's work, the Ooloi are alien beings with a knack for genetic manipulation and transformation. It's a decent metaphor for what we're doing: taking the DNA of music notation software and turning it into something new. This future name change isn't mere whimsy. Where FrankenScore suggests our current closed-source phase of experimentation, Ooloi represents what comes next. It's organic, sci-fi, modern, mind-bending. A bit like the software itself, one hopes. Ooloi is also just a good name. It's odd, memorable, and stands out in a field not exactly known for its naming creativity. So, there it is. When this project eventually emerges from its closed development, it'll do so as Ooloi. A name that, with any luck, will suit the software it represents. The metamorphosis is coming. Eventually.   Gustav Mahler's summer composition hut The past four weeks have been a whirlwind of productivity. Enjoying a deep creative flow, I've really been wind-surfing through parentheses as I've been working almost around the clock on FrankenScore. The results have been surprising:
This initial rush has successfully got FrankenScore off the ground, building a strong foundation in record time. However, as my holiday draws to its close and my day job with Delegat AB resumes, the pace will inevitably slow down a little. The timeline for releasing FrankenScore as open source depends on several factors, including the presence of internal collaborators before the public release. While the foundational work is largely complete, the project will continue to evolve at a steadier pace. If I'm left entirely to my own devices without any pre-release assistance, I should say the public open source release of Ooloi 0.x will happen in about a year's time. With collaborators, in about six months or so. But this is difficult to gauge with any exactness, as there are so many variables involved. Also, after going public, remember Ooloi won't be finished by any means. That's when the journey begins in earnest, travelling the distance from Ooloi 0.x to 1.0. But then we'll be travelling as a group. Anyway, there'll be regular status and road map updates on this blog. I'll keep you posted. |
AuthorPeter Bengtson –composer, organist, programmer, cloud architect. Currently windsurfing through parentheses. 
Archives
March 2025
Categories
All
|
RSS Feed