Hacker News Reader

A function which returns the same output (and has no side effects) if given the same input is a "pure function".

Things like network requests, or reading from files, or keeping track of state like a counter, are effectful. So, yes, a function which does these things couldn't be pure.

It's still nice to be able to have a pure function over an impure function. (Sortof the same "nice" as in "it's nice to not use global variables for everything in your code"). An impure function might be more difficult to think about than a pure one.

In languages like Haskell, all the functions are pure. But useful programs are effectful. There are different ways Haskell can still have useful programs while only allowing pure functions. (The most common way this gets done is using monads). -- One trick is "algebraic effects", this blogpost is an accessible intro: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Functional languages themselves are about a bit more than pure functions. It's about being able to pass functions around.. languages like JavaScript or Python have functions like map/filter/flatMap. Functions which take functions as parameters. They're a neat way of writing code.

The JSON program JQ's language is comparable to Nix. -- You could write your JSON-processing programs with Python (or whatever), or you can use some JQ expressions to do the processing.

The needs of the Nix language differs from that of a general purpose programming language. Its sole purpose is to output a self-contained and deterministic package build script. As such, it doesn't need persistent state. Every external input, such as source tarballs has their hashes verified so it should wield the exact same result every time it's evaluated. If any external input doesn't match expectations, evaluation would be aborted immediately.

> And it would not be possible to keep track of anything. No counting, no transformation of data, nothing.

All of this is possible without state. Counting could be done with, say, 'builtins.length'. As for transforming data, that's what programming languages literally do. The Nix language isn't an exception here. In fact, the Nix language has everything to do with transforming data. It transforms high level package definitions to lower level build instructions.

> I see a lot of overhead coming from these mental gymnastics with no benefit

At least with the Nix language, there's no mental gymnastics going on. Defining a package is as simple as it gets, as can be seen here[1]. The benefits are reproducible package builds and composability. Since Nix functions don't contain state, it's really easy to combine abstractions and make modifications to existing packages compared to conventional package managers. See the Chrome example in the NixOS Wiki[2].

[1]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

[2]: https://nixos.wiki/wiki/Overlays

With Nix, any network I/O is done through "fixed-output derivations." Fixed-output derivations define the expected hash of their outputs, so if they don't produce the expected output they throw an error.

This seems like another mental trick to me.

"Yeah, the function did not produce a different output. It just behaved different by throwing an exception."

Still, some other code will read (or "interpret") this behavior and then behave accordingly etc. So what is won here?

Nix doesn't allow for recovering from errors

It's a good trick.

The function didn't return a value, so its caller cannot interpret that value and cannot change it behaviour.

Your absolutely right: it's not true. Well, not entirely true.

There are two ways functional languages get around this:

Most functional language don't force functions to be pure. So, while they tend to be composed of functions that produce the same output for a given input, they aren't entirely. That is, they're just like any other language in this respect. Nonetheless, functional programs tend to separate the impure parts using patterns such as https://www.destroyallsoftware.com/screencasts/catalog/funct...

Then there are the languages where functions actually are necessarily pure - mostly Haskell. But this just means that the imperative actions aren't functions, not that they don't exist. The big impact is that, since a pure function can't invoke an impure action - or it wouldn't be pure - you have to use function-code-imperative-shell or your program won't compile.

> I think this is not true. If it was this way, there would be no way to read data from an API.

Why do you think the only way to read from an API is with a function call? Have you not heard of monads?

Nope. I have not heard of any of this. I only read this sentence in the article:

> Functional languages are composed of functions that take some input and produce some output. Every time a function is executed with a given input, it will return the same output.

It does not mention "monads".

in pure FP languages there are functions and IO actions, functions are pure, IO actions are side-effectful.