3 ms·

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 independen

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?

markeibes 3y ago
How is "side-effects free" less fancy and trendy than functional?
kaba0 3y ago
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.
dwohnitmok 3y ago
> 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).
- captaincrisp 3y ago
  > 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.
  - dwohnitmok 3y ago
    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).
- deleted 3y ago
  [deleted]
- hardware2win 3y ago
  You definitely can write method CalculateSomething which is both: pure and oop viable
  - dwohnitmok 3y ago
    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").

markeibes 3y ago

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

kaba0 3y ago

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.

dwohnitmok 3y ago

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

captaincrisp 3y ago
> 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.
- dwohnitmok 3y ago
  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).
deleted 3y ago
[deleted]
hardware2win 3y ago
You definitely can write method CalculateSomething which is both: pure and oop viable
- dwohnitmok 3y ago
  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").