freem a écrit 4952 commentaires

Par example, l'absence de type algébriques en C++, (i.e. des unions "safe")

Qu'entends-tu par union sécurisée? Une union avec de la "RTTI"?

Rust

Le prochain langage que j'apprendrais, ce sera sûrement Rust, il a pas mal de points intéressants à ce qu'il semble. (pas de GC, se base sur des techniques éprouvées, multi-paradigmes, pas d'héritage direct du C)

(Je fournis des examples si vous voulez).

Je suis preneur, à titre de curiosité.

Mais clairement le même problème existe dans de nombreuses librairies de la vraie vie en python ou en c++.

C'est clair. Malheureusement le C++ autorise les auteurs à faire de la merde, et j'ai lu assez de codes sources pour savoir que l'on ne s'en prive pas, avec un volontarisme variable.
je n'ouvrirai pas le débat sur les origines (en langage de prog) des gens faisant le plus de merdes en C++, mais mon opinion est… disons, contraire à celle Linus Torvalds.
Perso, je pense que quand on fait une fonction qui prend en paramètre un jeu de constantes, le plus simple est de définir une enum qui les définit, et si il s'avère qu'un utilisateur normal (du logiciel et non de la lib) peut impacter dessus via de la config, alors on file une fonction de conversion string<->enum.

je faisais référence par exemple au fait que les tableaux sont souvent passés par référence, et par exemple en Python dans l'exemple donné par Guillaum une copie b = a d'un tableau ne crée pas une copie du tableau, juste une copie de la référence au tableau

Oui, cet exemple est assez moche en effet. Mais c'est lié au langage uniquement: en C, la notion de tableaux n'existe pas (dans le meilleurs des cas on à des pointeurs vers des zones mémoire statique, me semble), donc c'est réglé, en C++ elle existe (array, vector, list, map, set…) et on aurais bien une copie. Je crois qu'en Java c'est la même, ça copie (mais ça va faire 5 ans que j'y ai pas touché, et je n'ai jamais utilisé longtemps ce langage).

Pour le coup, ça me rappelle cette vidéo qui m'avais bien fait rire.

si l'interface est pas claire, tu risque de passer un pire moment en Haskell (pas forcément non plus)

Tu devrais lire le code de la libstdc++ ou de boost::program_options. Tu verras que dans le genre mauvais moment à passer quand il y a une erreur de template, c'est pas mal (d'ailleurs, entre l'illisibilité de boost::po et sa lourdeur, j'ai finit par coder ma propre lib, plus primitive mais bien suffisante pour la tâche, faudra que je partage ça).

j'ai l'impression que plus un langage propose des moyens de documenter automatiquement et formellement (signatures des fonctions, etc.), moins il y a d'exemples dans la doc en moyenne

C'est probablement pas faux, je documente très peu mon code en général, particulièrement quand j'écris un programme (et non une lib). Par contre, je prête beaucoup attention aux signatures de mes fonctions.
Par contre, j'ai arrêté avec les commentaires doxygen, je trouve que le gain est franchement limité: la doc qui en résulte est pourrie au final, et ça pourrit plus le code qu'autre chose.

simplement l'ordre dans lequel les concepts sont appris. Tout le monde apprend ce qu'est une variable en maths avant de l'apprendre en informatique, c'est tout.

Dans ce cas, tout le monde apprend ce qu'est une variable en français (un truc qui varie en fonction de l'environnement) avant d'apprendre ce que c'est en maths.

Tout ça pour dire qu'on est certes habitué à la programmation impérative et à voir les programmes comme des modifications d'état, mais que ce n'est pas nécessairement la plus naturelle.

Je suppose que ça dépend des gens, en fait. J'étais bon en électronique et physique mais mauvais en maths. Pour d'autres c'est l'inverse (pourtant, ces domaines sont très liés!). Le raisonnement n'est pas le même, et de là à dire que l'aisance avec certains paradigmes de programmation en dépends, il n'y a qu'un pas qui ne me semble pas si dur que ça à franchir.
Bref, je suis convaincu par tes arguments :)

Je ne connais pas RxCpp, mais de ce que j'ai pu lire vite fait dans le README, ça semble reproduire des fonctionnalités du .NET, LINQ à priori.
Je n'ai jamais utilisé LINQ, mais un collègue m'en a dis beaucoup de bien.
Il me semble que c'était lié aux bases de données, et wikipedia le confirme:

LINQ définit un ensemble d’opérateurs de requêtes qui peuvent être utilisés pour effectuer des requêtes, filtrer et projeter des données dans des collections, dans des classes énumérables, dans des structures XML, dans des bases de données relationnelles, et dans des sources de données tierces.

Enfin, à ceci près que ce n'est pas juste les bases de données, du coup :)
C'est vrai que ça peut avoir son intérêt, mais je ne suis pas convaincu par le bout de code du README.
Peut-être à cause du style d'indentation (le K&R, c'est bien sur du C pas trop indenté, mais avec l'enchaînement de lambda de ce code, c'est juste illisible sans éditeur, amhà)… ce qui est dommage.

J'aime pas spécialement la sémantique de copie de référence non plus (je suis plus habitué au Perl qui passe par valeur et fait des vraies copies à moins de créer explicitement des références).

Juste pour savoir, quelle langage passe par défaut des références?

C++ […] m'a semblé le genre de langage que si on n'en fait pas pendant un an, il faut réapprendre

Honnêtement, le C++ à une syntaxe horrible, je ne pourrai jamais affirmer le contraire, particulièrement quand on utilise les templates, et de manière générale la STL.
Depuis C++11, on peut enfin utiliser sans trop se prendre la tête, grâce aux lambdas et std::bind, mais je me souviens d'avoir implémenté une lib de fenêtrage (pour la SDL même si le code était plutôt générique… faudrait que je remette la main dessus et que je le nettoie) et dans la gestion des évènements, j'avais une ligne en particulier (qui en faisais 2 dans vim, d'ailleurs) pour laquelle j'avais écrit un paragraphe complet de commentaire, moi qui n'en écrivait que très très peu à l'époque (ce qui n'à pas changé, d'ailleurs, mais bon je préfère un code qui se commente tout seul).

Autre chose que je trouve imbuvable, les streams. J'ai un mal fou avec les opérateurs '<<' et '>>'. Ça viens peut-être du fait que j'ai commencé par le C, mais je trouve printf et puts plus clairs. Pour scanf, non, mais c'est que scanf est un truc vraiment complexe (je veux dire, ça manipule du pointeur dans tous les sens ainsi que des conversions pas forcément évidentes à comprendre).

Par contre, mais ce n'est que mon opinion, si on reste à un niveau faible je trouve qu'il est moins délicat à manier que C ou Java (moins de sucre syntaxique que ces deux-là). Pour le C, il faut vraiment gérer toutes les ressources manuellement, tandis que pour Java, on se retrouve avec une tonne de sucre syntaxique pour le moindre pet (tout est obligatoirement objet donc il faut des classes pour tout, il faut obligatoirement ajouter des try/catch, les "include" font vite la taille du bras…) et si on joue avec des ressources qui sont vraiment demandées, il faut la même rigueur qu'en C, parce que le GC ne passe pas forcément quand il faut (et on ne peut pas l'y forcer, à ce que je sais).
La complexité du C++ est plus dans l'écriture de libs avec de bonnes APIs. Est-ce pareil pour les autres langages, je suppose que oui mais ça dois être moins pire (encore une fois mention spéciale aux templates C++, très puissants mais illisibles et qui génèrent des messages d'erreur horribles).

si l'abstraction ou la doc ne sont pas suffisamment claires

Je pense que c'est justement là le point le plus difficile en programmation: exposer une interface assez simple et claire pour être compréhensible rapidement. Je doute que changer de langage change ça, c'est plus du niveau de l'architecture logicielle?

Erf, exact, j'avais pas vu que tu as mixé les champs de e1 et de e2… c'est fourbe ça :)

En tout cas je note le coup de la comparaison des tuples, ça pourrait me servir un de ces 4.

Si le mot de passe est supprimé, ça n'empêchera pas d'avoir l'écran de login, si?
Le password, c'est utile pour un ssh (et c'est fragile dans ce cas) ou pour une machine multi-utilisateurs (et pour root, bien sûr), mais un système sur lequel on est le seul utilisateur, l'intérêt est plutôt limité, il me semble.
J'ai le sentiment qu'un simple passwd -d [user] rendrait les choses plus simple pour un live.

Lorsque je dis bios, je parle de cet utilitaire

Ok, donc c'est bien le BIOS. Il doit y avoir un paramètre de sécurité qui t'empêche d'agir.

Le plus gros ennui étant de ne plus pouvoir lancer un boot sur cd pour réinstaller l'OS. J'ai sorti la pile mais la manip' n'a eu aucun effet sur le bios, pas de remise à zéro.

Moui, en même temps, je n'ai jamais vu cette manip marcher moi.

Pour une tour, tu as en général un cavalier pas loin de la pile du BIOS, qui est situé sur une série de 3 connecteurs mais n'en relie que 2. Éteindre&débrancher le PC, changer la position, rallumer (rien ne se produit, c'est normal), ré-éteindre(&débrancher, même si c'est plus une sécurité qu'autre chose), remettre le cavalier à sa place, et ré-allumer.
Si c'était le bon cavalier, le BIOS est réinitialisé (sauf dommages plus importants).
Pour savoir quel est le bon cavalier, il te faudra consulter le manuel de ta carte mère, par contre. Pas du PC, de la carte mère.

Pour un PC portable, un voisin m'a donné une technique, que j'ai essayée une seule fois et qui (à ma grande surprise d'ailleurs) avais marché: éteindre et débrancher, batterie incluse, puis, toujours débranché, appuyer longuement (10s devraient suffire, de mémoire) sur le bouton de démarrage. Ça avait dégagé le mot de passe du BIOS de la machine en question.
Hum… par contre j'ai un doute sur le fait qu'il fallait que le secteur soit débranché… je re-testerait si tu me dis que c'est un portable que tu as.

Si cette manipulation (tour ou portable) ne fonctionne pas pour le BIOS, il est probable qu'il faudra flasher ce dernier. Pour ça, il va te falloir aller sur le site du constructeur de ta carte mère, télécharger la dernière version du BIOS, et préparer un support (clé usb ou disquette, en fonction de l'âge de la machine) pour le flashage (qui équivaut à réinstaller le logiciel interne qui "permets de démarrer le pc" pour faire simple).

j'ai un affichage qui ressemble à des caractères piratés

Quelque chose dans ce goût la?

La perte des privilèges utilisateurs s'affiche lorsque j'entre la commande sudo.

Qu'appelles-tu "privilèges utilisateurs", au juste? Aurais-tu le message exact donné par le système? Et je ne pense pas que ce soit un problème de piratage, sinon, mais, on ne sait jamais. À mon goût, ça ressemblerait plus à un problème matériel, genre la RAM défaillante ou le disque dur qui merde.

Le setup avec réparation des paquets bloque.

Quel setup? Quelle commande/logiciel bloque?

il paraît qu'avec l'UEFI on peut accéder à quelques paramètres à partir de l'OS, mais je n'ai jamais pu le vérifier, et je doute que les distrib s'amusent à trop jouer avec ça.

C'est-a-dire?

C'est à dire qu'il serait possible de modifier certains paramètres du BIOS à partir du système d'exploitation, ce qui était auparavant impossible. Maintenant, je n'ai jamais expérimenté, pas de machine assez récente.

Je ne vois pas de quelles connections il s'agit.

À priori tu arrives à utiliser ton utilisateur ordinaire, donc tu peux te connecter, et lire tes fichiers. Pour savoir si tu arrives encore à te connecter en tant que root, le plus simple reste de faire la commande suivante: sudo su, mais tu dis que ça bug.
Une autre solution est, au démarrage du PC, d'interrompre GRUB (le menu qui permets de choisir le système à démarrer). Il y a un document à ce sujet ici. Enfin, il va plus loin, mais peu importe pour le moment.

PS: pour faire des citations, tu peux juste insérer une ligne vide puis faire commencer la suivante avec '>'. Plus de détails sur l'aide mémoire juste en dessous de la zone de saisie quand tu écris.

36 Mo, ça m'intrigue, tout de même, Xorg est quand même assez lourd. Il faut que j'aille voir ça du coup.

Exact, mes doigts ont inversé les lettres.

L'affectation n'est pas du tout naturelle

Pourquoi?
Quand j'étais enfant et que je lisais (je lisais beaucoup) "untel est affecté par [évènement|maladie]" je comprenais ce que ça voulait dire. Si on traduit en programmation, en C++ histoire de troller peu mais bien: "untel = event();" ou "untel = MALADIE::GRIPPE;" ne me semble pas si choquant (à part que la maladie fait gueuler du coup ;)).
Je pense qu'on pourrait aussi parler de l'affectation à un poste. En bref, en français, affectation => changement d'état. Exactement comme en programmation, non?

les variables n'ont pas du tout le même sens que celui appris en maths

Hum… je ne sais pas, sur ce coup, je n'arrive pas à comprendre l'intro wikipedia sur les définitions d'une variable mathématique, dans les différents branches (mathématiques, proba, stats… que des trucs avec lesquels j'étais très, très fâché à l'école). Mais, ça ne me choque pas, je n'ai jamais compris en quel honneur l'informatique devrait être considérée comme une branche des maths.
Pour moi, c'est l'inverse: les maths sont un outil utilisé par les autres sciences, et sans les autres sciences elles n'ont aucun intérêt pratique.
Par contre, j'arrive à comprendre les définitions pour les autres domaines:

• En physique, en biologie, en mécanique et en chimie, la variable représente un paramètre mesurable comme la température, le temps, la vitesse ou l'intensité.
• En informatique, une variable est un symbole (habituellement un nom) qui renvoie à une position de mémoire dont le contenu peut prendre successivement différentes valeurs pendant l'exécution d'un programme
• En sociolinguistique, une variable est un mot dont la forme varie selon le genre, le nombre ou la fonction

La notion commune, c'est le changement, ou pour être plus exact, le nommage d'une valeur qui peut potentiellement changer. Je trouve que ça se tiens, mais c'est peut-être une question de biais personnel. Il faudra que je teste un truc la prochaine fois que je discuterais avec des techniciens qui ne connaissent rien à l'informatique: placer le mot variable pour voir comment ils réagissent.

Le pire étant de pouvoir modifier le contenu des variables passées en paramètres des fonctions qui complique le raisonnement.

Hum, je vois ce que tu veux dire, mais à part les langages qui passent des références non constantes par défaut (ça, c'est vraiment dégueu si veux mon avis), le programme appelant ne verra pas la modification.
Ce qui est regrettable, et je suis d'accord, c'est que par défaut ça ne soit pas constant, et du coup le compilateur ne gueule pas quand on fait void foo( int bar ){bar=2;}.

(mais pas pour tous les types de variables pour compliquer le truc)

Pas d'accord.
En C et en C++, pour tous les types de variables on peut, tant que ce n'est pas constant.
Ce qui complique le truc, comme tu dis, c'est que certaines variables indiquent la position d'éléments qui ne sont pas elles-même. Et la modification n'affecte qu'une copie, l'appellant ne la verra donc pas.
Dans d'autres langages, ça peut changer, mais ça serait de très mauvais goût de passer by-ref si les ref ne sont pas constantes…

J'admets que ça dois pas être simple à expliquer, et typiquement je me souviens que la notion de pointeurs et de mémoire à été difficile à comprendre pour mes camarades de BTS (pourtant, la plupart avait un bac STI électronique… l'adressage mémoire c'était au programme de 1ère me semble). Moi, je ne me souviens pas si j'ai eu du mal: j'ai appris seul donc, pas pu me comparer aux autres.

que tu as mal pris en compte, de là à conclure que c'est source d'erreur ;)

Mais non, c'est juste que c'est la meilleure façon pour que je sois en haut du classement en maths :D

Tient, j'ai une autre proposition marrante, en C++ :

Du coup, le tri se fait dans le même sens pour les deux membres, c'est la même erreur que j'ai faite moi-même, non?
Aussi, je ne suis pas sûr que les tuples implémentent l'opérateur< ? Si c'est le cas, peut-être que je finirai par m'en servir, jusqu'ici à chaque fois que j'ai essayé, ça c'est transformé en classe dans les heures qui suivent (contrôle du comportement plus fin, et code vachement plus lisible, parce que les tuples c'est supra lourd à lire. Un peu comme les lambda, mais sans la raison de rendre utilisable , en fait.)

C'est en discussion pour c++17 et j’espère que cela aboutira.

Ça serait vraiment pas mal oui. J'avoue ne pas avoir trop suivi ce qui est prévu pour C++17, il faudrait peut-être que je commence à m'en inquiéter.

et propose […] de définir une interface et des lois pour les types qui suivent cette interface [commune aux types].

Je suppose donc que les unsigned int (par exemple) disposent de ce type d'interface?

Preuve que cela devrait être pensé dans l'autre sens ;)

Je suis d'accord avec ça, tant qu'on garde un moyen simple (et concis) de rendre les données mutables (j'ai un peu trollé sur l'immutabilité, mais dans la pratique mon code est constellé de const, j'aime me faire engueuler par le compilo alors je fais des interfaces qui le font râler le plus possible quand mal utilisées).
Mais dans le cas que j'ai cité, ça marche juste pas en fait (ça me paraissait bizarre honnêtement, de déclarer une variable en tant que rvalue) ce qui résous mon interrogation. Après une compilation tu aurais sûrement mis un const&.

Tout est dans le titre. Il en existe des tonnes, après, plus ou moins simples à manier, mais tu n'as rien précisé à ce niveau, donc, à toi de les essayer.

D'accord, merci pour l'info. J'ai un peu joué à réduire l'empreinte d'une Debian le plus possible, pour l'instant en me limitant à un système qui tourne avec juste un serveur ssh (pas de X donc, autrement dit, intérêt inexistant pour des machines de bureau).

Je ne pense pas que ce soit très pertinent pour autre chose que le fun, pas sans recompiler la moitié des paquets, du moins (m'y amuserai sûrement un de ces 4).
En fait, je ne pense pas que Debian soit la distrib la plus adaptée pour faire une distribution légère, sans recompiler: le principe étant d'être universel, la plupart des (si ce n'est toutes les) fonctionnalités sont activées, ce qui peut ne pas être pertinent. Après, l'avantage c'est que c'est éprouvé.

D'ailleurs, pourquoi s'embêter avec un pass en live?

Au chargement en session Live ou installée, 165 Mo sont consommés

Avec ou sans les caches? Joli score en tout cas.
Vous avez juste sélectionné des logiciels plus légers, ou vous avez aussi modifié des paramètres plus pointus, d'ailleurs?

Si c'est juste pour afficher des noms de fichiers, je n'utilise pas ls, find est bien intéressant (si j'ai besoin de filtrer) ou simplement *.
La seule chose qui fait qu'il m'arrive d'utiliser ls pour des scripts, c'est qu'en une commande de 5 caractères, on peut avoir la taille des fichiers et le nom. Accessoirement, on se retrouve avec d'autres infos plus ou moins utiles selon le contexte.
Avec find, il faut jouer de l'-exec pour avoir ces infos la.

Ou alors j'ai raté un épisode (ça ne serait pas la première fois).

Exact, j'ai tendance à oublier que le compte root n'est pas activable par défaut.
Mais, sudo su fonctionnait la dernière fois que j'ai eu à utiliser un *buntu, donc le compte root existait bien. Je pense que le `append="init=/bin/dash"' au boot aurait aussi marché, mais pas vérifié… je n'utilise pas ça tous les jours :)

Sous Debian au moins on à le choix… J'ai tendance à fuir cette technique moi, mais bon, je comprend les avantages de sudo (pas besoin de filer le pass root aux utilisateurs de certaines commandes).

C'est pour les scripts utilisants la sotie de ls que ça va être drôle…

En même temps, utiliser la sortie de ls dans un script, c'est casse-gueule.
Il me semble, justement, que la sortie de ls n'est définie par aucun standard (ce qui fait que le nouveau comportement ne pose en théorie pas de problème) et dès qu'il y à des espaces dans le nom de fichier, c'est juste plus possible d'utiliser des trucs comme cut. Je ne parle pas du cas des colonnes alignées par des suites d'espaces plutôt que par des tabulations. D'ailleurs, une fin de ligne dans ls, c'est représenté par '\0' ou '\n'?

Je ne dirais pas que ça ne m'arrive pas de parser la sortie de ls, mais c'est quand j'ai la flemme ou en dernier recours. Et le nom de fichier que je récupère est destiné à un humain avec un minimum de neurones, pas à une machine, parce que je sais qu'il à de grandes chances de ne pas être exact.

Qu'ils contiennent des caractères spéciaux, manifestement, pas juste un espace. Enfin, avec -lF.

J'ai un doute, tu parles vraiment du BIOS? Il paraît qu'avec l'UEFI on peut accéder à quelques paramètres à partir de l'OS, mais je n'ai jamais pu le vérifier, et je doute que les distrib s'amusent à trop jouer avec ça.

Tu dis que tu perds les privilèges utilisateur, c'est à dire? Tu ne peux plus te connecter? Tu ne peux plus accéder à tes fichiers? La connexion avec root, elle fonctionne encore?

Et merde… 30% de mon salaire vient de mes enseignements à l'université… Mais bon, comme on dit, "Ceux qui savent font, les autres enseignent".

D'un autre côté j'ai été très crû… sûrement trop, p'tet pas la bonne journée :)

Avant de continuer je voulais mettre un truc au point. Ce n'est pas un cours d'introduction à Haskell,

Ce n'est pas un cours, je l'avais bien compris, mais cette phrase me faisait penser que ça serait moins difficile à lire:

L'idée c'est de vous présenter un peu Haskell et sa syntaxe à partir d'un exemple simple à partir d'une fonction simple, le tri.

Ca ne choque personne que le + soit utilisé en python ou en C++ pour concaténer des chaines de caractère

Ce n'est pas exact:

Another, more subtle, issue with operators is that certain rules from mathematics can be wrongly expected or unintentionally assumed. For example, the commutativity of + (i.e. that a + b == b + a) does not always apply; an example of this occurs when the operands are strings, since + is commonly overloaded to perform a concatenation of strings (i.e. "school" + "bag" yields "schoolbag", while "bag" + "school" yields "bagschool"). A typical counter[citation needed] to this argument comes directly from mathematics: While + is commutative on integers (and more generally any complex numbers), it is not commutative for other "types" of variable.

Tout n'est pas rose dans la surcharge d'opérateurs.

Moi c'était plutôt du genre 15+ en math et 2 en français et en physique, chacun son handicap ;)

Ça peut expliquer les affinités avec les paradigmes je suppose :)

Oui, toutes mes excuses, tu n'imagines pas le temps que j'ai passé à rajouter des paragraphs pour rendre mon histoire plus clair.

Ce qui est sûr, c'est que faire simple à toujours été la chose la plus complexe en ingéniérie. Surtout faire simple pour les autres.

Toi tu fais partie de ces étudiants qui n'aime pas comprendre l'ensemble et qui s'attachent aux points de détails. C'est intéressant ;) Ton "pourquoi" est vague donc je vais essayer de répondre à de nombreuses questions possibles :

Pourquoi non mutable ? C'est subjectif. Parce que on aime bien cela en fonctionnel et surtout en Haskell. Cela permet de ne pas se demander qui modifie quoi. Cela simplifie le parallélisme (personne ne va venir modifier ta donnée sans te prévenir) donc on préfère commencer non mutable et introduire de la mutabilité contrôlée quand c'est nécessaire. Cela rend aussi les tests plus simple (pas d'état caché) et le raisonnement sur le code plus simple, car il n'y a pas de modification d'état caché possible.

Pour être honnête, je suis un fanatique des paramètres et méthodes const, en C++. Et pas juste pour le parallélisme, de manière générale ça rend le code plus adaptable. Et ça permets au compilo de vérifier derrière moi.

La plupart des mes algos en Haskell sont en moyenne 2x plus lent que du c++ optimisés

Tout dépend de que tu appelles du C++ optimisé, après. Le C++, si on inclue la STL, à un gros défaut niveau perf: on n'a que peu de contrôle sur la consommation mémoire (oui, on connais toutes les complexités des algo, mais il est difficile d'estimer la RAM que ça va consommer, ce qui impacte potentiellement lourdement sur les caches L1/L2/L3.).

Essaye de te rappeler tes débuts en programmation et ce sur quoi tu bloquais et tu verras que rien n'est naturel ;) Mes bêtes noires à moi c'était la post et pré incrémentation (a++ ou ++a), les constructeurs en C++ et les boucles…

Mes 1ers langages de programmation, dans l'ordre:

• Basic de TI82 (1ère 2nde générale)
• QBasic (1ère 2nde générale)
• ASM (2ème 2nde)
• C (2ème 2nde)
• C++ (BTS)

Le QBasic avait des fonctions mais je ne m'en suis pas servi dès le début, et quant à l'objet, j'ai lutté à comprendre comment ça marche, jusqu'à tomber sur un type qui montrait comment implémenter de l'objet en C… méthodes virtuelles & co.
Le truc, je pense, c'est qu'il faudrait arrêter de faire commencer les gens avec du C ou du Java, qui ne sont pas faits pour l'enseignement. Enfin, c'est mon opinion personnelle. Ce qui à aussi du beaucoup m'aider, c'est que je n'ai pas appris en cours (sauf pour mes 50 premières lignes de QB, un prof qui m'a filé le virus :D et le pire c'est que je l'aimais pas, mais bon), avec un rythme ou des exercices imposés. Sauf pour le C++, mais bon, une fois le déclic objet fait, ça à été tout seul.

Mais si tu y tient, voila l'implementation comparée de mon histoire de tri en Haskell et en C++… Je sais lequel est le plus naturel pour moi ;)

Juste deux petits points:

• si tu veux un truc expressif, plutôt que performant, tu aurais pu utiliser un std::set: std::set<Etudiant,bool(*)(Etudiant const&,Etudiant const&)> etudiants({{"foo",20},{"bar",10}}, [](Etudiant const& e1, Etudiant const& e2){...;}. Bon, forcément, si on veut un autre tri à un autre moment, ça n'est peut-être pas le bon choix :) [1]
• l'opérateur ternaire (?:) rend le code plus lisible parfois (mais ne pas en abuser): etu0.note == etu1.note ? etu0.nom < etu0.nom : etu0.note < etu1.note. Mais la notation Haskell est effectivement belle sur ce coup (doit être codable avec un peu de variadic templates je pense… faudrait tester tiens.).
• for(auto &&item : etudiants), tu aurais pu écrire for(auto const& item : etudiants). C'est ce que j'aurai fait en fait. Ça aurait permis de pouvoir réutiliser la liste après les yeux fermés, parce que là j'ai un doute sur l'état des éléments de etudiants après coup.

J'espere que mes réponses t’intéresserons.

Beaucoup.
Quant aux '<<', c'est sûrement mon passé de C, mais je trouve ça immonde. J'aime pas les iostreams… un bon vieux printf c'est tellement plus lisible. En tout cas, tu aurais pu mettre les 2 'std::cout' sur la même ligne.

1:
Et la taille de cette ligne, c'est une des raisons qui font que quand j'utilise un conteneur STL, j'utilise TOUJOURS un typedef.

Franchement, pour avoir enseigné la programmation à des débutants, le C, le Java et le JavaScript sont loin d'être faciles à comprendre.

Forcément. Le Java impose du sucre syntaxique débile dans tous les sens (tout est objet… y compris la fonction d'entrée, que l'on doit du coller en static… ahem…), le C impose de gérer la mémoire à la main, donc une connaissance au moins de base de ce qu'est un pointeur… et JavaScript, je sais pas, je connais pas.
Personnellement, j'ai débuté en QBasic, c'était vraiment simple. Pas de gestion mémoire, pas d'objet, du typage optionnel (si je ne me trompe pas) et des chaînes de caractère digne de ce nom (contrairement au C, qui à été mon 2nd langage).

Aussi surprenant que ça puisse paraître, je pense que C++ est plus facile à utiliser que le C ou le Java, si on évite d'enseigner la création de bibliothèques et qu'on se limite à la console: de l'objet optionnel, pas de gestion mémoire manuelle. Choses qui deviennent nécessaires par la suite, mais au début on peut s'en passer.
Le seul truc gênant, c'est le typage fort, je dirait, mais un physicien ne serait pas surpris: les unités c'est important, 5°C ce n'est pas 5V (et un résultat sans unité était considéré comme faux, de mémoire).
Ah, et bien sûr, les messages d'erreur liés aux templates aussi, c'est moche, mais ça s'est bien amélioré.
M'enfin, de toute façon, aucun des langages que l'on à cité n'est fait pour l'enseignement. Pascal/Delphi eux ont été conçus pour il me semble, mais je n'ai pas assez vu de code Pascal pour juger de la lisibilité du langage.

Alors moi je me rappelle très clairement de quand j'ai appris le « i = i + 1 » qui n'était absolument pas naturel

Le C (et ses fils) sont en effet moches sur ce point, mais ce n'est pas une fatalité, certains langages utilisent d'autres signes (: en pascal je crois?).
Je parle de paradigme, et tu réponds avec un exemple de syntaxe :)

En fonctionnel pur (ce qu'est Haskell), c'est le postulat inverse.

Oui, je sais. J'avais essayé de me mettre à je sais plus quel langage fonctionnel à un moment donné. Mais le fait est que je n'ai jamais réussi à faire une I/O, très gênant, un programme qui ne modifie rien, je trouve (y compris l'écran…).

Ça reviens à ce que je disais, les langages fonctionnels sont complexes, peu naturels. Dire à quelqu'un qu'il va apprendre la programmation pour écrire des programmes qui n'interagissent avec rien, ça me semble difficilement motivant.