An introduction/overview of the properties of functional programming, followed by an exploration of some benefits. Code examples are in either javascript or scala.
of functions. 1) Return results can be functions. (i.e. Functions can return functions.) 2) Arguments can be functions. (i.e. Functions can take functions.)
of functions. 1) Return results can be functions. (i.e. Functions can return functions.) 2) Arguments can be functions. (i.e. Functions can take functions.)
of functions. 1) Return results can be functions. (i.e. Functions can return functions.) 2) Arguments can be functions. (i.e. Functions can take functions.)
of functions. 1) Return results can be functions. (i.e. Functions can return functions.) 2) Arguments can be functions. (i.e. Functions can take functions.) makeAdd and addAndMultiply are higher-order functions.
They are context independent. (doesn’t matter when or where) • The same input produces same output. (predictable, deterministic program) RT just doesn’t work for imperative programming.
state outside of their scope. • Don’t have any observable interaction with their surrounding context. • Are idempotent. • Are eligible for referential transparency.
state outside of their scope. • Don’t have any observable interaction with their surrounding context. • Are idempotent. • Are eligible for referential transparency.
state outside of their scope. • Don’t have any observable interaction with their surrounding context. • Are idempotent. • Are eligible for referential transparency.
state outside of their scope. • Don’t have any observable interaction with their surrounding context. • Are idempotent. • Are eligible for referential transparency.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation. Abstractions over evaluation are used to model effects.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation. Abstractions over evaluation are used to model effects.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation. Abstractions over evaluation are used to model effects.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation. Abstractions over evaluation are used to model effects.
to do it. • Is not sequential instructions. (doesn’t describe control flow of execution) • Achieves separation of concerns between description and implementation. Abstractions over evaluation are used to model effects.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well.
of data types and functions. • Use a toolbox of core, reusable, and proven tools • Create new computations quickly from existing ones. • Utilize simple components that do one thing well. The goal: not heaps of special cases and tangled conditions, but an expressive domain composed of simple parts.
concurrency. • Functional abstractions separate concerns elegantly. • Required reasoning about code is reduced and localized. • Pure functions can be easily reused.
mocking required. • Previously tested “tools” can be used with confidence. • Properties can be verified with property-based testing. • Properties expressed by types are automatically “tested” by the compiler.
Rúnar Bjarnason (on Safari) Functional and Reactive Domain Modeling by Debasish Ghosh (Early Access) 4 upcoming on-demand coursera courses from the Scala Center at EPFL