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.
# trolls...
Posté par Nico C. . Évalué à 6.
Les trolls s'apparentent a du lancer de caca a la tete de l'adversaire... alors qu'un bon argument technique demontre par un exemple (si possible), ca s'apparente plutot a un lancer de grenade a defragmentation.
C'est tout de suite beaucoup plus efficace... ;)
[^] # Re: trolls...
Posté par Nico C. . Évalué à 3.
Sinon y'a le bon vieux : javasapusaypaslibre !! ... hum....shit... il existe plus celui la...
[^] # Re: trolls...
Posté par GCN (site web personnel) . Évalué à 8.
[^] # Re: trolls...
Posté par Nico C. . Évalué à 7.
Au boulot, je suis le seul a travailler sous linux :)
# Analysons les arguments
Posté par Nelis (site web personnel) . Évalué à 7.
* 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 :-)
[^] # Re: Analysons les arguments
Posté par Fabimaru (site web personnel) . Évalué à 5.
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...
[^] # Re: Analysons les arguments
Posté par Fabimaru (site web personnel) . Évalué à 9.
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.
[^] # Re: Analysons les arguments
Posté par Elrik de Melnibone . Évalué à 3.
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
Posté par freeze . Évalué à 6.
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
Posté par パパフラクス . Évalué à 1.
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
Posté par freeze . Évalué à 1.
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
Posté par ciol . Évalué à 3.
« 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
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Analysons les arguments
Posté par Aldoo . Évalué à 10.
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
Posté par timid . Évalué à 4.
Après y a aussi ceux qui aiment le risque ...
[^] # Re: Analysons les arguments
Posté par パパフラクス . Évalué à 1.
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
Posté par Aldoo . Évalué à 2.
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
Posté par timid . Évalué à 2.
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
Posté par viridis (site web personnel) . Évalué à 6.
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
Posté par Bozo_le_clown . Évalué à 10.
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
Posté par Bozo_le_clown . Évalué à 4.
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
Posté par Bozo_le_clown . Évalué à 4.
- 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
Posté par Olivier Serve (site web personnel) . Évalué à 5.
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
Posté par GeneralZod . Évalué à 2.
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
Posté par Olivier Serve (site web personnel) . Évalué à 3.
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
Posté par GeneralZod . Évalué à 4.
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
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Analysons les arguments
Posté par GeneralZod . Évalué à 2.
# Java
Posté par Yusei (Mastodon) . Évalué à 10.
Étant donné qu'employer uniquement des bons programmeurs coûte cher, et qu'il est assez difficile de s'assurer de la compétence de ses employés, je pense qu'utiliser Java est un choix cohérent. Ça va coûter plus cher en temps et en personnel, mais tu as un minimum de garantie que le code soit ré-exploitable et que ta main d'oeuvre est interchangeable.
Maintenant, si tu veux les convaincre de choisir ton langage dynamique favori, il faut surtout leur montrer qu'on peut obtenir la même chose. Je ne connais pas Python alors je parle pour Ruby: un argument peut-être que le dynamisme du langage incite à utiliser son framework de tests. En rédigeant correctement ses tests unitaires et fonctionnels, on obtient souvent une meilleure qualité de code que lorsque l'on fait trop confiance à un compilateur dont les capacités sont limitées. Ruby rend l'écriture de tests très facile. (Je ne connais pas le framework de tests de Java, mais il me semble qu'il a bonne réputation aussi.)
[^] # Re: Java
Posté par timid . Évalué à 2.
Mouhahaha ca me fait bien marrer de lire des inepties comme ça !
Java c'est un langage pour les programeurs qui ont un peu d'humilité et qui aiment pouvoir modifier leur code 1 an après sans que ca plante de partout parce qu'ils ont oublié de changer un nom de méthode à un endroit.
Aussi bon programmeur sois tu, l'erreur est humaine ... ou alors il faut voir ce que tu appelles bon programmeur, si pour toi c'est quelqu'un qui passe son temps à faire le boulot d'un compilateur ...
[^] # Re: Java
Posté par Yusei (Mastodon) . Évalué à 3.
http://home.pacbell.net/s-max/scott/re-java.html
Avec en particulier la conclusion:
Bien sûr, ce n'est qu'une partie du problème, et je ne suis pas sûr que la comparaison avec le C++ soit la meilleure chose à faire...
Un bon programmeur, c'est quelqu'un qui sait quand il est opportun d'utiliser une fonctionnalité avancée d'un langage, parce que ça rend le code plus élégant et plus facile à maintenir. Un mauvais programmeur, c'est quelqu'un qui n'a pas une idée très claire de ce qu'il fait, et qui choisit donc la manière de le faire un peu au hasard parmis toutes celles qu'il connait ou trouve sur le net.
Conséquence de cette définition, il vaut mieux limiter les possibilités du mauvais programmeur. Si tu lui donnes la possibilité de faire de l'héritage multiple, de surcharger les opérateurs ou, pire, de faire de la métaprogrammation, il risque de s'en servir à tort et à travers et de produire du code difficile à maintenir (et faux).
[^] # Re: Java
Posté par ecyrbe . Évalué à 0.
Un mauvais programmeur, c'est un débutant. En Java, t'as donc de bon programmeurs et des mauvais. En C/C++, idem.
[^] # Re: Java
Posté par Yusei (Mastodon) . Évalué à 2.
Je n'ai pas l'impression d'avoir dit quelque chose impliquant que les développeurs Java étaient tous mauvais. J'ai dit que le langage était conçu pour de mauvais programmeurs. Ça n'empêche pas les bons programmeurs de s'en servir.
[^] # Re: Java
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
Par contre, effectivement, je confirme que Java dispose d'un framework de tests unitaires efficaces, JUnit ... Quoique de plus normal, vous allez me répondre, puisque celui-ci est le portage dans Java du premier framework de tests unitaire qui se trouve être SUnit (un framework de tests unitaires Smalltalk).
[^] # Re: Java
Posté par TNorth . Évalué à 1.
Comme ça Pierre Tramo ne te sautera pas dessus...
[^] # Re: Java
Posté par defdrek . Évalué à 6.
En suivant ta logique PHP serait un langage pour les dieux de la programmation. :)
# Dynamiquement typé ou statiquement typé ?
Posté par Ummon . Évalué à 8.
A partir d'une certaine taille de projet (disons 10'000 lignes), les langages à typage dynamique deviennent une plaie à utiliser. pourquoi ?
Beaucoup d'erreurs qui sont levées à l'exécution (parfois chez le client) auraient pu être détectée à la compilation dans le cas d'un langage statiquement typé.
Même des fautes de frappe toutes connes peuvent engendrer des problèmes beaucoup plus tard. par exemple un appel de méthode inexistant "monObjet.aficher()" ne se verra qu'a l'exécution dans le cas de Ruby. Ok le Ruby/python c'est souple on peut faire plein de chose (ducktyping et cie) mais personnellement je pense justement que cette souplesse est plus un inconvénient qu'un avantage dans beaucoup de cas.
On est obligé d'imposer des consignes très strictes en matière de codage comme par exemple documenter de manière formel le type des paramètres des méthodes.
Je ne dis pas que le typage statique et meilleur que le typage dynamique, l'un et l'autre ont leurs avantages et inconvénients. Je pense que Python et Java peuvent très bien être utilisés conjointement, l'utilisation de l'un ou de l'autre dépend du type de la problématique.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Nelis (site web personnel) . Évalué à 4.
L'avantage c'est de bénéficier de la flexibilité de Ruby ou Python pour certains aspects bien précis du logiciel, et d'utiliser Java pour le reste.
Pour Civilization III ils ont fait ça (c'est pas du Java mais le principe est le même) : la majorité de l'IA et des règles du jeu sont écrites en Python, ce qui permet aux fans d'écrire des mods assez facilement sans devoir se plonger dans le code complet du jeu.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Sébastien B. . Évalué à 3.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Nelis (site web personnel) . Évalué à 3.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Tout dépend de son usage et de l'implémentation dans le langage.
Par exemple, écrit une véritable application complexe en Smalltalk qui est un langage à typage dynamique et tu constateras alors l'absence de problèmes liés au typage et que tu trouves dans d'autres langages à typage dynamique.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Thomas . Évalué à 5.
Grâce aux outils disponibles pour le développement. La possibilité d'inspecter n'importe quel widget de l'interface graphique, avec le code qui est derrière, de savoir où est définie une fonction, et quelles autres fonctions l'utilise, etc. Les déclarations de type *optionnelles* aussi (le compilo peut s'en servir pour optimiser plus qu'en ne faisant qu'inférer le type).
Peut-être aussi que les programmeurs n'étaient pas des "pisseurs de code" lambda (pun not intended)
Bon je suis ptêtre un vieux con à 26 ans, mais je trouve les IDE Common Lisp, qui sont pourtant moins puissantes qu'une Lisp Machine, beaucoup plus puissantes que les IDE Java.
PS: je n'ai pas physiquement accès à une Lisp Machine, mais des vidéos sont dispos. Je n'ai pas d'actions chez Symbolics ou Franz non plus :-)
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par par . Évalué à 0.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par Thomas . Évalué à 3.
En Python tu as des éléments qui le rapproche du fonctionnel.
Donc je pense qu'on peut quand même faire la comparaison.
Il faut que je retrouve une vidéo dans laquelle on voit bien l'environnement de développement et les outils qu'il propose.
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par wilk . Évalué à 3.
Pareil pour les exceptions, je trouve concrètement très rare d'avoir un bug en python qui aurait été attrapé par un rattrapage obligatoire en java.
En revanche les tests fonctionnels et unitaires me servent énormément et sont beaucoup plus facile à faire qu'en java, ne serait-ce parce qu'ils n'obligent pas aux mêmes contraintes justement !
Est-ce parce que je travail généralement seul ?
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par timid . Évalué à 5.
Par contre reviens 6 mois plus tard faire des modifs sur un projet de plus de 100000 lignes qui utilise des librairies développées par d'autres gens ... là tu seras bien content d'avoir ces vérifications au lieu de devoir découvrir les plantages en testant à la main (oui on peut faire des tests unitaires mais quand on touche à la couche GUI ça devient plus chiant).
[^] # Re: Dynamiquement typé ou statiquement typé ?
Posté par wilk . Évalué à 3.
Le seul cas critique que je vois en y réfléchissant c'est si je met à jour une librairie et qu'elle a changée son type de données, mais ça me semble quand même hyper rare...
Un cas de figure auquel je ne pense pas ?
Si les tests de type étaient indispensables, on ferait des tests unitaires pour ça, hors c'est également rarement le cas. Il y a également des outils comme pychecker ou pylint pour généraliser ce type de tests.
Pour les GUI, je suis passé aux applis web en grande partie pour faciliter les tests !!
# Un argument technique n'est pas un critère de choix
Posté par Unixfix le Gaulois . Évalué à 1.
D'abord, je l'avoue je ne connaît pas Python contrairement à Java.
Cependant je me permet de faire quelques remarques:
Python n'est certe pas un langage exotique mais peu répandu.
Les développeurs Python ne sont pas légion. Un responsable se trouve dans une position délicate. Il ne pourra pas te remplacer (virer?) facilement et te trouver un remplacant. Que tu le veuilles ou non cela est un argument (non avoué!) mais essentiel.
Tous les autres arguments (pour ou contre Java/Python) sont sans réelle importance
[^] # Re: Un argument technique n'est pas un critère de choix
Posté par Sisyphe Plâtrier . Évalué à 1.
# jython, le compromis
Posté par . Takhi . Évalué à 1.
ya meme un compilo jythonc.. je sais pas s'il fait du controle de syntaxe...
[^] # Re: jython, le compromis
Posté par Unixfix le Gaulois . Évalué à 1.
# Tout est bon
Posté par André Rodier . Évalué à 2.
https://linuxfr.org/~ploum/23607.html
[^] # Re: Tout est bon
Posté par Sébastien B. . Évalué à 2.
( je suis pythonnien, le python sinon rien)
# Trollarguments
Posté par _p4_ . Évalué à 2.
- Ca mange pas beaucoup: python consomme nettement moins de ressources que java
- Ca court vite: pas besoin d'un porte-avions nucléaire pour écrire un hello world, dev rapide
- Ca a en a une grosse aussi: même que Google ils l'utilisent, non mais!
[^] # Re: Trollarguments
Posté par Sébastien B. . Évalué à 0.
C'est pas dur ...
[^] # Re: Trollarguments
Posté par Bozo_le_clown . Évalué à 3.
Ce sempiternel argument tient à l'héritage de AWT/Swing qui redessinait complètement le contenu des widgets.
Aujourd'hui Swing a évolué de même qu'on dispose de SWT/JFace et même Qt/Jambi.
[^] # Re: Trollarguments
Posté par GeneralZod . Évalué à 3.
* Ca court vite => j'aurais tendance à le croire, le Java est nettement plus verbeux.
* Ca a en a une grosse aussi => Google utilise également Java.
Quant à Jython, il est hors course, il évolue très lentement, son ex-mainteneur Jim Hugunin travaillant désormais sur IronPython le port sur Mono/.Net -yuck-.
Sinon moi, je préfére C/Python, le meilleur compromis \o/
[^] # Re: Trollarguments
Posté par timid . Évalué à 5.
D'un autre côté en temps d'exécution brute il est 4 ou 5 fois plus rapide que python, faut savoir ce qu'on veut.
# normes et bibliothèques dispos
Posté par BAud (site web personnel) . Évalué à 2.
- lourdeur de la JVM (allouons 2 Go on sera peinard avec le garbage collector comme cela... pas de risque de dégradation des performances)
- incompatibilités entre versions (pas trop visible côté serveur, mais pour des applis client c'était un peu la bataille sur les chaînes de caractères pour tout caser à l'écran et les alignements de boîtes de saisie et autres bugs d'affichage)
- améliorations des frameworks et des bibliothèques uniquement disponibles avec du java 1.5 (si cela entraîne une mise à jour...), avec des boosts de perf pour traiter tout ce qui est XML par exemple
- un bon programmeur java fera appel à un maximum de bibliothèques existantes (remplaçant son travail par de l'intégration plutôt que du codage), mais bon je n'en vois pas tant que ça (2 ou 3 sur les dizaines de javaistes que j'ai rencontrés).
- proposer une alternative à JUnit pour les tests unitaires, log4j pour les logs, hibernate pour l'accès aux données, doxygen pour la doc' et autres bibliothèques "standards" (ça dépend sur quoi vous normalisez actuellement vos développements)
Pour python, il y a peut-être à mettre en avant certaines applications toute faites (en java c'est plutôt des frameworks, tout étant à faire). Cela permettrait de montrer ce qui marche avec python et effectuer le travail de normalisation des développements au titre de ce projet.
Le critère n'est pas tant technique qu'organisationnel : savoir constituer une équipe avec toutes les normes et démarches pour mener un projet du dév' à la production (et rassurer au passage sur les avantages que peut avoir python).
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Le problème de cette approche est que tu deviens dépendant d'un projet externe, et donc des décisions prises par ce projet. Que faire s'il est abandonné ? Si la nouvelle version (nécessaire pour supporter la nouvelle plateforme par ex.) prend une direction qui rend son utilisation difficile ?
Utiliser une bibliothèque externe, c'est prendre la responsabilité de suivre ses évolutions, tester les nouvelles versions et éventuellement devoir reporter la sortie d'un projet à cause d'incompatibilités.
Bref, il n'y a pas que des avantages et c'est un choix qu'il ne faut pas prendre à la légère.
[^] # Re: normes et bibliothèques dispos
Posté par BAud (site web personnel) . Évalué à 3.
mais c'est le clair que le syndrôme NIH frappe partout... (Not_Invented_Here aussi appelé "pas fait par moi")
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . Évalué à 1.
[^] # Re: normes et bibliothèques dispos
Posté par Bozo_le_clown . Évalué à 3.
Dans le pire des cas tu payes quelqu'un pour faire les modifs dont tu as besoin.
Si tu l'a redéveloppé en interne tu dois de toute façon le faire.
En plus tu vas faire des heureux qui ne bosseront pas pour le plaisir et d'autres encore puisque tu peux/dois reverser les modifs à la communauté.
Par contre avec du logiciel proprio ton raisonnement se tient parfaitement, tu es obligé de suivre les mise à jour de l'éditeur ou adopter un autre composant au prix d'adaptations.
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Oui, en théorie.
En pratique, tu vas évaluer le coût de maintenance par rapport à un changement de techno. S'il existe d'autres bibliothèques assez proches, ce sera sans doute le choix retenu. Mais il faudra bien faire l'intégration. Sinon, tu vas garder la vieille version en ajustant pour que ça marche (bugfix only), jusqu'à atteindre le moment où il devient plus avantageux de tout réécrire voire de partir sur une techno différente que de continuer à boucher les trous.
Dans le premier cas, c'est une modif qui n'est pas prévue dans le planning initial. Dans le second cas, ça revient à faire du dev interne (sauf qu'il n'était pas prévu non plus).
Si c'est un développement interne, les modifications sont celles requises uniquement par le projet (pas de retard à cause d'un développement dont on n'a pas besoin) et sont prévues dans le planning.
Bref, tout recoder est stupide, mais utiliser toutes les bibliothèques disponibles parce que saybien est tout aussi suicidaire.
<mavie>
On utilise pas mal de bibliothèques Apache, et pour le moment ça va plutôt bien.
Mais pour l'interface d'admin, on était partis il y a 5 ans sur Luxor (traducteur XUL -> Swing) pour que des personnes ne connaissant pas Java puissent modifier facilement les formulaires. XUL semblait prometteur à l'époque, et ce choix aurait pu marcher.
Mais Luxor est mort et n'a aucun remplaçant. Le maintenir est hors de question (1. ce n'est pas notre domaine 2. on n'a pas assez de personnes 3. qui paye ?). On reste donc avec un truc qui marche mais est trop basique. Du coup, on va certainement tout refaire en changeant complètement de techno.
</mavie>
# En résumé....
Posté par Unixfix le Gaulois . Évalué à 5.
Ta boite développe en java mais tu préfère Python. Après tout c'est ton droit mais
Visiblement ton chef préfère Java (habitude, expérience, possibilité de se passer de toi)
Tu cherche des arguments massues (Troll etc....) pour essayer de le convaincre.
A l'évidence tu veux changer de boulot:
Si on te demande de développer en Java et que tu préfères python n'oublie pas que tu ne te payes pas toi-même.
Les autres commentaires sur les avantages/inconvénient de Java/Python sont un divertissement et non des arguments
[^] # Re: En résumé....
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: En résumé....
Posté par Gilles G. . Évalué à 1.
Aujourd'hui, il faut qu'on développe une nouvelle application que nous devons faire en interne. J'aurai souhaité faire cela en Python parce que je pense que je pourrais gagner du temps. Je connais bien Python parce que j'utilise Scipy/Numpy et que je fais du PyQt à mes heures perdues.
Note aussi que je ne suis pas développeur (i.e. pas de formation, mais on fait avec nos ressources).
Python n'a pas le "rayonnement" de Java, et la plupart des gens autour de nous nous ont incité à utiliser Java sans bons arguments puisqu'ils ne sont pas programmeurs eux-mêmes.
Après lecture des commentaires de ce journal, je commence à changer d'avis et à me dire que Java serait une bonne solution.
En particulier, le fait de pouvoir modifier "en toute sécurité" une application que l'on n'a pas touchée depuis 1 an (ou qu'on n'a pas écrite) m'apparait être un *très* bon argument en faveur de Java.
PS: malgré le ton trollesque de mon journal, j'étais sérieux! Les arguments que j'ai pu entendre contre Python et pour Java étaient infondés et semblaient résulter avant tout d'une peur de l'inconnu.
[^] # Re: En résumé....
Posté par Unixfix le Gaulois . Évalué à 2.
Ne connaissant pas vraiment Python je ne pouvais pas me permettre de le critiquer ou l'aduler.
Maintenant il faudrait (aussi!) savoir ce qui est à développer. Certains langages sont mal adapté à des applications particulières.
Pour ce qui est de la maintenance du code, cela n'a pas grand chose à voir avec le langage. On pourrait résumer par simplicité et commentaires....
# google toussa
Posté par Krunch (site web personnel) . Évalué à 3.
Évidemment, il n'y pas grand chose de positif sur Python non plus là dedans puisqu'il partage sans doute une bonne partie des tares de Java (notamment au niveau consommation de ressources).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Mon point de vue
Posté par パパフラクス . Évalué à 1.
Donc, d'un point de vue professionnel je suis développeur Java, ou consultant Java, ou ingénieur Java, ou JEE lead architect (non pas celui la en fait ;) bref, je suis totalement invisible en tant que dev Python, même si j'aimerais en faire, et je ne pense pas être le seul dans ce cas.
Un point que tu peux mettre en avant, c'est qu'un développeur Python a de forte chances d'être de meilleure qualité qu'un développeur Java, non pas parce que Python est élitiste, ou que des dev soient intrinsèquement meilleurs, mais simplement parce que ce sont des gens qui ont eu la curiosité de s'intereser a quelque chose de moins rependu, alors que la facilité est de faire ce que je fais, aller là ou est l'argent.
Concernant la rapidité, Python est plus lent que Java, mais largement assez rapide pour la majorité des applis. Et par exemple, pour le calcul numérique, l'utilisation de bibiliothèque est d'une vitesse fulgurante, comparé a une implémentation full Java.
Concernant le typage dynamique, je dirais qu'il y a des avantages et des inconvénients, et c'est un peu une histoire de goût (perso, j'aime bien le typage dynamique, ms aussi le statique avec inférence de type), mais surtout de profile de développeurs, et encore plus de méthode de travail.
Par exemple, je pense que le typage dynamique est intéressant dans le cadre d'une petite equipe, fonctionnant sur un mode XP, avec une bonne pratique des tests unitaires.
Pour la simplicité, je trouve effectivement que Python est plus simple que Java, mais ça ne me semble pas démontrable. Je laisserais tomber cet argument.
Idem pour la flexibilité.
Je laisserais aussi tomber le fait que tu aimes bien Python, tu ne ferais que passer pour quelqu'un qui prend un projet pour un terrain de jeu, et ne tient pas compte de l'intérêt du projet.
Quelque chose qui peut être rassurant aussi, c'est le grand nombre de bibiliothèque, et le côté "battery included" de Python.
Autre chose qui peut plaire au décideur, c'est le coté "one way" et non bloated, du langage: du coup on repose moins sur des convention de codage, qui sont là de fait (tout est relatif...)
Je mettrai aussi l'accent sur la lisibilité. Les décideurs sont en général sensible au coût de maintenance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.