Discussion :

[gangsoleil]

Sauf que la loi de Moore, c'est fini.

En tant que tel, le nombre de transistors ne m'interesse pas. Par contre, lorsqu'on passe d'un serveur dual-core a un serveur quadri processeur parce que ceux-ci sont aujourd'hui a des prix abordables, ce qui n'etait pas le cas il y a 5 ou 10 ans, on gagne en performance sur toutes les applis sachant tirer partie de plusieurs processeurs.
De meme, des serveurs avec 64 ou 128 Go de RAM ne sont plus du tout aussi cher qu'avant, ce qui te permet d'utiliser des solutions techniques que tu ne pouvais pas mettre en place avant (mapper une grosse base de donnees en memoire par exemple, sans ecrouler le serveur).

Tu ajoutes des reseaux Gigabits, des liens LAN en 10 Gb voir plus (infiniband par exemple), et des cartes reseaux sur lesquelles il est possible de deporter une partie de certains gros calculs, et tu as presque fait le tour des optimisations dont tu peux profiter aujourd'hui, sans tenir compte (du moins consciemment) de la loi de Moore.

[chaplin]

De manière générale, les logiques de traitements se prêtent parfaitement à une représentation graphique. Certains langages, comme les ETL, commencent à proposer cette programmation logique graphique. Les macro opérations (lectures/écritures, jointure, tri, filtre, ...) sont représentées par des symboles, qu'on enchaîne en les reliant par des traits (un peu comme du shell graphique, les traits étant les 'pipes').

Avec ces langages logiques et graphiques à base de symboles, la logique des traitements (opérations, enchaînements) n'est plus stockée dans des 'programmes' : elle est stockée logiquement dans des bases de données référentielles. Ce stockage logique apporte de nombreux avantages : par exemple il devient simple de faire de l'analyse d'impact (si je change ceci, quels impacts ? quelles sont toutes les manières d'alimenter cette donnée ?).

Donc oui, les langages actuels n'apportent pas de simplicité aux développeurs. Plus ils sont complexes, plus ils soulignent la vision limitée de leurs concepteurs : ces personnes ont déployé des prouesses pour fabriquer et poser une superbe échelle, mais elles se sont juste trompé de mur !

Assez d'accord avec ce qui écrit, mais l'un n'empêche pas l'autre et les opposer n'est pas logique, ils sont complémentaires.

Les L4G voulaient répondre à ce genre de problème mais présentent des inconvénients également, comme la dépendance à un éditeur.

[cap_gregg]

Oui il faudra toujours des langages physiques pour écrire les langages logiques.

Mais la très grande majorité des informaticiens doit répondre à des besoins ‘fonctionnels’, dans des délais courts, et pour cela des langages logiques comme le SQL sont beaucoup plus adaptés, plus rapides, plus sûrs.

Ces outils logiques ne sont pas des L4G. Le SQL est un langage interprété à l’aide d’un système expert, et c’est pour cela qu’il est aussi performant.

Il est faux de penser que les langages logiques seront plus gourmand ou moins performant que les langages physiques. Dès qu’un système devient complexe, comme l’accès aux données, quiconque entreprendrait de le développer physiquement produirait une catastrophe en longueur de code, en performances, et en qualité.

Aujourd’hui, on ne dispose pas d’outils logiques, il faut donc gérer des tas d’aspects physiques à la main. Par exemple pour faire une jointure (ceci est la logique, très simple) entre un fichier texte et une base de données (ce sont des caractéristiques d’environnement), il faut écrire en général un code conséquent. C’est anormal, il ne devrait y avoir qu’une ligne à écrire (la jointure), et un interpréteur écrit par des experts devrait savoir comment s’y prendre pour exécuter cette logique de manière idéale avec la plupart des types d’environnements.

En l’absences de ces langages logiques, les informaticiens doivent résoudre des tas de problèmes physiques qui les accaparent. De plus, ces problèmes sont parfois complexes, et ils les résolvent en s’y prenant très mal, souvent en les sur-complexifant.

C’est pour cela que la production informatique est si faible (par rapport aux budgets, on peut même parler d’indigence), si lente (les délais s’expriment souvent en ‘mois’, l’informatique est ‘le’ goulot d’étranglement) et surtout de si mauvaise qualité. Si on produisait des véhicules, ou des médicaments, avec autant de défauts que les programmes, tout le monde serait scandalisé !

C’est pourquoi des langages logiques doivent apparaître. L’interprétation de ces langages en actions physiques adaptées à l’environnement, doit être confiée à des experts qui sauront optimiser mieux que quiconque ce qu’il faut faire pour exécuter cette logique.

On peut d’ailleurs s’étonner, au bout de 60 ans d’informatique, que ces outils logiques ne soient pas déjà largement apparus ! En effet il est quasiment contradictoire de voir des programmeurs répéter autant de tâches de bas niveau, alors que l’informatique sert justement à automatiser les tâches fastidieuses et répétitives.

Il y a semble-t-il une grande complaisance des programmeurs à l’égard de cette situation. Le ‘codage’ leur procure une satisfaction intellectuelle immense, et de surcroît ‘tout faire à la main’ maintient leur activité. Alors nombreux sont ceux dont l’état d’esprit est « pourvu que ça dure !».

Mais il y a aussi de plus en plus de programmeurs qui aspirent à passer ce cap, qui aspirent à jouer un autre rôle que celui de technicien, qui ne se complaisent plus de délais longs et d’une qualité exécrable, qui veulent êtres acteurs et non plus exécutants.

Ces nouveaux programmeurs ont besoin pour développer d’outils avec la même philosophie que BO. Avec BO, pour développer un rapport, il n’y a strictement rien à coder, il faut juste exprimer la logique (les requêtes se génèrent toutes seules) et le design du rapport. La logique et le design sont deux aspects purement fonctionnels : les programmeurs aspirent à être des interlocuteurs fonctionnels.

A ces programmeurs qui évoluent, il va falloir une nouvelle génération d’outils. Ces outils ne seront pas physiques, mais logiques.

[thierry.chich]

On ne pourrait qu'etre d'accord au moins partiellement avec ce que vous dites si vous ne l'enonciez pas comme une chose neuve. Or, ce que vous appelez langage logique et langage physique n'est pas franchement une nouveauté. On appelle ça des niveaux d'abstraction, et votre indignation me semble méconnaître le nombre de niveaux qui ont été franchi dans l'histoire de l'informatique. Entre l'assembleur et les frameworks web qui fonctionnent sur des langages interpretés, il y a quand même plusieurs niveaux d'abstraction. Et ce ne sont pas les développeurs qui sont d'affreux passéistes, ce sont eux qui ont bâti ces outils. Pour donner un exemple, en 1997, il fallait plusieurs jours pour faire une page web qui remplissait un simple formulaire. Aujourd'hui, un frameworks comme django permet de construire une appli simple complète en quelques heures, avec une bd qui tourne et un modèle MVC cohérent. Ce qui n'empêche pas que dès que les contraintes s'accroissent, le temps de développement s'accroît aussi, et l'expertise du développeur redevient nécessaire.
J'ajoute de plus que le fait d'avoir des nouveaux outils ne supprime jamais totalement le besoin en développeurs de plus bas niveau. Quelque soit la finition du frameworks, il faut parfois passer plus directement aux ressources.

[cap_gregg]

On a aujourd'hui beaucoup d'outils remarquables, c'est vrai. Il y a beaucoup d'outils orientés vers des paradigmes d'un haut niveau d'abstraction.

La seule chose qui manque maintenant, en quelques sortes, ce sont des outils orientés développeurs.

On pourra dire qu'on en aura :

• lorsque les logiques de traitement seront stockées de manière logiques dans des référentiels ouverts
• lorsque les caractéristiques physiques (types de données, type d'ihm) seront déclarées indépendamment de la logique, dans des fichiers d'environnement
• lorsque les logiques de traitements seront interprétées par des systèmes experts sachant quelles sont les meilleures actions à mener pour mener à bien la logique en fonction de l'environnement

Aujourd'hui, pour reprendre l'exemple des ihm, la logique est décrite 'dans' Php, ou 'dans' VB. Autrement dit, c'est le physique qui contient la logique.

Quand les systèmes logiques existeront, ce sera la logique, au travers de l'interprète, qui pilotera le physique, le physique ne sera qu'un moyen. Par exemple, pour une Ihm, la logique demandera simplement à Php, ou à VB, d'afficher une liste, de griser un champ, etc.

Pour bien marquer les esprits en montrant ce que signifie cette nouvelle manière approche, nous avons réalisé des écrans où nous changeons complètement d'Ihm (VB <--> html) en pleine saisie d'un écran, l'utilisateur ayant juste un bouton à cliquer (quand il le veut).

Ceci n'est plus du domaine de l'abstraction au sens traditionnel. Il s'agit d'une isolation 'totale' entre la logique et le physique, et là enfin, on peut affirmer qu'on est 'complètement' libérés des aspects physiques, qu'on ne travaille qu'en pure logique, et que le physique n'est plus qu'une contingence.

Et pour revenir au sujet du départ : le code logique est ultra-simple, c'est

[cap_gregg]

c'est ... simple, et court, comme la pensée

[Joauc]

Pour résumé ce que tout le monde pense (enfin sauf notre ami journaliste ) ,
dans la vie on a rien sans rien, pour réaliser quelque chose il faut y consacrer un minimum d'effort et plus la tache à réaliser est complexe plus l'effort est important.
S'il y tenait vraiment a son appli iPhone et s'il y avait consacrer un peu plus de temps il y serait probablement arrivé.
Rome ne s'est pas construite en un jour, ba les appli iPhone non plus ...

[cap_gregg]

Il existe déjà un langage purement logique, c’est le SQL. Pourquoi le SQL a-t-il pu voir le jour ?

Parce que, quand on ne s'intéresse qu'au niveau logique, on s'aperçoit que le nombre de types d'opérations possibles est limité. Par exemple, pour les requêtes, il y a les filtres, les jointures, les tris, les fonctions ...

Bien sûr, après ça se ramifie : par exemple il y a des 'centaines' de fonctions possibles, mais les systèmes experts qui traduisent le Sql en actions physiques se fichent de savoir si la fonction est Sinus() ou Valeur_Absolue(). Il raisonne à un niveau supérieur : Si (il y a des fonctions) Alors ... C'est cette possibilité qui fait aussi que le SQL existe.

Maintenant, essayons d'extrapoler cette expérience aux traitements batchs (par exemple)

Si on se pose la question "Que peut-on faire, finalement, comme différents types d'opérations logiques dans un batch ?", on arrive très difficilement à une trentaine de types d'opérations (et encore faut-il être vicieux) : par exemple jointure, filtre, tri, etc.

L'exemple de la jointure est intéressant. Si on veut joindre entre Excel et un fichier plat, ou même entre 2 SGBD différents, il faut écrire un code assez long. Mais ce qu'on veut faire sur le plan logique est très simple '"Joindre deux données".

C'est à dire que toutes les personnes qui produisent des kilomètres de code de batch chaque jour, ne font finalement que 30 choses logiques différentes, alors que ces choses sont très simples à exprimer puisqu'elles correspondent à notre pensée.

Le problème est le physique

Ce code long est souvent médiocre (la production informatique accepte un taux de défauts qu’aucune autre industrie ne tolèrerait). Et si la jointure met en jeu des volumes gigantesques, non seulement le code sera long, mais il sera catastrophique à l’exécution si on le confie à un débutant, alors qu’un expert s’en sortira.

Donc on voit bien que ce sont toujours les aspects physiques qui complexifient les problèmes. A tel point qu’il vaut mieux parfois laisser la main à des experts.

Par chance, la logique est très limitée

Comme le nombre de types d’opérations logiques à gérer est très limité (une trentaine pour un batch), même s’il est complexe pour des systèmes experts d’en traiter certaines, la tâche devient limitée et possible (d’autant que les systèmes experts raisonnent globalement, par exemple ils savent exprimer à propos d’une jointure « Si les deux sources sont des SGBD alors », ils ne traitent pas les choses au cas par cas « Si une source est Oracle et l’autre Sql-Server alors »).

Le développement de langages purement logiques est donc possible. Leur intérêt pour l’industrie informatique est fabuleux. Donc on ne voit pas ce qui pourrait maintenant empêcher leur développement.

[zeyr2mejetrem]

Il existe déjà un langage purement logique, c’est le SQL. Pourquoi le SQL a-t-il pu voir le jour ?
[...] empêcher leur développement.

Très belle réponse ...
Mais qu'a t elle à voir avec le topic ??

[Bluedeep]

Très belle réponse ...
Mais qu'a t elle à voir avec le topic ??

Rien à voir, comme la majorité de ses interventions(du moins celles que j'ai lues).
De plus "langage logique", on aimerait bien qu'il définisse ce que c'est (une définition qui nous dirait ce qu'est un langage "pas logique" )

[el_slapper]

ça fait plus de dix ans que je me farçis des batches de rapprochement de fichiers. Eh bien, je n'ai jamais fait deux fois le même. Mes besoins étaient toujours différents. Alors un langage magique qui fait tout à ma place en devinant à chaque fois les spécificités du jour, j'ai du mal à y croire.

[gangsoleil]

ça fait plus de dix ans que je me farçis des batches de rapprochement de fichiers. Eh bien, je n'ai jamais fait deux fois le même.

[Mode salaud, el_slapper a le droit de taper en premier]
Ca, c'est parce que tu es mauvais. [/salaud]

Mes besoins étaient toujours différents. Alors un langage magique qui fait tout à ma place en devinant à chaque fois les spécificités du jour, j'ai du mal à y croire.

Je ne sais pas pourquoi, mais moi non plus j'y crois pas trop...

[el_slapper]

Ca, c'est parce que tu es mauvais.
(.../...)

Maitre,

Je me prosterne devant votre Infinie Magnificience. (d'autant plus que je viens de poser une question de noob dans le forum Ocaml).

J'aurais toutefois l'outrecuidance de signaler à Votre Excellence que ma médiocrité est largement partagée. Par conséquent, un outillage ultime qui exigerait un fort niveau de compétence et d'intelligence ne serait pas utilisé : la nullité crasse de mes innombrables confrères et de moi-même l'empecherait.

[cap_gregg]

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.

Le gros souci, c'est le COMMENT (la mise en oeuvre). Il n'est pas rare que pour traduire une seule ligne de spécifications, il faille une grande quantité de code.

Ce qui est intéressant, c'est d'analyser ce fameux QUOI, par exemple dans les spécifications. Plus particulièrement, il est intéressant de repérer les types d'opérations manipulées.

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.

Ici dans les spécifications, si on arrive à décrire la ‘logique’ du traitement avec aussi peu de types d’opérations, c’est parce qu’on ne présage pas des implantations physiques, on ne sait pas si les données seront dans des SGBD ou dans des fichiers textes, on ne sait pas si le système sera un mainframe ou un serveur, etc.

Et si on essaie de recenser tous les types d’opérations pour un domaine informatique donné (les Ihm, les batch, etc), on s'aperçoit que ce sont toujours les mêmes types d'opérations qui reviennent, et qu’en réalité les types d’opérations logiques sont très peu nombreux.

L'idée de la programmation logique c’est :

- de programmer la logique simplement, en utilisant les types d’opérations
- de stocker la logique logiquement, dans des référentiels ouverts (et non pas dans des programmes).
- de définir l’environnement physique à part, par ex. dans des fichiers de configuration indiquant le type de chaque donnée, etc
- de faire interpréter la logique par un système logique basé sur un système expert
- de laisser ce système expert ouvert, afin que des experts puissent le compléter et l’améliorer

Donc à la question « Faut-il simplifier la programmation et revoir ses fondements ? », on peut répondre « Il est possible d’exprimer un traitement avec la plus grande simplicité imaginable : celle de la logique, celle des spécifications. Et il est possible de faire exécuter automatiquement cette logique de la meilleure manière imaginable, en la confiant à des systèmes experts, c’est à dire au plus au niveau possible de mise en œuvre. Cependant cela ne passe pas par une refondation de la programmation, mais par une refondation de l’informatique : en effet cette évolution va impliquer la disparition de la programmation au sens actuel, c’est dire du codage (à part quelques experts). »

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.

Il n’y a malheureusement rien de visionnaire à annoncer cette évolution de l’informatique, car elle a déjà eu lieu pour d‘autres domaines, par exemple pour la programmation des machines outils. Il n’y a plus besoin aujourd’hui de spécialistes de l’usinage pour fabriquer des formes complexes : il suffit d’indiquer la forme finale à la machine (c’est la logique), de lui préciser le matériau à usiner ainsi que les outils disponibles (c’est le physique), et c’est la machine qui détermine elle-même comment s’y prendre.

Cette évolution générale (l’automatisation du travail manuel, le remplacement du savoir faire par des systèmes experts) correspond à une avancée logique du progrès. Mais si elle est largement en marche dans d’autres domaines, elle n’a pas encore commencé en informatique. L’opportunité reste donc parfaitement ouverte pour que les programmeurs anticipent ce progrès, en particulier pour s’assurer qu’il reste un bien public, et qu’il ne devienne pas la propriété exclusive de quelques firmes.

Pourquoi ? La principale raison, c’est que ces firmes ne vont pas faire les outils dont nous, leurs utilisateurs, avons besoin. Parce que nous sommes sur le terrain, personne mieux que nous ne peut définir nos propres outils (en termes de fonctionnalités, d’architecture, de gestion des environnements, de gestion des versions, de métrologie, …). Les chercheurs et les concepteurs des firmes sont intellectuellement brillants, mais ils ont des visions orientées, et il vont une nouvelle fois nous enfermer dans des schémas de pensées limités. Il faudra ensuite des dizaines d’années pour faire évoluer ça. En tant que futurs utilisateurs, c’est à nous et à personne d’autre, de concevoir nos outils.

La seconde raison, c’est que cette révolution (la fin du codage) va être d’une ampleur générale, largement promotionnée par les entreprises qui ont tout à y gagner. Et donc il est hors de question que dans notre branche, nous laissions des firmes détourner ce progrès commun à leur seul profit. Et il ne faudra pas s’attendre à ce que les politiques nous soutiennent, car ils sont largement complices des firmes au nom de l’économie (par exemple ils ont autorisé que les firmes puisse breveter le génome humain, c’est comme si Lavoisier avait pu breveter l’oxygène !).

De manière à conserver notre liberté, ce sera donc à nous aussi de développer ces outils, au moins le cœur, le tronc commun.

A suivre …

[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. (.../...)

Foutaises. Tout le reste de ton raisonnement est erroné à partir de ça. La spécification est un art difficille, et les spécifications "simples" sont souvent fausses.

[deadalnix]

J'ai plutôt tendance à justement penser que les specs sont trop complexe par rapport à ce qu'il y a besoin pour répondre au besoin (faire simple est un art difficile).

Mais on se rejoint : des bonnes specs, c'est rare. Donc ça ne doit pas être si trivial que cela.

[yann2]

Bonjour

Foutaises. Tout le reste de ton raisonnement est erroné à partir de ça. La spécification est un art difficille, et les spécifications "simples" sont souvent fausses.

Je ne suis pas sûr que tu es tout lu. Je ne rentrerai pas dans le débat : "les spécifications sont-elles un art ?"

Pour le raisonnement de cap_gregg, j'ai du mal à voir ce que vous lui reprochez. Il faudrait être un peu plus constructif dans les arguments pour pour alimenter le débat. La programmation devient de plus en plus simple MAIS, d'un autre côté, nous pouvons réaliser de plus en plus de choses. C'est le seul problème que je vois dans le raisonnement de cap_gregg, il oublie de parler de l'évolution en terme de possibilités techniques (il y a 30 ans, les outils tactiles tels qu'une tablette n'étaient pas légion...).

Par contre, la programmation se simplifie et je ne vois pas de raison pour que ça s'arrête. La plupart d'entre nous ne code plus en assembleur mais, pourtant, l'assembleur est toujours bel et bien là. Seulement, beaucoup d'entre nous utilisons un langage plus simple pour exprimer une logique (le QUOI de cap_gregg).

Bref, je trouve que vous avez un peu la main lourde sur un membre qui ose apportez sa goutte d'eau au débat. D'ailleurs, son aparté sur le SQL est excellente. Tout gestionnaire de bases de données qui se respecte gère ce langage. Pourquoi ne pourrais-je pas l'utiliser sur une source excel ou même des instances java (moyennant une évolution du langage bien entendu).

cap_gregg n'a jamais parlé de langages magiques mais, de langages plus simple : plus proche de la pensée. C'est l'évolution logique depuis les débuts de l'informatique et la marge de progression me parait encore énorme.

Yann

[I_believe_in_code]

Pour le raisonnement de cap_gregg, j'ai du mal à voir ce que vous lui reprochez.

On peut lui reprocher, par exemple, de tenir des propos délirants (par exemple envisager la disparition de l'acte de coder comme il le fait dans son dernier post).

Il faudrait être un peu plus constructif dans les arguments pour pour alimenter le débat.

Chacun participe aux discussions à la mesure de ses priorités et de son temps.

Par contre, la programmation se simplifie et je ne vois pas de raison pour que ça s'arrête.

Plus un langage est spécifique, moins il peut être utilisé partout et pour tout (par définition). Il en faut donc pour tous les goûts (ou plutôt, pour tous les types de réalisations logicielles). On pourra observer une tendance à la simplification d'un côté, une tendance contraire d'un autre côté, etc. Tout mettre dans le même panier en disant "la programmation se simplifie" n'a pas trop de sens. Quant aux outils les plus polyvalents, ils resteront les plus difficiles à utiliser et, pour autant, ils seront les derniers à disparaître.

Bref, je trouve que vous avez un peu la main lourde sur un membre qui ose apportez sa goutte d'eau au débat. D'ailleurs, son aparté sur le SQL est excellente.

SQL est un exemple typique de langage qui répond à un besoin très spécifique. C'est donc un mauvais exemple pour illustrer un propos qui parle d'une "simplification de la programmation" en général.

Pourquoi ne pourrais-je pas l'utiliser sur une source excel ou même des instances java (moyennant une évolution du langage bien entendu).

Sans doute parce que Microsoft, Sun et Oracle ne sont pas au service de ceux qui voudraient que tous les langages ressemblent à SQL.

[yann2]

On peut lui reprocher, par exemple, de tenir des propos délirants (par exemple envisager la disparition de l'acte de coder comme il le fait dans son dernier post).

Je ne trouve pas ce passage aberrant. Même si je ne vois pas ça être mis en œuvre demain il me parait logique qu'on tend vers ce qu'il dit. Il y a des tas de choses que l'on fait aujourd'hui qui paraissaient aberrantes dans le passée excepté pour les plus "hérétiques" qui devaient avoir le même genre de réponses... d'ailleurs on trouve des exemples où l'exploit est bien plus important que ce dont on parle : marcher sur la lune, voler.

Chacun participe aux discussions à la mesure de ses priorités et de son temps.

Je suis d'accord que chacun puisse participer mais, argumenter sa réponse est une nécessité ! La preuve, je lis les messages de cap_gregg et je suis plutôt d'accord avec ce qu'il dit. Là, deux ou trois réponses descendent ses propos sans argument. Il n'y a donc plus de débat. Je n'ai rien contre le fait que les gens ne pensent pas la même chose, il est toujours important d'avoir d'autres personnes pour confronter les idées mais, il faut les défendre sinon elles n'ont aucune valeur.

Plus un langage est spécifique, moins il peut être utilisé partout et pour tout (par définition). Il en faut donc pour tous les goûts (ou plutôt, pour tous les types de réalisations logicielles). On pourra observer une tendance à la simplification d'un côté, une tendance contraire d'un autre côté, etc. Tout mettre dans le même panier en disant "la programmation se simplifie" n'a pas trop de sens. Quant aux outils les plus polyvalents, ils resteront les plus difficiles à utiliser et, pour autant, ils seront les derniers à disparaître.

Il est rare de voir une technologie (je reste dans le domaine de la programmation en utilisant ce terme) sortir pour nous compliquer la vie (ou alors elle est soit destinée à disparaitre soit soutenue par un grand groupe qui l'impose grâce à sa force marketing, j'en connais une ou deux qui rentrent dans le deuxième cas). Pour ma part quand je disais que l'informatique peut se compliquer c'est parce qu'elle offre de nouvelles possibilités. Si des choses que l'ont fait aujourd'hui deviennent plus compliquées à faire demain alors nous prenons certainement la mauvaise direction.

SQL est un exemple typique de langage qui répond à un besoin très spécifique. C'est donc un mauvais exemple pour illustrer un propos qui parle d'une "simplification de la programmation" en général.

C'est un besoin très spécifique qui se retrouve dans de nombreux cas. Déjà, il ne faut pas perdre de vue qu'il s'agit que d'un exemple et qu'il n'a jamais été question de remplacer "la programmation" par SQL. Quel est le problème ? J'ai besoin de récupérer des données depuis une source de données selon certains critères. Aujourd'hui, si ma source de données est composée d'instances java, je vais devoir parcourir mon graphe d'objets et faire des tests pour vérifier les critères. Pourquoi ne pas imaginer une autre façons de faire ? On pourrait faire une variante de SQL (une sorte de HQL pour ceux qui connaissent) mais, je trouve que c'est encore trop compliqué pour notre besoin qui est très simple. Pourquoi ne pas avoir un langage comme cela :

Code :

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

myObject.myProperty.anotherProperty[myCriteria] + myObject.aProperty

Où myObject est une instance, myProperty, anotherProperty et aProperty des collections et myCriteria une condition. Si je fais ça en java pur, je suis obligé d'écrire 3 boucles. Ce n'est pas la fin du monde mais, ce que je viens de mettre plus haut et largement plus facile à comprendre, est à la portée du premier venu et le développeur perd moins de temps à faire des boucles débiles. C'est juste un exemple pour répondre à un QUOI (la phrase en gras plus haut). Peut être que ce genre de langage existe déjà (en fait j'en connais un ) mais, pourquoi ne pourrais-je pas l'utiliser avec n'importe quelle source de données objet ?

Un autre exemple de problèmes : comment faire une jolie interface ?
1- Je fais tout à la main en C en utilisant l'API windows
2- J'utilise un éditeur pour dessiner ma fenêtre. Puis, hmm voyons. Si je veux afficher une liste, je dois pouvoir indiquer une source de données et utiliser le langage de requête énoncé plus haut pour indiquer quels sont les valeurs à afficher. C'est du databinding basique !!

Je prend la solution 2 même si cette solution va peut être me sortir le même code que la solution 1.

Un autre exemple de problèmes : comment faire pour être multi plateformes (OS et plateforme physique (PC, téléphone, tablette)).
1- Je fais un programme pour chaque plateforme
2- J'utilise HTML5+javascript et c'est le browser (développé par des experts) qui se charge de l'intégration à la plateforme

Ces deux problèmes sont d'actualités. J'aime beaucoup l'exemple du HTML5 parce que pour la même source, on obtient le même résultat selon la plateforme. Donc pourquoi pas quelque chose d'encore plus haut niveau qui est interprété ou qui génère du code ?

Il y a pas mal de travail à faire, c'est sûr, c'est pas demain qu'on va avoir ce qu'énonce cap_gregg mais, j'ai envie de dire : pourquoi pas plus tard ? Et, attention à ne pas lire cela en diagonale. Des personnes sachant programmer en assembleur, en c, en c++, en java, en ce que tu veux, on en aura toujours besoin. Seulement, leur travail sera beaucoup plus intelligent et ne sera pas du simple pissage de code déduit des spécifications (si c'est déduit, ça veut dire qu'on peut générer du code ou interpréter un modèle). Ces experts seront essentiels pour développer les outils permettant l'évolution dont on parle (mais bon, visiblement, il va d'abord falloir les convaincre )

Sans doute parce que Microsoft, Sun et Oracle ne sont pas au service de ceux qui voudraient que tous les langages ressemblent à SQL.

Encore une fois, SQL était juste un exemple pour répondre à un certains type d'opérations. Il faut pousser le raisonnement plus loin (puis si je veux chipoter : Sun n'existe plus ).

[Bluedeep]

Bonjour

D'ailleurs, son aparté sur le SQL est excellente.

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.

Tout gestionnaire de bases de données qui se respecte gère ce langage.

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).

Pourquoi ne pourrais-je pas l'utiliser sur une source excel ou même des instances java (moyennant une évolution du langage bien entendu).

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 :

On pourrait faire une variante de SQL (une sorte de HQL pour ceux qui connaissent) mais, je trouve que c'est encore trop compliqué pour notre besoin qui est très simple. Pourquoi ne pas avoir un langage comme cela :

Code :

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

myObject.myProperty.anotherProperty[myCriteria] + myObject.aProperty

Où myObject est une instance, myProperty, anotherProperty et aProperty des collections et myCriteria une condition. Si je fais ça en java pur, je suis obligé d'écrire 3 boucles.

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