Journal Python et les décideurs

Posté par  .
Étiquettes : aucune
0
20
nov.
2007
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  . Évalué à 6.

    Je suis donc à la recherche de trolls (sauvages et poilus) sur Java-et-ses-potes histoire de lutter à armes égales avec mes adversaires...

    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  . Évalué à 3.

      oups... c'est de "grenades a fragmentation" dont je voulais parler bien entendu... ^^'

      Sinon y'a le bon vieux : javasapusaypaslibre !! ... hum....shit... il existe plus celui la...

      • [^] # Re: trolls...

        Posté par  (site web personnel) . Évalué à 8.

        Des restes de ta période Windozienne ? :)

        • [^] # Re: trolls...

          Posté par  . Évalué à 7.

          beurk... non ! c'est plutot les windows que je cotoie sans le vouloir qui me contaminent...
          Au boulot, je suis le seul a travailler sous linux :)

  • # Analysons les arguments

    Posté par  (site web personnel) . Évalué à 7.

    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 :-)

    • [^] # Re: Analysons les arguments

      Posté par  (site web personnel) . Évalué à 5.

      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...

      • [^] # Re: Analysons les arguments

        Posté par  (site web personnel) . Évalué à 9.

        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.

        • [^] # Re: Analysons les arguments

          Posté par  . Évalué à 3.

          la maintenance est coûteuse


          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  . Évalué à 6.

            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

              Posté par  . Évalué à 1.

              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

                Posté par  . Évalué à 1.

                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

      Posté par  . Évalué à 3.

      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

        Posté par  (Mastodon) . Évalué à 1.

        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

          Posté par  . Évalué à 10.

          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

            Posté par  . Évalué à 4.

            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

              Posté par  . Évalué à 1.

              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

                Posté par  . Évalué à 2.

                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

                Posté par  . Évalué à 2.

                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

          Posté par  (site web personnel) . Évalué à 6.

          ...un code Java qui compile n'est pas spécialement sûr. Si tu as besoin qu'il le soit [...] tu as besoin d'écrire des tests unitaires


          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  . Évalué à 10.

          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

      Posté par  . Évalué à 4.

      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

      Posté par  (site web personnel) . Évalué à 5.

      Là, ils marquent un point : les ressources Java courent les rues, [...].

      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  . Évalué à 2.

        > 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

          Posté par  (site web personnel) . Évalué à 3.

          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

            Posté par  . Évalué à 4.

            > 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

              Posté par  (Mastodon) . Évalué à 2.

              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

                Posté par  . Évalué à 2.

                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).

  • # Java

    Posté par  (Mastodon) . Évalué à 10.

    Je dirais qu'une des forces de Java, c'est que c'est un langage pour mauvais programmeurs. C'est suffisamment rigide et complet pour que les dégâts causés par les mauvais programmeurs soient réduits. Des langages plus souples donnent tellement de liberté et permettent tellement de manières de programmer qu'il faut plus de discipline et de compétence pour produire du bon code qui va correctement s'interfacer avec le code de ses coéquipiers.

    É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  . Évalué à 2.


      Je dirais qu'une des forces de Java, c'est que c'est un langage pour mauvais programmeurs. C'est suffisamment rigide et complet pour que les dégâts causés par les mauvais programmeurs soient réduits.

      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  (Mastodon) . Évalué à 3.

        J'aime bien troller sur les différences entre les langages, mais j'avoue manquer un peu de temps, alors j'ai triché, je viens de chercher sur Google "java bad programmers", et j'ai trouvé ça qui résume une partie de ce que je voulais dire:

        http://home.pacbell.net/s-max/scott/re-java.html

        Avec en particulier la conclusion:
        In general, Java's restrictions (when compared to C++) make it a little harder for bad programmers to write bad programs at the expense of making it somewhat harder for good programmers to write good programs. I suppose that whether you consider this a good thing depends on how many bad programmers you have to deal with [...]


        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...

        ou alors il faut voir ce que tu appelles bon programmeur

        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  . Évalué à 0.

          Faut arrêter, un bon programmeur c'est quelqu'un qui à de l'expérience dans son langage de prédilection, qui a su retirer quelque choses de ses erreurs passées.... C'est tout.
          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  (Mastodon) . Évalué à 2.

            Évidemment, un bon programmeur a de l'expérience, et l'expérience s'acquiert en faisant des erreurs. Mais je pense que lier ça à un langage de prédilection est une erreur. J'aurais plus confiance dans quelqu'un qui a une expérience moyenne dans plusieurs langages sensiblement différents que dans une personne qui ne code que dans un seul.

            En Java, t'as donc de bon programmeurs et des mauvais. En C/C++, idem.

            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  (site web personnel) . Évalué à 0.

      Je ne relèverais pas la phrase sur Java comme étant un langage pour mauvais programmeurs.

      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  . Évalué à 1.

        Il fallait peut-être lire "Java est un *bon* language pour mauvais programmeurs".

        Comme ça Pierre Tramo ne te sautera pas dessus...

    • [^] # Re: Java

      Posté par  . Évalué à 6.

      Je dirais qu'une des forces de Java, c'est que c'est un langage pour mauvais programmeurs. C'est suffisamment rigide et complet pour que les dégâts causés par les mauvais programmeurs soient réduits. Des langages plus souples donnent tellement de liberté et permettent tellement de manières de programmer qu'il faut plus de discipline et de compétence pour produire du bon code qui va correctement s'interfacer avec le code de ses coéquipiers.


      En suivant ta logique PHP serait un langage pour les dieux de la programmation. :)

  • # Dynamiquement typé ou statiquement typé ?

    Posté par  . Évalué à 8.

    Je ne connais pas très bien java et encore moins Python mais je connais par contre bien le C# ainsi que le Ruby. J'ai développé dans ces deux langages et bien je peux dire une chose :

    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  (site web personnel) . Évalué à 4.

      Un truc qui commence à se développer pas mal en Java, c'est d'utiliser via l'inteface de scripting Java du Ruby ou du Python pour certaines taches.

      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  (site web personnel) . Évalué à 1.

      Je pense que le problème n'est pas le typage dynamique versus le typage statique ou quel est le meilleur.
      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  . Évalué à 5.

      Tout (de l'OS aux applis) sur les Lisp Machines étaient implémenté en Lisp (pas Common Lisp, mais "presque"), et difficile de faire plus dynamique. On dépasse assez largement les 10 000 lignes dans ce cas-là, et personne ne s'en est jamais plaint. Pourquoi?

      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  (site web personnel) . Évalué à 0.

        Est-il encore pertinent de faire la comparaison entre le dynamique-impératif et le dynamique-fonctionnel, je ne suis pas sûr. L'approche est complètement différente.

        • [^] # Re: Dynamiquement typé ou statiquement typé ?

          Posté par  . Évalué à 3.

          Dans la majeure partie des dialectes de Lisp, tu peux autant coder en impératif qu'en fonctionnel. Ou tout autre paradigme d'ailleurs, merci les macros... enfin on est pas là pour faire de la pub.

          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  . Évalué à 3.

      On parle toujours des erreurs de typages détectés à la compilation, comme si elles étaient très fréquentes. Hors je sais pas vous mais personnellement, quelque soit le langage que j'ai utilisé je ne me souviens pas avoir été particulièrement confronté à ces problèmes...
      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  . Évalué à 5.

        Oui ca ne sert pas à grand chose quand tu développes "à chaud", surtout quand tu es seul sur le projet vu que tu as une vision globale de ton code.

        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  . Évalué à 3.

          Admettons que je revienne sur un gros projet, admettons même que ce ne soit pas moi qui l'ai fait. Je vais utiliser une fonction déjà existante, il me semble que le premier truc que je vais regarder c'est le type des données qu'elle attend et reçoit...
          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  . Évalué à 1.

    Un argument technique n'est pas un critère de choix!

    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

  • # jython, le compromis

    Posté par  . Évalué à 1.

    tu codes en python mais ca s'execute dans une jvm :)

    ya meme un compilo jythonc.. je sais pas s'il fait du controle de syntaxe...

    • [^] # Re: jython, le compromis

      Posté par  . Évalué à 1.

      Cela ne résoud pas le principal problème. Les sources sont en Python. Les développeurs Python ne sont pas légion.....

  • # Tout est bon

    Posté par  . Évalué à 2.

    dans linuxfr...
    https://linuxfr.org/~ploum/23607.html

    • [^] # Re: Tout est bon

      Posté par  . Évalué à 2.

      Dans le python aussi ...
      ( je suis pythonnien, le python sinon rien)

  • # Trollarguments

    Posté par  . Évalué à 2.

    Python c'est vrai que c'est plus développeur-friendly que dissaïdor-friendly. Mais:

    - 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  . Évalué à 0.

      - Ca mange pas beaucoup: python consomme nettement moins de ressources que java


      C'est pas dur ...

      • [^] # Re: Trollarguments

        Posté par  . Évalué à 3.

        Prouves le.

        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  . Évalué à 3.

      * Ca mange pas beaucoup => c'est pas toujours le cas, d'ailleurs la JVM et Mono sont nettement plus performant sque l'interpréteur Python en régle générale. D'ailleurs l'implémentation la plus performante de Python est IronPython, cela a même été annoncé lors d'un précédent PyCon.
      * 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  . Évalué à 5.

      Java a un temps de lancement plus important que python et consomme plus de mémoire initialement.

      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  (site web personnel) . Évalué à 2.

    Si tu as encore du java 1.3 qui traîne cela serait un peu plus facile d'argumenter sur les changements ; m'enfin le passage en 1.5 même s'il fait apparaître pas mal de "deprecated" au passage fait tomber les principaux défauts de java :
    - 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  (site web personnel) . Évalué à 2.

      un bon programmeur java fera appel à un maximum de bibliothèques existantes [...], mais bon je n'en vois pas tant que ça

      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  (site web personnel) . Évalué à 3.

        sur les bibliothèques / framework que j'ai cités ? j'espère que tu déconnes :p

        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  (site web personnel) . Évalué à 1.

          log4j n'est plus développé activement par exemple.

          • [^] # Re: normes et bibliothèques dispos

            Posté par  . Évalué à 3.

            Sauf que c'est Open Source.
            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  (site web personnel) . Évalué à 4.

              Sauf que c'est Open Source.
              Dans le pire des cas tu payes quelqu'un pour faire les modifs dont tu as besoin.

              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  . Évalué à 5.

    Dis moi si je me trompe...

    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  (Mastodon) . Évalué à 3.

      Peut-être que dans certaines boîtes, la hiérarchie n'est pas importante au point que les chefs refusent d'écouter les arguments de leurs inférieurs et de changer d'avis lorsque c'est approprié... allez savoir.

    • [^] # Re: En résumé....

      Posté par  . Évalué à 1.

      Tu te trompes complètement. Nous sommes deux dans ma boite: mon patron et moi, et on s'entend vraiment bien.

      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  . Évalué à 2.

        Evidement cela change tout.

        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  (site web personnel) . Évalué à 3.

    http://www.jwz.org/doc/java.html

    É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.

    Je développe en Python, et j'essaye un peu aussi en Haskell ces derniers temps. Par contre, quand je fait du développement orienté monnaie, je ne fais que du Java.
    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.