Michaël a écrit 2935 commentaires

Ce n'est pas parceque tout le monde fait des erreurs qu'il ne faut pas les relever!

En lisant que la NASA utiliserait le système impérial, je suis tombé dix-sept fois de ma chaise puis j'ai utilisé mon moteur de recherche préféré pour vérifier:

In 2007 http://www.space.com/3332-nasa-finally-metric.html said:

NASA has ostensibly used the metric system since about 1990 […] but English units are still employed on some missions, and a few projects use both. NASA uses both English and metric aboard the International Space Station.

C'est l'utilisation du système impérial qui est anecdotique chez la NASA.

In 2009 http://www.newscientist.com/article/dn17350-nasa-criticised-for-sticking-to-imperial-units.html wrote:

NASA agreed to conform with US legislation enacted in 1988 that ordered all government departments to move towards the exclusive use of SI units.

Même si le changement semble mettre du temps, l'utilisation du SI doit devenir la norme aux US — pour le gouvernement et ses agences.

Le cas Linus s'apparente à du défouloir (ce qui n'est pas d'un grand niveau intellectuel mais passons)

C'est un (tout petit) peu plus que du défouloir, cela envoie un message très clair sur la nature de l'erreur commise — celle qui vaut les commentaires de Linus à son auteur: c'est une erreur grossière!

Ce n'est pas comme si il avait promis de le pendre à un croc de boucher! ☺

Linus assume son ton, et quand dans ta vidéo on lui demande si il est allé trop loin ou veut s'excuser, il s'explique et s'assume. C'est son caractère, ce n'est pas le mien — et à vrai dire, je ne suis pas super fan — mais chacun a son caractère et c'est comme ça, et je trouve que les gens qui sont à mes yeux exagérement froissés par ce genre de piques (humoristiques) n'ont pas plus raison que ceux qui jettent ces piques.

C'est le genre de personne qui s'étonne quand on leur dit qu'un code plus verbeux peut être bien plus rapide qu'un code plus court (moins de dépendance read after write).

C'est le genre de personne qui a écrit exactement ça dans le post auquel tu réponds, non?

Non. C'est géré.

Ok, au temps pour moi.

C'est très loin d'être mon impression en lisant le lien […]

Et bien merci pour cette correction, j'étais complètement passé à côté de cet article de Chris Lomont!

Je veux dire sur du vrai code de la vrai vie. Tu te rend compte de la taille de code qui rentre dans un cache L1 ? On parle de boucle interne, pour remplir les 16/32/64 Ko de cache L1, il faut sans doute, l'équivalent d'un millier de lignes de code.

Le point clef est l'alignement plutôt que la taille. Changer le code en déroulant change l'alignement de façon non maîtrisée, on peut donc se retrouver dans des situations où le code non déroulé est mieux aligné que le code déroulé ce qui le rend plus rapide.

Oui et sur un code moyen, cela ne change rien.

Cela change l'alignement.

Tu parles de Ocaml,

Oui, on parle de OCaml dans ce fil, non?

en mathématiques, on approche les fonctions trigonométriques par des polynômes (on approche tout par des polynome d'ailleurs)

C'est assez loin d'être vrai, même pour les fonctions réelles sur un intervalle compact. Tout dépend de ce qu'on veut démontrer.

Le travail mathématique, […]

Étant mathématicien je sais assez bien ce qu'est le travail mathématique et je ne vois toujours pas ce qui te permet de tracer une ligne claire entre mathématiques et calcul numérique.

Après, les mathématiciens peuvent évidemment utiliser eux-mêmes des méthodes numériques dans leur boulot, mais ça ne donne pas magiquement une dimension mathématique à un algorithme…

Les méthodes numériques sont pourtant sujettes à des raisonnements mathématiques! Et il y a même des mathématiciens qui s'y intéressent beaucoup.

Un peu ennuyant ce comique de répétition.

De toutes façons un serveur, ça tourne sous BSD, non?

Comme on l'a dit plus haut, le code est destiné à être lu par un compilateur mais surtout par des programmeurs: pour apprécier les qualités ou les défauts du dit code, il faut donc tenir compte de son public de lecture.

Si le public est formé de développeurs généralistes, tout le monde est d'accord pour dire que le snippet en question est tout pourri. On peut cependant imaginer qu'un labo de numériciens a une culture et un folklore complètement différent, qui modifie complètement les besoins qu'ils peuvent avoir en termes de commentaires ou de références à des articles publiés — ou autres documents du même genre.

Pour en revenir au bout de code en question, des recherches archéolgiques te donnent raison: personne ne semble vraiment capable d'expliquer en détails comment marche la fonction!

C'est souvent un argument mis en avant contre l'inlining, qui s'avère faux chaque fois que j'en fais l'essaie.

D'autres personnes ont des expériences différentes, apparemment.

Oui, mais dont on se fout un peu sur nos machines de bureau tant que le binaire n'a pas fait x10 ou x100.

Pas forcément, il vaut mieux avoir un boucle for non déroulée qui tient dans le cache L1 qu'une boucle déroulée qui n'y tient pas.

C'est une chose qu'on contrôle très mal à l'échelle d'un programme, parceque passer d'un modèle à l'autre (folded/unfolded) change de façon imprévisible la façon dont le code est saucissonné en morceaux de pages de cache.

Le comportement normal du compilateur est l'optimisation pour la taille, mais on peut le configurer pour qu'il fasse autre chose.

C'est un peu approximatif! OCaml fait de l'inlining inter-module — des fois il faut motiver le compilateur en ajustant son “agressivité” — et cela me suprprend un peu de voir qu'il ne fait pas du unfolding de boucles — mais peut-être qu'il faut motiver un peu le compilateur en stimulant son agressivité.

Si je me souviens bien, le compilateur optimise la taille du programme plutôt que la “vitesse” et je mets des guillemets sur “vitesse” parceque l'inlining et l'unfolding ne sont que spéculativement des optimisation en vitesse, qui sont parfois contredites par l'expérience. L'optimisation en taille est en revanche faite face à un critère complètement objectif.

À mes yeux, dès qu'on passe dans le domaine de l'approximation, on sort des mathématiques, c'est à dire de la représentation symbolique, pour passer dans l'imperfection du monde réel.

Faire des approximations c'est l'activité principale de tous les mathéamticiens qui font de l'analyse ou de la géométrie (même algébrique). À part ça, tout va bien!

On a le droit de ne pas aimer le calcul numérique, mais pas de le dire comme ça!

Mais est-il vraiment à jeter pour autant ? N'est-ce pas là tout simplement le prix à payer pour avoir à la fois puissance et abstraction ?

Oui, non. C'est mon avis, et devnewton s'intéresse à l'avis des gens… ☺

Les pointeurs purs non plus n'ont pas d'information de propriétés, non ?

Quand on passe une référence, inutile de préciser (dans la documentation, p.ex.) qu'on reste propriétaire de l'objet. C'est ce que je veux dire. Les pointeurs eux, ne disent rien sur la propriété mais je parle des références.

On peut parfaitement delete l'adresse d'une référence crée depuis un objet allouée sur le tas si ça nous amuse. Puisqu'au fond c'est un pointeur pur déguisé.

On peut faire delete sur un pointeur et pas sur une référence: c'est une fonctionnalité du pointeur qui n'est pas autorisée par une référence. Et si on prend un pointeur sur l'objet référencé par une référence, et bien on travaille avec un pointeur et plus avec une référence.

D'ailleurs, j'ai même le droit de delete un objet alloué sur la pile.

Ça, certainement pas, ça sent l'UB à plein nez. À moins que je n'aie pas compris ce à quoi tu fais allusion.

Un pointeur indique un emplacement mémoire. Il peut être nul (nullptr). Une référence indique un objet. Elle ne peut pas être nulle.

Mais ce n'est pas du tout la différence entre un pointeur et une référence — en dépit de la litanie lénifiante qu'on peut lire à beaucoup d'endroits. Comme tu le dis plus bas on peut maladroitement — mais de façon complètement anodine — passer un référence nulle. En réalité la seule véritable différence de fonctionnalité entre un pointeur et une référence c'est que le pointeur permet de déconstruire l'objet et pas la référence.

Autrement dit les références implémentent les pointeurs sans transfert de propriété — le propriétaire est responsable de la libération de mémoire. Et les rapprocher d'un outil de gestion comme les smart pointers n'a rien de farfelu.

Dans le fond, ce que tu reproches à C++, c'est de ne pas assez restreindre le développeur, c'est ça ?

Pas du tout. Ce que je reproche à C++ est d'être un langage complètement byzantin, absolument illisible, et où il y a 36 réponses à chaque problème d'organisation qu'on se pose — et aucun des choix de réponse qu'on fait n'est anodin et les interdépendances et incompatibilités entre ces choix n'apparaissent souvent que lorsqu'on a écrit une quantité substantielle de code.

[…]

Pour en revenir à la discussion, mon message à DevNewton est que les problèmes d'ingénierie logicielle posés par C++ sont plus difficiles que dans beaucoup d'autres langages. Une façon de commencer à les résoudre est de faire, comme tu les suggères, du C with classes mais ce n'est pas forcément la plus intéressante.

C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les const sont au bons endroits.

Oui c'est exactement comme ça que ça marche. Quand on parle de blague! Au passage, le bon sens c'est la dialectique typique des gens qui n'ont pas d'argument, comme nous l'a rappelé à souhait un de nos précédents gouvernements, c'est donc une expression à éviter invariablement si on veut être pris au sérieux.

Exemple au hasard: si je décide de mettre une référence constante dans une object, et bien je ne peux plus utiliser le classique clone & swap pour implémenter l'assignement, ce qui oblige à dupliquer une bonne partie du clonage et de l'assignement. Le bon sens ici ne suffit pas.

Autre exemple: dans la vraie vie on travaille avec des APIs toutes pourries qui ne connaissent pas const et penser une interface vaguement propre ne se fait pas sur un coin de table de bar avec un peu de bon sens.

Pour avoir travaillé sur une importante base de code C++ développée avec “le bon sens” j'ai une expérience qui dit que ça se passe plutôt mal.

Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.

Si tu as des choses utiles à dire — du type, une affirmation positive — ne t'en prive pas, on est toujours content d'apprendre quelque chose.

C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment.

Effectivement. Mais il ne faut pas oublier que dans la vie de beaucoup de développeurs contemporains C++11 c'est de la science-fiction, ne parlons pas de C++14.

Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.

Tu t'appuies tes arguments sur le bon sens et ensuite tu exagères les propos de tes contradicteurs pour les contredire par le ridicule. Merci pour tes contributions inestimables à la qualité du débat sur LinuxFR.

C++ a d'immenses problèmes, qui sont essentiellement liés à la présence dans le langage de technologies ou méthodes concurrentes et à tous les outils de code obfuscation dont il dispose.

• Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.

• Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.

• Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut const nécessite de préparer une vraie stratégie de développement.

• Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!

J'abrège un peu parce que c'est Samedi: C++ est utilisable si

• On a une grosse équipe avec deux “seniors” et un architecte compétents pour la diriger.
• On écrit un compilateur dont le backend est C++.

Dans tous les autres cas, s'abstenir.

J'ai travaillé plusieurs années sous VisualStudio 2008 sur un très gros projet — appli industrielle de gestion de risque financier — en C++ et je dois dire que le débogueur visuel est excellent — à ceci près que notre version n'incluait pas de fonction trace, mais les fonctions offertes sont très bonnes. Il a toujours fonctionné de façon à peu près correcte — ce qui sur une codebase pré-STL de plus de 30 ans, qui sert accessoirement de vitrine à toutes les mauvaises pratiques de programmation imaginables, est un succès non-négligeable.

Le problème de la boîte est qu'il était utilisé en guise de documentation technique — c'est à dire, pour comprendre l'organisation du code, la seule ressource était de faire du pas à pas! :)

C'est triste ton avis sur les motardes.

Elle peut utiliser sysV à condition d'avoir écrit un port en Elisp de systemd, qui permettrait à Emacs de devenir un composant proche du noyau indispensable à tout système GNU/Linux ou DebianBSD.

Un beau jour d'automne, http://boycottsystemd.org/ prit sa plume et écrivit:

As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7.

Apparemment ils ne sont pas d'accord avec toi—mais je ne suis pas allé vérifier!

Personnellement je trouve douteux la démarche de vouloir un système d'init portable qui est par essence un composant proche du noyau et ne pouvant exploiter ses spécificités s'il est trop portable.

Je suis assez de ton avis, mais voir que des programmes comme gdm ou gnome-shell dépendent de systemd montre — ou plutôt donne à penser que — que systemd n'est pas juste un système d'init. C'est l'argument que développent ceux de Boycott systemd, texte que j'ai lu avec intérêt — bien que j'utilise XFCE sous FreeBSD, c'est dire si ça me touche! — du moins, au premier degré!

Un des très gros avantages de systemd, ce sont les cgroups. Du coup, sous d'autres kernel, ça perd beaucoup d'intérêt.

Ton commentaire montre que systemd perd beaucoup de son intérêt en lui-même sur les systèmes qui n'ont pas de cgroups. Mais des logiciels ajoutent systemd dans leurs dépendances dures — Gnome, paraît-il — parceque systemd aurait phagocyté udev et qu'ils dépendaient de udev, ce qui rend tous ces logiciels non portables.

Il y a donc un intérêt à avoir un systemd portable.

Unicode sera quasi-toujours implémenté en UTF-8 au niveau du shell (pour la compatibilité avec l'ASCII)

Ce qui sert justement à pouvoir en partie traiter un document Unicode avec des programmes ne supportant pas Unicode.

pour le reste, il y a toujours la commande standard iconv

La commande iconv sert à faire de la transcription tandis qu'une bibliothèque Unicode permet de:

1. Analyser les catégories de caractères
2. Analyser d'autres types d'attributs
3. Travailler avec des expressions rationnelles ou écrire des lexers Unicode
4. Compter correctement le nombre de caractères dans un texte
5. Faire du transcodage
6. …

Tu vois bien que iconv fait quand même beaucoup moins qu'une vraie bibliothèque Unicode.

Dans mon commentaire, je dis que awk montre ses limites quand on a besoin de Unicode et tu réponds que ce n'est pas le cas parcequ'on a en pratique pas très souvent d'Unicode: c'est une réponse à côté de la plaque!

Et c'est opportun pour faire de l'IO, surprise surprise. Pour une question sur SO j'ai fait une petite comparaison en OCaml entre un style d'output impératif traditionnel et le style en monades: conclusion le style impératif est plus rapide.

Si je trouve Haskell si difficile à lire c'est qu'on peut définir des macros qui ont apparemment plein de pouvoir magiques, notamment à réécrire les do… en choses moins inoffensives qu'elles n'en ont l'air.