Yesterday’s post was about pitch transposition in Ooloi: how an old Igor Engraver function (printed on a t-shirt, of all places) came back to life in a new context. That work didn’t just solve the mechanics of shifting notes up and down; it reopened the larger question of playback. How do you hear microtonality and advanced humanisation without drowning in technical workarounds?

In Igor, the answer was MIDI. Notes were split across channels, bent into place, reassigned constantly. The result worked, but at the cost of complexity: a “DNA soup” of allocations and pitch-bend tricks. Ingenious, but exhausting.

Ooloi makes a different choice.

With ADR-0027: Plugin-Based Audio Architecture, we draw a line: no MIDI output in the core, no audio generation in the backend. Playback is done entirely through plugins in the frontend. If you want VST/AU instruments, SoundFonts, OSC, or any other output path, you install a plugin. The backend remains what it should be: musical data, collaboration, structure.

This is not just simplification, it’s liberation.

• Microtonality is handled directly in the data model, then played back by plugins without channel gymnastics.
• Humanisation is no longer bound to 7-bit controllers; plugins can drive modern sample libraries with full parameter precision.
• Collaboration becomes clearer: the backend never streams audio, never mangles MIDI, never compromises. Each client handles its own sound.

Put bluntly: we no longer need MIDI as an output protocol. It served its time. For professionals who need nuanced playback, orchestral realism, or contemporary techniques, we now have better tools: VST/AU plugins and beyond.

That said, MIDI output isn’t forbidden. If anyone needs it, a frontend plugin can provide it. For tonal music it will work fine. But if you want advanced humanisation or microtonality, you’ll inherit the need for all the old machinery: channel allocation, pitch-bend acrobatics, the DNA soup. That’s exactly why Ooloi itself doesn’t touch it.

The logic is simple: Ooloi’s core manages music, not sound. Plugins handle playback, and in doing so, they do it better than MIDI ever could.

The DNA soup is gone. What remains is clean, modern, and far more powerful.

​Our solution was elegantly brutal: we seized complete control of attached MIDI units and employed pitch bend to achieve microtonal accuracy. This required distributing notes across MIDI channels according to their pitch bend requirements, using register allocation algorithms borrowed from compiler technology. In a chord containing one microtonally altered note, that note would play on a different channel from its companions. We changed patches frantically and maintained no fixed relationship between instruments and channels – everything existed in a kind of 'DNA soup' where resources were allocated dynamically as needed.

This approach let us extract far more than the nominal sixteen-channel limit from typical MIDI synthesisers. We maintained detailed specifications for every common synthesiser on the market, including how to balance dynamics and handle idiosyncratic behaviours. 

​The system's sophistication extended well beyond pure pitch calculations. When my opera The Maids was commissioned by the Royal Stockholm Opera, I spent considerable time crafting realistic rehearsal tapes. Everything I learned from that process was automated into Igor's playback engine.

We also collaborated with the KTH Royal Institute of Technology Musical Acoustics department, led by the legendary Johan Sundberg, whose research had quantified subtle but crucial performance characteristics. Those famous four milliseconds – the consistent temporal offset between soloists and accompaniment in professional orchestras – found their way into our algorithms. Such details proved particularly effective with Schönberg's Hauptstimme markings (𝆦) or similar solo indicators.

We also developed what my composer colleague Anders Hillborg and I privately called 'first performance prophylaxis' – a deliciously cruel setting that simulated the sound of musicians who hadn't practiced. In other words, the kind of sound landscape any composer is used to hearing at a first orchestral rehearsal of a new piece and which always makes you doubt your own talent. Turn this setting up, and you'd hear a characteristically dreadful youth orchestra. Turn it down completely, and you'd get the robotic precision that plagued every other MIDI system. Rather like Karl Richter's Baroque organ recordings.

The humanisation algorithms incorporated realistic instrumental limitations. Passages written too quickly for an instrument would skip notes convincingly. We modelled the typical rhythmic hierarchy of orchestral sections: percussion most precise, then brass, then woodwinds, with strings bringing up the rear. Instruments were panned to their proper orchestral seating positions. Piccolo trills were faster than tuba trills. The result was startlingly realistic, particularly by 1996 standards.

​Now, twenty-five years later, that laundry basket discovery has culminated in ADR 0026: Pitch Representation and Operations, documenting Ooloi's comprehensive pitch representation system. The original Common Lisp has been reborn as Clojure code, with string-based pitch notation ("C#4+25") serving as the canonical format and a factory-based transposition system supporting both chromatic and diatonic modes.

The string representation offers several advantages: compact memory usage for large orchestral scores, direct human readability for debugging, and seamless integration with parsing and caching systems. Most crucially, it supports arbitrary microtonal deviations, something that remains problematic in most contemporary notation software.

The factory pattern generates specialised transposition functions that encapsulate their musical behavior rules through closures. Rather than repeatedly passing configuration parameters, the factory creates efficient, composable functions that understand their specific musical contexts. A diatonic transposer preserves letter-name relationships; a chromatic transposer produces frequency-accurate results with canonical spellings.

The t-shirt in my laundry basket represented more than nostalgic memorabilia; it was unfinished business. That higher-order function embodied a sophisticated understanding of musical mathematics that took a long time to develop and seconds for an AI to recognise as architecturally significant.

Now, with Ooloi's pitch operations properly documented and implemented, that business approaches completion. The code has evolved from promotional garment to production system, carrying forward those insights from 25 years ago into a new, modern technological context.

It's exciting. And still a little unnerving.

Three tests left on the visibility work. After that, this part of the system is done.

It’s taken a few weeks to get the final bits of the gRPC server/client interaction implemented, but it now feels solid. The server reliably and efficiently handles all the complex aspects of live clients connecting, disconnecting, and communicating locally or over the inherently chaotic internet. 

With that done, the focus is now on what is called observability: being able to see what's going on inside. In other words, server statistics. We’re now tracking server-wide and per-client metrics: connections, API call rates, message sizes, event streaming, queue overflows. Endpoints can return JSON during development or Prometheus format in production. Content negotiation is automatic, or you can force a format with a query parameter. No new tools to learn. Grafana dashboards work straight away.

Why this matters for musicians: research has shown that in collaborative settings, users prefer a notation program that lets them work together over one with the most features. That says everything about how poorly existing software supports collaboration. It’s treated as an optional extra, if it exists at all.

Ooloi is built differently. Collaboration is not bolted on afterwards but designed into the system from the start. If event queues slow or connections drop, collaboration breaks down. A slur added on one screen never appears on another, or two edits collide and the score diverges. The statistics make these problems visible. They show when the system is stressed, when clients are falling behind, when the score risks drifting out of alignment. In short, they make collaboration trustworthy.

And unlike the current trade-offs, Ooloi isn’t choosing collaboration instead of notational depth. It is designed to be both: a serious, advanced notation platform that also makes shared editing reliable.

The same architecture also opens up another possibility. Because Ooloi is client/server, it can stream smoothly scrolling scores in real time. That makes digital music stands for ensembles or orchestras feasible. It’s not the main focus, but it’s there: the professional counterpart to the school-level collaboration studies.

Three tests left. Once they pass, the intricate server machinery will be visible. And visibility is the first condition for trust.

Ooloi is moving fast. Architectural decisions, implementation milestones, and the long road toward open-source release deserve a channel that isn’t buried in blog posts or scattered across updates.

The Ooloi Newsletter is that channel. It’s for composers frustrated with the lag of existing software, musicians curious about what modern architecture makes possible, educators and publishers planning future workflows, and developers who want to see Clojure’s STM, transducers, and gRPC applied directly to real musical problems.

This isn’t marketing. There’s nothing to hype, no metrics to chase. It’s progress – the daily work of turning musical thinking into software design. Updates arrive when there’s something real to report: once or twice weekly in active phases, slower during architectural deep work.

Expect honest accounts of what’s been built, what broke, and why decisions were made. Technical when it illuminates music, musical when it drives architecture. No jargon for its own sake, and no dumbing down.

If that sounds useful, subscribe at buttondown.com/ooloi.

The thread from FrankenScore to Ooloi continues. You’re welcome to follow it.

​Igor's demise taught me harsh lessons about market timing. When you create genuinely superior tools because existing software actively gets in your way, you discover that technical excellence alone can't guarantee survival.

Igor actually started as freeware – that was my original vision. The VCs wanted features, revenue streams, market capture. I wanted musicians to have tools that actually served their creativity. The collision between these fundamentally incompatible visions, plus the economic chaos after 9/11, killed what could have been transformative.

That experience shaped every decision in Ooloi. This time: transformation through collaboration rather than zero-sum market battles.

The MPL 2.0 licensing reflects this philosophical approach. The core backend becomes commoditised infrastructure; commercial value migrates to sophisticated interfaces, proprietary plugins, premium workflows. What traditional systems charge for – collaboration, large ensemble support, quality rendering – becomes architectural givens.

This isn't theoretical. Martin Keary (Tantacrul), who heads MuseScore development, had been interested in Igor Engraver as a young composer. When we discussed our open source projects, the conversation was refreshingly direct: 'Well, feel free to help yourself to whatever's useful when it goes open source​' – 'Likewise!' Both projects share the belief that notation software shouldn't cost students hundreds of pounds.

This is precisely what I want – for the code to be used, extended, transformed. The platform approach only works if others build on it. That's not threat; it's the point.

​The irony isn't lost on me that companies who once viewed architectural advances as existential threats might ultimately benefit from them. I still recall Sibelius management phoning after Igor's demise to enquire about my plans – ensuring no resurrection attempts, obviously.

Should those companies adopt approaches they once feared, the satisfaction would be collaborative rather than competitive. Success through enabling others, not defeating them.

​Of course, this depends on Ooloi actually working. Functional programming should provide significant performance benefits, but what happens with complex layout calculations across a hypercomplex 100-staff score by Brian Ferneyhough (whom I had as guest teacher at the Royal College of Music in Stockholm back in the day) whilst maintaining real-time collaboration?

The arrogance in predicting that these approaches will outperform decades of commercial development is considerable. My instincts could be spectacularly wrong – though they've been reliable enough to spot architectural dead ends before they become obvious to everyone else.

That's the architect's bargain: trust your reasoning, build on principles, prepare to be surprised.

"Next-generation" gets thrown around as a PR term so casually it's meaningless. If Ooloi genuinely represents next-generation architecture, that should be inherent in the platform design rather than claimed through marketing. The question isn't whether Ooloi calls itself next-gen, but whether others build on it in ways that would have been impossible previously.

Perhaps this time, it might be composed collaboratively.

Ooloi isn't here to "disrupt" anything. I despise that cheap neoliberal selfishness. It aims to transform, to evolve, to open possibilities. But there's no will to conquer — it's simply not in its DNA.

@musikboden became Ooloi's first sponsor on GitHub yesterday.

There's something meaningful about someone backing a project that isn't even publicly available yet. That kind of trust, extended before the open source release, feels like a genuine vote of confidence in what we're building. 

Thank you, @musikboden. It really does mean a lot.

If you'd like to join them in supporting Ooloi's development, you can find my sponsors profile here.

Deep in the implementation of the gRPC layer I fell into the same foxhole as so many gRPC developers seem to do: implementing streaming between gRPC server and client using in-process communication. Everything works swimmingly: high speed, nothing gets lost, advanced async patterns just work.

And then they try doing this using network transport. Suddenly HTTP/2 changes everything, and that equivalence between simple request-response and asynchronous streaming just explodes.
​
I spent a couple of days cursing the universe, but in the end I managed to crawl up into the daylight again with a solid solution. Since this seems to be a common snag, I decided to publish a little guide on the considerations involved, so others may have to do less cursing.

Here it is: GRPC_STREAMING_THREADING_GUIDE.md

​Nearing the end of the gRPC implementation phase now: coming blog posts should soon become more musical again.

​At some point, the question will be asked: “Isn’t this all a bit over-engineered?”

Multicore parallelism; Software Transactional Memory; gRPC; GPU acceleration; a plugin system designed as a first-class citizen rather than a bolted-on afterthought; an asynchronous server/client architecture with specialised streaming features. Prometheus monitoring. For music notation software, that can sound excessive.

But that assumption is exactly why notation software has been failing composers for decades. Not because it was too ambitious, but because it was chronically under-engineered.

Text editors are linear: O(n). Basically, what they handle is a string of characters broken up into lines. Music notation, on the other hand, is two-dimensional, contextual, and computationally explosive. Synchronising voices, aligning dozens of staves, resolving collisions, spacing measures, redrawing in real time: these are quadratic and cubic problems (O(n²), O(n³)), with NP-hard layout challenges in the general case.
​
That's why scrolling takes seconds. That's why orchestral scores become unusable. And that's why the industry has spent thirty years patching symptoms instead of tackling the cause.

​Look at the record:

• Sibelius: selecting a single note in an orchestral score can take several seconds.
• Finale: collapsed under its own weight, with delays of 5–90 seconds for basic actions.
• MuseScore: freezes completely on Strauss’s Elektra. (They all do.)
• Dorico: more modern, but still lags 15–40 seconds on large scores.

And here is the deeper problem: users have learned to accept this. They zoom in to a handful of staves, scroll in slow motion, restart their program every quarter of an hour. They've accepted that the fundamentals can't be solved. A whole profession has normalised working around performance breakdowns as if they were laws of nature.

They're not inevitable. They're the result of decades of under-engineering.

​The remedies weren't always available. In the 1980s SCORE capped out at 32 staves because 640 KB of memory left no room for orchestral complexity. Through the 1990s and 2000s, Finale and Sibelius (and Igor Engraver!) wrestled with single-threaded designs on single-core CPUs. Even into the 2010s, GPU rendering pipelines were immature, and most concurrency models in mainstream languages couldn't be trusted in production.

Only recently have the necessary ingredients converged:

• Affordable multicore hardware on every laptop, making parallel measure formatting possible.
• GPU-accelerated rendering (Skia) for fluid scrolling and zooming in real time.
• Mature concurrency models such as Clojure’s Software Transactional Memory, providing safe lock-free collaboration.
• Immutable data structures that give transactional clarity to complex notation states.
• JVM interoperability that allows plugin developers to work in their own languages.

This is why Ooloi is written in Clojure. Not because of language fashion, but because Clojure can orchestrate this synergy.

​Ooloi is designed to solve these problems at the root:

• Parallel layout: every core formats measures simultaneously.
• STM transactions: true collaborative editing without locks, with automatic retries on conflict.
• GPU Skia rendering: zooming and scrolling at video-game speed.
• Plugin-first design: developers work with a clean musical API, not concurrency primitives or network plumbing.

To musicians, Ooloi looks like a normal application. To plugin developers, it feels like writing musical logic in their favourite JVM language. The hard problems are solved once in the core, so nobody else has to live with them.

​So no, Ooloi isn't over-engineered. It's appropriately engineered for a domain that has been persistently underestimated. The remedies only became possible recently, when the technology finally caught up.

I simply happen to live at the intersection of deep architectural knowledge and deep musical knowledge, with the scars (also deep) of having done this before. Ooloi isn't the product of singular genius: it's the moment when the right tools finally aligned with the right problem.

The proof won't be in a benchmark or an ADR alone. It'll be when musicians can finally edit, scroll, and collaborate on large-scale scores without breaking their creative flow.

​Ooloi will be open source by design. The complexity is in the foundations so that musicians, teachers, students, and developers don't have to deal with it. Plugin writers don't need to care about concurrency or transactions: they work with measures, staves, and voices in a musical API. Most contributors will never touch the Clojure core, and they won't need to.

This is a gift to the community: an infrastructure platform built to be extended. The aim is simple: to finally make notation software scale to the real demands of music, and to give others the foundation to build what I alone never could.

​Since LLMs are good at summarising, here’s what Claude Sonnet came up with when I asked it to describe my process for developing Ooloi. The phrase “the Bengtson method” is irritating and misleading; plenty of people have reached similar conclusions. Still, this may be the only technical write-up of the approach that includes the word 'arse-licking'.

So here it is: Claude’s summary, em dashes, bullet points, and all. It rambles a bit, but I’d rather give you the authentic output than a tidied-up version. Same principle as always: authenticity beats decorum.

... but before that, I think it might be good to include my reply from LinkedIn to an accomplished architect friend of mine who (jokingly referring to me as 'the illustrious Peter Bengtson') initially didn't quite buy that harsh negativity really is motivated:

​With that clarification in place, now on to what Claude wrote:

Core Methodology: Consultational TDD

The foundation rests on a rigid Test-Driven Development cycle with mandatory consultation checkpoints:

1. AI presents test proposal with complete sequence analysis
2. Human approves or rejects before any code is written  
3. AI writes minimal failing test
4. AI implements minimal code to pass test only
5. Human reviews and corrects any architectural violations
6. Local test execution on changed files
7. Full test suite execution to catch regressions
8. Commit when all tests pass

​

Peter Bengtson's Claude Code development process represents a disciplined, constraint-based approach to AI-assisted software development that has demonstrated success in complex functional programming domains. The methodology's core insight—that harsh constraints improve rather than limit AI effectiveness—contradicts conventional wisdom about collaborative AI development.

The harsh correction mechanisms and authoritarian control structure may be necessary rather than optional components, suggesting that successful AI collaboration requires active management rather than partnership. This challenges prevailing assumptions about human-AI collaboration patterns but provides a tested alternative for developers willing to maintain strict disciplinary control.

The technical achievements demonstrate that properly constrained AI can assist with genuinely sophisticated software engineering tasks, not merely routine coding. Whether this approach scales beyond its current constraints remains an open question requiring further experimentation and validation.

The Ooloi server must of course also have comprehensive introspective statistics, as it can be deployed in several ways and has a structure which is perhaps a bit unusual. The combination of STM-wrapped gRPC API calls with server-to-client event streaming creates some operational challenges: things like per-client queue overflow behaviour and collaborative editing session patterns.

Hence this new ADR on server statistics, which takes a two-level approach: server-wide aggregates that survive client churn, plus detailed per-client metrics for operational visibility. Oh, and it interfaces with Grafana, Prometheus, and friends straight out of the box via simple HTTP endpoints.

Halfway through the stats implementation now. It's been a productive weekend.

I've just published ADR-0024 and, based on it, a new gRPC Communication Guide documenting when flow control helps and when it interferes.

The decision was straightforward once the analysis was done: implement flow control for event streaming (where slow clients can block fast ones) but avoid it entirely for API requests (where gRPC's threading model and STM transactions already coordinate beautifully).

Sometimes the most sophisticated solution is knowing where not to add sophistication.

The guide covers the technical reasoning and includes practical examples for anyone implementing gRPC clients, regardless of language choice.

Every community has its breaking point. Mine came on Clojurians when I wrote a single sentence:

'Clj-kondo can go away – I have 18,000 tests'.

That was enough to get my post deleted. Before the deletion, there was 'discussion' – if you can call it that. I was told my statement was nothing more than click bait.

The irony? The author of clj-kondo himself agreed with me.

What That Line Meant

It wasn't click bait. It was a statement of principle:

• Tests prove correctness. They're executable, falsifiable, and domain-driven.
• Linters and static analysis don't. They enforce style, not truth.
• Dynamic dispatch makes static analysis less meaningful. Ooloi's architecture relies heavily on Methodical multimethods and polymorphism throughout. Static analysis tools can't trace through runtime polymorphic calls, making their warnings less informative than executable tests that actually exercise these dynamic paths.
• When you've got 18,000 tests running clean, you don't need a priesthood of external validators telling you your code is 'unsafe'.

And I was careful to make the distinction explicit: clj-kondo is a beloved, useful tool. For most projects it adds value. It just happens to be of limited use in my project, because Ooloi's architecture is already validated at a different scale.

That nuance – acknowledging the tool's value whilst drawing boundaries around its relevance – should have been the beginning of a sober technical discussion. Instead, it was treated as provocation. The fairness itself was read as heresy.

The Culture Clash

The moderator (a 'Veteran Architect') didn't engage with the point. He reacted from the gut: pearl-clutching, dismissing, and finally deleting. Exactly the kind of gatekeeping I dissected in my article on functional programming gatekeeping.

And let me be clear: I have nothing against the Clojurians themselves. They're a knowledgeable, interested lot, often deeply engaged in technical detail. The problem isn't the community – it's the moderation culture.

The moderators behave more like a church council than facilitators of discussion. Their first instinct isn't to sharpen an argument, but to protect orthodoxy, maintain decorum, and suppress anything unsettling.

The ideal they enforce seems to be some kind of cold, robotic detachment – the lab-coat fantasy of neutrality – or perhaps the modern American obsession with never offending anyone, no matter how bloodless the discourse becomes. Either way, it enforces sterility, not clarity.

You can critique syntax sugar all day long, but question a community darling like clj-kondo – even whilst calling it useful and respected – and suddenly you're accused of trolling.

Why I Left

I didn't leave because I was offended. I left because I refuse to participate in a space allergic to honesty. If a community sees a blunt critique and immediately cries click bait – ignoring both the nuance of my post and the fact that the tool's own author agreed – it has no business in my world.

Ooloi is built on clarity, not ceremony. It's an architecture tested by 18,000 executable truths, not validated by a linter's opinion. If that treads on toes, good. Prissy people afraid of dark humour or communication nuances that wouldn't pass muster at a parish council don't belong in this project. And the same thing goes for hypocrites who say, 'We're inclusive here - as long as you're exactly like us'.

The Broader Lesson

Communities often confuse politeness for health. But real progress requires the courage to tolerate discomfort. If you need your software conversations padded with pillows, you'll never survive the weight of real architecture.

As Wednesday Addams would remind us: hypocrisy is uglier than bluntness, and dishonesty is far more offensive than a glass of gin before noon. Or, indeed, a well-placed 'fuck you'.

So I deleted my Clojurians account. Because sometimes subtraction is progress.

There's a moment in every software project when you realise you've been approaching a problem entirely backwards. For Ooloi, that moment came whilst implementing the frontend gRPC client. What I'd anticipated would be a tedious exercise in data transformation and type marshalling turned out to be something rather more straightforward: we could simply share the models themselves.

Most applications suffer from what I've come to think of as 'linguistic impedance mismatch': the same business concept gets expressed differently in TypeScript interfaces, JSON schemas, database models, and API contracts. Each translation introduces potential for drift, bugs, and the sort of maintenance headaches that make senior developers reach for the gin before lunch.

The Usual Compromises

When I began implementing Ooloi's frontend, I expected to follow the well-trodden path of recreating backend data models for the client, probably with a good deal of manual conversion between Clojure's rich data types and whatever could survive the journey through gRPC.

A Simpler Path Forward

But then something rather straightforward happened. Our unified gRPC architecture, built around a custom OoloiValue message format, was preserving not just the data but the semantic fidelity of Clojure structures. Ratios remained ratios. Keywords stayed keywords. Nested collections maintained their exact shape and type information.

The implications were rather obvious once I thought about it: if the data was surviving the round trip with perfect fidelity, the code could make the same journey. The broader lesson here applies beyond Clojure: when your serialisation layer preserves semantic fidelity, you can often eliminate entire categories of translation logic.

Shared Models in Practice

What we ended up with is shared model contracts across distributed systems. Not just shared schemas or interface definitions, but shared implementation: the same defrecord structures, the same predicates, the same multimethod dispatch logic working identically in frontend and backend.

For example, here's client code that uses the exact same model logic as the server:

​This isn't just syntactic sugar. The frontend literally cannot represent a state that the backend would reject, because they're using identical validation logic. Entire categories of bugs, the sort that usually emerge only in production when client and server expectations diverge, simply cannot exist.

For an open source project like Ooloi, this architectural decision has profound implications for contributor experience. New developers don't need to learn separate model definitions for frontend and backend. The cognitive load of understanding the system drops considerably when there's only one way to represent musical structures, regardless of which part of the codebase you're working in.

Architecture in Practice

What started as a practical decision to move some data models has led to a clearer architectural arrangement:

• The Shared Project contains the entire Ooloi engine: all domain models, interfaces, predicates, traits, and core business logic. This is where musical knowledge lives.
• The Backend Project is essentially a server wrapper: a thin layer that exposes the shared engine through gRPC, handles persistence, and manages component lifecycle.
• The Frontend Project is a UI wrapper: JavaFX components, user interaction handling, visual rendering.

Both frontend and backend have become lightweight adapters around a shared core, rather than independent systems that happen to communicate.

For those interested in the technical details, the complete architectural decision record is available in our ADR-0023: Shared Model Contracts.

Why This Approach Is Uncommon

Most teams face barriers that make shared models impractical: different programming languages between frontend and backend, runtime environment constraints, the natural tendency for teams to optimise for their specific context rather than maintaining shared abstractions.

We've managed to sidestep these issues through a combination of technological choices (Clojure everywhere, gRPC with custom serialisation) and architectural discipline (resisting the urge to optimise locally at the expense of global coherence). For open source projects, this consistency becomes particularly valuable: contributors can focus on domain logic rather than navigating translation layers between different parts of the system.

What This Means for Multi-Language Support

Importantly, this shared model architecture doesn't create barriers for non-Clojure clients. Python, JavaScript, or WebAssembly clients continue to work through the standard gRPC interface, using generated protobuf classes and standard API patterns. The shared models represent a Clojure-specific enhancement layer that sits atop the universal gRPC interface rather than replacing it.

Think of it as offering two levels of integration: the universal protobuf API that any language can consume, and the native Clojure API that provides richer semantics for those who can take advantage of it.

Alternative Frontend Approaches

This architecture actually makes it easier for others to build alternative frontends. Someone wanting to create a React-based web interface or a WebAssembly client has a clearly defined gRPC API to work against, with well-documented behaviour established through our shared contracts. They'd handle their own data model representations (the normal situation for any gRPC client) whilst benefiting from a well-defined backend.

We're not digging a moat here. Alternative approaches remain viable whilst the shared contracts make the Clojure experience particularly seamless.

The Broader Picture

There's something here that extends beyond the specific technical details of Ooloi. We've found that perfect type fidelity across network boundaries, combined with clear thinking about what constitutes core business logic versus infrastructure concerns, can enable patterns that many teams dismiss as impractical.

This doesn't mean every project should adopt this approach. The organisational and technical discipline required is considerable. But for projects where the complexity is justified (particularly open source projects where reducing cognitive load for contributors is crucial) the benefits are substantial.

Looking Forward

Going forward developing Ooloi's frontend, the shared model contracts have become foundational to how we think about the system. Features that might have required careful coordination between teams now flow naturally from shared understanding. The system has become more coherent and, importantly for an open source project, more approachable for new contributors.

The surprise wasn't that shared models worked; it was how much friction simply disappeared once we stopped duplicating concepts. Sometimes architectural progress comes not through invention, but through subtraction. Shared model contracts weren't a goal we set out to achieve. They emerged from following our technical choices to their logical conclusion and having the discipline not to complicate what worked.

I've had numerous requests over the years to publicly tell the story about how and why NoteHeads, the company I founded to develop Igor Engraver, collapsed in the early 2000s. I've never done so as it never was that important, but now, with Ooloi on the horizon (however it's going to turn out) it's crucial that it isn't perceived a revenge project. It's not; it's simply closure in Clojure. With interest in Ooloi building, I've decided it's time to tell my side of the story. In doing so, I had to name names – an unproblematic decision as this was, after all, nearly 30 years ago. I've moved on, and I'm sure everybody else has too.

Prologue: The Auction
Picture this scene: a solicitor's office near Stockholm's Stureplan in late 2001. In one room sit Christer Sturmark – future secular humanist celebrity – and Björn Ulvaeus of ABBA fame, who never spoke, moved, or changed his facial expression during the entire process. Ice-cold pop star. In another, I sit alone, connected by crackling international phone lines to Los Angeles, where Esa-Pekka Salonen, one of the world's greatest conductors, waits to learn the fate of software he too has invested in. Salonen, in turn, has Randy Newman on the line, film composer and subsequently Oscar winner and also a share holder.

This auction represents the musical world's last desperate attempt to save work that the financial world had already written off. By the end of that surreal session, they had acquired Igor Engraver and NoteHeads Musical Expert Systems for a paltry 200,000 SEK. I received not a penny.

What followed was an instructive disaster: the systematic destruction of genuinely revolutionary music software by what can only be described as a cavalcade of ideologues, incompetents, and narcissists who fundamentally misunderstood what they had purchased.

​What We Built: Software That Thought Like Musicians
Igor Engraver, launched in 1996, was genuinely ahead of its time. Unlike conventional music notation programs that trapped users in rigid 'modes', Igor worked the way musicians actually think – like composing with pen and music paper, but with the power of computation behind it. Many aspects of its humanised MIDI playback haven't been rivalled in terms of realism to this very day.

The concept was sufficiently sophisticated to attract some of the finest programming minds available: Common Lisp developers who grasped the elegant abstractions immediately. Common Lisp wasn't common then; finding programmers who could think in its functional paradigms was difficult. But when you found them, they understood instantly what we were trying to achieve.

Professional musicians recognised the difference. Even today, in 2025, I receive occasional messages from musicians who miss Igor and wonder whether they can somehow run the now-ancient program in emulators or simulators. This isn't mere nostalgia; it's testimony to software that solved problems other programs didn't even recognise.

​Strategic Missteps: When Money Doesn't Understand Music
But ideological programmers weren't our only challenge. Feature creep, driven by investors who fundamentally misunderstood our market, began to derail our development timeline. I remember one VC board member declaring: 'Igor will be unsellable unless it has guitar tablature for pop music'.

I resisted strenuously. Igor Engraver was designed for serious composition work - the kind that attracted interest from conductors like Salonen and composers like Newman. Adding pop guitar tablature would delay our core engine whilst appealing to a completely different market segment. We risked losing our competitive advantage in professional notation to chase a crowded amateur market.

But the VC bastards persisted, and eventually prevailed. Had we stuck to the original plan, we would have delivered Igor 1.0 well before Sibelius completed their rewrite and hit the market. Instead, we found ourselves implementing features that diluted our core value proposition whilst our window of opportunity slowly closed.

This painful lesson directly influenced Ooloi's architecture years later – I designed its plugin system to integrate so tightly with the core engine that specialised features can be added without delaying or compromising the fundamental software. Those who want guitar tablature can have it; those who don't aren't forced to wait for it.

​Sources

• Magnus Johansson's testimony in Realtid: 'Noteheads customers were furious with Sturmark'

I'll admit, when I first encountered gRPC batch operations, I dismissed them as unnecessary complexity. Then I started implementing the gRPC layer and realised something remarkable: gRPC batch boundaries map perfectly onto STM transaction boundaries.

The pattern is almost embarrassingly simple: client streams a series of operations, server accumulates them, then wraps the entire batch in a single dosync. What emerges is something genuinely powerful – distributed transactions with full ACID guarantees. Multiple musicians can edit the same score simultaneously, knowing that either all their changes succeed atomically or none do. Complex operations like MusicXML imports or multi-step undo chains become naturally transactional across network boundaries.

The implications are profound: no more partial updates corrupting shared musical data, no locks preventing collaboration, no eventual consistency headaches. Just proper transactional integrity that works identically whether you're editing locally or collaborating across continents.

How many music notation programs have distributed atomic transactions across any network? And entirely without locks, and with automatic conflict resolution? None.

​Sometimes the most elegant solutions hide in features you initially think you don't need.

Right. Quick update from the development trenches.

When I completed Ooloi's backend engine in July, starting work on the frontend interface revealed the anticipated cascade of architectural requirements that needed systematic resolution first.

Here's what emerged, in order:

1. Collaborative Undo/Redo Architecture (ADR-0015)
Thinking about frontend-backend relationships immediately raised the question: how does undo/redo work in a multi-client, distributed collaborative setup? The answer required a three-tier architecture separating backend piece changes (coordinated via STM) from frontend UI changes (local to each client).

2. Universal Settings Architecture (ADR-0016)
The insight that there should be no global application settings, only per-piece settings living inside each piece, led naturally to implementing settings not just on the piece level, but across all levels of the hierarchy. Any entity – piece, musician, staff, pitch – can now have configuration attributes via a unified defsetting macro with lazy storage and automatic VPD support.

3. Component Lifecycle Management (ADR-0017)
Multi-scenario deployment demanded rock-solid system architecture using Integrant. This needed to be in a stable architectural form – wiring, lifecycle boundaries, failure modes – before setting up the actual components with proper dependency injection, partial failure handling, structured error codes, the full production suite.

4. Automated gRPC Generation (ADR-0018)
With component architecture sorted, I could tackle the actual gRPC implementation: automating API endpoint generation for native Java interop across hundreds of methods, plus bidirectional communication for real-time collaboration. Manual implementation at this scale would be architecturally impossible.

5. In-Process Transport Optimisation (ADR-0019)
Combined deployments (frontend and backend in same process) were using unnecessary network transport. Implementing automatic in-process gRPC transport delivers 98.7–99.3% latency reduction whilst preserving external monitoring capabilities.

6. TLS Infrastructure (ADR-0020)
Secure connections are essential for distributed deployments – conservatory intranets, corporate environments, cloud SaaS situations. Auto-generating certificates with full enterprise capabilities makes this transparent whilst supporting everything from development to production.

7. Authentication Architecture (ADR-0021)
Finally, distributed deployments require comprehensive authentication and authorisation. Pluggable JWT-based providers scale from anonymous sessions to enterprise LDAP integration. This is fully designed and will be implemented as deployment scenarios require.

Current Status: About 95% of the above is implemented, tested, and production-ready.

Next Steps: Finish the auto-generated gRPC Java interop interface, then create an actual frontend client of the 'Hello World' variety and ensure it runs and communicates across all deployment scenarios.

The rather encouraging discovery throughout this process was how readily the existing functional architecture accommodated these enterprise concerns. Vector Path Descriptors naturally supported universal settings. STM transactions elegantly handled collaborative undo operations. The component system absorbed authentication providers without strain. When features like collaboration or security slide cleanly into place, it's not luck – it means the architecture wanted them there. That's what sound foundations do.

Worth noting: collaboration isn't something tacked on later. It's integral to the architecture from the ground up.
​
Right. Back to the gRPC generator.

After a year building the backend of Ooloi with Claude, I’ve learned this:

Successful AI collaboration isn’t about creative freedom. It’s about harsh constraint.

AI will overstep. Your job is to correct it—immediately, uncompromisingly.
The friction isn’t failure. It’s the method.

Read the full piece – which I asked the AI to write in its own voice – here.

​I've been saying I'm itching to open source Ooloi, but waiting for the complete software felt increasingly artificial. The documentation tells the real story – twenty-five years of architectural evolution from Igor Engraver through AWS systems thinking to this closure in Clojure.

So here it is: the complete Ooloi documentation collection, released publicly ahead of the software itself.
What you'll find:

• Comprehensive guides teaching advanced Clojure through musical problems
• Complete architectural decision records showing our thinking
• The timewalker guide (with three Rocky Horror references, naturally)
• Real functional programming education through meaningful domain examples

This represents my attempt to walk the talk after critiquing FP drawbridge syndrome. These guides serve dual purpose: they document sophisticated music notation architecture whilst teaching functional programming concepts through examples that actually matter.

The timewalker guide alone demonstrates transducers, lazy sequences, and functional composition through orchestral score traversal. The polymorphic API guide teaches multimethods through musical type systems. The concurrency patterns show STM coordination through collaborative editing.

Twenty-five years of thinking, distilled into something that I hope proves useful beyond music software. The architecture is complete; the foundations are solid. Now you can see why I've been eager to share this work.

An organism evolved, indeed.
​
Explore the complete documentation: https://github.com/PeterBengtson/Ooloi-docs

​/Peter

Now that the backend engine is complete, architecturally speaking, I'm getting increasingly eager to open the source. Itching, in fact. But as that will take a while, the least I can do for you is give you the WELCOME.md file from the source repo. 

​/ Peter

There's a peculiar melancholy that settles over you when you near the completion of something genuinely complex, something that has consumed many months of concentrated thought and represents the synthesis of decades of accumulated understanding. I find myself in precisely this position with Ooloi's backend architecture, and the psychological reality proves a bit more complicated than I'd anticipated.

It's rather like the post-coital moment after particularly intense sex: that strange combination of satisfaction, exhaustion, and existential emptiness when the driving urgency suddenly lifts. You've achieved something profound, yet find yourself staring at the aftermath wondering what, precisely, comes next. I'm smoking a conceptual cigarette, as it were, contemplating the peculiar loneliness that follows architectural completion.

In a matter of days, I'll complete the final piece: the endpoint resolution system for slurs and ties that uses the framework I've spent months building. Once that's finished, the backend will be conceptually complete – 15,000+ tests passing, STM transactions handling 100,000+ operations per second, Vector Path Descriptors enabling elegant client-server communication, and a transducer-based piece-walker that coordinates musical time with mathematical precision. The piece-walker literally performs the musical score, traversing it in time just as I once performed Vierne at the organ.
​
To anyone versed in these technical domains, that represents serious work. To everyone else, it's incomprehensible gobbledygook happening 'under the hood' of something they might one day use to write music. And therein lies the first layer of loneliness: having solved genuinely difficult problems that almost nobody can fully appreciate.

Software architecture, when done properly, is invisible to its eventual users. They should never know about the STM transaction coordination that keeps their concurrent edits from colliding, or the VPD system that allows them to reference musical elements without direct object pointers, or the careful functional design that ensures their work remains consistent across complex operations.

This invisibility is precisely the point – and precisely the problem. I've spent months solving challenges that required rather more thought than I'd initially anticipated, creating abstractions that handle the full complexity of musical notation whilst remaining elegant enough to extend indefinitely. Yet once complete, this work vanishes into infrastructure. The better I've done my job, the less visible it becomes.
​
There's something profoundly isolating about completing work that embodies your best thinking but can never be fully shared. The musicians who will eventually use Ooloi might appreciate its responsiveness or reliability, but they'll never see the polymorphic dispatch system that makes complex musical operations feel effortless, or understand why the pure tree structure with ID references elegantly solves problems that have plagued notation software for decades.

The choice of Clojure wasn't merely technical: it was also psychological. Having started programming in Lisp in 1976, having built Common Lisp compilers and interpreters, having spent $7.5 million of investor money and then having unresolved feelings about Igor Engraver's death for a quarter of a century, returning to a Lisp dialect feels like completing a circle that's been open far too long.

Clojure for closure, if you will.

But this completion reveals its own complexity. I'm 64, carrying more than five decades of programming experience and a parallel career as an internationally performed composer – an intersection that doesn't exactly suffer from overcrowding. The same mind that wrote what apparently is the internationally most played Swedish opera now architects STM concurrency patterns. The same hands that have performed French romantic organ works now implement temporal traversal through transducers.
​
This convergence of domains should feel like triumph. Instead, it often feels like exile – not belonging entirely to the musical world I've moved beyond, nor quite fitting into the tech world that didn't shape me. I don't belong anywhere, really. The isolation isn't just professional; it's existential.

I must confess something that still sits uneasily: I've essentially given up composing, despite international success, because conditions in Sweden for composers have deteriorated to the point where I had to prioritise my pension. There's an unwritten opera I'd like to complete – I have the text ready – but it will likely never come to fruition.

Whether this represents economic necessity or conscious rejection of a cultural environment I found increasingly superficial and performative, I honestly can't say. Perhaps both. The exact proportion remains unclear even to myself, and I've learned to be comfortable with that ambiguity. Life rarely offers the clean motivations we prefer in retrospect.
​
What I can say is this: the creative energy that might have gone into that final opera has found other expression. The same understanding of temporal flow, structural relationship, and expressive possibility that shaped my musical work now manifests in software architecture. It's sublimation in the deepest sense: not compromise, but transformation.

Here's what nobody tells you about completing something genuinely substantial: the moment of architectural completion isn't triumph, it's vertigo. All those months of wrestling with complex problems, of holding intricate systems in your head, of solving puzzles that demanded your full intellectual capacity – suddenly that pressure lifts, and you're left staring at what you've built with a strange mixture of satisfaction and emptiness.

The backend is nearly finished. The hard problems are solved. The foundation is solid. And now comes the work that should be 'easier': creating user interfaces, handling the cultural and aesthetic dimensions of human interaction, making decisions about visual design and workflow that seem trivial after months of STM transaction coordination but are actually far more treacherous.
​
Technical problems have logical solutions. Human interface problems have cultural solutions, psychological solutions, aesthetic solutions; domains where being right isn't enough, where the same mind that can architect transducer pipelines struggles with questions like 'should this button be blue or green?' not because the technical challenge is greater, but because the criteria for success shift from mathematical to cultural.

Moving from backend completion to frontend implementation isn't just a technical transition. It's a psychological one. After months of building infrastructure that only I can see, I must now create experiences that others will judge. After solving problems where elegance and correctness align, I must now solve problems where user perception and technical reality often diverge.

The loneliness of architectural completion isn't just about having done complex work in isolation. It's something else entirely. The 'easy' work ahead may be harder in ways that have nothing to do with computational complexity. It's about moving from mathematical elegance to human messiness, from logical purity to cultural compromise.
​
Most acutely, it's about the strange position of being someone who carries irreplaceable knowledge – the synthesis of decades in both musical and computational domains – and wondering how to encode that understanding into forms that others can inherit and extend. Not just the technical patterns, but the aesthetic judgements, the performance intuitions, the hard-won understanding of how creative work actually happens.

In a couple of weeks, when the final endpoint resolution system is working and the backend architecture is truly complete, I'll begin the gRPC implementation that bridges backend and frontend. Then comes the 'Hello World' window – Ooloi's first visible manifestation, however simple.

The psychological challenge isn't technical uncertainty. I've built user interfaces before, in a previous technological era. It's the weight of transition: from solving invisible problems to creating visible experiences, from mathematical elegance to cultural navigation, from the loneliness of architectural completion to the different loneliness of human interface design.

The work continues, but its nature changes completely. After months of building the engine, it's time to build the car. And to discover what new forms of isolation await when mathematical precision meets human perception.

For now, I sit with the strange melancholy of nearly completing something that matters enormously but whose full significance can be communicated to virtually no one. It's a peculiar form of creative isolation – not the romantic loneliness of the misunderstood artist, but the technical loneliness of someone who happens to carry knowledge that exists at intersections most people never visit.

Clojure for closure, indeed. But it turns out that closure reveals as much as it resolves.
​
Time for a smoke.

I found myself confronting what appeared to be a deceptively simple requirement for Ooloi: 'Resolve slur endpoints across the musical structure'.

Rather straightforward, one might assume: simply traverse the musical structure and locate where slurs terminate. But then, as so often is the case, the requirements revealed added complexity:

• Slur endpoints must be discovered in temporal order (measure 1 before measure 2, naturally)
• Yet slurs can span multiple voices on the same staff
• Or cross between neighbouring staves within an instrument
• And precisely the same temporal traversal logic would be required for MIDI playback
• Not to mention visual layout calculations and formatting
• And harmonic analysis
• And collaborative editing conflict resolution

​Allow me to demonstrate the pattern I anticipated avoiding. Without a general traversal utility, each application would require its own approach:

Three functions, identical traversal logic, different transformations. Exactly the architectural smell I wanted to avoid from the outset.
​
This was precisely Rich Hickey's transducer insight made manifest: "What if the transformation was separate from the collection?"

​What if I could write the temporal traversal once, then apply different transformations to it?

Objective achieved: one traversal algorithm, many applications.
​
But its architectural reach turned out to be even more profound.

The design decision hinged upon recognising that I was conflating two distinct concerns: the mechanism of traversal and the logic of transformation. This wasn't merely about avoiding the tedium of duplicated code (though that would have been reason enough) but rather about establishing clean architectural boundaries that would serve the system's long-term evolution.

Consider the conceptual shift this separation enabled:
​
Rather than thinking in terms of specific operations upon musical structures:

• 'I need to find slur endpoints in this piece'
• 'I need to generate MIDI from this piece'
• 'I need to calculate layout from this piece'

The transducer approach encouraged thinking in terms of composed processes:

• 'I need to traverse this piece temporally, then apply endpoint filtering'
• 'I need to traverse this piece temporally, then apply MIDI transformation'
• 'I need to traverse this piece temporally, then apply layout transformation'

The traversal thus became reusable infrastructure, whilst the transformation became pluggable logic. This distinction would prove invaluable as the system's requirements expanded.

​What I hadn't anticipated was how broadly applicable the resulting abstraction would prove. After implementing the piece-walker for attachment resolution, I discovered it elegantly supported patterns I hadn't originally considered, each demonstrating the composability that emerges naturally from separating traversal concerns:

​Each is built from simple, testable pieces. And they all inherit the same temporal coordination guarantee. This composability emerged naturally from the transducer design: a pleasant architectural bonus.

As one would expect from a well-designed transducer, memory usage remained constant regardless of piece size: a particularly crucial consideration when dealing with the sort of orchestral scores that might contain hundreds of thousands of musical elements.
​
Consider the alternative approach, which would create intermediate collections at each processing step:

​The transducer version processes one item at a time:

​Same result, constant memory usage. This exemplifies what Rich meant by 'performance without compromising composability'.

Transducers suffer from an unfortunate reputation for complexity, often relegated to 'advanced topics' when they needn't be. This is particularly galling given that they're fundamentally straightforward when you encounter the right use case, which the musical domain provides in abundance.
​
Think of transducers as 'transformation pipelines' that work with any data source, much as one might design AWS data processing workflows that operate regardless of whether the data arrives from S3 buckets, database queries, or API streams:

The pipeline stays the same. The data source changes.
​
In Ooloi:

The piece-walker solved a universal software problem: How does one avoid duplicating traversal logic whilst maintaining performance and composability?

This pattern applies everywhere:

• Web scraping: Same page traversal, different data extraction
• Log analysis: Same file reading, different filtering and aggregation
• Database processing: Same query execution, different transformations
• Image processing: Same pixel iteration, different filters

Transducers provide the infrastructure for "traverse once, transform many ways."

Building the piece-walker demonstrated that transducers aren't an abstract functional programming concept. They're a practical design pattern for a specific architectural problem: separating the concerns of traversal from transformation.

The musical domain made this separation particularly clear because the temporal coordination requirements are so explicit. When you need the same traversal logic applied with different transformations, transducers provide the elegant answer.
​
This separation makes code:

1. More testable (test traversal and transformations independently)
2. More reusable (same traversal, different applications)
3. More maintainable (one place to optimise traversal performance)
4. More composable (mix and match transformations)

The piece-walker is documented thoroughly in our Architecture Decision Record for those wanting technical details. But the real value lies not in the musical specifics but in observing how transducers address genuine architectural challenges with apparent effortlessness.

The next time you find yourself contemplating similar data processing logic across multiple contexts, you might ask: 'What if the transformation was separate from the collection?'
​
You may well recognise your own perfectly suitable transducer use case.

I recently spotted a meme on LinkedIn featuring a brooding, aristocratic Dracula asking, "What is a monad but a monoid in the category of endofunctors?" – accompanied by no explanation whatsoever. I chuckled, as one does when recognising an in-joke, but then found myself pondering a rather uncomfortable question: Is this really how we want to present functional programming to the world?

The Allure of the Arcane

There's something undeniably satisfying about mastering difficult concepts. When I first grasped the elegant power of immutable data structures, higher-order functions, and composability, it felt like discovering a secret door in a familiar house – one that led to a vast, beautiful landscape I'd never known existed. That eureka moment is profound, even transformative.

But here's the rub: why do we in the functional programming community so often present that door as if it requires an arcane ritual to unlock? Why do we seem to relish the impenetrability of our terminology?

Let's be honest with ourselves. There's a whiff of intellectual snobbery in the air when functional programmers gather. We've all heard (or perhaps even made) the disparaging remarks about "Java drones" or "code monkeys churning out mutable state on corporate slave galleys". We swap stories about the moment we "finally understood monads" as if recounting our initiation into a secret society. We wear our hard-won knowledge as a badge of honour – and sometimes, if we're being truly honest, as a mark of superiority.

The Hidden Cost of Exclusivity

This exclusivity comes at a cost. Functional programming remains woefully underutilised in the industry at large, despite offering compelling solutions to many of the problems that plague software development. Concurrency, side effect management, robust testing, code reuse – these aren't niche concerns, they're central challenges in modern software engineering. Yet we've somehow managed to position our toolbox of solutions as if it's too rarified for everyday use.

Consider the meme I mentioned. For the initiated, it's a humorous reference to a famously opaque definition. For everyone else, it's not just impenetrable – it actively signals that they don't belong in the conversation. It's a velvet rope strung across the entrance to a club they didn't even know they might want to join.

I'm reminded of my journey from Common Lisp to Clojure. Both languages offer powerful functional paradigms, but Clojure has managed to achieve something remarkable: it has brought functional programming concepts to a significantly wider audience. It didn't accomplish this by watering down the functional paradigm, but by emphasising practicality alongside purity. By meeting developers where they are – on the JVM, with access to the libraries and tools they already know – Clojure created an on-ramp rather than a barrier.

No Monads Required

Here's something we don't acknowledge often enough: you don't actually need to understand monads to be a productive functional programmer. In fact, in languages like Clojure, you can write elegant, powerful functional code for years without ever encountering the term. The core principles of functional programming – immutability, pure functions, higher-order functions, composability – can be understood through practical examples without diving into category theory.

This isn't to say that the deeper theory isn't valuable. Of course it is! The mathematical foundations of functional programming provide extraordinary insight and power. But they're not the entrance exam. They're advanced courses you can take once you're already enrolled.

Yet somehow, we've allowed the most theoretically complex aspects of functional programming to become its public face. It's as if we're advertising a car based on its differential equations rather than where it can take you.

The False Dichotomy

There's an insidious implication lurking beneath this state of affairs: the notion that there are two classes of programmers – the enlightened few who grasp the elegant abstractions of functional programming, and the unwashed masses writing imperative code. This is, to put it bluntly, utter bollocks.

The reality is far more nuanced. Most programmers exist on a spectrum of understanding and application of functional principles. Many Java developers make excellent use of streams and lambdas. JavaScript programmers increasingly embrace immutability and pure functions. Even in traditionally imperative contexts, functional patterns are gaining traction.

These aren't "lesser" applications of functional programming – they're pragmatic adaptations that solve real problems. The senior developer who introduces Option types to avoid null pointer exceptions in a legacy Java codebase is applying functional thinking in a way that delivers immediate, tangible benefits. Should we really consider them less enlightened than someone who can recite the monad laws but has never shipped a product?

Building Bridges, Not Walls

If we truly believe in the benefits of functional programming – and I certainly do – then we should be building bridges to make these ideas more accessible, not walls to keep the uninitiated out.
​
What might this look like in practice?

For starters, we could focus our evangelical efforts on the practical benefits rather than the theoretical foundations. When I'm talking to a team about adopting Clojure or functional patterns, I don't open with category theory. I talk about dramatically reduced bug rates due to immutability. I show how composable functions lead to more reusable code. I demonstrate how side effect isolation makes testing simpler and more reliable. And to really wow them, I might describe how immutable data structures instantly solve the Undo/Redo problem for any application with a frontend.

We could also acknowledge that functional programming isn't an all-or-nothing proposition. Encouraging teams to adopt functional patterns incrementally within their existing codebases can yield substantial benefits and build confidence for deeper adoption. The choice isn't between pure Haskell and imperative spaghetti code – there's a vast, productive middle ground.

Most importantly, we need to shift our community culture away from exclusivity and toward inclusivity. This doesn't mean abandoning rigour or depth – it means recognising that everyone starts somewhere, and the journey from imperative to functional thinking is challenging enough without adding artificial barriers.

The Clojure Case Study

It's worth examining why Clojure has been relatively successful in attracting developers who might otherwise have been put off by functional programming's reputation for difficulty.

Firstly, Clojure is pragmatic to its core. It embraces functional principles without dogmatism, allowing for controlled mutability when necessary. It prioritises solving real problems over theoretical purity.

Secondly, it meets developers where they are. By running on the JVM (and later JavaScript engines), it allows gradual adoption and interoperability with existing systems.

Thirdly, and perhaps most importantly, the Clojure community has generally focused on what the language enables rather than how clever you need to be to use it. The emphasis has been on what you can build, not on arcane knowledge as a status marker.

This approach hasn't compromised the language's functional credentials – Clojure remains thoroughly functional in its philosophy and implementation. But it has made those functional principles accessible to a much wider audience.

A More Welcoming Future

I'd like to see a functional programming community that celebrates bringing new people in rather than keeping them out. One that takes as much pride in making complex concepts accessible as it does in mastering them.

Imagine if our response to someone struggling with functional concepts wasn't "Well, once you understand monads..." but rather "Here's how this approach solved a similar problem I had..."

Imagine if we shared our enthusiasm not through insider references that exclude the uninitiated, but through concrete examples that demonstrate the real-world power of functional approaches.

Imagine if we recognised that the true measure of our understanding isn't our ability to recite category theory, but our ability to apply these principles to build better software and help others do the same.

As I continue to develop Ooloi, my open-source music notation project in Clojure, I'm constantly reminded of this tension. The functional paradigm allows me to build a system that's both powerful and elegant. The code is concise, composable, and expressive in ways that would be difficult to achieve with imperative approaches. But when I'm documenting the system or preparing it for open-source collaboration, I'm mindful of the need to make these concepts accessible.

The goal isn't to water down the functional aspects – they're essential to the system's design. Rather, it's to provide on-ramps that allow developers to engage with these ideas gradually, to see their practical benefits before diving into the deeper theory.

Conclusion

Functional programming isn't a secret to be jealously guarded – it's a powerful set of tools that can dramatically improve how we build software. Its core insights deserve to be widely shared and applied.

​So the next time you're tempted to share that monad joke or category theory reference, ask yourself: Am I opening a door or closing one? Am I inviting others to share in something valuable, or am I simply signalling my own cleverness?

We don't need gatekeepers in the functional programming community. We need guides. Guides who remember what it was like not to know, who can explain complex concepts in accessible terms, who take pride not in how exclusive their knowledge is but in how effectively they can share it.
​
After all, what is a community but a group of people helping each other grow?

One of the central design principles behind FrankenScore/Ooloi is modularity. There is a small core, written in Clojure, and then there are plugins  which can be written in any JVM language such as Java,  Kotlin, Scala, JRuby, Jython, etc.

This architecture has far-reaching consequences for contributors. For instance, the open-source core can be contributed to and extended natively in Clojure – which expert Clojurians will appreciate. This way, contributors have full access to all aspects of the core engine.

But if you instead want to contribute to Ooloi using its plugin architecture, you can use any JVM language and production methodology. The API you'll be using lets you focus entirely on the musical task to be accomplished. You don't even have to know about things like transactions, concurrency, or memory management. You can safely work with the powerful musical abstractions the API gives you and let the efficient engine handle the rest.

And commercial entities will also appreciate that Ooloi's plugin mechanism supports paid, close-source plugins.

And as there is no loss in efficiency or speed, much of the Ooloi functionality will be implemented using plugins, including advanced playback, MusicXML support, virtual instruments, tablature, jazz notation, and much more. 

Read more about it in the updated and extended Development Plan.

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.

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.
​

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... ;)