Discussion :

[BenoitM]

Sauf qu'il a enfoncé une porte ouverte : toute personne ayant travaillé avec SQL sait que c'est un langage orienté fonctionnel (même si non objet) : on décrit ce qu'il doit faire, mais pas comment le faire.

Euh vois pas la différence entre un langage soit disant fonctionnel et un autre

[yann2]

Bonjour

Sauf qu'il a enfoncé une porte ouverte : toute personne ayant travaillé avec SQL sait que c'est un langage orienté fonctionnel (même si non objet) : on décrit ce qu'il doit faire, mais pas comment le faire.

C'est tout l'intérêt de l'exemple, il est compréhensible par tous.

Si il n'y avait que les DBA a "gérer" ce langage se serait inquiétant (d'ailleurs sa méconnaissance par les jeunes ingé d'études est assez inquiétante).

Désolé, je voulais parler des SGBD (avec l'heure tardive j'ai oublié le "système"). Bien entendu, on est d'accord que le SQL n'est pas réservé au DBA (mais bon ça n'a pas grand chose à voir avec notre débat).

On peut parfaitement utiliser SQL sur une source Excel et cela depuis des années.

Quand aux instances Java, désolé, mais je ne mange pas de cela , mais il existe un "sql like" en .NET qui s'appelle LINQ qui répond précisément au besoin que tu décrits.

D'ailleurs, si je prend ton message suivant :



C'est précisément LINQ que tu décrits.

J'ai entendu parler de LINQ (je ne fais ni du C# ni du VB), je trouve que c'est prometteur mais cette technologie (qui a 5 ans) corrobore ce qu'on dit, non ? On monte de plus en plus en abstraction pour les tâches simples et il n'y a pas de raison que ça s'arrête.

Encore une fois, il faut voir plus loin que l'exemple SQL. Cela reste un exemple et c'est pour cela que j'en ai donné d'autres. Vous êtes trop focalisés dessus.

[souviron34]

Encore une fois, il faut voir plus loin que l'exemple SQL. Cela reste un exemple et c'est pour cela que j'en ai donné d'autres. Vous êtes trop focalisés dessus.

Entièrement d'accord, mais justement c'est là où l'argument de base pêche :

Par exemple, si dans une spécification il y a "Tous les Clients de moins de 40 ans n'ayant pas passé un minimum de commandes de xxx doivent être identifiés afin d'être relancés", les types d'opérations évoqués sont :

- La lecture (des clients et des commandes)
- La jointure (entre les clients et leurs commandes)
- L'agrégation (la sommation des commandes par client)
- Le filtre (sur les Clients de moins de 40 ans, et sur les totaux de commandes < xxx)
- L'écriture (des clients correspondant aux critères).

On voit que la spécification prise en exemple s'exprime avec seulement 5 types d'opérations logiques : lecture / jointure / agrégation / filtre / écriture.

D'une part j'aime beaucoup () le "on voit que" ..

D'autre part, et c'est là que le bât blesse, quand je lis sa phrase de spec, je ne voit pas en quoi on peut en déduire "logiquement" des termes comme "jointure" ou "aggrégation"... Sans parler de "filtre"..

Ces termes sont orientés, techniques, et n'ont strictement rien à voir avec la spec, mais tout avec le domaine de prédilection de l'intervenant, la notion de SGBD telle qu'elle est à l'heure actuelle, les concepts qui y sont attachés par des langages comme SQL..

Il n'y a donc strictement pas de logique entre la spec et la description des actions qui en est tirée..

Une logique doit être compéhensible par toute personne sensée, par par un spécialiste du domaine..



C'est pour ça que j'ai relevé le "on voit que"..

Moi, n'étant pas spécialiste de SGBD, "je ne vois pas que"...


D'autre part, comme l'a relevé el_slapper :

En informatique, le QUOI (ce qu'il y a à faire, la logique) n'est pas complexe, par exemple les concepteurs arrivent à l'expliciter dans les spécifications en quelques lignes seulement.

Est faux...

C'était (théoriquement) le but de UML, et "on voit que" ça ne marche pas.. Il y a autant d'échecs avec que sans..

Pour la bonne et simple raison que la "logique" d'une part dépend des gens, et des projets, et des environnements, et d'autre part que sa traduction en informatique dépend des "paradigmes" : pour moi, qui ai une logique "fonctionnelle", orientée procédurale donc, ma construction ne sera pas du tout la même que quelqu'un formé à l'OO..



Ensuite, quand je lis :

La réaction des programmeurs est logique. Leur métier traditionnel, parce qu'il s'effectue manuellement, et parce qu'il nécessite un énorme savoir faire, s’apparente complètement à un compagnonnage moderne. Il est donc logique que les programmeurs aient un goût immense pour leur métier. Or cette évolution de l’informatique va faire disparaître ce métier traditionnel, pour faire passer les programmeurs d'une activité de codage vers une activité plus fonctionnels.

C'est justement ce qui était le cas AVANT les 20 dernières années..

A part dans les très grosses équipes de cycle en V, tous les intervenants étaient mixtes (c'est d'ailleurs pour ça que ça s'appelait "analyste-progammeur").

L'évolution des 20 dernières années a produit des "spécialistes" du codage, avec des titres tous plus ronflants les uns que les autres, et j'ai déjà eu l'occasion de dire que entre la bêtise des recruteurs et l'ego des candidats, on a droit à des offres de "Chef de Projet JEEE" ou "Architecte Java", alors que la fonction et le travail est "Chef de Projet" ou "Architecte"..

Ce qu'il décrit là serait donc un retour vers les bases..



Enfin, quand je lis :

La seconde raison, c’est que cette révolution (la fin du codage) va être d’une ampleur générale,

ça me fait irrésitiblement penser aux discussions dans le forum IA où certaines personnes décrivent un avenir proche et radieux dans lequel un ordi nous comprendra, gérera notre vie, et où "intelligence" est compris dans notre sens humain et non pas dans le sens des machines..

Encore une fois, qui laissera sa vie dépendre entièrement, à 100%, d'une machine, un avion sans pilote, une voiture sans conducteur, un élève sans prof, etc etc.. ???

[deadalnix]

Sauf qu'il a enfoncé une porte ouverte : toute personne ayant travaillé avec SQL sait que c'est un langage orienté fonctionnel (même si non objet) : on décrit ce qu'il doit faire, mais pas comment le faire.

Un langage fonctionnel, c'est Caml, LISP ou Haskell. SQL c'est tout ce que tu veux sauf du fonctionnel.

[yann2]

Rebonjour

Je ne vais pas quoter ton message souviron mais, je vais quand même y répondre.

Je suis d'accord avec toi sur le fait que le rapprochement entre le besoin et le résultat énoncé par cap_gregg est un poil rapide (le "on voit que"). Si je devais raffiner cet exemple cela donnerait quelque chose d'encore plus simple :

Par exemple, si dans une spécification il y a "Tous les Clients de moins de 40 ans n'ayant pas passé un minimum de commandes de xxx doivent être identifiés afin d'être relancés"

1. Lister les clients qui ont
   
   • Moins de 40 ans
   • n'ont pas passé plus de X commandes
2. Envoyer une notification pour chacun des clients

Bon là le problème c'est qu'on ne dit pas de quelle manière le client est notifié (courrier/mail/sms?) mais, le but du débat n'est pas d'apprendre à écrire des spécifications.

Pour chaque plateforme technique (langage, framework, etc.) il n'y a pas 36 manières de développer la solution à ce problème.


Dans mon expérience professionnelle, il y a une logique entre les spécifications fonctionnelles et le code à écrire. Je vais donc décrire en quoi cela consistait.

Mon travail sur des projets au forfait afin de réaliser des applications de gestion se résumait à prendre les spécifications, le guide d'architecture et le guide de développement en entrée pour produire le code source en sortie. La grosse majorité du code produit est donc juste déduit de ces documents. C'est ce que j'appelle le pissage de code. A cet époque cela m'irritait un poil. C'est du travail à la chaine qui peut être automatiser. Je suis qu'un technicien donc je peux, à la limite, accepter ma situation. Cependant, beaucoup de mes collègues étaient des ingénieurs qui font le même travail : pisser du code. Pourtant dans ces projets qu'est ce qu'on trouve ?
- une spécification fonctionnelle
- une spécification technique
- un guide de développement
- des développeurs qui suivent bêtement ces documents pour produire le code.

Comment pourrions nous améliorer ça ?
- une spécification fonctionnelle
- une spécification technique
- un générateur de code
- des développeurs pour réaliser ce qui ne peut pas être (ou ce qui coûte trop cher à) générer.

C'est du MDA basique. Là où je te rejoins, souviron, c'est sur tes propos sur UML. Le gros soucis de ce langage est qu'il permet de tout spécifier quelque soit le domaine d'application (par contre ça reste un langage sympathique pour faire de la documentation). Il y a une alternative à UML : les Domain Specific Language (DSL). Ces langages sont spécifiques à un métier. La principale difficulté étant d'en choisir un... voir d'en créer un.
UML est un langage très complexe comportant beaucoup de concepts. Et, un de ses inconvénients (ou avantage, ça dépend du point de vue) : UML n'impose pas de méthode. De mon point de vue, l'avenir se situe dans les DSL accompagnés d'un outillage dédié et d'une méthode (l'outillage devant guider l'utilisateur selon cette méthode). Donc, au lieu de se focaliser sur l'aspect technique, on se focalise sur l'aspect fonctionnel. Évidemment, dans ce domaine, il reste encore beaucoup de travail. La marge de progression est vraiment énorme même si le chemin accompli depuis les débuts de l'informatique l'est tout autant.

(Aparté, je ne crois pas en l'avenir des Profils UML qui ne font qu'enrichir un langage déjà trop riche. Surtout qu'on a déjà les outils permettant de réaliser des DSL sans passer par des profils UML).

Yann

[el_slapper]

+1 avec souviron;

J'ajouterais qu'une autre erreur du raisonnement de base est qu'il ne parle que d'une extraction de données. Ca n'est pas tout, loin s'en faut, ce qu'on fait dans les programmes. Ensuite, on les manipule, et ça peu être conceptuellement complexe.

Exemple vécu

On a des evenements de type T1 et T2. Certains sont reliés par le "fichier des regroupements T1"
On regroupera les evenements en raccord avec les numéros de regroupement T1, en fonction de la priorité de ceux-ci

Doit en fait se comprendre :

(0)on relie un evenement à un regroupement par son numéro de client. La difficulté est qu'il peut y avoir plusieurs clients par regroupement, et plusieurs regroupements par client, il ne faut en garder qu'un, au plus.
(1)On doit attribuer des numéros de regroupements à tous les evenements T1, ainsi qu'aux evenements T2 reliés à ceux-ci
(2)Prioritairement, on doit choisir le numéro de regroupement qui permet de regrouper au moins un T1 et un T2. A défaut, celui qui permet de regrouper plusieurs T2 entre eux. Puis, enfin, les T2 seuls.
(3)la priorité du numéro de regroupement n'intervient que en cas d'ambiguité sur le point (2).
(4)On élimine les evenements T1 non regroupés. On va chercher une autre faleur en base pour les evenements T2 non regroupés

L'algorithme complet ne tient pas sur une page(parceque j'ai simplifié). Pourtant, ce qu'il fallait faire était parfaitement clair dans l'esprit de la spécificatrice, d'après ses deux lignes. Le code Cobol fait 1100 lignes(pour l'algo principal, il y a aussi deux autres petits programmes). Je me suis mis à Ocaml en partie pour voir en quoi je peux le faire tenir dans un langage fonctionnel(mais je n'ai pas encore le niveau).

On a là un exemple de spécification faussement simple. L'opération à faire est compliquée, décomposée en plusieurs parties. Pourtant, l'idée de base est simple : "regrouper en fonction des numéros de regroupement.". Mais elle cache un grand nombre de subtilités, de priorités, de choix, de sous-algorithmes(et j'en ai volontairement passé quelques-uns).

C'est pour ça que je prétends que l'art de la spécification est hautement délicat. Ce genre de cas est fréquent.

SQL ou LINQ existent justement parceque l'extraction de données est un domaine plus facile à abstraire(je n'ai pas dit facile dans l'absolu). D'ailleurs, si l'utilisateur n'a besoin que d'extraction de données, on lui installe Business Objects, et il se démerde(ou il appelle l'informaticien pour lui cracher ses requêtes). Mais, quand il s'agit de transformer lesdites données, on arrive à des choses beaucoup plus délicates. Et le rêve d'une langage descriptif "simple" me parait, euh, utopique.

[souviron34]

je répondrais plus précisément plus tard, mais sur 2 points je vais le faire de suite..

Dans mon expérience professionnelle, il y a une logique entre les spécifications fonctionnelles et le code à écrire. Je vais donc décrire en quoi cela consistait.

Eh bien dans la mienne non..

"Faire un examen IRM en un temps raisonnable et à un coût concurrentiel".

Suivant la technique employée, il faut des FFT 2F ou 3D, une électronique adaptée, et un logiciel suivant les 2.

Au choix, on peut à un moment donné faire intervenir un "array-processor" spéraé pour le calcul de la FFT 3D en //, utiliser un bus et une machine spéciale, ou bien un ordi "grand-public"..

Même une fois la spec détaillée écrite, l'implantation algorithmique dépend fortement du jeu d'instructions de l'AP, si il y en a un, de l'architecture du bus, des points sur lesquels on décide (ou non) de lâcher du lest..



Autre exemple :

"calculer une enveloppe convexe d'un nuage de points".

Plusieurs algorithmes existent, les uns, éventuellement plus rapides mais nécessitant plus de méoire que d'autres, les uns utilisant des listes chaînées les autres des tableaux, etc etc..

Je ne vois franchement pas comment de la spec on pourrait déduire l'algo à utiliser.



Et c'est bien là le problème : vous prenez des exemples "qui justent remplissent ce qu'il faut". Dès qu'on sort du champ simpliste, ça foire, et il faut une intervention humaine...

La plupart de l'informatique industrielle est très nettement plus compliquée que ce qui est sous-tendu par vos exemples... Et nécessite des interventions humaines...

Là où je te rejoins, souviron, c'est sur tes propos sur UML. Le gros soucis de ce langage est qu'il permet de tout spécifier quelque soit le domaine d'application (par contre ça reste un langage sympathique pour faire de la documentation). Il y a une alternative à UML...

Oui, le TEXTE et l'INTELLIGENCE HUMAINE...

[MiaowZedong]

Entièrement d'accord, mais justement c'est là où l'argument de base pêche :



D'une part j'aime beaucoup () le "on voit que" ..

D'autre part, et c'est là que le bât blesse, quand je lis sa phrase de spec, je ne voit pas en quoi on peut en déduire "logiquement" des termes comme "jointure" ou "aggrégation"... Sans parler de "filtre"..

Ces termes sont orientés, techniques, et n'ont strictement rien à voir avec la spec, mais tout avec le domaine de prédilection de l'intervenant, la notion de SGBD telle qu'elle est à l'heure actuelle, les concepts qui y sont attachés par des langages comme SQL..

Il n'y a donc strictement pas de logique entre la spec et la description des actions qui en est tirée..

Euh, Souvi.....

Le SGBDR sont un example de l'adage "une bonne théorie produit un bon code". Il s'appuient justement sur un formalisme logique qui permet de retranscrire comme le fait cap_gregg une phrase du language naturel dans son language formel, et ensuite de passer presque sans efforts vers le SQL. Dans le cas présent, la "bonne théorie" est donc la logique formelle, et les SGBDR marchent bien, vu les quantités de données qu'ils arrivent à gérer.

Le principe derrière le SQL, c'est de permettre à l'informaticien de pouvoir toujours retranscrire une spec exprimée clairement et sans ambiguités.

[deadalnix]

C'est la ou l'on rappelle que le SQL, c'est bien, mais le NoSQL est la lui aussi parce que justement ça a ses limites.

En plus de cela, il faut toujours coder les SGBD.

Alors oui, c'est clair que formaliser certains partie de l'informatique simplifie ces domaines, mais cela ne rend en rien la programmation plus simple. Ça en diminue simplement l'importance dans certains domaines.

Qui plus est, en général, on profite de cette simplification pour demander au programme de faire plus. De la même façon que la puissance des machines est transformée en fonctions supplémentaires plutôt qu'en programmes plus rapides, le gain est transformé en dev sur d'autres problèmes plutôt qu'en simplification du dev.

[souviron34]

Euh, Souvi.....

Le SGBDR sont un example de l'adage "une bonne théorie produit un bon code". Il s'appuient justement sur un formalisme logique qui permet de retranscrire comme le fait cap_gregg une phrase du language naturel dans son language formel, et ensuite de passer presque sans efforts vers le SQL. Dans le cas présent, la "bonne théorie" est donc la logique formelle, et les SGBDR marchent bien, vu les quantités de données qu'ils arrivent à gérer.

Le principe derrière le SQL, c'est de permettre à l'informaticien de pouvoir toujours retranscrire une spec exprimée clairement et sans ambiguités.

je ne dis pas le contraire, je dis que c'est de la logique de spécialiste, pas de la logique de généraliste, qui ne sait en rien ce qu'est une jointure ou une aggrégation..

Et que donc, partir de la phrase telle qu'elle est, pour moi, se scinde en :

• ouvir une (des ??) base(s) de données (laquelle ?? Avec quel moteur ?? Où ??)
• aller chercher dans la(les ??) base(s) la liste des clients de moins de 40 ans
• aller chercher dans la(les ??) base(s) la liste des commandes de xx
• établir la correspondance pour trouver ceux des cleints de moins de 40 ans qui ont passé la commande de xx
• en déduire la liste de ceux qui n'ont PAS passé la commande
• pour chaque élément de cette liste
  
  • récupérer dans la(les ??) bases(s) le moyen de contact (tel, mail, fax, lettre..)
  • vérifier dans quel pays il est
  • aller chercher dans la (les ??) base(s) le texte dans la langue correspondante au pays
  • envoyer ce message à ce client (par quel mécanisme ?? direct ? fichier déposé dans un répertoire scanné centralement et régulièrement ? Que faire si c'est occupé ? Si la file de messages est pleine ?? Si on n'a pas accès à une ligne internationale ?? Si on a un accès restreint ou pas prioritaire à une imprimante ?? à un serveur ?? à un répertoire ??)

Je ne vois toujours pas comment à partir de la spec on déduit le code..

Si ma base est un flat-file perso (format interne à la boîte), ma spec marche aussi... Ou si je me sers d'Oracle, ou de Access, ou de n'importe quoi elle marche toujours.. Et pourtant le code devra être différent...

[MiaowZedong]

Je ne vois toujours pas comment à partir de la spec on déduit le code..

Si ma base est un flat-file perso (format interne à la boîte), ma spec marche aussi... Ou si je me sers d'Oracle, ou de Access, ou de n'importe quoi elle marche toujours.. Et pourtant le code devra être différent...

À partir de la spec, on en déduit le code SQL pour un SGBDR. Si tu veux faire autre chose, tu te débrouilles, à tes risques et périls.

Oui, oui, je sais, le SQL a des dialectes différents, certains sont même assez moisis si tu veux mon opinion, mais une bonne implémentation de SGBDR reconnaitra toujours un certain nombre de choses, il n'y a qu'a remplacer quelques symboles formels (mots-clés SQL, en clair) par leurs équivalents. Je n'ai pas non plus dit que toutes les DB sur le marché sont bonnes, hein....

[souviron34]

À partir de la spec, on en déduit le code SQL pour un SGBDR. Si tu veux faire autre chose, tu te débrouilles, à tes risques et périls.

Donc il faut toujours des mecs qui savent coder

Parce que imposer sur un projet qu'on ne connait pas d'avoir un SGBDR avec SQL, alors que potentiellement la base du projet pourrait n'avoir que 100 lignes, c'est peut-être démesuré, non ???

Or c'est bien ce que ferait cet "automatisme"...

[MiaowZedong]

Oui mais je n'ai jamais dit le contraire

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.

Le journaliste à l'origine, désormais lointaine, de ce thread aurait du se documenter avant de prendre son clavier: ce qu'il souhaite ce n'est ni plus ni moins que des languages de cinquième génération, hors les 5GL ont déjà étées tentées maintes fois depuis la fin des années 70, sans aucun succès car les languages naturels sont trop ambigus pour décrire des problèmes complexes à résoudre par une méthodologie détérministe. C'est pour cela que les languages formels ont été inventés avant l'avènement de l'informatique.

Peut-être qu'un 5GL à base d'Esperanto serait envisageable, mais cela impliquerait d'apprendre l'Esperanto....je n'en vois pas l'intérêt.

[yann2]

Rebonjour

Donc il faut toujours des mecs qui savent coder

Parce que imposer sur un projet qu'on ne connait pas d'avoir un SGBDR avec SQL, alors que potentiellement la base du projet pourrait n'avoir que 100 lignes, c'est peut-être démesuré, non ???

Or c'est bien ce que ferait cet "automatisme"...

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

Oui, de toutes façons on aura toujours besoin de personnes qui savent coder. Dans une usine où la chaine de montage est automatisé par des robots il y a quand même des gens connaissant toute la chaine et des gens qui savent ce que font tels ou tels robots. Et, le sur mesure requiert forcément des spécialistes. On est d'accord.

Ce ne sont pas mes exemples qui sont simplistes mais les votre qui sont trop compliqués :p (je n'ai toujours pas compris l'algo de el_slapper donc je vais avoir du mal à l'apprendre à mon ordi) Plus sérieusement, je ne connais pas le domaine dont tu parles souviron mais, tu m'as l'air mieux placé pour nous sortir le DSL . Le soucis de l'approche par DSL est qu'il faut vraiment bien connaître le domaine et tu conviendras que je ne connais pas du tout le tiens souviron.

Bref, de mon expérience (parce qu'on est bien là pour les confronter), il y a beaucoup de choses qui peuvent être automatiser. De la votre, c'est moins évident.

[el_slapper]

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

non. Si j'ai un langage miracle, ça vaut le coup de créer un compilateur sur la machine dont j'ai besoin.

(.../...)Ce ne sont pas mes exemples qui sont simplistes mais les votre qui sont trop compliqués :p (je n'ai toujours pas compris l'algo de el_slapper donc je vais avoir du mal à l'apprendre à mon ordi) Plus sérieusement, je ne connais pas le domaine dont tu parles souviron mais, tu m'as l'air mieux placé pour nous sortir le DSL . Le soucis de l'approche par DSL est qu'il faut vraiment bien connaître le domaine et tu conviendras que je ne connais pas du tout le tiens souviron.

Et encore, je l'ai gravement simplifié ici. Et il s'agit vraiment d'un truc que j'ai codé l'été dernier, après 3 semaines de reflexion avec la MOA pour arriver à mettre au point l'algorithme complet. Alors que la première spec se limitait vraiment à mes deux premières phrases.

Conclusion : les specs simples, c'est suspect.

Bref, de mon expérience (parce qu'on est bien là pour les confronter), il y a beaucoup de choses qui peuvent être automatiser. De la votre, c'est moins évident.

La plupart des trucs automatisables le sont déjà : chez les gens sérieux, on fait les builds en un clic(c'est notre cas), les tests en un autre(ce n'est pas notre cas et je souffre mille morts à cause de celà), on a parlé de SQL ou de LINQ qui sont très efficaces dans leur domaine spécifique. Certains gisements de productivité restent certainement à explorer, mais le point sur lequel j'insiste encore et encore - et souviron aussi, est le suivant :

Les programmes qu'on nous demande de coder doivent représenter des réalités complexes et/ou compliquées, avec beaucoup de choses spécifiques. Les coder ne sera donc jamais simple. D'ailleurs, SQL est bien plus efficace qu'un code impératif(dans son domaine), ça n'empêche pas des requêtes monstrueuses d'exister.....Même avec un niveau d'abstraction "exemplaire", on peut arriver à des monuments de complexité. Parceque le besoin lui-même est, en général, bien plus subtil qu'il n'en a l'air.

Coder, au final, ça n'est jamais que découper une activité en ses composantes les plus élémentaires de manière exhaustive. Les progrès des langages de programmation ont permis d'élargir la taille des actions élémentaires en question - mais pas de se passer de l'exhaustivité des actions à faire.

Par exemple, le Garbage collector(malgré tous ses défauts, je l'adore) permet de se passer d'une gestion de la mémoire. Pour autant, toutes les actions de l'algorithme doivent être décrites quand même. La modularité du code permet de centraliser les actions, et de ne décrire qu'une seule fois une action réalisée plusieurs fois - mais pas de se passer de la décrire. Les méthodes abstraites de description des actions - telles le SQL ou LINQ - permettent de simplifier(relativement) l'écriture des actions - mais pas de se passer de les décrire.

Qu'on écrive

Code :

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

SELECT LABEL_BANQUE FROM TREF_BANQUE WHERE CODE_BANQUE = 30001 INTO :LIBELLE-AFFICHE

ou

Code :

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

1
2
3
4
5
6
MOVE SPACES TO LIBELLE-AFFICHE
PERFORM VARYING I FROM 1 BY 1 UNTIL I > NBR-BANQUES OR LIBELLE-AFFICHE NOT EQUAL SPACES
   IF CODE-BANQUE (I) = 30001
      MOVE LABEL-BANQUE(I) TO LIBELLE-AFFICHE
   END-IF
END-PERFORM

, dans les deux cas, on a décrit l'intégralité de l'action. Plus simplement dans le premier cas(c'est donc un progrès), mais il a bien fallu décrire tout ce qu'il fallait faire. Et ce "tout" est, en général, plus complexe/compliqué que la lecture du libellé "banque de France" dans le référentiel qui va bien.

[Bluedeep]

Un langage fonctionnel, c'est Caml, LISP ou Haskell. SQL c'est tout ce que tu veux sauf du fonctionnel.

Peut être, mais comme c'est tout sauf de l'impératif, si ce n'est ni de la programmation logique ni du fonctionnel, il manque une catégorie, alors.

[Luckyluke34]

Pour recentrer un peu le débat sur le sujet d'origine, il y a actuellement des efforts intéressants pour rendre la programmation plus accessible et intuitive aux novices, et à mon avis cela peut avoir des conséquences très bénéfiques pour les développeurs experts aussi.

Bret Victor a récemment sorti un article qui contient une mine d'idées assez considérable sur la façon dont on pourrait adapter les langages et les environnements de développement à la manière dont notre cerveau raisonne. Cela peut servir aux débutants mais aussi aux professionnels avec à la clé un ticket d'entrée moins élevé pour passer sur de nouvelles technos/langages, et un gain en confort de dev et de productivité.

The environment should allow the learner to:

• read the vocabulary -- what do these words mean?
• follow the flow -- what happens when?
• see the state -- what is the computer thinking?
• create by reacting -- start somewhere, then sculpt
• create by abstracting -- start concrete, then generalize

The language should provide:

• identity and metaphor -- how can I relate the computer's world to my own?
• decomposition -- how do I break down my thoughts into mind-sized pieces?
• recomposition -- how do I glue pieces together?
• readability -- what do these words mean ?

A noter aussi l'initiative de Chris Granger avec son IDE LightTable qui exploite entre autres l'idée de rapprocher l'écriture du code de son exécution. L'exécution immédiate du code qu'on vient d'écrire sur un exemple fournit un feedback rapide qui simplifie la programmation et la rend plus intuitive.

[MiaowZedong]

Bret Victor a récemment sorti un article qui contient une mine d'idées assez considérable sur la façon dont on pourrait adapter les langages et les environnements de développement à la manière dont notre cerveau raisonne.

Je pense qu'il faut toujours adapter l'outil à la tâche, non la tâche à l'outil. Hors, c'est ce que propose de faire Victor:

How do we get people to understand programming?

We change programming. We turn it into something that's understandable by people.

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.

L'ordinateur existe pour resoudre des problèmes exprimables en termes de machines de Turing. Ce que sugère Victor, c'est que comme il est difficile pour les humains de raisonner en ces termes, il ne faut les leur apprendre, il faut cacher la "vilaine" architecture machine et espérer qu'un héros anonyme fasse en sorte que leur code abstrait fonctionne....c'est un peu la politique de l'autruche que d'espérer qu'autrui resolve les problèmes trop durs pour soi.

L'informatique, lorsque l'on descend dans les 0 et les 1, ce n'est qu'un sous-ensemble de propriétés physiques de notre univers. Ce sous-ensemble peut servir à modéliser énormément de problèmes et les résoudre, et l'outil que l'on a pour ça, c'est le cerveau humain. 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.

[I_believe_in_code]

@MiaowZeDong : tu as tout très bien résumé !

Peut être, mais comme c'est tout sauf de l'impératif, si ce n'est ni de la programmation logique ni du fonctionnel, il manque une catégorie, alors.

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.

[Logan Mauzaize]

Bon puisque j'ai mis mon "-1", je m'explique :

On pourrait toujours simplifier tant que possible la "programmation", il faudrait toujours décrire des "instructions" "non-ambigue" dans un "langage" "non-ambigue", programmer quoi ! Que ce soit du SQL, du Java, du COBOL, ABAP, "un" DSL, etc.

Tout ce qui est MDA et UML n'y change pas grand chose non plus. Ils ont juste leur propre langage. Par ailleurs la meilleure solution de génération ne produira que des coquilles vides à remplir avec le langage cible. C'est bien pour ça qu'il existe les notions PIM, PSM et DSL.

Et puis bon, coder un DSL, puis coder avec. Bonjour le progrès !

La plupart des applications de gestion fonctionne sur le principe de "Integration - Consultation - Sortie". Cependant chaque étape peut corresponde à des milliers d'implémentations différentes. Si je prend l'exemple, de la requête sur les clients. Rien ne me dit où sont les clients, ni qu'elles sont les contraintes d'accès. Si ca se trouve, il faudra que je génère une image de la base cliente une fois par semaine, que je devrais consolider avec la base prospection que je dois répliquer une fois par mois ...
Le choix de répliquer, consolider, etc. est purement technique. Et l'implémentation de ces fonctions encore plus.
Seul un méga conglomérat des spécifications, du domaine, des contraintes techniques, etc. me fournira une solution parmi plusieurs qui évoluera en fonction de l'expérience que ce soit en maquettage (ex: test de monté en charge), en acceptance, ou en production (ex: serveur qui n'a plus d'espace disque).
Je parle même pas des contraintes économiques (ex: prix des licences), idéologiques (la personne ne veut pas travailler avec Oracle), etc.


SQL est exactement un mauvais exemple. Autant il se veut standardiser autant il ne l'est pas du tout ... Regarde ce qu'Oracle propose :

• En terme d'objet: Role, Vue matérialisée, cluster, type, procédure, etc.
• En terme de fonction: Hint, DB Link, Analytic function, Collection, Objet, XML, etc.

Et je parle même pas de l'administration et/ou gestion des données (export, import, backup).
Choisir un produit requiert énormément de critères que peu (aucun ?) programme ne permettra de juger. Déjà que la plupart des gens ne savent pas le faire ...

Qu'on écrive

Code SQL :

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

SELECT LABEL_BANQUE FROM TREF_BANQUE WHERE CODE_BANQUE = 30001 INTO :LIBELLE-AFFICHE

ou

Code COBOL :

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

1
2
3
4
5
6
MOVE SPACES TO LIBELLE-AFFICHE
PERFORM VARYING I FROM 1 BY 1 UNTIL I > NBR-BANQUES OR LIBELLE-AFFICHE NOT EQUAL SPACES
   IF CODE-BANQUE (I) = 30001
      MOVE LABEL-BANQUE(I) TO LIBELLE-AFFICHE
   END-IF
END-PERFORM

Ou bien tu aurais pu utiliser un fichier séquentiel indexé ;-)

Peut être, mais comme c'est tout sauf de l'impératif, si ce n'est ni de la programmation logique ni du fonctionnel, il manque une catégorie, alors.

Un langage multi-paradigme. A la rigueur on pourrait parler de langage "relationnel" ou "ensembliste" ? Sinon je trouve qu'il a un côté "logique" comme Prolog. Tu lui donnes une "requête" sur un ensemble de "fait", et il te donne un ensemble de "vérité".

A noter aussi l'initiative de Chris Granger avec son IDE LightTable qui exploite entre autres l'idée de rapprocher l'écriture du code de son exécution. L'exécution immédiate du code qu'on vient d'écrire sur un exemple fournit un feedback rapide qui simplifie la programmation et la rend plus intuitive.

Il y a eu une news du DVP à ce sujet. Cependant je vois rien de révolutionnaire, la plupart des IDE (au moins Eclipse) propose ces fonctions. Il n'y a guère que les "Code Bubbles" qui ne sont pas aussi finement géré mais il m'arrive régulièrement de splitter mon éditeur et utiliser des "collapsed codes" pour avoir une vue focaliser sur un bloc de code en particulier.