|
Linus :
Tout commence
par une simple remarque d'un des intervenants sur le forum
:
« […] je suis d’accord avec Larry : Linux ne
suis pas une direction particulière et semble progresser
par pure chance. »
Hé, ce n’est pas un
bug, c’est une caractéristique !
Connaissez-vous la conception la plus
complexe de tout le système solaire ?
Devinez quoi : ce n’est pas Linux,
ce n’est pas Solaris et ce n’est pas votre voiture.
C’est vous. Et moi.
Et réfléchissez comment vous et moi en
sont réellement arrivé là ? Pas par une conception
compliquée.
Hé oui : « pure chance ».
Enfin, pure chance ET :
-
libre
disponibilité et pollinisation croisée, via un partage
du code, même si les biologistes l’appelle ADN ;
-
un environnement utilisateur plutôt
impitoyable, qui remplace allégrement de mauvaises
versions de nous par des versions fonctionnant mieux,
ainsi éliminant les déchets du troupeau (les biologistes
appellent cela : « la sélection naturelle du
plus adaptée ») ;
-
un important développement parallèle
non contrôlé. (via des « essais-erreurs ») [tactique
déjà remarquée par notre ingénieur
informaticien de 30 ans].
Je suis très sérieux :
nous, les humains, n’avons jamais été capable de
reproduire quelque chose de plus complexe que nous-même,
alors que la sélection naturelle le fait sans même y penser.
Ne sous-estimez pas le pouvoir de la sélection
naturelle.
Et ne faites jamais l’erreur de
croire que vous pouvez concevoir quelque chose de mieux que ce
que vous obtenez d’un cycle itératif avec développement
parallèle basé sur des essai-erreur. Ce serait accorder
beaucoup trop d’importance à votre intelligence.
Très franchement, Sun est condamné. Et
cela n’a rien à voir avec leur pratique de conception ou
leur style de code. [évidemment, une
telle affirmation demande des explications... qui vous sont
fournis juste ci-dessous quelques paragraphes plus loin ! Il suffit de continuer de lire...]
Concernant la sélection naturelle,
on lui fait remarquer :
Je suis très sérieux : nous, les
humains, n’avons jamais été capable de reproduire
quelque chose de plus complexe que nous-même, alors que la
sélection naturelle le fait sans même y penser.
Voilà un argument
intéressant, mais peu pertinent. Nous n’avons pas 10 000
ans ou même 10 ans [en matière
de développement de logiciel]. Nous
devons utiliser notre intellect pour éviter les mauvaises idées
les plus évidentes et, encore plus important, pour éviter
les mauvaises idées « pas si évidentes ».
Linus répond :
Une évolution dirigée,
c.à.d. qui a des objectif plus spécifiques et des pénalités
plus rapides en cas d’erreurs avérées, fonctionne à l’échelle
des dizaines ou centaines d’années, pas à des dizaines de
milliers d’années. Par exemple, la reproduction canine, ou
encore mieux la reproduction du bétail qui a fait des progrès
considérables ces dernières dizaines d’années.
Croire qu’une évolution est nécessairement
lente est sans fondement.
Au contraire, croire que trop de contrôle
est mauvais a certainement des fondements : cela tends à
révéler des problèmes de conception qui n’apparaîtraient
pas avec moins de contrôle.
Ainsi, considérez les reproductions exagérées de certaines
races canines entraînant l’apparition de mauvais caractéristiques.
Autre exemple, l’industrie de la volaille.
Et vous devez gardez à l’esprit que ce
qui précède concerne des entités qui sont bien plus
complexes que vos projets logiciels hasardeux, et dont vous
n’avez pas vraiment réussi à influencer quoique ce soit à
part le processus de sélection.
Être capable d’influencer non seulement
le processus de sélection, mais aussi celui de la mutation
qui en résulte permet à l’évidence de raccourcir le tout.
En résumé, votre qualificatif de « non
pertinent » indique uniquement soit que vous n’êtes
pas très bien renseigné sur les changements biologiques ou,
plus vraisemblablement que vous avez réagit à l’instinct
sans vraiment y accorder une réflexion poussée.
L'évolution biologique est là, et bien
là, et ne prend pas des millions d'années pour opérer des
changements. En fait, la plupart des paléontologistes
considèrent que certaines des modifications survenues après
des désastres naturels ont été étonnamment rapides, même
en l'absence de "contrôle intelligent".
Bien sûr, il est vrai que, parallèlement, l’évolution tend à
favoriser lourdement les formes de vie "stables (les
requins et beaucoup d'amphibiens existent depuis des millions
d'années). Ce n'est pas parce que le processus d'évolution
est lent, mais simplement parce que les bonnes formes de vie
fonctionnent bien dans leurs environnements, et si cet
environnement ne subit pas de modification radicale, elles ont
peu d'incitation à changer elle-même.
Il n'y a pas de "bénéfice
intrinsèque" dans le changement. En fait, il y a
beaucoup de raisons contre le changement, ce qui est un
fait que l'on oublie souvent dans le domaine technologie.
[très vrai : les jeunes ingénieurs
sont fascinés par toutes ces évolutions techniques,
multi-média pouêt-pouêt, streaming, applet, HTML dynamique,
J2EE, etc., etc.,... et perdent la perspective de la vision
métier rappelé par cet ingénieur de 30, ans. Même si
la technologie change, le métier ne change pas toujours
fondamentalement. Et la technologie se doit d'être, en
principe, au service du métier!]
Le
fait que le processus d'évolution soit lent alors qu'il n'y a
pas de raison particulière pour changer est un avantage,
non un désavantage.
Très
franchement, Sun est condamné. Et cela n’a rien à voir
avec leur pratique de conception ou leur style de code.
J'aimerais
connaître les raisons qui vous font dire cela.
Vous les avez lu ci-dessus. Sun est fondamentalement de se
reproduire entre elle-même [en
train de ne créer des idées qu'en son sein ... pas
évident de traduire 'inbreeding'...]. C'est une
bonne pratique pour éliminer des caractéristiques
indésirables d'un groupe, et cela tend à favoriser la spécialisation.
Mais c'est catastrophique en terme de capacité réelle à
survivre, et cela génère un système unilatéral qui ne
s'adapte pas bien aux changements.
Microsoft, malgré tous les arguments qui
existent contre cette société, est avantagé simplement par
la taille de sa population : elle a une base de consommateur
très large, ce qui leur a évité toute spécialisation.
Ainsi, Microsoft a un pouvoir d'attraction bien plus large, et
tout d'un coup la plupart des niches que Sun avait l'habitude
d'avoir ont disparu, et elle se bat pour sa vie dans la
plupart des niches qui lui restent.
Pourquoi pensez-vous que Linux a fini par
être plus largement déployé que Unix ? Cela tient à
l'absence de niche, d'intra-reproduction et à une absence de
contrôle trop directif, ce qui évite les problèmes que l'on
rencontre dans des systèmes non-équilibrés.
Admettez-le, être unilatéral est une mauvaise
chose. Unix mourrait parce qu'il devenait trop
unilatéral.
Essayez de me prouver le contraire.
Ce qui précède déclenche
l'incrédulité et on finit par lui poser la
question :
Et ne faites jamais l’erreur
de croire que vous pouvez concevoir quelque chose de mieux
que ce que vous obtenez d’un cycle itératif avec développement
parallèle basé sur des essai-erreur. Ce serait accorder
beaucoup trop d’importance à votre intelligence.
Linux est ce qu'il est de par sa
conception, pas par accident. Et vous le savez mieux que
personne.
Soyons honnête et
admettez qu'il n'y a jamais eu de conception.
[au sens "design"]
Bien sûr, il y a aussi de la conception.
La conception de Unix a constitué un échafaudage pour le
système, et plus important encore, cela a permis aux gens de
communiquer parce qu'il partageaient une représentation
mentale commune du système, ce qui rendaient plus faciles les
discussions sur les modifications.
Mais c'est comme de dire que vous savez que
vous allez construire une voiture avec 4 roues et un
volant. :
c'est vrai mais les vraies difficultés résident dans les
détails.
Et je sais mieux que personne que la
plupart de ce que j'avais comme vision de Linux il y a 10 ans
n'a rien à voir avec ce que Linux est devenu
aujourd'hui. Il n'y avait là certainement aucune conception
préméditée.
Et j'affirmerai pourtant que personne
d'autre n'a autant "conçu" Linux que moi, et je
doute que beaucoup de monde ne soit pas d'accord. Ce
système a grandi. Il a évolué avec beaucoup de mutations ;
et parce que ces mutations n'étaient pas dues au seul hasard,
elles étaient plus rapides et plus contrôlées que les
particules alpha dans l'ADN.
La question est
de savoir si Linux pourrait encore être conçu à son
échelle actuelle.
Faites-moi confiance.
Il n'a jamais eu de conception.
Et je vais même aller plus loin et
affirmer que aucun gros projet majeur de logiciel qui
ait jamais été complété dans le marché en général (et
non pour une niche) n'est jamais passé par ces jolis petits
cycles de vie que l'on vous enseigne dans les cours de génie
logiciel. Avez-vous jamais entendu parler d'un projet qui a
vraiment démarré en essayant de bien définir toutes ses
fonctionnalités et en faisant une phase rigoureuse de
conception, puis d'implémentation.
Dans vos rêves !
Les logiciels évoluent. Ils ne possède
pas de "conception". La seule question est votre manière
de contrôler cette évolution et à quel point vous
pouvez assimilé des sources externes de modifications.
Et trop de contrôle de cette évolution
vous tuera. Inévitablement et sans faillir. Toujours. En
biologie et pour les logiciels.
Amen.
[Hophophop... là
je dois intervenir, je n'y tiens plus.
D'abord, gardez bien à l'esprit que Linus
est un tech-ni-cien, et un très très bon technicien. Son
point de vue découle de son domaine d'excellence.
Ensuite, et je l'ai détaillé dans
l'article sur enjeux
du développement objet sous AGL,
ces cycles de vie - notamment le cycle conception-codage -
n'ont une chances que s'ils sont automatisés et gérés par
l'outils AGL. Garantir une cohérence permanente entre le code et
le modèle UML permet de développer une conception
sophistiquée, car facile à modifier si besoin. Cette
cohérence se garantit d'autant mieux avec un paradigme
de
programmation objet, pour lequel UML est particulièrement
adapté. Or ces techniciens codent toujours en C (ce qui n'est
pas une critique ! Le langage, bien manipulé, est très
efficace, adapté au projet - un système d'exploitation -
alors que le C++, comme le fait remarquer son créateur Bjarne
Stroustrup, peut
s'avérer très dangereux.)
Évidemment, de tels outils, comme rappelé
dans AGL
: les grands écarts,
laissent encore de côté l'architecture
et l'analyse,
2 phases en amont de la conception et du code. En aval, les
Tests-Unitaires commencent
tout juste à apparaître (fin 2001) dans les AGL, avec
l'intégration du pattern de test JUnit.
Enfin, pour contrôler cette évolution, le
cycle Itératif semble être
une démarche pleine de bon sens et très souple.]
Je ne peux pas
croire toutes les sornettes que vous débitez à ce sujet et
je ne pense pas que vous y croyiez vous-même. Si vous y
croyez, vous avez besoin de vacances. Je suis complètement
pour laisser les gens expérimenter, laisser le logiciel
évoluer, tout cela est bien. Mais quelqu'un doit garder un œil
sur l'ensemble.
De la même façon que quelqu'un doit garder un œil sur notre
évolution de façon à vous permettre d'exister ?
Qui est naïf ?
Si personne ne
doit garder un œil sur le projet, Linus, dégagez. Vous
n'êtes pas indispensable et vous venez juste de le prouver.
Oh absolument.
J'aimerai que plus de gens s'en rendent
compte. Certains ne le réalisent que lorsqu'ils sont vraiment
furieux contre moi et disent « allez vous faire voir, je peux
faire ça par moi-même ». Et vous savez quoi ? Ils ont raison
en plus, même s'ils arrivent à cette conclusion sur la base
de raisons que je considère incorrectes.
La raison pour laquelle je fais Linux n'est
pas parce que je crois être "indispensable". C'est
parce que je trouve cela agréable et parce que j'en suis venu
à croire que je suis meilleur dans cet exercice que la
plupart d'entre vous. Pas forcément meilleur que tout le
monde, mais assez bon et avec assez de connexions sociales
pour me rendre incontournable en ce moment.
Mais "indispensable" ? Ne soyez
pas si enfantin. Vous m'accordez trop d'importance.
Et pourquoi devrais-je me retirer juste
parce que je ne suis pas indispensable ? Êtes-vous
indispensable au bonheur continu de l'humanité ? Je ne
pense pas, bien que vous soyez bien sûr libre de me
contredire. Devriez-vous donc juste vous "retirer"de
la vie parce vous n'est pas à strictement parler
"indispensable" ?
Est-ce que je dirige des choses ? Oui, mais
très franchement, d'autres personnes dirigent aussi des
choses. Et pas mal de compagnies font parties également de
cette évolution, qu'elles le réalisent ou non. Et également
tous les utilisateurs, qui finissent par faire parti du
programme de "test de robustesse".
Et oui, je crois en effet en ce que je dis.
Linus.
Devant une telle attitude (style "je persiste,
signe et contre-signe"), certains finissent par admettre,
ironiquement :
Ok. Il n'y a pas eu de conception,
justes des "mutations pas trop aléatoires"...
Comme c'est profond...
Je ne prétends pas
être profond, j'affirme juste le faire pour le fun.
J'affirme que les gens qui pensent
que vous "concevez" des logiciels simplifient
grandement le problème et ne réalisent pas comment eux-même
travaillent.
Certains font remarquer :
Il y a une une architecture globale.
Demandez à Dennis et Ken.
Demandez leur. Je vous
parie 5 $ qu'ils seront d'accord avec moi, pas avec vous. J'ai
parlé avec eux, mais pas vraiment sur ce sujet précis, donc je
pourrai peut-être perdre le pari, mais je pense que j'ai les
meilleures probabilités de gagner.
Si vous tenez à voir un
système qui a été conçu plus rigoureusement, vous ne
devriez pas vous adressez à Dennis et Ken, mais plutôt vous
tourner vers des systèmes comme L4 et Plan-9 et des gens
comme Jochen Liedtk et Rob Pike.
[Jochen
Liedtk, décédé en juin 2001, est
à l'origine d'un OS appelé L4.
Plus précisément, il s'agit d'un micro-kernel,
c'est-à-dire un noyau d'OS qui ne fournit que les services
essentiels comme les tâches, les threads, la communication
inter-process (IPC). L4 a été écrit en C++
!
Plan
9 est un OS développé par, entre
autres, Rob Pike chez Bell Labs depuis le début des années
1980 et dont on peut trouver l'organisation dans cet article.
Remarque : ce ne sont pas, de loin, les
seuls OS
libres de droit.]
Et avez-vous remarqué comme ils sont peu
connus ou appréciés ? La "conception" est comme
une religion : en abuser vous rend inflexible et impopulaire.
L'architecture centrale de Unix a subi une
évolution. Bien sûr, il y a quelques idées de base, mais
les idées de base ne font pas un système. [cela
rejoint la remarque sur la voiture
du début d'article].
Quand ils disent que la difficulté réside
dans les détails, ils essaient de vous dire que les détails comptent.
En fait les détails comptent beaucoup plus que la conception.
[encore une
remarque de technicien, et très honnêtement, même dans un
environnement qui se prête à la conception, avec un
paradigme objet et un langage de modélisation adapté comme
UML, cette remarque reste vraie.
L'article sur les enjeux
du développement objet sous AGL
insiste sur ce problème : mettre en avant les concepts et la
conception alors qu'il faut bien un jour faire des choix
d'implémentation, cela est un grand
écart que l'on a, à ma
connaissance, encore du mal à résoudre en 2002.]
Certains s'obstinent à proposer une
méthode de conception :
Voilà une bonne
méthode de conception à la Linux (ou appelez cela une
"mutation pas trop aléatoire", si cela vous
amuse) : étudiez la littérature, réfléchissez bien,
essayez quelque chose et implémentez-le.
Hah !
Je ne pense pas avoir vu beaucoup
d'exemples illustrant cette méthode particulière de
conception.
C'est impressionnant que vous puissiez
penser que c'est comme cela que les choses se passent, mais de
par mon expérience personnelle, je dirais que cela n'est
certainement pas le cas à quelque degré que ce soit. Ce qui
est vraiment impressionnant est que le développement de Linux
pourrait, de l'extérieur, paraître organisé.
Oui, les gens étudient la littérature,
mais ils ont tendance à être trop spécifique. Cela sert
surtout pour des détails comme les timeout des contrôles
d'encombrement TCP. Ce sont des détails importants,
mais qui ne concernent que quelque centaines de ligne de code
sur 20 millions.
Et non, je ne suis pas en train de dire que
le reste est "aléatoire". Mais j'affirme
qu'il n'y a pas de but commun, et quel la plupart des projets
finissent par se faire pour des raisons relativement
aléatoires, comme les intérêts particuliers d'une personne.
Il s'agit de "modifications
directes" à un niveau microscopique. Il y a beaucoup
d'individus qui ont quelques idées générales quant à la
direction qu'ils souhaitent donner au système (et je suis à
l'évidence l'un d'entre eux), mais en définitive on est tous
un groupe de gens avec une vision globale très approximative.
Est cela est bien.
Une vision claire et des mains expertes
sont en théorie de bonne chose. Simplement, je n'ai jamais jamais
rencontré un technicien (moi y compris) auquel je pourrai
accorder ma confiance quant à la direction générale à
adopter sur le long terme.
[très vrai : cela
rejoint la loi n°5 des grands projets informatique,
qui n'existe pas par hasard : "Trouvez le meilleur manager possible, il trouvera le
technicien, le contraire n'est jamais vrai".]
Une vision
trop claire et trop forte peut vous tuer : vous franchirez le
bord de l'abîme, avec la certitude de la connaissance du
chemin qui vous attend devant vous.
Je préfère adopter une "mouvement
brownien", où plein d'améliorations microscopiques et
contrôlées finissent par faire lentement évoluer le
système dans une direction dont aucun des développeur
n'avait vraiment la capacité de prédire.
[vous pouvez visualiser
un tel mouvement sur ce site
et sur celui-là,
qui insiste aussi sur son aspect fractal.
Ce mouvement sert de modèle mathématique pour les mouvement
aléatoire. Cela remonte à une observation
d'une goutte d'eau emprisonné dans un morceau de quartz
au début du 19ème siècle par le botaniste écossais Robert
PERRIN]
Et je crois fermement que, pour que cela
marche bien, vous devez avoir un groupe de développeur
qui est assez étrange et hétérogène.
Pour en revenir à l'affirmation de
départ, où Larry vénère l'équipe de conception de Sun
pour son esprit unilatéral et son contrôle de fer, et pour
en revenir à celle où Linux semble aller mieux par
"pure chance" : je crois vraiment que cela est
important.
Le problème avec un "esprit
unilatéral et un contrôle strict" (ou
"conception") est que vous allez certainement d'un
point A à un point B d'une façon beaucoup plus directe, et
avec une dépense d'énergie moindre, mais comment diable
allez-vous savoir tout le temps où vous voulez effectivement
aller ? Ce n'est pas comme si l'on savait que "B"
était notre destination finale.
En réalité, la plupart des développeurs
ne savent même pas quelles sont les bonnes destinations intermédiaires,
et encore moins la destination finale. Et avoir quelqu'un qui
vous montre le seul vrai chemin est très pratique pour
réaliser un projet, mais j'ai le sentiment fort que même si
"le seul vrai chemin" finit par être en effet le
bon (et avec un chef de projet intelligent, ce chemin peut
être le bon très souvent), il arrive toujours une fois où
ce chemin est vraiment le mauvais.
Et si vous suivez en file indienne, et dans
la même direction, vous n'avez besoin que d'une erreur pour mourir.
A l'opposé, si vous marchez dans toutes
les directions à la fois, et essayez de deviner votre chemin,
vous n'arriverez peut-être pas à la destination que vous pensiez
que vous vouliez, mais vous ne ferez jamais d'erreur
fatales, parce ce que vous finirez toujours par avoir à
satisfaire beaucoup de différentes opinions. Vous
obtiendrez un système beaucoup plus équilibré.
C'est cela que je voulais dire par
"intra-reproduction", et le problème avec UNIX,
c'est qu'il est traditionnellement associé à des compagnies
qui ne s'occupe que d'une seule niche.
(La compagnie Linux tend également à se
diriger vers un marché de niche, mais elle vise différentes
niches, donc le résultat final comprend bien les
"nombreuses directions différentes" qui, je pense,
sont ce que vous voulez pour survivre.)
[Au final, on
retrouve 2 styles de gestion de projet différentes mais pas
forcément opposé :
| -
la gestion itérative
avec son cycle en spirale
et ses livrables réguliers, notamment en terme
d'exécutable ("prototype") et ses retours
d'expérience planifiés ; |
|
| -
une sorte de gestion"radiale" (dont le
centre n'est pas toujours défini avec une
"précision extrême" !) avec apparemment
une qualité de feedback moindre, mais de nombreux
petit retour d'expérience dont certains finissent par
être capitalisés... |
|
]
Certains
critiquent le lien entre la non-validité des cycles de vie et
la non-validité d'une démarche de conception :
Et je vais même aller plus loin et
affirmer que aucun gros projet majeur de logiciel qui
ait jamais été complété dans le marché en général (et
non pour une niche) n'est jamais passé par ces jolis petits
cycles de vie que l'on vous enseigne dans les cours de génie
logiciel.
C'est du
classique :
A) "Faites-mois confiance" ;
B) Maintenant vous avez à votre disposition un nombre
effrayant de mauvaises direction pour vous bloquer.
Est-ce que quelqu'un croit dans ces stupides cycles de vie ?
Non.
Alors est-ce que ce qui suit à quelque chose à voir avec
la conception ?
Non.
Hé,
toute la notion de "conception" réside dans
le fait que vous savez ce que vous allez implémentez, et que
vous concevez en conséquence.
Ou alors vous avec une autre définition du
mot "conception" dont je n'ai pas entendu parler.
Au terme de ce
débat, il reste des désaccords :
Et ne faites jamais l’erreur
de croire que vous pouvez concevoir quelque chose de mieux
que ce que vous obtenez d’un cycle itératif avec développement
parallèle basé sur des essai-erreur. Ce serait accorder
beaucoup trop d’importance à votre intelligence.
Alors, allons
nous ôter l'appendice [pour éviter une appendicite]
dans la version 2.5 ou allons-nous continuer d'espérer que
notre noyau n'attrape pas une maladie sans tenter aucune
action préventive ?
La sélection biologique ne fait rien d'autre que d'ôter
les faibles, elle ne peut créer automatiquement un système
qui fonctionne correctement.
En résumé, je crois que la sélection biologique n'est
rien d'autre que cela : une sélection. La création de
choses requiert une direction.
Il reste également au terme
de ce débat des point d'accord
:
Voilà une bonne
méthode de conception à la Linux (ou appelez cela une
"mutation pas trop aléatoire", si cela vous
amuse) : étudiez la littérature, réfléchissez bien,
essayez quelque chose et implémentez-le.
Cela serait
assumer que la science des ordinateur est une discipline de
conception fonctionnelle [pleinement
opérationnelle]. Or c'est
faux, au mieux nous somme à un stage de l'alchimie. Vous
mettez 2 choses ensembles, cela vous explose à la figure et
vous essayez de comprendre pourquoi. [on
croirait entendre la description de la phase
d'intégration,
que cet ingénieur
de 30 ans avait déjà
identifié.]
Dans la plupart de ces
domaines, il n'y a pas de littérature formalisée. Les
articles scientifique concernant la science informatique
sont basés sur la publication de choses auxquelles les gens
croient déjà. La plupart du reste de cette connaissance
est non-écrite ou isolée dans des labos en tant que secret
commercial, et ne sera probablement jamais réutilisé.
Considérez TCP, par exemple. Le protocole TCP est
spécifié par une série de document. Si vous faites une
implémentation formellement correcte de la base de TCP RFC,
vous n'arrivez même pas à établir une connexion. La
plupart du comportement du flux de contrôle, la mise en
file d'attente et les autres détails ne sont accessibles
que directement via la communauté des développeurs de TCP.
Vous pouvez lire tous les papiers scientifiques que vous
voulez, cela ne fera pas de vous un bon développeur de TCP.
[Les
modifications ont été réalisées et testées au fur et
à mesure qu'elles été intégrées. Seul un vrai
processus de conception peut garantir que cela fonctionne
correctement.]
Cela n'empêche
rien : la conception ne requiert pas de démarche
scientifique. La science aide beaucoup mais les gens
construisent de très bons murs de brique bien avant de
savoir comment le ciment fonctionne.
[Tous ce que
les alchimistes ont jamais réussi à accomplir étaient
des cas d'empoisonnement par le mercure.]
Et aussi la
chimie, en définitive. Vous dévalorisez beaucoup trop
cette démarche.
Mais en ce moment, si l'on me donne 2 morceaux de code,
j'arrive à trouver ce qui se passe en les mettant ensemble
sans vraiment disposer de méthode formalisée.
Dans le cas de l'alchimie contre la chimie, les chimistes
savent juste si cela va vous exploser à la figure ou non avant
de faire l'assemblage (et pourtant, même les chimistes vont
quand-même se planquer!).
Évidemment, ce
type de débat peut facilement dériver vers des sujets
philosophiques beaucoup plus profonds encore. Quelques
exemples :
[Mouais, le
commentaire sur "la conception qui n'a pas besoin de
science" est vrai pour des objets à dimension
humaine (feu, roue, chaise, etc.). Mais à grande
échelle, cela n'est plus vraie. Sans la science il n'y
aurait pas eu les machines à vapeur ou les vaccins ou
...]
[Serendipity]
[heu... en français
"chance" ou "inspiration", la faculté
de trouver des choses intéressante sans vraiment les avoir
cherchées. Ce mot est issu d'un conte Perse : Les 3 princes
de Serendip.] :
[Serendipity est le nom du jeu. Les machines à vapeur ont
été inventées bien avant que les Lois de la
Thermodynamique viennent expliquer son fonctionnement.
Science est le nom que nous donnons aux gens qui ont le
courage de poser de questions simples et qui attendent une
réponse qui a du sens.]
[Cela rejoint d'ailleurs les
travaux de Thomas Kuhn sur le fait que toute observation
scientifique ait sous-tendue par une théorie.
A force "d'inspiration", on en déduit une
théorie que l'on s'acharne à vérifier par l'observation
et les expérience.
Quelques célèbres illustrations :
- la pomme de Newton qui a ravivé des idées sur les
mouvements accélérés et uniformes ;
- les expériences
d'esprit d'Einstein, surtout après ses expériences en
laboratoire où il tentait de mettre en évidence
l'éther... et où il a manqué 2 ou 3 fois de tout faire
exploser ! Devant l'incompatibilité entre l'éther, censé
être au repos absolu, et la notion de relativité, Einstein
finit par abandonner le premier concept, et parle d'un
"espace physique" qui a la propriété de
transmettre les ondes.]
[La science est le nom
donné à la connaissance issue d'une démarche scientifique
:
- création d'une hypothèse (via l'observation, l'instinct,
le génie...) ;
- expérimentation ;
- feedback et correction.
Je pense que l'intelligence et les résultats
scientifiques de ces 3 derniers siècles ont conduit
l'humanité à croire faussement qu'elle pouvait tout
contrôler et concevoir ce que le monde allait devenir.]
Allez, un
dernier p'tit débat pour la route, mais attention, Dieu se
cache dans ce débat !
Connaissez-vous la conception la plus
complexe de tout le système solaire ?
Devinez quoi : ce n’est pas Linux,
ce n’est pas Solaris et ce n’est pas votre voiture.
C’est vous. Et moi.
Et réfléchissez comment vous et moi en
sont réellement arrivé là ? Pas par une conception
compliquée.
Hé oui : « pure chance ».
[Définitions
issues de [MerriamWebster]
des mots "Engineering" et
"Engineer".
"Engineering" : application pratique des principes
mathématiques et scientifiques.
[Attention, ce n'est pas la seule
signification relevée par
[MerriamWebster],
et je lui préfère toujours, comme indiqué en introduction
: "conception et fabrication d'un produit
complexe"].
"Engineer" : piloter la course de, diriger.
Affirmer que l'humanité est (pour reprendre les termes de
Linus) "la conception la plus
complexe de tout le système solaire"
puis affirmer que cette-dite conception est le
résultat de la "pure chance" est une
contradiction grossière.
Les définitions des mots "Engineering" et "Engineer"
implique que la conception est guidée, contrôlée, faite intentionnellement,
construite avec un plan spécifique.
Ce qui serait l'exact opposé de "pure chance".
"pure chance" est du chaos, pas de la conception.
Si l'humanité est un travail de conception, et je pense
qu'elle n'est juste que cela, un travail de conception, cela
suggérerait en des termes explicites la présence d'un
concepteur ou créateur.
Le créateur ici est l'entité individuelle qui possède les
plan de notre conception.
Bien sûr, il s'agit de Dieu.
Dieu nous a conçu.
Nous déduisons cela par observation, parce que nous voyons
en nous-même une conception trop élaborée et
intentionnelle pour ne pas voir la marque de fabrique d'un
créateur.
Conclure que l'on est conçu revient à conclure que Dieu
existe.]
Bien sûr... une telle
affirmation n'a pas manqué de soulever quelques objections
bien senties, la première d'entre elle portant sur
l'utilisation d'une définition d'un dictionnaire alors que
:
- il y a plusieurs sens mentionné (comme je l'ai remarqué
juste avant) ;
- certaines définitions sont écrites pour mettre en avant
une certaine "vérité" ou vision, et cela ne doit
pas être considéré comme un référent absolu.
Mais les remarques suivantes
sont encore plus intéressantes
:
["pure
chance" est du chaos, pas de la conception.]
[Ben justement,
si vous étudiez la théorie du chaos, en particulier le
travail de Prigogine sur la théorie des systèmes, vous
verrez que même un système en apparence chaotique évolue,
et lutte typiquement vers un système stable.
[Ilya
Prigogine (né en 1917),
prix Nobel de chimie en 1977, auteur avec Isabelle Stengers
de "Order Out of Chaos" (1984). Il s'est
intéressé à la thermodynamique des systèmes "loin
de l'équilibre" - par opposition aux système en
équilibre ou proche de l'équilibre. Il y a constaté
l'apparition d'une auto-organisation avec des symétries ou
des patterns récurrents.]
Les étapes d'évolution naissent d'un système stable
devenant de plus en plus instable jusqu'à ce qu'une
évolution ("un bond") soit indispensable à la
survie de ce système.
[Cela rejoint les périodes
critiques qui précèdent la mise en place d'un nouveau
paradigme, évoquées par Thomas Kuhn dans son
approche
systémique et
qui valident ou invalident les théories déjà mentionnées
ci-dessus,
théories qui sous-tendent toute observation scientifique,
toujours d'après le même Thomas Kuhn.]
La conception ("engineering") est typiquement
basé sur la science, mais il peut encore y avoir une
démarche scientifique lorsque la conception est utilisée
pour explorer des systèmes encore non encore expliqués par
la science. Et en plus, on a le problème lié au fait que
la science ne fait pas état des petits ratés : avez-vous
déjà lu un article scientifique qui décrit une
expérience qui a foiré complètement ?
La conception logicielle ("Software Engineering")
est également très différente des autres domaines de
conception, dans la mesure où elle concerne une conception
dans un environnement instable. Notre monde physique
est assez stable, du moins à notre niveau habituel de
perception. Toutefois, nous savons tous que les plate-formes
logicielles sont loin d'être stables et basées sur des
théories fiables, donc toutes les théories que nous leur
appliquons sont issues avant tout d'essai-erreur.
Je pense que le commentaire nous décrivant comme au stade
de l'alchimie est assez pertinent, la majeur partie des
conception consistant encore à mettre 2 choses ensemble et
à voir ce qui marche et ce qui ne marche pas. Ce qui nous
sépare encore de la science est le manque de méthodes
scientifiques reconnues pour documenter les process et
les résultats.]
Cette dernière contribution
a, pour le coup, a jeté un trouble sur le propos initial de
Linus, comme l'illustre la remarque suivante : [Donc...
Linus a certainement voulu dire que nous n'étions pas
conçu, sinon cela aurait été une sacré performance en
terme de conception, or certaines partie de notre corps
peuvent nous en faire douter.] De
fait, un autre intervenant poursuit dans la même direction
: [Aaaargh !
Quelqu'un qui essaie de nier l'évolution ! A nouveau !
[nous voyons en
nous-même une conception trop élaborée et
intentionnelle]
[Expliquez-nous
l'appendice !
Il existe encore parce qu'il n'y a pas de facteurs
environnementaux pour conduire à sa suppression. Si
quelqu'un avait vraiment son mot à dire quant à ce qui
doit se trouver dans le corps humain, il n'y aurait pas
d'appendice.
Si l'on utilise le principe du rasoir d'Occam, on conclut
que Dieu n'existe pas. Il n'existe pas parce qu'il n'y a pas
de besoin justifiant son existence.
[en 2 mots, « Pluralitas
non est ponenda sine neccesitate » ou « la pluralité ne
doit pas être prônée sans nécessité » est une
expression attribuée à William of Ockham (1285-1349),
philosophe anglais et moine franciscain.
Ce "principe de parcimonie" est couramment
interprété aujourd'hui comme "l'explication la plus
simple est souvent la meilleure". En informatique, elle
est dérivée et résumée par K.I.S.S. ("Keep It
Simple, Stupid !")
Un tel principe a été réutilisé par les athés pour
rejeter l'hypothèse d'un Dieu-créateur au profit de
l'hypothèse d'une évolution naturelle, sous prétexte que
si Dieu avait créé l'Univers parfait, ce dernier et ses
composants auraient été bien moins compliqués. William
n'aurait pas approuvé !...]
Et dans les logiciels, on constate qu'un projet majeur comme
Linux peut évoluer de façon autonome, au hasard et dans
toutes les directions. Le fait qu'il ait l'air (en surface)
conçu n'implique pas la présence d'une conception.] Voilà
qui amène quelques réponses bien senties et qui ramène le
propos dans le sens de Linus, qui nous décrit comme la plus
complexe des conceptions : [
[Aaaargh !
Quelqu'un qui essaie de nier l'évolution ! A nouveau !]
Aaaargh!
Quelqu'un qui essaie de nier Dieu ! A nouveau ! ;)
[Expliquez-nous
l'appendice !]
S'il vous plait,
procurez-vous un bouquin d'anatomie écrit cette dernière
décennie. L'appendice n'est pas inutile. Il fait parti du
système immunitaire. Le fait qu'on puisse l'ôter sans tuer
la personne auquel il appartient n'implique pas qu'il soit
inutile, pas plus que le fait que l'on puisse ôter un bras
d'une personne sans la tuer implique que le bras est
inutile!
[Si quelqu'un
avait vraiment son mot à dire quant à ce qui doit se
trouver dans le corps humain, il n'y aurait pas
d'appendice.]
Vous assumez
naïvement que, si vous ne voyez pas de raison justifiant
l'existence de quelque chose, alors il n'y a aucune raison.
C'est assez prétentieux que de prétendre comprendre si
complètement le monde qui vous entoure. Vous ne connaissez
même pas l'existence de plusieurs sujets dont vous ignorez
l'existence. Pouvez vous vous imaginer en train d'expliquer
la physique quantique à quelqu'un qui vivait avant Galilée
? Nous sommes probablement au même niveau d'ignorance
lorsque l'on compare ce que l'on sait à ce qu'il reste
encore à découvrir.
[Si l'on
utilise le principe du rasoir d'Occam, on conclut que Dieu
n'existe pas.]
La rasoir d'Occam
ne prouve rien, c'est juste un guide permettant de
déterminer quelle théorie a le plus de chance d'être
acceptée.
[Il n'existe
pas parce qu'il n'y a pas de besoin justifiant son existence.]
Le seul fait que
vous ne voyez pas de raison justifiant l'existence de Dieu
n'implique pas qu'il n'y ait aucune raison. Cf. ci-dessus au
sujet du fait que vous ne connaissez pas tout ce qu'il est
possible de savoir. Reportez vous également au théorème
d'incomplétude [de Kurt
Gödel (1906-1978), qui démontrait en 1931 à l'age de 25
ans que dans un système formel "SF" donné,
basé sur des postulats de base et des théorèmes qui s'en
déduisent :
- il existe toujours un théorème qui ne sera pas
démontrable à partir des axiomes de bases de SF
(incomplétude). Même en incluant ce théorème parmi les
axiomes de base (SF'), on pourra toujours en trouver un
autre, à son tour non-déductible ;
- on ne peut démontrer la consistance - capacité à ne pas
produire des théorèmes contradictoires - de ce système
formel SF en le modélisant uniquement avec les éléments
du même système formel SF. En particulier, en modélisant
la phrase "SF est consistant" avec les éléments
de SF, ce théorème ne se déduit pas des postulats de base
de SF ! Du coup, dans certain cas, on peut prouver une chose
et son contraire. (inconsistance). ]
: ... même si vous connaissiez tout ce qu'il y a à savoir,
vous ne pourriez tout expliquer ou déduire toute chose,
mais cela ne les rendraient pas moins vraies.
Il est très possible pour quelque chose d'exister sans
qu'aucun besoin ne le justifie. En utilisant votre propre
argument, il est aussi logique de conclure que l'appendice
n'existe pas, puisque vous affirmez qu'il n'y a aucun besoin
justifiant son existence.
Je suis curieux de savoir comment vous pensez que l'Univers
est apparu, s'il n'y a n'y créateur, ni besoin d'un
créateur. Et ne me parlez pas de la théorie du Big-Bang,
je l'ai déjà entendue. Même si cette théorie est sans
doute vraie, elle ne dit rien quant à l'origine de cette
masse très dense et compacte qui a explosé au tout début,
ni pourquoi elle a explosé, ce qui, vous en conviendrez,
est un comportement très inhabituelle pour une masse très
dense et compacte!
[Et
dans les logiciels, on constate qu'un projet majeur comme
Linux peut évoluer de façon autonome, au hasard et dans
toutes les directions.]
J'ai peu vu de
modifications aléatoires dans Linux, et je peux songer à
bien des direction que Linux n'a pas emprunté et ne risque
pas d'emprunter à l'avenir.
Aussi l'évolution n'est peut-être pas une métaphore si
appropriée. Puis-je suggérer la théorie de la "main
invisible" du capitalisme de Adam Smith comme une
meilleur explication ?
A savoir des individus qui agissent dans leur intérêts
propres et qui arrivent, quand les conditions sont bonnes à
une solution pratiquement optimale. ]
[Adam
Smith (1723-1790),
économiste écossais, dans An Inquiry into the Nature and
Causes of the Wealth of Nations (1776), prétend que la
bonne santé d'une société résulte de la poursuite des
intérêts personnels par chaque individu. Cela sert
l'intérêt publique alors que le citoyen est guidé par
"une main invisible". Cela revient au
"laissez-faire capitaliste... mais la crise de 1929 a
fait réfléchir !]
|
