Pourquoi programmer en temps continu ? Quels sont les bénéfices et utilités de cette technique ?

Pourquoi programmer en temps continu ? Quels sont les bénéfices et utilités de cette technique ?

Selon le blogueur américain Elliott Conal, le functional reactive programming (FRP) est régi par deux grands principes : le design dénotationnel et le temps continu (présent depuis TBAG, le prédécesseur d'ActiveVRML).

Ce passionné de programmation a reçu ces derniers jours un courrier d'un internaute qui indiquait "ne pas avoir besoin" de temps continu, et "ne pas comprendre pourquoi l'absence de flux continus est un problème" puisqu'au final, "tous les flux sont discrets".

Conal lui a répondu sous la forme d'une lettre ouverte publiée sur son blog où il explique que la programmation se joue plus "au milieu qu'à la fin, au niveau de la composition qu'à celui de la sortie".

Selon lui, la continuité dans l'espace et le temps est meilleure pour la modularité, laissant la discrétion pour l'étape de sortie.

Un autre nom pour "continu" est "résolution - indépendance". C'est ainsi que des données peuvent être transformées en espace et en temps facilement, et en "évitant la propagation et l'amplification d'artéfacts".

Il donne plusieurs exemples :

- Le type de données dans une application 3D n'est finalement composée que de pixels, alors quel manque y-a-t-il dans une API pixel-oriented qui ne fait pas appel à des notions continues de haut niveau comme des triangles ou des surfaces courbes ? Il serait possible de dire qu'à la "fin", tout type de donnée n'est que phosphore ou impulsions électriques.

- La programmation impérative contre la programmation fonctionnelle. Cette dernière excelle en composabilité.

- Les structures de données infinies contre celles finies. On n'accède à une quantité de données finies qu'à la "fin". Cependant, autoriser des structures infinies "au milieu" permet de style de programmation bien plus composable.

:fleche: Qu'en pensez-vous ?

:fleche: Selon vous, est-il plus facile d'écrire un programme avec des flux continus ou bien des flux discrets ?

:fleche: Les flux continus sont-ils réellement continus ?

Source : Le blog de Conal

J'ai absolument rien compris :aie:

Citation:

---

Envoyé par jmnicolas

J'ai absolument rien compris :aie:

---

J'osais pas le dire :lol:

Pas mieux :aie:

Le contraire de la programmation en temps continu, c'est la programmation en temps alternatif non ? :aie:

Je crois que c'est plutôt une histoire de données discrètes ou continues.

Et je crois qu'il dit juste qu'il peut y avoir une accumulation d'erreurs avec des calculs sur des données discrètes, ce que l'on sait depuis déjà bien longtemps puisque l'on quantifie en général les erreurs commises :aie:

De bonne volonté quand même, j'ai essayé de chercher ça sur google, histoire d'y voir plus clair, et le premier résultat pour "programmation en temps continu" est cette page même. C'est même le seul résultat cohérent :aie:

Rien compris non plus, Kathleen, tu devrais demander à un développeur de te relire avant de publier :mouarf:

Un peu précoce, pour un 1er avril...

personnellement, j'aime, j'adore et je défend la simplicité :ccool:
En programmation encore plus que dans d'autre domaine !

Autant je suis pour des approches agiles, même simplifiées style XP, avec un brin de CMMi pour rester dans les clous, autant là ... à part du blabla, je ne vois pas en quoi ça va changer la façon dont je pisse des exigences et du code :mrgreen:

Mais je suis peut-être trop ... terre-à-terre.

Citation:

---

Envoyé par Jack Sparrow

Je crois que c'est plutôt une histoire de données discrètes ou continues.

Et je crois qu'il dit juste qu'il peut y avoir une accumulation d'erreurs avec des calculs sur des données discrètes, ce que l'on sait depuis déjà bien longtemps puisque l'on quantifie en général les erreurs commises :aie:

---

Aaaahhhhh !!! J'y vois plus clair. :ccool:
Heureusement que j'ai quelques souvenir de mes cours de traitement du signal sinon je ne saurais pas ce que veut dire "données discrètes".

Pour tenter une explication, si je me souvient bien, un signal discret, c'est un signal échantillonné à une certaine fréquence. C'est ce qui permet de transformer de l'analogique en numérique par exemple.
Sur un CD audio, le signal est échantillonné à 44100 Hz. Cela signifie qu'il est divisé en 44100 échantillons par seconde : un petit article Wikipédia pour comprendre : http://fr.wikipedia.org/wiki/%C3%89c...e_%28signal%29

Voilà, de même pour une image, celle-ci est échantillonnée selon sa résolution. Par exemple, 800x600 signifie que l'image a été divisée en 480 000 pixels.

Mouais...
Ca m'a l'air intérssant mais quelques éclaircissements ne feraient pas de mal :aie:

C'est peut être fait exprès pour qu'on comprenne rien la dedans.

euh bah c'est pas faux...:)

On va essayer de donner quelques pistes pour éclairer les profanes... :aie:


clairement ce sujet est d'un haut niveau académique et il semble clair que :

1. la programmation fonctionnelle est méconnue du développeur lambda, malgré l'apparition de notions fonctionnelles dans des langages mainstream comme C# (d'une certaine manière les délégates, Func<T,TReturn>, Linq, etc). pour plus d'infos venez nous voir sur le forum dédié
2. la programmation réactive est encore moins connue (même pour des étudiants mangeant du Caml depuis leur plus tendre enfance :aie: ; il n'y a même pas de page francophone sur wikipedia à ce sujet imaginez :mouarf:). Selon moi, les langages les plus connus sont Lustre, Esterel et Erlang... certains ont peut-être même entendu parler de Lucid Synchron (petite pub pas méchante)

:bravo: à Kathleen d'avoir tenté d'élargir un peu l'horizon des news :ccool:



l'auteur du billet d'origine semble TRES Functional Programming As an End, Not a Mean, comme beaucoup d'académiciens de ce milieu (ce n'est pas un jugement de valeur, mais juste un ressenti ;))