This isn’t as helpful a discussion, but I don’t agree. A stack does not care about the underlying data structure (abstract over it). When you use an array to implement a Stack, it’s an implementation of Stack - the ADT with an array - the data structure.

One of the classics: Roboto Mono.

Good question! For simpler items (numbers), "filling" is trivial, where what you're suggesting is an efficient way to do things. But consider an array of complex items, where each item is a message object and we're interested in sorting them by their priority (a member on the object). The process of "filling" might not even be possible, or when it is, it will perform badly as you'd be making copies (allocations) of the complex objects. The method described in the video allows you to reuse items present in the original array.

theteachr.github.io

100%, sometimes even can cause the compiler to produce less performant assembly. But he literally says pretty much this in the description.

f is not impure, but you did point out the incorrect thing I said. I meant to say, "pure functions are idempotent." But that's wrong. Pure functions need not be idempotent. Thanks for bringing this up.

It's just a lot more to think about when you find such a reference being passed around with mutation. You'd have to keep a look out for where it's being passed and whether it gets mutated in that place. Values are much easier to reason about. They just can't change. No matter where or how you pass them. Any change is reflected by a new value. A smart compiler can see when the old value is not used after and just do an in place mutation.

theteachr.github.io

This is getting into referential transparency.

@@theteachr yes, it also touches functional extensionality

I think they’re well aware of it.

Everything is pure in an immutable context.

No, you’re expecting the same result: Improvement. More technically, you wouldn’t be doing the same thing either. Every time you do it again, your previous doing would have changed you.

@@theteachr i see your point but still there are many things where our effort is not the only factor and trying again and again is not insanity i do not completely agree with that quote

Fair point, I guess to make it truly pure it needs to pass definitions for any operators/functions that are used in the function as arguments.

I like the take. But what matters is whether the properties are held. Checking a bool maybe impure, but does it ever behave non deterministically? If it does, we have a more serious problem. A function when executed by a run time might (more that it will) have a side effect but can still be pure given that that side effect is not affecting your program's behavior. As long as the properties are held, you're objectively in a better position to reason about your program. And that's what FP tries to maximize.

@@shadow-ht5gk A pure function can call another pure function without losing purity. It will still be deterministic and doing no side effects. You can chain a bunch of pure functions into another pure function when you see the same chain of calls being made in more than a few places.

​@@theteachr the properties aren't held, they aren't real. Your function tries to allocate a string and runs out of memory and needs to somehow stat alive, of course that's impure. Your thread does a calculation and gets shut down in the middle of it and needs to restart and continue correctly - if you actually believe it's pure it should be impossible. In reality these are also possibilities that you are faced with among many others. This purity business is more like something we play with and imagine to improve our code and that's fine because it can help, but we shouldn't forget that all of that is fake and made up by us to help us think in a particular way about things as opposed to describing actual things.

Isn’t everything a utility? Shouldn’t they all go in utils? Utils is a smell. The filling pure functions should have a name and place inside the core. All side effect-y things can go into an IO namespace. From what I read, you are giving less importance to the filling.

Because doing so would make them impure.

Async is pretty much solved by having virtual threads that eliminate the need for red/blue functions and disjointed mutually incompatible code. It's only a matter of having a GC that makes this possible and a language that supports them

@@NJ-wb1cz functional programming is exactly the kind of a thing that would make async functions achievable without coloring or even runtime

@@sunofabeach9424 I'm not talking about ifs or woulds, I'm talking about java that already has async without color functions or async/await

@@sunofabeach9424 can you provide an example where this is implemented?

Even Ruby does !

If you have to comment your code to be understood then it is almost always poorly written. Using named variables and functions and defensive programming goes a long way in making code more readable.

@@ImperiumLibertas On occasion you need the "why" of what you're doing. Good comments add context, not restate the what.

also, you could still have an impure function, as long as it is indeterministic.

Keynote Magic Move >>> PowerPoint Morph

Someone *has* to do the side effects. Even if you're writing a memory allocator, you can express its behaviour in a pure functional way. The act of doing / inserting the side effects will be the responsibility of runtime / compiler. The goal is to maximise describing the what over how.

basically, you write as much as possible to be pure, and then a thin veneer of small and simple impure functions. this also has the benefit that it makes changing the ui code easy. so you develop the pure functions in the library, add thin impure functions at the edge, then you can turn it into a cli tool to exercise the parameters, have a separate thin web ui for headless use, and a gui for desktop use. this is why people who do ci and tdd have implausibly high code coverage, because it is mainly pure functions.

While I don't completely dismiss this idea, every flag results in a branch, doubling the number of valid paths, which would bother me. I can understand if it's small piece of code, but I would still prefer the decorator. Pure function is completely pure and the impure counterpart just wraps over it with side effects and / or reading external sources.

@@theteachr i'm not sure what you mean by a "decorator". if it's just a function that provides additional pre/post processing of arguments/return values of a target function, then i don't see much difference between these approaches. if it's something like python decorators or "design patterns"TM decorators, then i don't like them. i find them very cumbersome and not suitable for most tasks. if it's something along the lines of lisp-style macros, or some other code generation technique, then it's a total overkill for 99% of tasks.

Hmm, this idea might be formalizable into some kind of polymorphism around the effect system. Oh wait… Isn't this what Idris does already? Also, free monads are a very similar concept.

or you can just wrap your impure function around the pure one as shown in the video. this is better, as you don't muck up your api with the optional parameter. also because the pure function is testable, and the impure function is almost trivial because it is just thin glue around the pure function, so it is near trivial. it makes ci and tdd easy.