Discussion :

[Bluedeep]

Il existe en effet des langages qui pourraient être chacun une nouvelle catégorie à lui tout seul, la catégorie "langage fonctionnel" n'étant pas une catégorie fourre-tout dans laquelle on mettrait tout ce qui ne rentre pas ailleurs.

Sans doute. Il semble que la catégorie "langage de requête" soit admise, même si elle semble un peu "ad hoc", au sens où elle serait plus énumérée que définie.

[souviron34]

Le SQL n'est qu'un cas particulièrement clair d'une réalité de base de l'informatique: tout language de programmation bien structuré est un système de logique formelle permettant de décrire des problèmes et une méthodologie pour les résoudre.

Cela dépend de la plateforme technique qui, bien entendu, doit être choisie en fonction des contraintes du projet.

Pour rebondir sur vos 2 remarques :

Par exemple pour construire des IHM, tout un tas d'outils 4G sont soi-disant apparus : entre Delphi, les différents IDE style Eclipse ou NetBeans, VC++, etc etc..

Chacun de ces outils fait - normalement - les choses de bases de fabrication d'une IHM..

Pourtant, ils les font tous de manière différente...

Comment un "langage logique" pourrait-il choisir parmi les différentes manières, au risque de se retrouver avec du code obsolète ou non-compatible (problème des compilateurs, avec gcc et ses N variations/spécialisations/options dont i faut attendre la release ou debug : qui est bien écrite par quelqu'un, non ??) ??

Si je dis "changer l'accessibilité de ce champ de texte", suivant les cas ce sera une propriété du Widget, du parent du Widget, avec focus ou sans, en callback ou forcé, etc etc...

Si je dis "présenter une liste", comment le "traducteur" chosira-t-il entre une liste "normale", un combo-box, une liste de toggles, une liste de radio ??



Ce "langage" serait donc une "pré-compilation", nécessitant d'une part des programmeurs pour le faire, d'autre part des progammeurs pour modifier le résultat (car chacun ayant déjà eu l'occasion de faire une IHM sait qu'à part pour les cas simplissimes, tout outil nécessite des choses particulières pour atteindre telle ou telle propriété) .

Etant donné que la "logique" dépend quasiment de chacun, quand on parle d'autre chose que de maths pures, je ne vois pas très bien...

Honnêtement, je n'y vois strictement aucun intérêt, car, comme UML, ce serait encore un langage et une logique de plus à apprendre, avec encore un échelon suplémentaire et encore des erreurs/imprécisions de traduction supplémentaires... Et donc encore un coût additionnel en termes de maintenance... et de pérennité..

[cap_gregg]

Un aparté sur le SQL : par la fonction qu'il assure, il est plutôt un langage de conception qu'un langage de programmation.


La première justification, c’est qu’il n’y a quasiment aucune différence entre :

- Dire, dans une spécification : « Récupérer les Libellés des Types de Produits dont la Famille est égale à ZZZ »
- Et écrire en SQL « Select Libelle from Types_Produits where Famille = ‘ZZZ’ »

On voit ici que les programmeurs n’ajoutent rien par rapport aux spécifications, ils ne font que les traduire, que les mettre en forme.

Cet exemple montre autre chose. Comme le SQL est une traduction des spécifications, c’est à dire des idées, enlever un mot du SQL c’est enlever une idée. Donc on ne peut pas retirer un seul mot du SQL : c’est le langage le plus court possible.


La seconde raison, c’est que le code SQL n’indique pas au SGBD comment s’y prendre : faire des lectures successives, ou travailler en mémoire, ou utiliser un index (accélérateurs d’accès), ou répartir le traitement sur plusieurs processeurs, ou combiner tout ça.

Non, le code SQL indique simplement ce qu’il faut obtenir à la fin : par exemple les résultats ne doivent concerner que la Famille ‘ZZZ’.

Puisque le SQL décrit le résultat à obtenir, et qu’il le décrit de la manière la plus simple possible, ce langage devrait donc avoir sa place dans les MOA plutôt que dans les MOE.


Cependant il ne faut pas penser que le SQL soit cité comme modèle de langage logique idéal. On a vu avec BO qu’il était possible de faire beaucoup plus simple que le SQL. Mais BO n'est pas non plus un modèle idéal.

Par contre, BO peut être cité pour fixer l’ordre d’idée de la simplicité (c’est le sujet de cette discussion) des futurs outils logiques.

Et le SQL peut être cité comme modèle d’architecture : les concepteurs décriront uniquement ce qu’il faut obtenir, grâce à des langages logiques qui les assisteront pour concevoir. Ces outils permettront de définir le QUOI (ce qu’il faut obtenir à la fin, ce qu’on attend du traitement) de manière non ambiguë, et sans non-dit. Ensuite ce QUOI sera transmis à un système qui saura l’interpréter.

On peut faire le parallèle avec l’industrie automobile. Les concepteurs disposent d’outils de CAO qui les aident à définir ce qu’il veulent obtenir (c’est ce qui correspond aux langages logiques de demain). Quand la conception est finie, les outils de CAO produisent une description très précise de chaque pièce à fabriquer. Autrefois la fabrication de ces pièces était entièrement manuelle (c’est ce qui correspond au codage), mais aujourd’hui elle est automatisée. L’homme ré-intervient ensuite pour assembler et pour s’assurer de la qualité.

L’informatique va connaître à son tour cette révolution industrielle. Même si on peut regretter l’aspect artisanal et humain du codage, on peut reconnaître que ce sera une manière plus moderne de travailler. Et bien sûr, on programmera encore de très belles choses à la main, mais ce sera très marginal. Les culasses des Porsche sont toujours finies à la main.

(Les générateurs de DSL -Domain Specific Langages- sont séduisants pour décrire de nouveaux langages très professionnels, mais ils ne permettent pas, à ce jour, d’utiliser la programmation logique – type prolog -. C’est dommage. En effet un de leurs buts est d’automatiser l’exécution, de remplacer les programmeurs. Or les programmeurs mettent parfois en œuvre une immense expertise, donc pour les remplacer on ne peut pas se passer de systèmes experts.)

[MiaowZedong]

Quelqu'un programme bien AutoCAD, non?

Ce que tu suggères, c'est un peu comme si AutoCAD deviendrait capable de se reproduire, je veux dire, créer soi-même ses nouvelles versions.

[Logan Mauzaize]

Un aparté sur le SQL : par la fonction qu'il assure, il est plutôt un langage de conception qu'un langage de programmation.


La première justification, c’est qu’il n’y a quasiment aucune différence entre :

- Dire, dans une spécification : « Récupérer les Libellés des Types de Produits dont la Famille est égale à ZZZ »
- Et écrire en SQL « Select Libelle from Types_Produits where Famille = ‘ZZZ’ »

A se demander pourquoi on a MERISE et ses MCD/MLD/MPD ...

Ta phrase m'indique seulement qu'il y a une relation entre Types, Produits et Famille ... Quelle est la nature de la relation, ou le nombre de transition nécessaire pour passer de Produits à Types à Famille est simplement sous-entendue ...


Ensuite, si ! le programmeur dit au SGBD comment s'y prendre en y insérant des HINT ou bien en créant des index, des clés primaires, des contraintes, des clés étrangères. D'ailleurs MERISE définit les CIF et les CIM.

Enfin, l'analogie avec la fabrication de la pièce est plus de l'ordre de la compilation que de la génération de code source ... Ce qui rejoint l'idée que le codage est une activité de conception, je laisserai le soin spécialiste sur ce sujet d'expliquer et argumenter.

[chaplin]

Est-ce que la programmation est simple? A partir du moment où il faut traduire un problème complexe en code, la programmation devient automatiquement complexe quelque soit le langage.

Il vient 3 aspects:

• Le niveau d'abstraction du langage
• La lisibilité du langage
• La richesse fonctionnelle du langage

Je suis surpris au sujet du sous-débat sur la définition de la logique. Dire que tout le monde n'a pas la même logique, c'est faux, il faut dire que tout le monde ne suit pas le même raisonnement, ou chacun a son mode de raisonnement, c'est plus logique dit de cette façon . Finalement, il y a des raisonnements logiques au sens juste, c'est du tout ou rien.

[maske]

- Dire, dans une spécification : « Récupérer les Libellés des Types de Produits dont la Famille est égale à ZZZ »
- Et écrire en SQL « Select Libelle from Types_Produits where Famille = ‘ZZZ’ »

Juste pour réagir là dessus - sur le fond je pige pas tout au débat sur la logique & compagnie.

En smalltalk on peut faire la même chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
|familles libellesFamilles|
familles := Types_Produits select:[:type| type famille = 'ZZZ'].
libellesFamilles := familles collect:[:famille| famille libelle].

Moi il me semble que c'est la même chose, pourtant même si ça semble se rapprocher de ce qu'on appelle "logique" ici, et même si le Smalltalk (vieux de 40 ans) tend à se rapprocher du "parler courant" (donc simplicité d'utilisation et de lecture), dès que les spécifications montent en puissance, adieu la simplicité du code.

Alors - j'en sais rien mais - j'ai l'impression que pour faire des trucs simples, c'est faisable des trucs comme ça, mais dès qu'on veut faire un truc plus compliqué - comme quelqu'un l'a dit plus haut - choisir une méthode spécifique via un système expert me semble être un vaste bordel.

D'autre part, je pige pas un truc. Si je désire un logiciel qui gère des stocks, si je comprend bien, je dois lui dire "gère les stocks au mieux" (comme le dit la spec) et mon langage me trouve l'algo optimal pour ça.

Mais comment je fais si je veux lui dire : "gère les stocks au mieux, et de manière plus optimale que mes concurrents ?" - une spec ne dira peut-être pas ça mais, comment faire pour innover si c'est chaque fois un système qui derrière s'occupe des détails du codage pour qu'on se focalise sur la logique ?

[I_believe_in_code]

C'est bien beau de rêver qu'un générateur de code miracle sera capable de réaliser tout seul une application complète à partir des spécifications...

C'est juste oublier que tout n'est pas automatisable (par exemple comment un logiciel peut-il inventer un algorithme ?).

C'est juste oublier que ce qui est automatisable l'est souvent au prix d'une perte de souplesse et / ou de performance.

C'est juste oublier que le mélange code généré / code écrit à la main est une horreur à maintenir.

C'est juste oublier que le seul moyen pour que les spécifications soient assez précises pour être "traduites" directement en code, dans le cas général du moins, c'est qu'elles contiennent au moins autant d'infos que le code lui-même. Autrement dit le code est plus facile à écrire.

Donc là on a quelqu'un qui explique que comme on cherche de plus en plus à automatiser et à simplifier les choses (ce qui est vrai et qui n'est pas un mal en soi, le tout est de savoir ce que cela peut impliquer sur tel ou tel type de projet), on va automatiquement en arriver à la disparition (ou à la marginalisation) de la programmation.

Que ce soit réaliste (et peut-être même déja d'actualité) dans certains cas particuliers, pourquoi pas.

Dans le cas général c'est du délire.

On va bientôt en arriver aux systèmes experts pour écrire un hello world.

J'en ai personnellement un peu assez de toutes ces élucubrations. Quand elles viennent d'un journaliste, ok. Quand elles viennent d'un informaticien, on s'interroge quand même un peu, non ?

On a d'abord eu des feignasses qui nous ont expliqué qu'on peut être un bon programmeur même sans ne rien connaître au bas niveau. (Le bas niveau, tout repose dessus, donc même si vous ne touchez qu'aux hautes sphères, sans savoir ce qui se passe dessous, vous ferez des choix aberrants qui se sentiront dans les performances)



Après il y a eu la deuxième génération de feignasses : ceux qui nous ont expliqué que le paradigme objet était le seul paradigme possible, le seul moyen d'écrire des applications propres et maintenables. (génial ! Ca en fait des langages et des visions du monde qu'il n'est plus nécessaire de se fatiguer à maîtriser !)

Puis la troisième génération qui n'a jamais écrit une seule bibliothèque maison pour rendre ses applications meilleurs que celles de la concurrence. Tout existe déjà, il suffit d'assembler des monceaux de code écrits par d'autres plus talentueux et plus travailleurs que soi. (Jusqu'au jour où on ne trouve pas quelqu'un qui a déjà fait ce qu'on doit faire... il faut donc s'y remettre et, oh surprise, on ne sait plus faire !)

Après il y a eu ceux qui nous ont expliqué qu'on n'avait besoin de connaître qu'un seul langage et que les "design pattern" et les "frameworks" étaient la panacée. Bien sûr, eux non plus n'ont jamais rien créé à la main. En effet chaque génération de feignasses hérite des défauts de la génération précédente et ajoute en plus ses propres envies.

Les feignasses étant de pire en pire, il faudrait en effet que le métier soit de plus en plus facile. Mais les lois de la physique n'ont pas changé, la machine de Turing non plus, et les applications concevables par les humains sont toujours aussi éloignées de la physique et de Turing. Donc comment la programmation pourrait-elle devenir facile ?

Mais je ne pensais pas qu'on en arriverait là. Maintenant la nouvelle mode ça va être de prôner la quasi disparition de l'activité humaine d'écriture de code. Ca vous ennuie tant que ça de devoir programmer ? Si c'est trop dur pour vous, changez de métier.

Non, la programmation telle qu'on la connait depuis des décennies ne risque pas de disparaître. Tout au plus risque-t-elle de devenir une activité assez élitiste, réservée à ceux ayant encore le goûts de l'effort, de la réflexion, et n'ayant pas peur de se heurter à la naïveté de la masse qui croit que programmer une application est facile.

Tiens, je vais de ce pas écrire les spécifications d'un logiciel qui va éclater Photoshop sur son propre terrain... et puis je vais attendre qu'un générateur de code miracle sache traduire mes spécifications en un programme hyper performant. Bien sûr il va au passage devoir inventer une floppée de nouveaux algorithmes. Et puis, tiens, il va rédiger aussi quelques articles scientifiques qui expliqueront les nouvelles découvertes fondamentales qu'il a du faire avant de les appliquer pour arriver au résultat. Quand ce générateur miracle existera, je n'aurai plus qu'à le faire "compiler" mes specs. Je deviendrai alors riche et célèbre, et je demanderai pardon à genoux à cap_gregg pour ne pas avoir cru en sa clairvoyance.

[gilwath]

Pour moi clairement la simplification généralisé de la programmation n'est pas possible, mais la simplification de la programmation pour des domaines particuliers est possible et existe déjà on appelle ça les DSLs ( Domain specific languages ), SQL en est un, HTML et CSS peuvent être aussi considérés comme des DSLs, il existe énormément de DSLs ecrite en Clojure, Ruby répondant chacune à des problèmes spécifique ( déploiement d'application, d'infrastructure, d'aggregation ) . Par contre une chose en laquelle je ne crois pas c'est les générateurs de code car d'après mon expérience on finis toujours par mettre la main dans le camboui pour pouvoir répondre à une demande bien spécifique et s'y retrouver sur du code généré c'est loin d'être une parti de plaisir. Donc clairement je ne crois pas à la simplification généralisé de la programmation.

[Luckyluke34]

Cependant, la machine restera la même! D'ailleurs, pas une fois il ne mentione la machine, le binaire, à le lire on pourrait croire qu'il ignore jusqu'à l'existence du bas niveau. Il veut donc former des programmeurs qui ne sauront pas ce qu'ils font.

Quand tu parles français, est-ce que tu penses aux racines indo-européennes des mots que tu emploies ? Probablement pas. C'est un peu pareil pour la programmation haut niveau : notre cerveau est beaucoup plus efficace lorsqu'il peut se concentrer sur le niveau de langage pertinent pour la tâche de développement en cours sans se préoccuper de la plomberie sous-jacente. Les premiers langages "évolués" ont d'ailleurs été créés pour s'abstraire du fardeau d'écrire de l'assembleur. C'est aussi un peu le propos de langages comme Lisp (qu'on peut difficilement taxer de L4G "cliquodrome" pour débutants) qui permet de créer des couches successives de langage se reposant sur les couches du dessous en supposant par "wishful thinking" qu'elles vont fonctionner.

Pour autant, ça ne nous empêche évidemment pas de connaître le fonctionnement bas niveau de la machine (avoir appris les racines indo-européennes) et donc de "savoir ce qu'on fait" quand on prend un peu de recul.

Donc coder sans penser au bas niveau ne nous empêche pas de connaître le bas niveau, ce n'est absolument pas incompatible.

Il y a bien sûr des cas où on ne peut pas faire abstraction du bas niveau, comme le SQL où des requêtes optimisées nécessitent qu'on prête attention à des détails proches de la machine (partitionnement, taille des pages, représentation interne des types de données...) Et encore, on peut faire l'optimisation après. Je pense aussi à la programmation multi-coeurs.

Il reste que s'affranchir du langage machine pour raisonner en termes plus abstraits me paraît bénéfique partout où c'est possible.

[Luckyluke34]

Il faut donc adapter l'outil à la tâche: former les programmeurs pour comprendre l'algorithmie, la logique formelle et les machines qui mettent ça en oeuvre.

Ensuite seulement, on créé les librairies et les métaphores qui permettent d'aller vite.

C'est un fantastique voeu pieux, mais tu fais fi de centaines d'années d'histoire qui vont dans le sens d'une parcellisation des tâches et d'une division du travail accrues.

Il va bien évidemment continuer à y avoir des gens qui créent des ponts entre la machine et des langages de plus haut niveau, mais ce ne généralement sont pas les mêmes qui manipuleront ces langages abstraits pour en faire les programmes de la vie courante (je parle au futur mais c'est déjà le cas depuis assez longtemps).

[el_slapper]

(.../...)Non, la programmation telle qu'on la connait depuis des décennies ne risque pas de disparaître. Tout au plus risque-t-elle de devenir une activité assez élitiste, réservée à ceux ayant encore le goûts de l'effort, de la réflexion, et n'ayant pas peur de se heurter à la naïveté de la masse qui croit que programmer une application est facile.(.../...)

Je suis globalement d'accord avec ton propos, mais je ne suis pas sur que :
(1)il y aie plus de feignasses aujourd'hui qu'hier.
(2)seule l'informatique soit considérée comme "facile" par ceux qui ne la pratiquent pas.

Le point (1) mérite plus de détail. L'informatique est un formidable outil permettant de simplifier certaines tâches. De plus en plus, le grand public a conscience de celà. Il peut en arriver à certaines conclusions erronées - comme quoi tout est facile en informatique. Donc, le débutant peut être surpris par le fait que ça n'est pas toujours drôle ni facile, dans la réalité. Quand on formait les gens dans les années 60, la surprise était moindre. Personne ne prétendait comprendre ces machines bizarres.

L'évolution, donc, s'est faite sur la perception des outils. D'ailleurs, les informaticiens aussi ont oeuvré à simplifier leur propre travail : langages structurés de plus en plus abstraits, routines, outils de développement divers, gestionnaires de source, base de bugs, outils de conception, etc.....

Mais si connecter la tuyauterie se simplifie avec les années, il faut toujours dessiner le plan des tuyaux. Et une spec qui dit "faire un tuyau principal rue laurence qui alimente toutes les maisons de la rue" nécéssitera toujours de faire des choix intelligents, parceque la rue laurence est en pente, qu'elle a un virage, etc... dans le temps on aurait dessiné à la main. Aujourd'hui, on dessine sur de la CAO. Mais il y a toujours une partie reflexion, pour optimiser le réseau de tuyaux, qui est de la conception de bas niveau. Comme le codage.

Tron, le premier film du nom, s'était fait détruire par une certaine critique, qui accusait "l'ordinateur d'avoir tout fait", alors que le boulot des gens travaillant sur ordinateur, justement, avait été colossal. La situation n'a pas vraiment changé, en fait. C'était il y a 30 ans.

[MiaowZedong]

Quand tu parles français, est-ce que tu penses aux racines indo-européennes des mots que tu emploies ?

Avec cette comparaison, tu creuses ton trou....les racines indo-européennes n'ont pas un sens différent des langages actuels, ce n'est pas une manière différente de raisonner. Ce n'est pas une structure sous-jacente à la langue Française, ce sont les restes d'un autre langage permettant d'exprimer les mêmes notions.

L'équivalent linguistique de ce que tu propose serait supprimer l'apprentissage de la grammaire et de l'orthographe, sous prétexte que dans de nombreuses situations on peut s'exprimer sans les connaître. C'est vrai jusqu'à un certain point seulement, et quand je vois les textes écris par des jeunes de mon âge adeptes de cette mentalité, j'ai envie de m'arracher les yeux. Pourtant, le Français n'est même pas "ma" langue (mais je vois les même choses en Anglais et en Allemand). Le pire, c'est que ces personnes arrivent à écrire horriblement même quand elles utilisent des correcteurs d'orthographe!

Le LISP ne s'adapte pas à la façon de penser "naturelle" de l'humain; il est même réputé particulièrement hermétique à cause de principes que la majorité trouve contre-intuitifs, tels que code is data et la récursion. Certes, il n'y a pas besoin de penser en termes de machine (enfin, selon le programme, parfois un peu quand même) mais il faut passer par un formalisme logique/mathématique rigoureux (entre autres raisons, pour permettre à l'interpréteur de gérer proprement les opérations machine).

En ce sens, le LISP est comme le SQL: il cache les opérations machine pour offrir un formalisme logique "métier", adapté à des tâches spécifiques. Le LISP a certes des facultés d'adaptation presque infinies, mais pour s'en servir il faut déjà comprendre le LISP. On n'est pas dans l'optique de rendre la programmation facile à comprendre pour un kikoolol de base.

Certes, il y a une demande de programmeurs aujourd'hui qui entre en conflit avec les coûts et les exigences intellectuelles d'une formation rigoureuse. Certes, certaines tâches peuvent être confiées à des sous-programmeurs utilisant les outils de programmation simplifiée que préconise Victor. Il est vrai que le bas niveau et l'algorithmie deviennent plus élitistes et moins fréquents.

Cela ne fait pas qu'il soit une vérité universelle que fuir tant la machine que la logique formelle améliore la productivité.

[Luckyluke34]

Avec cette comparaison, tu creuses ton trou....les racines indo-européennes n'ont pas un sens différent des langages actuels, ce n'est pas une manière différente de raisonner. Ce n'est pas une structure sous-jacente à la langue Française, ce sont les restes d'un autre langage permettant d'exprimer les mêmes notions.

Peu importe, je pense que tu as très bien saisi le sens de ma métaphore On peut aussi prendre l'exemple du conducteur qui se fiche de savoir quels engrenages entrent en jeu lorsqu'il passe une vitesse.

Je voulais juste dire que le concept de boîte noire marche très bien pour un cerveau humain, il est présent partout sous plein de formes, et ce n'est pas nouveau.

Pour autant, penser à un système comme une boîte noire lors d'une tâche spécifique n'empêche pas d'aller voir ce qu'il y a à l'intérieur de la boîte noire, avant, après ou quand bon nous chante...

[MiaowZedong]

Peu importe, je pense que tu as très bien saisi le sens de ma métaphore On peut aussi prendre l'exemple du conducteur qui se fiche de savoir quels engrenages entrent en jeu lorsqu'il passe une vitesse.

J'ai parfaitement compris ce que tu veux dire, le problème c'est qu'aucune métaphore issue du monde réel ne le représentera bien car, tout simplement, ce n'est pas vrai.

Prenons la boîte de vitesses: non, le conducteur n'a pas besoin de savoir ce que fait chaque engrenage, pas plus que le codeur n'a besoin de connaitre l'addresse mémoire de chaque instruction en langage machine. Par contre, il doit savoir ce qu'est une boîte de vitesses: un dispositif permettant de règler le rapport entre le nombre de rotations par minute de l'arbre moteur et le nombre de rotations par minute des roues. Il doit aussi savoir pourquoi il est important de faire ce règlage, pour avoir plus de couple au démarrage et ne pas abimer le moteur à haute vitesse. Si on lui dit juste de passer les vitesses pour aller plus vite, il ne comprendra pas pourquoi il n'arrive pas à démarrer en côte ("j'étais en cinquième vitesse, pourtant, j'aurais du aller vite").

Heureusement, la tâche est simple, avec peu de variables d'entrée. On peut donc faire des boîtes automatiques pour ceux que I believe in Code appelle des feignasses. Cependant, laisser tout contrôle sur la boîte de vitesse à un dispositif automatique comporte des désavantages: par exemple, il est très difficile de detecter si la voiture va lentement car on est en côte et qu'il faut plus de couple, ou si elle va lentement car le conducteur en a décidé ainsi. Du coup, même chez les boîte automatiques, il y a souvent un moyen pour l'automobiliste d'intervenir sur la vitesse, et de nombreux conducteurs restent avec leur boîte manuelle.

Sachant que la programmation est un problème autrement plus complexe, si l'automatique a de gros problèmes dans les transmissions, comment veux-tu que cela marche en programmation?

[souviron34]

...

J'ai bien ri (jaune) .. Merci

C'est malheureusement un excellent résumé des 20 dernières années...

Et de se faire traiter de dinosaure (quand ce n'est pas d'ancêtre du dinosaure), lorsqu'on ose défendre autre chose (une certaine disucssion dur OO / procédural me revient en mémoire..)...

[deadalnix]

Peu importe, je pense que tu as très bien saisi le sens de ma métaphore On peut aussi prendre l'exemple du conducteur qui se fiche de savoir quels engrenages entrent en jeu lorsqu'il passe une vitesse.

Je suis à peu près certain que Loeb s'y connais plus que moi en mécanique. Tout comme à peu près n'importe quel pilote/chauffeur professionnel.

[yann2]

Bonjour

C'est bien beau de rêver qu'un générateur de code miracle sera capable de réaliser tout seul une application complète à partir des spécifications...

C'est juste oublier que tout n'est pas automatisable (par exemple comment un logiciel peut-il inventer un algorithme ?).

C'est juste oublier que ce qui est automatisable l'est souvent au prix d'une perte de souplesse et / ou de performance.

C'est juste oublier que le mélange code généré / code écrit à la main est une horreur à maintenir.

C'est juste oublier que le seul moyen pour que les spécifications soient assez précises pour être "traduites" directement en code, dans le cas général du moins, c'est qu'elles contiennent au moins autant d'infos que le code lui-même. Autrement dit le code est plus facile à écrire.

Donc là on a quelqu'un qui explique que comme on cherche de plus en plus à automatiser et à simplifier les choses (ce qui est vrai et qui n'est pas un mal en soi, le tout est de savoir ce que cela peut impliquer sur tel ou tel type de projet), on va automatiquement en arriver à la disparition (ou à la marginalisation) de la programmation.

Que ce soit réaliste (et peut-être même déja d'actualité) dans certains cas particuliers, pourquoi pas.

Dans le cas général c'est du délire.

On va bientôt en arriver aux systèmes experts pour écrire un hello world.

J'en ai personnellement un peu assez de toutes ces élucubrations. Quand elles viennent d'un journaliste, ok. Quand elles viennent d'un informaticien, on s'interroge quand même un peu, non ?

On a d'abord eu des feignasses qui nous ont expliqué qu'on peut être un bon programmeur même sans ne rien connaître au bas niveau. (Le bas niveau, tout repose dessus, donc même si vous ne touchez qu'aux hautes sphères, sans savoir ce qui se passe dessous, vous ferez des choix aberrants qui se sentiront dans les performances)



Après il y a eu la deuxième génération de feignasses : ceux qui nous ont expliqué que le paradigme objet était le seul paradigme possible, le seul moyen d'écrire des applications propres et maintenables. (génial ! Ca en fait des langages et des visions du monde qu'il n'est plus nécessaire de se fatiguer à maîtriser !)

Puis la troisième génération qui n'a jamais écrit une seule bibliothèque maison pour rendre ses applications meilleurs que celles de la concurrence. Tout existe déjà, il suffit d'assembler des monceaux de code écrits par d'autres plus talentueux et plus travailleurs que soi. (Jusqu'au jour où on ne trouve pas quelqu'un qui a déjà fait ce qu'on doit faire... il faut donc s'y remettre et, oh surprise, on ne sait plus faire !)

Après il y a eu ceux qui nous ont expliqué qu'on n'avait besoin de connaître qu'un seul langage et que les "design pattern" et les "frameworks" étaient la panacée. Bien sûr, eux non plus n'ont jamais rien créé à la main. En effet chaque génération de feignasses hérite des défauts de la génération précédente et ajoute en plus ses propres envies.

Les feignasses étant de pire en pire, il faudrait en effet que le métier soit de plus en plus facile. Mais les lois de la physique n'ont pas changé, la machine de Turing non plus, et les applications concevables par les humains sont toujours aussi éloignées de la physique et de Turing. Donc comment la programmation pourrait-elle devenir facile ?

Mais je ne pensais pas qu'on en arriverait là. Maintenant la nouvelle mode ça va être de prôner la quasi disparition de l'activité humaine d'écriture de code. Ca vous ennuie tant que ça de devoir programmer ? Si c'est trop dur pour vous, changez de métier.

Non, la programmation telle qu'on la connait depuis des décennies ne risque pas de disparaître. Tout au plus risque-t-elle de devenir une activité assez élitiste, réservée à ceux ayant encore le goûts de l'effort, de la réflexion, et n'ayant pas peur de se heurter à la naïveté de la masse qui croit que programmer une application est facile.

Tiens, je vais de ce pas écrire les spécifications d'un logiciel qui va éclater Photoshop sur son propre terrain... et puis je vais attendre qu'un générateur de code miracle sache traduire mes spécifications en un programme hyper performant. Bien sûr il va au passage devoir inventer une floppée de nouveaux algorithmes. Et puis, tiens, il va rédiger aussi quelques articles scientifiques qui expliqueront les nouvelles découvertes fondamentales qu'il a du faire avant de les appliquer pour arriver au résultat. Quand ce générateur miracle existera, je n'aurai plus qu'à le faire "compiler" mes specs. Je deviendrai alors riche et célèbre, et je demanderai pardon à genoux à cap_gregg pour ne pas avoir cru en sa clairvoyance.

Euh... qui a dit que l'informatique est pour les feignasses ? Bon déjà, elle sert à automatiser des tâches donc d'un côté... quoiqu'il en soit tous les outils que tu cites demandent des compétences. Si je prend une machine à coudre je ne vais pas devenir couturier pour autant ! Donc la machine à coudre est une mauvaise chose ? Non, bien entendu. Personnellement, je ne veux pas voir l'informatique se simplifier parce qu'on serait, soi disant, trop bête mais, bel et bien parce que l'informatique est, dans certains cas, inutilement compliqué. Lorsque je développe, je fais beaucoup plus de plomberie technique que de fonctionnel. C'est cela qui m'embête parce que, souvent, c'est répétitif. Ça peut aussi être source de bug (je n'ai pas la prétention de coder bug free). Le but est de pouvoir se concentrer sur le cœur du métier de l'application : ce qu'elle doit faire.

Donc non, la génération de code ne doit pas être utilisez par tous, il faut d'abord comprendre comment ça fonctionne. Non, la programmation orientée objet ne doit pas être utilisée par tous, il faut d'abord la comprendre. Non les DPs ne doivent pas être utilisés par tous, il faut d'abord les comprendre. Non, on n'utilise pas un framework avant d'avoir compris comment il marche. Non, on ne programme pas tant qu'on ne sait pas comment la machine sur laquelle on développe fonctionne. Ok ! Mais ça, ça s'appelle enfoncer une porte ouverte.

[souviron34]

Mais ça, ça s'appelle enfoncer une porte ouverte.

euh. Elle est plutôt pas mal fermée au vu des discours lus et de la réalité de ce qu'on voit sur ces forums...

[deadalnix]

Euh... qui a dit que l'informatique est pour les feignasses ? Bon déjà, elle sert à automatiser des tâches donc d'un côté... quoiqu'il en soit tous les outils que tu cites demandent des compétences. Si je prend une machine à coudre je ne vais pas devenir couturier pour autant ! Donc la machine à coudre est une mauvaise chose ? Non, bien entendu. Personnellement, je ne veux pas voir l'informatique se simplifier parce qu'on serait, soi disant, trop bête mais, bel et bien parce que l'informatique est, dans certains cas, inutilement compliqué. Lorsque je développe, je fais beaucoup plus de plomberie technique que de fonctionnel. C'est cela qui m'embête parce que, souvent, c'est répétitif. Ça peut aussi être source de bug (je n'ai pas la prétention de coder bug free). Le but est de pouvoir se concentrer sur le cœur du métier de l'application : ce qu'elle doit faire.

Je te laisse faire la conclusion.