Lizzie Crowdagger a écrit 219 commentaires

"Est-ce possible en rust ?"

Oui tu peux avoir la même chose avec l'implémentation par défaut de traits.

trait Plop {
    fn even (&self) -> bool {!self.odd ()}
    fn odd (&self) -> bool {!self.even ()}
}

L'annonce de la sortie imminente de la version 1.0 de ce langage m'avait motivée à m'y pencher un peu plus (j'avais regardé un peu suite aux différentes dépêches, mais vu les évolutions d'une version à l'autre j'avais préféré attendre que ça se stabilise).

Bilan : je trouve les fonctionnalités un peu "annexes" (le pattern matching, l'inférence de type) plutôt sympathiques, certes c'est pas "nouveau" mais quand même plutôt bien foutu.

Par contre la façon de gérer la mémoire… ouah, c'est quand même vraiment particulier, et autant le reste j'ai l'impression d'avoir déjà vu des éléments dans un langage ou un autre, autant là, il y a un coup de main à prendre. Je pense notamment à la notion de "lifetime", qu'il faut parfois déclarer en plus du type des variables pour indiquer que la référence que renvoie une fonction ne sera plus valable une fois que tel argument sera détruit. Une fois le truc un peu compris, ça paraît une bonne idée, mais ça m'a demandé de réfléchir un peu plus que la plupart des autres langages à la syntaxe "à la C". (Ce qui me rend dubitative sur l'attrait de Rust pour les fans de langages dynamiques : pour le coup le on a un compilateur que je trouve quand même fort psychorigide, ce qui est une qualité dans une logique de sécurité du code mais me paraît demander quand même une autre approche qu'un langage dynamique.)

Globalement je trouve l'approche du langage intéressante, même s'il y a des choses qui me convainquent moyennement pour l'instant (notamment le fait que quand tu fais un appel à ma_fonction (x) ça peut être soit une copie, soit un move qui va transférer la «propriété» de la variable x à la fonction ma_fonction, ce qui empêche d'utiliser à nouveau la variable par la suite dans la fonction appelante). Peut-être que c'est une question d'habitude à l'usage, cela dit.

Ben d'après le journal ce qui se passe c'est que :

Effectivement, au boot, j'ai un timeout puis le choix de retenter ou d'entrer dans un shell de secours.

Je trouve que ça mangerait pas de pain de proposer une option supplémentaire pour continuer le démarrage en ne montant pas cette partition ce coup-ci.

J'ai re-regardé vite fait pour voir la différence, vu que j'avais plus trop réutilisé le mode monofenêtre (qui a peut-être évolué) depuis, et notamment un truc que je trouve gênant, c'est quand tu as plusieurs images ouvertes, tu te tapes une grosse barre horizontale façon onglets de Firefox (qui prend pas mal de place parce que t'as une preview de l'image) qui réduit pas mal l'espace vertical qui reste à disposition vraiment de l'image. Après j'admets que j'ai pas cherché des plombes non plus, si ça se trouve il y a moyen de désactiver ça et je veux bien admettre une part de biais de "le truc auquel j'étais habituée était mieux" :)

Le mode multifenêtre n'est utilisable que si tu as au moins 2 grands écrans et que tu te consacres à 100% au dessin.

Ah ? Moi j'ai eu l'expérience inverse, c'est-à-dire que sur un laptop à petit écran je trouvais le mode monofenêtre insupportable (la place pour l'image étant vraiment petite, du coup).

Le problème d'inclure du LaTeX comme du HTML c'est que tu perds un des intérêts du markdown (pour moi en tout cas) qui est de pouvoir générer plusieurs formats de sorties différents à partir du même fichier de départ.

J'ai un peu du mal dans l'article avec le raisonnement de son ami de l'EFF, qui explique qu'il utilise Gmail parce que de toute façon vu que tout le monde l'utilise dans tous les cas ses ses données ne seront pas protégées. Soit, sauf que tu peux aussi tenir le raisonnement dans l'autre sens : en utilisant Gmail, non seulement ce qui te concerne n'est pas protégé, mais tu participes en plus à « compromettre » tes interlocuteurs qui n'utilisent pas Gmail, donc si tu t'attaches à la vie privée il me semble que ça devrait te pousser à encore moins utiliser Gmail, non ?

Je n'ai pas testé Elementary OS, mais il me semble que OSX n'est ni libre, ni disponible sous Linux, donc je trouve pas aberrant que des gens qui aiment ce genre d'interface aient envie de pouvoir retrouver ça sous Linux et en logiciel libre.

À propos de la JVM : il y a quand même un petit truc spécifique (enfin, il y a peut-être le même problème pour la machine virtuelle Microsoft) concernant la récursion terminale (Tail Call Optimization). Je maîtrise pas les détails techniques, mais en gros si j'ai bien compris c'est pas possible de faire ça sur la la JVM. Concrètement ça a rien de dramatique à mon avis (en gros il faut juste utiliser la forme spéciale, recur pour faire une récursion terminale si on veut éviter de surcharger la pile). Ça me semble pas une différence vitale et j'avoue que je comprends pas forcément tous les enjeux, mais j'ai vu pas mal de discussions dessus :)

Sinon, c'est pas uniquement la faute à la JVM (cela dit je crois que le problème se pose moins pour la version Javascript), mais Clojure est quand même vraiment long à démarrer, ce qui est pas très gênant pour une appli qui tourne lontemps (serveur web, GUI, …) mais est plus embêtant pour un usage en mode ligne de commande où on n'a pas forcément envie d'attende ~1s pour une commande simple. Je crois qu'il y a des réflexions pour améliorer ça, donc des chances pour que ça s'améliore dans pas trop longtemps, à voir.

Après je trouve que la JVM a aussi des avantages. Pour des petits projets (où t'as pas forcément les moyens d'être intégré dans des distributions ou de fournir des paquets pour chaque distrib), je trouve qu'avoir la possiblité (certes pas optimale, j'en conviens) de fournir un gros fichier .jar avec tout ce qu'il fait, ça rend quand même l'utilisation plus facile.

J'avoue que j'ai pas regardé de près les dispositions possibles en fonction des algorithmes proposés pour voir s'il y avait ce risque, mais en gros le truc indispensable c'est que tous les boutons soient accessibles depuis n'importe quel autre bouton (par une combinaison de touches plus ou moins longue), quelle que soit la disposition.

À vue de pif, mais je me trompe peut-être, j'aurais tendance à penser qu'il y a moins de risque d'avoir un bouton inaccessible avec les distances euclidiennes qu'avec les angles (par exemple avec les angles, si tu as 4 boutons situés en carré parfait, plus un bouton au centre de ce carré, ce dernier ne pourra il me semble jamais être atteint depuis le bord du carré).

Il y a eu un bug, c'est certain. Reste à savoir où il se plaçait: entre le tableau de bord et la chaise, ou dans l'électronique?

Ou peut-être que c'est quelqu'un qui ne savait pas qu'il ne fallait PAS acheter une voiture d'occasion à un vieux type bizarre si elle s'appelait Christine.

Si le moteur se bloquait "a fond" je ne sais pas ce qu'il conviendrait de faire… des prières ?

Tiens je me demandais à ce propos : sur les voitures modernes avec plein d'électronique, est-ce que si t'enlèves les (bons) fusibles, ça permet de couper certains systèmes ?

S'il n'y en a pas en compétition, il y a sûrement une raison, la fiabilité peut-être ?

C'est peut-être surtout qu'en compétition le but c'est d'avoir notamment de la compétition entre humains (dans les couses automobiles c'est pas que ça vu que la voiture joue aussi beaucoup, certes) et du coup c'est plus intéressant que les pilotes aient à gérer eux-même leurs freinages et accélérations que d'avoir un logiciel qui le fait de façon optimisé ?

Mais tout est objet en python. Tout !!!

Pas tout à fait. Là où Smalltalk va plus loin que Python, par exemple, c'est qu'en Python, si je ne dis pas de bêtises, "if" est une construction spéciale, un mot-clé réservé. Alors qu'en Smalltalk ça va être une méthode d'un objet booléen qui va prendre en paramètre un morceau de code qui sera executé par l'objet true mais pas par l'objet false.

Du coup il y a effectivement une démarche plus pure dans Smalltalk, puisque des choses qui sont des mots-clés réservés dans la plupart des langages (y compris orientés objet) deviennent des objets ou des méthodes comme les autres. Après c'est des approches différentes : Python fait plutôt le choix du pragmatisme que de la beauté conceptuelle.

C'est quand même une définition très restrictive de ce qu'est un langage objet. Après ça se tient, si tu définis un langage objet comme ça, y'a plein de langages qui effectivement ne sont pas objet et, bon, OK. Après j'ai l'impression que les définitions les plus courantes ne sont pas aussi restrictives, et qu'il y a une distinction entre «langage objet» et «langage objet pur». Après, on peut trouver que c'est «laxiste» e et que seuls les langages objets purs (donc où tout est objet) méritent l'appellation objet, ça peut se tenir, mais au final je sais pas si c'est un débat très intéressant.

Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

J'imagine que le C++ doit être considéré comme encore moins un langage entièrement objet que Python, vu que les types de base (int, float, par exemple) ne sont pas des objets.

À moins en fait que Python ne soit « moins objet » que le C++ parce qu'il n'y a pas de possibilité de définir des attributs privés ou protégés, et que donc c'est pas de la vraie encapsulation et pas du vrai objet.

En fait je suis pas sûre qu'il y ait une définition unique qui fasse qu'un langage est « plus objet » qu'un autre (par exemple : est-ce que c'est plus «pur objet» d'inclure le maximum de fonctionnalités liées à la programmation objet, ou de décourager l'utilisation d'un autre style de programmation?). Cela dit je suis d'accord que pour moi le fait de pouvoir appliquer une fonction à un objet, plutôt que d'appeler directement la méthode de la fonction, c'est pas spécialement « non objet ». En l'occurrence je reprocherais plutôt un problème de cohérence, qui fait que quand tu connais pas bien et que tu te rappelles juste que pour avoir ce que tu veux c'est «plop», tu sais pas trop s'il faut plutôt faire plop(x) ou x.plop(). (Surtout si comme moi, dès que tu passes d'un langage à un autre t'as déjà du mal à te rappeler s'il faut faire len, length, ou size dans celui-là)

Je crois que c'est plus à vocation humoristique qu'autre chose. Après une licence c'est pas forcément le meilleur endroit pour faire de l'humour ou du second degré, mais c'est un autre problème.

pas forcement facile a mettre en place pour un mag vendu en kiosque (déjà plus réalisable si le mag papier est acheté online), très facile pour un livre…

Là, comme ça, je comprends pas pourquoi ce serait plus facile pour un livre (je parle évidemment d'un livre acheté en librairie pour comparer avec le kiosque, pas d'une commande en ligne) ? Avec le ticket de caisse, peut-être ? Ça me paraît moyennement pratique…

Voilà une bonne nouvelle :)

Je n'ai joué avec que quelques minutes, histoire de voir ce que ça donnait. Pour l'instant j'ai l'impression qu'il n'y a pas foule de langages supportés, mais que ce soit en Python ou en Clojure, le coup d'avoir une évaluation intégrée dans le buffer et qui marche "out of the box", c'est plutôt intéressant (surtout pour Clojure, je suppose que Python a déjà des IDE qui font ça ?).

Après, il y a des trucs d'ergonomie que je trouve un peu… euh, bizarres (par exemple le fait qu'il faille chercher la commande "tabset: add a tabset" dans la liste de commandes de l'éditeur pour avoir deux buffers en côte à côte, au lieu d'une option dans un menu… bon, OK, pourquoi pas…), mais bon, entre le fait que c'est censé être une version alpha et que j'ai pas testé plus que ça ce que ça donne à la longue, je me dis que ça a l'air assez prometteur.

Question bête (j'avoue que je connais pas spécialement le fonctionnement des garbage collectors) : il n'y a pas moyen de forcer le «nettoyage» (ouais, je maîtrise vraiment pas les termes) du GC à un moment précis, histoire d'être un peu tranquille par la suite (par exemple, dans un lecteur de musique, lancer le GC entre deux morceaux vu qu'il y a de toute façon un blanc, afin d'éviter qu'il se déclenche au milieu du morceau suivant) ?

Par contre y'a pas de bindings Gtk+, je crois ? :/

Pour faire des applis GNOME si on aime les parenthèses, ça doit par contre être possible avec Clojure vu qu'il y a des bindings Java (j'avais testé vite fait un Hello World Gtk, ça marchait, mais j'ai pas regardé plus en détail (je trouvais pas non plus le code hyper élégant, mais bon (ah et le problème de la syntaxe Lisp c'est qu'après t'as un peu trop tendance à imbriquer des parenthèses))).

(l'exemple est assez ancien, GtkObject et GtkSignal n'existent plus depuis un bon bout de temps, mais les principes restent valides)

Ah oui tiens, je me disais que c'était un peu bizarre, mais j'ai pas pensé à vérifier de quand datait cet exemple :)

On peut espérer dans le futur avoir des plugins pour GCC ou Clang pour faire ce genre de vérifications. Et un développeur a justement commencé ce boulot récemment pour Clang.

Je savais pas, c'est intéressant comme projet (mais du coup, est-ce que ça ne revient quand même un peu à ce que tu disais là : http://linuxfr.org/nodes/100669/comments/1507561 ? :) D'ailleurs, pour l'instant il n'y a pas de bindings et Rust est encore en développement, mais je me dis qu'à terme ça pourrait être plutôt intéressant comme alternative pour du dev Gtk+)

Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).

Mouais, je pense que c'est bien, les tests unitaires, mais c'est un peu optimiste de penser qu'il y en a systématiquement et qu'ils couvrent tous les bouts du code :) (Surtout que pour les applis graphiques qui demandent une interaction avec l'utilisateur, je trouve pas évident de faire des tests unitaires)

Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.

C'est pas juste une question de style objet et de greppabilité : en Java t'as aussi de l'objet, mais si tu refactores une méthode, t'as la compilation qui va t'envoyer bouler s'il y a un endroit où tu n'as pas modifié l'appel (et, j'imagine, des IDE qui permettent de faire ça automatiquement). C'est la combinaison "objet" et "dynamique" qui rend ça embêtant, parce que si t'oublies un appel dans une fonction obscure qui ne se lance pas tout le temps, tu (ou un utilisateur) ne t'en rendras compte qu'à l'exécution. (Cela dit, oui on peut éviter l'objet en python)

Cela dit, autant je pense qu'un typage statique permet de détecter pas mal d'erreurs à la compilation, autant avec un typage dynamique, certes ça plante à l'exécution, mais en général c'est des erreurs où on voit assez trivialement d'où ça vient (puisqu'il y a quand même une vérification des types, et que tu vas avoir une erreur du genre "Grrrr, tu me donnes une chaine de caractères alors que je veux un entier"). Je trouve ça moins pénible à débugger qu'en C quand t'as un pointeur sur un tableau qui n'est pas la bonne taille, et que ça ne vérifie ni à la compilation, ni à l'exécution, mais que tu te retrouves avec une segfault ou des données bizarres à un autre endroit du code.

Mouais…

Je trouve que dire « le typage dynamique, ça marche pas pour les gros projets », c'est quand même un peu simpliste, il me semble qu'il y a quand même quelques contre-exemples. Cela dit, pour le refactoring, je suis d'accord que typage dynamique + orienté objet ça rend les trucs un peu compliqué, puisqu'effectivement quand tu vois x.show () tu sais pas si c'est un appel à la méthode qu'il faut renommer ou à une autre méthode show () qui doit continuer à s'appeler show (), elle.

Par ailleurs, je suis pas sûre que C/Gobject soit vraiment un très bon exemple de typage statique. Dans du code C/Gobject, il y a beaucoup de casts qui se contentent de vérifier que t'as un pointeur, ou encore des fonctions qui prennent ou qui renvoient du void * (enfin, du GPointer), et pour tout ce qui est objet les vraies vérifications de type (par exemple, vérifier que GtkWindow hérite de GtkWidget et que tu peux donc effectivement appeler gtk_widget_truc) elles se font en fait en dynamique. Un petit exemple (tiré d'un "Hello World" Gtk+) :

gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
                     GTK_SIGNAL_FUNC (gtk_widget_destroy),
                 GTK_OBJECT (window));

Là en fait la seule vraie vérification statique de typage, c'est que "clicked" est bien un char *, par contre tu peux compiler sans que button ou window ne soient des GtkObject, et avec gtk_widget_destroy qui n'ait pas du tout la bonne signature (je pense quand même que ça vérifie que c'est un pointeur sur fonction).

Donc le typage statique, pourquoi pas, mais dans ce cas il faut un autre langage que le C…

Je pense que le le choix des noms de variables dépend aussi du langage, et plus que du langage lui-même de la « culture » des développeurs qu'il y a autour et du fait que tel nom de variable va sembler évident ou pas à un lecteur potentiel. Par exemple il me semble que "x" et "xs" sont souvent utilisés dans certains langages pour désigner respectivement le premier élement d'une liste et le reste de la liste (quand tu parcours une liste par récursion), et je pense que c'est assez clair. Par contre si tu le fais en C où c'est pas habituel je pense qu'il ne vaut mieux pas être aussi concis.