oop - What is the exhaustive list of guidelines/practices/rules to fully conform with functional paradigm? -

i've started playing around kotlin, sense own limitation in way program. problem still think java therefore style still imperative, question functional programming zealots , believe useful people @ beginning stage , need 'brake' brain start building again; leave comfort zone , start thinking pseudo , not in "whatever first language". believe possible highly experienced polyglot developers chew concepts down plain advices of makes program being written in entirely functional way , violates paradigm. don't know quirks please don't hesitate include universally accepted terms might unknown me(i can lookup). @ point need set of rules make myself suffer @ first , not break them know feel it, analyze guidelines , understand how worse/better of course own homework.

so example of these guidelines, like:

• never change state, can avoided using x, y, z
• operate using higher order functions (i maybe wrong, example)

i hope answer give me long term reference put myself in extreme conditions stop escaping oop whenever feel uncomfortable. , when @ kotlin understand how i've should've been thinking problems, intention not structure imposed 1 language or another. intention can converted language of choice , backed design patterns applicable language, find middle ground need jail myself first comfort zone.

• avoid mutable state plague.

  one of main points of using functional programming, possibly main one, avoid little pitfalls, bugs, issues 1 needs deal when using mutable state. should can in order avoid mutating state. instance, instead of using c-style for-loops need keep counter variable updated, use map , other higher-order functions in order abstract away iteration patterns. means should never change value of variable if can avoid that. instead, should defining of variables, preferrably of them, constants, , using functions compute new values them instead of mutating them.

• avoid side-effects plague.

  mutable state's ugly cousin, side-effects. side effects mean other taking value , returning value in function. if function prints data, mutates global variables, sends messages threads, or anything, other taking parameters, computing value them, , returning value, function has side-effects. side-effects important (see next bullet point), if use them lot, impossible track. think of how tells avoid global variables in imperative programming. functional programming goes step further , tries avoid side-effects. bulk of program should made of pure functions. (see ahead)

• when need use side-effects, keep them contained.

  yes, told run away side-effects. however, no program useful without side-effects of kind. graphical user interface? side-effect. audio output? side-effect. printing shell? side-effect. can't rid of side-effects if want build useful stuff. should instead write code side-effecting code lives in thin layer calls pure functions , required side-effects using result of these pure function calls.

• use pure functions can.

  this sort of flipside of previous point. pure function function has no side-effects , not mutate anything. can take in parameters , return value. should use these a lot. instance, instead of doing logging within functions computing stuff, should constructing log strings using pure functions, , letting side-effects layer call these pure functions, call more pure functions in order format log strings full log, , output log side-effects layer.

• use higher-order functions structure code.

  higher-order functions are, in way, glue makes functional programming work. higher-order function function takes 1 or more functions parameters and/or returns function. power of higher-order functions can encapsulate many of patterns use in imperative-style program in declarative manner. instance, let's take @ 3 common higher-order functions:

  map function takes function , list of values, applies function argument each of values, , returns new list results. map encapsulates whole pattern of iterating on list doing operation on each value in declarative manner.

  filter function takes function returns boolean , list of values, applies function argument each of values , returns list containing values function argument returns true. encapsulates whole pattern of selecting results list in declarative manner.

  reduce, known fold, takes initial value, binary function , list of values. uses function argument combine initial value first value of list, combines result next value of list , keeps on doing until has reduced list 1 single value. encapsulates entire pattern of obtaining aggregate value list of values.

  this in no way exhaustive list of higher-order functions, these 3 common ones. hope has been enough show how can structure code require lot of tracking variables using functions in declarative manner. if use these higher-order functions well, it's won't ever need for or while loop again.

this not exhaustive list of functional programming practices, think functional programmers agree these 5 guidelines form core of functional programming about. if want learn how apply these, advice learn pure functional programming language such haskell, forced abandon imperative paradigm , learn how structure things functionally instead. recommend fantastic haskell programming first principles starting resource if choose go way. in case don't want to/can't put down cash, brent yorgey's haskell course @ upenn great free resource.