Limite de la programmation

[guigui428]

Bonjour

Je me suis mis a la prog depuis une certain temps ( php/mysql c/c++ ) et je me pose une question toute bete :

Que ne peut on pas faire à l'aide le la programation?

Est ce que les jeux actuel sont limités par la prog?

Le non-fiabilité de programme est du aux programmeurs ou aux langages?

J'espere que vous comprenez mes question...

Ce post peut peut etre devenir un debat

Bonne fin de week-end

[Cubic-Design]

A mon avis atteindre les limites de la programmation c'est quasiment impossible (en tous cas je ne pense pas que quelqu'un puisse) tout simplement car on sera bloqué par le matériel avant (par exemple les jeux les graphismes sont limité par les cg ou l'aspect gameplay par le matos)

Enfin voilà, maintenant tu ne paux pas (encore) faire sortir une image de ton écran, des odeurs de ta machine, mais encore une fois c'est plus "phisyque" donc matériel

Sinon une des limites est la fameuse boucle infini (le while tueur ;p)

[tsubasaleguedin]

Le non-fiabilité de programme est du aux programmeurs ou aux langages?

Disons que plus tu monte dans le langage ( en terme de couche ) plus ca peut etre les deux, plus tu descend vers le materiel et plus c'est limité qu'au limite du programmeur.

En clair:

Java/.net/C#/python/vb : Fiabilité lié à la stabilité du langage et au programmeur

C/C++/assembleur: Fiabilité limité uniquement au programmeur

[Jiriki]

Que ne peut on pas faire à l'aide le la programation?

Il faut aller vers la théorie pour voir les limites de la programmation.

Tu ne penses pas à ça tous les jours en écrivant un programme C.

Un exemple, il est impossible d'écrire un programme décidant pour tous les programmes s'ils terminent ou pas. A un instant t, si le programme n'a pas terminé, tu ne sais pas dire s'il va s'arrêter à l'instant t+1 ou jamais. C'est ce qu'on appelle un problème semi-décidable. Si le programme s'arrête, tu as ta réponse, mais s'il ne s'est pas encore arrêté, tu ne sais pas si tu auras une réponse en un temps fini (et un temps fini suffisamment petit pour que tu sois encore vivant )

Est ce que les jeux actuel sont limités par la prog?

Oui et non. Oui parce que les GPU disponibles sur le marchés n'offrent qu'un nombre limité d'instructions et qu'on ne peut pas écrire n'importe quoi sous peine de de voir tourner son jeu à 1-2 fps sur une config de la mort. Non parce que cette limite n'est pas seulement inhérente au langage lui même mais aussi au matériel comme je l'ai dit plus haut.

Le non-fiabilité de programme est du aux programmeurs ou aux langages?

Je dirais: à 95%, aux progammeurs. Il y a des langages plus permissifs que d'autres dans leurs instructions. Je pense par exemple au cobol dans lequel il y avait (je parle au passé si je veux, à mort le cobol ) l'instruction GOTO. Cette instruction est horrible au sens qualité du logiciel, elle détruit la structuration logique du code en permettant de pointer vers n'importe que partie du code. A l'origine, elle était peut être destinée à n'être employée que comme un appel de fonction mais ses capacités sont beaucoup plus importantes qu'un simple appel. Bref, par ce type d'instruction un langage peut engendrer de la non fiabilité, mais on voit déjà que l'aspect humain est important puisqu'un bon programmeur ne programmera pas comme ça.

Mais pour revenir à mes 95%, on peut se demander ce qu'est un "bon programmeur". Un bon programmeur est un programmeur qui code bien. Bien coder consiste à (liste non exhaustive): respecter un cahier des charges, faire un code propre commenté et documenté, respecter le référentiel documentaire... L'ensemble des tâches de développement constitue ce que l'on appelle un processus. Si le processus est mauvais (on saute une étape: pas de commentaires, pas de relecture de code ..) alors le résultat sera mauvais et il y aura des erreurs. Ces erreurs seront due au programmeur ou plus généralement à l'équipe de développement qui n'aura pas suivi un processus suffisamment robuste. Ca fait un bon moment qu'on s'est rendu compte que les erreurs des logiciels provenait d'erreurs humaines. On s'est aussi rendu compte que faire un effort sur le processus permettait de réduire ces erreurs. il y a un certain nombre de modèles de développement qui sont apparus. Le plus important et le plus intéressant est le modèle CMMI qui liste les éléments clés du développement du logiciel et propose un cheminement vers les plus haut niveau de qualité.

http://fr.wikipedia.org/wiki/CMMI

[Captain Hadock]

La manière dont cette question est posée ressemble a un énoncé de problème existentiel de programmeur, savoir si il peut oui ou non agir totalement sur le monde finalement si accessible qu'est l'informatique. En effet, programmer peut sembler donner un certain pouvoir sur cet espace, dans lequel les normes de valeurs sont différentes de celle du "monde physique", ce qui permet de donner leur chance à d'autre gens.

Mais ce qu'il faut se dire, c'est que si on réduit la question aux seuls capacité de la programmation, en faisant donc abstraction des contraintes matérielles, qui sont finalement le joug nous rappelant que ce sur quoi nous agissons comporte des contraintes inhérentes au monde physique, alors cette simple question de ce qu'il nous est ou non donné de faire est probablement ardue à solutionner.

L'une des raisons en est qu'il faudrait un exemple de limitation due à la programmation pour que le problème soit réglé. Tant que rien de tel n'apparait (ou n'est porté à notre connaissance), comment pouvons nous nous prononcer de manière définitive sur la réponse? Donc tant que des limites n'apparaissent pas, on peut seulement dire que soit il n'y en a pas, soit on ne les a pas encore atteinte.

Une question se pose donc, vu qu'on ne pourra jamais être sur qu'il n'y en a pas, ne vaut il pas mieux considérer qu'il y en a et se demander pourquoi on ne les a pas encore atteinte. C'est probablement une démarche qui permettra d'avancer sur le problème.

[LePhasme]

Le non-fiabilité de programme est du aux programmeurs ou aux langages?

Je dirais: à 95%, aux progammeurs. Il y a des langages plus permissifs que d'autres dans leurs instructions. Je pense par exemple au cobol dans lequel il y avait (je parle au passé si je veux, à mort le cobol ) l'instruction GOTO. Cette instruction est horrible au sens qualité du logiciel, elle détruit la structuration logique du code en permettant de pointer vers n'importe que partie du code. A l'origine, elle était peut être destinée à n'être employée que comme un appel de fonction mais ses capacités sont beaucoup plus importantes qu'un simple appel. Bref, par ce type d'instruction un langage peut engendrer de la non fiabilité, mais on voit déjà que l'aspect humain est important puisqu'un bon programmeur ne programmera pas comme ça.

Juste pour signaler que le goto est implémenté dans beaucoup de langages même si il est peu utilisé et pas uniquement dans le cobol...

[Jiriki]

Juste pour signaler que le goto est implémenté dans beaucoup de langages même si il est peu utilisé et pas uniquement dans le cobol...

Oui, je me suis fais la réflexion en me relisant. Mais je suis resté sur l'exemple du cobol car à l'époque, l'instruction était utilisée. Actuellement, le goto en c par exemple n'est pas utilisé par beaucoup de monde (en tout cas à ma connaissance).

[LePhasme]

Le goto n'est plus utilisé car ça fout en l'air la structure d'un programme, mais bon un de nos prof nous a appris le fortran et pour faire des boucles on devait utiliser des goto...

Pour revenir au sujet du topic, il y a quand même des limitations, par exemple générer un nombre réellement aléatoire... D'un coté c'est impossible aussi en réel ( normalement si on possède les informations suffisantes on peut savoir à l'avance quel résultat va être produit ), mais la programmation ne permet pas de le faire.

[mogwai93]

[hs à propos de goto]c'est vrai qu'en cours, on apprend à ne pas utiliser cette fonction afin d'avoir une bonne méthodologie et un code "propre"

mais dès que tu veux optimiser ton code, goto est quasi necessaire, d'ailleurs tu codes avec la methodologie assembleur, pour ne pas dire directement en assembleur

[fin hs]

[windu.2b]

Le goto n'est plus utilisé car ça fout en l'air la structure d'un programme, mais bon un de nos prof nous a appris le fortran et pour faire des boucles on devait utiliser des goto...

Pour revenir au sujet du topic, il y a quand même des limitations, par exemple générer un nombre réellement aléatoire... D'un coté c'est impossible aussi en réel ( normalement si on possède les informations suffisantes on peut savoir à l'avance quel résultat va être produit ), mais la programmation ne permet pas de le faire.

J'avias lu (il y a un petit moment de ça) que la physique quantique permettrait d'obtenir des valeurs totalement aléatoires!

[LePhasme]

Ha bon, pourtant jmesemblait avoir entendu que si tous les états d'un système à un temps T étaient connu on pouvait prévoir l'état du système au temps T+1...

Mais bon mes connaissances en physique quantique sont proches du NULL donc c'est possible qu'ils aient trouvé un moyen de contourner ca.

[Krogoth]

Pour répondre sur les goto en cobol.

Il faut savoir que les goto ne sont plus utilisé en cobol avec les normes cobol 2. Bien sur s'il y a de la maintenance à faire sur un ancien programme on ne peut pas faire autrement car celà nécessiterrait une refonte du programme. En concevant son programme dès le début sans s'appuyer sur le goto il est tout à fait possible de ne pas les utilisé et déjà que c'est assez le bordel avec tout les perform until...

[LePhasme]

Remarque un perform until ca ressemble franchement à un goto déguisé...

[FiP_]

Sinon, par rapport aux limites actuelles de la programation, il y a la génération de nombres aléatoires: Un ordi sort toujours les mêmes résultats pour les mêmes entrées, trouver des nombres "au hasard" est donc un tâche impossible. Il existe en revanche de très bon algorithmes pour la génération de nombre pseudo-aleatoires.

( voir http://www.alrj.org/docs/algo/random.php )

Sinon, en ce qui concerne la limite des jeux, je suppose qu'on peut dire qu'on ne poura créér un univers virtuel aussi complexe que le reel, etant donné que les puissances de calcul et les espaces de stockages sont des quantités finies :)

Pour la non fiabilité des programmes, elle vient souvent d'un langage trop permissif, qui pourait donner de mauvaises habitudes de programation... Un des langages les plus stricts que j'ai pu tester est le ada, qui posséde entre autre une définition des variable tres precise, de l'ordre de: "x est un entier naturel positif, compris entre 30 et 42". D'après ces utilisateurs, ce langage est souvent utilisé dans des modules embarqués, grâce à sa fiabilité.

Perso j'ai pas aimé

[namewithn0man]

Il y a deux théorèmes de logique mathématique qui répondent à ta question sur les limites.

Il s'agit des "Théorèmes d'incomplétude de Godel", démontrés en 1931.

Un énoncé peu précis de ces théorèmes est que dans la plupart des théories, il existe des énoncés vrais mais pourtant indémontrables.

Cela s'applique notemment aux théories fondatrices des mathématiques (théorie des ensembles et Principia Mathematica).

Cette démonstration contribué à mettre un terme à l'idée répandue que l'on pouvait tout formaliser, trouver la grande équation du tout, la programmer...

- Pensée Profonde, quelle est la réponse à la Grande Question, celle du sens de la vie, de l'Univers et de tout ce qui est ?

- J'ai votre réponse. C'est 42.

Quelque part, ces théorèmes sont dérangeants car ils nous renvoie à notre finitude humaine. En plus, ils nous apprennent l'humilité - qualité de plus en plus rare.

Pour en savoir plus, un joli article sur Wikipedia.

[Krogoth]

Remarque un perform until ca ressemble franchement à un goto déguisé...

euh non pas exactement. Ce serrai plutot un appel d'un sous-prog ou d'une fonction mais en aucun cas un goto. Le perfom tout simple serrait equivalent a goto mais là aussi en cobol 2 on associe toujours le until au perform.

[Jiriki]

[...]

+1000 pour Douglas Adams

A ce sujet, un bon (gros !) bouquin est "Gödel, Escher, Bach, ou les brins d'une guirlande éternelle" de Douglas Hofstadter.

[FiP_]

[...]

+1000 pour Douglas Adams

A ce sujet, un bon (gros !) bouquin est "Gödel, Escher, Bach, ou les brins d'une guirlande éternelle" de Douglas Hofstadter.

Et là, c'est le drame

Je ne sais pas quel type de réponse cherchait l'auteur du premier message, mais nous voila parti dans la théorie mathématique voire philosophique de l'informatique (et c'est normal)

[geogeo]

La programmation est limitée par le matériel, par les limites de notre imagination, par les mathématiques....

Par exemple aujourd'hui il n'existe toujours pas de logiciel de reconnaissance vocale parfait ou encore de correcteur orthographique qui corrige vos documents en un éclair et ce en corrigeant toutes les fautes.

Je ne parlerais pas de l'intelligence artificiel, vous ne trouvez pas encore un logiciel qui puisse faire la conversation avec vous...

[astero-H]

TIens pas mal cette question...

Moi je suis pas un philosophe donc je vais pas philosopher, je suis pas non plus théoricien ( ) donc je sortirais pas de théorème.

La limite de l'informartique je pense que c'est l'informaticien.

Un exemple, l'algo pour trouver les chiffres du loto existe, le truc c'est que personne est assez doué pour le sortir (limitation technologique + intellectuelle).

Donc perso je dirais que l'informatique peut potentiellement tout faire.

[playstation.2.fg]

Un exemple, l'algo pour trouver les chiffres du loto existe, le truc c'est que personne est assez doué pour le sortir (limitation technologique + intellectuelle).

Le coup du loto ce n'est pas vraiment vrai, étant donné que c'est théoriquement du pur random. Tu ne peux pas vraiment faire de statistiques dessus non plus, étant donné que les boules sont changées après chaque tirage. A moins de lire l'avenir, ou de pouvoir revenir dans le passé, je ne pense pas que devnier la combinaison du Loto soit possible (c'est mathématiques là, pas programmatoire).

Sinon je ne pense pas vraiment qu'il existe une limite à la programmation. C'est comme dire qu'une science sera un jour limitée. On peut toujours (ou presque) avancer, trouver de nouvelles choses. Une comparaison avec la physique serait intéressante étant donné que c'est le programmeur/mathématitien qui cherche souvent la manière dont modéliser un phénomère physique. Donc tant que la physique avancera, la programmation avancera (enfin d'après moi).

Pour l'instant, la seule vraie limite est la limite matérielle et intellectuelle je dirais.

Matérielle car plus on avance vers des programmes complexes, plus ils prennent en ressources (en fonction de la tâche). Mais ce problème n'en est enfaite pas vraiment un. En effet, les techniciens ont su augmenter leur puissance de calcul par divers moyens (clusters, supercalculateurs, etc...), et donc les problèmes matérielles ne sont pas une vraie limite

Intellectuelle, car l'homme a besoin également d'apprendre et d'accepter de nouveaux concepts (et ceci dans tous les domaines). De plus c'est lui qui a créé les langages de programmation, et donc il s'est fixer lui même certaines bornes. En créant de nouveaux langages, plus souples, plus adaptés, il pourra aussi créer des choses plus élaborés.

Pour conclure, étant donné que c'est l'homme qui a créé toute l'informatique et la programmation, je dirais que la seule limite est l'esprit humain

Voila ma minute philosophique est passée (décidément on dirait que ça commence à me manquer les cours de philo ).

[astero-H]

Pour le coup du loto non ce n'est pas un pur random.

C'est juste que les paramètres sont nombreux et complexes

[lorinc]

parametres qui ne trouveront sans doute jamais de capteur pour les retranscrire en grandeur analogique, puis numérique

Sinon, le théoreme d'incomplétude de Gödel montre bien une des limites de l'informatique, en disant qu'ils existent des proposition indémontrable vraies et fausses.

Cela veut dire qu'il existe des algorithmes dont on ne pourra jamais démontrer s'ils sont vrais ou faux, ce qui limite énormément leur utilisation dans un contexte professionnel... de là à penser que certains seront nécéssaires pour obtenir des résultats (au hasard, en crypto, par exemple ).

Cela pose aussi une énorme limite au systèmes intelligents d'approche top-down, tels les systèmes experts, car il n'existe pas systématiquement un chemin logique permettant d'arriver au résultat (théorème indémontrable, donc indéductible).

En gros, tout n'est pas programmable

Bien sûr, il reste les approche bottom-up, mais elles sont beaucoup plus complexe à mettre en oeuvre du point de vue de la programmation, et de la conception. En plus, elles sont beaucoup plus consommatrice en ressource, (mais là, on sort des limites de la programmation).

[Chow]

Tu pourrais expliquer le truc du loto? Tu as un site en parlant? en français de preference !

merci

[fabien29200]

Pour moi la programmation ne fait qu'automatiser ce que sait déjà faire l'esprit humain ...

On peut effectivement prévoir le résultat du Loto en connaissant la structure exacte des boules, la position exacte au démarrage, la structure exacte de l'appareil qui fait tourner les boules ...

Bref, un programme trouvera la solution, mais toi aussi avec une feuille et un crayon. Tu mettras juste énormément + de temps.