Purely functional programming - Revision history

Apm: added a misc fun section and link to Wikipedia page Heisenbug

2026-03-20T11:10:23Z

added a misc fun section and link to Wikipedia page Heisenbug

← Older revision		Revision as of 13:10, 20 March 2026
Line 170:		Line 170:
	* But if it did is seems that came at the big expense of significantly reduced expressiveness??		* But if it did is seems that came at the big expense of significantly reduced expressiveness??
	{{wikitodo\|look deeper into that}}		{{wikitodo\|look deeper into that}}

			== Misc fun ==

			Imperative programming is doing the supposedly same thing f(x) f(x) f(x) over and over again and getting different results sometimes. Intentional or not. <br>
			Popular saying: "The definition of insanity is doing the same thing over and over again and expecting different results." <br>

	= Related =		= Related =
Line 185:		Line 190:
	* [https://www.fpcomplete.com/blog/2012/04/the-downfall-of-imperative-programming the-downfall-of-imperative-programming] by Bartosz Milewski		* [https://www.fpcomplete.com/blog/2012/04/the-downfall-of-imperative-programming the-downfall-of-imperative-programming] by Bartosz Milewski
	Wikipedia:		Wikipedia:
	* [https://en.wikipedia.org/wiki/Purely_functional_programming ~~Purely_functional_programming~~]		* [https://en.wikipedia.org/wiki/Purely_functional_programming Purely functional programming]
	* [https://en.wikipedia.org/wiki/Purely_functional ~~Purely_functional~~]		* [https://en.wikipedia.org/wiki/Purely_functional Purely functional]
			* [https://en.wikipedia.org/wiki/Heisenbug Heisenbug]

	[[Category:Programming]]		[[Category:Programming]]
	[[Category:Software]]		[[Category:Software]]

Apm: /* Pureness */ == Limits of referential transparency ==

2024-05-05T10:20:50Z

Pureness: == Limits of referential transparency ==

@@ Line 54: / Line 54: @@
 "… but mere referential transparent programming is more functional" <br>
 (purely/poorly – mere/more) <br>
 == Functionalness ==

Apm at 08:43, 5 May 2024

2024-05-05T08:43:30Z

← Older revision		Revision as of 10:43, 5 May 2024
Line 178:		Line 178:

	[[Category:Programming]]		[[Category:Programming]]
			[[Category:Software]]

Apm: /* Pureness */ === Scope of purity ===

2024-05-05T08:08:40Z

Pureness: === Scope of purity ===

@@ Line 26: / Line 26: @@
 * pure functional reactive programming (FRP) libraries manage to do this without monads and they managed to overcome PFP's "batch processing only" stigma.
-'''Purity demotes debugging from an art to technique.'''
+From [[APM:About|me this wikis author]]: '''Purity demotes debugging from an art to technique.''' <br>
-<small>(Just like the difference in difficulty between integration and differentiation).</small>
+<small>(Just like the difference in difficulty between integration and differentiation).</small> <br>
-Narrowing down on an error always leads to the error.
+Narrowing down on an error always leads to the error. No [[heisenbugs]].
 == Functionalness ==

Apm: /* Pureness */

2024-05-05T06:56:41Z

Pureness

← Older revision		Revision as of 08:56, 5 May 2024
Line 12:		Line 12:

	Basic (mutually self implying) properties:		Basic (mutually self implying) properties:
	* forbidden: updating variables aka destructive assignments -- E.g. x := x+1		* forbidden: updating variables aka destructive assignments -- E.g. x := x+1 is forbidden for simplest possible example -- aka immutability
	* required: "referential transparency" -- f(x) = y -- same x in f's domain leads to same y in f's range -- no matter where in code and when in execution.		* required: "referential transparency" -- f(x) = y -- same x in f's domain leads to same y in f's range -- no matter where in code and when in execution.
	* allowed: "mathematical reasoning" -- E.g. substitution or the reverse: a=b ∧ b=c ⇔ a=c -- code order does not matter		* allowed: "mathematical reasoning" -- E.g. substitution or the reverse: a=b ∧ b=c ⇔ a=c -- code order does not matter
Line 28:		Line 28:
	'''Purity demotes debugging from an art to technique.'''		'''Purity demotes debugging from an art to technique.'''
	<small>(Just like the difference in difficulty between integration and differentiation).</small>		<small>(Just like the difference in difficulty between integration and differentiation).</small>
	Narrowing down on an error always leads to the error.		Narrowing down on an error always leads to the error.

	== Functionalness ==		== Functionalness ==

Apm: /* Functionalness */ made important statement bold

2024-05-05T06:53:43Z

Functionalness: made important statement bold

← Older revision		Revision as of 08:53, 5 May 2024
Line 36:		Line 36:
	This is a powerful abstraction tool.		This is a powerful abstraction tool.

	Note that functionalness in neither a necessary nor a sufficient property for purity.		Note that '''functionalness in neither a necessary nor a sufficient property for purity.''' <br>
	<small>(As a name "pure and functional" would be better than the historic accident: "purely functional")</small> <br>		<small>(As a name "pure and functional" would be better than the historic accident: "purely functional")</small> <br>
	There are languages that are pure but not functional and vice versa.		There are languages that are pure but not functional and vice versa.

Apm: Undo revision 16447 by Apm (talk)

2024-05-05T06:49:14Z

Undo revision 16447 by Apm (talk)

← Older revision		Revision as of 08:49, 5 May 2024
Line 127:		Line 127:

	Bartosz Milewski:		Bartosz Milewski:
	>> ''"Unfortunately, objects ~~dont~~ compose in the presence of concurrency. They hide the wrong kind of things. They hide sharing and mutation. Let me quote the definition of data race: Two or more threads accessing the same piece of memory at the same time, at least one of them writing. In other words: Sharing + Mutation = Data Race. Nothing in the object’s interface informs you about the possibility of sharing and mutation inside the object’s implementation. Each object in isolation may be data-race-free but their composition may inadvertently introduce data races. And you won’t know about it unless you study the details of their implementation down to every single memory access."''		>> ''"Unfortunately, objects don’t compose in the presence of concurrency. They hide the wrong kind of things. They hide sharing and mutation. Let me quote the definition of data race: Two or more threads accessing the same piece of memory at the same time, at least one of them writing. In other words: Sharing + Mutation = Data Race. Nothing in the object’s interface informs you about the possibility of sharing and mutation inside the object’s implementation. Each object in isolation may be data-race-free but their composition may inadvertently introduce data races. And you won’t know about it unless you study the details of their implementation down to every single memory access."''
	Source: [https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/]		Source: [https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/]

Apm: /* Relation to OOP (object oriented programming) */

2024-05-05T06:48:23Z

Relation to OOP (object oriented programming)

← Older revision		Revision as of 08:48, 5 May 2024
Line 127:		Line 127:

	Bartosz Milewski:		Bartosz Milewski:
	>> ''"Unfortunately, objects ~~don’t~~ compose in the presence of concurrency. They hide the wrong kind of things. They hide sharing and mutation. Let me quote the definition of data race: Two or more threads accessing the same piece of memory at the same time, at least one of them writing. In other words: Sharing + Mutation = Data Race. Nothing in the object’s interface informs you about the possibility of sharing and mutation inside the object’s implementation. Each object in isolation may be data-race-free but their composition may inadvertently introduce data races. And you won’t know about it unless you study the details of their implementation down to every single memory access."''		>> ''"Unfortunately, objects dont compose in the presence of concurrency. They hide the wrong kind of things. They hide sharing and mutation. Let me quote the definition of data race: Two or more threads accessing the same piece of memory at the same time, at least one of them writing. In other words: Sharing + Mutation = Data Race. Nothing in the object’s interface informs you about the possibility of sharing and mutation inside the object’s implementation. Each object in isolation may be data-race-free but their composition may inadvertently introduce data races. And you won’t know about it unless you study the details of their implementation down to every single memory access."''
	Source: [https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/]		Source: [https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/]

Apm: /* Related / added link to yet unwritten page Mathematical substitutability

2024-05-05T06:43:58Z

Related: added link to yet unwritten page * Mathematical substitutability

← Older revision		Revision as of 08:43, 5 May 2024
Line 143:		Line 143:
	* [[General software issues]]		* [[General software issues]]
	* [[Programming languages]]		* [[Programming languages]]
			* [[Mathematical substitutability]]

	= External links =		= External links =

Apm: /* External links */

2024-05-05T06:41:29Z

External links

← Older revision		Revision as of 08:41, 5 May 2024
Line 146:		Line 146:
	= External links =		= External links =

	* [https://www.fpcomplete.com/blog/2012/04/the-downfall-of-imperative-programming the-downfall-of-imperative-programming ] by Bartosz Milewski		* [https://www.fpcomplete.com/blog/2012/04/the-downfall-of-imperative-programming the-downfall-of-imperative-programming] by Bartosz Milewski
	Wikipedia:		Wikipedia:
	* [https://en.wikipedia.org/wiki/Purely_functional_programming Purely_functional_programming]		* [https://en.wikipedia.org/wiki/Purely_functional_programming Purely_functional_programming]