reno a écrit 3886 commentaires

Pour ce qui est de V, le blog que tu pointes date de 2019 et le langage a continué d'être développé depuis.. Donc vaporware est trop fort, survendu ça probablement.

Pour Julia, il me semble qu'il n'y a pas d'interpréteur? Pour un langage qui est pensé pour une utilisation REPL c'est surprenant.

Et aussi ils ont fait des grosses boulettes, en voila une:
-il disent qu'ils sont un langage générique
-leur tableaux commençant a l'index 1
-mais il y a une librairie qui permet de faire des tableaux avec des index de début arbitraire
-leur système de typage ne permet pas de différencier les 2 types de tableaux
--> il y a des librairies qui hardcode l'index commençant à 1 et ce qui veut dire qu'elles ne fonctionnent pas avec les tableaux avec index arbitraire :-(

Pour un langage dont le point fort supposé est la combinaison des librairies (Dispatch multiple) ça fait désordre..

Ça s'appelle foncer droit dans le mur et être surpris qu'on a des problèmes ensuite..
Ils auraient pas pu utiliser des tableaux avec des index de début arbitraire (à la Ada) dès le début plutôt que de reléguer ça à une librairie???

Je ne mettrai pas des langages avec GC: Crystal, Nim, dans la même catégorie que les langages avec gestion manuelle de la mémoire: Zig, V.

Enfin pour V je ne sais pas trop ce qu'il compte faire sa doc n'est pas terrible (enfin la fois ou j'avais regardé il y a longtemps).

Odin mériterai d'être ajouté à la liste: un C-like qui se focalise plus sur la programmation des jeux (enfin il n'est forcément restreint à ce sujet).

Salut,
Sur mon portable du bureau j'avais un comportement bien agaçant : l'ordinateur devenait très lent aléatoirement alors que le CPU n'était pas à 100%.

Un collège m'a suggéré de désactiver la carte graphique et ça a résolu le problème !

Mon hypothèse est que le système de refroidissement est devenu moins performant et que la chaleur émise par la CG faisait que le CPU se ralentissait..

Le maintien du frein en cote + le frein a main électrique c'est quand même un peu plantogène: vécu cette été, je suis en cote, je crois avoir activé le frein a main électrique d'ailleurs quand j'ai relâché la pédale de frein la voiture reste en place .. jusqu'à la désactivation du "maintien de frein"!

Et là quand j'ai senti la voiture reculer, ça m'a beaucoup surpris, et j'ai mis un peu de temps a réagir.
D'habitude je ne regarde pas spécialement car j'entends le frein a main faire son travail, sauf que la les ventilateurs tournaient a fond..

C'était clairement de ma faute, mais c'est un autre exemple comme quoi les fonctionnalités pour simplifier la vie peuvent être piégeuses.

Le problème principal de Google sur le C++ "normal" était lié a des problèmes de performance donc évidemment utiliser du Go qui est plus lent que le C++ n'aurait pas de sens.

Même si Go avait des perf similaire au C++, ils ont une base installée énorme de C++, donc ça fait plus de sens pour eux de "faire évoluer le C++" que de wrapper ça par du Go.

Remis en cause, remis en cause..
Je préfère 'affiner' : la théorie de Newton reste très utilisée car les calculs sont plus simple.

Pour montrer le progrès scientifique Asimov avait une très bonne image : le progrès de nos connaissances sur la terre: d'abord on l'imagine plate, puis sphérique, puis on se rend compte que l'équateur est un peu + grand, puis on mesure le relief de plus en plus précisément, le déplacement des continents, etc.

Aucune théorie n'est 'vraie' ce sont des approximations utiles de la réalité.

Pour ton exemple sur |> je suis d'accord que ça n'a pas d'intérêt dans un langage ou les opérateurs s'applique sur des valeurs, mais pas pour la même raison que toi:
x |> f serait une façon tout à fait acceptable d'écrire f(x), mais ça ne marche plus si on veut faire x |> f(y) a la place de f(x,y)..

---

Et je ne parle pas d'ajouter f(x y) au Lisp classique mais de remplacer (a b) par a(b) partout.
Donc defvar(a 42) défun(…) +(1 2)..

On peut très bien traduire mécaniquement l'un en l'autre, sauf '(x y) bien sûr qui n'est pas une S-expression.. ;-)

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..