Jonathan Lalou's Blog

Posts Tagged ‘FunctionalProgramming’

Lecturer

Dustin Getz is the founder of Hyperfiddle and the primary architect behind Electric Clojure. His professional mission is to “collapse to zero” the cost of internal frontend development for business applications. With a background in distributed systems and concurrency, Dustin has spent years researching how to apply these low-level technical concepts to higher-level UI infrastructure. He is a frequent speaker at Clojure conferences, where he demonstrates how rethinking the computational structure of web applications can eliminate the complexities of traditional client-server architecture.

Abstract

Electric Clojure represents a paradigm shift in web architecture, moving away from the traditional separation of frontend and backend towards a unified, cloud-connected model. This article explores how Electric frames the user interface (UI) not as a series of manual network requests and state updates, but as a concurrency problem solvable through “differential dataflow”. By applying process supervision and structured concurrency, Electric achieves a UI = f(state) model that remains consistent across the network boundary. Through an analysis of Electric’s core principles, this article highlights how it addresses the “supervision problem” and optimizes network traffic through automatic differential updates, ultimately simplifying the development of complex, data-heavy applications.

Rethinking the Computational Structure of UIs

The fundamental premise of Dustin Getz’s work is that modern UI development is hindered by an incorrect computational structure. Most web applications rely on a manual bridge between the client (browser) and the server, involving REST or GraphQL APIs, manual state management (like Redux), and complex error handling for network failures.
Electric proposes a different structure based on differential dataflow. While React introduced the idea that the UI is a function of state, it is typically confined to the browser. Electric extends this concept across the entire network. In an Electric application, the code is written as a single, continuous program where the compiler automatically determines which parts of the code should run on the server and which should run on the client.

Solving the Network Boundary Problem

The “network boundary” is where most web applications fail or become overly complex. Electric addresses this by treating the connection between the client and server as a reactive data stream. Key innovations include:
1. Automatic Differential Updates: Instead of sending entire data objects over the wire, Electric only transmits the “diffs”—the specific changes in state. This high-frequency, high-fidelity communication is essential for maintaining a responsive UI in data-intensive environments.
2. Process Supervision: Electric applies Erlang-style supervision trees to UI components. If a server-side process fails or a network connection drops, the system can automatically recover and resume the UI state, solving the supervision problem that plagues traditional distributed web apps.
3. Reactive Back-pressure: By integrating differential dataflow, Electric manages the speed of data flow. If the client cannot keep up with the server’s updates, the system applies back-pressure to ensure the application remains stable and doesn’t “clobber” the browser’s resources.

Code Sample: Unified Frontend/Backend

(e/defn MyComponent [id]
  ;; This part runs on the server (accesses DB)
  (e/server
    (let [user (db/find-user id)]
      ;; This part runs on the client (renders UI)
      (e/client
        (dom/div
          (dom/h1 (str "Hello, " (:name user)))
          (dom/p "This data came directly from the DB!"))))))

Implications for Internal Tools and Enterprise Scaling

Dustin identifies a massive opportunity for this architecture in internal enterprise applications. Companies with thousands of microservices often struggle to build scalable UIs that can aggregate data from multiple sources. By placing an Electric “agent” in each microservice, developers can call backend Java or Clojure functions directly from a UI as if they were local calls.
This “UI Spreadsheet” model, as Dustin describes it, allows for native navigation of backend data structures. During his demonstration, he shows how a UI can query a git repository using the Java Git API (JGit) in real-time, displaying a git log through a scalable data browser without a single manually-written API endpoint. This approach collapses the traditional tiers of web development into a single, cohesive abstraction that composes across microservice boundaries.

Links:

• Electric Clojure: Differential Dataflow for UI (Lecture)
• Hyperfiddle Official Website
• Electric Clojure GitHub

Lecturer
Aicha Laafia is a Java software engineer at Havana Group, currently based in France while originally from Morocco. She is passionate about sustainable technology, green programming, and advocating for greater representation of women in tech. Aicha actively participates in various communities, serves as a Women Techmakers and Girls Code ambassador, and facilitates IAmRemarkable workshops. She was recently promoted to Oracle ACE Associate, recognizing her contributions to the Java ecosystem.

Abstract
In this engaging session from Voxxed Days Amsterdam 2026, Aicha Laafia explores significant enhancements to Java’s stream processing capabilities and string handling introduced in JDK 25. She addresses longstanding pain points with traditional streams—such as the inability to maintain state mid-pipeline, complex custom collectors for batching or sliding windows, and error-prone string concatenation for SQL, JSON, or logs—through the new Stream Gatherers API and String Templates. Drawing on live code demonstrations and relatable examples from Formula 1 racing data, the presentation illustrates how these features introduce memory and statefulness to streams, simplify data transformations, and promote safer, more readable code. The talk underscores Java’s continued evolution toward more expressive and maintainable programming paradigms, encouraging developers to upgrade and share knowledge about these advancements.

The Persistent Challenges with Traditional Java Streams

Java developers have long appreciated streams for producing cleaner, more declarative, and expressive code compared to imperative loops. However, as Aicha points out, streams can occasionally leave programmers feeling frustrated or even “like complete idiots” when attempting advanced operations. The core limitation stems from the stateless nature of intermediate operations like map, filter, or flatMap. Each element processes independently and is immediately forgotten, making it impossible to track accumulated state, create overlapping windows, or group data mid-pipeline without terminating the stream via a collector.

Common pain points include manual batching implementations that rely on counters, lists, and careful index management to avoid off-by-one errors or lost elements. Grouping overlapping data—for instance, creating sliding windows of size n for rolling averages or trend detection—often requires intricate custom collectors that become difficult to understand or maintain over time, even for the original author. Furthermore, once a collector is applied, the pipeline ends; no further stream operations are possible afterward. These issues lead to verbose, error-prone code or a reluctant fallback to traditional for-loops, undermining the very benefits streams were meant to deliver.

Aicha emphasizes that these problems arise because prior to JDK 25, streams lacked “memory.” Elements flowed through independently without retaining context from previous items, forcing developers into workarounds that compromised readability and maintainability.

Introducing Stream Gatherers: Bringing Memory and Flexibility to Streams

JDK 25 addresses these limitations head-on with the Stream Gatherers API, which equips streams with stateful processing capabilities while remaining intermediate operations. Unlike terminal collectors, gatherers allow continued chaining after stateful transformations. A gatherer consists of up to four components, though only the integrator is mandatory:

• Initializer (optional): Executes once before any elements arrive, establishing initial state such as an empty list or counter.
• Integrator: The core logic, invoked for every element. It receives the current element, the mutable state, and a downstream consumer. Developers implement accumulation or transformation here, returning true to continue or false to short-circuit the pipeline.
• Combiner (optional): Essential for parallel streams, merging partial states from different threads.
• Finisher (optional): Runs once at the end of the stream, ensuring no residual state (such as an incomplete final batch) is lost by pushing any remaining elements downstream.

This design provides a short-circuit mechanism and supports parallel execution when a combiner is supplied. Aicha demonstrates creating a custom batching gatherer in roughly 15 lines of code—far simpler than equivalent custom collectors or manual loops. The initializer creates an empty list; the integrator adds elements until the batch size is reached, then pushes the batch downstream and clears the buffer; the finisher handles any trailing incomplete batch.

Even better, JDK 25 ships with five built-in gatherers that eliminate most custom implementations:

• windowFixed(n): Produces non-overlapping batches of exactly size n, including a final potentially smaller batch.
• windowSliding(n): Generates overlapping windows, ideal for rolling calculations, trend detection, or analyzing sequential data patterns in production monitoring.
• scan: Accumulates intermediate results similar to a fold, emitting every partial value starting from an initial element—unlike reduce, which yields only the final result.
• fold: Similar accumulation but treats the operation as intermediate, returning an Optional while permitting further pipeline chaining.
• mapConcurrent(maxConcurrency, mapper): Executes the mapper on virtual threads (up to the specified concurrency limit) while preserving encounter order, making it particularly suited for I/O-bound tasks without manual thread management.

These tools transform previously cumbersome tasks into concise, readable one- or few-line operations.

Live Demonstration: Analyzing Formula 1 Data with Gatherers

To illustrate practical application, Aicha uses racing data from Max Verstappen’s 2025 Formula 1 season, modeled as a record containing round number, Grand Prix name, position, and points. She contrasts traditional approaches—often involving dozens of lines of custom collector code with initializer, accumulator, combiner, and finisher—with gatherer-based solutions.

For batching every three races to compute cumulative points and wins, a windowFixed(3) gatherer replaces extensive custom logic, producing clean batches while automatically handling the final incomplete group. Sliding windows demonstrate overlapping views, such as performance trends across consecutive race triplets, again in just a few lines.

Accumulation across the entire season uses scan to emit running totals after each race, revealing Verstappen’s final 421 points and near-miss championship outcome. These examples highlight how gatherers retain “memory” of prior elements, enabling stateful yet fluent pipelines.

Aicha also touches on String Templates, another JDK 25 feature that enhances safety and readability. Traditional string concatenation or String.format often leads to injection vulnerabilities in SQL or JSON and creates “plus soup” that is hard to read. String Templates provide a clean, type-safe interpolation mechanism that reduces errors and improves security for logging, queries, and data serialization.

Implications and Recommendations for Modern Java Development

The introduction of gatherers and string templates reflects Java’s ongoing commitment to evolving without breaking compatibility, offering developers more powerful abstractions while preserving the language’s robustness. By reducing reliance on custom collectors and imperative workarounds, these features promote more maintainable, expressive codebases that are easier to reason about and debug.

Gatherers particularly shine in data processing pipelines, analytics, monitoring, and any domain requiring windowed or accumulated views. Their support for parallelism and short-circuiting adds efficiency, while the built-in variants cover the majority of common use cases, lowering the barrier to advanced stream usage.

Aicha encourages the community to upgrade to the latest JDK, experiment with these capabilities, write articles, and deliver talks to spread awareness. She notes that many scenarios previously abandoned to “for-loop hell” now become elegant stream solutions thanks to gatherers.

Code Sample: Batching with windowFixed

// Traditional complex collector approach omitted for brevity

// With Gatherers in JDK 25
var batches = races.stream()
    .gather(Gatherers.windowFixed(3))
    .map(batch -> computeStats(batch))  // e.g., sum points, count wins
    .toList();

Code Sample: Sliding Window for Trends

var slidingWindows = races.stream()
    .gather(Gatherers.windowSliding(3))
    .map(window -> analyzeTrend(window))
    .toList();

Code Sample: Accumulation with scan

var runningTotals = pointsStream
    .gather(Gatherers.scan(() -> 0, Integer::sum))
    .toList();  // Emits every intermediate sum

These snippets demonstrate the dramatic reduction in complexity while preserving full pipeline fluency.

In conclusion, Aicha Laafia’s presentation provides both a clear diagnosis of historical stream limitations and a compelling vision for their resolution in JDK 25. By incorporating statefulness through gatherers and safer string handling, Java strengthens its position as a modern, versatile language suitable for complex data-driven applications. Developers who adopt these features will benefit from shorter, more readable code, fewer maintenance headaches, and enhanced productivity.

Links:

• Video URL
• Aicha Laafia on LinkedIn
• Aicha Laafia Oracle ACE Profile

Lecturer

Kapil Reddy is a software engineer known for his “business-first” approach to development. He is a prominent figure in the Clojure community, frequently contributing to discussions and ideation at the Scicloj meetups. Kapil has collaborated with other leading engineers in the ecosystem, such as Vedang Manerikar and Daniel Slutzky, to explore the intersection of artificial intelligence and functional programming. He is currently involved in developing the llms.edn project, which aims to bridge the gap between Clojure’s library-centric philosophy and the modern need for rapid project scaffolding using Large Language Models (LLMs).

Abstract

In the modern software development landscape, Large Language Models (LLMs) have significantly altered workflows, particularly in the realm of project scaffolding. However, the Clojure ecosystem, which prioritizes a philosophy of composable libraries over rigid frameworks, often presents a steep learning curve for newcomers who seek the convenience of “Rails-like” frameworks. This article explores a novel methodology introduced by Kapil Reddy that leverages LLMs to automate the composition of Clojure libraries. By utilizing a structured, native format called llms.edn, developers can describe library usage patterns in a way that LLMs can understand and execute. This approach aims to provide the convenience of a framework while maintaining the flexibility and power of Clojure’s traditional library-based architecture.

The Framework Paradox in Clojure

The debate between using frameworks versus a collection of libraries is central to Clojure’s identity. Traditional frameworks like Ruby on Rails provide a “Golden Path,” offering a set of pre-configured tools and conventions that allow for rapid prototyping. For many developers, especially those transitioning from other ecosystems, the absence of such a framework in Clojure is perceived as a significant barrier to entry. Clojure’s core philosophy leans heavily toward composition, where developers select specialized libraries—such as Ring for HTTP, Reitit for routing, and HugSQL for database access—and manually integrate them.
While this library-centric approach prevents the “black box” complexity and “magic” often associated with frameworks, it requires a deep understanding of the ecosystem. Kapil Reddy observes that LLMs are exceptionally proficient at project scaffolding, a task traditionally reserved for frameworks. The challenge, therefore, is to create a system where LLMs can assist in this scaffolding process without forcing the community to adopt a monolithic framework that would sacrifice the language’s fundamental strengths.

llms.edn: Structured Knowledge for AI Agents

To enable LLMs to effectively compose Clojure libraries, Kapil proposes a structured, Clojure-native approach to describing libraries and their common usage patterns: llms.edn. This concept is inspired by the broader llms.txt initiative but is tailored specifically for the unique requirements of the Clojure ecosystem.
The llms.edn file serves as a manifest that provides the LLM with the necessary context to understand how a library should be initialized, configured, and integrated with others. Instead of the LLM relying on potentially outdated or hallucinatory training data, llms.edn provides a source of truth directly from the library authors or the community. This structured data includes:
* Dependency declarations: Specific coordinates for tools like deps.edn or Leiningen.
* Code snippets: Standard boilerplate for starting a server or connecting to a database.
* Interoperability rules: Instructions on how a library (e.g., a router) interacts with another (e.g., a handler).
By providing these instructions in a machine-readable format, the manual task of “wiring” libraries together—often the most frustrating part for beginners—can be offloaded to an AI agent.

LLM-Powered Composition Workflows

The practical application of this methodology is an LLM-powered composition workflow. In this model, the developer describes the desired features of their application in natural language. An AI agent then queries a registry of llms.edn files to identify the best libraries for the task.
Kapil demonstrates that once the “how-to” for each library is codified, the process of generating a cohesive starter project becomes a “looper making a REST call”. This flow engineering treats the LLM as a pipeline that manages state and passes configuration data between different execution steps. This results in a “framework-like” experience where a full project structure is generated instantly, yet the underlying code remains a collection of simple, independent libraries that the developer can easily modify or replace.
The implications of this shift are profound. It suggests that the primary utility of a framework—reducing the cognitive load of setup and configuration—can now be achieved through intelligent automation. As Kapil notes, the LLM world requires more “simple software” because the models themselves introduce enough complexity; Clojure’s inherent simplicity makes it an ideal target for this kind of AI-driven orchestration.

Links:

• Kapil Reddy’s Lecture: LLMs + Clojure = Who needs frameworks?
• Scicloj Community Website

Lecturer

Jim Newton is an Assistant Research Professor at EPITA, a prestigious engineering school in Paris, France. A veteran Lisp programmer since 1988, Jim has worked extensively with various dialects, including Common Lisp, SKILL++, and Clojure. His research focuses on the theoretical foundations of type systems in dynamically typed languages. At EPITA, he teaches courses on functional programming using Clojure and Scala. He is the author of several research papers and a PhD thesis titled “Representing and Computing with Types in Dynamically Typed Languages,” which forms the basis for the Regular Type Expression (RTE) library.

Abstract

While string-based regular expressions are a staple of modern programming, their application to sequences of heterogeneous types remains a relatively unexplored domain. This article details the development of Regular Type Expressions (RTEs), a framework for recognizing regular patterns within sequences of mixed-type elements in Clojure. We examine the transition from classical character-based Finite Automata to Symbolic Finite Automata, where transitions are governed by type predicates rather than literal characters. The discussion covers the theoretical challenges of implementing such a system, including the embedding of a Simple Type System (SETS) into the Clojure runtime, the construction of Deterministic Finite Automata (DFAs), and the complexities of subtype determination in a dynamic environment.

Beyond Strings: The Concept of Regular Type Expressions

Clojure programs frequently manipulate sequences—lists, vectors, or streams—that contain a variety of data types (e.g., a mixture of integers, strings, and keywords). While developers often need to validate the structure of these sequences, standard regular expressions are limited to character data. RTEs generalize the concept of regular languages to the level of types. Just as a standard regex might match the pattern a(a|b)*b, an RTE can be defined to match a sequence that “starts with an integer, contains zero or more strings or doubles, and ends with a keyword.”
Jim Newton’s work bridges the gap between the flexibility of dynamic typing and the rigor of formal language theory. By treating types as the alphabet of a regular language, RTEs allow developers to specify complex structural constraints on data. This is particularly useful in Clojure for validating macro arguments, processing heterogeneous data streams, or implementing sophisticated pattern-matching algorithms that go beyond simple structure-based destructuring.

Theoretical Challenges and Implementation

The implementation of RTEs in Clojure required solving several deep theoretical problems. Unlike character-based regex engines, where the alphabet is finite and each character is distinct, the “alphabet” of types is potentially infinite and overlapping. For example, a value might simultaneously satisfy the types Number, Integer, and Positive-Integer.

1. The Simple Type System (SETS)

To support RTEs, a fundamental type system (SETS) had to be embedded into the Clojure runtime. This system supports boolean algebraic operations on types: union, intersection, and complement. This allows for the definition of complex types such as “an element that is a String but not ‘admin'” or “an element that is either an Integer or a Keyword.”

2. Symbolic Finite Automata

The core of the RTE engine is a Symbolic Finite Automaton. In a standard DFA, a transition from one state to another is triggered by a specific character. In a Symbolic DFA, a transition is triggered if the next element in the sequence satisfies a given type predicate. A significant challenge here is ensuring the DFA remains deterministic. If an element matches multiple outgoing transitions (due to overlapping types), the automaton would become non-deterministic. To solve this, the system must be able to partition the type space into disjoint sets.

3. Subtype Determination

A critical requirement for DFA construction is the ability to determine if one type is a subtype of another. In a dynamic language like Clojure, which allows arbitrary predicates as types, this is not always decidable. Jim’s research introduces a “clever procedure” for DFA construction that maintains determinism even when the subtype relation cannot be fully determined, ensuring that the library remains robust across a wide range of use cases.

Code Sample: Using RTEs in Clojure

(require '[clojure-rte.core :refer [rte-match]])
;; Define an RTE: an Integer, followed by one or more Strings, 
;; and ending with a Keyword.
(def my-pattern '(:cat Long (:* String) Keyword))
(rte-match my-pattern [1 "hello" "world" :done]) ; => true
(rte-match my-pattern [1 :done])                 ; => true
(rte-match my-pattern ["wrong" :done])           ; => false

Practical Implications and Conclusion

The development of the clojure-rte library provides Clojure developers with a powerful tool for data validation and pattern recognition. It allows for the detection of unreachable code (by identifying patterns that can never be matched) and enables highly expressive type-based dispatch. Because the system is built on a solid theoretical foundation, it handles edge cases—such as empty sets or overlapping type definitions—with mathematical precision.
This project is part of a larger, multi-language research effort, with implementations also available in Scala, Python, and Common Lisp. By bringing the rigor of Symbolic Finite Automata to Clojure, Jim Newton has provided a compelling example of how theoretical computer science can enhance the practical tools of modern software engineering, particularly in the realm of dynamic, data-driven applications.

Links:

• Jim Newton on GitHub
• Clojure-RTE Library on GitHub
• EPITA Research Profile
• Watch the Lecture: Recognizing Regular Patterns

Lecturer

Joan Goyeau is a Senior Playback Data Engineer at Netflix, where he specializes in building high-scale distributed systems using functional programming paradigms. He is a prolific contributor to the open-source community, with notable involvement in projects such as the Mill build tool, the Kubernetes Java/Scala Client, Cats, Apache Spark, and Avro4s. Joan’s expertise lies in leveraging the grammatical simplicity of Scala to manage complex data architectures in enterprise environments.

Abstract

This article explores the historical and technical relationship between Scala and Java, framing Scala as a primary driver of innovation for the Java Virtual Machine (JVM). By tracing the lineage of modern Java features—such as generics, lambdas, and records—to their origins in the Pizza and Scala languages, the analysis demonstrates how functional concepts have systematically transitioned into mainstream enterprise development. Furthermore, the study examines the practical advantages of Scala’s minimalist grammar and multi-platform compilation capabilities, specifically within the context of data engineering at scale.

The Evolutionary Lineage: From Pizza to Java 21

The modernization of the Java language is deeply rooted in experiments conducted over two decades ago. In 2001, the “Pizza” language emerged as a superset of Java 1.4, introducing a proof-of-concept for generics, lambdas, and pattern matching. While the Java ecosystem initially only adopted generics, the broader suite of functional features found a permanent home in Scala upon its release in 2004.

In the years following, a “trickle-down” effect occurred where Scala features were progressively integrated into the Java language specification. Java 8 introduced lambdas through the Stream API, Java 14 implemented record classes (conceptually identical to Scala’s case classes), and recent versions have refined pattern matching through switch expressions. This history identifies Scala not just as a standalone language, but as a vanguard for JVM innovation that tests “unknown lands” before they are deemed safe for Java’s more conservative adoption cycle.

Grammatical Simplicity and Language Complexity

A significant technical advantage of Scala is its relatively small formal grammar compared to other modern languages. Analysis of language grammar sizes reveals that while Java and C# have grown in complexity to accommodate specific use cases, Scala maintains a core simplicity that allows for high expressiveness through library definitions rather than language keywords. This design philosophy ensures that the cognitive load remains manageable even as the developer leverages powerful functional features. Notably, newer languages like Kotlin have already surpassed Scala in grammatical size, illustrating the efficiency of Scala’s architectural choices.

Multi-Platform Versatility and Modern Tooling

Beyond its influence on Java, Scala has evolved into a versatile language capable of targeting multiple execution environments. Using the Scala CLI—a streamlined alternative to heavy build tools—developers can manage dependencies and package applications with minimal boilerplate. A single Scala codebase can target:

• The JVM: For traditional high-performance backend services.
• Native: For low-latency binaries that run directly on hardware.
• JavaScript (Scala.js): For front-end web development.

In the context of web development, libraries like Laminar allow developers to build reactive interfaces using type-safe functional structures. By replacing string-heavy HTML/JavaScript interactions with Scala’s rigorous type system, engineers can catch errors at compile-time that would typically manifest as runtime bugs in a traditional JavaScript stack.

Links:

• Joan Goyeau on GitHub
• Joan Goyeau on LinkedIn
• Joan Goyeau on Twitter/X
• Scala Official Website
• Scala CLI Project

Lecturer

Kevlin Henney is an independent consultant, trainer, and author specializing in software architecture, programming paradigms, and agile practices. He has contributed to numerous books, including “97 Things Every Programmer Should Know,” and is a frequent speaker at international conferences. Kevlin’s work spans decades, influencing developers through his insights on language evolution and design patterns. Relevant links include his X account (https://x.com/kevlinhenney) and Mastodon (https://mastodon.social/@kevlinhenney).

Abstract

This article analyzes Kevlin Henney’s exploration of programming languages’ historical trajectory, current state, and prospective developments. It dissects paradigms, influences, and biases shaping language adoption, emphasizing slow evolution despite rapid technological hype. Through data-driven analysis and historical anecdotes, it underscores the dominance of 20th-century languages, the assimilation of functional features into mainstream ones, and AI’s reinforcing role, offering implications for future trends.

Historical Foundations and Paradigm Shifts

Programming languages bridge hardware and human cognition, embodying philosophies for structuring thoughts and systems. Kevlin traces their origins to the 1950s, with Fortran as an experimental compiler challenging beliefs that high-level languages couldn’t match assembly efficiency. John Backus’s team at IBM proved otherwise, unleashing a “virus” that normalized compilation.

By 1977, Backus questioned liberation from the “von Neumann style”—imperative models mimicking memory storage, jumps, and assignments. He advocated functional styles with program algebras, introducing “style” before Robert Floyd’s 1978 formalization of paradigms. Paradigms, borrowed from other disciplines, frame programming approaches: imperative, functional, logic.

Historical influences abound; Algol 68, despite limited adoption, pioneered constructs like if-then-else as expressions, impacting modern syntax. Kevlin highlights languages’ slow pace: mainstream ones still integrate decades-old ideas, with developers embracing “new” features older than themselves.

This context reveals languages as ecosystems defining skills, communities, and loyalties, evolving gradually amid technological progress.

Current Landscape: Dominance and Biases

Contemporary rankings like TIOBE and RedMonk illustrate stasis. TIOBE’s January 2026 top 10 features Python leading, followed by C, Java, C++, and others—all 20th-century except Go. Skewed distributions show Python’s dominance, with top-five accounting for nearly 60% of activity.

RedMonk, biased toward Stack Overflow and GitHub, elevates TypeScript but confirms 20th-century prevalence. Even gRPC-supported languages skew vintage. Kevlin notes human statistical misconceptions: top-10 lists appear linear, but power laws dominate, amplifying incumbents.

Biases perpetuate this: legacy code bases influence employment and evolution, with languages borrowing features (e.g., lambdas from 1930s lambda calculus) to retain users. Java’s 2014 lambdas postdate C++’s; JavaScript popularized them, but Lisp implemented in 1960.

Paradigms blend: few pure functional languages in top-20; most hybridize, raiding functional concepts (lambdas, map-reduce) without full adoption. SQL, a declarative logic language, exemplifies non-functional declarativeness, rewritten as comprehensions in Python or Haskell.

Excel, per Simon Peyton Jones, is the most popular functional language, with 2020 lambdas (now in Google Sheets) adding calculus. This assimilation dilutes paradigms; functional programming peaked a decade ago, its ideas mainstreamed.

AI’s Influence on Language Evolution

Artificial intelligence reinforces biases. Early Lisp dominance in symbolic AI gave way to neural networks and machine learning in the 1980s-1990s. Modern LLMs, statistical at core, excel in languages with abundant data: JavaScript, Python, TypeScript.

Anders Hejlsberg observes AI’s proficiency proportional to exposure, disadvantaging new languages. LLMs default to mainstream, using Python for tasks like counting ‘R’s in “strawberry”—orchestrating code where reasoning falters.

Implications: AI makes languages “irrelevant” yet crucial, as defaults bias toward past dominants. Orchestration (e.g., Gemini writing Python) joins developers’ statistical set, perpetuating incumbents.

Future Trajectories and Constraints

Future predictions defy certainty, but trends suggest continuity. Change lags expectations; quantum computing remains niche, irrelevant to mainstream for decades.

Functional programming won’t dominate; von Neumann imperatives persist. AI amplifies long tails—easier language creation—but cores stabilize. Notations could innovate, per Richard Feynman, but comfort favors sharing existing ones.

William Faulkner’s quote—”The past is never dead. It’s not even past”—encapsulates: legacies endure, shaped by data, communities, and AI.

In conclusion, languages evolve slowly, assimilating ideas while incumbents dominate, with AI entrenching this amid potential for niche proliferation.

Links:

• Lecture Video
• Kevlin Henney on X
• Kevlin Henney on Mastodon

Lecturer

Christian Johansen is a highly experienced software developer at the Norwegian Food Safety Authority, where he specializes in architecting robust systems using Clojure and Datomic. With a professional career spanning two decades, Christian has dedicated the last ten years to full-time Clojure development. His expertise is deeply rooted in web technologies, encompassing the entire delivery pipeline from infrastructure configuration and data modeling to sophisticated frontend implementation. Beyond his primary role, he is a prolific contributor to the Clojure ecosystem, maintaining various open-source libraries and frequently sharing insights through conference presentations, educational courses, and a collaborative professional blog.

Abstract

Modern frontend development is often plagued by the complexities of shared mutable state and pervasive side effects, which complicate testing and maintenance. This article examines the philosophical and technical foundations of achieving a truly functional user interface. By revisiting the original promise of React—that UI is a function of state—and refining it through the lens of Clojure’s immutability, we introduce a paradigm known as top-down rendering. Central to this discussion is Replicant, a small, dependency-free Clojure rendering library designed to treat UI as pure, deterministic data. We analyze the methodology of building modular UIs that decouple rendering from state management, utilize data-driven event handlers, and leverage declarative animations to create simpler, more testable applications.

Historical Context and the Pursuit of Purity

The evolution of modern web development reached a significant milestone in 2013 with the introduction of React. The framework proposed a revolutionary conceptual model: the user interface should be viewed as a pure function of application state. In this ideal scenario, developers would write code as if the entire UI were rendered from scratch with every update, leaving the heavy lifting of DOM manipulation to the framework. However, while React transformed the industry’s mental model, it did not fully deliver on the promise of functional purity. In practice, React applications often allow mutable state to proliferate throughout the component tree, leading to the very “side-effect-ridden” complexity it sought to solve.
The ClojureScript community recognized this gap early on. Developers sought a more rigorous adherence to functional principles. One notable advancement was the library Quiescent, which introduced the constraint of “top-down rendering.” In this model, components are prohibited from maintaining their own internal state or triggering their own re-renders. Instead, the entire UI is a literal projection of a central, immutable data structure. This approach aligns perfectly with Clojure’s core strengths, providing a foundation for UIs that are stateless, deterministic, and built entirely on data.

Methodology: Rendering with Replicant

Replicant serves as a realization of this top-down philosophy. It is a minimalist virtual DOM library that operates on Hiccup, a domain-specific language in Clojure that represents HTML structures as standard data vectors and maps. The core methodology involves creating pure functions that transform domain data into Hiccup data. Because these functions are pure, they are inherently predictable and easy to test in isolation.
To illustrate this, consider the rendering of a task card in a Kanban application. The developer defines a function that takes a task map and returns a Hiccup representation. Replicant’s render function then takes this data and a target DOM element to perform the initial mount. When the application state changes, the process is repeated: the pure function generates new Hiccup data, and Replicant calculates the minimal set of DOM mutations required to transition the view. This “diffing” process ensures efficiency without requiring the developer to manage state transitions manually.

Code Sample: Pure Hiccup Transformation

(defn render-task [task tags-lookup]
  [:div.task-card
   [:h3 (:task/title task)]
   [:div.tags
    (map (fn [tag-id]
           (let [tag (get tags-lookup tag-id)]
             [:span {:class (str "tag-" (:tag/color tag))}
              (:tag/label tag)]))
         (:task/tags task))]])

Advanced UI Patterns: Events and Animations

Beyond static rendering, the “pure and simple” approach extends to interactivity. In traditional frameworks, event handlers are often opaque functions that execute side effects directly. Replicant encourages data-driven event handlers. Instead of passing a callback function to an onClick attribute, the developer can pass a data structure—a vector or a map—representing the intent of the event. A central coordinator then interprets this data to update the global state. This decoupling makes the UI’s behavior as inspectable and testable as its appearance.
The same principle applies to complex UI requirements like animations and timed effects. By treating time and transitions as part of the data flow, developers can create declarative animations. These are not imperative commands to “fade in an element” but rather state-based descriptions of how an element should appear at a given point in the application lifecycle. This approach dramatically simplifies the creation of interactive features like drag-and-drop or live data streaming, as the UI remains a consistent reflection of the underlying store regardless of where the data originates.

Consequential Benefits and Conclusion

Adopting a stateless, data-centric approach to UI development yields significant benefits for software quality. Because the UI is composed of pure functions, it is highly modular and testable. Tools like Portfolio (similar to Storybook for ClojureScript) allow developers to render “scenes” in isolation by passing mock domain data to their rendering functions. This facilitates rapid prototyping and visual regression testing without the need to navigate through a live, stateful application.
Ultimately, the shift toward pure and simple UIs represents a move away from the “nashing of teeth” associated with shared mutable state. By leveraging Clojure’s immutable data structures and Replicant’s minimalist rendering engine, developers can build systems that are not only more robust and maintainable but also more enjoyable to create. The decoupling of rendering from state management allows for a degree of architectural clarity that is often missing in contemporary frontend development.

Links:

• Christian Johansen on GitHub
• Replicant Library on GitHub
• Portfolio Library on GitHub
• Watch the Lecture: UI, Pure and Simple

Benjamin Rambaud, an accomplished PHP engineer at ekino, delivered an engaging presentation at PHP Forum Paris 2022, inviting developers to explore Domain-Driven Design (DDD) and functional programming to enhance their craft. With a nod to the collaborative spirit of the event, Benjamin adopted a market-like metaphor, encouraging attendees to “pick and choose” principles from DDD and functional programming to enrich their PHP projects. His talk, informed by his role as a co-organizer of AFUP Bordeaux, offered practical insights into improving code quality and project communication, drawing from established methodologies while urging developers to adapt them thoughtfully.

Foundations of Domain-Driven Design

Benjamin opened by demystifying DDD, a methodology focused on modeling complex business domains with precision. He emphasized the Ubiquitous Language, a shared vocabulary that aligns developers, stakeholders, and domain experts, fostering clearer communication. By prioritizing domain logic over technical details, DDD isolates business rules, making code more maintainable and expressive. Benjamin illustrated this with examples from his work at ekino, showing how DDD’s strategic patterns, like bounded contexts, help developers encapsulate business logic effectively, reducing framework dependency.

Leveraging Functional Programming

Shifting to functional programming, Benjamin highlighted its synergy with PHP’s multi-paradigm nature. He introduced concepts like pure functions, immutability, and value objects, which enhance testability and predictability. By integrating these principles, developers can create robust, error-resistant codebases. Benjamin drew from his experience with Drupal, demonstrating how functional programming complements DDD by isolating domain logic from framework-specific code, allowing for greater flexibility and maintainability in PHP projects.

Practical Implementation and Hexagonal Architecture

Delving into practical applications, Benjamin advocated for hexagonal architecture as a cornerstone of DDD in PHP. This approach uses ports and adapters to decouple business logic from external systems, enabling seamless integration with frameworks like Symfony. He cautioned against rigid adherence to frameworks, referencing resources like Mathias Verraes’ blog for deeper insights into DDD patterns. Benjamin’s practical advice, grounded in real-world examples, encouraged developers to experiment with repositories and interfaces tailored to their project’s needs, fostering adaptable and resilient code.

Balancing Frameworks and Principles

Concluding, Benjamin urged developers to understand their frameworks deeply while embracing external paradigms to avoid being constrained by default configurations. He emphasized that DDD and functional programming are not rigid doctrines but flexible tools to be adapted contextually. By encouraging exploration of languages like Elixir or OCaml, Benjamin inspired attendees to broaden their perspectives, enhancing their ability to craft high-quality, business-aligned PHP applications through thoughtful experimentation.

Links:

• ekino company website
• Benjamin Rambaud on GitHub
• Benjamin Rambaud’s blog

Baptiste Langlade, a PHP developer at EFI Automotive, captivated the Forum PHP 2021 audience with a deep dive into the limitations of exceptions in PHP’s type system. With a decade of experience in PHP and open-source contributions, Baptiste explored how exceptions disrupt type safety and proposed functional programming-inspired solutions. His talk combined technical rigor with practical insights, urging developers to rethink error handling. This post covers four themes: the problem with exceptions, functional programming alternatives, automating error handling, and challenges with interfaces.

The Problem with Exceptions

Baptiste Langlade began by highlighting the inherent flaws in PHP’s exception system, describing it as a “hole in the type system’s racket.” Exceptions, he argued, bypass type checks, leading to unexpected runtime errors that static analysis struggles to catch. Drawing on his work at EFI Automotive, Baptiste illustrated how unchecked exceptions in complex systems, like document management, can lead to fragile code, emphasizing the need for more robust error-handling mechanisms.

Functional Programming Alternatives

Drawing inspiration from functional programming, Baptiste proposed alternatives like the Either monad to handle errors explicitly without exceptions. He demonstrated how returning values that encapsulate success or failure states can improve type safety and predictability. By sharing examples from his open-source packages, Baptiste showed how these patterns integrate with PHP, offering developers a way to write cleaner, more reliable code that aligns with modern type-safe practices.

Automating Error Handling

Baptiste emphasized the importance of automating error detection to address the limitations of manual exception testing. He noted that developers often miss edge cases when writing unit tests, leading to uncaught exceptions. Tools like static analyzers can help by enforcing explicit error handling, but Baptiste cautioned that PHP currently lacks native support for declaring thrown exceptions in method signatures, unlike languages like Java. His insights urged developers to adopt rigorous testing practices to mitigate these risks.

Challenges with Interfaces

Concluding his talk, Baptiste addressed the challenges of using exceptions with PHP interfaces. He explained that interfaces cannot enforce specific exception types, limiting their utility in ensuring type safety. By exploring workarounds, such as explicit documentation and custom error types, Baptiste provided practical solutions for developers. His talk encouraged the PHP community to push for language improvements, drawing on his experiences to advocate for a more robust type system.

Links:

• EFI Automotive website

Lecturer

Venkat Subramaniam is an acclaimed software developer, author, and educator who founded Agile Developer, Inc., specializing in training and consulting on agile practices and programming languages. He holds a position as an instructional professor at the University of Houston, where he imparts knowledge on software engineering principles, and has authored several books on programming topics, including works on Kotlin and functional paradigms.

Abstract

This exploration delves into the principles of functional programming within the Kotlin language, contrasting it with imperative approaches and emphasizing declarative techniques, higher-order functions, lambda expressions, and lazy evaluation strategies. Through detailed examples, it examines how these elements streamline code, mitigate complexity, and support concurrent operations, while discussing methodological choices and their broader effects on software architecture.

Distinguishing Imperative and Declarative Paradigms: Establishing the Base

In software development, the choice of programming style profoundly influences the clarity and maintainability of code. Venkat initiates his discussion by highlighting the imperative style, where developers must specify not only the desired outcome but also the exact sequence of steps to achieve it. This method resembles providing exhaustive instructions, placing the onus on the programmer to manage every aspect of the process, which can introduce unnecessary intricacies that obscure the primary objective.

To illustrate, consider a scenario involving a collection of integers from one to ten, where the task is to calculate the sum of the doubles of all even numbers. In an imperative framework, one would typically declare a mutable variable to accumulate the result, then employ a loop to traverse the collection, apply a condition to identify even numbers, perform the doubling operation, and update the accumulator accordingly. Such an approach requires explicit handling of iteration and state changes, which can lead to errors if not managed meticulously. For instance, overlooking the initialization of the accumulator or mishandling the loop boundaries could yield incorrect results, thereby increasing the cognitive burden on the developer.

Conversely, the declarative style allows programmers to articulate solely what is needed, delegating the implementation details to underlying abstractions. This shift enables a focus on intent rather than mechanics, much like issuing a high-level command without detailing the execution path. Functional programming builds upon this by incorporating higher-order functions, which are capable of accepting other functions as arguments, generating new functions, or yielding functions as results. These constructs facilitate functional composition, where smaller, reusable units of behavior are combined to form more sophisticated operations without altering shared state.

Venkat underscores that while Kotlin permits imperative coding for familiarity, its support for declarative constructs encourages a move toward reduced complexity. By abstracting away low-level controls, developers can produce code that is more intuitive and less prone to defects. This transition has significant ramifications for large-scale systems, where maintaining code over time becomes paramount; declarative code tends to be more adaptable, facilitating easier modifications and extensions without widespread ripple effects.

Harnessing Lambda Expressions and Higher-Order Functions: Fundamental Tools

At the heart of Kotlin’s functional capabilities lie lambda expressions, which Venkat portrays as nameless functions designed to encapsulate behavior concisely and purely, meaning they avoid modifying external state or producing side effects. These expressions consist of a parameter list separated by an arrow from the body, enclosed in curly braces, with the return type inferred from the context to minimize verbosity.

The structure promotes brevity, ideally limiting the body to a single line to preserve readability. For example, incrementing each element in a list can be achieved with a lambda passed to the map function, transforming the collection in a one-to-one manner without explicit loops. However, when transformations yield multiple outputs per input—such as generating predecessors and successors for each number—standard mapping results in nested collections. To address this, flattening merges these into a single list, but performing mapping followed by flattening separately can be inefficient.

Venkat explains that flatMap elegantly combines these operations, applying the transformation and then consolidating the results. This is particularly useful for one-to-many mappings, ensuring the output remains a flat structure. Methodologically, selecting map for direct correspondences and flatMap for expansive transformations optimizes the pipeline, aligning with functional composition principles where functions chain to build complex logic from simple components.

Furthermore, higher-order functions extend this by treating functions as data, enabling dynamic behavior parameterization. The broader context is Kotlin’s hybrid nature, integrating object-oriented features with functional ones, allowing seamless interoperability. Analytically, this purity aids in reasoning about code; since functions depend only on inputs, outputs are predictable, simplifying testing and debugging. The consequences extend to concurrency, where absence of mutable state eliminates contention, making parallelization straightforward and safer in multi-threaded environments.

Implementing Lazy Evaluation: Optimizing Resource Utilization

A critical facet Venkat addresses is evaluation strategy, distinguishing eager from lazy approaches. Eager evaluation processes operations immediately, which can be wasteful for large datasets or when only partial results are needed. For instance, finding the double of the first even number greater than three in a list involves filtering for values exceeding three, then for evenness, doubling, and selecting the first—eagerly traversing the entire collection multiple times.

By converting the list to a sequence in Kotlin, operations become lazy, computing only as required. This defers execution until the terminal operation, such as retrieving the first element, halting further processing once the result is found. Venkat demonstrates this with print statements in filter and map functions, revealing that lazy sequences minimize calls, touching only necessary elements.

Methodologically, employing sequences for potentially infinite or voluminous data prevents unnecessary computations, akin to Java’s streams. However, developers must consciously opt for sequences, as list operations default to eagerness. The context here is performance-sensitive applications, where eager defaults could lead to inefficiencies. Implications include resource conservation in big data scenarios, enabling handling of streams that exceed memory capacity. Analytically, laziness embodies functional essence, allowing declarative chains without premature optimization concerns, thus promoting scalable designs in resource-constrained settings.

Broader Ramifications for Software Engineering: From Concurrency to Maintainability

Although functional programming bolsters concurrency by eschewing mutable state—thus avoiding locks and race conditions—Venkat posits that its chief merit lies in declarative reduction of accidental complexity, where code mirrors intent more closely. Imperative verbosity often embeds implementation details that hinder comprehension, whereas functional pipelines express logic fluidly.

In Kotlin, this manifests through native support for these idioms, blending with object-oriented paradigms for versatile architectures. Yet, judicious application is key; misusing eagerness or bloating lambdas undermines benefits. The consequences foster resilient systems, adaptable to change with minimal disruption. For practitioners, this encourages a mindset shift toward composition and purity, yielding codebases that are easier to evolve and collaborate on.

Ultimately, Kotlin’s functional features empower developers to craft elegant solutions, balancing expressiveness with efficiency, and paving the way for innovative software practices.

Links:

• Lecture Video
• Venkat Subramaniam on X/Twitter
• Venkat Subramaniam on LinkedIn
• Agile Developer Website
• Programming Kotlin Book