reno a écrit 3879 commentaires

D’autre part, je trouve que ça correspond bien à la volonté de rendre toujours tout plus simple et plus clair

Sauf que plus simple visuellement != plus simple d'utilisation, c'est le problème majeur du flat, donc on en reviendra..

Pour un hobby? Python me parait bien adapté..

Et si je suis d'accord avec toi que Scala me parait mieux adapté pour programmer des gros programmes, comme premier langage Python a des avantages.

Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..

Explique alors que je préfère la lisibilité de la version Scala/Perl/Ruby et toi celle de la version Python/Rust?

La lisibilité est principalement subjective dans beaucoup de cas..

Comme je le disais, la lisibilité c'est subjectif, bien que n'utilisant pas Scala je trouve ça plus lisible que la version Python, alors?
Alors ça ne veut RIEN dire, la lisibilité c'est plus une question d'habitude qu'autre chose.

Par contre la maintenabilité ça c'est moins arbitraire, et je pense que mes arguments sur le manque de maintenabilité de {} en Python ou la verbosité des place holders obligatoires sont plus objectif.

Ça permet de passer toutes les variables dans un dictionnaire, sans forcément les connaître à l'avance.

Ce qui est rarement utile.. Rendre moins lisible et moins maintenable la syntaxe la plus utilisée pour une possibilité rarement utilisée, bof!

De plus, elle permet un formatage supplémentaire grâce aux indications (nombre de chiffres, remplissage avec des espaces, …).

Et alors? Avoir des formats strings lisibles n’empêche pas d'avoir des formatages supplémentaire..
En Scala, ça donne ça: println(f"$name%s is $height%2.2f meters tall")

J'ai l'impression qu'il y en a pas mal qui se disent, c'est comme ça que c'est fait en Python donc c'est forcément bien!
Désolé mais si la lisibilité est subjective, la maintenable ne l'est pas elle et
1) mettre les variables séparément des chaines ("foo {} faa {}",var1,var2) est moins maintenable que ("foo $var1 faa $var2")
2) en utilisant les places holders nommés tu peux récupérer la maintenabilité ("foo {u} faa {v}",u = var1, v = var2) MAIS c'est au prix d'une verbosité et d'une redondance supplémentaire par rapport à ("foo $var1 faa $var2") (si le nom des variable est trop moche pour mettre directement dans la format string c'est un problème entre la chaise et le clavier, pas un problème de langage).

Alors OK, les places holder nommés permettent quelques trucs supplémentaires utile dans 1% des cas, mais ça reste une syntaxe pas terrible pour le cas par défaut.

De mon point de vue, les concepteurs de Python ont merdé sur ce point là, ça arrive et après c'est difficile de changer donc ils sont coincés OK, mais que les dev de Rust copient Python sans améliorer la syntaxe par défaut là..

Puissante, puissante.. Ça se discute.
Je ne vois pas trop en quoi c'est plus puissant que l'équivalent en Scala (la même chose existe en Perl, Ruby):
tata="tutu"
"toto ${tata}"
mis à part que la syntaxe Python/Rust viole la règle DRY (ne pas se répéter)..

Si tu as une variable avec un nom bien clair alors "toto ${ma_variable}" est court et bien lisible mais la syntaxe Python/Rust impose d'ajouter un renommage supplémentaire même dans ce cas ("toto {foo}",foo=ma_variable)..

Tu peux expliquer/détailler par un exemple concret?
En Scala par exemple..

Ah? Ça ne me gène pas beaucoup personnellement..
Et les conséquences d'une faute d’orthographe me paraissent bien plus anecdotique que les conséquences d'un mauvais ordonnancement des variables, ce qui est très classique avec ce type de format string: modifier la chaine sans modifier la liste des variables en conséquence ou vice versa..

La plupart des langages?
Ça ne me parait pas un argument valide pour un nouveau langage, il devrait autant que possible reprendre le meilleur des langages existants!

Ah, j'imagine que certains trouvent la comparaison de Rust avec Perl ou Ruby biaisée car ces derniers sont interprétés, mais avec Scala la syntaxe est similaire..

Qui préfère lire
println!("texte {}", variable) ou println!("texte {v}, v = variable); (Rust)
a
println(s"texte $variable") ou println(s"texte ${variable}") (Scala)
?

Quand le nombre de variables augmente, je trouve la version Scala/Perl/Ruby bien plus lisible..

En fait la chaîne est passée à la fonction fmt qui ne connait bien sûr pas les variables déclarées,

Note que ce n'est pas une fonction, c'est une macro donc comme c'est a la compilation, je pense qu'on peut extraire le nom de la variable de la chaine et c'est le compilateur qui hurle plus tard si la variable n'est pas déclarée..
En D, un mixin doit pouvoir faire ça.

Pouvoir faire ça, ok ça peut être intéressant, mais ne pouvoir faire QUE ça, c'est ça qui me choque, pourquoi je ne peut pas faire println!("plop: {ma_variable}");
au lieu de devoir faire println!("plop: {u}", u = ma_variable);

Euh, il me semble que tout ce que tu dis, on peut le faire en Perl avec en plus l'avantage que tu as une syntaxe lisible pour les programmes tout simple ou tu n'as pas l'internationalisation..

De plus je ne vois pas l'avantage de faire printf!("{u}, u = v); par rapport à
my $u = $v;
print("$u");

et je trouve franchement dommage qu'un nouveau langage utilise une syntaxe si peu lisible..

L'équivalent de println!("{}", foo); ça serait en Perl print("$foo");
ou avec des {} si on veut clairement délimiter les variables du texte print("${foo}"); en Ruby pareil mais avec un # au lieu d'un $.

Dans les deux cas en Perl ou en Ruby, quand on lit le programme pas besoin de faire des aller-retour entre le texte et les variables contrairement à Rust ou au C: qui ne s'est jamais trompé en C dans ses chaine de formats en utilisant la mauvaise variable?
Pas moi!

En Rust, on peut faire  println!("{u}", u = foo);, c’est un peu moins moche mais je ne comprends pas l'intérêt par rapport à un (hypothétique) println!("{foo}"); ??

Il y a du concept, ça couvre la plupart de mes points bloquants avec la Fantasy…

Vu la liste de tes points, je t'invite a lire la série du trône de fer.
Enfin si tu as beaucoup de temps devant toi.. C'est tellement prenant que c'est très chronophage, genre tiens je vais lire jusqu'à 22h et à 2h du matin, bon il faut que j’arrête là!
Le seul inconvénient de lire cette saga, c'est que toutes les autres paraissent mièvres à coté..

Mmm, je t'ai plusser puis j'ai réfléchi: l’intérêt principal des conteneur est d'être 'autonome' ce qui évite les problèmes de compatibilités, mais à chaque fois que tu utilise la solution que tu décris, tu réintroduit le problème de compatibilité, non?

Ne vaudrait-il pas mieux automatiser la création de conteneur pour garder a la fois l'autonomie et une certaine 'facilité de mise à jour'?
Bon, réinstaller N conteneurs c'est moins simple qu'un seul, mais bon si c'est automatisé..

Desole pour le doublon.
Ce que je voulais dire: si la decoration de la fenetre est geree cote client, est ce que le compositeur sait qu'un clic a un endroit correspond a une iconification?

Avec Windows, c'est aussi quand tu iconifie une fenêtre.
Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..

Avec Windows, c'est aussi quand tu iconifie une fenêtre.
Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..

Je pense qu'il parle de fenetres en onglets, comme BeOS.
Sinon, franchement, les messages "cette application ne repond pas, voulez vous …" je connais sous Windows, je ne suis pas impatient de retrouver l'equivalent sous Linux, tout ca pour avoir des fenetres jolies quand on les déplace/déforme..

Dans Wayland, il y a une nette separation entre les clients et le serveur d'affichage/gestionnaire de fenetre/compositeur pour des raisons de sécurité et de performance.
Donc un dock est plutot censé faire partie du serveur, eventuellement par un plugin (Weston le permet).
Apres j'ai comme un doute que les dev de KDE ou Gnome considèrent comme prioritaire dimplementer des interfaces qui remplacent ce qu'ils font eux même..

Normalement, tous les compositeurs implémentant Wayland sont (ou seront) équivalents, c'est transparent pour l'application cliente.

Ouh la attention! Les compositeurs seront équivalent pour l'affichage des fenêtres mais par exemple Weston a une sortie RDP et il n'est pas du tout garanti que les autres compositeurs l'auront..

Pour le reste, les interfaces privilégiées dont tu parles, devraient être dans xdg-shell qui est en cours de développement.

C'est impressionnant comme durée de vie!
Je me demandes quel autres logiciels ont >30 ans et sont toujours utilisés..

Hum, je crois que la ba aussi, ça aurait pu se passer comme ça s'ils n'étaient pas tombés sur des gens intelligents..

En Ada (de mémoire) rien ne t’empêche d'avoir un pointeur entre 2 structure de durée de vie incompatible si tu gère la mémoire manuellement, en Rust il me semble que le système de type est là pour éviter les erreurs 'use after free'..

Ce qui a un coût lors de l'écriture du programme: il faut associer aux variables avec leur durée de vie, ceux qui se plaignaient qu'Ada c'était trop stricte, et bien Rust ça l'est encore plus!

T’inquiètes, on a Rust sur le feu pour éviter ce genre de soucis. :p

C'est vrai qu'un nouveau langage est nécessaire pour éviter les dépassement de tampon, Ada, OCaml, Java et autres ça n'existe pas..