Discussion :

[RyzenOC]

- ses dépendances (trop = très mauvais )

Je ne suis pas d'accord avec vous sur ce point.
Un bon code dois justement utiliser a mon sens un maximum de bibliothèques/dépendances existante (si nécessaire bien sur), car en générale, les développeurs (dont moi y compris) réinventent très mal la roue.

En python j'arrive a faire un code aussi puissant que si je l'avais fais en C ou en assembleur, car j'utilise des bibliothèques bien optimisé, pour le calcule scientifique par exemple, je défis quoiqu'onques de faire un code plus performant que numpy (qui est fais en C).
numpy est conçue par de brillant mathématiciens et ce depuis plus de 10ans , aucun développeur ne peut faire mieux dans le temps qui lui est impartis pour faire son projet, et même au delà, je connais très peu de personnes qui soient des génies en informatique et en mathématiques.

- certains tours de passe-passe permettant de raccourcir le code

C'est le gros défauts des langages de haut niveau, manipuler par les débutants.
En php ou en python, on arrive a faire de ces trucs que parfois on se demande comment le langage peut accepter de telles ineptie.

[Invité]

Hmm, j'entends bien, mais

Quid de l'optimisation ? Car je peux très bien faire une analogie flagrante avec la paperasse administrative, plus il y en a et moins c'est rapide de les faire, et puis ça me donne un peu mal de tête quand je vois tous ces protocoles de communications dues à trop de questionnement à la chaine.

Et cela rend la compréhension du code à la fois complexe et compliqué.

Enfin perso je veux absolument jouer la carte de la transparence, c'est vraiment un but fondamental selon moi, plus que tout.

Peut-être la solution est "d'optimiser" la fonction mère au lieu d'enfanter des fonctions sur fonctions

Pour le php et python ? ^^ surement je ne l'ai ai jamais essayé, enfin ma première ligne du code était en python: 2 + 2

Sinon il y a aussi le fait de warning/error qui empêche ces "hacks" ^^

[el_slapper]

Hmm, je vois ce que tu veux dire, mais

Quid de l'optimisation ? Car je peux très bien faire une analogie flagrante avec la paperasse administrative, plus il y en a et moins c'est rapide de les faire, et puis ça me donne un peu mal de tête quand je vois tous ces protocoles de communications dues à trop de questionnement à la chaine.

Et cela rend la compréhension du code à la fois complexe et compliqué.

Enfin perso je veux absolument jouer la carte de la transparence, c'est vraiment un but fondamental selon moi, plus que tout.

Le truc, c'est le bon et le mauvais développeur. Réduire les dépendances, quand on est meilleur que lamoyenne, c'est une bonne chose. Quand on est nul, c'est se priver de la seule chance de faire illusion. La plupart d'entre nous sont plus souvent dans le camp des "nuls". Perso, si il s'agit de traiter un fichier comptable en masse, j'en ai tellement bouffé que je peut faire mieux que n'importe quel outils supposé me faciliter la vie(j'en ai usé quelques uns). Mais pour la plupart des tâches standard simples, envoyer un mail, afficher un bouton, si je n'ai pas de bibliothèque, je suis mort.

Éliminer les dépendances, c'est bien gentil, mais encore faut-il avoir le niveau pour faire ça.

[qnope]

Je ne suis pas d'accord avec vous sur ce point.
Un bon code dois justement utiliser a mon sens un maximum de bibliothèques/dépendances existante (si nécessaire bien sur), car en générale, les développeurs (dont moi y compris) réinventent très mal la roue.

En python j'arrive a faire un code aussi puissant que si je l'avais fais en C ou en assembleur, car j'utilise des bibliothèques bien optimisé, pour le calcule scientifique par exemple, je défis quoiqu'onques de faire un code plus performant que numpy (qui est fais en C).
numpy est conçue par de brillant mathématiciens et ce depuis plus de 10ans , aucun développeur ne peut faire mieux dans le temps qui lui est impartis pour faire son projet, et même au delà, je connais très peu de personnes qui soient des génies en informatique et en mathématiques.



C'est le gros défauts des langages de haut niveau, manipuler par les débutants.
En php ou en python, on arrive a faire de ces trucs que parfois on se demande comment le langage peut accepter de telles ineptie.

Plus rapide que numpy en C? Probablement pleins de débutant sur CUDA ou OpenCL .

[RyzenOC]

Plus rapide que numpy en C? Probablement pleins de débutant sur CUDA ou OpenCL .

Pas sur, déjà faut une bonne carte graphique.
Ensuite CUDA, faut de l'Nvidia, je crois que sur AMD ou intel sa doit marcher (jamais essayé), mais sa ne serait pas du tous optimisé.
OpenCL, je ne connais pas.

Utiliser CUDA ou OpenCL sa a des contraintes. Sur mes serveurs ou je développe avec numpy, y'a des Xeon a 5000€, mais pas de carte graphique.
Au dernière nouvelle, les gros calcules se font sur des serveurs, et en générale les serveurs n'ont que des processeurs.

D'ailleurs, je serais intéressé qu'il ait un benchmark, entre un processeur a 1000€ et une carte graphique a 1000€ pour ce genre de calcule.

[DonQuiche]

skeleton:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
close loop
{
    if (keyboard(z, q, s, d, alt, ²) or mouse(right_click + move_mouse)) is active, then
    {
        if msg = (alt + ²)                 , then quit the close loop
        if msg = (z, q, s, d)              , then move   the camera
        if msg = (right_click + move_mouse), then rotate the camera

        clear the screen
        update the scene(object) (by applying object rotation/movement and camera rotation/movement      )
        update the screen        (by project the scene into the array_screen through perspective equation)
        show   the screen        (by send the array_screen to the screen                                 ) 
    }

    show the frame per second
}

Voilà à vous maintenant de définir votre conception de l'art.

Voici un code (pas un squelette)

Code ruby :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
until UserAskedToQuit?() do
   UpdateCamera()
   Update(object)
 
   ClearScreen()
   Raster()
   Present()

Non je ne vérifie pas qu'un nouveau rendu soit nécessaire : dans un jeu il y a toujours des animations ou autres, cette optimisation n'a donc aucun intérêt ou trop marginale pour justifier la pollution du code. Et oui j'ai sous-divisé et augmenté le nombre d'appels de functions, ce qui ne pose aucun problème puisqu'on parle de quelques appels par frame, soit 0,0001% du budget CPU de la frame.

[Invité]

Non je ne vérifie pas qu'un nouveau rendu soit nécessaire : dans un jeu il y a toujours des animations ou autres, cette optimisation n'a donc aucun intérêt ou trop marginale pour justifier la pollution du code. Et oui j'ai sous-divisé et augmenté le nombre d'appels de functions, ce qui ne pose aucun problème puisqu'on parle de quelques appels par frame, soit 0,0001% du budget CPU de la frame.

J'ai fait cette opti car mon moteur fonctionne sur CPU (je n'utilise pas le pipeline du gpu) et soit très rudimentaire pour l'instant (monde fixe)
Donc autant ne pas bouffer trop de temps CPU ^^

J'appelle ça squelette, car il faut bien que je montre son fonctionnement en globalité, même en C je ne peux retranscrire un tel "code", donc en gros c'est un peu un résumé de ce qui se passe en interne.
Et je pense que je vais m'en servir pour mieux documenter ma source (m'à l'air du bonne idée) ^^



Sinon pour le sujet principale, j'ai beau être un fanatique de l'asm/programmation, mais le simple fait qu'il y ait ce genre de débat montre clairement le fait (même dans le milieu professionnel) que certains ne sont pas d'accord sur le point de ne voir la programmation que comme un simple vulgaire outil ne servant qu'à créer des softwares à la chaine.

Qu'est-ce cela veut dire ? que pour beaucoup, ils ont déjà copié la mentalité des consommateurs intégralement et ont perdu leur âme de programmeur (bon ok j'y vais un peu fort)
Oui cela sert à créer des softwares, mais aussi à choisir quelle est la plus belle manière de le faire, le choix technologique, d'évoluer sa créativité et son savoir (enfin l’acquisition du savoir est un peu le but ultime à tous programmeur, enfin pour certains, que pour vivre avec surement)

Alors, mais à quoi bon faire tout ce micmac pour au final n'avoir qu'un logiciel ... tout ça pour n'avoir que cette récompense -_-
Et bien, je dirais que la récompense n'est pas forcément le logiciel, mais le savoir et l'expérience, c'est cela même la récompense, même si elle n'est qu'intellectuelle et non visible

Et donc au lieu de ne vénérer que les logiciels et en faire leurs promotions, on devrait plus faire la promotion de comment ils ont été conçus, mais ça m'étonnerait que les médias acceptent x)



La programmation n'est pas un outil comme les autres, il est vraiment spécial
Même les fanas de mécanique ne sont pas aussi fanatiques que certains programmeurs sur le regard qu'ils ont avec leurs outils, je pense

[lankoande]

Ahh !
Très rigolots ces pubs.
On ne pourra jamais s'entendre sur ces choses là.
La beauté c'est quelque chose de subjective, c'est comme le goût.
Vous pouvez faire l'expérience, pour un même logiciel intérroger
many users et vous verrai !

[DonQuiche]

On ne pourra jamais s'entendre sur ces choses là.
La beauté c'est quelque chose de subjective, c'est comme le goût.

On peut au moins s'entendre à peu près sur ce qu'est un code propre. D'ailleurs certains enseignent même comment en écrire : Clean Code.

[pcaboche]

Qu’est-ce qu’un beau logiciel ? Quelle est la place de la technologie et la qualité du code dans la création d’un beau logiciel ?

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

[Jitou]

Un solution logicielle pourra être dotée d'une implémentation "sexy" selon le développeur mais comme déjà souligné ce qui importe au final ce sont le gain de productivité apporté pour l'utilisateur et la maintenabilité future de la solution.

Beaucoup de développeurs oublient qu'une fois développé un logiciel va vivre et être utilisé probablement quotidiennement. Cet aspect peut facilement être éludé car la plupart du temps le développeur n'échangera jamais avec les utilisateurs finaux au cours du développement du projet, son intervention se terminera définitivement à la livraison du projet et il repartira alors sur un autre projet chez un autre client. Certains problèmes d'implémentation et/ou de conception rencontrés au court du développement et impactant la maintenabilité ne seront pas résolu par gain de temps d'autant que le projet sera confié vraisemblablement à un prestataire qui alors héritera des malfaçons.

De ce point de vue, certain clients peuvent regretter l'époque révolue des "services informatiques internes" d'avant la main mise des SSII sur le marché, et dans lesquels les développeurs étant aussi des experts fonctionnels investis dans leur mission et surtout très proches des utilisateurs finaux.

Mon expérience m'a montré que dans 90% des projets l'utilisateur final n'a pas participé à la définition du projet, ni à la recette (souvent réalisé par une société de service tierce). Enfin la maintenabilité future reste un préoccupation largement sous évaluée. Croyez moi le client fini par payer très cher son projet ... il y a beaucoup de négligences que l'on se permet dans les projets informatiques qui seraient rédhibitoires dans d’autres industries.

[Luckyluke34]

C'est peine perdue de tenter de définir un logiciel en termes de beauté, c'est une notion tellement floue et subjective que personne ne l'associera jamais aux mêmes caractéristiques. On est déjà à des années-lumière de l'ombre du poil d'un accord sur ce qu'est un logiciel maintenable, une UI ergonomique, du code lisible, même entre développeurs qui utilisent le même langage et les mêmes approches. Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

[Invité]

Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

Si on ne peut pas se mettre d'accord, alors autant partager notre définition d'un beau code comme je l'ai fait, rien que pour le savoir et non plus pour en débattre.

[e-ric]

C'est peine perdue de tenter de définir un logiciel en termes de beauté, c'est une notion tellement floue et subjective que personne ne l'associera jamais aux mêmes caractéristiques. On est déjà à des années-lumière de l'ombre du poil d'un accord sur ce qu'est un logiciel maintenable, une UI ergonomique, du code lisible, même entre développeurs qui utilisent le même langage et les mêmes approches. Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

On approche de la bonne réponse à la question. Le sujet est fondamentalement subjectif et ce fil de discussion risque de durer longtemps sans que l'on trouve un consensus. Qu'est-ce que la beauté en général ?

La beauté visuelle, je ne parle pas du code, est à graduer selon l'emploi du logiciel. Pour un produit d'usage professionnel, une compta par exemple, il n'est forcément utile, ni rentable, de faire quelque chose de sexy mais l'ergonomie et la fiabilité sont primordiale, pour un jeu vidéo, l'aspect esthétique, pas forcément la beauté, demeure fondamental.

Parler de la laideur d'un logiciel serait plus novateur et au moins, on aurait droit à de beaux trolls .

Cdlt

[reventlov]

Je ne sais pas si c'est un critère de beauté mais pour ma part j'apprécie énormément un code qui se comprend même sans commentaires. Surtout avec la POO (et même sans d'ailleurs, quelle drôle d'idée ), pour peut que les méthodes, les fonctions et les variables aient un nom bien choisi et bien catégorisé, les commentaires deviennent inutiles pour la compréhension de la logique du code. Et je trouve ça chouette Les choses simples s'énoncent simplement...

[foetus]

Surtout avec la POO (et même sans d'ailleurs, quelle drôle d'idée ), pour peut que les méthodes, les fonctions et les variables aient un nom bien choisi et bien catégorisé, les commentaires deviennent inutiles pour la compréhension de la logique du code. Et je trouve ça chouette Les choses simples s'énoncent simplement...

Je ne pense pas que ce soit vrai : tu peux faire du code bien ordonné, bien nommé ... ce que tu préfères en somme, mais il peut y avoir un mécanisme "bas niveau" qui soit tordu/ crade/ personnalisé/ bizarre et peut-être difficile d'accès.

Une analogie pourrie Tu as une belle voiture profilée/ racée avec tout: le volant, les sièges baquets, vraiment tout.
Mais tu soulèves le capot et là tu as un V5 en fonte qui fonctionne au colza sans bougies ... mais un moteur impeccable à tous les niveaux

[madmarsu]

Déjà, en premier lieu, si on veut qu'il existe (et s'il est issu d'une entreprise dont le but est d'être rentable, c'est très différent pour un(e équipe de) développeur(s) indépendant(e)), il faut qu'il serve à quelque chose, et en effet réponde à un besoin.

Là où ça se gâte généralement, c'est que ceux qui conçoivent ne se sont pas réellement renseigné sur le besoin (voire d'où est issu ce besoin), et comme l'adresser. Ensuite ils ne transfèrement pas forcément de la bonne façon à celles/ceux qui le réalisent. Quelquefois même on s'appuie sur des statistiques de haut niveau pour déterminer ce qui serait recherché/utilisé ou pas. Et on aboutit parfois à des trucs débiles (Ctrl-H et/ou Ctrl-F pour Remplacer/Rechercher dans un éditeur de texte connu, et deux clics mini pour retrouver cette fonction Remplacer qui autrefois était en accès direct. La faute à la statistique sus-mentionnée du nombre d'utilisateurs qui l'utilisent directement) ou qui satisferont une partie des utilisateurs mais pas les autres (autres qui, eux, utilisent 80% du logiciel, au lieu de 5-15% des premiers, majoritaires).
Et ça, c'est typique de l'approche top-down et/ou waterfall.

A contrario, en rapprochant développeurs et usagers, on a une chance d'avoir un "beau" logiciel : qui soit codé de façon pérenne (quel dév a envie de refaire du code pour une fonction similaire à celle de la semaine précédente ?), ergonomique (on a le retour client en live) et efficace (idem et ça inclut les performances). Et ça, c'est ce que l'on peut obtenir via des "Sprints" en Scrum, avec un résultat plus rapide et surtout plus proche du besoin.

Là où la beauté intervient réellement, c'est dans l'évolution du logiciel. Car un logiciel qui n'évolue pas (sauf à répondre à un besoin qui n'évolue pas non plus), c'est beau, mais pas longtemps : un autre le remplacera inéluctablement. Il deviendra donc inutile... Ce sera un vieux beau. Exit.

[ChristianRoberge]

« Un beau logiciel résout un problème, et il le fait mieux que tout autre » Très d'accord sur ce point... Mais c'est un critère très subjectif qui laisse beaucoup de place à l'interprétation et à du folklore...
L'inclusion de TROP d'entête en est une. Il faudrait plutôt dire que l'appel inutile d'entête dégrade un code et, indirectement sa "beauté".
L'utilisation de bibliothèque C performante ne remplie pas "faire mieux qu'un autre" n'en déplaise aux adeptes de ces librairies. C'est du folklore maintenant basé sur des vielles histoires (souvent véridiques). En C++ moderne, il pratiquement toujours possible de faire mieux que dans l'ensemble des libraires scientifiques (ou autre) C ou Fortran qui ont été optimisés depuis des décennies. L'exemple du qsort par Stroustrup lui-même est assez éloquent sur le sujet (Voir https://isocpp.org/blog/2014/12/myths-3 ) mais je pourrais en apporter de nombreux autres. Aujourd'hui même avec un minimum de talent en C++, la performance sera au pire égal aux vielles routines C.

Une idée, une vision différente du problème, conduisent quelque fois à des "beaux" logiciels. C'est la voie que je privilégie. Développer un "beau" logiciel qui fait mieux que les autres en y consacrant seulement plus de temps est rarement un avenue très fructueuse. Voici ce que je conseillerait à ceux qui veulent développer des "beaux" logiciels, des logiciels d'exception:

1. Cultiver vos idées en vous informant continuellement. N'ayez pas peur de sortir de votre discipline ou spécialité.
2. Soyez un programmeur paresseux. Habituellement, plus vous avez un code concis, meilleure sera les performances.
3. N'hésitez pas à sortir des sentiers battus. Si vous le faites, de grâce, ne réinventer pas ce qui existe déjà ailleurs.
4. Expérimentez toutes les facettes de ou des langages que vous utiliser. Les changements majeurs de versions d'un langage sont un moment idéal pour se mettre à jour. À la limite, n'hésitez pas à regarder l'assembleur pour connaître la version la plus efficace dans un contexte donné.
5. N'ayez pas d'idées préconçues sur qui peut être fait ou pas avec un langage. Mon exemple classique est mon utilisation d'un "ou exclusif" entre 2 pointeurs. C'est en soit une opération qui n'a pas de sens. Vous ne verrez pas cela dans aucun bouquin mais c'était le détail qui donnait un avantage marqué sur tous les autres logiciels du marché de cet époque.

[devEric69]

Ça n'est pas une polémique, c'est une précision que je veux apporter, car je lis des choses sur Apple en exemple de "beauté de logiciel": c'est à mes yeux un constat qui sonne trop proche d'un slogan marketing. Apple, c'est plus compliqué que cela entre terme d'OS. Quand on parle d'Apple, il existe l'Apple d'avant 2001 et l'Apple d'après 2001: Apple a laissé tomber son ancien OS 100% fait maison, (trop bogué, avec Apple-Talk et d'autres à côté) et donc aussi ces clients historiques (j'en connais, fans historiques depuis le révolutionnaire Macintosh; ceux qui avaient les moyens d'en avoir un faisaient saliver les autres; qui n'ont pas eu d'autre choix que de jeter 15-20 ans de code-source à la poubelle, au moment même où le slogan publicitaire "Apple, l'ultime mise à jour de votre PC" fleurissait partout sur les panneaux publicitaires. Pour un fan de la première heure, ça voulait dire "Apple passe sous l'architecture hardware PC qu'ils ont si longtemps critiquée" ). Ils utilisent depuis le code source de FreeBSD, clang et Grand Central Dispatch. De ces libérations open-source, ils créent leur propre mouture, avec leur charte graphique. Donc à mes yeux, Apple n'est pas ce que j'appellerais le meilleur des exemples pour parler de la beauté d'un logiciel surtout en matière d'OS (les vrais acteurs qui écrivent un bel OS de A à Z, sont Microsoft, Linux, freeBSD, ...).

Ou plutôt, Apple est un exemple intéressant qui prouve que le beauté d'un logiciel commence par un code source bien écrit sur le fond (leur constat de survie en 2000-20001), maintenable avec une IHM visuellement compréhensible, sous peine de devoir l'abandonner tôt ou tard. Ensuite, appliquer tel ou tel peau sur les fenêtres, c'est la touche finale de beauté forcément subjective, sur la forme.

Sinon, un logiciel, c'est du temps capitalisé pour résoudre au mieux un problème récurrent: donc faire passer subtilement dans le ressenti de l'utilisateur, le temps ou l'argent que son utilisation lui dégage, peut être une piste à creuser pour lui donner le sentiment d'utiliser un bon/beau logiciel.

[devEric69]

Apple a laissé tomber son ancien OS 100% fait maison[/B], (trop bogué, avec Apple-Talk et d'autres à côté) et donc aussi ces clients historiques

Erratum: Apple avait édité à cette époque un "kit de transition" pour migrer de leur ancienne architecture-OS-100% maison, vers le monde PC-Intel+nouvelle mouture personnalisée de BSD.