Bah justement. Ce qui était vrai à une certaine époque ne s'applique plus vraiment de nos jours, ou alors pour des programmes vraiment triviaux : j'avais l'habitude de désassembler les binaires de mes tests en C, et plus ça va et moins ça ressemble…
Par ailleurs, quand je lis du D ou du Go, je retrouve les mêmes perspectives qu'en C : je vois (pour ma part) le même assembleur et mon algo est tout aussi proche de la machine. Si je dis ironiquement que c'est mieux, c'est parce-que ça me semble l'évolution naturelle du C (comme celui-ci l'a été pour le B —pour les personnes qui ont pris la peine de jeter un œil.)
Mais pas grave si tu ne veux pas le comprendre.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
j'avais l'habitude de désassembler les binaires de mes tests en C, et plus ça va et moins ça ressemble…
Désactive les optimisations du compilateur, et comme par magie ça redeviendra comme avant. Comme Linus le dit dans la vidéo, fut un temps les compilateurs devaient être simple. Ils sont maintenant très intelligent.
je vois (pour ma part) le même assembleur et mon algo est tout aussi proche de la machine
Bizarre venant de langage avec un runtime, un garbage collector, et tout plein d'autres features qui viennent modifier l'assembleur produit.
Si je dis ironiquement que c'est mieux, c'est parce-que ça me semble l'évolution naturelle du C
Si tu as regardé la vidéo, tu comprendre que le titre racoleur de ce lien n'est qu'une infime partie du message de Linus: I have yet to see a language that comes close to C in that respect.
En aucun cas il est dit que le C est le meilleur langage de tout les temps, tout usages confondus, toutes plateformes confondues, de manière purement objective.
Mais pas grave si tu ne veux pas le comprendre.
Oui, pas grave non plus si tu parles en lisant que le titre.
Désactive les optimisations du compilateur, et comme par magie ça redeviendra comme avant. Comme Linus le dit dans la vidéo, fut un temps les compilateurs devaient être simple. Ils sont maintenant très intelligent.
Nous disons la même chose : avant on pouvait se figurer le code assembleur généré ; aujourd'hui peu y arrivent (et en tout cas pas moi, même en désactivant les optimisations avec certains compilos) et ce n'est pas forcément une mauvaise chose (les compilateurs font du très bon boulot, et bien mieux que ce qu'on ferait à la main sans y passer une éternité.) Mon propos est que l'assertion selon laquelle écrire du C est transparent par rapport au binaire produit n'était vrai qu'avant (quand les compilateurs étaient simples) ou pour de rares êtres suprêmes…
Bizarre venant de langage avec un runtime, un garbage collector, et tout plein d'autres features qui viennent modifier l'assembleur produit.
Beaucoup font cette critique en n'étant pas au courant qu'on peut le désactiver https://dlang.org/spec/garbage.html
Mais je comparais surtout à code équivalent (sans utiliser les fonctionnalités ajoutés) pour dire que je lis (et traduit ou me représente mentalement les actions de bas niveau) de la même façon que pour le C. Je fais partir des gens qui s'amusent à réécrire leurs codes dans divers langages de plusieurs façon (au moins une naïve traduisant mot à mot le C ici, et une autre cherchant à utiliser les plus du langage au fur et à mesure que je gagne en maitrise dessus.)
Si tu as regardé la vidéo, tu comprendre que le titre racoleur de ce lien n'est qu'une infime partie du message de Linus: I have yet to see a language that comes close to C in that respect.
En aucun cas il est dit que le C est le meilleur langage de tout les temps, tout usages confondus, toutes plateformes confondues, de manière purement objective.
C'est justement parce-que j'ai écouté la vidéo (que j'ai quand même trouvé agaçant par moment) que ma réponse est tout aussi nuancée : j'ai utilisé un titre racoleur aussi, mais ai indiqué que mes propositions dépendent des usages tout en répondant aux points que j'ai retenu.
Tout le monde ne peut pas toujours dire amen.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Il est construit sur un modèle qui n'existe plus: un seul fil d'exécution, pas de mémoire cache, des instructions qui s'exécutent dans l'ordre ou elles sont présentes dans le programme, un ensemble de registres fixes. Aujourd'hui, un ordinateur ne fonctionne plus comme ça. Il y a plusieurs CPUs qui chacun peuvent exécuter plusieurs threads en parallèle, plusieurs niveaux de mémoire cache et de mémoire virtuelle, les instructions sont exécutées dans le désordre et même parfois exécutées avant d'être finalement annulées, et les registres visibles en assembleur n'existent pas vraiment, le processeur assigne ses registres internes dynamiquement en fonction des dépendances qu'il détecte entre les instructions.
Donc, non, le C n'est pas vraiment proche du comportement du matériel actuel. Il est proche du fonctionnement d'un ordinateur des années 70-80. Ça permet d'avoir un modèle simple à comprendre (mais approximatif) de ce qu'il se passe. Mais on pourrait prendre un autre modèle moins proche du PDP-11 et ça fonctionnerait bien aussi. Par exemple quand on programme en Smalltalk, on réfléchit en terme d'objets qui s'envoient des messages, et on peut très bien parler de performances dans ce contexte (combien d'objets sont créés/supprimés, combien de messages sont envoyés, etc). Ou par exemple si on fait du Haskell, on réfléchit en terme de fonctions, et les optimisations se font à un autre niveau (qu'est-ce qui peut être précalculé à la compilation?).
La difficulté de C++ (je prend cet exemple parce que je le connaît bien), c'est surtout qu'il y a plusieurs façons de penser qui sont mélangées dans un seul langage. À la fois c'est intéressant, parce que ça permet d'écrire du code à différent niveaux d'abstraction sans trop s'embêter. À la fois, on a vite fait de tomber dans un piège parce qu'on saute sans cesse d'une façon de penser à une autre (de la programmation objet, impérative, procédurale, ou même fonctionnelle).
Il a un garbage collector et les devs se sont pris la tête au début donc il y a eu plusieurs versions de la stdlib pendant un moment. En plus de ça il n'apporte aucune fonctionnalités modernes. Ce langage est mort né.
git is great because linus did it, mercurial is better because he didn't
Oui, il y a un ramasse-miettes qui n'est activé que dans des cas précis et peut être désactivé https://forum.dlang.org/thread/kpuujowqxgqudfujhzdu@forum.dlang.org
Pour les apports, c'est quand même multi-paradigmes (parallélisme, concurrence, fonctionnel, orienté objet, etc.) et a introduit un certain nombre de concepts qui ont été repris plus tard dans C++ (fermetures, fonctions anonymes, etc.) Après, oui, il a une restriction relative par rapport à C++ : un code légitime en C ANSI se comporte de la même façon en D.
Son seul (petit) inconvénient est de ne pas être 100% source compatible (le prix pour un peu plus de clarté et permettre l'ajout de fonctionnalités sans introduire d'ambiguïté.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Best comment ever
Posté par gUI (Mastodon) . Évalué à 10.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 26 novembre 2021 à 09:58.
Ce commentaire a été supprimé par l’équipe de modération.
# mine is better
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Si on ne cible qu'une seule plateforme, on peut faire directement de l'assembleur et c'est pas forcément plus compliqué…
Sinon il y a D qui est bien mieux et pas aussi complexe que C++ ! On peut préférer aussi Go ou Rust. Jdçjdr
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mine is better
Posté par David Delassus (site web personnel) . Évalué à 5.
Tiens donc, on a pas regardé la vidéo?
Ni D, ni C++, ni Go, ni Rust ne remplissent ces 3 critères en même temps.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: mine is better
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Bah justement. Ce qui était vrai à une certaine époque ne s'applique plus vraiment de nos jours, ou alors pour des programmes vraiment triviaux : j'avais l'habitude de désassembler les binaires de mes tests en C, et plus ça va et moins ça ressemble…
Par ailleurs, quand je lis du D ou du Go, je retrouve les mêmes perspectives qu'en C : je vois (pour ma part) le même assembleur et mon algo est tout aussi proche de la machine. Si je dis ironiquement que c'est mieux, c'est parce-que ça me semble l'évolution naturelle du C (comme celui-ci l'a été pour le B —pour les personnes qui ont pris la peine de jeter un œil.)
Mais pas grave si tu ne veux pas le comprendre.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mine is better
Posté par David Delassus (site web personnel) . Évalué à 3.
Désactive les optimisations du compilateur, et comme par magie ça redeviendra comme avant. Comme Linus le dit dans la vidéo, fut un temps les compilateurs devaient être simple. Ils sont maintenant très intelligent.
Bizarre venant de langage avec un runtime, un garbage collector, et tout plein d'autres features qui viennent modifier l'assembleur produit.
Si tu as regardé la vidéo, tu comprendre que le titre racoleur de ce lien n'est qu'une infime partie du message de Linus: I have yet to see a language that comes close to C in that respect.
En aucun cas il est dit que le C est le meilleur langage de tout les temps, tout usages confondus, toutes plateformes confondues, de manière purement objective.
Oui, pas grave non plus si tu parles en lisant que le titre.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: mine is better
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Nous disons la même chose : avant on pouvait se figurer le code assembleur généré ; aujourd'hui peu y arrivent (et en tout cas pas moi, même en désactivant les optimisations avec certains compilos) et ce n'est pas forcément une mauvaise chose (les compilateurs font du très bon boulot, et bien mieux que ce qu'on ferait à la main sans y passer une éternité.) Mon propos est que l'assertion selon laquelle écrire du C est transparent par rapport au binaire produit n'était vrai qu'avant (quand les compilateurs étaient simples) ou pour de rares êtres suprêmes…
Beaucoup font cette critique en n'étant pas au courant qu'on peut le désactiver https://dlang.org/spec/garbage.html
Mais je comparais surtout à code équivalent (sans utiliser les fonctionnalités ajoutés) pour dire que je lis (et traduit ou me représente mentalement les actions de bas niveau) de la même façon que pour le C. Je fais partir des gens qui s'amusent à réécrire leurs codes dans divers langages de plusieurs façon (au moins une naïve traduisant mot à mot le C ici, et une autre cherchant à utiliser les plus du langage au fur et à mesure que je gagne en maitrise dessus.)
C'est justement parce-que j'ai écouté la vidéo (que j'ai quand même trouvé agaçant par moment) que ma réponse est tout aussi nuancée : j'ai utilisé un titre racoleur aussi, mais ai indiqué que mes propositions dépendent des usages tout en répondant aux points que j'ai retenu.
Tout le monde ne peut pas toujours dire amen.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mine is better
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour retrouver le charme de l'assembleur: https://github.com/wiz-lang/wiz
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mine is better
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 novembre 2021 à 11:46.
Pas mal (je vais tester ça en décembre.) Très proche de C
;-)Ça va me changer de- hack https://github.com/easoncxz/hack-assembler
- LC-3 https://www.haverford.edu/computer-science/resources/hera
- MIXAL https://www-cs-faculty.stanford.edu/~knuth/mmix.html
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mine is better
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
C non plus ne remplit plus ces critères pour les ordinateurs modernes: https://queue.acm.org/detail.cfm?id=3212479
Il est construit sur un modèle qui n'existe plus: un seul fil d'exécution, pas de mémoire cache, des instructions qui s'exécutent dans l'ordre ou elles sont présentes dans le programme, un ensemble de registres fixes. Aujourd'hui, un ordinateur ne fonctionne plus comme ça. Il y a plusieurs CPUs qui chacun peuvent exécuter plusieurs threads en parallèle, plusieurs niveaux de mémoire cache et de mémoire virtuelle, les instructions sont exécutées dans le désordre et même parfois exécutées avant d'être finalement annulées, et les registres visibles en assembleur n'existent pas vraiment, le processeur assigne ses registres internes dynamiquement en fonction des dépendances qu'il détecte entre les instructions.
Donc, non, le C n'est pas vraiment proche du comportement du matériel actuel. Il est proche du fonctionnement d'un ordinateur des années 70-80. Ça permet d'avoir un modèle simple à comprendre (mais approximatif) de ce qu'il se passe. Mais on pourrait prendre un autre modèle moins proche du PDP-11 et ça fonctionnerait bien aussi. Par exemple quand on programme en Smalltalk, on réfléchit en terme d'objets qui s'envoient des messages, et on peut très bien parler de performances dans ce contexte (combien d'objets sont créés/supprimés, combien de messages sont envoyés, etc). Ou par exemple si on fait du Haskell, on réfléchit en terme de fonctions, et les optimisations se font à un autre niveau (qu'est-ce qui peut être précalculé à la compilation?).
La difficulté de C++ (je prend cet exemple parce que je le connaît bien), c'est surtout qu'il y a plusieurs façons de penser qui sont mélangées dans un seul langage. À la fois c'est intéressant, parce que ça permet d'écrire du code à différent niveaux d'abstraction sans trop s'embêter. À la fois, on a vite fait de tomber dans un piège parce qu'on saute sans cesse d'une façon de penser à une autre (de la programmation objet, impérative, procédurale, ou même fonctionnelle).
[^] # Re: mine is better
Posté par David Demelier (site web personnel) . Évalué à 2.
Il a un garbage collector et les devs se sont pris la tête au début donc il y a eu plusieurs versions de la stdlib pendant un moment. En plus de ça il n'apporte aucune fonctionnalités modernes. Ce langage est mort né.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: mine is better
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'aime bien cet article pour ne plus craindre le grand méchant GC : https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
Une autre approche de la gestion de la mémoire semiautomatique: https://ziglang.org/documentation/master/#Memory
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mine is better
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Oui, il y a un ramasse-miettes qui n'est activé que dans des cas précis et peut être désactivé https://forum.dlang.org/thread/kpuujowqxgqudfujhzdu@forum.dlang.org
Pour les apports, c'est quand même multi-paradigmes (parallélisme, concurrence, fonctionnel, orienté objet, etc.) et a introduit un certain nombre de concepts qui ont été repris plus tard dans C++ (fermetures, fonctions anonymes, etc.) Après, oui, il a une restriction relative par rapport à C++ : un code légitime en C ANSI se comporte de la même façon en D.
Son seul (petit) inconvénient est de ne pas être 100% source compatible (le prix pour un peu plus de clarté et permettre l'ajout de fonctionnalités sans introduire d'ambiguïté.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.