SlideShare a Scribd company logo
1 of 7
Download to read offline
Definitions	of	Functional	
Programming
Comparing	four	Definitions
slides	by @philip_schwarz
1. A	pure	function	depends	only	on	(a)	its	declared	input	parameters	and	(b)	its	algorithm	to	produce	its	result.	
A	pure	function	has	no	“back	doors,”	which	means:
1. Its	result	can’t depend	on reading any	hidden	value	outside	of	the	function	scope,	such	as	another	field	in	the	same	class or	global	variables.
2. It	cannot	modify any hidden	fields	outside	of	the	function	scope,	such	as	other	mutable fields in	the	same	class or	global	variables.
3. It	cannot depend on	any	external	I/O.	It	can’t	rely	on	input	from	files,	databases,	web	services,	UIs,	etc;	it	can’t	produce	output,	such	as	
writing to	a	file,	database,	or	web	service,	writing to	a	screen,	etc.
2.	A	pure	function	does	not	modify its	input	parameters.
A pure function has no side effects,
meaning that it does not read
anything from the outside world or
write anything to the outside world.
As a result of 1, if a pure function is
called with an input parameter x an
infinite number of times, it will
always return the same result y.
This is unlike an OOP method, which
can depend on other fields in the
same class as the method.
A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output.
It does not read any other values from “the outside world” — the world outside
of the function’s scope — and it does not modify any values in the outside world
Functional	programming is	a	way	of	writing software	applications	using	only	pure	functions and	immutable	values.
FP means programming with pure functions, and a pure function is one that lacks side effects…
A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type
A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a).
For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else.
In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We
sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant.
FP in Scala
by	Paul	Chiusano	
and	Runar	Bjarnason
@pchiusano @runarorama
by	Sam	Halliday
@fommil
by	Alvin	Alexander
@alvinalexander
Definitions	of	Functional	Programming
1.2	Pure	Functional	Programming
Functional	Programming	is	the	act	of	writing	programs	with	pure	functions.	Pure	functions	have	three	properties:
• Total:	return	a	value	for	every	possible	input
•	Deterministic:	return	the	same	value	for	the	same	input
• Inculpable:	no	(direct)	interaction	with	the	world	or	program	state.
Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is
easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is
easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side
effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is
impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions.
PF = ODI + NSE	
Pure	Functions	=	Output	Depends	only	on	Input	+ No	Side	Effects)
FP is just programming with functions. Functions are:
1. Total: They return an output for every input.
2. Deterministic: They return the same output for the same input.
3. Pure: Their only effect is computing the output.
The rest is just composition you can learn over time.
john Ⓐ De Goes
1. A	pure	function	depends	only	on	(a)	its	declared	input	parameters	and	(b)	its	algorithm	to	produce	its	result.	
A	pure	function	has	no	“back	doors,”	which	means:
1. Its	result	can’t depend	on reading any	hidden	value	outside	of	the	function	scope,	such	as	another	field	in	the	same	class or	global	variables.
2. It	cannot	modify any hidden	fields	outside	of	the	function	scope,	such	as	other	mutable fields	in	the	same	class or	global	variables.
3. It	cannot	depend on	any	external	I/O.	It	can’t	rely	on	input	from	files,	databases,	web	services,	UIs,	etc;	it	can’t	produce	output,	such	as	
writing to	a	file,	database,	or	web	service,	writing to	a	screen,	etc.
2.	A	pure	function	does	not	modify its	input	parameters.
A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output.
It does not read any other values from “the outside world” — the world outside
of the function’s scope — and it does not modify any values in the outside world
Functional	programming is	a	way	of	writing software	applications	using	only	pure	functions and	immutable	values.
FP means programming with pure functions, and a pure function is one that lacks side effects…
A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type
A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a).
For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else.
In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We
sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant.
FP in Scala
by	Paul	Chiusano	
and	Runar	Bjarnason
@pchiusano @runarorama
by	Sam	Halliday
@fommil
by	Alvin	Alexander
@alvinalexander
Definitions	of	Functional	Programming
1.2	Pure	Functional	Programming
Functional	Programming	is	the	act	of	writing	programs	with	pure	functions.	Pure	functions	have	three	properties:
•	Total:	return	a	value	for	every	possible	input
•	Deterministic:	return	the	same	value	for	the	same	input
•	Inculpable:	no	(direct)	interaction	with	the	world	or	program	state.
Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is
easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is
easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side
effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is
impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions.
FP is just programming with functions. Functions are:
1. Total: They return an output for every input.
2. Deterministic: They return the same output for the same input.
3. Pure: Their only effect is computing the output.
The rest is just composition you can learn over time.
TOTALITY
john Ⓐ De Goes
PF = ODI + NSE	
Pure	Functions	=	Output	Depends	only	on	Input	+ No	Side	Effects)
A pure function has no side effects,
meaning that it does not read
anything from the outside world or
write anything to the outside world.
As a result of 1, if a pure function is
called with an input parameter x an
infinite number of times, it will
always return the same result y.
This is unlike an OOP method, which
can depend on other fields in the
same class as the method.
1. A	pure	function	depends	only	on	(a)	its	declared	input	parameters	and	(b)	its	algorithm	to	produce	its	result.	
A	pure	function	has	no	“back	doors,”	which	means:
1. Its	result	can’t depend	on reading any	hidden	value	outside	of	the	function	scope,	such	as	another	field	in	the	same	class or	global	variables.
2. It	cannot	modify any hidden	fields	outside	of	the	function	scope,	such	as	other	mutable fields	in	the	same	class or	global	variables.
3. It	cannot	depend on	any	external	I/O.	It	can’t	rely	on	input	from	files,	databases,	web	services,	UIs,	etc;	it	can’t	produce	output,	such	as	
writing to	a	file,	database,	or	web	service,	writing to	a	screen,	etc.
2.	A	pure	function	does	not	modify its	input	parameters.
A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output.
It does not read any other values from “the outside world” — the world outside
of the function’s scope — and it does not modify any values in the outside world
Functional	programming is	a	way	of	writing software	applications	using	only	pure	functions and	immutable	values.
FP means programming with pure functions, and a pure function is one that lacks side effects…
A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type
A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a).
For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else.
In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We
sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant.
FP in Scala
by	Paul	Chiusano	
and	Runar	Bjarnason
@pchiusano @runarorama
by	Sam	Halliday
@fommil
by	Alvin	Alexander
@alvinalexander
Definitions	of	Functional	Programming
1.2	Pure	Functional	Programming
Functional	Programming	is	the	act	of	writing	programs	with	pure	functions.	Pure	functions	have	three	properties:
•	Total:	return	a	value	for	every	possible	input
•	Deterministic:	return	the	same	value	for	the	same	input
•	Inculpable:	no	(direct)	interaction	with	the	world	or	program	state.
Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is
easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is
easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side
effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is
impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions.
FP is just programming with functions. Functions are:
1. Total: They return an output for every input.
2. Deterministic: They return the same output for the same input.
3. Pure: Their only effect is computing the output.
The rest is just composition you can learn over time.
DETERMINISM
john Ⓐ De Goes
PF = ODI + NSE	
Pure	Functions	=	Output	Depends	only	on	Input	+ No	Side	Effects)
A pure function has no side effects,
meaning that it does not read
anything from the outside world or
write anything to the outside world.
As a result of 1, if a pure function is
called with an input parameter x an
infinite number of times, it will
always return the same result y.
This is unlike an OOP method, which
can depend on other fields in the
same class as the method.
1. A	pure	function	depends	only	on	(a)	its	declared	input	parameters	and	(b)	its	algorithm	to	produce	its	result.	
A	pure	function	has	no	“back	doors,”	which	means:
1. Its	result	can’t depend	on reading any	hidden	value	outside	of	the	function	scope,	such	as	another	field	in	the	same	class or	global	variables.
2. It	cannot	modify any hidden	fields	outside	of	the	function	scope,	such	as	other	mutable fields	in	the	same	class or	global	variables.
3. It	cannot	depend on	any	external	I/O.	It	can’t	rely	on	input	from	files,	databases,	web	services,	UIs,	etc;	it	can’t	produce	output,	such	as	
writing to	a	file,	database,	or	web	service,	writing to	a	screen,	etc.
2.	A	pure	function	does	not	modify its	input	parameters.
A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output.
It does not read any other values from “the outside world” — the world outside
of the function’s scope — and it does not modify any values in the outside world
Functional	programming is	a	way	of	writing software	applications	using	only	pure	functions and	immutable	values.
FP means programming with pure functions, and a pure function is one that lacks side effects…
A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type
A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a).
For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else.
In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes
qualify such functions as pure functions to make this more explicit, but this is somewhat redundant.
FP in Scala
by	Paul	Chiusano	
and	Runar	Bjarnason
@pchiusano @runarorama
by	Sam	Halliday
@fommil
by	Alvin	Alexander
@alvinalexander
Definitions	of	Functional	Programming
1.2	Pure	Functional	Programming
Functional	Programming	is	the	act	of	writing	programs	with	pure	functions.	Pure	functions	have	three	properties:
•	Total:	return	a	value	for	every	possible	input
•	Deterministic:	return	the	same	value	for	the	same	input
•	Inculpable:	no	(direct)	interaction	with	the	world	or	program	state.
Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is
easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is
easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side
effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is
impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions.
FP is just programming with functions. Functions are:
1. Total: They return an output for every input.
2. Deterministic: They return the same output for the same input.
3. Pure: Their only effect is computing the output.
The rest is just composition you can learn over time.
NO	SIDE	EFFECTS
john Ⓐ De Goes
PF = ODI + NSE	
Pure	Functions	=	Output	Depends	only	on	Input	+ No	Side	Effects)
A pure function has no side effects,
meaning that it does not read
anything from the outside world or
write anything to the outside world.
As a result of 1, if a pure function is
called with an input parameter x an
infinite number of times, it will
always return the same result y.
This is unlike an OOP method, which
can depend on other fields in the
same class as the method.
1. A	pure	function	depends	only	on	(a)	its	declared	input	parameters	and	(b)	its	algorithm	to	produce	its	result.	
A	pure	function	has	no	“back	doors,”	which	means:
1. Its	result	can’t depend	on reading any	hidden	value	outside	of	the	function	scope,	such	as	another	field	in	the	same	class or	global	variables.
2. It	cannot	modify any hidden	fields	outside	of	the	function	scope,	such	as	other	mutable fields	in	the	same	class or	global	variables.
3. It	cannot	depend on	any	external	I/O.	It	can’t	rely	on	input	from	files,	databases,	web	services,	UIs,	etc;	it	can’t	produce	output,	such	as	
writing to	a	file,	database,	or	web	service,	writing to	a	screen,	etc.
2.	A	pure	function	does	not	modify its	input	parameters.
A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output.
It does not read any other values from “the outside world” — the world outside
of the function’s scope — and it does not modify any values in the outside world
Functional	programming is	a	way	of	writing software	applications	using	only	pure	functions and	immutable	values.
FP means programming with pure functions, and a pure function is one that lacks side effects…
A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type
A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a).
For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else.
In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We
sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant.
FP in Scala
by	Paul	Chiusano	
and	Runar	Bjarnason
@pchiusano @runarorama
by	Sam	Halliday
@fommil
by	Alvin	Alexander
@alvinalexander
Definitions	of	Functional	Programming
1.2	Pure	Functional	Programming
Functional	Programming	is	the	act	of	writing	programs	with	pure	functions.	Pure	functions	have	three	properties:
•	Total:	return	a	value	for	every	possible	input
•	Deterministic:	return	the	same	value	for	the	same	input
•	Inculpable:	no	(direct)	interaction	with	the	world	or	program	state.
Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is
easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is
easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side
effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is
impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions.
FP is just programming with functions. Functions are:
1. Total: They return an output for every input.
2. Deterministic: They return the same output for the same input.
3. Pure: Their only effect is computing the output.
The rest is just composition you can learn over time.
PURITY
john Ⓐ De Goes
A pure function has no side effects,
meaning that it does not read
anything from the outside world or
write anything to the outside world.
As a result of 1, if a pure function is
called with an input parameter x an
infinite number of times, it will
always return the same result y.
This is unlike an OOP method, which
can depend on other fields in the
same class as the method.
PF = ODI + NSE	
Pure	Functions	=	Output	Depends	only	on	Input	+ No	Side	Effects)
We can formalize this idea of pure functions using the concept of referential transparency (RT). This is a property of
expressions in general and not just functions. For the purposes of our discussion, consider an expression to be any part of a
program that can be evaluated to a result—anything that you could type into the Scala interpreter and get an answer. For
example, 2 + 3 is an expression that applies the pure function + to the values 2 and 3 (which are also expressions). This has no
side effect. The evaluation of this expression results in the same value 5 every time. In fact, if we saw 2 + 3 in a program we
could simply replace it with the value 5 and it wouldn’t change a thing about the meaning of our program.
This is all it means for an expression to be referentially transparent—in any program, the expression can be replaced by its
result without changing the meaning of the program. And we say that a function is pure if calling it with RT arguments is
also RT.
Referential	transparency	and	purity
An expression E is	referentially	transparent if,	for	all	programs P,	all	occurrences	of E in P can	be	replaced	by	the	result	of	
evaluating E without	affecting	the	meaning	of P.
A	function f	is pure if	the	expression	f(x)	is	referentially	transparent for	all	referentially	transparent	x.3
3 There are some subtleties to this definition, and we’ll refine it later in this book. See the chapter notes at our
GitHub site (https://github.com/pchiusano/fpinscala; see the preface) for more discussion.
Referential	Transparency	and	Purity
Functional Programming in Scala
(by	Paul	Chiusano	and	Runar	Bjarnason)
@pchiusano @runarorama

More Related Content

What's hot

Natural Transformations
Natural TransformationsNatural Transformations
Natural TransformationsPhilip Schwarz
 
Compositionality and Category Theory - a montage of slides/transcript for sec...
Compositionality and Category Theory - a montage of slides/transcript for sec...Compositionality and Category Theory - a montage of slides/transcript for sec...
Compositionality and Category Theory - a montage of slides/transcript for sec...Philip Schwarz
 
Monad as functor with pair of natural transformations
Monad as functor with pair of natural transformationsMonad as functor with pair of natural transformations
Monad as functor with pair of natural transformationsPhilip Schwarz
 
Unison Language - Contact
Unison Language - ContactUnison Language - Contact
Unison Language - ContactPhilip Schwarz
 
The Expression Problem - Part 2
The Expression Problem - Part 2The Expression Problem - Part 2
The Expression Problem - Part 2Philip Schwarz
 
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3Philip Schwarz
 
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2Philip Schwarz
 
‘go-to’ general-purpose sequential collections - from Java To Scala
‘go-to’ general-purpose sequential collections -from Java To Scala‘go-to’ general-purpose sequential collections -from Java To Scala
‘go-to’ general-purpose sequential collections - from Java To ScalaPhilip Schwarz
 
Control structures functions and modules in python programming
Control structures functions and modules in python programmingControl structures functions and modules in python programming
Control structures functions and modules in python programmingSrinivas Narasegouda
 
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...Philip Schwarz
 
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...Function Applicative for Great Good of Palindrome Checker Function - Polyglot...
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...Philip Schwarz
 
Point free or die - tacit programming in Haskell and beyond
Point free or die - tacit programming in Haskell and beyondPoint free or die - tacit programming in Haskell and beyond
Point free or die - tacit programming in Haskell and beyondPhilip Schwarz
 
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...Philip Schwarz
 
Lesson 02 python keywords and identifiers
Lesson 02   python keywords and identifiersLesson 02   python keywords and identifiers
Lesson 02 python keywords and identifiersNilimesh Halder
 
Implicit conversion and parameters
Implicit conversion and parametersImplicit conversion and parameters
Implicit conversion and parametersKnoldus Inc.
 
Intro to functional programming
Intro to functional programmingIntro to functional programming
Intro to functional programmingAssaf Gannon
 
Function Composition - forward composition versus backward composition
Function Composition - forward composition versus backward compositionFunction Composition - forward composition versus backward composition
Function Composition - forward composition versus backward compositionPhilip Schwarz
 

What's hot (20)

Natural Transformations
Natural TransformationsNatural Transformations
Natural Transformations
 
Compositionality and Category Theory - a montage of slides/transcript for sec...
Compositionality and Category Theory - a montage of slides/transcript for sec...Compositionality and Category Theory - a montage of slides/transcript for sec...
Compositionality and Category Theory - a montage of slides/transcript for sec...
 
Monad as functor with pair of natural transformations
Monad as functor with pair of natural transformationsMonad as functor with pair of natural transformations
Monad as functor with pair of natural transformations
 
Monad Fact #6
Monad Fact #6Monad Fact #6
Monad Fact #6
 
Introduction to Python
Introduction to Python  Introduction to Python
Introduction to Python
 
Unison Language - Contact
Unison Language - ContactUnison Language - Contact
Unison Language - Contact
 
The Expression Problem - Part 2
The Expression Problem - Part 2The Expression Problem - Part 2
The Expression Problem - Part 2
 
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3
Game of Life - Polyglot FP - Haskell - Scala - Unison - Part 3
 
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2
Scala 3 by Example - Algebraic Data Types for Domain Driven Design - Part 2
 
Kleisli Composition
Kleisli CompositionKleisli Composition
Kleisli Composition
 
‘go-to’ general-purpose sequential collections - from Java To Scala
‘go-to’ general-purpose sequential collections -from Java To Scala‘go-to’ general-purpose sequential collections -from Java To Scala
‘go-to’ general-purpose sequential collections - from Java To Scala
 
Control structures functions and modules in python programming
Control structures functions and modules in python programmingControl structures functions and modules in python programming
Control structures functions and modules in python programming
 
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...
Refactoring: A First Example - Martin Fowler’s First Example of Refactoring, ...
 
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...Function Applicative for Great Good of Palindrome Checker Function - Polyglot...
Function Applicative for Great Good of Palindrome Checker Function - Polyglot...
 
Point free or die - tacit programming in Haskell and beyond
Point free or die - tacit programming in Haskell and beyondPoint free or die - tacit programming in Haskell and beyond
Point free or die - tacit programming in Haskell and beyond
 
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...
Game of Life - Polyglot FP - Haskell, Scala, Unison - Part 2 - with minor cor...
 
Lesson 02 python keywords and identifiers
Lesson 02   python keywords and identifiersLesson 02   python keywords and identifiers
Lesson 02 python keywords and identifiers
 
Implicit conversion and parameters
Implicit conversion and parametersImplicit conversion and parameters
Implicit conversion and parameters
 
Intro to functional programming
Intro to functional programmingIntro to functional programming
Intro to functional programming
 
Function Composition - forward composition versus backward composition
Function Composition - forward composition versus backward compositionFunction Composition - forward composition versus backward composition
Function Composition - forward composition versus backward composition
 

Similar to Comparing Definitions of Functional Programming

Pure functions and usage in Angular
Pure functions and usage in AngularPure functions and usage in Angular
Pure functions and usage in AngularMA Jiangfan
 
Functions in Python.pdfnsjiwshkwijjahuwjwjw
Functions in Python.pdfnsjiwshkwijjahuwjwjwFunctions in Python.pdfnsjiwshkwijjahuwjwjw
Functions in Python.pdfnsjiwshkwijjahuwjwjwMayankSinghRawat6
 
Functional Swift
Functional SwiftFunctional Swift
Functional SwiftGeison Goes
 
Functions in c++
Functions in c++Functions in c++
Functions in c++Asaye Dilbo
 
Introduction to C Language - Version 1.0 by Mark John Lado
Introduction to C Language - Version 1.0 by Mark John LadoIntroduction to C Language - Version 1.0 by Mark John Lado
Introduction to C Language - Version 1.0 by Mark John LadoMark John Lado, MIT
 
Functions-Computer programming
Functions-Computer programmingFunctions-Computer programming
Functions-Computer programmingnmahi96
 
Python functional programming
Python functional programmingPython functional programming
Python functional programmingGeison Goes
 
Why functional programming in C# & F#
Why functional programming in C# & F#Why functional programming in C# & F#
Why functional programming in C# & F#Riccardo Terrell
 
Presentation1.pptx
Presentation1.pptxPresentation1.pptx
Presentation1.pptxAFANJIPHILL
 
Introduction to c programming
Introduction to c programmingIntroduction to c programming
Introduction to c programmingAMAN ANAND
 
Vendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxVendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxGuillaume Saint Etienne
 
Functional programming in TypeScript
Functional programming in TypeScriptFunctional programming in TypeScript
Functional programming in TypeScriptbinDebug WorkSpace
 
Functional programming
Functional programmingFunctional programming
Functional programmingKibru Demeke
 
Functions assignment
Functions assignmentFunctions assignment
Functions assignmentAhmad Kamal
 

Similar to Comparing Definitions of Functional Programming (20)

Pure functions and usage in Angular
Pure functions and usage in AngularPure functions and usage in Angular
Pure functions and usage in Angular
 
Functional Go
Functional GoFunctional Go
Functional Go
 
Functions in Python.pdfnsjiwshkwijjahuwjwjw
Functions in Python.pdfnsjiwshkwijjahuwjwjwFunctions in Python.pdfnsjiwshkwijjahuwjwjw
Functions in Python.pdfnsjiwshkwijjahuwjwjw
 
Functional Swift
Functional SwiftFunctional Swift
Functional Swift
 
User Defined Functions
User Defined FunctionsUser Defined Functions
User Defined Functions
 
C functions list
C functions listC functions list
C functions list
 
Functions in c++
Functions in c++Functions in c++
Functions in c++
 
Introduction to C Language - Version 1.0 by Mark John Lado
Introduction to C Language - Version 1.0 by Mark John LadoIntroduction to C Language - Version 1.0 by Mark John Lado
Introduction to C Language - Version 1.0 by Mark John Lado
 
Functions-Computer programming
Functions-Computer programmingFunctions-Computer programming
Functions-Computer programming
 
C interview questions
C interview  questionsC interview  questions
C interview questions
 
Python functional programming
Python functional programmingPython functional programming
Python functional programming
 
Why functional programming in C# & F#
Why functional programming in C# & F#Why functional programming in C# & F#
Why functional programming in C# & F#
 
Presentation1.pptx
Presentation1.pptxPresentation1.pptx
Presentation1.pptx
 
Introduction to c programming
Introduction to c programmingIntroduction to c programming
Introduction to c programming
 
Vendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxVendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptx
 
Functional programming in TypeScript
Functional programming in TypeScriptFunctional programming in TypeScript
Functional programming in TypeScript
 
Functional programming
Functional programmingFunctional programming
Functional programming
 
Functions assignment
Functions assignmentFunctions assignment
Functions assignment
 
Lecture 11 - Functions
Lecture 11 - FunctionsLecture 11 - Functions
Lecture 11 - Functions
 
Function overloading
Function overloadingFunction overloading
Function overloading
 

More from Philip Schwarz

Folding Cheat Sheet #4 - fourth in a series
Folding Cheat Sheet #4 - fourth in a seriesFolding Cheat Sheet #4 - fourth in a series
Folding Cheat Sheet #4 - fourth in a seriesPhilip Schwarz
 
Folding Cheat Sheet #3 - third in a series
Folding Cheat Sheet #3 - third in a seriesFolding Cheat Sheet #3 - third in a series
Folding Cheat Sheet #3 - third in a seriesPhilip Schwarz
 
Folding Cheat Sheet #2 - second in a series
Folding Cheat Sheet #2 - second in a seriesFolding Cheat Sheet #2 - second in a series
Folding Cheat Sheet #2 - second in a seriesPhilip Schwarz
 
Folding Cheat Sheet #1 - first in a series
Folding Cheat Sheet #1 - first in a seriesFolding Cheat Sheet #1 - first in a series
Folding Cheat Sheet #1 - first in a seriesPhilip Schwarz
 
Scala Left Fold Parallelisation - Three Approaches
Scala Left Fold Parallelisation- Three ApproachesScala Left Fold Parallelisation- Three Approaches
Scala Left Fold Parallelisation - Three ApproachesPhilip Schwarz
 
Tagless Final Encoding - Algebras and Interpreters and also Programs
Tagless Final Encoding - Algebras and Interpreters and also ProgramsTagless Final Encoding - Algebras and Interpreters and also Programs
Tagless Final Encoding - Algebras and Interpreters and also ProgramsPhilip Schwarz
 
Fusing Transformations of Strict Scala Collections with Views
Fusing Transformations of Strict Scala Collections with ViewsFusing Transformations of Strict Scala Collections with Views
Fusing Transformations of Strict Scala Collections with ViewsPhilip Schwarz
 
A sighting of traverse_ function in Practical FP in Scala
A sighting of traverse_ function in Practical FP in ScalaA sighting of traverse_ function in Practical FP in Scala
A sighting of traverse_ function in Practical FP in ScalaPhilip Schwarz
 
A sighting of traverseFilter and foldMap in Practical FP in Scala
A sighting of traverseFilter and foldMap in Practical FP in ScalaA sighting of traverseFilter and foldMap in Practical FP in Scala
A sighting of traverseFilter and foldMap in Practical FP in ScalaPhilip Schwarz
 
A sighting of sequence function in Practical FP in Scala
A sighting of sequence function in Practical FP in ScalaA sighting of sequence function in Practical FP in Scala
A sighting of sequence function in Practical FP in ScalaPhilip Schwarz
 
N-Queens Combinatorial Puzzle meets Cats
N-Queens Combinatorial Puzzle meets CatsN-Queens Combinatorial Puzzle meets Cats
N-Queens Combinatorial Puzzle meets CatsPhilip Schwarz
 
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...Kleisli composition, flatMap, join, map, unit - implementation and interrelat...
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...Philip Schwarz
 
The aggregate function - from sequential and parallel folds to parallel aggre...
The aggregate function - from sequential and parallel folds to parallel aggre...The aggregate function - from sequential and parallel folds to parallel aggre...
The aggregate function - from sequential and parallel folds to parallel aggre...Philip Schwarz
 
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
Nat, List and Option Monoids -from scratch -Combining and Folding -an exampleNat, List and Option Monoids -from scratch -Combining and Folding -an example
Nat, List and Option Monoids - from scratch - Combining and Folding - an examplePhilip Schwarz
 
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
Nat, List and Option Monoids -from scratch -Combining and Folding -an exampleNat, List and Option Monoids -from scratch -Combining and Folding -an example
Nat, List and Option Monoids - from scratch - Combining and Folding - an examplePhilip Schwarz
 
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...Philip Schwarz
 
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...
Sum and Product Types -The Fruit Salad & Fruit Snack Example - From F# to Ha...Sum and Product Types -The Fruit Salad & Fruit Snack Example - From F# to Ha...
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...Philip Schwarz
 
Algebraic Data Types for Data Oriented Programming - From Haskell and Scala t...
Algebraic Data Types forData Oriented Programming - From Haskell and Scala t...Algebraic Data Types forData Oriented Programming - From Haskell and Scala t...
Algebraic Data Types for Data Oriented Programming - From Haskell and Scala t...Philip Schwarz
 
Jordan Peterson - The pursuit of meaning and related ethical axioms
Jordan Peterson - The pursuit of meaning and related ethical axiomsJordan Peterson - The pursuit of meaning and related ethical axioms
Jordan Peterson - The pursuit of meaning and related ethical axiomsPhilip Schwarz
 
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...Philip Schwarz
 

More from Philip Schwarz (20)

Folding Cheat Sheet #4 - fourth in a series
Folding Cheat Sheet #4 - fourth in a seriesFolding Cheat Sheet #4 - fourth in a series
Folding Cheat Sheet #4 - fourth in a series
 
Folding Cheat Sheet #3 - third in a series
Folding Cheat Sheet #3 - third in a seriesFolding Cheat Sheet #3 - third in a series
Folding Cheat Sheet #3 - third in a series
 
Folding Cheat Sheet #2 - second in a series
Folding Cheat Sheet #2 - second in a seriesFolding Cheat Sheet #2 - second in a series
Folding Cheat Sheet #2 - second in a series
 
Folding Cheat Sheet #1 - first in a series
Folding Cheat Sheet #1 - first in a seriesFolding Cheat Sheet #1 - first in a series
Folding Cheat Sheet #1 - first in a series
 
Scala Left Fold Parallelisation - Three Approaches
Scala Left Fold Parallelisation- Three ApproachesScala Left Fold Parallelisation- Three Approaches
Scala Left Fold Parallelisation - Three Approaches
 
Tagless Final Encoding - Algebras and Interpreters and also Programs
Tagless Final Encoding - Algebras and Interpreters and also ProgramsTagless Final Encoding - Algebras and Interpreters and also Programs
Tagless Final Encoding - Algebras and Interpreters and also Programs
 
Fusing Transformations of Strict Scala Collections with Views
Fusing Transformations of Strict Scala Collections with ViewsFusing Transformations of Strict Scala Collections with Views
Fusing Transformations of Strict Scala Collections with Views
 
A sighting of traverse_ function in Practical FP in Scala
A sighting of traverse_ function in Practical FP in ScalaA sighting of traverse_ function in Practical FP in Scala
A sighting of traverse_ function in Practical FP in Scala
 
A sighting of traverseFilter and foldMap in Practical FP in Scala
A sighting of traverseFilter and foldMap in Practical FP in ScalaA sighting of traverseFilter and foldMap in Practical FP in Scala
A sighting of traverseFilter and foldMap in Practical FP in Scala
 
A sighting of sequence function in Practical FP in Scala
A sighting of sequence function in Practical FP in ScalaA sighting of sequence function in Practical FP in Scala
A sighting of sequence function in Practical FP in Scala
 
N-Queens Combinatorial Puzzle meets Cats
N-Queens Combinatorial Puzzle meets CatsN-Queens Combinatorial Puzzle meets Cats
N-Queens Combinatorial Puzzle meets Cats
 
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...Kleisli composition, flatMap, join, map, unit - implementation and interrelat...
Kleisli composition, flatMap, join, map, unit - implementation and interrelat...
 
The aggregate function - from sequential and parallel folds to parallel aggre...
The aggregate function - from sequential and parallel folds to parallel aggre...The aggregate function - from sequential and parallel folds to parallel aggre...
The aggregate function - from sequential and parallel folds to parallel aggre...
 
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
Nat, List and Option Monoids -from scratch -Combining and Folding -an exampleNat, List and Option Monoids -from scratch -Combining and Folding -an example
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
 
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
Nat, List and Option Monoids -from scratch -Combining and Folding -an exampleNat, List and Option Monoids -from scratch -Combining and Folding -an example
Nat, List and Option Monoids - from scratch - Combining and Folding - an example
 
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...
The Sieve of Eratosthenes - Part II - Genuine versus Unfaithful Sieve - Haske...
 
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...
Sum and Product Types -The Fruit Salad & Fruit Snack Example - From F# to Ha...Sum and Product Types -The Fruit Salad & Fruit Snack Example - From F# to Ha...
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...
 
Algebraic Data Types for Data Oriented Programming - From Haskell and Scala t...
Algebraic Data Types forData Oriented Programming - From Haskell and Scala t...Algebraic Data Types forData Oriented Programming - From Haskell and Scala t...
Algebraic Data Types for Data Oriented Programming - From Haskell and Scala t...
 
Jordan Peterson - The pursuit of meaning and related ethical axioms
Jordan Peterson - The pursuit of meaning and related ethical axiomsJordan Peterson - The pursuit of meaning and related ethical axioms
Jordan Peterson - The pursuit of meaning and related ethical axioms
 
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...
Defining filter using (a) recursion (b) folding (c) folding with S, B and I c...
 

Recently uploaded

SpotFlow: Tracking Method Calls and States at Runtime
SpotFlow: Tracking Method Calls and States at RuntimeSpotFlow: Tracking Method Calls and States at Runtime
SpotFlow: Tracking Method Calls and States at Runtimeandrehoraa
 
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...Natan Silnitsky
 
Odoo 14 - eLearning Module In Odoo 14 Enterprise
Odoo 14 - eLearning Module In Odoo 14 EnterpriseOdoo 14 - eLearning Module In Odoo 14 Enterprise
Odoo 14 - eLearning Module In Odoo 14 Enterprisepreethippts
 
Post Quantum Cryptography – The Impact on Identity
Post Quantum Cryptography – The Impact on IdentityPost Quantum Cryptography – The Impact on Identity
Post Quantum Cryptography – The Impact on Identityteam-WIBU
 
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...Matt Ray
 
Simplifying Microservices & Apps - The art of effortless development - Meetup...
Simplifying Microservices & Apps - The art of effortless development - Meetup...Simplifying Microservices & Apps - The art of effortless development - Meetup...
Simplifying Microservices & Apps - The art of effortless development - Meetup...Rob Geurden
 
英国UN学位证,北安普顿大学毕业证书1:1制作
英国UN学位证,北安普顿大学毕业证书1:1制作英国UN学位证,北安普顿大学毕业证书1:1制作
英国UN学位证,北安普顿大学毕业证书1:1制作qr0udbr0
 
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...Angel Borroy López
 
Cyber security and its impact on E commerce
Cyber security and its impact on E commerceCyber security and its impact on E commerce
Cyber security and its impact on E commercemanigoyal112
 
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...confluent
 
Lecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptLecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptesrabilgic2
 
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdf
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdfInnovate and Collaborate- Harnessing the Power of Open Source Software.pdf
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdfYashikaSharma391629
 
Unveiling the Future: Sylius 2.0 New Features
Unveiling the Future: Sylius 2.0 New FeaturesUnveiling the Future: Sylius 2.0 New Features
Unveiling the Future: Sylius 2.0 New FeaturesŁukasz Chruściel
 
Balasore Best It Company|| Top 10 IT Company || Balasore Software company Odisha
Balasore Best It Company|| Top 10 IT Company || Balasore Software company OdishaBalasore Best It Company|| Top 10 IT Company || Balasore Software company Odisha
Balasore Best It Company|| Top 10 IT Company || Balasore Software company Odishasmiwainfosol
 
Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringHironori Washizaki
 
Large Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLarge Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLionel Briand
 
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte Germany
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte GermanySuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte Germany
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte GermanyChristoph Pohl
 
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdf
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdfExploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdf
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdfkalichargn70th171
 
Patterns for automating API delivery. API conference
Patterns for automating API delivery. API conferencePatterns for automating API delivery. API conference
Patterns for automating API delivery. API conferencessuser9e7c64
 
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptx
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptxReal-time Tracking and Monitoring with Cargo Cloud Solutions.pptx
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptxRTS corp
 

Recently uploaded (20)

SpotFlow: Tracking Method Calls and States at Runtime
SpotFlow: Tracking Method Calls and States at RuntimeSpotFlow: Tracking Method Calls and States at Runtime
SpotFlow: Tracking Method Calls and States at Runtime
 
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...
Taming Distributed Systems: Key Insights from Wix's Large-Scale Experience - ...
 
Odoo 14 - eLearning Module In Odoo 14 Enterprise
Odoo 14 - eLearning Module In Odoo 14 EnterpriseOdoo 14 - eLearning Module In Odoo 14 Enterprise
Odoo 14 - eLearning Module In Odoo 14 Enterprise
 
Post Quantum Cryptography – The Impact on Identity
Post Quantum Cryptography – The Impact on IdentityPost Quantum Cryptography – The Impact on Identity
Post Quantum Cryptography – The Impact on Identity
 
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
 
Simplifying Microservices & Apps - The art of effortless development - Meetup...
Simplifying Microservices & Apps - The art of effortless development - Meetup...Simplifying Microservices & Apps - The art of effortless development - Meetup...
Simplifying Microservices & Apps - The art of effortless development - Meetup...
 
英国UN学位证,北安普顿大学毕业证书1:1制作
英国UN学位证,北安普顿大学毕业证书1:1制作英国UN学位证,北安普顿大学毕业证书1:1制作
英国UN学位证,北安普顿大学毕业证书1:1制作
 
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
Alfresco TTL#157 - Troubleshooting Made Easy: Deciphering Alfresco mTLS Confi...
 
Cyber security and its impact on E commerce
Cyber security and its impact on E commerceCyber security and its impact on E commerce
Cyber security and its impact on E commerce
 
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...
Catch the Wave: SAP Event-Driven and Data Streaming for the Intelligence Ente...
 
Lecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).pptLecture # 8 software design and architecture (SDA).ppt
Lecture # 8 software design and architecture (SDA).ppt
 
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdf
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdfInnovate and Collaborate- Harnessing the Power of Open Source Software.pdf
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdf
 
Unveiling the Future: Sylius 2.0 New Features
Unveiling the Future: Sylius 2.0 New FeaturesUnveiling the Future: Sylius 2.0 New Features
Unveiling the Future: Sylius 2.0 New Features
 
Balasore Best It Company|| Top 10 IT Company || Balasore Software company Odisha
Balasore Best It Company|| Top 10 IT Company || Balasore Software company OdishaBalasore Best It Company|| Top 10 IT Company || Balasore Software company Odisha
Balasore Best It Company|| Top 10 IT Company || Balasore Software company Odisha
 
Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their Engineering
 
Large Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and RepairLarge Language Models for Test Case Evolution and Repair
Large Language Models for Test Case Evolution and Repair
 
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte Germany
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte GermanySuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte Germany
SuccessFactors 1H 2024 Release - Sneak-Peek by Deloitte Germany
 
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdf
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdfExploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdf
Exploring Selenium_Appium Frameworks for Seamless Integration with HeadSpin.pdf
 
Patterns for automating API delivery. API conference
Patterns for automating API delivery. API conferencePatterns for automating API delivery. API conference
Patterns for automating API delivery. API conference
 
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptx
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptxReal-time Tracking and Monitoring with Cargo Cloud Solutions.pptx
Real-time Tracking and Monitoring with Cargo Cloud Solutions.pptx
 

Comparing Definitions of Functional Programming

  • 2. 1. A pure function depends only on (a) its declared input parameters and (b) its algorithm to produce its result. A pure function has no “back doors,” which means: 1. Its result can’t depend on reading any hidden value outside of the function scope, such as another field in the same class or global variables. 2. It cannot modify any hidden fields outside of the function scope, such as other mutable fields in the same class or global variables. 3. It cannot depend on any external I/O. It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc. 2. A pure function does not modify its input parameters. A pure function has no side effects, meaning that it does not read anything from the outside world or write anything to the outside world. As a result of 1, if a pure function is called with an input parameter x an infinite number of times, it will always return the same result y. This is unlike an OOP method, which can depend on other fields in the same class as the method. A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world Functional programming is a way of writing software applications using only pure functions and immutable values. FP means programming with pure functions, and a pure function is one that lacks side effects… A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a). For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else. In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant. FP in Scala by Paul Chiusano and Runar Bjarnason @pchiusano @runarorama by Sam Halliday @fommil by Alvin Alexander @alvinalexander Definitions of Functional Programming 1.2 Pure Functional Programming Functional Programming is the act of writing programs with pure functions. Pure functions have three properties: • Total: return a value for every possible input • Deterministic: return the same value for the same input • Inculpable: no (direct) interaction with the world or program state. Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions. PF = ODI + NSE Pure Functions = Output Depends only on Input + No Side Effects) FP is just programming with functions. Functions are: 1. Total: They return an output for every input. 2. Deterministic: They return the same output for the same input. 3. Pure: Their only effect is computing the output. The rest is just composition you can learn over time. john Ⓐ De Goes
  • 3. 1. A pure function depends only on (a) its declared input parameters and (b) its algorithm to produce its result. A pure function has no “back doors,” which means: 1. Its result can’t depend on reading any hidden value outside of the function scope, such as another field in the same class or global variables. 2. It cannot modify any hidden fields outside of the function scope, such as other mutable fields in the same class or global variables. 3. It cannot depend on any external I/O. It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc. 2. A pure function does not modify its input parameters. A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world Functional programming is a way of writing software applications using only pure functions and immutable values. FP means programming with pure functions, and a pure function is one that lacks side effects… A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a). For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else. In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant. FP in Scala by Paul Chiusano and Runar Bjarnason @pchiusano @runarorama by Sam Halliday @fommil by Alvin Alexander @alvinalexander Definitions of Functional Programming 1.2 Pure Functional Programming Functional Programming is the act of writing programs with pure functions. Pure functions have three properties: • Total: return a value for every possible input • Deterministic: return the same value for the same input • Inculpable: no (direct) interaction with the world or program state. Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions. FP is just programming with functions. Functions are: 1. Total: They return an output for every input. 2. Deterministic: They return the same output for the same input. 3. Pure: Their only effect is computing the output. The rest is just composition you can learn over time. TOTALITY john Ⓐ De Goes PF = ODI + NSE Pure Functions = Output Depends only on Input + No Side Effects) A pure function has no side effects, meaning that it does not read anything from the outside world or write anything to the outside world. As a result of 1, if a pure function is called with an input parameter x an infinite number of times, it will always return the same result y. This is unlike an OOP method, which can depend on other fields in the same class as the method.
  • 4. 1. A pure function depends only on (a) its declared input parameters and (b) its algorithm to produce its result. A pure function has no “back doors,” which means: 1. Its result can’t depend on reading any hidden value outside of the function scope, such as another field in the same class or global variables. 2. It cannot modify any hidden fields outside of the function scope, such as other mutable fields in the same class or global variables. 3. It cannot depend on any external I/O. It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc. 2. A pure function does not modify its input parameters. A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world Functional programming is a way of writing software applications using only pure functions and immutable values. FP means programming with pure functions, and a pure function is one that lacks side effects… A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a). For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else. In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant. FP in Scala by Paul Chiusano and Runar Bjarnason @pchiusano @runarorama by Sam Halliday @fommil by Alvin Alexander @alvinalexander Definitions of Functional Programming 1.2 Pure Functional Programming Functional Programming is the act of writing programs with pure functions. Pure functions have three properties: • Total: return a value for every possible input • Deterministic: return the same value for the same input • Inculpable: no (direct) interaction with the world or program state. Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions. FP is just programming with functions. Functions are: 1. Total: They return an output for every input. 2. Deterministic: They return the same output for the same input. 3. Pure: Their only effect is computing the output. The rest is just composition you can learn over time. DETERMINISM john Ⓐ De Goes PF = ODI + NSE Pure Functions = Output Depends only on Input + No Side Effects) A pure function has no side effects, meaning that it does not read anything from the outside world or write anything to the outside world. As a result of 1, if a pure function is called with an input parameter x an infinite number of times, it will always return the same result y. This is unlike an OOP method, which can depend on other fields in the same class as the method.
  • 5. 1. A pure function depends only on (a) its declared input parameters and (b) its algorithm to produce its result. A pure function has no “back doors,” which means: 1. Its result can’t depend on reading any hidden value outside of the function scope, such as another field in the same class or global variables. 2. It cannot modify any hidden fields outside of the function scope, such as other mutable fields in the same class or global variables. 3. It cannot depend on any external I/O. It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc. 2. A pure function does not modify its input parameters. A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world Functional programming is a way of writing software applications using only pure functions and immutable values. FP means programming with pure functions, and a pure function is one that lacks side effects… A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a). For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else. In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant. FP in Scala by Paul Chiusano and Runar Bjarnason @pchiusano @runarorama by Sam Halliday @fommil by Alvin Alexander @alvinalexander Definitions of Functional Programming 1.2 Pure Functional Programming Functional Programming is the act of writing programs with pure functions. Pure functions have three properties: • Total: return a value for every possible input • Deterministic: return the same value for the same input • Inculpable: no (direct) interaction with the world or program state. Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions. FP is just programming with functions. Functions are: 1. Total: They return an output for every input. 2. Deterministic: They return the same output for the same input. 3. Pure: Their only effect is computing the output. The rest is just composition you can learn over time. NO SIDE EFFECTS john Ⓐ De Goes PF = ODI + NSE Pure Functions = Output Depends only on Input + No Side Effects) A pure function has no side effects, meaning that it does not read anything from the outside world or write anything to the outside world. As a result of 1, if a pure function is called with an input parameter x an infinite number of times, it will always return the same result y. This is unlike an OOP method, which can depend on other fields in the same class as the method.
  • 6. 1. A pure function depends only on (a) its declared input parameters and (b) its algorithm to produce its result. A pure function has no “back doors,” which means: 1. Its result can’t depend on reading any hidden value outside of the function scope, such as another field in the same class or global variables. 2. It cannot modify any hidden fields outside of the function scope, such as other mutable fields in the same class or global variables. 3. It cannot depend on any external I/O. It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc. 2. A pure function does not modify its input parameters. A pure function is a function that depends only on its declared input parameters and its algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world Functional programming is a way of writing software applications using only pure functions and immutable values. FP means programming with pure functions, and a pure function is one that lacks side effects… A function f with input type A and output type B (written in Scala as a single type: A => B , pronounced “A to B ” or “A arrow B ”) is a computation that relates every value a of type A to exactly one value b of type B such that b is determined solely by the value of a. Any changing state of an internal or external process is irrelevant to computing the result f(a). For example, a function intToString having type Int => String will take every integer to a corresponding string. Furthermore, if it really is a function, it will do nothing else. In other words, a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects. We sometimes qualify such functions as pure functions to make this more explicit, but this is somewhat redundant. FP in Scala by Paul Chiusano and Runar Bjarnason @pchiusano @runarorama by Sam Halliday @fommil by Alvin Alexander @alvinalexander Definitions of Functional Programming 1.2 Pure Functional Programming Functional Programming is the act of writing programs with pure functions. Pure functions have three properties: • Total: return a value for every possible input • Deterministic: return the same value for the same input • Inculpable: no (direct) interaction with the world or program state. Together, these properties give us an unprecedented ability to reason about our code. For example, input validation is easier to isolate with totality, caching is possible when functions are deterministic, and interacting with the world is easier to control, and test, when functions are inculpable. The kinds of things that break these properties are side effects: directly accessing or changing mutable state (e.g. maintaining a var in a class or using a legacy API that is impure), communicating with external resources (e.g. files or network lookup), or throwing exceptions. FP is just programming with functions. Functions are: 1. Total: They return an output for every input. 2. Deterministic: They return the same output for the same input. 3. Pure: Their only effect is computing the output. The rest is just composition you can learn over time. PURITY john Ⓐ De Goes A pure function has no side effects, meaning that it does not read anything from the outside world or write anything to the outside world. As a result of 1, if a pure function is called with an input parameter x an infinite number of times, it will always return the same result y. This is unlike an OOP method, which can depend on other fields in the same class as the method. PF = ODI + NSE Pure Functions = Output Depends only on Input + No Side Effects)
  • 7. We can formalize this idea of pure functions using the concept of referential transparency (RT). This is a property of expressions in general and not just functions. For the purposes of our discussion, consider an expression to be any part of a program that can be evaluated to a result—anything that you could type into the Scala interpreter and get an answer. For example, 2 + 3 is an expression that applies the pure function + to the values 2 and 3 (which are also expressions). This has no side effect. The evaluation of this expression results in the same value 5 every time. In fact, if we saw 2 + 3 in a program we could simply replace it with the value 5 and it wouldn’t change a thing about the meaning of our program. This is all it means for an expression to be referentially transparent—in any program, the expression can be replaced by its result without changing the meaning of the program. And we say that a function is pure if calling it with RT arguments is also RT. Referential transparency and purity An expression E is referentially transparent if, for all programs P, all occurrences of E in P can be replaced by the result of evaluating E without affecting the meaning of P. A function f is pure if the expression f(x) is referentially transparent for all referentially transparent x.3 3 There are some subtleties to this definition, and we’ll refine it later in this book. See the chapter notes at our GitHub site (https://github.com/pchiusano/fpinscala; see the preface) for more discussion. Referential Transparency and Purity Functional Programming in Scala (by Paul Chiusano and Runar Bjarnason) @pchiusano @runarorama