Dans la veine des je trouve un article sur un service de twitterie et je le poste, en voici un juste pour le vendredi.
C'est un article rédigé par quelqu'un qui travaille chez Google de longue date, et qui publie un billet sur son blog par rapport à la complexité. Tout est dans le titre, il pense que le plus gros problème quand on programme est de faire du code qui travaille peu, le moins complexe possible.
J'en cite une partie pour faire la liaison avec mon précédent nourjal sur la POO :
new languages by novices tend to have lots of features, while few have the crisp clarity of C. In today's programs it's frequently related to how many objects are involved; in distributed systems it's about how many moving parts there are.
J'ai senti des appeaux à trolls dans ce billet. Et vous, qu'en pensez-vous aujourd'hui ?
# Merci captain Obvious
Posté par claudex . Évalué à 10.
Heureusement qu'il est là pour le dire, moi je pensais que le plus dur, c'était de faire un hello world.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Savoir choisir, plutôt que se restreindre
Posté par drakmaniso . Évalué à 10.
En matière de troll, j'avoue que qualifier Bjarne Stroustrup(1) de novice a le mérite d'apporter un peu d'originalité dans un domaine qui en manque cruellement.
Après, je pense que l'auteur du billet commet une erreur de raisonnement. Qu'un code simple et concis soit préférable, je pense que c'est particulièrement évident. Mais en conclure que la meilleure façon d'arriver à ce résultat est de se restreindre à des outils "plus faibles"(2), c'est aller un peu vite en besogne. Quelque soit l'outil, il est toujours possible de choisir un sous-ensemble de ses fonctionnalités et de s'y tenir. Choisir un outil adapté au problème reste le plus important, amha.
(1) suis-je le seul à devoir googler son nom à chaque fois?
(2) joli: mettre côte-à-côte deux trolls distincts sur C++ et sur C dans le même post…
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par rewind (Mastodon) . Évalué à 3.
C'est d'ailleurs ce que quasi tout le monde fait en C++, tout le monde évite l'héritage multiple, les exceptions, des dynamic_cast, etc. pour s'en tenir à un sous-ensemble proche de Java finalement. Ça tient à des raisons historiques (pour les exceptions qui ne marchaient pas bien à une époque) et/ou culturelles (difficile de faire de l'héritage multiple propre). Qt (vieux logiciel en C++) en est un bon exemple.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par claudex . Évalué à 3.
C'est d'ailleurs bien dommage qu'ils n'aient pas intégré les exception dans Qt4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par psychoslave__ (site web personnel) . Évalué à 2.
http://www.qtcentre.org/threads/2620-Qt-s-Exception-Handling
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par claudex . Évalué à 3.
Ça n'a rien à voir, je parlais des exceptions en utilisant le code de Qt, c'est normal d'utiliser les exceptions à côté mais ce n'est pas cohérent de devoir tantôt gérer les exceptions, tantôt gérer le retour de fonction en fonction de ce qu'on fait.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par fearan . Évalué à 4.
alors la je regrette j'ai bossé sur du code ayant de l'héritage multiple et j'ai moi même utilisé des dynamic_cast; quand aux exception je m'en sert, comme leur nom l'indique, lors de traitements anormaux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par 2PetitsVerres . Évalué à -3.
Les exceptions sont là pour traiter les cas exceptionnels si on se réfère à leurs nom, pas les cas anormaux.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par fearan . Évalué à 10.
Là c'est du pinaillage.
un cas qui sort de la norme, est pour moi une exception; si on peut pas ouvrir le fichier destination, je ne suis plus dans le fonctionnement normal (d'où anormal), et je pète une exception.
Par contre le bouton comme les autre qui est utilisé 1 fois tous les dix ans en prod n'est pas une exception, même si son usage est exceptionnel.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par Guillaume Knispel . Évalué à 3.
Ca dépend dans quel contexte. Si gérer l'échec d'ouverture d'un fichier fait parti des fonctionnalités apportées par le programme dans la plupart ou tous ses aspects (IHM, continuation du fonctionnement, etc.), cela n'est pas optimal d'utiliser les exceptions pour les traiter (sans compter que leur utilisation rend plus difficile l'analyse statique de correction). Si l'intégralité du programme est écrit de manière à ne pas se préoccuper des échecs d'ouverture de fichiers et en faisant semblant que ce genre d'échec n'existe pas, alors les exceptions sont évidemment indispensable pour éviter une avalanche catastrophique causée par l'erreur initiale.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par Croconux . Évalué à 7.
Ca ne fonctionne que si tu développes seul et que tu n'utilises aucune bibliothèque externe. Dès que tu utilises du code écrit par quelqu'un d'autre, c'est foutu. Le gros problème des langages "riches" (qui disposent d'un tas de constructions/paradigmes) c'est qu'il faut à peu près tous les maîtriser parce qu'on est susceptible de les rencontrer dans le code de quelqu'un d'autre.
Je partage en grande partie le jugement de l'auteur de l'article sur le fait que les langages récent en tendance à trop vouloir en faire et à sans cesse ajouter de nouvelles construction. C# en est un bel exemple selon moi (depuis les lambda, linq, var, dynamic,...). On devrait plutôt s'inspirer de la philosophie Unix : Un outil fait une chose et la fait bien, utiliser l'outil approprié pour chaque tâche.
Quand à prendre le C comme modèle de simplicité, l'auteur y va un peu fort. Il a peu de fonctionnalités mais c'est loin d'are un langage simple. Comme beaucoup de développeurs ont commencé avec le C, ça peut leur paraître simple aujourd'hui (un peu comme ceux qui ont été habitués à Windows ne sont plus choqués et trouve l'interface "logique"). Mais bon, les pointeurs ça reste compliqué pour beaucoup de développeurs occasionnels.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par drakmaniso . Évalué à 1.
Concernant la conception des langages, je suis entièrement d'accord.
Si je pouvais réécrire l'histoire de l'informatique, Forth aurait supplanté le C pour tout ce qui n'est pas extrêmement bas niveau. Eiffel (dans sa première incarnation) serait le plus populaire des langages objets. Lua remplacerait Python, javascript, Perl, PHP et (avec un peu d'adaptation) tous les shells…
Seulement, l'auteur ne se place pas du point de vue du concepteur de langage, mais de celui du développeur. Et son erreur, amha, est de penser qu'il faut un langage "simple" pour coder simplement.
Après, comme tu le fait remarquer, ce n'est pas toujours facile… Probablement plus dans l'open source qu'en entreprise.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par laurent laffont (site web personnel) . Évalué à 1.
Je préfère restreindre.
C'est ce que fait Smalltalk, la syntaxe tiens sur une carte postale et c'est extrêmement puissant.
Même pas de if, tout est objet, je reste impressionné par l'élégance et la simplicité des designs qu'on peut trouver.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par drakmaniso . Évalué à 0.
Ah, mais je ne dit pas qu'il faut fuir les outils simples, qui s'appuient sur quelques concepts puissants plutôt qu'une foultitude de fonctionnalités!
Au contraire, mes langages préférés tombent tous dans cette catégorie: Forth, Lua, Scheme, et dans une moindre mesure le regretté Eiffel. Je tiens Smalltalk en haute estime, même si je ne l'ai jamais pratiqué "en conditions réelles" (remarque, Forth non plus, hélas).
Je voulais simplement dire qu'il ne faut pas éliminer d'office un outil parce qu'il contient trop de fonctionnalités: parfois, il restera le meilleur choix.
D'autre part, même dans les langages "simples", il faut faire un choix, restreindre non pas la quantité de fonctionnalités qu'on va utiliser (vu que par définition elles sont déjà restreintes) mais la façon dont on va les utiliser. Par exemple dans Lua, un concept unique, la table, peut permettre une approche orientée classes, orientée prototype, simple conteneur, etc.
# Sujet du commentaire
Posté par Étienne . Évalué à 8.
[^] # Re: Sujet du commentaire
Posté par insert_coincoin . Évalué à 10.
[^] # Re: Sujet du commentaire
Posté par boq . Évalué à 5.
[^] # Re: Sujet du commentaire
Posté par Antoine . Évalué à 4.
# complexité ou complication
Posté par steph1978 . Évalué à 0.
J'avais posté MHO sur un sujet approchant.
http://fiveinthewood.wordpress.com/2011/02/16/complique-nest-pas-complexe/
Pour en revenir à ce post, je pense que cela a très bien été commenté par avis précédents.
# KiSS
Posté par i M@N (site web personnel) . Évalué à 2.
le [[Keep_it_Simple,_Stupid]] "Keep it Simple Stupid" (qu'on pourrait traduire par "Faites simple, stupide") va dans ce sens non?
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: KiSS
Posté par i M@N (site web personnel) . Évalué à 2.
pfff ... pourquoi il fonctionne pas la syntaxe Wiki?
http://fr.wikipedia.org/wiki/Keep_it_Simple,_Stupid
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: KiSS
Posté par claudex . Évalué à 5.
À cause de la virgule.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: KiSS
Posté par jean . Évalué à -1.
Pur la traduction je propose, je propose:
Je trouve ton faites simple plutôt bien parce que, même s'il s'éloigne un peu du sens en gardant bien l'idée (par exemple le it disparaît), garde la forme plutôt percutante de l'anglais.
Comme dans le film
Pour la deuxième
mais bon, c'est pas top.
# Digging deeper.
Posté par Thomas Douillard . Évalué à 1.
C'est un troll, donc j'ai pas lu l'article.
Cependant ça ne va pas bien évidemment m'empêcher d'y apporter ma pierre vu que c'est la règle du jeu :
Il préfèrerait quoi entre un langage avec pas mal de feature mais certaines qui sont vachement cool pour son problème et ammène à un design "cool" et peu complexe à un langage simple mais qui oblige à réinventer / réimplémenter des pseudos équivalents aux features en question, amenant à un code complexe du même coup, des features potentiellement chiantes à implémenter et par conséquent bug prone, peu matures et prises de tête ?
Certaines features haut niveau dans certains langages sont réfléchies par les concepteurs, bien implémentées et éprouvées, même si elles sont pas forcément simple à la base. Est-ce cacher la merde sous le tapis ?
[^] # Re: Digging deeper.
Posté par totof2000 . Évalué à 2.
Toi tu devrais te mettre à ADA.
[^] # Re: Digging deeper.
Posté par pasScott pasForstall . Évalué à 2.
C'est un peu ce que je me suis dit en lisant l'article. C'est un peu un melange de:
- Un outil simple c'est de la balle, parce que c'est super simple a utiliser. Ce qu'il oublie de mentionner, c'est que l'outil simple va te faire reimplementer la roue et que ca peux potentiellement etre une catastrophe (genre si tu reinventes la roue, mais que tu la construit voilee, c'est ballot quand meme non?). Typiquement avec du C, ca donnerais: c'est cool, la gestion de la memoire est super simple, t'as pas de pauses GC et autres. Par contre, t'es a peu pres sur de te taper des core dumps par ci par la, des fuites probables et les grosses appli se retrouvent a reimplementer leur propre GC parce que leur heap est tellement fragmentee apres un certain temps qu'elle en devient inutilisable...
- La complexite c'est pas cool, certes, moi je veux bien faire simple, mais les requirements sont ce qu'ils sont. On peut pas dire "pfouuuuyayaya, c'est complexe votre truc, vous voulez pas plutot un truc simple qui resoud pas votre probleme?"
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# "crisp clarity of C" c'est une blague?
Posté par reno . Évalué à 6.
Je te renvoie vers ce blog: http://blog.regehr.org/
C'est un gars qui entre autre s'amuse beaucoup à trouver les failles des compilateurs C,
et tiens-toi bien: il en a trouvé beaucoup()!
Pourquoi? Parce que le C n'est *pas simple.
Pas vraiment simple à implémenter.
Pas simple a utiliser: non-initialisation des variables par défaut, arithmétique signée/non-signée bordélique, pas de détection des débordements de calculs, etc.
Certes le C est bien plus simple que le C++ ou Perl, mais il serait possible de le rendre bien plus simple à utiliser,
utiliser Python comme du C comme le recommande le blog serait effectivement un bon début pour un langage simple.
*: beaucoup étant un terme relatif, si on compare avec des compilateurs C++, il y en a pas tant que ça bien sur..
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par Christophe B. (site web personnel) . Évalué à -2.
tout dépend comment c'est écrit, du C C++ comme du perl peuvent devenir
illisible.
Faites le test avec un bout de code qui fait la même chose écrit en plusieurs langages, et demandez l'avis a quelqu'un qui ne connait pas le/les langage(s).
Il vous dira que c'est compliqué parce qu'il ne connait pas.
le seul cas que j'ai rencontré ou un dev a compris ce que faisait un bout de code sans connaitre le langage c'était avec du python qui pour moi a l'énorme avantage d'être lisible.
après tout dépend de ce que vous voulez faire avec votre langage préféré.
c'est du code jetable, reutilisable, a maintenir pendant plusieurs années etc ...
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par nicolas . Évalué à 0.
« trouver les failles des compilateurs C »
« non-initialisation des variables par défaut, arithmétique signée/non-signée bordélique, pas de détection des débordements de calculs »
It's not a bug, it's a feature.
Très sérieusement il manque une très sérieuse connaissance du langage. Les comportement que tu décris ne sont pas des failles de compilateurs, mais sont les comportements standards du C.
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par reno . Évalué à 3.
Oui bah tu ferais mieux de lire plus lentement plutôt que de survoler et de citer dans le désordre..
Je marquais dans mon post que le langage C n'était pas simple à implémenter ET n'est pas simple à utiliser.
Pour la difficulté d'implémentation et les bugs des compilateurs, j'ai mis un lien vers un blog.
Pour la difficulté d'utilisations je citais des comportements 'standards' du C qui sont compliqués à utiliser en pratique.
Je connais très bien le langage C, merci.
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par Jak . Évalué à 3.
Je suppose que l'auteur du message précédent fait une raccourci rapide. Je suppose qu'il veut dire que le comportement du C (non-initialisation des variables, etc) EST une source de bug dans les compilateurs.
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Il me semble que c'est ce qu'il dit, puisque ce que tu cites est précédé de :
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par dave . Évalué à -1.
D'ailleurs, je me demande si ça existe des langages à déclaration automatique. Par example, si on fait
alors a est équivalent à "" et c est équivalent à 0. Parce que cela me semble logique comme fonctionnement. De rien.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par claudex . Évalué à 4.
En C++, c'est le constructeur par défaut qui est appelé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par rewind (Mastodon) . Évalué à 3.
En Go, toutes les variables sont initialisés à zéro par défaut.
[^] # Re: "crisp clarity of C" c'est une blague?
Posté par Krunch (site web personnel) . Évalué à 2.
En C, les variables qui ont une durée de vie globale sont initialisées à 0.
En Perl, c'est initialisé à "undef".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# A lire avant de dire du mal d'un langage
Posté par Christophe B. (site web personnel) . Évalué à 2.
Bonjour,
A lire pour choisir un langage :
http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/
# Compréhension
Posté par barmic . Évalué à 5.
C'est pas parce que l'auteur ne comprends pas une technologie ou un langage que c'est forcément compliqué. Le C aussi bien soit-il a un énorme défaut : il est pauvre à en crever. Résultat soit tu réinvente la roue (donc tu re-code des choses des choses pourtant très classique en y ajoutant tes bugs et ton manque de compétence dans des domaines précis) soit tu cherche une bibliothèque et chacun à la sienne, complémentaires mais pas totalement, qui se chevauchent un peu, pas vraiment compatibles entre elles,...
Face à des langages qui incorporent ces mécaniques et qui permettent de ce concentrer sur son problème et de le résoudre simplement, il n'y a pas photos.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compréhension
Posté par nicolas . Évalué à -2.
Plutôt que de dire que le C est pauvre. Tu voulais dire son éco-système de bibliothèques. Je pense que c’est intrinsèque au C, on en fait lorsqu’on veut une implémentation optimisée avec le problème à résoudre. Du coup quand on fait du C on ne s’attend pas, à priori, trouver une bibliothèque qui répond au besoin. Par contre des bibliothèques C, ce n’est pas ce qui manque…
[^] # Re: Compréhension
Posté par barmic . Évalué à 4.
Je n'ai rien compris à ce que tu dis. Pour moi le C est pauvre mais il a une myriade de bibliothèques (ce qui s'explique d'une part parce que c'est pas avec le langage de base que tu va aller très loin d'autre part par la position du langage dans l'écosystème des langages de programmation).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compréhension
Posté par nicolas . Évalué à 4.
Tu critiquais dans ton commentaire l’absence de bibliothèque standard, et en concluait que le langage est pauvre.
Ça n’a rien à voir.
Et je rajoutais que c’est inhérent à l’utilisation qui est faite du C. On s’attaque à un programme en C lorsque on veut quelque chose de rapide et optimisé pour son problème. Il est strictement impossible d’avoir une bibliothèque qui fasse l’unanimité dans ce cas.
Tiens par exemple : j’ai utiliser sorted hier, en standard dans Python. Quel est l’algorithme utilisé ? Est-il vraiment adapté à mon jeu de donné (presque trié en ordre inverse) ? Est-ce qu’il bascule d’algorithme quand le jeu de donnée à trier devient petit (vers un algo. plus rapide…) ? Quel est le critère de basculement ? Si je veux changer de critère (qui dépendra de la machine à priori), comment je fais ? Rien qu’un algo. aussi basique, il y a mille et une façon de faire. Les langages évolués masquent tout ça. Par contre si j’aurai à le faire en C, je le recoderai moi-même, pour retrouver cette liberté que Python ne permet pas (avec des performances acceptables).
Bref, j’arrive à la conclusion inverse : le C offre plus de liberté ⇒ le C est plus riche.
[^] # Re: Compréhension
Posté par Michaël (site web personnel) . Évalué à 2.
Tu as ô combien raison!
Et c'est tout aussi vrai. En pratique la réutilisabilité du code est très limitée dès qu'on s'attaque à des projets spécialisés. Par exemple, une bibliothèque implémentant un GET en HTTP ne seras probablements pas un bon point de départ pour écrire quelques chose comme curl ou wget. À l'inverse un programme ayant besoin de réaliser un simple GET en HTTP ne va pas le déléguer vers une bibliothèque aussi complexe que curl ou wget, si un choix plus simple est disponible.
Le C a été introduit pour écrire un OS (Unix dans mon livre d'histoire), il
est aussi utilisé pour programmer des machines (à laver, etc.): basiquement c'est du langage machine portable. Sur ce terrain il semble être incontesté.
Pour l'écriture de prototypes, on a intérêt à se tourner vers d'autres solutions comme le shell ou des langages à la Perl, Python, etc. et on peut faire sa vie avec un prototype!
[^] # Re: Compréhension
Posté par claudex . Évalué à 4.
Est-ce que ça ferra une différence sensible? Premature optimization is the root of all evil (or at least most of it) in programming. Si vraiment ça devient un goulot d'étranglement, tu pourra le réécrire en utilisant un autre algorithme (ou utiliser un package). Je ne comprend pas en quoi l'utilisation d'une méthode générique qui servira pour la plupart des utilisations empêche l'utilisation d'une méthode spécifique dans certains cas. C'est, pour moi, tout l'intérêt des bibliothèque standard bien fournies, elles ont des algorithme qui seront utile dans la plupart des cas.
Je ne vois pas quelles sont les libertés supplémentaires dans ce cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compréhension
Posté par nicolas . Évalué à 1.
« Est-ce que ça ferra une différence sensible ? »
Plus que les détails d’implémentation, sur de grands jeux de données, ne serait-ce qu’un truc aussi basique que le tri il y a des algo. qui vont de O(n) à O(n²), les plus rapides en moyenne peuvent être les plus lents en « pire cas ». Il vaut mieux avoir une idée du jeu de donnée à traiter et choisir l’algo. en fonction. À moins de vouloir les tester un à un…
Dans un de mes codes en arbre pour une recherche de voisins il y a un critère pour basculer sur l’algo. brut (pour tous couples test la distance), la différence était sensible lors de mes tests.
« Premature optimization is the root of all evil (or at least most of it) in programming. »
D’où vient cette idée ? J’ai déjà eu l’occasion d’exprimer mon désaccord à ce sujet : lorsque la rapidité une contrainte importante l’optimisation doit être pensée dès la conception. À moins de vouloir refaire le travail deux fois.
Je veux bien que dans un programme complexe, qui invoque multitude d’algo. on va pas chercher la rapidité pour une fonction qui ne s’exécute qu’une fois l’an et il vaut mieux savoir où chercher. Mais la plupart du temps on sait quelle portion de code est incriminée dans un calcul lourd…
[^] # Re: Compréhension
Posté par claudex . Évalué à 4.
Et, ça ne veut pas dire que l'utilisation classique de la fonction sorted montrera une différence.
De Knuth.
La citation ne s'oppose pas à ça.
Et donc à ce moment-là, tu utilise ton algo spécifique, en quoi c'est important que la fonction sorted de Python n'utilise pas l'algorithme que tu veux?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compréhension
Posté par pasScott pasForstall . Évalué à 4.
Regle de base d'optimisation: don't do it.
Deuxieme regle de base: ne touche a rien tant que t'as pas de chiffres et que t'as pas clairement identifie le plus gros goulet d'etranglement ET qu'il est avere que tu peux gagner qq chose de significatif.
Troisieme regle de base: le goulet d'etranglement n'est pas la ou tu le penses.
En gros, l'idee c'est d'architecturer ton appli en ayant une certaine idee d'ou les points chauds vont probablement se trouver, faire une implementation naive, mais pas trop non plus.
Ensuite, et seulement quand ca marche et que c'est fonctionel, tu peux conmencer a regarder ou le temps est passe, fixer un but a atteindre et commencer a travailler pour l'atteindre.
Tu passes ton temps dans ton layer db, c'est quoi le probleme? Requete trop couteuse, tu perds trop de temps a instantier des objets une fois la requete recue, ton pool de connexions est trop petit et tu prends un hit massif au moment de le faire grossir, tu fais trois requete la ou tu pourrais n'en faire qu'une? Les solutions vont etre diametralement opposees.
T'as une interface utilisateur qui est lente? Est ce du a une vue trop complexe, t'abuses du layout automatique et doit implementer ton propre layout, tu fais des fetchs reseaux/disque sur le ui thread, tu passes ton temps a creer/ajouter des widgets sur la scene, tu fais des refresh constamment sur une table de 200 000 elements? La encore, les solutions sont diametralement opposees.
Tes calculs sont trop lents, quel est le probleme? Code trop gros qui rentre pas dans le cache? Mauvaise localite des donnees qui te fait prendre un cache miss a chaque fois? Trop grande precision du calcul?
Mauvais tuning du gc ou tu retiens des objets trop longtemps, qui passent donc dans la generation superieure alors qu'ils ne devraient pas?
Dans chacun des cas donnes, il faut avoir une appli presque finie pour estimer quel est le probleme et y apporter une vraie solution.
Sinon tout ce que tu fais, c'est resoudre un probleme qui n'existe pas, voir potentiellement, tu vas passer du temps a pas le resoudre, si tu paries sur le mauvais cheval.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Compréhension
Posté par totof2000 . Évalué à 1.
C'est comme ça qu'on se retrouve avec des OS qui n'ont pas de perfs acceptables avant au moins le SP3, et avec des projets qui rament comme pas possible, pour lesquelq il faut un super calculateur de 40 CPU quad cores juste pour faire un Hello World.
Voila comment ça se passe :
- l'équipe technique estime qu'il faudra N jours pour développer l'appli et O jours pour les optimisations
- mais on peut pas, la sortie (ou la date de livraison) est déjà prévue
- ( Version OS) pas grave, on va revoir les prérequis pour faire tourner l'OS en ajoutant de la puissance CPU et de la RAM, ya une nouvelle version de processeur qui doit sortir. Au pire on sortira une version optiisée pour le SP2 ou SP3.
- (version appli) pas grave, on va revoir les prérequis pour faire tourner l'appli. Le constructeur doit sortir une nouvelle version de son hardware avec un CPU contenant plus de coeurs, et plus rapide.
Dans chacun des cas donnes, il faut avoir une appli presque finie pour estimer quel est le probleme et y apporter une vraie solution.
Ca dépend, il y a des tas d'applis ou on peut savoir par l'expérience ou vont se situer les problèmes de perf.
[^] # Re: Compréhension
Posté par pasScott pasForstall . Évalué à 0.
Non, ca c'est parce que le product manager veut un time to market court (eux aussi optimisent leur boulot :p) et "coupe les coins" de partout pour accelerer le dev. Ce qui saute le premier en general, c'est les tests unitaires, puis la QA, puis la doc.
Si t'as pas le temps, t'as pas le temps, prendre les optimisations trop tot va au contraire te faire passer du temps sans aucune garantie de performance au final, ce qui est tres exactement l'inverse de l'effet que tu souhaites dans le cas que tu decris.
Potentiellement, t'auras parie sur le bon cheval, potentiellement pas.
Surtout dans un truc aussi monstrueux qu'un OS ou des tas d'equipes bossent de leur cote et collent leur boulot ensemble a un moment donne.
Ou pas. Ya clairement des cas d'ecoles que tu vas eviter instinctivement parce que tu sais que ca performe tres tres mal, mais c'est pas de l'optimisation ca, c'est juste pas etre completement debile quand t'ecris ton code.
C'est pas comme si c'etait la base des bonnes pratiques, que meme des mecs dont c'est le boulot de regler des problemes de perfs te le diront, ne fait rien tot, ca a plus de chance de te faire perdre du temps au mieux que de faire quoi que ce soit.
Et quand tu fais qq chose, fixe toi un objectif clair a atteindre, sinon tu vas partir dans tous les sens et ne rien faire de valable.
Implemente ton algo d'abord, fait une appli fonctionelle, ensuite il sera temps de le faire tourner plus vite. Si t'en as besoin, parce que c'est meme pas dit que t'en ais besoin au final, ni que le temps passe a optimiser en vaille la chandelle.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Compréhension
Posté par barmic . Évalué à 3.
Tu as raison sur pas mal de chose. Moi je critiquais le fait de dire, le C est bon de manière absolue comme c'est dis dans l'article plus haut.
Avoir différentes implémentation de la libc et je ne sais combien de bibliothèque c'est bien, mais il faut reconnaître que ce n'est pas toujours la panacées. Comme tu le dis le C est génial quand tu veut voir ce qui se passe en vrai, toucher aux partie basses du système d'exploitation quand tu as des besoin en performances tel que tu veut choisir à la main quel appel système lancer et quand. C'est loin d'être le cas pour tous.
A noter que le C c'est tout de même un langage qui ignore les booléens ça montre tout de même sa pauvreté. C'est sa qualité et son défaut en fonction de ce que tu veut faire. Ce que je voulais critiquer c'est le fait de dire que c'est un langage qui conviens à tout.
Tu parle des tris, je n'ai jamais compris pourquoi tout les bibliothèques standard que j'ai vu n'en proposée qu'un seul alors qu'il est trivial d'en proposer 5 ou 6 (avec un par défaut). Mais normalement c'est pas un endroit ou ton programme doit beaucoup consommer, à partir du moment ou tu dois lancer régulièrement un tris sur un même conteneur c'est probablement un conteneur mal choisi. Les conteneurs trié (avec un tas par exemple) sont performant et permettent d'avoir un algorithme plus simple à lire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compréhension
Posté par houra . Évalué à 2.
mmh j'adore. :)
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Compréhension
Posté par Antoine . Évalué à 2.
Pour info :
http://hg.python.org/cpython/file/tip/Objects/listsort.txt
# La POO c'est de la Merde en barre
Posté par Pascal Lambert . Évalué à -10.
C est vrai que la programmation objet c est de la MERDE, avec un grand M.
ca ne sert qu'a une chose a rendre le programmeur FENEANT !
c'est du confort pour ses petits yeux de cropette !
on garde un interpreteur pour les objets pour l'execution !
c'est forcement plus lent qu'une co;pilation complete!
et on pete de joie !
[^] # Re: La POO c'est de la Merde en barre
Posté par barmic . Évalué à 3.
Apprends à écrire.
C'est une qualité chez le programmeur.
Ce qui permet de mieux voir l'algorithme.
Le C++, le D et tout un tas d'autres langages sont objet et sortent un binaire ELF à la compilation. Mais je te conseil de regarder les journaux que nous avons eu sur shinken qui est un serveur écris en python qui est plus gère mieux la montée en charge que nagios qui est écris en C.
Pour faire des remarques comme tu le fais c'est probablement que tu est un script kiddy (en C oui) qui n'a pas eu à toucher à des vrais programmes là où l'algorithme utiliser et l'architecture du logiciel ont plus d'impact que le langage utilisé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La POO c'est de la Merde en barre
Posté par claudex . Évalué à 1.
Il faut quand même précisé que c'est une architecture différente qui a été utilisé. Même si ça montre bien que le langage ne fait pas tout.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La POO c'est de la Merde en barre
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Le langage à quand même une influence sur l'architecture de ton projet non ? Bien sûr on peut tout exprimer plus ou moins facilement dans n'importe quel langage, mais bon.
[^] # Re: La POO c'est de la Merde en barre
Posté par claudex . Évalué à 1.
Si je me souviens bien, c'était tout à fait possible de le faire en C (puisque ça devait être intégré à Nagios à la base) mais ça a été fait en Python parce que l'auteur préfère ce langage et développe plus vite avec.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La POO c'est de la Merde en barre
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Si le langage te permet d'avancer plus vite sur le projet, c'est qu'il est plus adapté non ? Surtout si derrière l'utilisation d'un langage plus bas niveau n'apporterais pas d'amélioration significative des performances.
[^] # Re: La POO c'est de la Merde en barre
Posté par claudex . Évalué à 0.
Ou que le développeur le connaît mieux.
On ne le saura sans doute jamais.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La POO c'est de la Merde en barre
Posté par pasScott pasForstall . Évalué à -3.
Essayes de faire de l'injection de dependance automatique (autowiring) proprement sans annotation. On peut pas toujours exprimer qq chose, meme si le langage est turing complet :)
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Sémantique trop bas niveau
Posté par Ontologia (site web personnel) . Évalué à 5.
Le problème majeur des langages de programmation est leur sémantique trop basse, et aussi leur inadéquation à la conception intuitive du monde.
Quel que soit le paradigme, le problème est à peu près le même : on pense en terme de "termes" ou de case mémoire contenant des données qu'il faut manipuler, transmettre via des canaux, etc...
L'ordinateur se programme de cette façon parce que les langages de programmation ne sont qu'une série de sucre syntaxique qui descendent directement des câblages à la main des premières machines construites à la sortie de la seconde guerre.
Reconnaissons quelques inventions majeures : L'objet (Simula/Smalltalk), la programmation logique/par contrainte, l'inférence de type (Caml).
L'humain qui programme doit donc, dans chaque paradigme, penser dans cette logique de "terme" (en langage fonctionnelle et logique) ou de zone mémoire que l'on va faire manipuler par une suite d'instruction qui manipules ces termes/zones de mémoire.
Un humain ne conçoit pas intuitivement le monde ainsi que le traitement de données qui en sont une représentation, de cette façon.
Pour un humain, le monde est un système multi-agent où les agents ont des croyances/connaissances, des désirs, des intentions. On a tendance à prêter des intentions aux choses qui nous entourent ("Putain de lacet à la con, tu va bien vouloir te défaire ???!!!! T'as décidé de m'emmerder hein ??!?"). Observez une heure, vous verrez ;-)
De plus, ces agents s'inscrivent dans un espace-temps. On a tendance à étendre cette notion d'espace-temps un peu partout : quand on stocke un fichier dans une arbo, il y a une notion de localisation dans l'espace, psychologiquement.
Il nous arrive de mélanger les notions : "c'est assez loin dans le temps, j'ai du mal à me souvenir", certaines langues du pacifique mélangent d'ailleurs cette notion de loin/proche qui s'applique indifféremment au temps ou à l'espace.
Le temps et l'espace n'est pas représenté explicitement dans les langages, donc des choses qui peuvent être simple à expliquer peuvent facilement être difficile à programmer.
Et quand ces choses sont elles-mêmes complexes, ça peut devenir très très complexe !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.