Journal : Python et les décideurs
Posté par Gilles G. () le 20 novembre 2007
0
Bonjour à tous,je suis actuellement en train de pousser dans ma boite pour pouvoir développer en Python (au lieu de Java).
Les bonnes raisons pour utiliser Python sont:
* c'est simple
* c'est rapide à développer
* c'est flexible
* c'est vraiment simple...
* j'aime bien Python
Les deux gros obstacles que je rencontre dans mon argumentation sont:
* java saymieux (sans arguments c'est plus facile)
* Python c'est pas fiable puisque c'est dynamique
* on trouve facilement des développeurs Java alors que personne connait Python
* Python c'est lent
(Vous pouvez d'ailleurs constater que même des gens qui ne connaissent quasiment pas Python sont capable de troller comme des malades)
Je sais répondre calmement et de manière argumentée à la plupart des trolls (c'est dur de trouver un développeur Python??)
J'imagine que je ne suis pas le premier qui se retrouve face à ce genre d'argumentation sans trop de fondements, et je commence à avoir envie de troller à mon tour dans l'autre sens.
Je suis donc à la recherche de trolls (sauvages et poilus) sur Java-et-ses-potes histoire de lutter à armes égales avec mes adversaires...
Merci d'avance!
PS: si vous avez des vrais arguments, ça m'intéresse aussi.
> Lire le journal (70 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #883754.
Run by 
Cette page a été générée par Templeet en 0.0981s (dont 0.0099 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Analysons les arguments
Ce n'est pas pour te contrarier mais regardons tes arguments :
* c'est simple => Java aussi ...
* c'est rapide à développer => Java aussi ...
* c'est flexible => Java aussi ...
* c'est vraiment simple... => Java aussi ...
* j'aime bien Python => Bon, il reste celui là ...
Donc de leur point de vue, tu veux qu'ils passent à python, parce que tu aimes bien python.
Bon regardons leurs arguments :
* java saymieux => Bon laissons tomber celui là
* Python c'est pas fiable puisque c'est dynamique => N'importe quoi, on est d'accord
* on trouve facilement des développeurs Java alors que personne connait Python => Là, ils marquent un point : les ressources Java courent les rues, les devs python moins.
* Python c'est lent => Java aussi était lent au début, et je ne suis pas sur que le python soit tellement plus lent que Java maintenant (en tout cas pas de quoi le disqualifier).
Bref, plutôt que de chercher des trolls contre Java, cherche plutôt de _bons_ arguments pour les convaincre (dans tel projet, le python permettrait de faire ceci qui aurait l'avantage de ...).
Sinon, propose d'écrire une partie en Jython, comme ça tu fais du Java, mais tu fais du python :-)
Vache qui rit, à moitié dans son lit
[^]Re: Analysons les arguments
J'aime bien python, mais je suis d'accord avec le coté "pas fiable puisque c'est dynamique". Pour des programmes simple, c'est très pratique car on peut manipuler facilement des listes (concaténation, filtrage...), et quand on n'a pas envie de créer un type, on utilise un tuple ou une liste.
Mais quand le projet grossi, utiliser de vrais types, avoir un typage statique, ça aide beaucoup. Et tant qu'à faire, je préfère que le compilateur vérifie tout ça pour moi.
Conclusion: ça dépend de tes projets. Pour les programmes utilitaires de taille réduite, tu peux mettre en avant le temps de développement: "en python ça me prendra 3h, en java 5h". Et comme le temps c'est de l'argent...
Pas de bureau 3d libre sans drivers libres!
[^]Re: Analysons les arguments
Pour préciser mon expérience perso à moi, je devais générer du XSL et du XML à partir d'un schéma XSD.
Ca a finit avec une structure de données du style "liste d'instances de classe ayant pour membres des listes de tuples". Flexible, mais peu maintenable.
A posteriori, je serais partagé:
- j'ai gagné beaucoup de temps sur le dev, mon programme a été fonctionnel rapidement, j'ai pu le faire évoluer au fur et à mesure que j'avais à traiter des fichiers XSD de plus en plus complexes
- la maintenance est coûteuse (zut, il est de quel type cet objet? pourquoi il a pas cette méthode? faut retrouver l'endroit où j'ai affecté un objet d'un mauvais type, c'est où?)
A mon humble avis, dire "je préfère du java ou du python" n'est pas la bonne question. Le problème est de savoir si c'est adapté à ce que tu veux faire, et de savoir qui va maintenir tes programmes.
Pas de bureau 3d libre sans drivers libres!
[^]Re: Analysons les arguments
Ca dépend comment tu codes.
Tout le monde dit qu'il faut faire des tests unitaires. Et bien python te _force_ à faire ces tests unitaires de par son typage dynamique et donc il n'y a pas de verif des types à la compilation.
Pour les types de base, tu peux aussi les surcharger...
Si tu codes bien, au final ton code est aussi maintenable que du java.
Mais Python ne te force pas (contrairement à Java) à faire du code propre : à toi de le faire.
C'est completement dans la philo Python - rien n'est forcé car bcp de choses réside dans la méthodologie.
Je conseille de lire le petit livre de Tarek Ziadé sur Python et le développement agile et l'architecture logicielle. Très interessant !
[^]Re: Analysons les arguments
En entreprise, personnellement (par mon expérience ;) ), je sais que si c'est "à vot' bon coeur m'sieurs, dames" ... ben ça veut dire que personne ne le fera, en tout cas durablement.
Il faut tout imposer, tout encadrer (pour le dév en tout cas), sinon, chacun va faire son truc dans son coin et au final on n'aura rien gagné (dans le meilleur des cas...)
Python, c'est sympa pour faire des plugins, des petits bouts de code, et des prototypes. A part ça, franchement, s'il faut croiser les doigts et espérer que les développeurs vont suivre des normes .... je préfère quitter le navire
[^]Re: Analysons les arguments
Même en Java, sans test unitaires, tu es sérieusement dans la mouise.
D'expérience, un mauvais développeur sera toujours capable te satisfaire un compilo Java, et le code qui en résulte peut faire peur.
Par contre écrire un test qui passe, ça force un peu a réfléchir.
Franchement sur un projet de taille conséquente, si tu n'as pas de test, je te conseille de quitter le navire ;)
Et de toute façon, même les gros projets commencent petits, donc il faut toujours tester.
[^]Re: Analysons les arguments
J'ai dit où que "encadrer" ça veut dire "pas de tests" ???
Au contraire, dans mes build.xml (scripts ant), en général, je force le passage des tests unitaires (difficile de scripter des tests plus complets), et si ça passe pas les tests, le JAR ne sera pas généré.
[^]Re: Analysons les arguments
Je profite d'avoir sous la main des experts avec des arguments pour poser naïvement la question :
« En quoi l'absence de typage statique permet-il de dire que python n'est pas moins sûr ? »
Une autre variante :
« Si on écrit un code python équivalent à un code Java, le temps d'analyse nécessaire à le rendre au moins aussi sûr n'est il pas plus important ? »
[^]Re: Analysons les arguments
Un élément de réponse: un code Java qui compile n'est pas spécialement sûr. Si tu as besoin qu'il le soit, et ça devrait généralement être le cas, tu as besoin d'écrire des tests unitaires. En écrivant les mêmes tests unitaires en python, tu obtiens plus ou moins le même niveau de sûreté, en un temps moindre, puisque tu as écrit le code d'origine plus vite.
[^]Re: Analysons les arguments
Hum, tout ce que tu arrives à faire passer dans le système de types, c'est toujours ça de plus qui est vérifié statiquement à la compilation et n'a plus besoin de tests unitaires.
Ok, le système de type ne peut pas couvrir toute la sémantique (sinon sa correction ne serait pas décidable), mais on ne peut pas cracher sur un outil qui supprime une part non négligeable des erreurs de programmation pour le même prix.
Est-ce que ça compense le temps gagné par la facilité d'écriture en python ? Aucune idée, je n'ai pas pratiqué python.
[^]Re: Analysons les arguments
Sans oublier que Java vérifie que tu gères bien les exceptions à la compilation, ça fait toujours ça de moins en plantages à l'exécution, ça limite les imprévus.
Après y a aussi ceux qui aiment le risque ...
[^]Re: Analysons les arguments
Euh, rien n'empêche de catcher les "checked exceptions " et de ne rien en faire.
Et je t'assure que c'est ce que fait le développeur peu scrupuleux ou ignorant, si on est gentil.
Donc Java de force à faire des chose, ms ça n'aboutit pas forcément a une meilleure qualité finale.
[^]Re: Analysons les arguments
Rien n'empêche, mais là, il faut le faire exprès.
Rien n'empêche non plus de faire un programme sans erreur ni warning (ni à la compilation, ni à l'exécution) qui reformate ton disque dur, et heureusement !
[^]Re: Analysons les arguments
Ca limite quand même pas mal les erreurs humaines.
Honnêtement, quand tu programmes dans un langage qui n'oblige pas à catcher les exceptions, tu vas regarder pour chaque fonction des APIs que tu utilises quelles erreurs peuvent survenir ?
Si tu le fait pas ton programme est potentiellement plus facilement plantable.
Après si le mec qui pond le code est fainéant, il n'y a rien à faire.
Ca reste quand même un gros plus pour la pluspart des programmeurs et ça aide à faire des programmes plus fiables.
[^]Re: Analysons les arguments
les tests unitaires ne permettent pas de s'assurer de la sûreté d'un code à moins qu'ils ne soient exhaustifs (ce qui n'est bien évidemment pas réaliste). Ils permettent néanmoins une certaine vérification (dont notamment des tests de non régression) ce qui est toujours bon à prendre.
[^]Re: Analysons les arguments
Le problème se situe Lorsque tu attends des types particuliers en entrée.
Avec une programmation défensive tu te retrouves à faire du contrôle de type dans tes méthodes alors que c'est typiquement le rôle d'un compilo de traiter ça.
Si tu écris du code réutilisable il n'est pas facile d'anticiper toutes les circonstances d'utilisation de ta lib après coup.
Prenons l'exemple d'un code qui définit une Pile d'objet mais qui fait des présupposés sur le contrat des objets traités dans la pile.
Avec Java tu va utiliser un generics et des interfaces en guise de type.(Avant les generics c'était plus galère)
Avec Python tu devras armer ton code pour en tenir compte.
A contrario l'utilisation de type complètement générique est facilitée avec Python. Si tu te moques des types d'objet que contient ta pile tu en as pour 3 lignes.
Avec Java, tu va t'appuyer sur la classe Object et être obligé d'être plus verbeux.
Le duck typing c'est bien mais ce que tu gagnes en temps de prototypage tu le reperds ensuite en blindage du code et en maintenance ou en intégration avec des erreurs qui ne seraient jamais intervenues avec un langage compilé pendant les phases d'assemblage.
[^]Re: Analysons les arguments
A noter pour ceux que ca intéresse en python que cette problématique est en partie résolue (et de façon élégante) avec le framework PEAK et notamment
PyProtocols
http://peak.telecommunity.com/PyProtocols.html
ou RuleDispatcher
http://www-128.ibm.com/developerworks/library/l-cppeak2/
Il n'en demeure pas moins que ceci est incontournable pour faire du code de qualité.
Il vaut mieux decouvrir les problème au moment de l'assemblage qu'à l'exécution devant le client.
[^]Re: Analysons les arguments
Globalement d'accord mais il y a quelques inconvénients à utiliser Jython.
- Jython est tjs en retard sur les évolutions de python
- Avec Jython tu as le choix entre les librairies standard de Java et celles de python. Ce qui peut apparaitre comme un avantage peut parfois se révéler problématique car 2 deve différents risquent de faire des choix différents avec les contraintes qui s'ensuivent (dépendances inutiles, architecture incohérente et plus fragiles, besoin d'apprentissage des 2 libs .....) . Il est donc souvent nécessaires de se limiter aux frameworks Java.
- règles de codage différentes (python nomme les méthodes à la C avec des _ et Java en capitales.
- La syntaxe de Jython est vraiment déroutante pour ceux qui sont habitué aux accolades.
Bref un tas de petits trucs pénalisants
Quitte a faire le choix d'un langage dynamique pour des devs JEE autant faire le choix d'un langage qui ne remette pas en cause l'existant, j'ai nommé Groovy.
Avec lui tu t'appuies sur les libs standards Java, tu gades une syntaxe proche de Java, tu bénéficies de tout ce qui fait la puissance des langes dynamique. Moins de sucre syntaxique, types de haut niveaux (dictionnaires et tableaux) des fermetures lexicales, de l'interpolation dans les chaines de caractères.
Tu peux donc prototyper rapidement en Groovy et réécrire en Java lorsque c'est nécessaire.
Avec python tu perdras plus de temps.
Tu pourras plus simplement mélanger les 2 langages, ...
[^]Re: Analysons les arguments
Malheureusement, les bonnes ressources Java ne courent pas les rues. N'importe qui ayant suivi 3 jours de formation est développeur Java. Sans avoir une culture de développement minimale :
- pointeurs,
- récursivité,
- programmation fonctionelle,
- programmation logique.
De plus en plus de formations au développement commencent directement avec le Java et ne font que ça. C'est une énorme erreur, dommageable pour les personnes formées, leur employeur et le langage lui-même.
[^]Re: Analysons les arguments
> programmation fonctionelle,
Je ne savais pas que la programmation fonctionnelle était un minimum requis ...
Sinon, je suis globalement d'accord, pas mal de boites embauchent n'importe qui pour faire du Java.
[^]Re: Analysons les arguments
Pour moi, ça l'est car ça permet d'envisager les choses sous un autre angle. L'une des difficultés qu'on rencontre généralement en commençant la programmation fonctionnelle, c'est qu'on a l'habitude de penser en impératif.
Il me semble important d'être capable d'aborder un problème de différentes façons.
Ex: traitement de gros volumes de données à répartir sur un grand nombre de machines. Google a "inventé" le MapReduce qui décompose un algorithme en deux fonctions et est naturellement parallélisable. Leur implémentation est en C++, mais le concept est directement inspiré des fonctions map() et reduce() communes en programmation fonctionnelle.
[^]Re: Analysons les arguments
> Il me semble important d'être capable d'aborder un problème de différentes façons.
Il serait tout aussi important d'apprendre aux développeurs comment fonctionne le matériel sous-jacent pour apprendre à mieux s'en servir.
[^]Re: Analysons les arguments
Pas nécessairement. On peut espérer déléguer la gestion du matériel au compliateur, alors qu'on peut difficilement lui demander de concevoir les algorithmes. D'ailleurs les langages fonctionnels offrent de bonnes performances sans beaucoup se soucier du matériel.
[^]Re: Analysons les arguments
Tout dépends de ton domaine d'application, si connaitre la programmation fonctionnelle est une bonne chose, je ne suis pas certain que ça doit faire partie du socle minimal de connaissance contrairement à l'algorithmie et aux structures de données (ASD).