Discussion :

[Justforfunmedia]

Pour moi, l'art est quelque chose de subjectif sujet à interprétation
Bref, c'est tout l'inverse de la programmation
Le dev, ce n'est pas un art, c'est de la technique
Après, il peut y avoir une bonne maîtrise / utilisation de la technique, mais ça reste de la technique.

Avec l'art, en fonction de la personne qui l'admire, elle peut aimer ou détester et la comprendre à sa manière (qui peut être radicalement différente de celle de l'auteur).
Avec le code, si le compilateur comprend à sa sauce le code, c'est qu'il y a un bug quelque part

L'art n'a pas que le sens de « beaux-arts » : en plus des arts de l'artiste, il y a l'art de l'artisan, qui lui aussi réclame une technique, c'est-à-dire un ensemble de règles à respecter.

[Saverok]

L'art n'a pas que le sens de « beaux-arts » : en plus des arts de l'artiste, il y a l'art de l'artisan, qui lui aussi réclame une technique, c'est-à-dire un ensemble de règles à respecter.

Dans ce cas, il y a de l'art dans la conception, pas dans le développement.
Un artisan n'a pas la vocation à ce que son travail soit repris par d'autres à de multiples reprises durant des années.

Un ébéniste, par exemple, lorsqu'il fabrique un meuble, celui ci n'a pas vocation à être transformé sans arrêts par d'autres artisans au fil des années.
Par contre, si ce meuble a vocation a être produit en série, il n'y a plus vraiment d'art dans sa reproduction car ce n'est que l'exercice de technique. L'art se trouvait dans la conception du meuble.

C'est la même chose en cuisine.
L'art de la conception des plats revient au chef.
Son équipe en cuisine maîtrise les techniques qui permettent de reproduire ce plat.
Par ailleurs, le plat produit n'a pas vocation à être modifié par d'autres.
Une fois préparé, il est consommé.

Le code, c'est un peu la même chose.
J'accepte volontiers qu'on parle d'art pour la conception : Maîtriser les techniques et savoir conceptualiser la meilleure solution à un problème.
Par contre, dans la réalisation, bref, le code, il n'y a que de la technique.
C'est technique est indispensable pour que le programme produit soit compréhensible par d'autres et puisse évoluer sur des bases connues de tous (car respectent des standards).
Autrement dit : le respect des standard est incompatible avec l'art.

Il n'y a absolument rien de péjoratif la dedans.
On peut être un excellent technicien, un virtuose même, sans être un artiste pour autant.

Sans compter que tous les artisans ne sont pas des artistes.
C'est bien 2 termes différents et il y a des raisons à cela.
(mon beau frère est plombier et je crois qu'il rirai beaucoup si je le qualifiais d'artiste. Alors que c'est un très bon artisan et commerçant qui prend beaucoup de plaisir dans son travail et dit en passant, gagne bien plus que moi alors que j'ai 4 ans d'étude de plus...)

Pour finir, l'avantage avec la technique, c'est qu'elle peut être évaluée et mesurée en toute objectivité.
Le travail en est apprécié à sa juste valeur.

L'artiste, c'est nettement plus subjectif.
De ce fait, il y a énormément de sur évaluation et de désillusion.
La très grande majorité des artistes décèdent sans que leur art ne soit jamais compris et/ou apprécié.

C'est sans doute mon esprit cartésien mais je préfère être un bon technicien et vivre de mon savoir faire qu'un artiste inconnu sans le sous...

[Escapetiger]

Dans ce cas, il y a de l'art dans la conception, pas dans le développement.
Un artisan n'a pas la vocation à ce que son travail soit repris par d'autres à de multiples reprises durant des années.

Un ébéniste, par exemple, lorsqu'il fabrique un meuble, celui ci n'a pas vocation à être transformé sans arrêts par d'autres artisans au fil des années.
Par contre, si ce meuble a vocation a être produit en série, il n'y a plus vraiment d'art dans sa reproduction car ce n'est que l'exercice de technique. L'art se trouvait dans la conception du meuble.

C'est la même chose en cuisine.
L'art de la conception des plats revient au chef.
Son équipe en cuisine maîtrise les techniques qui permettent de reproduire ce plat.
Par ailleurs, le plat produit n'a pas vocation à être modifié par d'autres.
Une fois préparé, il est consommé.

Le code, c'est un peu la même chose.
J'accepte volontiers qu'on parle d'art pour la conception : Maîtriser les techniques et savoir conceptualiser la meilleure solution à un problème.
Par contre, dans la réalisation, bref, le code, il n'y a que de la technique. (...)

Je trouve cette séparation beaucoup trop manichéenne (tout "noir" ou tout "blanc"), plutôt typiquement française d'ailleurs, avec ce système hiérarchique (issu du centralisme "parisien ?) dont nous avons le plus grand mal à nous dépêtrer alors que nos métiers évoluent vers plus d'autonomie et de responsabilité, vers un aplatissement de la "pyramide".

Pour en revenir à la dualité conception/réalisation, on dit en français, l'art et la manière de faire les choses.
Il s'agit bien de création.
C' est valable pour la fabrication des meubles en série aussi, pour les bons petits plats préparés avec amour, pour le codage informatique, etc...

[Théolude]

Encore une étude statistique à l'américaine qui annonce des résultats fabuleux sur une méthodologie douteuse...

Un échantillon de 250 personnes, sur 650 lignes de codes ? Certes ils ont certainement développé une méthode intelligente et perspicace... mais étendue à la vraie vie (nous sommes combien de développeurs dans le monde ?) ça risque vite de donner n'importe quoi comme résultat.

Toujours prendre avec beaucoup de circonspections ces grandes annonces ...

[tails]

Je trouve que cela est une bonne chose pour détecter les auteurs de malwares.

En revanche, à cause des différentes conditions pour les droits d'auteur (notamment la difficulté à comprendre correctement ce qu'implique une licence GPL 2/3), les perspectives ne me plaisent pas trop dans cette direction. En clair, avant de vouloir sanctionner à tout prix, il faudrait selon moi d'abord chercher à clarifier davantage les choses.

Après, ce n'est que l'humble avis d'un simple passionné ...

[abgech]

"...sa préférence pour les espacements au lieu des tabulations, sa préférence pour les boucles ‘While’ plutôt que pour les boucles ‘For’, la règle utilisée pour nommer ses variables, l'alignement des blocs de code, etc., mais aussi par sa manière de mettre en œuvre certains types de fonctionnalités. ..."

En voilà une découverte qu'elle est importante !

En ce qui me concerne, quelques mois de correction de travaux d'étudiant et j'étais arrivé à la même conclusion il y a bien longtemps !

Décidément, je dois être un génie ! MDR

[Saverok]

"...sa préférence pour les espacements au lieu des tabulations, sa préférence pour les boucles ‘While’ plutôt que pour les boucles ‘For’, la règle utilisée pour nommer ses variables, l'alignement des blocs de code, etc., mais aussi par sa manière de mettre en œuvre certains types de fonctionnalités. ..."

En voilà une découverte qu'elle est importante !

En ce qui me concerne, quelques mois de correction de travaux d'étudiant et j'étais arrivé à la même conclusion il y a bien longtemps !

Décidément, je dois être un génie ! MDR

Entre pressentir quelque chose par l'expérience et le démontrer scientifiquement par un programme qui le met en oeuvre, il peut y avoir un monde
Je suis surpris de voir ce genre de remarque de la part d'un "enseignant chercheur"

[gangsoleil]

Entre pressentir quelque chose par l'expérience et le démontrer scientifiquement par un programme qui le met en oeuvre, il peut y avoir un monde
Je suis surpris de voir ce genre de remarque de la part d'un "enseignant chercheur"

Ce programme ne prouve absolument rien. Tout au plus valide-t-il ce que beaucoup de gens savent par expérience, et les conclusions de l'article ne sont pas issues de démonstrations quelconques, mais bien de réflexions...

"On pourrait s'en servir pour faire de l'identification", c'est bien gentil, mais regarde bien le paragraphe "limitations" :

We have not considered the case where a source file might be written by a different author than the stated contestant, which is a ground truth problem that we cannot control. Adding extra dummy code to a file without affecting the functionality will represent a different coding style as long as the features from the extra code are extracted. The adversary can evade the classifier by this method but detecting such an addition to code is trivial through manual analysis.

[ChristianRoberge]

Cela me surprenant aucunement. J'irais même plus loin. Nos expertises passée teintent notre présent, et là je ne parle pas de programmation... Durant, les années j'étais un programmeurs TOP niveau en FORTRAN durant mes études doctorales. Même si je suis à des années lumières du Fortran et du type de programme que je faisais à l'époque, je suis toujours surpris de constater les fortes différences avec les programmeurs plus jeunes n'ayant pas eu ce genre d'expérience et la coloration Scientifique/FORTRAN de mes codes.

[bassman13]

Bah c'est de l'analyse de signature non ? Rien d'extraordinaire, sinon que d'exprimer une application à la reconnaissance de codeur.
L’intérêt est dans la finalité, pas dans la méthode employée.

[frantzgac]

Il est plus facile d'identifier l'auteur d'un code lorsque celui-ci est qualifié (capable d'exécuter les tâches les plus difficiles) que lorsqu'il est moins qualifié. « Cela pourrait indiquer que lorsque les programmeurs deviennent plus avancés, ils construisent un style de codage plus fort par rapport à des débutants. Il y a une autre possibilité que peut-être de meilleurs programmeurs commencent avec un style de codage plus unique», selon les chercheurs.

Un "style de codage plus fort" est une expression au sens plutôt évasif.
Je propose une explication plus précise : les développeurs expérimentés adoptent des règles personnelles de plus en plus strictes et nombreuses au fur et à mesure de leur expérience car cela leur permet d'inférer à coup sûr de quelle manière ils ont codé une séquence. On sait tous qu'une part importante du travail du développeur est de retrouver la ligne de code qui effectue une fonction précise parmi des milliers de ligne. Donc savoir retrouver une ligne de code écrite trois ans plus tôt nécessite de savoir comment on l'a écrite même si on ne s'en souvient pas, grâce aux règles régulières. les développeurs plus débutants ont un style moins figé et varient les méthodes de sorte que leur code est davantage imprévisible. Il n'est donc pas surprenant que les règles d'écriture des aguerris soient aisées à repérer puisque plus nombreuses et plus stables.