Tout dépend de ce que tu veux faire comme logiciel. Il y a des cas où l’on cherche à minimiser les tâches réalisés par un logiciel (_KISS_ qu’ils disaient), que ce soit par souci de réaliser une pièce qui fleur bon l’œuvre artisanale soignée (_for the love of art and the making_ qu’ils disaient), ou pour des raisons beaucoup plus pragmatiques comme « moins de lignes de code et de fioriture, c’est moins de bug potentiel ».
Donc pour répondre à la question du journal, je dirais que tout simplement ça dépend du projet sur lequel tu bosses. Si toute ton équipe utilise la même IDE et que la maintenabilité du code devient dépendante de celle-ci, alors tu y échapperas que difficilement à travers une démarche probablement pas la plus productive possible.
pas de possibilité (dans les outils couramment utilisés) de gérer le temps, car le programme est un éternel amnésique sur ses donnés (quelle règle appliquer si on a tel changement successif sur les donnés ?).
C’est probablement lié au fait que raisonner sur le temps est un exercice d’une complexité nettement supérieur à celle de réflexions causales (déjà elles mêmes pas toujours évidentes). Mais ce n’est peut-être pas le temps en ce sens que tu signifiais. Pour le cas que tu cites, on peut par exemple maintenir sans trop de peine une structure qui sauvegarde l’historique des changements, une fonction qui prends cette structure et te renvois un nombre, une fonction qui applique un traitement en fonction de ce nombre. Bien sûr je consent qu’en pratique c’est plus ou moins aisé à mettre en œuvre.
Sémantique du langage limité à celle définie lors de sa conception.
Je crois qu’il me faudrait plus d’information pour comprendre ce que tu veux dire. Si on en crois la thèse de Church-Turing tous les programmes sont sémantiquement équivalent (et de toute façon en pratique c’est les mêmes circuits électroniques qui font le circuit au final). Mais je pense que je ne comprends tout simplement pas ce que tu as voulu dire ici.
Aucune notion de calculs sur contraintes entre composant.
Des langages par contraintes ça existe, je ne doute pas que tu le saches, puisque d’après mes souvenirs tu es un gourou du fonctionnel/Ocaml d’où j’infère que tu as un profil à savoir ce genre de choses. Par contre ici je pense que ce qui me manque c’est une explication du entre composant. Pense aux ignares comme moi quand tu écris. ;)
Pas de sémantique de définition du comportement global du système.
[^] # Re: Automatisation indispensable
Posté par psychoslave__ (site web personnel) . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 5.
Tout dépend de ce que tu veux faire comme logiciel. Il y a des cas où l’on cherche à minimiser les tâches réalisés par un logiciel (_KISS_ qu’ils disaient), que ce soit par souci de réaliser une pièce qui fleur bon l’œuvre artisanale soignée (_for the love of art and the making_ qu’ils disaient), ou pour des raisons beaucoup plus pragmatiques comme « moins de lignes de code et de fioriture, c’est moins de bug potentiel ».
Donc pour répondre à la question du journal, je dirais que tout simplement ça dépend du projet sur lequel tu bosses. Si toute ton équipe utilise la même IDE et que la maintenabilité du code devient dépendante de celle-ci, alors tu y échapperas que difficilement à travers une démarche probablement pas la plus productive possible.
C’est probablement lié au fait que raisonner sur le temps est un exercice d’une complexité nettement supérieur à celle de réflexions causales (déjà elles mêmes pas toujours évidentes). Mais ce n’est peut-être pas le temps en ce sens que tu signifiais. Pour le cas que tu cites, on peut par exemple maintenir sans trop de peine une structure qui sauvegarde l’historique des changements, une fonction qui prends cette structure et te renvois un nombre, une fonction qui applique un traitement en fonction de ce nombre. Bien sûr je consent qu’en pratique c’est plus ou moins aisé à mettre en œuvre.
Je crois qu’il me faudrait plus d’information pour comprendre ce que tu veux dire. Si on en crois la thèse de Church-Turing tous les programmes sont sémantiquement équivalent (et de toute façon en pratique c’est les mêmes circuits électroniques qui font le circuit au final). Mais je pense que je ne comprends tout simplement pas ce que tu as voulu dire ici.
Des langages par contraintes ça existe, je ne doute pas que tu le saches, puisque d’après mes souvenirs tu es un gourou du fonctionnel/Ocaml d’où j’infère que tu as un profil à savoir ce genre de choses. Par contre ici je pense que ce qui me manque c’est une explication du entre composant. Pense aux ignares comme moi quand tu écris. ;)
Idem.