Discussion :

[skeud]

De nos jours, on peut tout (ou presque) faire avec un outil informatique.
De plus en plus de métiers sont remplacé de manières informatique.
Actuellement, on est capable de générer du code à partir d'un autre code (compilateur qui transforme un langage en code assembleur puis langage machine).
On pourrait donc penser qu'un programme pourrait traduire du français en langage machine.

La question est:

Un programme peut-il être développé par un autre programme?



Cette question revient dans pas mal de film (I-robot,Matrix par exemple), dans lesquels des machines créent d'autre machine.

Cette question pose aussi un problème d'éthique, si des machines peuvent "procréer", peut-on les considérer comme des "êtres"?


Pour ma part je pense que cela pourrait être possible, mais aurions-nous vraiment l'intéret de le faire?

[gangsoleil]

Bonjour,

C'est techniquement possible. Mais ca s'arrete la.

En effet, tous ceux qui ont pu voir des cahiers des charges savent bien qu'entre ce que veut le client, ce qu'il demande, ce qu'il ecrit dans le cahier des charges, et ce qu'il te dit au cours du developpement, ca n'a rien a voir.

Le temps passe a etablir un cahier des charges "compilable" serait probablement plus important, ou au moins aussi long et cher, que de faire developper le code par des humains.

[davcha]

J'ai programmé il y a quelques temps durant mon temps libre un énumérateur de "machine de turing"... En fait, c'était plutôt basé sur le lambda-calcul, mais c'est exactement la même chose.

A côté de ça, j'avais mit en place un système de contrainte qui permettait de définir ce qu'on voulait... Mais c'était très loin d'être au point.

Par exemple, pour définir l'opérateur successeur (+1 quoi), j'avais une série de contrainte, par exemple :
0 -> 1
1 -> 2
2 -> 3

Et ça marche très bien hein. Le programme te sortait un lambda-terme (donc un algorithme) qui satisfaisait à la contrainte.
Le problème, c'est que, tu lui passais 3, il te renvoyait n'importe quoi.
C'est à dire qu'avec la contrainte ci-dessus, t'avais pas l'opérateur +1, mais la fonction qui associe 1 à 0, 2 à 1, 3 à 2, etc...

Le gros problème en fait est : comment définir une contrainte qui réponde vraiment à ce qu'on veut (successeur), sans donner l'algorithme du successeur...

Parce que l'ordinateur doit être capable de vérifier que l'algorithme testé réponde bien à ce qu'on veut. Mais pour faire ça, il faut qu'il puisse tester et comparer l'algorithme avec quelque chose qui se comporte comme ce que devrait faire l'algorithme recherché. Or, ce quelque chose, c'est l'algorithme recherché.

A côté de ça, il y a un 2e problème au moins : celui de l'arrêt.
En gros, c'est pas parce que ton algo donne pas le bon résultat rapidement qu'il ne le donnera pas plus tard (si tant est qu'il soit encore en cours d'exécution).

Bref... On peut clairement pas tout faire dans ce domaine en tout cas. On ne pourra se limiter qu'à une partie de l'ensemble.

[nah666]

On pourrait donc penser qu'un programme pourrait traduire du français en langage machine.

Comme nous le voyons tous les jours dans notre travail de traduction de spécifications en programme, il y a un un grand nombre de points non précisés qui demandent à être tranchés ou indiqués.

Dans l'absolu il est possible de réaliser un programme qui va traduire le français en langage machine, mais tu devra être tellement précis dans cette spécification qu'au final ... tu fera du code.

[zaventem]

Est-ce qu'un développeur peut être remplacé par la machine?
Oui certainement, il suffit de voir certains générateurs de code qui automatisent de façon plutôt pas mal une partie de la programmation.

Est-ce que l'on pourra un jour construire des solutions entières en se passant de développeurs, j'en doute.

[Chatanga]

C'est un peu confus.

Si on parle de traduire un algorithme exprimé sans ambiguité du français (ou une autre langue naturelle) vers un langage formel, la réponse est oui. Il faudra juste une personne (qu'on appellera un développeur) pour trouver la formulation sans ambiguité.

Si on parle d'un algorithme capable d'en produire un autre, la réponse est évidemment oui et ça n'a rien de sensationnel s'il n'y a pas plus de contraintes.

Si on parle d'un algorithme capable d'en produire un autre qui résout un problème donné quelconque (pas un sous-ensemble bien délimité donc), la réponse est connus depuis pas mal de temps et c'est non : cf. le théorème de Gödel.

Une question plus intéressante serait : "que possède l'homme qui lui permette d'imaginer des solutions et qu'un algorithme ne possède pas ?". Roger Penrose répondrait la conscience. Peut-on construire une machine artificielle pensante ? On ne sais pas encore (sans-doute que oui, ce serait un peu frustrant sinon). Quant à savoir si on devrait le faire une fois en mesure de le faire, c'est aussi une bonne question... Personnellement, je n'hésiterais pas. Il n'y a pas de raison de se limiter à ce que la nature nous a donné, y compris en terme de reproduction. La frontière ne sera d'ailleurs probablement pas stricte entre humains et machines. Le biologique n'est qu'une forme de mécanique très évoluée et on commence déjà à jouer avec des solutions biomécaniques (transistors organiques, organiques artificielles, etc.). J'imagine aussi que la transition ne se fera pas d'un seul coup. On devrait savoir étendre le cerveau humain avant de le dupliquer (implants mémoires avec des neurones de synthèses par exemple), modifier le génomes de nouveau-nés pour leur permettre de vivre sous les océans ou dans l'espace (des corps différents produisent aussi des esprits différents aux pensées différentes), etc. Bref, en 2019 la question ne sera pas de savoir si on est un humain ou une machine, mais plutôt si on est suffisamment riche (pour améliorer son corps biomécanique et son esprit augmenté) ou trop pauvre (pour soigner ses poumons ou réparer son injecteur d'huile).

[gorgonite]

il ne faut pas oublier aussi la "programmation graphique", on décrit des modèles avec des relations et des contraintes, et une chaîne de compilation dédiée effectue le restes... alors clairement ce n'est pas un cahier des charges, mais ça reste plus compréhensible pour un non-développeur : ex pour les controle-commandes avec des outils orientés automaticiens

[skeud]

La question que je me pose surtout c'est:

Si on arrive bien à réaliser notre programme, en demandant au client comment il veut que ça fonctionne, pourquoi une machine ne pourrait pas en faire autant?

Il m'arrive souvent, lors de la création d'algorithme, de me demander:
"Comment je ferais moi-même?"
Et de reproduire ma démarche en code.
On pourrait donc se poser la question, comment je fais pour coder?
Et reproduire notre démarche en code.

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

Ensuite effectivement, il faudra des développeurs pour créer de tel programmes. De la même manière on a besoin de pilote pour conduire les machines qui remplacent les ouvriers.

Conclusion, on pourrait réduire l'effectif de moitier grâce à une tel technologie.
Chose qui plairait à pas mal de pdg je pense. (mais pas à nous, pauvre codeur)

[souviron34]

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

Là où tu te goures, c'est que même algorithmiquement, il peut y avoir plusieurs solutions à un problèmes, solutions qui ont certains avantages par rapport à d'autres, et qui, en l'absence d'autre chose comme entrée, deviennent indécidables..

D'excellents exemples se trouvent partout en algorithmie géométrique : entre économe de mémoire, économie de vitesse, économie de complexité, économie pour des calculs ultérieurs, hypothèses sur la répartition des données initiales, etc etc, le même but peut être atteint par diverses solutions...

Sans une intervention humaine qui "hiérarchise" les priorités (et ceci est au cas par cas en général), impossible de choisir "le bon" algorithme...

Par exemple un tri... Mais on peut aussi penser aux algorithmes d'enveloppes convexes, au plu court chemin, etc etc..



Ce qui fait la force de l'intervention humaine, c'est justement de prendre en compte des contraintes non-quantifiables facilement (comme pour le design)... Et d'avoir des "associations d'idées" à la base de la plupart des algorithmes importants...

[Ubiquité]

Fondamentalement être développeur c'est traduire des spécifications exprimées en langage naturelle (écrite, oral, peu importe) en langage formel compréhensible par la machine.
Donc on peut se passer de développeur si on peut écrire les specifiquation en langage formel sans lui. Pour cela il faut un langage de programmation (le langage formel) suffisament simple pour que tout le monde le maitrise.

[skeud]

Là où tu te goures, c'est que même algorithmiquement, il peut y avoir plusieurs solutions à un problèmes, solutions qui ont certains avantages par rapport à d'autres, et qui, en l'absence d'autre chose comme entrée, deviennent indécidables..

Je suis d'accord mais pour décider, on utilise bien une logique, hors l'ordinateur est logique lui aussi, il suffirait de lui donner cette logique de la même manière qu'on nous la donne, pour qu'il puisse faire le choix.

Donc on peut se passer de développeur si on peut écrire les specifiquation en langage formel sans lui. Pour cela il faut un langage de programmation (le langage formel) suffisament simple pour que tout le monde le maitrise.

A force de simplifier de plus en plus les langage (ie langage bas niveaux -> langage haut niveau) on finira bien par arriver à un résultat proche de ce que j'explique

[zaventem]

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant. Là où ça posera des problèmes, ce sera pour le design, une machine ne peut que reproduire, pas inventer.

il y a un an ou deux, j'ai eu l'occasion de tester un outil de Business Process Modeling qui générait automatiquement une grande partie du code de l'application avec très peu d'intervention technique de l'IT (le principal travail consistait à lier les données métiers aux champs de la base de données). Le résultat était plutôt pas mal mais cela a un prix.

1. Les processus métiers doivent être définis rigoureusement dès le début et de manière très formelles. Cela a une valeur ajoutée pour le métier en offrant des processus documentés de manière complète et cohérente dans l'ensemble de l'entreprise mais le travail pour ce faire est colossal
2. Quand les processus sont complexes et fortement non-linéaires, on évite pas de mettre les mains profondément dans le cambouis et la complexité des développements sont alors souvent plus compliqués.
3. L'architecture de la solution est largement dictée par la solution. Si celle-ci n'est pas mauvaise en soi, cela peut poser problème par exemple lorsque qu'un même traitement doit être tantôt exécuté à la demande cas par cas, tantôt exécuté en batch sur un grand nombre de données.

Cela fonctionne dans des applications de gestion telles que gestion d'inventaire, gestion des clients,... mais c'est encore loin d'être une solution universelle.

En fin de compte, si le seul but est de générer automatiquement l'application, je trouve que l'intérêt est très limité: le travail de modélisation et de spécification en amont est tel qu'une fois qu'il est fait, le développement en lui même ne représente plus qu'une "simple" formalité.

[souviron34]

J'ahouterais que le seul cas où c'est simple c'est :

Si on programme un logiciel qui pose ces questions auxquelles le client répond, on pourra générer le code correspondant.

ça c'est un système expert..


J'ai eu le cas avec le Département de la Protection à La Jeunesse : un soft fait pour que les intervenants puissent décider si le gamin rentrait dans la catégorie "sévices", "à surveiller", "trè dur", "à signaler", etc tc...

Tout ce que ça faisait c'était poser dans l'ordre les questions de la loi, et aiguiller suivant les bons aiguillages au fur et à mesure..

Mais au-delà de ça, et comme le dit Zaventen, à part des champs d'actions très limités, c'est irréaliste pour des questions et de coût et de complexité des phénomènes / demandes / possibilités / algorithmes / décisions ...

[fregolo52]

Cette question revient dans pas mal de film (I-robot,Matrix par exemple), dans lesquels des machines créent d'autre machine.

Tu as oublié le meilleur de tous, mais c'est peut-etre ta jeunesse qui fait ça !!

Terminator et SkyNet !!!!

[skeud]

Tu as oublié le meilleur de tous, mais c'est peut-etre ta jeunesse qui fait ça !!

Terminator et SkyNet !!!!

voila terminator, je savais bien que j'en oubliais un

Par contre connais pas skynet, je sais quoi regarder ce soir

Peut-être est-ce du à ma jeune expérience, mais j'étais persuader que coder un programme qui en code un autre en fonction des demandes était réalisable, certe ça prendrait pas mal de temps (en année bien sur).

Je me mets souvent a la place de l'ordinateur lors de la création d'un programme, pour savoir comment faire tel ou tel chose, et à chaque fois je prend des décision logique choisi par des paramètre quantifiable.
J'agis comme une machine en quelque sorte , donc une machine aurait pu agir comme moi

[Ubiquité]

voila terminator, je savais bien que j'en oubliais un

Par contre connais pas skynet, je sais quoi regarder ce soir

haha, skynet c'est l'ia qui créa terminator.

[skeud]

haha, skynet c'est l'ia qui créa terminator.

ah fort bien, n'ayant regarder que le dernier et il y a fort longtemps, je ne me rappelle plus du tout de tout ça, une cure s'impose ^^

[Nebulix]

Si on arrive bien à réaliser notre programme, en demandant au client comment il veut que ça fonctionne, pourquoi une machine ne pourrait pas en faire autant?

La gégène ?

Donc on peut se passer de développeur si on peut écrire les specifiquation en langage formel

le travail de modélisation et de spécification en amont est tel qu'une fois qu'il est fait, le développement en lui même ne représente plus qu'une "simple" formalité.

+1. On peut parfaitement se passer du développeur ... dès qu'il a fini son boulot.

[TropMDR]

Bon je vais tenter une dernière fois d'apporter une réponse sérieuse et avec un vague fondement scientifique, qui dépasse le "nan mais sérieux, je vois pas comment on peut faire, c'est trop pas possible", et après j'abandonne.

La questions initiale est: peut-on écrire un programme qui écrit des programmes.

La réponse simple est : il est impossible d'écrire un programme qui dans le cas général est capable, à partir d'une spécification, de générer un programme. C'est en effet un problème indécidable.

Donc la question suivante est: est ce qu'il est possible d'écrire un programme qui arrive quand même parfois à programmer. Puisqu'un être humain arrive à programmer (du moins certains êtres humains !), est-il possible de simuler le processus intellectuel qui mène à offrir une solution algorithmique à une spécification ?

Cette question peut se comprendre de deux façons: "saurait-on le faire maintenant ?" et "est ce possible dans l'absolu ?".

A la première question, la réponse me semble assez clairement être "non". On n'a pas le niveau de connaissance algorithmique pour ça, ni sans doute la puissance de calcul. Disons que quand on compare ce qu'on fait actuellement en terme d'intelligence artificielle et de "machine learning", on est très très loin de faire programmer un ordinateur.

La seconde question, et c'est là qu'il me semble que je suis lourdement incompris est donc "y a-t-il des raisons fondamentales et incontournables qui font que l'on ne pourrait pas simuler un processus créatif?". Et là, je persiste et signe, ça relève à se demander si un cerveau humain est plus qu'une machine de turing. Et savoir qu'un cerveau apprend, a plein d'unité en parallèle, est façonné par son environnement etc. ne sont absolument pas des arguments contre le fait que ce soit juste une machine de turing. Il est trivial de simuler un comportement pavlovien, le machine learning (à savoir un algorithme qui change ses réponses au fur et à mesure de son apprentissage, c'est à dire en étant confronté à de nouvelles information) est utilisé tous les jours, etc. Savoir si la pensée humaine est plus qu'une machine de turing est une question qui, à ma connaissance, n'a aucune réponse "sérieuse".
Maintenant pour le rapport à "l'âme", le problème est le suivant : un certain nombre de personnes (mais ça ne fait pas consensus) pensent que dans notre monde physique, on ne peut pas faire mieux qu'une machine de turing. Donc si l'esprit humain est supérieur à une machine de turing, alors il ne serait alors pas juste le résultat de connexion électrique dans le cerveau, et serait donc "en dehors du monde physique". Bref, une sorte d'âme. Et donc ne serait jamais simulable. Donc cette question n'est pas totalement hors sujet.

[davcha]

Je me mets souvent a la place de l'ordinateur lors de la création d'un programme, pour savoir comment faire tel ou tel chose, et à chaque fois je prend des décision logique choisi par des paramètre quantifiable.
J'agis comme une machine en quelque sorte , donc une machine aurait pu agir comme moi

Oui, mais tu y arrives parce que tu as une vision globale du problème, tu le comprends et tu as une certaine expérience de la vie qui te permet de te référer à des problèmes plus ou moins similaires pour t'aiguiller dans ta démarche.

Un ordinateur n'a pas cette vision globale, ne comprend pas et ne dispose pas d'un contexte suffisant pour s'aiguiller comme tu le fais.

Ca changera peut-être avec l'informatique quantique, si un jour on arrive vraiment à en faire quelque chose. Mais pour l'instant, le simple fait de faire un choix algorithmique entre diverses possibilités est un problème : pour faire ces choix, il faut déjà découvrir les possibilités. Et cette activité de découverte est finalement très consommatrice en temps, encore plus pour un appareil aussi "simple" qu'un ordinateur (simple en regard de ton cerveau et de ta vie hein).