judicael a écrit 20 commentaires

Bonne question. La question de la conformité au droit se pose sans doute, pour beaucoup d'acteurs (entreprises, personnages politiques) comme la question «qu'est-ce que je risque si je confie des données personnelles à des entreprises états-uniennes ?».

Et là, il y a deux théories qui s'affrontaient. D'un côté, les personnes qui vont s'intéresser un peu aux principes et dire que c'est irréaliste. De l'autre, des personnes qui se présenteront comme plus pragmatiques, avec implicitement le raisonnement suivant : j'ai besoin de confier mes données à des entreprises états-unienne parce que je ne sais pas/je ne veux pas faire autrement, donc il faut bien que ce soit légal (mais ma vision est sans doute biaisée).

Dans ce deuxième camp, la commission européenne a défendu l'idée qu'il suffisait d'un petit accord entre les USA et l'union Européenne pour que les pays européens puissent exporter des données personnelles aux USA. Elle a mis en place un premier accord (Safe Harbor) pour cela (c'était avant le RGPD).

À partir du moment où il y a cet accord, tout un chacun peut faire semblant qu'il n'y a pas de problème : «mon entreprise confie des données personnelles à des entreprises états-uniennes, mais ce n'est pas un problème sur le plan du droit [comprendre : je ne risque rien], regardez d'ailleurs cet accord de l'union européenne avec les USA le dit clairement».
C'est ainsi que MS peut se faire certifier HDS et prétendre que c'est complètement légal.

L'accord s'est fait retoquer par la cour de Justice de l'union européenne, qui a considéré que la législation états-unienne était incompatible avec l'«essence» même du droit à la vie privée. Le terme «essence» est dans le texte du jugement et, bien que je ne sois pas juriste, il me paraît extrêmement fort. Ça veut dire qu'il est impossible de réparer la directive Safe Harbor.

Cela n'a pas découragé la commission, qui a proposé un deuxième accord (Privacy Shield). Celui-ci a été invalidé par la CJUE en 2020. Et la commission européenne prépare un nouveau texte.

J'ai dit qu'il y avait deux théories qui s'affrontaient (à l'imparfait), parce que je pense qu'il n'y a plus vraiment d'affrontement : la théorie qui affirmait qu'on pouvait envoyer les données aux USA a quasiment perdu la bataille des idées. En raison de l'affaire Snowden, du Cloud Act, et des deux invalidations des accords existants plus celle, probable, du futur accord (Max Schrems dit déjà qu'il le fera invalider), il devient difficile de plaider qu'on peut confier des données personnelles à une entreprise états-unienne.

Dans ce contexte, il me semble qu'il serait erroné de penser que la prise de position récente de l'éducation nationale citée dans l'article est quelque chose de mineur (prise de position qui suit la doctrine édictée récemment par la DINUM). C'est à mon avis un basculement majeur de l'éducation nationale, qui sera suivi par les autres ministères. Et pour répondre à un autre commentaire : y compris dans les universités. Car quelle que soit la difficulté techniques pour quitter les GAFAM, les services juridiques vont alerter les directions ministérielles/des universités/des rectorats pour leur signaler qu'il y a un risque fort. Et je vois mal ces directions ne pas écouter leurs services juridiques…

Ça ne veut évidemment pas dire qu'on va basculer du «tout GAFAM» à du «tout logiciel libre» d'ici quelques mois. Il y aura évidemment des résistances fortes des GAFAM qui feront tout pour retarder l'évolution. Mais il y a, à mon avis, une tendance de fond qu'ils auront du mal à stopper.

Je ne sais pas précisément comment marchait l'authentification, mais l'expérience montre qu'un certains nombre de développeurs raisonnent de la façon suivante :

• je veux que les utilisateurs s'authentifient en HTTP
• mais si j'envoie le mot de passe en clair, n'importe quel intermédiaire peut voler le mot de passe
• donc je vais être malin et hacher le mot de passe m avec une fonction à sens unique h sur le client, puis envoyer h(m), comme cela le mot de passe ne circulera pas en clair.

Ça paraît malin, sauf que…

• pour s'authentifier auprès du serveur, il n'y a plus besoin du mot de passe m, juste de la valeur de h(m)
• et ça tombe bien pour l'homme du milieu qui va voir passer cette valeur
• il lui suffit donc d'écrire son propre client qui enverra cette valeur (sans avoir besoin de connaître m)

Résultat : on n'a rien gagné en sécurité.

Il y a évidemment des protocoles plus complexes qui permettent de s'authentifier sur un canal qui est espionné. Mais à ma connaissance, pour résister à un adversaire passif, ils demandent de partager un secret (ce qui veut dire stocker le secret sur le serveur) ou… reposent sur de la crypto à clé publique (type échange de Diffie-Hellman). Et si on veut résister à un adversaire actif, il faut rajouter une forme de PKI (certificats).

TL;DR: il y a un protocole qui permet d'échanger sur un canal non-sûr, ça s'appelle TLS.

Je plussoie. Et plus généralement, des moyens à base de crypto (et des moyens globalement relativement simples). Avec un checksum cryptographique envoyé à un tiers de confiance à chaque transaction/chaque seconde/chaque minute/chaque jour suivant ce qu'on veut, on peut assez facilement assurer que toute altération des données est détectée. (Et on peut même le faire tout en gardant la confidentialité des données sans difficulté majeure AMHA.)

Bref, ce commentaire réduit l'intérêt de l'article, et montre le sérieux des préjugés de l'auteur.

Je trouve qu'au contraire ça montre que l'auteur connaît plus d'un langage et n'est pas resté à l'état de l'art des années 70. ;-)

Et oui, la gestion manuelle de la mémoire en C et C++ pose de gros problèmes. Ce n'est pas récent et plus d'un programmeur C ou C++ s'est déjà vu condamné à récrire un GC, en général très mauvais par rapport à l'état de l'art…

(certes, il y a quelques domaines dans lesquels on a des bonnes raisons de ne pas utiliser un GC mais en général, c'est qu'on ne fait pas non plus d'allocation mémoire dans le tas.)

Et tu as surtout oublié le plus gros problème dans la fonction de comparaison de lasher : elle est boguée jusqu'à la moelle.

Parce que "a-b est négatif" n'est pas équivalent à "a est plus petit que b". Du moins pas avec des entiers machines. Par exemple INT_MAX+1 est négatif donc plus petit que INT_MAX, alors que la différence est positive. Bien sûr le problème ne se produit pas pour les petits entiers. Mais ce n'est mis nulle part dans le commentaire. Et pour des couples d'entiers pris au hasard uniformément, je dirais à la louche que ça bogue une fois sur 4. Gênant…

Bref, c'est pour dire que c'est pas toujours la moyenne qui est importante, sinon, on ne jouerait pas au loto.

Effectivement, la moyenne ne dit pas grand'chose à elle seule.

En revanche, pour ce qui est du loto, quand on croit à la chance plutôt qu'au raisonnement scientifique et qu'en plus on ignore ce que vivent réellement les gagnants, on peut y jouer… Un conseil : ouvre plutôt un livret de caisse d'épargne.

Sans avoir les chiffres précis, il reste dure d'être sûr à 100%, mais une chose est cependant certaines (quasi). Moins il y a d'utilisateur d'un langage, moins la moyenne de réussite est noyé, donc on peut juste dire que peu, très peu de personnes ayant utilisées ruby se sont plantées.

Ton raisonnement est incorrect. Tu peux t'en apercevoir aisément avec l'expérience de pensée suivante : tu prends un langage X, tu en fais une version complètement identique que tu appelles Y et tu testes un petit groupe de programmeurs sur X et un gros groupe sur Y. Avec ton raisonnement, tu vas arriver à dire qu'il vaut mieux programmer en X qu'en Y…

Pour en revenir au cas Ruby/Python, la moyenne ne dit rien sur les écarts-types comparés des «performances» des programmes/programmeurs Ruby et Python. Qu'est-ce qui te permet d'affirmer qu'ils sont les mêmes ? Et s'ils sont les mêmes, tout ce que tu peux dire, c'est que la valeur moyenne obtenue est (probablement) plus proche de l'espérance de la valeur vraie lorsque tu as plus d'éléments dans ton échantillon.

Par ailleurs, j'aurais tendance à penser (conjecture qui resterait à vérifier) que les gens qui utilisent un langage moins répandu sont en général des gens plus intelligents (car plus curieux et je conjecture que les deux qualités sont corrélées), donc que les personnes qui utilisent ces langages sont plutôt déjà parmi les meilleurs programmeurs. Si l'«élite», en utilisant un langage original, a les mêmes résultats que le «vulgum pecum» utilisant un langage commun, ça n'est pas bon signe pour le langage original…

Judicaël.

J'aime beaucoup ton soutien à «aujourd'hui» contre «au jour d'aujourd'hui».

T'es tu déjà demandé d'où venait ce «hui» ?

En latin «ce jour» se dit «hoc die», qui s'est contracté en «hodie». Dans la geste de Roland (je recommande la version bilingue de Bédier), j'ai trouvé le mot «hoi».

Et XMLittré cite «hui» chez la Fontaine :

HUI
(ui) adv.
de temps servant à marquer le jour où l'on est.
Vous serez le parrain, dès hui je vous en prie, LA FONT., Mandr..
Dans dix mois d'hui, je vous fais père enfin, LA FONT., ib..
En termes de pratique, ce jourd'hui, les chambres assemblées.
Hui a vieilli, on dit aujourd'hui ; il est malheureux qu'on ait changé ce mot pour > un équivalent si lourd.

Amusant, non ;-)

Différence à noter cependant entre la commission européenne et nos ministres : la commission cumule les pouvoirs exécutifs, législatifs (le parlement européen ne peut à ma connaissance pas proposer de textes de lois) et judiciaires (sanctions envers les états membres). En France, il y a certes confusion des genres également mais en un peu moins pire (par exemple, le parlement peut dire non au gouvernement et le gouvernement ne peut pas lui forcer la main sans prendre le risque de se faire censurer… ; le parlement peut décider de faire tomber un gouvernement, je ne crois pas que ce soit le cas au niveau européen).

Dans les deux cas on voit en tout cas clairement que le fait que les dirigeants soient élus (directement ou indirectement) ne suffit pas à assurer qu'ils soient au service de l'intérêt général. Mais qui se soucie de la séparation des pouvoirs ? Et qui se soucie vraiment de démocratie ? Vous avez déjà vu un référendum d'initiative populaire en France ? ou dans l'Union Européenne ?

Pour ma part, j'ai enfin résolu le problème de classement de mes mails grâce à notmuch. Mais chut ! Quand on utilise un outil aussi génial (même s'il a encore quelques petits bugs), mieux vaut ne pas en parler, sinon tout le monde va se mettre à l'utiliser et ça va sérieusement manquer d'originalité ;-)

redo (cf article de Bruno Michel du 11/1/2011) est un outil

• minimaliste (une version correcte mais pas optimale en quelques centaines de lignes de sh existe)
• très unixien (on peut écrire ses scripts de compilation dans le langage de son choix)
• qui gère correctement les dépendances (i.e. si je change un paramètre de la commande utilisée pour recompiler certains fichiers, il recompilera les fichiers en question et uniquement ceux-là).

Le concept se comprend en quelques minutes ou quelques heures, il faut parfois un peu de pratique ensuite pour trouver comment faire bien ce qu'on faisait (mal) avec make, mais globalement, ça marche très bien. Je l'ai adopté depuis quelques mois et j'en suis très content...

Pour info, il existe pas mal d'outils qui permettent d'avoir accès à S3 (il suffit de chercher un peu), et duplicity a une interface graphique (déjà dup).

Quant à la possibilité d'utiliser la ligne de commande, c'est clairement un gros plus par rapport à un clickodrome : ça permet d'automatiser la procédure.

Pour ce qui est de l'apparente difficulté de la ligne de commande, comme le dit Sénèque dans ta signature :

« Ce n'est pas parce que les choses sont difficiles que nous n'osons pas, c'est parce que nous n'osons pas que les choses sont difficiles»

;-)

Pour mémoire, même si j'utilise tous les jours la ligne de commande, je suis loin de maîtriser toutes les options des commandes que j'utilise. Quand j'ai besoin de mettre en place une procédure (par exemple mes sauvegardes), je consulte la doc, je fais des essais, je trouve les options dont j'ai besoin et je mets ma commande dans un script.

Je ne voudrais pas faire de pub éhontée mais pour ma part, j'utilise depuis quelques mois amazon S3 avec duplicity. Autrement dit, j'utilise un service payant (probablement réalisé avec du logiciel privé voire privateur), dont l'interface a des specs publiques, avec un client libre. Donc ça m'a l'air plus libre que le service de Mandriva (si j'ai bien suivi : client pas libre, protocole secret et serveur pas plus libre que s3).

Niveau prix, Mandriva est à 7€ par mois pour un forfait de 20 Go (donc 0,35€ par Go). Amazon, à 0,10$ par Go transféré vers amazon plus 0,18$ par mois par Go stocké. Avec S3, si on ne consomme que 4Go, on ne paie que 4 Go, pas plus (donc pour un stockage de 4 Go sur un mois, 1,12€ contre 7€ ce qui fait cher du dollar).

Les prix de stockage pour s3 sont dégressifs après 50 To, donc pour les gros consommateurs, on peut aller apparemment plus loin que les 100Go de Mandriva (je n'ai pas testé).

Pour mémoire, duplicity :

- fait des sauvegardes incrémentales (à la rdiff-backup),

- chiffre les données avec gpg sur le poste client (donc le stockage est chiffré, pas seulement le transfert),

- coupe les archives en morceaux sur le poste client (donc a priori la seule limitation sur la taille des fichiers, c'est le système de fichiers où sont stockées les données et duplicity : aucune dépendance vis-à-vis du service proprio).

D'ou ma question : quel est vraiment l'intérêt du service de Mandriva ? (mis à part de soutenir Mandriva que-y-sont-gentils-y-font-du-libre ; pour soutenir le LL je préfère faire directement un don plutôt qu'acheter un truc qui ne me convient pas).

J'ai beau chercher, je ne vois pas d'argument sérieux… J'ai raté un truc ?

Comme d'habitude, l'académie prétend tout savoir. Et tant pis pour Racine, qui a déjà féminisé le mot ministre il y a quelques siècles...
cf http://www2.hec.ca/qualitecomm/chroniques/femini/racine.html

La langue française a existé avant les académiciens. Elle continue à évoluer indépendamment d'eux, malgré qu'ils en aient.

> La "GPLv2 or later" est compatible avec la GPLv3 puisque la "GPLv2 or later" peux être transformer en "GPLv3".

Dans ce cas, il vaut mieux la transformer en "GPLv3 or later", pour éviter le même problème dans quelques années :-)

Je connais peu les problèmes spécifiques de développement bas niveau, mais clairement, ce que tu as fait me semble avoir plus qu'un "petit intérêt" :

- Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ? (Forth ?) Clairement, Lisaac me semble une innovation dans ce domaine et elle est la bienvenue.

- De ce que j'en ai vu, l'interface Lisaac/C semble être extrêmement aisée puisqu'on peut écrire du code C dans une méthode Lisaac, ce qui me paraît également un très bon point pour travailler avec des systèmes existants.

Un créneau qui me semblerait intéressant, c'est de convaincre des développeurs de modules du noyau Linux ou/et des développeurs de (modules) xorg d'utiliser Lisaac (attention qd même aux questions de licence), car cela donnerait une forte visibilité à Lisaac. Est-ce dans tes projets ?

Linux est écrit en C, un langage qui n'aurait jamais dû exister. J'aimerais beaucoup que C puisse être mis à la poubelle et remplacé par un langage de plus niveau et *nix lui-même remplacé par des OS mieux conçus. On peut rêver d'un OS en Haskell (voir le boulot très intéressant d'Andrew Tolmach sur le sujet) et de machines Lisp mais C ne pourra sans doute être remplacé que progressivement, de manière évolutive. J'attends donc beaucoup de Lisaac...

Judicaël.

PS : Pour justifier mes remarques sur C : Les débordements de tampons, responsables de la majeure partie des failles de sécurité, étaient inexistants en 1974 sous le système le plus sécurisé de l'époque. Il faut dire qu'il était écrit en PL/I, un langage certes assez gros, mais dans lequel on pouvait manipuler des chaînes de caractères de façon décente. Plus d'infos : http://www.acsac.org/2002/papers/classic-multics.pdf

Pour mémoire, 33 ans après, je viens de jeter un coup d'oeil au 60 premières vulnérabilités données sur CVE (http://www.cve.mitre.org/cve/) sur les 365 de ce mois (septembre 2007). Pour 9 d'entre elles (15%), on trouve "buffer overflow" ou "stack overflow" dans le résumé...

• Pour répondre à quelques objections sur la lisibilité, il me semble que tout langage permet d'écrire des choses illisibles (à partir du moment où il est Turing complet du moins). Un bon langage de programmation à mon sens est un langage qui permet d'écrire lisiblement. Dans pas mal de situations, Caml permet d'écrire lisiblement là où ni C ni Java ne le permettent (et la réciproque est plutôt rare).
• Un code caml qui implante le produit de matrice peut être tout à fait lisible en fonctionnel et bien plus lisible que les versions impératives : deux fonctions auxiliaires (sigma et init_matrix) d'une ligne et une ligne pour le produit en lui même. C'est très lisible à partir du moment où on sait que "(fun i j -> expr)" désigne la fonction qui à i et j associe "expr".
• Comme je ne suis pas doué, j'ai évidemment fait beaucoup d'erreurs en écrivant le code ci-dessous. Le compilo caml les a toutes corrigées, sauf une dans la fonction sigma qui conduisait à une boucle infinie systématiquement. Correction du bug -> tout baigne. C'est pas en C ni en Java qu'on aurait le même confort.
• Cas des matrices de taille n fixée :

  (* Fonction d'intérêt général *)
  (* Calcule (f i) + (f (i+1) + ... + (f j) *)
  let rec sigma i j f = if j < i then 0. else (f i) +. sigma (i+1) j f;;
  
  (* taille des matrices *)
  let n = ...
  
  (* Construit la matrice des (f i j) *)
  let init_matrix f = Array.init n (fun i -> Array.init n (fun j -> f i j));;
  
  (* somme de matrices, juste pour s'amuser *)
  let sum p1 p2 = init_matrix (fun i j -> p1.(i).(j) +. p2.(i).(j));;
  ;;
  
  let prod p1 p2 =
    init_matrix (fun i j -> sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j)))
  ;;
  

• Cas des matrices de taille dynamique :

  (* Calcule (f i) + (f (i+1) + ... + (f j) *)
  let rec sigma i j f = if j < i then 0. else (f i) +. sigma (i+1) j f;;
  
  (* construit la matrice des (f i j), 0<=i<n, 0<=j<m *)
  let init_matrix n m f =
    Array.init n (fun i -> Array.init m (fun j -> f i j))
  ;;
  
  (* dimensions d'une matrice *)
  let dim_matrix p =
    let n = Array.length p in
    assert (n<>0);
    let m = Array.length p.(0) in
    (n,m)
  ;;
  
  (* somme de matrices, juste pour s'amuser *)
  let sum p1 p2 =
    let (n1,m1) = dim_matrix p1
    and (n2,m2) = dim_matrix p2 in
    assert (n1 = n2 && m1 = m2);
    init_matrix n1 m1 (fun i j -> p1.(i).(j) +. p2.(i).(j))
  ;;
  
  let prod p1 p2 =
    let (n1,m1) = dim_matrix p1
    and (n2,m2) = dim_matrix p2 in
    assert (m1 = n2);
    let c i j = sigma 0 (m1-1) (fun k -> p1.(i).(k) *. p2.(k).(j)) in
    init_matrix n1 m2 c
  ;;
  

Et pas seulement jusqu'au début des années 70 !

Sur le téléphone, l'électricité, ou le train, il suffit de faire la comparaison avec les États-Unis pour voir que notre système fonctionnait bien mieux (avant sa privatisation). De manière générale, j'ai cru comprendre que les économistes disent que sur ces domaines, le seul état stable est celui de monopole. Autant que ce soit un monopole étatique !

Par ailleurs, l'argument de la libre-concurrence qui permet d'améliorer tout ne tient pas sur la qualité des services fournis : pour le téléphone comme pour l'électricité le consommateur n'a pas les infos nécessaires pour savoir quel est le fournisseur qui lui donne la meilleure qualité ou le meilleur rapport qualité/prix et ne peut pas changer toutes les semaines de fournisseur pour comparer lui-même... Et pour ce qui est de la concurrence sur les prix, la seule grosse différence que j'ai vue en matière de téléphone, c'est les prix de FT qui sont plus chers que les autres en raison, non pas de la concurrence, mais d'obligations légales me semble t-il (ART)...

À la rigueur, pour les trains il peut y avoir des horaires qui permettent de comparer, mais quand vous avez deux trains de deux companies différentes sur une même ligne l'un derrière l'autre, il y a peu de chances que le second dépasse le premier. Autrement dit : pour les trains on peut comparer, mais la concurrence (sur le temps de transport) ne peut pas s'exercer.

On pourait aussi prendre l'exemple récent d'Airbus (merci l'État d'avoir fait une boîte qui tourne bien et de l'avoir vendue à un prix dérisoire), parler des aciéries Mittal (merci l'État pour la remise à flot d'Usinor dans les années 80), ...

On peut râler sur la qualité de nos services publics (on dit parfois que les Français sont très doués pour râler et j'ai moi-même des dispositions en la matière), mais dans les moments de frustration, il faudrait quand même penser à comparer notre système à d'autres systèmes réels (les plantages monumentaux des systèmes téléphoniques aux US dans les années 80, Enron qui a vendu plus de vent que d'électricité, les trains anglais qui sont tellement bien que les voies ont été discrètement renationalisées après le 11/9/2001, pendant que les médias regardaient ailleurs, les systèmes de retraite par capitalisation dans lesquels les retraités gagnent nettement moins que ce qu'ils pensaient) et pas juste aux systèmes théoriques du libéralisme parfait.

Pour conclure, il est assez remarquable que les tenants des solutions dites "libérales" accusent souvent leurs opposants sur le mode : "vous êtes dans l'idéologie, nous sommes des pragmatiques", le plus souvent sans donner autre chose que des théories basées sur des modèles simplistes pour soutenir leurs faits et que l'exemple de l'URSS pour démolir les propositions qui leur sont opposées... Comparons ce qui est comparable, améliorons ce qui est améliorable, mais ne lâchons pas la proie pour l'ombre.

Judicaël.

PS : Oui, bon ça n'a que peu de rapport avec linuxfr. Mais bon, en matière de logiciel comme en matière de politique économique, je réagis au lavage de cerveau ambiant ("le logiciel propriétaire et les privatisations lavent plus blanc").

Bien vu, c'était effectivement Valeur n -> n.

Effectivement, un des problèmes de l'enseignement de Caml, c'est qu'on l'utilise en prépa, sous une forme ancienne (caml-light au lieu d'Objective Caml), et pour rarement pour des exemples comme ceux des langages de script. Pourtant PCRE existe en Caml, on peut accéder à un certain nombre d'appels systèmes Unix, de façon portable entre les différents Unix, et pour la plupart des appels, aussi sur MS-chose. Et quand on n'a pas ce qu'il faut, on peut interfacer avec du C, du Java, ou même du Perl...

Et avec tout ça, on a un interpréteur (toujours très pratique, ceux qui utilisent des langages de scripts savent de quoi je parle), un compilo vers du byte-code portable et porté à peu près sur tous les Unix, et un compilo natif. Il y a aussi un debugger, pas forcément facile d'accès au départ (interface graphique : emacs) mais qui autorise le voyage dans le temps : le programme lève une exception après 123456 étapes élémentaires d'exécution ? Ok, je vais voir ce qui se passe 20000 étapes avant... Je ne connais pas beaucoup de debuggers qui font ça.

Je t'accorde que ./configure; make; make install c'est pas trivial pour un utilisateur de base (le plus dur est d'ailleurs plutôt la gestion des dépendances). Et que c'est long...

Mais de là à dire

Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?

Je ne vois pas bien en quoi compiler est une opération qui doit être réalisée par des spécialistes. Ça peut être automatisé (et la construction des paquets binaires l'est pour pas mal de distrib)... Et quand ça marche pas avec une install binaire, il fait quoi l'utilisateur ? Le rapport de bug (et la correction) sont souvent plus facile quand on sait à quelle ligne ça a foiré...

C'est clair que les fonctionnalités sont clairement bien en deçà de celle de LISP (ou de ses dialectes). Je suis étonné du nombre de langages qui fleurissent et dont les "nouveautés" sont beaucoup moins bonnes que l'état de l'art dans des systèmes moins connus ou sont tout simplement des choses qui devraient faire partie de la bibliothèque et pas du langage.

Exemple ici :

* templates : un mécanisme à pleurer quand on a un minimum joué avec des systèmes de modules paramétrés comme ceux de SML ou d'Objective Caml ou même tout simplement quand on a utilisé un langage avec des fonctions polymorphes (ML et l'essentiel des langages typés dynamiquement).

* tableaux dynamiques : devraient faire partie de la bibliothèque du langage, pas du langage lui-même (pour la syntaxe, les macros de LISP permettent de faire ça très bien, on peut s'en sortir également très facilement en Caml)

* "scope guards" : typiquement un truc qui se fait en 3 lignes de code de bibliothèque. En O'Caml le code pour l'équivalent du try finally présenté donne la chose suivante :

let abc() =
let m = Mutex.create() in (* un peu bizarre de faire un mutex localement, a priori, il devrait plutôt être une variable globale, mais bon *)
Mutex.lock(m);
try foo() with e -> (Mutex.unlock(m); raise e)
Mutex.unlock(m)

Maintenant je m'aperçois que ce motif revient un peu trop souvent. Comment faire mieux ? C'est tout simple, il suffit d'écrire le motif en paramétrant par foo :

let with_lock f =
let m = Mutex.create() in
Mutex.lock(m);
try f() with e -> (Mutex.unlock(m); raise e)
Mutex.unlock(m)

Et je peux maintenant écrire abc en une ligne :
let abc() = with_lock foo

Si "foo" est un block de code et non une fonction prenant () en argument, on utilise une simple fonction anonyme :

let abc() = with_lock (fun () -> begin
Printf.printf "Hello world\n";
Printf.printf "Hello DLFP\n";
end)

À côté de cela, on retrouve en D les unions du C (je n'ai pas testé, mais ça a bien l'air d'être ça) alors que clairement, les types sommes qu'on trouve en ML (depuis plus de 20 ans) sont extrêmement utiles. Les types sommes, c'est tout simplement des types unions dans lesquels on peut savoir quelle variante de l'union on a prise.

Ex en Caml :

type figure = Roi | Dame | Valet (* là, c'est juste un type énuméré *)
type carte = Valeur of int | Figure of figure (* une union de figure et int, avec une étiquette (Valeur ou Figure) pour dire dans quel cas on est *)

Mettons qu'on donne au roi la valeur 4, aux autres figures la valeur 0 et aux cartes numérotées le nombre qui y est inscrit. On peut calculer ça comme suit :

let valeur carte = match carte with
| Valeur n ->
| Figure Roi -> 4
| Figure _ -> 0

Cet exemple est évidemment inintéressant mais dès qu'on fait un peu d'algorithmique, il est très pratique de manipuler des structures de données ou une valeur peut être une feuille ou un noeud...

Un des problèmes avec LISP (ou ses variantes comme Scheme), et ML (et ses variantes SML, Objective Caml, ...) est qu'il faut accepter de rentrer dans un modèle qui a été pensé au départ par des théoriciens, universitaires de surcroît (quelle tare !). Pour ma part, je suis tombé dans la marmite dans mon jeune âge mais, bien qu'étant curieux, je n'ai encore pas trouvé de langage équivalent à ceux de cette famille... (pour être précis, les langages plus connus ont des avantages en termes de bibliothèques, d'environnement de développement, mais les langages en eux-mêmes sont nettement, nettement moins fun...)