top | item 7868177

(no title)

Xurinos | 11 years ago

1. I think we should challenge the definition of "global variable". In what context is the variable global? The traditional definition is that the context is the whole program. However, in imperative OOP [1] code, I find that people just learned to hide their global variables in class instances. The whole program cannot access them, right? but every method in the class can and does, and all those mutations and side effects can lead to the kind of spaghetti code we all hated when there was no OOP. It's just global variables with extra sugar. And we can make copies of them, so the code is maybe one step better.

Imperative OOP often feels like one is pivoting behavior around the data.

FP feels like the data is flowing from one transformation to the next.

There is the "functional" part of it, too... where functions are highly composable. One creates new functions by combining old functions, and these may carry along with them important context (closures).

2. From what I've learned of Haskell -- and I'm a Haskell noob -- it lets you work with the side effecty real world. You can alter your hardware state. The key is that it specifically flags such side effects and encourages separation between more "pure" code and code that is "tainted" with the side effects.

[1] OOP is an abstraction and compatible with pure FP. You can model your class instances such that they are immutable and get all the benefits of OOP. FP contrasts better with imperative programming.

discuss

order

No comments yet.