-
Anjana Vakil: Learning Functional Programming with JavaScript - JSUnconf ✅
-
An introduction to functional programming - by Mary Rose Cook ✅
Functional programming is partly about building up a library of generic, reusable, composable functions.
Currying means decomposing a function that takes multiple arguments into a function that takes the first argument and returns a function that takes the next argument, and so forth for all the arguments.
Languages with tail call optimisation reuse the same stack frame for their entire sequence of recursive calls.
Parallelization means running the same code concurrently without synchronization. These concurrent processes are often run on multiple processors.
Lazy evaluation is a compiler technique that avoids running code until the result is needed.
A process is deterministic if repetitions yield the same result every time.
-
Anjana Vakil — Functional Programming in JS: What? Why? How?
-
Anjana Vakil: Immutable data structures for functional JS | JSConf EU
-
Changing properties of objects is mutation. Mutation is a side effect by definition. Everyone of us learned that we should avoid side effects at all cost. We don’t have to look into the implementation of a function if it doesn’t have any side effects. Our code gets easier to reason about and will be more predictable and more testable.
-
Immutable JS persistent data structures and structural sharing
-
Immutability in React: There’s nothing wrong with mutating objects ✅
One of the big tradeoffs of mutability is lack of traceability as objects change over time. There are a number of devtools built around this, which greatly improve developer experience when chasing down the side effects of bugs. Not only that, you need to mentally map how things change over time when reading the code, which causes undue burden on the developer. One of the big gains of immutability is reduced cognitive friction. Immutable code tends to be more readable and more easily understood than code relying on mutating internal state, which makes bug remediation and managing large, shared codebases much simpler. It also makes testing much simpler because the code is more transactional. There is indeed a trade-off, but you pose this as a 50–50 proposition, whereas it is really 95–5. Immutably setting an array of 1000 elements in 3ms is technically 3x slower than mutably setting it in 1ms, but perspective is important because 3ms is still pretty friggin fast. Pre-optimization is the root of all evil, so the sacrifices in readability, understandability, traceability, etc are large just to squeeze that imperceptible-to-the-user performance gain. Unless you’re building a game. Only then is performance paramount.
-
Dan Abramov - Live React: Hot Reloading with Time Travel at react-europe 2015
-
First-class and Higher Order Functions: Effective Functional JavaScript
-
Do you really need immutable data? ✅
But if you think of your whole application as a state machine, where everything is a pure expression of state, then immutability stops being a problem.
Once state changes, you want that change to reflect everywhere. If I press “Play” on Spotify, I want my whole phone to react. iTunes has to stop playing, the music dock thingy has to update its UI, my headphones have to make sound, things like that.
Your app should be a state machine where everything is an expression of state. Your logic should manipulate the state and your app should react.
Last active
December 31, 2018 18:23
-
-
Save heitoralthmann/f6f7f275121d1dfdd685b82869879b27 to your computer and use it in GitHub Desktop.
Estudos em Functional Programming
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment