Page 2 sur 2Précédent 1, 2La vérité ...

[Pernmith]

Dans les entreprises, libre ou non, qui ont un impératif de temps = argent, oui effectivement, tant que ça marche, c'est pas grave s'il faut plus de mémoire...

Je trouve que c'est un peu réducteur -tant que ca marche n'est pas le seul argument-:
-ca dépend de l'utilisation qui est faite du logiciel produit. Ainsi par exemple, lorsqu'il s'agit de bureautique ou de logiciels destinés au PCs de bureau, l'impératif d'occupation mémoire est secondaire. Par contre, lorsque nous produisons un logiciel embarqué, par exemple dans un central téléphonique, la place occupée par le logiciel devient très importante.
- les langages de programmation modernes comme le C++, C#, java, consomment nettement plus de ressources que leur prédecesseurs. En contre partie, ils offrent plus de possibilités, par exemple dans les domaines des communications ou des interfaces utilisateurs. Ce que l'utilisateur perd en utilisation de ressources mémoire ou disque, il le gagne en simplicité de paramétrage, d'utilisation et de mise en oeuvre.
- les données stockées prennent elles aussi plus de place: un fichier texte comme aide en ligne comme on pouvait le trouver a l'époque (ouille, je me fais vieux) est maintenant replacé par un fichierd 'aide interactif avec vidéos et démonstrations, un bip pour indiquer une erreur est remplacer par un beau fichier son...

[AntoineP]

Aujourd'hui, on "pisse" du code plutôt que de faire un vrai travail de développement, non ?

Ah bon...

[ttoine]

Dans les entreprises, libre ou non, qui ont un impératif de temps = argent, oui effectivement, tant que ça marche, c'est pas grave s'il faut plus de mémoire...

Je ne remet pas en cause ce que dit Pernmith sur le travail des développeurs, bien au contraire, je suis le premier à faire des documentations complètes de 10 pages avec pleins de captures d'écran pour les utilisateurs débutants, alors qu'il suffit souvent de quelques lignes de terminal...

Je voulais dire par là que dans certains cas, les développeurs ne prennent pas le temps d'optimiser le code. Bien souvent, pour la même fonction, il est possible de faire un code mieux conçu, et donc plus léger. Seulement, l'optimisation du code, ça prend plus de temps que ce qui "vient à l'idée" du premier coup.

Et quand le temps est primordial, et que l'on considère par exemple que les pc sont toujours plus puissants, on ne cherche pas à optimiser. Et c'est dommage...

Toine

[ibinico]

ttoine >> Merci pour les liens.

[Invité]

Dans les entreprises, libre ou non, qui ont un impératif de temps = argent, oui effectivement, tant que ça marche, c'est pas grave s'il faut plus de mémoire...

Je ne remet pas en cause ce que dit Pernmith sur le travail des développeurs, bien au contraire, je suis le premier à faire des documentations complètes de 10 pages avec pleins de captures d'écran pour les utilisateurs débutants, alors qu'il suffit souvent de quelques lignes de terminal...

Je voulais dire par là que dans certains cas, les développeurs ne prennent pas le temps d'optimiser le code. Bien souvent, pour la même fonction, il est possible de faire un code mieux conçu, et donc plus léger. Seulement, l'optimisation du code, ça prend plus de temps que ce qui "vient à l'idée" du premier coup.

Et quand le temps est primordial, et que l'on considère par exemple que les pc sont toujours plus puissants, on ne cherche pas à optimiser. Et c'est dommage...

Toine

On est d'accord...

Quand je dit que l'on "pisse" du code, c'est simplement pour montrer que (comme bien trop souvent) les délais priment sur la réflexion...au risque de devoir replâtrer après.

C'est pas une critique, c'est un constat

[AntoineP]

Quand je dit que l'on "pisse" du code, c'est simplement pour montrer que (comme bien trop souvent) les délais priment sur la réflexion...au risque de devoir replâtrer après.

Replâtrer, patcher, améliorer, c'est une activité perpétuelle en informatique. Les seuls logiciels terminés sont les logiciels morts. Quand tu écris un logiciel, c'est pour des utilisateurs, et il vaut mieux donner à tes utilisateurs le plus tôt possible quelque chose d'imparfait à se mettre sous la dent, plutôt que de leur faire miroiter la perfection dans une durée inconnue.

Release often, release early : une des règles canoniques du logiciel libre. Voir aussi : Le mieux est-il l'ennemi du bien ?

Et, oui, Debian a totalement tort quand ils laissent leurs versions officielles prendre du retard à ce point ; ils le savent d'ailleurs, Ubuntu en est la preuve.

[Invité]

Quand je dit que l'on "pisse" du code, c'est simplement pour montrer que (comme bien trop souvent) les délais priment sur la réflexion...au risque de devoir replâtrer après.

Replâtrer, patcher, améliorer, c'est une activité perpétuelle en informatique. Les seuls logiciels terminés sont les logiciels morts. Quand tu écris un logiciel, c'est pour des utilisateurs, et il vaut mieux donner à tes utilisateurs le plus tôt possible quelque chose d'imparfait à se mettre sous la dent, plutôt que de leur faire miroiter la perfection dans une durée inconnue.

Release often, release early : une des règles canoniques du logiciel libre. Voir aussi : Le mieux est-il l'ennemi du bien ?

Et, oui, Debian a totalement tort quand ils laissent leurs versions officielles prendre du retard à ce point ; ils le savent d'ailleurs, Ubuntu en est la preuve.

Quitte à fournir des softs insécurisés ou qui foirent à qui mieux mieux ?

[AntoineP]

Quitte à fournir des softs insécurisés ou qui foirent à qui mieux mieux ?

Il y a deux types de bugs : ceux qu'on connaît déjà et ceux qu'on ne connaît pas encore.

Ceux qu'on ne connaît pas encore, c'est en demandant aux gens de tester le logiciel qu'on les trouve. D'où l'intérêt de faire des sorties fréquentes, et d'adopter un mode de développement ouvert et public.

Ceux qu'on connaît, on ne peut pas forcément les corriger tous. Tout logiciel conséquent a un nombre trop grand de bugs connus pour qu'il soit souhaitable de les corriger tous avant une sortie. L'honnêteté commande par contre de les signaler aux utilisateurs (README, KNOWN_BUGS...).

Qu'est-ce qui te rend le plus service : un logiciel adapté à la tâche mais entâché de quelques défauts, ou un logiciel inexistant ? Si l'on programme pour soi, pour la frime ou pour le plaisir, il est envisageable de retarder énormément la sortie du programme pour en diminuer la faillibilité. Si l'on programme pour des utilisateurs, il vaut mieux leur donner quelque chose à se mettre sous la dent... Le logiciel libre a une part hobbyiste, mais il a aussi une responsabilité sociale vis-à-vis des gens qui l'adoptent ; c'est pour ça que le délai de sortie de la Debian est inacceptable.