Vous parlez beaucoup de la beauté du code, d’une esthétique du code. Comment expliquer à quelqu’un qui n’a jamais codé, à quoi peut ressembler un beau code ?
"Il faut de la simplicité – un beau code est aussi simple que possible – mais aussi de l’expressivité. Car en un sens, on n’écrit pas le code pour sa machine, mais pour les autres programmeurs, qui liront votre code après vous. Certains codes ont une vie très longue : quelqu’un essaiera peut-être de comprendre dans vingt ans ce que vous avez essayé de faire.
Et donc, quand vous écrivez du code, vous essayez de le rendre le plus clair possible. Il doit être clair d’une ligne sur l’autre, mais aussi de façon globale : son architecture doit être limpide. Chaque concept doit avoir une fonction définie et les relations entre les différentes couches du programme doivent être évidentes. Alors le code devient très beau.
Et si quand un problème survient, on peut isoler une des parties du code sans devoir toucher à tout le reste, c’est le plus beau. Si, quand vous touchez quelque chose, tout le reste du code se met à vibrer de partout, alors vous savez que c’est vraiment laid."
http://rue89.nouvelobs.com/2014/09/27/geek-sublime-code-cest-emotionnel-254952
# le goût et les couleurs
Posté par serge_sans_paille (site web personnel) . Évalué à 7.
Cette phrase a fait resurgir en moi des souvenirs de thèse que j'aurais aimé oublier :-)
Je trouve que
s/beau/maintenable/serait plus exact, on peut trouver certaines constructions élégantes alors qu'elles ne sont pas pour autant maintenables…[^] # Re: le goût et les couleurs
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 4.
Si c'est pas maintenable, alors c'est laid, je ne vois pas comment cela pourrait être autrement. Ce que tu appelles élégant, ça doit plutôt s'appeler la feinte du corbeau à 5 becs, c'est malin, c'est rusé, c'est ce que tu veux mais c'est pas beau.
Beau devrait certainement être un mélange de maintenable, donc facile à lire, le moins verbeux possible et le plus rapide possible.
[^] # Re: le goût et les couleurs
Posté par serge_sans_paille (site web personnel) . Évalué à 2.
Un peu d'ouverture d'esprit, je te prie.
Une pâquerette, certains trouvent ça beau, d'autres trouvent ça moche. Rien à voir avec des critères objectifs. Allez je vais te citer un extrait de http://rue89.nouvelobs.com/2014/09/27/geek-sublime-code-cest-emotionnel-254952
[^] # Re: le goût et les couleurs
Posté par barmic . Évalué à 3.
Hors du fait qu'un développeur est ou non un artiste, qu'est-ce qui fait que quelqu'un mérite ou pas de se revendiquer artiste ?
Pour ce qui est des codeurs :
Quel est l'apport de se considérer comme un artiste ? Est-ce qu'ils sont reconnus socialement comme des artistes ?
La technique est-elle toujours décorrélé de l'artistique ? Les gens qui font des effets spéciaux, les développeurs de jeux vidéos, ceux qui créent des jeux, les prestidigitateurs, les gens qui faisaient des automates ne sont-ils pas des artistes ?
La beauté du code permet de donner un objectif de qualité qui est tellement compliqué qu'on arrive pas à le définir, n'est-ce pas là le propre de la beauté artistique (on peut facilement dire pourquoi quelque chose est beau ou ne l'est pas, mais décrire de manière factuel comment obtenir quelque chose de beau est une autre paire de manche) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le goût et les couleurs
Posté par deuzene (site web personnel) . Évalué à 7.
Je dirais plutôt que ce sont des artisans : ils maîtrisent une, ou plusieurs, techniques, pour créer des objets qui correspondent à certains canons de la beauté.
Les artistes ne produisent pas du beau, mais du sens.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: le goût et les couleurs
Posté par Moonz . Évalué à 9.
Précisément, la frontière artisan/artiste est assez floue.
[^] # Re: le goût et les couleurs
Posté par barmic . Évalué à 2.
Mais encore ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le goût et les couleurs
Posté par zebra3 . Évalué à 10.
Par là : →
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: le goût et les couleurs
Posté par CHP . Évalué à 0.
Je dirais plutôt qu'ils produisent (sont censés produire) de l’émotion.
[^] # Re: le goût et les couleurs
Posté par Antoine . Évalué à 10.
Oh, non. Pour de l'émotion, un chaton qui meurt sous tes yeux suffit largement.
[^] # Re: le goût et les couleurs
Posté par kowalsky . Évalué à 3.
Méchant, tu m'a fais pleurer !
[^] # Re: le goût et les couleurs
Posté par Letho . Évalué à 3. Dernière modification le 29 septembre 2014 à 18:01.
Le philosophe et le mathématicien seraient donc des artistes ?
[^] # Re: le goût et les couleurs
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 29 septembre 2014 à 18:49.
Faux: les artistes disent produire du sens. Mais souvent ça n'a aucun sens, et c'est juste de la branlette.
Il y a aussi beaucoup de personnes qui se disent artistes mais ne sont pas plus artistes qu'un gamain de 2 ans.
Bref, de quel droit dis-tu qu'une personne est artiste ou pas, suivant quels critères, des vrais, hein, pas un "du sens" parce que bon, un codeur produit aussi du sens?
Tiens, cette définition marche avec 99% des gens qui se disent artistes…
Socialement, on a de tout et n'importe quoi (un truc hyper moche va être considéré comme une "oeuvre", jsute parce que la personne a trouvé un mécène qui va bien), des gens sont morts puis on a trouvé qu'ils sont artistes, ça n'est pas vraiment un critère. Les codeurs sont les artistes qui seront reconnus comme tels dans 100 ans, comme d'autres personnes sont des "références de l'art" des dizaines d'années après leur mort (et avant, c'était juste des nuls dont on se foutait).
[^] # Re: le goût et les couleurs
Posté par Antoine . Évalué à 10.
Conclusion : Zenitram est un artiste (et le post auquel je réponds le prouve).
[^] # Re: le goût et les couleurs
Posté par pasBill pasGates . Évalué à 9.
On est tous un peu artiste quelque part…
[^] # Re: le goût et les couleurs
Posté par gnx . Évalué à 4.
Plutôt :
On est tous un peu autiste quelque part…
[^] # Re: le goût et les couleurs
Posté par gst . Évalué à 2.
et pour pas se la jouer solo:
On est tous un peu l'autiste de quelqu'un d'autre quelque part.
g-ni :*P
[^] # Re: le goût et les couleurs
Posté par fabien . Évalué à 2.
Oulala, ce n'est pas si evident que celà.
Le "beau" est-il universel? Je pense (avec certains philosophes) que le beau n'est pas universel, et qu'il s'agit plutôt d'un concept essentiellement culturel et sociologique. (en gros, tu prends un type que t'aurai trouvé d'une tribue recement decouverte, tu le met devant mona lisa ou la tour effel, il va pas trouver celà plus "beau" que le resto macdo d'a coté)
Oui… je sais, ca n'a rien avoir avec le sujet, c'est juste pour dire :)
[^] # Re: le goût et les couleurs
Posté par lancelotsix . Évalué à 3.
Tu parles de ça ?
# Ceci n'est pas un troll.
Posté par Lutin . Évalué à 4.
Lors d'une formation SCRUM on m'a expliqué qu'il était important de faire du code bien crade pour que ça nous fasse plaisir de tout démolir lorsqu'il faut rajouter une fonctionnalité (le mec était spécialiste .NET).
Le beau code, c'est très surfait.
[^] # Re: Ceci n'est pas un troll.
Posté par Patrick Nicolas . Évalué à 4.
Merci à ceux qui appliquent ces principes, ça fait une semaine que je dois retracer ce que fait un fichier de 3000 lignes. Ça me fera très plaisir de le supprimer et faire la même chose en 2 ou 3 modules bien segmentés.
[^] # Re: Ceci n'est pas un troll.
Posté par CrEv (site web personnel) . Évalué à 4.
hum, 3000 lignes c'est rien du tout hein :-)
Je connais des softs dont 1 méthode dépasse déjà plusieurs centaines de lignes et où les tailles de fichiers sont à 5 chiffres…
[^] # Re: Ceci n'est pas un troll.
Posté par Le Gab . Évalué à 1.
Si c'est du Java, ça ne compte pas. Quel est réellement la taille du code effectif. :)
[^] # Re: Ceci n'est pas un troll.
Posté par Philippe F (site web personnel) . Évalué à 4.
Vim ? Un demi-mega octet pour le fichier eval.c . J'arrive plus à retrouver des mega-fonctions mais il y en a pléthore !
# Plutôt beauté du design
Posté par RB . Évalué à 10.
C'est un peu exagéré de parler de beauté du code comme un objectif.
En effet, parfois on tombe sur des morceaux de code magnifiques: une astuce qui utilise le language en dehors de l'usage courant, un problème résolu de manière ultra succinte avec un language fonctionnel, un one-liner en shell. Les coding contest montrent aussi des résultats assez hallucinants parfois, sans parler des démo ASM en quelques K…
Toutefois, dans un milieu pro, c'est rarement les lignes de codes en elles même qui font notre fierté. C'est plutôt la structure de l'application, les structures de données utilisées, la complexité résultant de leur usage et parfois l'anticipation de futurs changements.
Quoi de plus jouissif quand le client demande un changement assez complexe et que l'on s'aperçoit qu'il ne nécessitera que très peu d'adaptations parce que notre développement à toujours favorisé une certaine généricité plutôt que l'accumulation de hacks crados qui auraient pu rendre le code très spécifique. Une bonne structure et le code qui va avec se réusinent bien en général.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Je pense que cela rentre précisément dans ce qu'il appelle le beau code.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
AMHA du code beau n'est pas astucieux. Une astuce c'est un truc qui peut casser dès qu'on met à jour le compilateur et/ou le runtime ou dès qu'on change d'environnement. Un code beau tente d'être concis mais sans être succin. On peut souligner la beauté du geste des participants à IOCCC, mais pas la beauté de leur code.
Personnellement pour moi un code beau c'est celui qui va avoir une séparation nette entre la technique et le métier. Du coté métier on manipule des concepts métier (j'augmente tous les employés) dans la technique on implémente les concepts métiers (un employé c'est …, une augmentation c'est…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Lutin . Évalué à 1.
(Les avatars rendent la mise en page foireuse,
cet espèce d'ipse lorem ipsum tagadum
règle le problème)
C'est astucieux et beau :
source: Id Tech 3
[^] # Re: Plutôt beauté du design
Posté par Patrick Nicolas . Évalué à 4.
Dommage que ce soit du code incorrect (warning: dereferencing type-punned pointer will break strict-aliasing rules) et que ce soit moins performant qu'un calcul explicite avec sqrt.
C'est une curiosité intéressante mais je veux éviter d'avoir ce genre de chose dans mon code.
[^] # Re: Plutôt beauté du design
Posté par alt3 (site web personnel) . Évalué à 1. Dernière modification le 29 septembre 2014 à 17:19.
Il ne s'agit pas du calcul d'une racine carrée, mais du calcul rapide de l'inverse d'une racine carrée:
https://fr.wikipedia.org/wiki/Racine_carr%C3%A9e_inverse_rapide
[^] # Re: Plutôt beauté du design
Posté par Patrick Nicolas . Évalué à 4.
D'après https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723 lorsque l'on écrit 1/sqrt(x) et que l'on compile avec -ffast-math c'est plus rapide (et précis) que cette astuce.
Il optimise aussi sqrt(x) en x*1/sqtr(x) qui est plus rapide !
[^] # Re: Plutôt beauté du design
Posté par pepp . Évalué à 4.
Enfin ce code est issu de "id Tech 3" qui d'après Wikipedia date de fin 1999.
Depuis les compilateurs/processeurs se sont peut-être suffisamment améliorés pour rendre obsolète ce genre d'astuce.
Pour moi ce code est peut-être au choix:
- une solution élégante à un problème rencontré par les développeurs à l'époque : mise en oeuvre d'une approximation mathématique, plus rapide et dispo sur toutes les plateformes tout en s'assurant que ses défauts n'étaient pas gênants pour le domaine concerné.
- ou l'exemple typique de chose à ne pas faire (si c'était juste pour le fun).
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
De mémoire, c'est surtout les multiplieurs en un seul cycle qui rende cette astuce inutile.
sqrt(x) est une instruction lente quand elle existe, genre en n cycles, n étant le nombre de bit du nombre. 1/sqrt(x) est au contraire rapide, souvent un seul cycle, et est donc souvent présente dans les jeux d'instruction.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Troy McClure (site web personnel) . Évalué à 5.
Oui, c'est typiquement une approximation de 1/sqrt sur 11 bits qui est fournie par les processeurs modernes via les instructions sse / vmx / neon etc (peut etre même en faisant des calculs similaires niveau hardware à ceux de quake ! qui sait). Si l'utilisateur veut une sqrt de precision superieure il doit faire une ou deux iterations de newton pour raffiner le resultat.
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 8.
C'est efficace, mais est-ce que c'est beau ? (est-ce qu'un code avec comme commentaire "what the fuck ?" est beau)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 3.
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!
[^] # Re: Plutôt beauté du design
Posté par xcomcmdr . Évalué à 4.
C'est très loin d'être mon impression en lisant le lien :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 2.
Et bien merci pour cette correction, j'étais complètement passé à côté de cet article de Chris Lomont!
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 4. Dernière modification le 29 septembre 2014 à 16:13.
Je ne sais pas ce que l'auteur de la dépêche avait en tête en parlant de beau code.
Mais moi, cela me fait plutôt penser à une architecture fonctionnelle, bien pensée et bien écrite pour ton logiciel.
Là tu présentes une astuce mathématique pour améliorer (ou pas, cette astuce est ancienne, elle a peut-être déjà été prise en compte dans les architecture/runtime récent) la performance de la fonction racine carrée.
C'est une belle astuce mathématique, mais cela n'a pas de sens pour moi, d'essayer de qualifier ce code de beau ou non.
À part peut-être pour le style comme le choix des noms de variables, l'indentation, …
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à 1.
À mon avis, c'était à peu près le contraire de celui qui est présenté en exemple.
Certainement pas "mathématique". C'est une sorte d'heuristique algorithmique, un peu du même genre que "sin(60°) ~ e/π". Plus bricolé que ça, c'est pas possible.
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 3.
j'appelle ça mathématique moi.
C'est peut-être le fait que ce soit une approximation ou qu'elle se sert de la représentation binaire des nombres qui te donne l'impression que ça ne l'est pas ?
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à -1.
À 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.
Il peut exister des astuces mathématiques, par exemple l'accélération d'un algorithme par la recherche de solutions entières avant de passer à une résolution numérique. On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme. Mais là, l'exemple dont on parle, c'est l'exploitation d'une coïncidence numérique fortuite pour accélérer un calcul. C'est certainement ingénieux et utile, on peut même trouver ça génial, mais "beau"? Je sais bien que tous les goûts sont dans la nature, mais je pense qu'on est quand même à l'extrême limite de ce qu'un être humain peut trouver beau être atteint d'une pathologie quelconque :-)
Pour moi, ce code est aussi beau qu'un cardan de suspension. Il est probablement fonctionnel, mais il n'est pas fait pour être regardé, encore moins admiré.
[^] # Re: Plutôt beauté du design
Posté par Troy McClure (site web personnel) . Évalué à 4.
Y'a quand meme une iteration de newton-raphson dans l'algo en question, ça me semble être un parfait exemple de ce que tu cites
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à 1.
Je ne pense pas que la discussion porte sur cette ligne de code :-) Évidemment, si on trouve un diamant dans une crotte de chien, on peut voir le diamant, ou la crotte de chien :-)
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à 3.
Je me permets de me re-répondre, pour me contredire : ce code est une abomination mathématique, parce qu'il préfère une valeur de départ moins bonne (d'après Wikipédia, 0x5f37642f donne une meilleure valeur de départ que 0x5f3759df), pour la simple raison qu'un seul tour de Newton donne une meilleure approximation finale (!). On n'est donc dans le bricolage crado le plus total—bricolage génial, mais c'est crade du début à la fin).
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 2. Dernière modification le 30 septembre 2014 à 10:30.
en mathématiques, on approche les fonctions trigonométriques par des polynômes (on approche tout par des polynome d'ailleurs)
C'est donc bien une approche mathématique, c'est son implémentation numérique qui en réduit la précision, et quand on veut faire une approximation pour une valeur numérique en particulier, il faut bien, de toute façon, stopper le calcul à un moment donné.
Pourquoi une coïncidence ? les constantes n'ont pas été choisies au hasard
Je n'ai jamais prétendu que ce code était beau, je le trouve même très moche, d'un point de vu des noms de variables et des commentaires par exemple. Je ne laisserai jamais passer ça sous cette forme dans ma boite ! Mais j'accepterai sans problèmes l'astuce mathématique si elle à un sens à l'endroit ou elle est utilisée. C'est juste un problème de forme pour moi.
Il n'est surtout pas fait pour être commité !
- des noms de variables à une lettre qui n'ont aucun sens.
- une constante dans une variable (threehalf), les autres directement dans le code ???
- des commentaires (en très petite quantité) qui n'ont strictement aucune utilité pour comprendre le code…
Le type qui me propose ça dans ma boite, je lui interdit le droit de commit à lui et sa famille sur 42 générations…
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu sais que tu parles de John Carmack, un des meilleurs codeurs de tous les temps ? https://fr.wikipedia.org/wiki/John_Carmack
Les génies sont incompris…
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 10. Dernière modification le 30 septembre 2014 à 11:40.
Je viens de vérifier, et effectivement, il n'a pas les autorisations pour commiter ! Ouf !
[^] # Re: Plutôt beauté du design
Posté par auve . Évalué à 5.
Tout le monde aimerait que ce soit vrai mais c'est une légende urbaine. John Carmack n'a pas écrit cette fonction.
[^] # Re: Plutôt beauté du design
Posté par KiKouN . Évalué à 2. Dernière modification le 01 octobre 2014 à 11:45.
Et les fonctions :
int Sys_MonkeyShouldBeSpanked( void )
C'est qui, qui les a écrit ?
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 2.
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.
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 4.
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!
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à 4.
Beuh, je n'ai jamais dit que je n'aimais pas le calcul numérique, c'est même le contraire, et j'en fais tous les jours. C'est juste que ce n'est pas des mathématiques. Le travail mathématique, c'est de défnir par exemple les équations récursives, de montrer qu'elles convergent, que le résultat est unique et défini, que les fonctions sont dérivables, etc. Mais l'implémentation de ces méthodes et leur utilisation, c'est de l'algorithmique ou de l'informatique, mais je ne comprends pas où est le travail mathématique là-dedans!
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…
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 4.
Qu'elle est ta définition de "mathématiques" ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par arnaudus . Évalué à 2.
Plus ou moins celle de Wikipédia, je pense : "Les mathématiques sont un ensemble de connaissances abstraites résultant de raisonnements logiques appliqués à divers objets tels que les nombres, les figures, les structures et les transformations." […] "Les mathématiques se distinguent des autres sciences par un rapport particulier au réel car l'observation et l'expérience ne s'y portent pas sur des objets physiques".
Je veux bien concevoir que tout problème numérique déterministe peut être formalisé sous forme de question à l'apparence mathématique : "à combien de décimales doit-on tronquer le cube d'un nombre en virgule flottante codé en binaire sur une architecture 64 bits pour s'assurer d'une erreur relative inférieure à 10-10 a nécessairement une réponse, trouver cette réponse nécessite d'utiliser des outils mathématiques, mais ça revient à dire que le calcul du brut imposable sur une fiche de paye relève des mathématiques, ou que n'importe quel bout de code est mathématique par nature.
Pour être un peu plus clair, je considère que
const double pi = 333./106.;
est une astuce numérique, alors que
const double pi = 6*asin(0.5);
est une astuce mathématique. Je n'essaye même pas de faire un classement entre les deux, c'est juste que quand on parle de beau code, les astuces mathématiques me semblent plus élégantes que les astuces numériques (même si elles sont moins optimales, par exemple).
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 4.
É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.
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.
[^] # Re: Plutôt beauté du design
Posté par Lutin . Évalué à 0.
C'est l'inverse de la racine carré.
Et je trouve ça plus beau (et moins soporifique) qu'un code qui fait ce qu'il doit faire sans aucune originalité.
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 7.
Tu lis le code sans comprendre ce qu'il fait (sans avoir un bon gros bagage mathématique et/ou sans avoir lu la page wikipedia), tu as un problème sur ce code y toucher est très dangereux. C'est du code fragile d'un expert que seul un expert peut retoucher.
C'est une astuce sympa mais je ne trouve pas ça beau. Pour moi le beau doit se lire, tu sais ce qu'il fait et pourquoi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Lutin . Évalué à 0.
C'est pour ça qu'on a fait 5 ans d'étude, parfois plus; pour avoir ce bagage.
Et avec un peu de TDD ce bout de code n'est pas si dangereux que ça.
[^] # Re: Plutôt beauté du design
Posté par hervé Couvelard . Évalué à 3.
le truc, c'est qu'après les 5 ans d'étude, le niveau n'est pas très homogène… et il y en a qui ne comprendront jamais ce code, peut importe le nombre d'année d'études.
Mais dans l'absolu tu as raison, et c'est le sens de ma remarque sur beauté pour quoi, maintenable par qui.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Moi j'attends d'avoir enfin un langage qui permet d'exprimer la fonction sous forme d'une approximation utilisant un tour de newton rafson, sans montrer un paquet de constant, ou un paquet ignoble de template ou de macro.
Le vrai problème est là : avoir un langage suffisamment expressif pour le codeur qui arrive ensuite, et pour générer exactement ce que l'on veut.
C'est souvent fait avec des templates C++, qui devient un langage dans le langage, ou avec des générateurs de code.
Souvent, on veut simplement de la "propagation de constante balèze" avec gestion des conteneurs (liste, tableau, string). Par exemple, compiler une expression régulière décrite sous forme de string à la compilation, décrire une forme de code plus rapide (fftw), générer des structures de donnés d'après un modèle (EMF d'Eclipse gère la structure de modèle objet, et la sérialisation XML depuis une DTD ou un modèle UML)…
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par 2PetitsVerres . Évalué à 3.
J'ai vu un RK4 en simulink avec uniquement des blocs de base, pas d'appel à une fonction et je me suis dit que c'était le "langage" idéal pour faire ça. C'était magnifique. Ou pas…
(bon ils avaient une raison. Je ne dis pas que c'était une bonne raison, mais au moins c'était une justification. Le tout passait dans un générateur de code pour finalement être compilé vers de l'embarqué, et les "règles" de "codage" autorisent uniquement certains blocs)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est un peu l'idée documenté exactement ce que l'on veut faire, au lieu de mettre le résultat de pré-calcul en dure. Cela permet aussi de relire les pré-calcul.
Cela me fait mal de lire que l'exemple que tu donnes, est dans le truc directement concurrent avec ma boite (qui édite SCADE suite), c'est le karma :)
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
C'est vrai que créer programmatiquement des données statiques (au sens où c'est de la donnée et non du calcul dans le binaire) est souvent manquant. Il n'y a guère que les macro (de C/C++, je ne connais pas bien celles de lisp) et les templates C++ qui le permettent (dans les langages classiques). Je ne sais pas si hotspot n'est pas capable d'arriver à ce genre de résultats après un certain temps (mais j'ai jamais vérifié).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
ocaml avec ocamlp4 mais la syntaxe était incompréhensible. On dirait que le nom était bien choisi en rapport avec les reformé du même nom.
Ils ont créé un nouveau truc, les points d'extension qui ressemble à des annotations java, histoire de créer des filtres code vers code, comme lisp, mais les exemples sont incomplets. C'est comme si il montrait les appels de fonctions, sans montrer les définitions de fonctions.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Dr BG . Évalué à 2.
ou celles de D.
[^] # Re: Plutôt beauté du design
Posté par serge_sans_paille (site web personnel) . Évalué à 1.
et les
constexpr? mmh ?[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
pas mal.
Mais ça c'est vraiment très con :
"It can call only other constexpr functions"
Cela veut dire pas de lib standard, pas de lecture de fichier, pas d'io, etc…
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 2.
ça parait logique.
la lib standard peu évoluer en proposant des constexpr !
Pour la lecture de fichiers, je ne vois pas le souci, un fichier c'est dynamique, si ce que tu veux c'est sont contenu statique au moment de la compilation, il y à la directive #include pour cela.
Pour les io, je ne sais pas, mais ça me parait louche, c'est typiquement un truc dynamique, dans quel cas on voudrait avoir un résultat statique d'une lecture d'un io ?
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
oulala… Tu inclus un fichier binaire (jpg) dans un programme avec #include ? Tu réussi à parser un fichier xmi uml ou DTD pour créer des class à la volé avec #include ?
Quand sa forme se rapproche plus du métier ou du besoin que le code source. C'est la raison d'être des DSL : s'éloigner du code pour s'approcher du problème à résoudre ; cela facilite la relecture, les vérifications, les règles génériques, l'automatisation, etc…
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 2.
si ce sont des datas binaires, il existe des tas de d'outils qui te permettent de les ajouter dans ton programme et de les retrouver avec.
Si tu veux créer des classes à la volée à la compilation, ce dont tu as besoin c'est un outil de génération de code, pourquoi voudrais-tu une fonctionnalité du langague qui permettre de lire ce fichier à la compilation ? Je pense que c'est un faux problème, ou alors, il me manque des informations.
ça ne m'avance pas, quel est ton problème à résoudre ? Une solution sert à résoudre un problème, quand on cherche une solution pour résoudre sa solution, c'est qu'il y a quelque chose qui dans la solution de base, en général, c'est qu'elle n'est pas bonne.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 01 octobre 2014 à 16:07.
Et donc tu utilises 2 outils et 2 langages pour faire quelques choses de très proche, avec tous les problèmes imaginables à l'interface.
J'ai déjà donné des exemples : inclure un binaire sans outils externe, pas de générateur de code externe, mais un générateur en library.
Et puis, c'est même pire que ça. Je parle de lire un fichier pour générer des API, et tu me parles "générateur de code", tu imagines la différence de difficulté entre une bonne propagation de constante et un compilateur ?
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à 2.
oui.
C'est pas comme si on ne faisait pas déjà ça depuis toujours. flex, bison, moc en sont des exemple parmi d'autres !
Mais ça, ça n'est pas un problème que tu as, mais une solution que tu proposes.
C'est quoi la différence ? une API c'est du code. il existe déjà des tas d'outils qui transforment des graphes uml en code (api seulement)
Je pense oui, mais ça ne me dit toujours pas pourquoi tu as besoin de ces choses de façon constante dans ton language !
c++ fait des algos, et il le fait très bien, il sait déjà gérer une certaine forme de propagation de constantes, il en gère un peu plus maintenant, si tu veux un meta langage qui fasse autre chose, utilise un autre langage et voila !
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'était le sujet du thread, un tel langage n'existe pas.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par serge_sans_paille (site web personnel) . Évalué à 1.
En fait ce que tu veux c'est une forme de propagation de constantes interprocédurales, non ?
<pub>Pythran le fait dans certains cas</pub>Par exemple :
est transformé (à la compilation) en
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui, c'est de la propagation de constante. Sauf qu'en général, dés qu'un conteneur rentre dans la boucle, cela stop (string, list, etc…). Impossible de compiler une regexp par exemple.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par serge_sans_paille (site web personnel) . Évalué à 2.
J'ai peu de bagage en langages fonctionnels, mais vu les bonnes propriétés de ces derniers, y a pas de compilo qui fait de la propagation de constantes avancées pour ces langages ?
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Haskell fait de la deforestation, qui évite la création d'arbre inutile dans un traitement (genre empilement de map).
ocaml fait le minimum. Il fait quelques optimisation haut niveau comme le tail recursif, mais c'est tout : presque pas de propagation de constante, pas d'inlining, pas de spécialisation de fonction, pas de déroulage de boucle.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 4.
Ça me surprend, j'ai toujours eu de très bons échos sur les performances d'OCaml.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui, cela va vite, mais sans se fouler.
Le système de typage permet d'éviter tout un tas de programmation défensive. Globalement le modèle haut niveau est très bon, et donc ils n'ont pas jugé utile d'aller plus loin.
Mais cela veut surtout dire que doubler les performances de certain code doit être possible.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 4.
Je comprends bien, mais le langage n'est plus nouveau, il n'y a vraiment personne qui veut s'y coller ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est un langage de recherche. Pendant un moment, il y avait 5 ou 6 personnes sur le nouveau système de typage (GADT), mais une demi pour gérer la correction de bugs. Ocaml pro va peut être changer cela.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 3.
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.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
C'est souvent un argument mis en avant contre l'inlining, qui s'avère faux chaque fois que j'en fais l'essaie. Et contrairement, a ce que crois les personnes qui pensent cela, faire de l'inlining réduit le code la plus part du temps, car la propagation de constante/l'élimination de code mort, jouent ensuite leur rôle.
Oui, mais dont on se fout un peu sur nos machines de bureau tant que le binaire n'a pas fait x10 ou x100.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 3.
D'autres personnes ont des expériences différentes, apparemment.
Pas forcément, il vaut mieux avoir un boucle
fornon 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.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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.
Oui et sur un code moyen, cela ne change rien. Par contre localement, la différence de performance est énorme. En -O3, gcc a tendance a dérouler les petites boucles 16 fois. J'estime que dérouler 4x fois ne peut jamais faire perdre de performance.
Tu parles de Ocaml, car tous les compilateurs C optimisent pour la vitesse. Le "-Os" de gcc évitent seulement les optimisations connues pour faire enfler le code.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 3.
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.
Cela change l'alignement.
Oui, on parle de OCaml dans ce fil, non?
[^] # Re: Plutôt beauté du design
Posté par anaseto . Évalué à 3.
L'année dernière le blog d'ocamlpro parlait d'un projet pour inliner de façon plus agressive, mais ça n'a plus l'air actif. Ceci dit, dernièrement, il y a eu des améliorations du côté de la propagation des constantes et quelques autres optimisations, à en croire le changelog de la 4.02.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'ai encore l'impression de parler avec un universitaire qui fait des compilos mais qui n'a absolument aucunes idées précises de comment fonctionne un cpu, ni comment les compilo comme gcc optimisent à bas niveau.
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).
Le compilo gère évidement l'alignement qui ne sera jamais cassé. De plus, les prefetchers font en sorte qu'il n'y a jamais de ruptures sur les enchainements de lignes de cache. Ils sont très efficace concernant le code, bien plus que pour les données.
Si jamais tu tombes sur le compilo suffisamment crétin pour ne pas faire d'alignement, il faut aussi que la perte de performance d'alignement ne soit pas compensé par la réduction du nombre de teste de boucle, et par la recombinaison des instructions.
Non. C'est géré.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Michaël (site web personnel) . Évalué à 2.
C'est le genre de personne qui a écrit exactement ça dans le post auquel tu réponds, non?
Ok, au temps pour moi.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je pensais même à du code local.
"a+b+c+d" sera un code plus court que "(a+b)+(c+d)" qui utilise plus de variable intermédiaires, mais le deuxième code sera 30% plus rapide, dans le meilleur des cas.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par lasher . Évalué à 3.
Le compilateur d'Intel en
-O2déroule 2 à 8 fois automatiquement la plupart des boucles qu'il rencontre (sauf si le nombre d'instructions dépasse les limites, cas d'exception). Je n'ai pas vérifié pour le compilateur GNU, mais avec-O3il y a des chances qu'il fasse pareil.[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De mémoire, j'aurais dis 16. J'imagine que c'est plus une histoire de taille du cœur de la boucle.
L'idéal est d'utiliser tous les registres (on déroule plus), pour ensuite mélanger les instructions qui sont indépendantes ce qui permet de bien utiliser le pipeline, mais il ne faut jamais devoir utiliser la mémoire (on déroule moins) qui deviendrait un goulet d'étranglement.
"La première sécurité est la liberté"
[^] # Re: Plutôt beauté du design
Posté par Christophe B. (site web personnel) . Évalué à 4.
Tout est relatif :
dans le monde du jeu vidéo (et surtout à l'époque) ce code est merveilleux
dans le monde super sexy et à la pointe de la techno du XXeme siècle qu'est l'informatique de gestion ce code peut passer pour un délire de débutant, un trip sous LSD ou autre.
En cas de bug on regarde même pas, on vire on réécrit.
La raison, c'est la finalité du code, c'est super optimisé pour du calcul graphique en 3D et donc super bien voire même génial.
C'est difficile à maintenir et à lire mais bon pour un jeu OSF
Pour du code qui doit tourner, voire même évoluer pendant plusieurs années il vaut mieux éviter.
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
Il est pourri ton faux dilemme, tu dis toi même que pour écrire n'importe quoi qui peut durer un peu c'est pas parfait (il n'y a pas que l'informatique de gestion, il y a aussi les moteurs de base de données, les noyaux de systèmes d'exploitation, les shell, les éditeurs de texte, les navigateurs, les serveurs,…).
Son code était bon parce qu'il répondait à un besoin de performance à une époque donnée, c'était intéressant dans les jeux vidéo, dans les codes de calculs numériques, en simulation, etc. Mais il semble qu'aujourd'hui ce soit déprécié par l'amélioration des compilateurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Christophe B. (site web personnel) . Évalué à 1.
C'est pas un dilemme, je voulais juste préciser que le beau code est relatif en fonction de sa finalité.
Pour faire plus simple :
Dans le jeu vidéo : si c'est rapide et que ça tourne tant pis si c'est illisible
Dans d'autres secteurs : la lisibilité et donc la maintenabilité du code est une priorité, et tant pis si cela se traine
Et par conséquent, du beau code dépend du contexte dans lequel il est employé
Exemple dans les années 80, j'avais du écrire des choses du style (en basic de l'époque):
B = 100*(A>5)*(A5) and (A<10) THEN B=100
Est ce beau ? oui et non
Par contre comme je devais jongler avec 80 Ko de mémoire RAM cela me faisait gagner quelques octets
qui pouvais servir ailleurs
[^] # Re: Plutôt beauté du design
Posté par kowalsky . Évalué à 2.
ça peut être du code astucieux sans effets de bord hors de la fonction/méthode.
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3. Dernière modification le 30 septembre 2014 à 10:50.
Oui cette fonction est de qualité (AMHA), car c'est une fonction pure qui s'utilise facilement (elle n'expose pas sa logique interne).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par lasher . Évalué à 3.
Non. Par exemple si je veux savoir si un nombre est une puissance de 2, je peux écrire
Ça marche, c'est assez direct, et au pire j'aurai
itérations (puisque je divise par 2 à chaque itération).
On peut quand même simplifier :
On peut même rendre l'écriture plus compacte :
Mais bon jusque là, « l'astuce » c'est juste connaître le langage, et savoir exprimer la même chose de différentes façon. Il s'agit donc purement de style.
Mais je peux être réellement astucieux, et répondre en temps constant :
Un entier non-signé ne changera jamais ses propriétés, donc j'ai la garantie que ce code fonctionnera toujours en C/C++ (et en fait n'importe quel langage qui permet les opérations bit-à-bit sur des entiers).
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
en quoi c'est plus compact que :
Ce qui a le bon goût de ne pas tordre une construction du langage par lubie.
Ta dernière solution n'est pas astucieuse elle utilise l'une des propriétés mathématiques. Ce n'est pas la première solution à la quelle pense un développeur, mais ça n'a rien de bien compliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par lasher . Évalué à 2.
Utiliser une connaissance en maths, physique, …, bref une connaissance du domaine auquel s'applique la fonction qu'on écrit pour optimiser/simplifier le code, oui, c'est astucieux. Perso, je n'aurais jamais pensé au coup du
n & (n-1). Il faut accepter le fait que l'informatique est l'enfant des maths et de l'électronique, et donc que tout « truc et astuce » tombera souvent dans un domaine ou l'autre. Et de temps en temps, utiliser les propriétés du langage utilisé sera une utilisation astucieuse du langage, et donc sera une « astuce de programmation ».En résumé : si à chaque fois que quelqu'un utilise une astuce pour simplifier/optimiser du code, on contre en disant « mais c'est pas de l'info, c'est des maths », alors on peut dire la même chose de 90% des « astuces » utilisées dans les autres domaines (mécanique, électronique, etc.), car après tout, toute modèle passant par une science « dure » est exprimé en termes mathématiques…
[^] # Re: Plutôt beauté du design
Posté par lasher . Évalué à 2. Dernière modification le 01 octobre 2014 à 18:43.
Tu « triches » dans le sens où tu mets le corps du
whilesur la même ligne. :) J'aurais pu faire pareil avec mon corps vide dans lefor.Ensuite, utiliser
n /= 2dans la post-condition n'est absolument pas un détournement, car il s'agit bien d'une façon d'itérer sur la boucle. Par exemple, écrire un truc comme ceci (en supposant une liste chaînée) :est parfaitement idiomatique, et clair. Tu pourrais bien sûr écrire quelque chose du genre :
Et ce serait (peut-être) plus clair pour un nouveau venu dans le monde du C, mais à mon avis ni plus ni moins pour quelqu'un qui connaît « raisonnablement bien » le langage (c'est-à-dire qui a plus de 6 mois d'expérience avec).
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
Je le fais quand la ligne en question reste courte, que ça ne nuit pas à la lisibilité.
Laisser vide 2 des 4 instructions faisant partie de la boucle
forc'est dommage (et pour moi c'est signe que ce n'est pas la construction qu'il te faux).Je préfère aussi la première (mis à part que la ligne est trop longue à mon goût) et n'importe qui ayant touché du C, C++, Java, C#,… pendant plus d'une semaine devrait le comprendre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par freem . Évalué à 2.
Des 4? Tu considères donc le corps d'une boucle comme partie intégrante de la boucle?
Pas moi, mais c'est une question d'opinion j'imagine.
Mais du coup, dans mon opinion, il n'y à donc qu'un champ sur 3 qui n'est pas utilisé, et il s'agit de l'initialisation de la boucle. Ce champ est régulièrement laissé vide, pour un tas de raisons.
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 3.
Pas vraiment quand on voit comment c'est défini (p 147) :
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
D'ailleurs c'est pareil quand tu vois la définition de la syntaxe.
Mais OSEF, ça fait 2 instructions vides.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par moi1392 . Évalué à -1.
is_power_of_2(1) renvoie true ;)
[^] # Re: Plutôt beauté du design
Posté par barmic . Évalué à 10.
En même temps 20 = 1
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plutôt beauté du design
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Beau‚ ce n'est pas forcément utile ou agréable ou dans le cas qui nous occupe ici maintenable.
A mon avis ce qui caractérise le beau c'est justement lorsqu'il y a quelque chose qui dépasse les qualités fonctionnelles du produit. Si tu prends par exemple le code de apache 1.3, il etait loin d'être maintenable et souffrait de problèmes de design important. A vrai dire c'était une série de hacks avec des ifdef spaghetti dans tous les sens. Mais finalement cela en faisait un morceau tellement essentiel du l'histoire de l'informatique qu'il avait une beauté certaine.
En le lisant, tu pouvais découvrir l'évolution des systèmes, leur parenté‚ leurs manques. Les tentatives diverses pour avoir des ipc efficaces‚ des codages de caractères insoupsonnés‚ des hacks pour résoudre toutes sorte de problème qui ont émaillés l'histoire du web.
Bref tu te retrouves devant des morceaux de codes qui te font voyager dans le temps‚ devant l'intention de programmeurs désarmés face a des problèmes nouveaux et qui finalement imaginent des solutions pas si éloignées des outils actuels …
Un tel code est une horreur a maintenir et a de grosses limites en efficacité. Pourtant il reste d'une beauté émouvante et a mon avis difficilement contestable.
# Le beau code c'est bien, ...
Posté par ChickenKiller . Évalué à 2.
mais le bro code c'est ma référence (oui je sais ça date un peu maintenant mais je suis vieux ;-( ) …
# Asimov...
Posté par redo_fr . Évalué à 3.
… faisait dire à l'un de ses personnages:
Je pense personnellement que ça s'applique très bien au code (= équation mathématique, non?)
Je ne suis pas un grand codeur, mais quand j'examine mes créations "de loin", j'ai l'impression qu'un code bien écrit (dans le sens fonctionnel), "ça" se voit (indentation, etc.). Lorsque j'ai un code qui n'est pas "beau", très souvent, il y a un problème fonctionnel dedans.
Remarques totalement subjectives et absolument non "industrialisables".
:-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Asimov...
Posté par Big Pete . Évalué à 2.
Mouais, je suis pas un grand codeur non plus, mais je me méfie comme de la peste de cette impression, personnellement. Je pense que tu peux très bien produire un code très élégant dans lequel peut se planquer un magnifique bug et faire planter superbement un programme.
Dans le monde de l'industrie ou de la science, y a un tas de truc très élégants et qui semblaient très réussis et qui ce sont vautrés lamentablement. Les plus célèbres sont le Titanic, la constante cosmologique d’Einstein ou les motocyclettes Ducati.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Asimov...
Posté par totof2000 . Évalué à 2.
Peux-tu détailler STP ?
Sinon il n'y a pas que l'industrie et la science qui sont concernés, mais tous les domaines. En politique on a eu par exemple dans la catégorie "truc très élégants et qui semblaient très réussis et qui ce sont vautrés lamentablement", il y a aussi Ségolène Royal aux présidentielles …
[^] # Re: Asimov...
Posté par Big Pete . Évalué à 1.
Détailler, c'est bien grand mot, mais dans le cadre de l'élaboration de sa théorie de relativité générale, Einstein aurait ajouté cette constante pour rendre l'univers stable (ce qui peut être interprété (avec précaution) comme une volonté de sa part de rendre sa théorie plus jolie). Néanmoins, on s'est aperçu ensuite que l'univers était en expansion et il est revenu dessus en la qualifiant de boulette. Bon en même temps des boulettes comme ça, je veux bien en faire tout les jours perso.
Bon il s’avère que récemment certains pensent que c'était pas forcément une boulette, mais là, moi, j'ai déjà décroché depuis un moment.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Asimov...
Posté par totof2000 . Évalué à 2.
C'est pour ça que je t'ai demandé de détailler, car j'ai cru comprendre également récemment en regardant une émission sur ce sujet que ce n'était peut-être pas une boulette.
[^] # Re: Asimov...
Posté par kowalsky . Évalué à 2.
En fait certain trouve que cette 'boulette' a plein de rapport avec la matière noir, qui n'est (pour l'instant) qu'une création pour permettre à la théorie de décrire l'univers comme l'on pense qu'il est. Et les constantes en jeu se ressemble, d’où le rapprochement fait par certain.
Il y a une conférence de Klein qui aborde très brièvement le sujet :
https://www.youtube.com/watch?v=NA2XOTSTs8w&list=TLgGn2G6qxhIfaso9YVFpl_bbg3S1_KWvO (ça dure une heure environ je crois)
ou ça, je crois que c'est dans le lien précédent mais je ne suis plus sur :
https://www.youtube.com/watch?v=VFyxniME8XA&list=PLgSHH6boFf5vGbAOmS7Gpp4BBEr3h5prA (c'est plus court).
Dans le 1er lien, ça aborde la question de la description de l'univers par les équations, un des points soulevé est aussi l'élégance des équations.
[^] # Re: Asimov...
Posté par freem . Évalué à 2.
Élégant? Euhhhh si on veux… les goûts et les couleurs après tout…
[^] # Re: Asimov...
Posté par totof2000 . Évalué à 2.
Compare avec ses adversaires de l'époque.
[^] # Re: Asimov...
Posté par barmic . Évalué à 3.
Son unique défaut c'est de manquer de canots de sauvetage, je ne connais pas de bateau de voyage capable de résister à un éperonnage avec un iceberg.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Asimov...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'acier était aussi trop fragile, ce qui a augmenté la taille de la déchirure. Le bateau aurait du couler plus lentement ou pas du tout.
"La première sécurité est la liberté"
[^] # Re: Asimov...
Posté par Big Pete . Évalué à 4. Dernière modification le 30 septembre 2014 à 10:15.
Alors, de ce que j'en sais,ce n'était pas son unique défaut. La conception des cloisons étanches qui devait assurer la flottabilité du navire même dans le cas d'un percement de la coque sous la ligne de flottaison n'avait pas prévu une ouverture longitudinale de cette ampleur, qui a noyé plusieurs compartiments, provoqué l'enfoncement de la partie avant et du fait du manque de hauteur des cloisons, noyé progressivement, à mesure de l'enfoncement du navire, les compartiments vers l'arrière, jusqu’à l'épuisement de la réserve de flottabilité du navire, ce qui a entrainé rapidement le naufrage.
Bon après, on peut discuter, parce qu'avec des si … Mais si ce problème de conception avait été mieux pris en compte, on peut espérer qu'il eu tenu plus longtemps à flot, surtout que le temps était calme et que ça aurait permis au secours d'arriver sur zone.
Sinon, personnellement, j'ai vu un porte-container qui s'en était mangé un (un petit, certes) dans l'atlantique nord et dont le bulbe était complètement détruit et qui flottait encore, il avait même réussi à rejoindre par ses propre moyen Halifax.
Bon sinon, je vois que personne n'a râlé pour les Ducati :).
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
# Zen Python
Posté par lolop (site web personnel) . Évalué à 9.
Pour ceux qui ne connaîtraient pas encore:
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# relativité étendue
Posté par hervé Couvelard . Évalué à 7.
De toute façon, à lire tous les trolls sur les codes, langages, hack et consorts, la beauté du code me semble assez relative au niveau de celui qui parle.
Et faire un code maintenable par d'autres c'est bien dans l'idée, mais quels autres ? Ceux qui ont le même niveau que toi ? des ingés avec 15 ans d'expé dans la techno ? des bts qui sortent de l'école, des prestas ssii balancés sur la techno avec une demie journée de "formation", des stagiaires ?
Et sur une machine qui iddle à 99% du temps ? sur une machine à 100% proc pratiquement tout le temps ? sur des calculs itératifs des milliards de fois ? sur une boucle exécutée une fois tous les 36 du mois ?
C'est une question ou il n'y a pas de réponse, il y a autant de réponse que de personnes et de cas.
Lorsque l'on reprend du code qu'on a fait il y a 10 ans, on a vue le chemin parcouru et on est capable d'améliorer son code (par expérience) et parce que notre manière de coder à changé. Maintenant si on prend le cas inverse, est-ce que 15 ans après je dois toujours faire le code de tel manière que je puisse le maintenir si j'avais 15 ans de moins ?
C'est plus le pourquoi on avait fait cela que comment on avait cela qui est compliqué. Il suffit de le documenter dans le code. La beauté est un truc tout relatif.
[^] # Re: relativité étendue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Non, il y a des trucs qui restent.
Si tu arrives à pondre un algo avec 4 cas génériques, dans tout les cas, c'est plus simple à maintenir que faire les 60 cas un par un.
J'avais le cas aussi de structures de donné strictement nécessaire, ou pas. Si il existe des champs inutiles, comme le savoir en ne lisant que le code localement ?
"La première sécurité est la liberté"
[^] # Re: relativité étendue
Posté par hervé Couvelard . Évalué à 1.
ok… et si tu es le seul à savoir lire les 4 cas génériques et comprendre qu'ils cachent les 60 cas réels, comment sait-tu que cela ne va pas casser dans 5 ans lors d'un refactoring par un mec qui ne réalisera pas que tu adresses 60 cas et non juste 4 ?
[^] # Re: relativité étendue
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2014 à 17:22.
En général, le typage ne laisse pas passer. Il force aussi au codeur suivant à réfléchir un peu.
Si on reste sur du code propre et pas du hack de concours, un code réduit est toujours préférable à un truc verbeux, dont on finit forcément par perdre la structure d'ensemble.
"La première sécurité est la liberté"
[^] # Re: relativité étendue
Posté par hervé Couvelard . Évalué à 1.
moi les certitudes ça m'a toujours fait peur… mais je dois pas être assez smart peut être.
[^] # Re: relativité étendue
Posté par freem . Évalué à 3.
Je suis bien certain que tu es certain d'avoir peur des certitudes…
[^] # Re: relativité étendue
Posté par freem . Évalué à 2.
Accessoirement, si le code n'est, par malheur, pas assez parlant lui-même, il reste les commentaires. Les commentaires qui peuvent aussi servir à pointer un endroit ou l'on à du tordre le code pour obéir à des règles métier un peu farfelues, ou parce que le code avec lequel on interagit (et sur lequel on à bien entendu aucun pouvoir) est buggué/complexe/bancal.
Je pense que tout le monde sera d'accord avec moi pour dire que quand on maintien du 10 ans d'âge, on fait attention quand on refacto, et même si c'est hyper tentant de refacto en masse, il faut savoir se contenir…
Donc, je suis complètement d'accord avec toi :)
[^] # Re: relativité étendue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les commentaires..
Je préfère 10x un nom parlant à des commentaires. Je connais 2 sortes de commentaires : ceux qui noient le code et le rende illisible (genre une ligne sur 2 est un commentaire), au lieu de tout sortir des fonctions, ce qui empêche de voir la fonction en entier sur un écran, et ceux qui sont obsolètes.
"La première sécurité est la liberté"
[^] # Re: relativité étendue
Posté par barmic . Évalué à 4.
Personnellement j'ai remarqué que la taille des fonctions que j'écris excède rarement 20 lignes. Donc je suis assez large avant d'arriver à une méthode qui ne s'affiche plus sur un écran (même avec un netbook).
Les commentaires me servent pour décrire certains aspects qui ne sont pas facile à faire ressortir dans un code. Il ne dois pas décrire ce qu'on fait mais pourquoi on le fait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: relativité étendue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
100% d'accord
Si le code est moche, il vaut mieux le changer, il y a de grande chance que malgré le commentaire, il pose problème plus tard.
"La première sécurité est la liberté"
[^] # Re: relativité étendue
Posté par freem . Évalué à 2.
Ce n'est pas toujours possible, pour diverses contraintes.
Genre: usine à gaz qui pète à la moindre modif (cause principale: variables globales, je vous hais!), manque de temps, fonction qui fait le café, le thé et accessoirement qui effectue une tâche utile, etc.
[^] # Re: relativité étendue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je vois. Je déteste ce genre de code. Le genre de pile de patchs locals sans architecture global. Le truc qui casse à chaque modification.
"La première sécurité est la liberté"
[^] # Re: relativité étendue
Posté par freem . Évalué à 2.
C'est ça. Sentiment partagé, rassures-toi, mais dans ce type de code les commentaires sont un mal nécessaire, et on ne peut nettoyer le bordel que petit à petit… et croiser les doigts pour ne rien casser au passage.
[^] # Re: relativité étendue
Posté par xcomcmdr . Évalué à 3.
J'ai l'impression d'être au boulot après le boulot là…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: relativité étendue
Posté par freem . Évalué à 2.
Je suis d'accord, mais parfois il n'y à pas le choix.
Tu as oublié:
Mais c'est clair: je suis aussi du genre à préférer éviter les commentaires que je le peux, par exemple un truc genre "i = 2* 3.14 * r; //3.14 is PI" n'apparaîtra jamais dans mes codes. Je préfère faire une constante et lui filer la valeur 3.14… bon, avec PI, c'est trivial, mais un autre exemple déjà cité ici:
i = 0x5f3759df - ( i >> 1 );montre que ça ne l'est pas toujours… (oui, je trouve ce truc crade, peu m'importe qui l'a écrit à l'origine. Les magic values, c'est déjà pas top, mais quand en plus c'est pas mis dans des constantes… berk)[^] # Re: relativité étendue
Posté par totof2000 . Évalué à 2.
Tu as oublié le plus horrible : le code lui même mis en commentaire suite à des modifications.
[^] # Re: relativité étendue
Posté par Moonz . Évalué à 1. Dernière modification le 04 octobre 2014 à 11:37.
Pour le coup ça me choque pas, ça permet à quelqu’un qui reprend le code dans 10 ans et qui se dit « j’ai besoin d’un peu plus de précision » de voir du premier coup d’œil comment faire sans avoir à comprendre le reste du code.
[^] # Re: relativité étendue
Posté par totof2000 . Évalué à 3.
Mais dpuis 10 ans, le code en question ne correspond à rien parce qu'il y a plein d'autre code qui a été ajouté entre deux et d'autres modifications ont été faites.
[^] # Re: relativité étendue
Posté par freem . Évalué à 3.
Mouai… il paraît que c'est à ça que servent les VCS, en fait. Avoir le source d'origine, et la liste des patchs qui y ont été appliqués avec en prime, un commentaire de leur auteur.
[^] # Re: relativité étendue
Posté par Moonz . Évalué à 1.
C’est pas une question d’historique (à priori on a toujours voulu de cette précision, c’est pas un changement), c’est une manière simple, concise et rapide d’expliquer une partie de l’algorithme, une manière élégante de dire «
y * ( threehalfs - ( x2 * y * y ) )c’est juste une manière de s’approcher du résultat, on peut le faire autant de fois qu’on veut pour avoir la précision souhaitée, mais pour ce qui nous intéresse, une seule itération suffit », moi qui ait jamais entendu « Newton-Raphson » avant aujourd’hui (et qui n’a rien compris du reste de l’algorithme), j’ai compris ça du premier coup. C’est donc un commentaire efficace :)[^] # Re: relativité étendue
Posté par barmic . Évalué à 3.
Et mettre ça dans une boucle qui itère
precisionfois,precisionétant un entier défini avant et laisser au compilateur le soin de dérouler la boucle ça ne te paraît pas plus clair ?Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: relativité étendue
Posté par freem . Évalué à 3.
Soit tu réponds à autre chose (je pense que c'est ça ) et dans ce cas je me permets de rappeler ce dont on parle ici:
Soit je n'ai rien compris à ton propos, soit tu dis n'imp.
On parle de code qui fut utile un jour, et qui ne l'est plus. En général, ce type de code est le résultat d'un bug ou d'une évolution, et l'on à donc mis en commentaire l'ancien pour y revenir plus vite si la nouvelle version merde.
Au bout de 10ans, tu peux te retrouver avec 3 versions de la même fonction, 2 bugguées (mais tu ne sais pas quel était le bug) et 1 est une ancienne version complète…
Et quand tu dois attaquer un petit code source de, disons, 5000 lignes, et que tu te retrouves avec 200 lignes de zombies, ben voila, ça aide pas à la compréhension.
[^] # Re: relativité étendue
Posté par freem . Évalué à 4.
Non non, c'est ce que j'appelle du code zombie :) il est mort mais pas totalement…
# C'est plus général que ça.
Posté par fmaz fmaz . Évalué à 5.
Dans tout artisanat (sans le sens noble du terme), on a une notion de beauté.
L'exemple caricatural à mon avis est celui d'un médecin qui parle d'une « belle plaie ».
# L'avis de Joel Spolsky sur la question
Posté par dinomasque . Évalué à 3.
http://www.joelonsoftware.com/articles/Wrong.html
En substance : il faut avoir un peu de métier pour appréhender réelement la "propreté" et la "beauté" du code.
BeOS le faisait il y a 20 ans !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.