De ce que je retiens des articles (enfin de leur traduction et des posts), deux choses sont mises en avant :
l'utilisation de langage de haut niveau
l'utilisation de concept le plus proche possible de l'objet à modéliser
Pour résumer grossièrement la chose (et pour exposer le fruit de mes méditations personnelles) on peut dire :
"On doit coder en fonction de ce qu'on code, et non pas de qui code, et de comment ou sur quoi il code".
Jusque là je suis d'accord. Le principe est de séparer au maximum le codeur de l'aspect matériel du problème.
Est-ce que les nouvelles orientations matérielles (par exemple le Cell) peuvent-elles etre compatibles à cela ? J'ai surtout eu l'impression que l'idée est "ce machin roxxe, si et seulement si le développeur pense qu'il doit coder comme si et comme ca". Pas très cool.
D'autre part, je voulais faire part d'une critique sur les articles : les propositions du style "un projet de 30.10^45 lignes est trop complexe pour les humains actuellement". Il semble qu'une des exigences est qu'une personne comprenne à elle seule l'ensemble du projet. Pour comparer, c'est un peu comme si on avait dit avant de construire la tour Effeil (ce n'est pas un message subliminal, je ne connais pas le programme du meme nom) "Chaque poutre est cruciale, un homme ne peut pas avec les moyens actuels appréhender toute la complexité du projet, ca va se péter la gueule".
La solution (meme si elle ne révolutionne rien (dommage) ni n'enlève les problèmes de bugs), et comme il a été dit plus haut le découpage en sous problèmes : chaque mec check son bout de code, et il existe des types qui ont à vérifier que les bouts de codes s'assemblent bien entre eux. En un mot : modularisation.
# Nouveaux matériels
Posté par gasche . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 5.
l'utilisation de langage de haut niveau
l'utilisation de concept le plus proche possible de l'objet à modéliser
Pour résumer grossièrement la chose (et pour exposer le fruit de mes méditations personnelles) on peut dire :
"On doit coder en fonction de ce qu'on code, et non pas de qui code, et de comment ou sur quoi il code".
Jusque là je suis d'accord. Le principe est de séparer au maximum le codeur de l'aspect matériel du problème.
Est-ce que les nouvelles orientations matérielles (par exemple le Cell) peuvent-elles etre compatibles à cela ? J'ai surtout eu l'impression que l'idée est "ce machin roxxe, si et seulement si le développeur pense qu'il doit coder comme si et comme ca". Pas très cool.
D'autre part, je voulais faire part d'une critique sur les articles : les propositions du style "un projet de 30.10^45 lignes est trop complexe pour les humains actuellement". Il semble qu'une des exigences est qu'une personne comprenne à elle seule l'ensemble du projet. Pour comparer, c'est un peu comme si on avait dit avant de construire la tour Effeil (ce n'est pas un message subliminal, je ne connais pas le programme du meme nom) "Chaque poutre est cruciale, un homme ne peut pas avec les moyens actuels appréhender toute la complexité du projet, ca va se péter la gueule".
La solution (meme si elle ne révolutionne rien (dommage) ni n'enlève les problèmes de bugs), et comme il a été dit plus haut le découpage en sous problèmes : chaque mec check son bout de code, et il existe des types qui ont à vérifier que les bouts de codes s'assemblent bien entre eux. En un mot : modularisation.