I mean how Nix uses FP?

Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.

Pure functions are just a concept that is used in FP world

Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them.

So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?

How is "side-effects free" less fancy and trendy than functional?

Because it is basically a dynamically typed Haskell? It also does currying.

Like, there is no one definition of FP, but Nix is definitely an FP language as well as the whole idea behind it.

> You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them.

This is not true. OOP is fundamentally built around impure operations.

Objects are persistent references that you send messages to or that you call methods on (depending on your OOP language of choice).

A persistent reference that is stable across different invocations (as opposed to a new reference being created on each invocation) requires that those invocations be impure operations, because the same invocation performed multiple times must have different effects, otherwise there is no point to having a stable reference.

That's not necessarily a bad thing, but OOP is fundamentally impure.

(If you do create a new reference on every invocation, then you no longer have OOP. You merely have a namespacing system where the first argument to a function can alternatively be written with a dot).

> You do not need FP to use pure functions

I think this is a bit more subtle, and a bit less interesting to say, than you're thinking it is and responding to. You need to be impure in OOP world but not in every function you write. I write many pure functions in my OOP work; they make the whole thing easier to reason about.

Sure, but it's precisely those places where you're using pure functions that aren't object-oriented. That is it is possible in some nominally OO languages to write code that is not object-oriented and that's where pure functions come in. In a language that has only classic OO-style objects pure functions (and their counterpart in data space, immutable data structures) are generally not used or are not very idiomatic, e.g. as in Smalltalk (you will have things that are kind of pure, but the purity can almost always be broken in some way).

You definitely can write method CalculateSomething which is both: pure and oop viable

Sure in the same way you can create an object in FP by sticking functions in a data structure or create functions in a logic programming language by constructing certain relations.

Heck you can even build "objects" in C.

And all of these methods are indeed used in those languages.

But none of those capture the spirit of object-orientation, in the same way that CalculateSomething is not object-oriented, unless it in turn generates a mutable object. That's not to say it's bad code or that it is uncommon, even in say Java. Simply that it's not object-oriented (and these days Java is getting less and less object-oriented anyways, with records and pattern matching explicitly separating data from functions).

Indeed in Java materials and blog posts from > 5 years ago, using pure methods of the form `CalculateSomething` was generally something used begrudgingly, where too many of those methods was specifically called out as an anti-pattern (e.g. the dreaded "utility class").