¿Puede * cualquier * tarea del programa expresarse sin estado?

Respuesta corta: si. Según Wikipedia, la equivalencia de cálculo lambda a las máquinas de Turing como modelo universal de cálculo se mostró en 1937 por Alan Turing. El modelo computacional de una máquina de Turing es lo que normalmente tiene en mente cuando habla de la programación imperativa o con estado, y el cálculo lambda es una formalización matemática de la "programación funcional pura".

Se conjetura que cada modelo efectivo de cálculo es capaz de realizar los mismos cálculos que una máquina de Turing, y viceversa. Esto se llama tesis de Church-Turing . Sin embargo, esta conjunción no se puede probar, debido al término más o menos intuitivo "modelo efectivo de computación" (¿quizás alguien inventará un nuevo modelo en el futuro?)

En cualquier sistema dinámico, el "estado" es lo que hace que su presente sea influenciado por su pasado o futuro (la flecha de el tiempo no es un problema matemático, solo una restricción física).

Si tienes algo que "recordar" o que depende de lo que hiciste, tienes un estado.

Un sistema sin estado no es "dinámico": es solo una función combinatoria. Es posible que no tenga un estado, pero, para obtener resultados diferentes, se necesita un estado que se proporcione de alguna manera.

Ahora, dependiendo del modelo computacional al que se refiera, un estado puede representarse explícitamente (en forma de variable) o implícitamente (en forma de "direcciones de retorno").

cuando haces fna(fnb(x)) le das un estado a fnb que a su vez producirá un estado para fna. Esto se debe al hecho de que x existe antes de llamar a fnb (por lo tanto, proviene de su propio "pasado").

No es una cuestión de "estado exisit" o "estado no existe". Es un asunto de "Me importa" o "No me gusta".

Estado significa la capacidad de responder a un estímulo presente de una manera que depende de estímulos pasados, no solo basado en el estímulo presente.

Los programas puramente funcionales son solo funciones. Por lo tanto, para aplicaciones prácticas, el programa puramente funcional ingresa un par (old_state * present_stimulus) y genera un par (new_state * present_response). Se necesita un "looper" externo y con estado para esperar el siguiente estímulo y propagar el estado.

Un programa puramente funcional no tiene un estado intrínseco, y -no se puede usar para aplicaciones prácticas directamente.

Por lo tanto, no el programa orientado por el estado puede ser reemplazado por una implementación diferente que sea puramente funcional y sin estado.

Puedes evitar el estado mutable explícito siempre que no tengas que interactuar con el mundo exterior.

En JavaScript para que su programa tenga un efecto que vaya más allá de los ciclos de procesamiento, debe modificar el objeto Dom o el objeto Window, y estas API tienen estado. Pero supongo que podría crear una envoltura que pasara los objetos Dom y Window como parámetros al código JavaScript y luego recibiera una nueva Dom / Window como salida. Esto aislaría el código JavaScript del estado mutable.

Por supuesto que todavía estás confiando en el estado, ya que la ventana del navegador y el DOM son de estado por naturaleza. Cualquier aplicación interactiva tiene un estado inherente, pero aún puede estructurar su código de manera tal que minimice el estado explícito.

Una pregunta diferente es si es una buena idea. Incluso Haskell, que es un lenguaje funcional puro por diseño, incluye la mónada 'state', que le permite simular un estado mutable. Esto muestra que el estado mutable explícito a veces realmente es un patrón deseable.

Piense en cómo implementaría una "máquina de estado" en un lenguaje de programación sin estado.

Probablemente podría hacerlo, pero terminaría usando nombres de funciones como almacenamiento. Acabar con un buen rollo como:

if (sm.atBegining()) sm.start() else if (sm.done()) sm.stop() ) else sm.progress()