TImaniac a écrit 6420 commentaires

Il faut ajouter un point avant free.fr

Oué enfin tu vois j'ai pas envie de me taper toute la doc et le cvs pour aller y décrouvrir les quelques lignes de Python révolutionnaire. Je voulais que tu me donne l'exemple de code académique.
Pour Erp 5 effectivement j'avais pas approfondi.

En même temps l'esquimau il peut taper avec ses 2 moufles, un moufle sur chaque bouton.

Nan mais donne moi un morceau de code qui me montre la puissance de Python en diminuant le nombre potentiel de bug.
Quand à Erp5, j'ai dis pas un logiciel libre, qui pour la plupart ne répondent pas à un besoin spécifique à un temps donné avec un temps et un coup imparti.

Montre moi un morceau de code en Python qui apporte une expressivité conséquente, susceptible de produire moins de bug.
Un langage dynamique est avant tout permissif avant d'être expressif.
Evidemment que les tests contribuent à améliorer la qualité du code.
Mais c'est une vérité générale, appliquée depuis longtemps, mais qui ne résoud absolument pas le problème de la complexité des grands projets.
Ici on cherche d'éventuelles nouvelles approches, Python n'a absolument rien de révolutionnaire, et les tests unitaires sont plutôt au stade de pratique industrielle extrêment courante.

Ah oui une autre question : combien de projets en Python de plusieurs millions de ligne de code ont été produits dans des délais impartis par un cahier des charges ? (bref pas un logiciel libre avec un roadmap "dynamique" si tu vois ce que je veux dire)

La problématique est ici de réduire le nombre de bugs dans des projets conséquents.
Python et les langages à typage dynamique n'ont jamais aidé dans ce sens, de part leur nature.

Question : vous connaissez beaucoup de monde qui utilise ce logiciel au réseau fermé ?
Perso : je connais personne.

Tout à fait d'accord, du moment que ca reste justement des "patrons" simples et courament utilisé, sinon le langage risque de devenir trop complexe et/ou élitiste/trop spécialisé.

Maintenant cela m'amène à une question : le langage doit-il se contenter de s'adapter au programmeur, ou doit-il innover en poussant le programmeur ?

Je pense que le plus sage serait de vous adresser à mon collègue le forum :)
http://linuxfr.org/forums/(...)

Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs.
C'est pas LA solution, mais c'est une partie de la solution.
Si personne ne s'était penché là dessus on en serait encore à code en assembleur. J'espère que t'as pas peur pour les centrales nucléaires :)

Il se contredit à quel moment ? J'ai rien vu.
Il se contredit en ce sens qu'il dit qu'il faut dépenser de la thune, mais que d'un autre côté les outils adaptés ca sert à rien.

Hors quand tu développes un soft pour une centrale nucléaire, il lsuffit pas de dire "je suis milliardaire, j'embauche des milliers de gens compétents" et pouf t'as un logiciel sans bug. Ca c'est du n'importe quoi.

Il faut des gens compétents ET des outils adaptés (tu prends Schumacher tout seul, ca sert à rien sur le circuit s'il a une voiture de merde). Ce sont également ces derniers qui coûtent cher, car ils induisent du temps humain supplémentaire (Les langages formelles et le VB ne demande pas tout à fait le même effort), mais permettent d'obtenir des garanties.

Alors oui à l'arrivée le coût va être sur les feuilles de paies des ingénieurs, mais les outils adaptés sont nécessaire, contrairement à ce qui laissait entendre.

Je me suis mieux fait comprendre ?

Mmmh tu te contredis, même si au final tu conclus comme il faut :

Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs.

Ensuite :
une seule solution pour faire baisser les bugs : cracher les thunes
Crasher des thunes pour ? Ca sert à rien de mettre des millions dans un projet pour qu'il soit sans bug si tu as une équipe de merde qui code en VB.
Alors oui il faut de la thune, mais il faut aussi des méthodes et outils (langages) adaptés, qui coûte cher surtout en ressources humaines.

Nan mais tu disais qu'une feature demandant un bouton particulier doit pouvoir être accessible à partir d'un menu... Ce qui n'est pas possible, sauf dans un menu contextuel bien entendu.
Enfin tout ca pour dire que plusieurs boutons sur une souris c'est parfois utile, d'ailleur ce sacré steevy a sorti des sorties à plusieurs boutons récemment si je ne m'abuse.

Et tu fais comment dans un menu pour dire que tu veux que le lien que tu survoles s'ouvre dans un nouveau tab ? Nan parcque pendant que t'es dans le menu tu survoles plus le lien :)

ils font comment sous Mac pour le clic-milieu-tab-mozilla ?

En dehors de tous langages, c'est le patron de conception observateur, qui peut être implémenté dans à peu prêt tous les langages, pas que C++.

http://www.dofactory.com/Patterns/PatternObserver.aspx(...)

1/ Tout le monde n'est pas capable de maîtriser B et même les bases de la logique. Tu fait partie d'une élite, ne l'oublie pas :-) Voir mes posts plus haut.
C'est justement là où je voulais en venir : la difficulté n'est pas de coder en soit, mais de réussir à formaliser toutes les spécifs, parcque la plupart du temps on fait confiance à notre intuition qui nous "vas y fonce t'as à peu prêt capter, code !"
B nous force à écrire ce qu'on croit savoir de manière intuitive, et c'est là que justement on tombe sur de nombreux problèmes : spécifs foireuses, absente ou partielle, etc.
Soit on veut un truc sans bug, c'est possible mais ca prend ouachement de temps (à poser nickel les spécifs), soit on prend une solution intermédiaire, en posant plus ou moins bien les spécifs.

Ce que je veux dire, c'est qu'il n'y pas de miracle : tant qu'on n'a pas réussi à mettre "carr"" les spécifs, on ne codera rien sans bug. Et l'intuition va souvent à l'encontre de cet objectif en court-circuitant l'étape de la mise au "carré".

2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.
gni ? Tu peux faire du multi-héritage. Et je vois pas trop le rapport avec UML, UML est un langage de modélisation, pas de spécification.

l'OO oblige souvent à des contortionnement pas possible pour gérer des choses simple
? Un exemple ?
Non parcque en objet tu peux tout modéliser, à n'importe quel niveau d'abstraction. Un objet peut être une entité de donnée comme une entitée manipulant des données ou un concept de baeucoup plus haut niveau, il peut encapsuler un protocole, une notion temporelle, il y a une liberté totale.
Donne moi un exemple qui demande des contorsions en objet.

Arf, ils ont juste voulu éviter les effets d'annonce à 2 balles, du coup ils se sont donnés 2 mois pour pouvoir montrer un minimum de travail, je vois pas où est le problème... On doit demander l'autorisation à des gens susceptibles pour se lancer dans un codage maintenant ?

Pour l'écriture de logiciel moins complexe, mon opinion personnelle:

Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept abstrait.
Moi j'ai l'opinion inverse : plus le langage est de haut niveau, plus il laisse le temps au programmeur de manipuler des concepts abstraits, bref à se focaliser sur la conception de l'appli.

Tu parles du succès de VB et PHP : ce n'est pas tant le fait qu'ils soient des langages de haut niveau (tu parles plus bas de Java qui est d'aussi au niveau), c'est qu'ils sont des langages "simples" et accessibles aux débutants.

"Pas de fonction, que des variables globales, pas de gestion memoires, etc... et souvent les codeurs sont pas tres vieux.
Mais ca marche."
Ca marche, je dirais plutôt ca marchouille : mais c'est pas réutilisable, c'est inmaintenable, bref, c'est rarement concluant. Ou alors il faut revenir en arrière en suivre la démarche traditionnelle contenant étape de conception avec expression de concepts de haut niveau etc. Auquels cas ces langages deviennent tout de suite moins adaptés.


Apprentissage => Tous les developpeurs devraient connaittre par coeurs les motifs de conception basique. (design patterns du gof)
Tout à fait : mais t'en vois beaucoup dans les projets PHP/VB codés par des geeks de 13 ans ?
Bof hein :)

OSS est totalement fonctionnelle, c'est juste une version 100% open source de SUSE Linux, sans soft proprio.
Les 2 sont gratuits, ca dépend de ton niveau d'implication dans la religion "Free Software".

A part faire de la pub pour ton langage préféré en nous disant qu'il va révolutionner ta life et enlarger ton 5ème membre, tu nous expliques le rapport avec le journal ?

J'ai un peu du mal à trouver une cohérence à l'ensemble de l'article mais bon y'a des réflexions intéressantes :)

Ca commence par un constat : y'a des bugs.
Oué bah oué. Au niveau langage on a déjà atteind l'objectif de perfection dans ce domaine : convertir tout programme en preuve mathématique.
Exemple : langage formel B. Tu peux t'assurer qu'il n'y a pas de bug dans le programme. Mais on arrive à un constat : bien que le programme est correct, on n'obtient pas le résultat escompté : pourquoi ?

L'article laisse sugérer des bugs "architecturaux". Les bugs sont tout simplement dans les spécifications elles-même. On s'en rend compte en utilisant les langages de type langage B : toute la difficulté consiste à poser sur le papier TOUTES les spécifications, et des spécifications justes.

Et là on sort des langages informatiques, les spécifications sont écrites (dans un premier temps avant d'êtres traduites en langaeg formel) en langage naturel. Difficile de trouver plus intuitif. Malheuresement si cette étape là n'est pas correcte, tout ce qui en découlera ne pourra pas l'être.
Hors plus un logiciel est complexe, plus ses spécifications sont conséquentes, et plus il est difficile de les appréhender et de les formaliser sur le papier.

D'où l'idée qui date pas d'hier de découper le problème en sous-problème, INDEPENDAMENT de tous langages informatique.

Après coder les spécifs reste relativement simple et automatique si celles-ci sont correctes.

Voilà tout ca pour dire qu'il ne faudrait pas faire l'erreur d'introduire trop de complexité dans le langage en introduisant de nouveaux concepts, alors que paradoxalement cela aurait été fait dans le but de mieux appréhender la complexité de la tâche à accomplir.

Un langage doit être là pour fournir des outils permettant au programmeur d'exprimer la plus large gammes de concepts et d'idée. La seule véritable contrainte, c'est de faciliter la solution n°1 : découper le problème en sous-problème. Bref, proposer la sémantique de grosses et petites boîtes. Le concept objet est parfait pour cela.

Pas plus d'une information par journal, ça embrouille le lecteur !
Pareil je me suis fais la même réflexion, mais après 10 minutes de recherche j'ai été incapable de trouver une liste des nouveautés apportées par la distribution, il est vraiment mal foutu leur site où j'ai du mal ?

Ca c'est des critères beaucoup plus justifié : tu parles du service de résiliation, qui lui est bien dépendant de Free.
Moi je critiquais juste les remarques concernant le débit, vu que personne n'est dans la même situation avec la même ligne, c'est impossible de comparer.

Et puis c'est super facile de récupérer tous les fichiers, même si la table des partitions est effacée, un très bon système de fichier de sauvegarde en gros :)
Nan parcque quand mon ext3 tire la tronche ca me fait autrement plus paniquer :-/