Guillaume Maillard a écrit 274 commentaires

Aurais tu des exemples d'applications qui sont, selon ta description, basées sur des "techno modernes"?
Difficile d'en trouver trace hors du helloworld ou de la description d'infra basées sur des milliers de serveurs.

Si seulement la priorité était de corriger la version officielle…

Peut être qu'un jour, ils se bougeront chez Oracle et changerons le bytecode pour inclure les génériques…(dont l'implémentation actuelle n'est pas géniale).
Le "diamant" c'est pas la plus brillante des idées.
On aurait aimé passer de

List<String> l=new ArrayList<String>();

à

List<String> l=new ArrayList();

Mais j'ai l'impression que c'est comme pouvoir synchroniser les constructeurs pour éviter de gérer les barrières mémoires avec des accès à des "final"…. c'est pas pour demain…

1

Je suis tout à fait d'accord avec toi quand tu considère que sur la ligne (et uniquement celle ci)

var myMap = new HashMap<String, String>();

il n'y a pas de perte d'information, mais je ne vois pas le gain par rapport à :

HashMap<String, String> myMap = new HashMap<>();

car ce n'est ni plus substantiellement long à écrire, ni à lire, ni à comprendre, ni à stocker.
Donc, pour moi, à ce niveau, 'var' c'est inutile.

2

Sur ton exemple :

var myContacts = getContacts();
for (var contact : myContacts){
   display(contact.name);
}

le problème est masqué car le var myContacts = getContacts(); est juste au dessus de ta boucle.
Intercales un ou deux écrans de code et tu n'a plus le contexte.
Pour pas te perdre, tu vas avoir tendance à généraliser ce que tu fais dans ton exemple, cad nommer tes variables en fonction de leurs types.

Par contre, si tu écris du code métier avec beaucoup d'abstraction, très rapidement tu te moques du type

J'aurais tendance à dire que dans ces cas, les classes manipulées implémentent souvent de multiples interfaces et qu'il est donc important de bien savoir ce que l'on manipule.
Peut être un exemple simple et court qui te parleras plus :

void store(String s, int nb) throws IOException {
  var stream = getCurrentStream();
  for(int i=0;i<nb;i++){
      stream.write(s, 0, s.length());
  }
}

Il se passe quoi? On écrit un fichier? On écrit sur une socket? On a flingué les perfs ? Le code est correct?

Par contre si tu écris :

void store(String s, int nb) throws IOException {
  FileOutput stream = getCurrentStream();
  for(int i=0;i<nb;i++){
      stream.write(s, 0, s.length());
  }
}

C'est tout de suite plus clair, on écrit dans un fichier
et, en plus, de la pire des façons.

On écrira donc :

void store(String s, int nb) throws IOException {
  FileOutput stream = getCurrentStream();
  BufferedOutputStream b = new BufferedOutputStream(stream);
  for(int i=0;i<nb;i++){
      b.write(s, 0, s.length());
  }
  b.flush();
}

Donc, pour moi, à ce niveau, 'var' c'est casse gueule.

Désolé de devoir me contenter de code de quelques lignes pour la lisibilité, les vrais problèmes apparaissent avec la complexité et la taille. Bien que je travaille en équipe sur un "codebase" d'un demi million de lignes Java depuis des années, je comprend très bien que "var" puisse être attrayant pour de tout petits projets, mais même dans ce cas j'ai du mal a y voir un véritable gain.

On ne le connaît pas exactement mais on s'en fout

C'est vrai, après tout, tant que ça compile… :) dans la même veine j'ai
"et si ça plante, on reboot."
et
"ici ça marche"
et
"j'écris du code c'est pas mon job de m'occuper des bugs"

Avec des raisonnements comme ça, c'est sûr qu'on fait des logiciels de qualité.

Tu passe la souris dessus

Il est où le gain de temps et de lisibilité ?

LA question que je pose depuis le début et que tout le monde fait semblant de ne pas comprendre et d'éluder (avec un petit downvote au passage), c'est quand tu lis :

auto counter=getNextValue();

if ( counter == numeric_limits<decltype(counter)>::max() )
 throw overflow_error("counter too big");

++counter;

comment tu connais le type de retour de getNextValue() sans aller voir sa déclaration (dans un autre fichier ou des centaines de lignes plus loin) ?

Ce n'est pas en répondant que "le langage XY a aussi des var/auto" ou "j'y arrive" que tu réponds à la question. Idem pour Renaud. Vos postures a base d'argument d'autorité genre "tu l'utilises pas tu sais pas", "je m'en sers, ca marche", "OCaml c'est bien", c'est le genre de poudre aux yeux qu'on laissera aux politiques. Et n'allez pas penser que je suis réfractaire à la nouveauté, il y en a de très intéressantes, mais pas celle ci.

De plus, je ne suis pas fan du code que tu proposes, tester les limites des types en dynamique alors que le type ne changera pas en runtime tout ca parce que c'est "mieux" d'écrire "auto counter" que "int counter", ca n'a pas de sens (et je ne parle même pas des performances…).

J'ai l'impression que par lisible tu veux dire "rapide à lire".
Oui, "for (auto element : conteneur)" c'est rapide à lire

Par lisible, j’entends compréhensible, et ceci ne l'est pas, car si la définition de "conteneur" est 40 lignes plus haut ou si c'est lui même un "auto" machin, le code n'est PAS compréhensible. Même pas en rêve avec tes technos dites "modernes" et les bonnes pratiques de mamie.

Pour reprendre sur Java et ne pas digresser sur le C++ qui n'a jamais eu de syntaxe claire,

for (String str : parts){
}
est parfaitement compréhensible, on a tout le contexte. On ne peux pas se tromper sur l'utilisation/le type de 'str'.

Je ne dis pas que le compilateur va se tromper, c'est le programmeur qui ne peux pas s'y retrouver (à moins que ta "bonne pratique" c'est frde nommer les variables/les paramètres en incluant le type.
genre :

var myInt = getNextValue();
Et ici, franchement, on a frôle la débilité profonde.

Comme tu es sérieux et rigoureux, tu vas écrire pour ton compteur :

var count = getNextValue();
et peut être même l'incrémenter quelques lignes plus bas.
Et comment tu vas être sûr que tu ne risque pas te faire un overflow?
count c'est un "int", un "long" ? Ah, non pas de bol, il est lu d'un stream octet par octet, c'est un "byte".

Conclusion, tu ne peux pas comprendre en lisant le code (faut aller voir la signature du getNextValue() pour savoir, une perte de temps), bref, c'est casse gueule au possible et complètement inutile (et c'est pas parce que Rust le fait que c'est bien).

Cette "évolution" de Java est juste là pour faire plaisir aux amateurs de Javascript qui voudrait goûter à Java.

(notons au passage que les gros projets Javascript migrent vers Cleartype pour justement avoir du code "lisible" et plus robuste que la loterie à base de "let" et "var")

C'est assez naïf comme raisonnement. Ce n'est pas parce que le compilateur connait le type que le "programmeur" oui.

Suffit de passer ce "var" magique à une API qui a des méthodes de même nom mais avec des arguments de types différents pour être sûr d'avoir du code Java du niveau d'un code javascript…

Ça va compiler sans problèmes, ça c'est sûr!
Je ne parle même pas des problèmes de refactoring que cela implique.

L'argument C++ et autre, je vois pas le rapport, en C++ on peut aussi se contenter de void** !

code plus lisible et maintenable,

C'est tout le contraire, on ne sait plus de quoi on parle:

var toto = getNextValue();
Tu m'explique comment tu arrives à mieux lire le type de toto pour savoir quoi en faire 3 lignes plus bas?

var titi = toto.apply();
toujours sûr de savoir de quoi on cause?
Je suis très curieux de voir un exemple réel…

en évitant les noms à rallonge

on parle de type, pas de nom de variable ou de paramètre, gagner quelques octets dans un code source n'apporte rien à moins d'avoir de sérieuses douleurs au doigts.
Aux dernières nouvelles, le temps à "taper" le code est ridiculement faible par rapport au temps à passer à réfléchir sur l'architecture, les algorithmes, bref à quoi frapper sur le clavier…

C'est surtout aussi inutile que casse gueule… le typage fort c'est un avantage pas un inconvénient.

Quand je lis "certains types peuvent être soit inconnus du programmeur", je comprend qu'on est pas en train de parler de programmation mais de bidouille, d'un code mal maitrisé qui a toute les chances d'être buggé jusqu'au trognon.

Après l'avoir utilisé quelques heures, je ne peux que vous conseiller de le tester, ça fait du bien, l'ensemble est stable (sauf peut être le navigateur qui plante aléatoire sur Youtube).

L'avantage c'est qu'étant basé sur une architecture performante d'il y a 20 ans (1 thread par fenêtre par exemple), et bien que non fortement optimisé, tout est très rapide et peu gourmand en mémoire.

Graphiquement, ce n'est pas aussi bon que l'original, les marges et alignements ne sont pas terribles, le look "glossy" (que n'avait pas BeOS) fait un peu désuet, mais rien compliqué à corriger.
J'espère que le "subpixel rendering" des polices arrivera bientôt.

Tu as tout à fait raison, les interfaces sont plus élaborées maintenant, mais je nuancerai ton propos en te donnant rendez-vous dans 1 an.
En effet, dans un an, les développeurs de GNOME auront passés des milliers d'heures sur leurs projets, les attentes des utilisateurs n'auront pas bougé, les matériels n'auront pas été révolutionnés.
Et pourtant, je prends le pari que la situation n'aura pas évoluée en termes de qualité et de performance.
Par contre on aura le droit a de nouvelles icônes ou des bizarreries d'ergonomie, GNOME a un passif de 20 ans.

On pourra toujours me reprocher d'être trop corrosif avec GNOME, mais quand ton job et ta passion c'est le développement logiciel, au bout de 25 ans, voire que la qualité a tendance a se dégrader et qu'il y a toujours quelqu'un pour le justifier avec un aplomb fabuleux, ça me fatigue.
Par "faire du code rapide, pas cher et de qualité, ça n'existe pas", si tu veux dire que dans un temps donné, un développeur ne peut pas écrire du code performant (quasi) sans bugs, c'est difficile à justifier.
Car cela revient à dire que tous les développeurs ont le même niveau. J'ai croisé assez de développeurs bien meilleur que moi et aussi bien pire, pour te garantir que je peux faire du code moins rapide, cher et de moins de bonne qualité que certains.
La capacité à écrire du code rapide et de qualité est, de mon point de vue, surtout lié à l'expérience (formation, temps passé sur le même sujet, etc) et l'attention portée aux détails.

Bizarre de me prêter des affirmations que je n'ai pas émises pour défendre coûte que coûte un logiciel mal codé (gdm).

Et pourtant vrai, si tu es développeur, tu peux mettre quelques "printf" pour t'en rendre compte.

Quand tu ouvres un dossier, les droits sont analysés (pour mettre des petites icônes d'interdiction), les icônes sont associées aux types des fichiers et disposées en fonction de la taille de la fenêtre, tout cela dans le respect du "thèmes", de tes préférences etc…etc…

Je ne suis pas au courant d'un accident nucléaire causé par un bug logiciel, ni d’appareil médical qui plante tous les jours…
Surement que les logiciels qui gèrent les plannings ou autres ne doivent pas être au top niveau, mais je ne faisais pas référence à cela.

Pour les jeux, tu crois vraiment que c'est des quiches qui codent les moteurs 3D ?
En 10ms, un développeur de Gnome n'est pas foutu d'ouvrir un dossier, les moteurs 3D s'occupent de gérer des millions de polygone, des gigas de textures, etc…
Je t'invite à regarder les publications/vidéos de Mike Acton par exemple (Data Oriented Programming) ou de Jonathan Blow (qui travaille sur le compilateur de son langage Jai). Le compilateur Jai compile 20 000 lignes de code par seconde, ce qu'il trouve encore lent par rapport à ce qu'il pense possible de faire (x2).

Le bugs auxquels tu fais référence concernent une minorité de jeux, et souvent ceux dont la date de sortie est définie avant que le jeu soit terminé. Quand les studios laisse la possibilité au devs de finir le job, en quelques mois tout est corrigé/terminé.

Gnome, lui, n'a pas de réelle deadline. Une version "stable" sort quand elle est décrétée stable. Gnome a nécessité 20 ans de travail pour en arriver où il en est. Il ne manque pas ici de commentaires pour asseoir (ansi que leur bugtracker) que la stabilité n'est pas son fort. Personnellement, je ne faisais juste qu'une parenthèse sur la gloutonnerie de ressources.

Oui c'est un constat général dans le monde du logiciel.

Il a toutefois des exceptions dans le monde :
- de l'embarqué (car les ressources sont extrêmement limitées),
- des applications critiques (pour la santé, le nucléaire… car des vies sont en jeu),
- des jeux "AAA" (car il faut sortir la plus "belle" des images en moins de 10ms),
- du calcul scientifique (car les minutes d'utilisation de supercalculateur sont chères)

C'est aussi une culture, pour un tout jeune "développeur" web, la conso mémoire c'est un concept lointain, il sait tout au plus que sa page web va consommer 300Mo de mémoire vive dans Chrome et pour le CPU, il ne prendra "que" 10% d'un cœur de son Core i7…

Rappelons que stocker en mémoire une image brute (bitmap) 4k en 32bits, nécessite 32Mo.

Un "desktop" a peine booté qui consomme 1Go, cela n'a rien de normal même en 4k.
La crypto, la gestion de l'autonomie, l'usb ou n'importe qu'elle techno que vous allez trouver ne justifie pas cela.
Le poids des images vectorielles c'est peanuts par rapports à leurs équivalents bitmap.

La "gestion de l'autonomie", la crypto et le rendu vectoriel sont pris en charge matériellement depuis des années et au dernières nouvelles. Ce n'est pas le boulot de Gnome d'implémenter ces points et ils n'ont pas d'impact majeurs sur la consommation CPU.

Je ne vois pas pourquoi un gestionnaire de session comme gdm aurait besoin d'un bitamp 4k en permanence… mais bon, si cela vous fait plaisir de vous conforter dans l'idée que les développeurs de Gnome sont à la hauteur, pourquoi pas.

Que l'OS ne protège pas (par de la mitigation ultra sophistiquée) les applications mal codées n'en fait pas un OS non fiable ou non sécurisé.

Il a été conçu principalement pour le marché des systèmes embarqués industriels et médicaux, qui ont besoin de fiabilité et du temps réels.
Des systèmes fermés difficilement piratables car n’exécutent pas de code externe.
Comme le document de l'article l'explique, les processus sont complètements isolés et il ne peuvent pas planter le système. Et il n’intègre pas de blague comme le tueur aléatoire de processus de linux "en cas de besoin".

Les commentaires sur OSNews semblent aller dans ce sens aussi.

Bon après, c'est sûr que si tu lances gnome/gdm en root dessus, QNX ne ferra rien de magique :)

Mais n'étant pas non plus un fanboy de QNX, je ne chercherai pas d'arguments bidons pour excuser tout bug/faille de QNX (NDLR : comme d'autre l'ont fait avec gdm…). On ne peut que souhaiter qu'ils intègrent des mitigations plus poussées. Ainsi les billes qui lancent leurs applis buggées en root, pleines de failles exploitables à distance auront moins de chances d'engendrer des morts… si des hackers ont envie de pirater leur propres assistants respiratoires, c'est pas trop mon problème.

Les guillemets c'est pour les anglicismes ou les notions un peu "borderline" ou flous.

Depuis le début je parle de gdm , le "truc" qui consomme plus qu'un os complet optimisé…

Alors bon, ton excuse à base d'USB, de PCIe, etc.. tu ne dois pas ignorer que gdm ne gère pas ça.
Il n'a pas non plus besoin d'une machine qui doit afficher des jeux videos en 4k, etc..

Pour la sécurité, la fiabilité, concernant QNX, tu repasseras, il est utilisé dans un bon nombre de systèmes critiques et il a fait ses preuves. Il est codé en langage C (et non en langage "forceps"), tout comme gdm…

Comparer à 20 ans n'est pas ridicule, vu que les gestionnaires de sessions existaient déjà et que les "nouveaux" ne font pas grand chose en plus.

Pour en revenir à ce dernier, presque 20 ans de dev pour gdm :
- juste 3192 bugs
- 26 071 lignes de code C (1737 lignes pour les headers), avec 54 fichiers .c

Oui, on avait déjà un "desktop" utilisable sur des machines avec 1Mo de mémoire vive (sur Amiga par exemple)…

Gnome (dont gdm fait partie) a presque 20 ans.

Il n'était déjà brillant à ses débuts, si vous avez eu la chance d'utiliser les premières versions vous vous souvenez surement de la galère juste pour le compiler et le paramétrer.
L'épisode "OpenedHand" n'a juste réussi qu'à dégrader "l'expérience" sur desktop, au profit du "mobile".
Au final, on se retrouve avec, entre autre, un gestionnaire de session qui occupe en permanence des mégas octets de mémoire vive, et on se félicite d'avoir gagné quelques centaines de mégas octets.
C'est sur que quelques mégas octets, ça ne représente plus rien, c'est juste la taille d'une page web… A réfléchir comme cela, on se retrouve avec un ordinateur qui démarre en plus d'une minute, et qui a déjà bouffé 1Go de mémoire… un milliard d'octet, rien que ça.

Difficile, impossible, on a déjà la crème de développeurs chez Gnome?

En 1999, QNX a sorti une version de son OS (v4) avec leur noyau temps-réel, les drivers (graphiques et réseau), un desktop et un navigateur internet sur une disquette de 1.4 Mo. Elle est encore téléchargeable : http://toastytech.com/guis/qnxdemo.html

En 2002, ils récidivent avec un truc beaucoup plus léché (QNX RTP), la doc complète, les outils de développements (graphiques), un player audio, un navigateur rapide, etc… une ISO de 260Mo. Voir cet article de preview de la version 6.2 pour le détail et des captures d'écran.

Bref, la transition "wayland" a bon dos.

J’apprécie toujours les news du style "xxx Mio de mémoire vive libérés", ou encore celles que l'on trouve régulièrement sur les performances "xyz est désormais 3000x plus rapide".

Le touriste pourrait se dire que c'est une super nouvelle, que les développeurs sont sacrements bons, qu'ils ont bossés dur pour arriver à ce résultat spectaculaire.

La réalité est tristement moins joyeuse, s'il est possible de faire de telle "optimisation" c'est qu'à la base toute cette "suite" logicielle est codée par dessus la jambe.
On ne peut qu'en conclure que leurs développeurs sont sacrements mauvais, qu'ils ont bossés un peu pour corriger leurs erreurs afin d'arriver à se résultat peu spectaculaire (gdm qui consomme 100Mo).

Il n'y a pas si longtemps, on avait un "desktop" fonctionnel avec des machines de 128Mo de mémoire vive et moins de 400Mhz.

Le compilateur n'est pas encore assez intelligent pour optimiser les accès, il peut réorganiser "un peu" les structures de données.

Mais pour des cas "simples" comme celui : multiplication de matrice

for (i = 0; i < N; i++) {
    for (j = 0; j < N; j++) {
        for (k = 0; k < N; k++)
            res[i][j] += mat1[i][k]*mat2[k][j];
    }
}

il faut un bon outil pour voir/comprendre le problème et écrire la version optimisée.

Maîtriser les allocations (nombres et tailles) est une chose, mais les gains importants en performance résident surtout sur les accès.
Plus ils sont "distants" les uns des autres moins les caches matériels sont efficaces.
De mémoire, il y a un facteur 200 entre la latence au niveau du cache L1 et la mémoire vive.

J'espère qu'un jour on aura un outil pour aider à optimiser les accès.