Très bel exemple d'humilité et de collaboration! On reconnait ainsi de vrais scientifiques.
Version imprimable
Très bel exemple d'humilité et de collaboration! On reconnait ainsi de vrais scientifiques.
Et les études du GIEC, c'est en python ??? :mrgreen:Citation:
Envoyé par _informix_
Vous devenez un peu lourds.
C'est pas comme si un bug célèbre ne venait pas de temps en temps défrayer la chronique que ce soit dans le firmware des CPU, dans les OS: Windows, Linux, OSX, bibliothèques SSL,... tous y passent.
Les bugs font partie des risques de cette industrie.
Et lorsqu'on trouve un, on en parle histoire que ceux qui pourraient être impacté soient alertés et installent les corrections.
C'est juste ce qu'il se passe ici.
Après on peut toujours trouver "dommage" que seul quelques professionnels aient la rigueur nécessaire pour coder et puissent profiter des avancées de l'industrie du logiciel pour utiliser de la POO, écrire des suites de tests, des installations qui les tournent en continu pour s'assurer des non-régressions.
Est ce que toutes ces précautions nous affranchissent de découvrir un bug en production? Même pas. Il y en a toujours qui passent à travers.
Il ne faut pas oublier que si l'informatique à un intérêt, c'est pour ce qu'on en fait: les applications qu'elle permet de réaliser.
Et des applications, c'est d'abord des besoins utilisateurs qui vont souvent se débrouiller pour répondre à leurs besoins avec un code certes pourri mais qui le fait à peu près (regardez l'histoire de PHP).
Pas toutes auront la chance d'être vues comme des killers apps potentielles qui mériteraient d'être "industrialisées". Quand çà arrive, on fait appel a des professionnels pour les remettre d'équerre.
Comment croyez vous qu'ont démarré des monstres comme Exchange ou SAP?
Heureusement que c'est comme çà, car sans toutes des nouvelles applications (combien imaginées par les informaticiens?), beaucoup d'entre nous n'auraient pas de boulot.
Le GIEC compile les résultats sortis de plusieurs modèles d'évolutions du climat qui tournent sur des super calculateurs.Citation:
Envoyé par jpiotrowski
Comme on a besoin de performances, on va utiliser des bibliothèques écrites en Fortran ou en C depuis des dizaines d'années (les lois de la physique changent moins vite que les modes informatique). Au dessus, il y a peut être une couche de Python histoire d'avoir une interface un peu plus facile (c'est à çà que sert un langage de script). Python n'est pas ici un sujet.
- W
Bonjour tout le monde,
Voici le lien du code source original de la publication : https://www.nature.com/articles/nprot.2014.042#s1
Cet article montre deux problèmes hélas aujourd'hui très courants :
1) le libre est bien souvent moins contrôlé que les produits d'éditeur et cela pour une raison simple. La vente engage la responsabilité de l'éditeur qui fait payer sa prestation, son objet, son bien... Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.
Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.
Chez les éditeurs, cette problématique oblige à passer de nombreuses batteries de tests afin d'éviter de se retrouver pénalisé en cas de faute.... Dans le libre la pression étant inexistante, les bugs sont nombreux et les tests bâclés (lorsqu'il y en a !).... Il n'est qu'a voir le nombre incroyable, de bugs qui persistent dans MySQL/MariaDB (par exemple le fameux GROUP BY qui donne des résultats faux et jamais corrigé depuis l'origine) pour s'en convaincre...
2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !
A +
Salut,
Avant d'utiliser en production un logiciel libre, on prend quelques précautions comme de savoir ce qu'en font ses utilisateurs. On peut aussi regarder dans la buglist les problèmes soumis et les réponses apportées. Et comme on a les sources regarder un peu les cas d'utilisation qui ont été testé.Citation:
Envoyé par SQLpro
Après ben on teste (même pour les logiciels produits par les éditeurs) que çà produit les résultats attendu dans les cas d'utilisation qu'on souhaite.
Et s'il y a plein de bugs et que la communauté des utilisateurs râle ben on utilisera autre chose.
Libre = gratuit mais il y a un autre travail à faire
Le problème est dans le code qui a été écrit avec Python et non dans Python.Citation:
Envoyé par SQLpro
Quand un chercheur ajoute une étape de traitement qui permet de sortir la fréquence des molécules qu'il réalise pour valider une étude... Il doit publier son code pour que d'autres puisse reproduire ses résultats.
Après si d'autres chercheurs réutilisent ce code pour leurs traitements, on n'est pas dans la production logicielle mais dans les échanges normaux d'une communauté scientifique.
La plupart des logiciels libres qui ont pignon sur rue peuvent être utilisés librement ou avec un contrat commercial.Citation:
Envoyé par SQLpro
Si le client veut de la daube pas cher, on lui livre de la daube pas cher et pleine de bugs. Et si les commerciaux des SSII se couchent devant le client pour faire du chiffre plutôt que d'assumer leur rôle de conseil et dire au client qu'il faut mettre un peu les moyens en fonction la criticité de l'application pour sa production....Citation:
Envoyé par SQLpro
Sûr qu'avant on avait des techniciens tant du côté entreprise que développeurs, aujourd'hui un commercial rencontre le directeur des achats et çà discute pépète.
Mais c'est pas un problème de logiciel libre/éditeur, c'est juste des organisations et des patrons qui ont oublié qu'ils n'y a pas que des objectifs financiers...
Ah ces mecs du Sud, toujours dans l’exagération :mouarf:Citation:
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
- W
Et il y aura toujours des pékins pour dire que c'est normal qu'il y ait des bugs car c'est du libre, tout en étant sévères à l'extrême lorsque des logiciels propriétaires comportent des failles. Et ce sont ces mêmes personnes qui promeuvent l'usage du libre en entreprise et dans le milieu pro. Bref...Citation:
Envoyé par SQLpro
Il est vrai que l'Agile est parfois/souvent un prétexte pour ne pas s'enquiquiner (pour rester poli) à trop réfléchir et formaliser en amont et à traiter les sujets à vas-y comme je te pousse.Citation:
2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !
Il y a un article à rédiger sur la face sombre des méthodes dites Agile.
Tout cela me rappelle une anecdote où des résultats en chimie avaient été faussés parce que l'on utilisait des conteneurs en plastique au lieu de conteneurs en verre.
À qui la faute ?