reno a écrit 3879 commentaires

Pas sur de comprendre ou est la confusion dans f(x g(y z) w)?
y et z sont les arguments de g
x, le resultat de g(y z) et w sont les arguments de f.

Dites les critiques, vous êtes sûrs que vous ne réagissez pas de manière un peu 'instinctive'?
Si le Lisp fait comme ça c'est 'forcément' bien?

f(x y …) est + proche de la notation mathématique classique que (f x y …),
mais pour moi l'intérêt principal est que ça montre bien la différence entre le premier argument et les autres:
dans (+ 1 2) on note bien que + est traité différemment de 1 et 2..

Le Lisp classique a d'ailleurs '(x y) pour l'abréviation de (quote x y)..
Avec ma(*) notation 'préfix' pas besoin d'abréviation c'est quote(x y) ou '(x y) normalement, comme quoi c'est une notation encore plus homoiconique que le Lisp!

*: je ne suis pas le seul a avoir eu l'idée, il y en a au moins un autre mais je n'ai plus le lien..

Sinon avec son GC Lisp est memory-safe donc je ne vois pas trop où est l'avantage de Rust ici..

Personellement j'ai toujours trouvé dommage que le lisp soit '(fonction arg1 arg2 …)' un simple changement 'fonction(arg1 arg2 …)' aurait été un bon compromis.

ça n'est pas vrai, un char* terminé par un '\0' ça ne s'appelle peut être pas une string en C mais les librairie la traite comme en étant une.
A l'époque des mémoires minuscules, c'était une bonne structure de donnée pour une chaine, mais ça n'est plus le cas depuis longtemps et pourtant le "C" (le langage mais surtout la librairie standard) n'a pas réussi a évoluer..

Tout les autres langages sont passés a une paire de pointeur ou a entier+pointeur pour les chaines, n'ajoutant le '\0' a la fin que si nécessaire pour la compatibilité avec le C, il doit y avoir une raison..

Et strlen en temps constant pour un cout mémoire ultra-faible est une très bonne raison!

Un algorithme de complexité quadatrique O(n2), l'explication classique toute simple est le gars qui peint une bande routière en laissant le seau de peinture au début de la route: le premier jour il va vite, mais au fur et à mesure il va aller beaucoup moins vite forcément..

Chaînes terminées par des zéros == attention aux algorithme quadratiques!

Quelques exemples ?

Le + célèbre: https://news.ycombinator.com/item?id=26296339

D'un point de vue + générique les algorithmes quadratiques sont très 'vicieux': assez rapide sur un petit jeu de donnée utilisé pour les tests unitaires mais en production ça peut déraper vite.
Il y a même un site web sur le sujet: https://accidentallyquadratic.tumblr.com/

2 languages au lieu d'un: le preprocesseur et le normal..

Et en quoi est-ce un défaut ?

Complexité additionnelle non nécessaire: d'autre langages tel que D, Zig, Jai utilisent le même langage au runtime et a la compilation (permettant entre autre la compilation conditionnelle bien sûr) avec juste un mot clef pour indiquer que le code correspondant doit être évalué a la compilation (comptime en Zig, je ne me souviens plus pour les autres).

Cast non-greppable..

Mmmmm, là, il faut que je creuse un peu, mais ça ne m'a jamais posé de souci.

Et bien tu as + de chance que moi.. Un 'XXX_cast' a la C++ ou ' as ' comme Rust(je crois) c'est beaucoup plus facile a chercher qu'une paire de parenthèse et comme un mauvais cast peut créer des tas de problèmes bien difficile a résoudre, ça n'est pas un détail!

J'ai commencé le C en 1992, j'apprécie ses points forts par rapport a d'autre langage, mais c'est un langage quasi-statique qui n'a jamais pu se débarrasser de ses nombreux problèmes..
Dommage qu'il n'ai pas pu évoluer (enfin après quand on voit le b… de l'évolution du C++..).

Je préfère le C au C++ pour ce qui est du temps réel (le C++ 'cache' trop de choses) mais ça ne veut pas dire que j'aime le C..

Conversion implicite stupides.. Chaînes terminées par des zéros == attention aux algorithme quadratiques!
2 languages au lieu d'un: le preprocesseur et le normal..
Cast non-greppable..
Trop d'UB qui ne servent à rien: par exemple l'ordre d'évaluation des paramètres d'une fonction..
Etc.

Après Ada existe depuis longtemps sans avoir percé pour autant.. Il commence à y avoir d'autres nouvelles alternatives (DasBetterC, Zig, V, Odin..) mais leur nombre peut aussi créer un problème pour remplacer le C..

A la réflexion, je me dis que ça pourrait quand même être amélioré, Frink te donne l'interval a la fin des calculs: https://futureboy.us/frinkdocs/#IntervalArithmetic

Je ne me souvenais pas qu'Ada supportait les intervalles arithmétiques pour faire des calcul avec des "vrais" nombre réels, quelqu'un sait si GNAT supporte ça?

Comme l'effet du vaccins s'affaiblit avec le temps, j'aurais plutôt tendance a vouloir me faire vacciner tout les 5 mois plutôt que d'hésiter a me refaire vacciner.

Chez nous bien qu'on ai été triplement vaccinés, on a eu le Covid quand même mais avec des symptomes assez faible..

Merci pour ta réponse, effectivement j'avais oublié cette limitation en longueur des ARM SVE.

moins contaminant = pas contaminant ?

Non: https://arstechnica.com/science/2021/07/cdc-mask-reversal-vaccinated-should-wear-masks-in-many-settings-amid-surge/

Moins de flexibilité SVE/SVE2?
Peut être mais lors d'un article qui comparait les 2 ( https://erik-engheim.medium.com/arm-vs-risc-v-vector-extensions-992f201f402f ) le code ARM était plus court, ce que j'interprète comme "potentiellement plus efficace"..

Hum, j'adore le télétravail mais pour ce qui est du bruit .. mettons que je hais cordialement l'inventeur du souffleur a feuille!

Le 'poids' aussi, c'est difficile a croire aujourd'hui mais à une époque Emacs était considéré comme un éditeureur 'lourd' (eight megabytes and constantly swapping) et ce n'est pas un mythe ou une méchanceté 'gratuite': quand j'étais en thèse une bonne façon de décoller quelqu'un de sa machine était de se connecter sur sa machine et de lancer emacs: le gars ne pouvait plus rien faire pendant un petit moment donc il venait manger..
Donc a cette époque là forcément vi était partout mais pas emacs et c'est resté..

Sur des petits programmes ça n'a pas d'intérêt, sur des gros tôt ou tard il y aura cette erreur..

Rien que le nom fait peur..

Je ne parlais de la vérification du range de l'index mais du type de l'index: si tu as un tableau indexé par un nombre de Choux, le compilateur ne te laisse pas l'indexer par un nombre de Carottes.
En C++, tout est indexé par des entiers, pareil en Rust je crois mais en Ada tu peux choisir simplement un type fort comme Index.

Il y a les effets de mode qui expliquent pourquoi Ada est si peu utilisé (même ses concepts comme les tableaux qui vérifie le type fe l'index ne sont pas repris par d'autres langages :-( ).

Mais il y a aussi que certaines choses courante dans d'autres langages comme les string de taille variable, en Ada ça pique les yeux, ça n'aide pas..

J'utilise principalement VSCode+grep pour travailler.

Pourquoi VSCode? Parce qu'il démarre assez rapidement et que la navigation entre ~20 fichiers est assez bonne la "plupart" du temps.

Pourquoi grep? Car souvent l'indexation de VSCode est pourrie (en C++): incapable de trouver un fichier sous un #include, ou il met + de temps que grep pour me trouver la définition d'une fonction(!) ou pire il me donne la mauvaise définition d'une fonction (dans le mauvais working tree).

Mais j'étais resté confiant en l'indexation de CLion (que je n'utilise pas car trop lent), sauf que cette semaine en faisant un find usage d'une méthode j'ai découvert que CLion avait manqué l'appel a la méthode a certains endroits..

Ma conclusion : un bon éditeur de texte plus grep/ag/ripgrep >> aux IDE pour les gros projets C++

Dommage que je n'ai pas le temps d'apprendre a configurer correctement VSCode pour qu'il appelle grep ou find pour moi, plutôt que de le faire moi même dans un terminal et de lui dire ensuite d'ouvrir le fichier que j'ai trouvé (ce qui est totalement absurde quand on y réfléchit bien)

Bon j'avoue ne pas vraiment comprendre l'analyse des performances sous Linux, il y a perf, SystemTap, bpftrace, ça fait beaucoup..

Mais pour ceux qui comprennent mieux, LWN vient de faire un article sur le sujet: Comparing SystemTap and bpftrace: je me permets d'envoyer un subscriber link (à ne pas diffuser inconsidérément merci):
https://lwn.net/SubscriberLink/852112/8a228aa8184dabc9/

Windows utilise \ comme séparateur de chemin car ils avaient peur de se prendre un procès s'ils réutilisaient /

SDL kezako?

Bah à peine GTK4 sorti qu'ils planifie GTK5 (cf le lien du dessous), qu'ils planifient GTK4.1 ça serait normal mais GTK5 .. ça montre bien qu'ils n'en 9nt rien a faire de la compatibilité..

Dommage que les dev d'Haiku ont préféré faire joujou avec leur propre noyau plutôt que d'utiliser Linux comme base car au contraire leur force a eux c'est la stabilité au niveau API..

Y a-t-il un desktop sur Linux qui vise la stabilité (retrocompatibilité) au niveau API?

Sur le long terme, ça pourrait être une stratégie gagnante..