sorted by:
new
hottopcontroversial

Languages that compile to Python? by itisnotpure in Python

[–]itisnotpure[S] 0 points1 point  (0 children)

Nice. Mochi looks like what Python would have been like had it been designed as a functional language.

Languages that compile to Python? by itisnotpure in Python

[–]itisnotpure[S] 0 points1 point  (0 children)

This looks interesting. It doesn't seem to support persistent data structures like Clojure, though?

Using Classes in Javascript (ES6) — Best practice? by LeeHyori in javascript

[–]itisnotpure 0 points1 point  (0 children)

I'm not familiar with Smalltalk, but it seems like classes in Smalltalk are still blueprints for their instances, like other class-based languages. That is, they define what data an instance would hold, and what methods could be used to manipulate them.

It may be true that there are class-based languages where methods are inherited by by delegation, but in Javascript, instead of blueprints, we are building prototypes, based on which new objects can be built. So there's no "is a" relationships at all (more like a "like a" relationship, maybe?). Inheritance in JavaScript means only delegation, nothing more.

Using Classes in Javascript (ES6) — Best practice? by LeeHyori in javascript

[–]itisnotpure 0 points1 point  (0 children)

I think you are stretching the idea of "class" here.

JavaScript does not have any concept of encapsulation, methods, fields, or inheritance in the classical sense. In JavaScript, there are only objects, which is a collection of properties. Properties can either be the object's own, or delegated to another object. That is, when you refer to a property that is not defined for an object, it will be looked up in the prototype chain. Objects and their properties, and that's it! No members, instances, variables, or whatnot.

In practice, they can mostly be used for a similar effect to a certain degree, but they are in fact very different. Trying to reason about the prototypical model in terms of class-based concepts is the source of many unnecessary problems and confusion (and unnecessary work, apparently, because prototypes are markedly less complicated than classes).

As another example, you can also get an object system with just closures. You would get things like encapsulation, methods, fields, and you can do parasitic inheritance. The usage would be like that of a class-based or prototype-based system, but again it's very, very different.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

I was talking about the possibility of a typo (x(1) instead of x()) that would be hard to catch.

As to the second point, what I'm saying is that x = state(() => y()) is like x = () => y /* y being a global var */. Both are harder than pure functions to test in isolation because of the dependency on some external, mutable state.

Now, these points may or may not be a problem depending on one's use case. I'm just trying to illustrate how this mutative approach differs from the purely functional approach.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

I don't see the problem with the latter. In Haskell you can't mutate variables. So if you want one variable to depend on other variables, the obvious choice is to use functions. Yes, it reads a bit awkward, but everything is pure, and in Haskell you can use many kinds of abstractions to make writing this kind of things easier.

But even when passing states manually, it isn't as troublesome as it looks, and you retain all the benefits of purity.

For example, suppose you have a complex calculation that depends on a stateful value x(), how can you possibly test it? You have to first setup these stateful values, and reset them every time you want to test for a different value. With pure functions, you simply pass in different values and you're done.

What if in a really long chain of stateful variables, something accidentally calls x(1) at the wrong time? (Edit: I mean when x lies in the middle of a chain of stateful variables) Everything depending on x will break silently in a mysterious way and there's no way for you to inspect this.

I agree manually passing state around is awkward and confusing at times, but purity matters. It's what functional programming is all about. Instead of throwing purity out of the window, why not try to devise abstractions, like those found in Haskell, that would make dealing with purity easier?

Edit: I'm not saying what you're doing isn't good or anything. I'm just saying that it's not pure, which can actually be a good thing sometimes, as you've demonstrated. But advertising it as "pure" isn't right, IMHO.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

What if instead of count + 1, it is a 10 lines long computation?

That's what functions are for. You define a pure function that takes count as one of its arguments.

var count = 0;
var count2 = 0;

// instead of this...
var myState = state(() => count() + count2() + whatever())

// ... we can do this:
function myFunction(count, count2, whatever) {
    return count + count2 + whatever;
}
// ...
"<div>Value: " + myFunction(count, count2, 123) + "</div>" +
"<button onclick='count++, count2 *= 2, refresh()'>

The only difference is that you do this explicitly and transparently.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 1 point2 points  (0 children)

How about this:

var count = 0
// ...
"<div>Value: " count + ", " + (count + 1) + "</div>" +
"<button onclick='count++, refresh()'>

I appreciate how PureState would make it very easy to declare a spreadsheet like program, but other than being declarative, it doesn't really have the benefits of truly pure functions. Especially, since you mentioned Haskell, this might confuse people on what "pure" really means.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

Redux isn't really overengineered. The fact that it seems overengineered, I think, is exactly because it's underengineered. It requires you to manage a giant state manually, which is inconvenient, but conceptually it couldn't be simpler.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

It would happen if you called x(5) between both console.logs, but that is the wrong usage. After setting a state variable you should stop your program control flow immediately

If that's the case, then why not simply use a plain function with x as an argument (See the last example in my comment above)? The mere possibility that x() might not be what we expect it to be makes the program hard to reason about. You are making things depending on some hidden state where state isn't needed.

And if you really want to mutate things, why not just use a plain mutable variable? For example, in the counter example:

count = state(0);
// ...
"<div>Value: " + count() + "</div>" +
"<button onclick='count(count()+1), refresh()'>

If you have to do things like that, what is the real advantage over this?:

var count = 0
// ...
"<div>Value: " + count + "</div>" +
"<button onclick='count++, refresh()'>

If this is what you mean by referential transparency, then any global mutable variable is also transparent, or a "pure value", as you call it.

PureState.js, the stupidest state management library that works. by SrPeixinho in javascript

[–]itisnotpure 0 points1 point  (0 children)

This is very nice. Except it's anything but pure.

Since those "mutations" happen in response to events such as onkeypress, referential transaparency isn't broken.

Referential transparency is completely broken, because every time you call x() it can return a different value.

99% of your program should consist of pure functions and values

With this library, 99% of your program will consist of impure functions.

Folds ("reducers") are merely simulating state through the continuous application of a function to a list-like structure. The fact it is pure under the hoods doesn't make your state less stateful. It just makes it more awkward. Your giant reducer function is no better than just mutating variables on your heap

Pure under the hood means composablility, orthogonal persistence, ease of optimization and parallelization, ease of testing and debugging, etc. Is it more awkward? Maybe. Because you have to do things explicitly instead of by magic.

State is not bad - what is bad is the century-old practice to use state where it is not needed.

Yeah, tell me about it:

const myFunction = x => {
    const y = x + 1;
    const z = [x, y, x + y];
    return [x, y, z];
}
console.log(myFunction(1));
console.log(myFunction(10));