They most likely refer to homoiconicity [1], as Clojure is a dialect of Lisp. However, it's hard to say for sure, and maybe they were simply referring to the built-in syntax for maps, lists, etc.

[1]: https://en.wikipedia.org/wiki/Homoiconicity

Not only due to homoiconic nature. All (well, technically not all, let's say most) Lisp dialects are homoiconic. Yet, there are some other aspects that make Clojure specifically well-suited for data manipulation:

- immutability and persistent data structures (makes code easier to reason about [the data]; enables efficient concurrency - no locks; some algorithmic tricks that makes it very performant despite having to create copies of collections),

- seq abstraction - unlike other Lisp where sequence functions are often specialized for different types, Clojure simplifies things by making baked-in abstraction central to the language - all core functions work with seqs by default. it emphasizes lazy sequences as a unified way to process data, i.e., memory efficiency and infinite sequences, etc.

- rich standard library of functions for data transformation

- destructuring - makes code both cleaner and more declarative

- emphasis on pure functions working on simple data structures

The combination of these features makes data processing in Clojure particularly elegant and efficient.

OOP generally "hides" data as internal state of class instances. Everything is private unless expressed as a method on an object.

The two sentences around the one you quoted should answer the question as well:

    > With Clojure, we modeled the entire collaboration system as a stream of immutable data transformations. Each user action becomes a transaction in our system.

And

   > When conflicts occur, our system can merge changes intelligently because we're working with pure data structures rather than complex objects.

Whereas OOP languages combine behavior and data into a single thing (classes with methods model behavior and hide state i.e. data) functional languages separate them: functions model behavior, and data is treated more like an input and output rather than "state".

In particular with clojure, data structures tend to be immutable and functions tend to not have side effects. This gives rise to the benefits the article talks about, though is not without its own drawbacks.

Appreciate the breakdown.

In Clojure, treating data as a first-class citizen means that data structures (like maps, vectors, sets) can be:

1. Passed as arguments

2. Returned from functions

3. Stored in variables

4. Manipulated directly

5. Compared easily

Unlike some languages where data needs special handling or conversion, Clojure lets you work with data structures directly and consistently throughout your program.

This philosophy extends to how Clojure handles data transformations. For example, transducers are composable algorithmic transformations that can work on any data source - whether it's a collection, stream, or channel. They treat the data transformation itself as a first-class value that can be composed, stored, and reused independently of the input source.

This first-class treatment of both data and data transformations makes Clojure particularly powerful for data processing and manipulation tasks.

That's why Clojure often finds strong adoption in data analytics, fintech and similar domains. The ability to treat both data and transformations as first-class citizens makes it easier to build, for example: reliable financial systems where data integrity is crucial.

This is a great explanation for "data as first class citizen"

I am planning on writing how we have built the real time collaboration engine with conflict resolution.

I think having a clear example would help in understanding.

Subscribe the newsletter to know when it's live.