Journal Noop : encore un nouveau langage ou bien nouvelle génération de langage

Posté par .
Tags : aucun
7
25
sept.
2009
Google vient de présenter un de ses nouveaux projets : Noop, un nouveau langage expérimental basé sur la JVM. Selon le site officiel [1] Il est facile de produire un code difficile à tester (i.e, valider) ou à maintenir avec les langages existent, notamment dans les gros projets. Noop, vise a pallier ces deux inconvénients en permettant l'injection de dépendances et des tests unitaires automatisés directement au sein du langage.

Vrai évolution (je ne pense pas que cela soit révolutionnaire pour utiliser ce terme) ou bien juste une autre bricole ... à voir.

Cher journal qu'en dis tu ?

[1]: http://code.google.com/p/noop/
  • # Rien de transcendant dirait-on

    Posté par (page perso) . Évalué à 2.

    Très vite fait :

    Un bête langage à classe

    Dans http://code.google.com/p/noop/wiki/ProposalForErrors un sucre syntaxique pas bête consistant à récupérer le résultat ET l'erreur.
    La fonction renvoi deux valeurs. Rien de très nouveau.

    Dans http://code.google.com/p/noop/wiki/ProposalForTestingApi
    Un machin sucre syntaxique dans la grammaire en dur (beurk caca) pour que le test ait l'air d'être écrit en anglais

    Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...)


    Si les scope, ou comment mettre les trucs crade de spring (injection d'objet à l'init) en natif dans le langage.

    Bref, faudrait que je creuse plus, mais ça m'a l'air d'un mélange de tous les trucs crades et dépassé de java/C#, mélangé avec les bidouilles à la spring qui sont là pour pallier aux limites de ces langages.
    Mais l'idée de les intégrer en natif est intéressante.

    Non, pour moi un truc vraiment nouveau serait :

    - Objet à frame, avec pose de contraintes entre les membres de chaque objets
    - Un sql intégré, minimum
    - Une sémantique orienté agent. Ie. pourvoir définir des agents autonomes interragissant entre eux avec des règles
    - Un moteur de règles avec résolution, détection de conflit à la compil

    Bon aller, je --> []

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Rien de transcendant dirait-on

      Posté par (page perso) . Évalué à 3.

      À quoi peut bien servir java de toute manière... Les vrais hommes programment en langages compilés.
    • [^] # Re: Rien de transcendant dirait-on

      Posté par . Évalué à 1.

      Quelques questions:
      - Qu'est ce que spring a de crade? L'IoC, dependancy injection et tout le tralala, c'est quand meme vachement elegant et rudement pratique pour des grosses applis.
      Et que ce soit au niveau de l'architecture ou du code, spring est clairement un tres bon exemple d'elegance.
      - Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate. La on se debarasse carrement de cette daube de sql.
      Bon apres, je vois ca dans mon contexte (grosses applis jee) ya ptetre (probablement?) des trucs qui m'echappent.
      • [^] # Re: Rien de transcendant dirait-on

        Posté par (page perso) . Évalué à 9.

        Qualité et Hibernate ?

        Daube et SQL ?

        Nous n'avons pas les mêmes valeurs.

        Envoyé depuis mon lapin.

        • [^] # Re: Rien de transcendant dirait-on

          Posté par . Évalué à 1.

          C'est une redite du "java, je sais pas comment ca marche, mais je dit que c'est mal quand meme, meme quand on m'a demontre plusieurs que je dit de la merde" comme la derneire fois que tu nous a fait un microbenchmarch pour tester le jit dans un public static main de 4 lignes?
          • [^] # Re: Rien de transcendant dirait-on

            Posté par (page perso) . Évalué à -3.

            Encore toi? Désolé, mais tu te fous le bras dans l'œil. Pas envi de répéter ce que j'ai déjà dit plusieurs fois, ça sert à rien apparemment.

            Envoyé depuis mon lapin.

            • [^] # Re: Rien de transcendant dirait-on

              Posté par . Évalué à 0.

              Bah, ben tu vas nous expliquer ou est le manque de qualite dans hibernate alors.

              Et puis tant que tu y es, tu vas aussi nous fournir un exemple de mapping DB/Objet, de plus de 4 lignes, fait par tes pitites mimines, qui:
              - abstrait integralement du sgbd sous jacent comme hibernate le permet. Genre tu coupes ton serveur, tu passes d'oracle a mysql et tu relances.
              - offre les perfs d'hibernate (je pense notamment au 2nd level cache)
              - maintient ton graphe d'objet a jour automatiquement (genre les delete orphans etc)
              - ne contient pas une seule ligne de SQL
              - se configure quasi exclusivement directement dans le code (je suis gentil, t'as droit a un fichier de config pour les connexions db et un autre pour declarer les classes qui sont mappees).
            • [^] # Re: Rien de transcendant dirait-on

              Posté par (page perso) . Évalué à 6.

              Pas envi de répéter ce que j'ai déjà dit plusieurs fois

              Tu *n'as* absolument *rien expliqué* à part dire "Java c'est lent, c'est de la merde, blabla". Maintenant tu viens avec tes gros sabots et tu dis "Hibernate c'est de la merde, blabla" toujours avec autant d'arguments.

              Moi j'ai un truc qu'on peut aisément vérifier juste en te lisant "Tu dis des **conneries**".

              @+
              • [^] # Re: Rien de transcendant dirait-on

                Posté par (page perso) . Évalué à 0.

                J'ai dit "Java c'est lent, c'est de la merde, blabla", et je le dirais encore et toujours rien que pour le plaisir. Je suis comme ça moi©.

                Je n'ai pas dit "Hibernate c'est de la merde, blabla". Tu as compris ça, et c'est très facile à comprendre. Pour vous, je suis un troll crétin et obstiné qui dit que des conneries sur la java. À moins de changer de pseudo, je risque pas de faire passer une **opinion** auprès de vous sur une technologie qui a un rapport de près ou de très loin avec le java.

                De toutes façons, ici, le but n'était pas de dire que ce que vous adorez est de la merde (même si c'est jouissif), mais que je ne suis pas d'accord avec l'opinion de l'auteur du post d'au dessus. Et à la vue de mon score, je ne suis pas le seul.

                Envoyé depuis mon lapin.

                • [^] # Re: Rien de transcendant dirait-on

                  Posté par . Évalué à 0.

                  non, meme si tu changes de pseudo, on te reconnaitra si tu dit toujours les memes conneries.

                  J'attends toujours les explications quand a:
                  - les problemes de qualite d'hibernate (code illisible? bugs? perfs? archi pourrie? merde il a rien de tout ca)
                  - ta solution super efficace mieux qu'hibernate.
                  • [^] # Re: Rien de transcendant dirait-on

                    Posté par (page perso) . Évalué à 4.

                    Ça, j'en suis moins certain.

                    Donc, pour te faire plaisir.

                    La chose que je reproche (pour moi, certain aiment) à hibernate, est la complexité face à du sql, surtout au niveau des requêtes sql complexes.

                    Je préfère donc le sql, directement. En plus, on peut utiliser les techniques avancées de son gestionnaire de base de données, et on n'est pas limité par le moins bien des gestionnaires de bases de données supportés.

                    C'est étrange, c'est un peu ce que j'ai dit plus haut en fait. Que je n'aimais pas forcément hibernate, et que je préférais le sql.

                    Tu pourrais t'appeler patrick_g que je serais que c'est toi qui m'embête pour rien.

                    Envoyé depuis mon lapin.

                    • [^] # Re: Rien de transcendant dirait-on

                      Posté par . Évalué à -8.

                      Soit.
                      On a avait deja des preuves tangibles, maintenant on en est sur:
                      Tu es un couillon d'etudiant qui croit tout connaitre.

                      Sur ce, on se retrouve dans 5 a 10 ans, on reparlera du meme sujet, tu auras change d'avis.
                      Bonne continuation, et bon depucelage.
                    • [^] # Re: Rien de transcendant dirait-on

                      Posté par (page perso) . Évalué à 3.

                      > Je préfère donc le sql, dirctement. En plus, on peut utiliser les techniques avancées de son gestionnaire de base de données, et on n'est pas limité par le moins bien des gestionnaires de bases de données supportés.

                      J'ai du mal à comprendre, hibernate te permet d'avoir une connexion JDBC standard, donc je ne vois pas de limitations.
                      Ainsi, tu peux faire des requêtes SQL à l'aide hibernate si tu le désires. Tu pourrais donner des exemples ?
                      Etant donné que j'utilise hibernate, j'aimerais mieux connaître ses défauts.
                      • [^] # Re: Rien de transcendant dirait-on

                        Posté par (page perso) . Évalué à 2.

                        Tout comme active record permet de faire une requête sql classique dès qu'il se trouve dépassé.

                        Mais d'un coup tu perds presque tout les avantages d'hibernate (schéma de la base de données mis à jour, code standard, facilité de migration entre les différents sgbd), pour finalement avoir la plupart des inconvénients (une couche en plus, une configuration en plus, quelque chose à apprendre en plus, du code en plus…).

                        En plus, c'est pas comme si utiliser Hibernate était plus facile que d'écrire du sql…

                        Envoyé depuis mon lapin.

                        • [^] # Re: Rien de transcendant dirait-on

                          Posté par (page perso) . Évalué à 2.

                          Mais d'un coup tu perds presque tout les avantages d'hibernate

                          Pour ça, faudrait déjà que l'écriture de requètes spécifiques soit le cas général or non loin de là. De plus tu ne perds pas le mapping objet, tu ne perds pas la gestion du cache, tu ne perds pas la gestion de l'optimistic locking, etc.
                        • [^] # Re: Rien de transcendant dirait-on

                          Posté par (page perso) . Évalué à 2.

                          > En plus, c'est pas comme si utiliser Hibernate était plus facile que d'écrire du sql…

                          Bah si, justement ! Je commence à douter du fait que tu ai vraiment utiliser hibernate. Le langage HQL est beaucoup plus naturel pour un développeur java, du fait qu'il soit objet.

                          from Cat as cat where cat.name='Fritz', c'est pas vraiment compliqué.

                          De plus, avec les criteria, même plus besoin de HQL, on obtient ceci:

                          Cat cat = new Cat();
                          cat.setName('Fritz');
                          List results = session.createCriteria(Cat.class)
                          .add( Example.create(cat) )
                          .list();


                          Avec ce genre d'api de haut niveau, on peut très simplement développer des fonctions génériques de recherches pour toutes les tables d'une base.

                          >quelque chose à apprendre en plus

                          Justement, avec hibernate tu ne fais que du java. Le développer n'a plus besoin d'être db admin...

                          >du code en plus

                          Comme je l'ai dit précédemment, avec du code générique, on évite beaucoup de code. On évite de dupliquer des requêtes sql car on a des critères différents par exemple. Et, je ne parle pas des requêtes de mise-à-jour/insertion, qui ne sont plus écrites.

                          Perso, dans ma boite, je travail sur 2 projets web, un utilisant hibernate et l'autre pas. Et y a pas photo, de l'avis des autres développeur aussi, hibernate c'est du bonheur, un gain de temps et de qualité indéniable. Peut-être que tu n'as jamais bossé sur un projet conséquent et que tu manques de recul.
                          • [^] # Re: Rien de transcendant dirait-on

                            Posté par (page perso) . Évalué à 1.

                            Les développeurs *aiment* Hibernate, certes. Mais les fonctionnels beaucoup moins.
                            Un ami fonctionnel m'a raconté comment il a envoyé bouler Hibernate sur un projet, où un simple delete prenait.... 2 jours..

                            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                            • [^] # Re: Rien de transcendant dirait-on

                              Posté par (page perso) . Évalué à 1.

                              Un delete qui prend 2 jours ? Humm, je dirais que c'est absolument pas la faute d'hibernate. Si tu as plus d'information, ça m'intéresserait fortement.

                              Sinon, oui, la plus part du temps, les résistances à hibernate vient de db admin qui ne connaissent pas et pense que des requêtes générées seront affreusement lentes. D'après mon expérience, ce serait plus le contraire, car hibernate connait mieux que moi les différents sgbd.
                              • [^] # Re: Rien de transcendant dirait-on

                                Posté par (page perso) . Évalué à 2.

                                C'était la faute d'hibernate, enfin plus exactement de la faute du fait que les dev ne veulent absolument pas savoir ce qu'il y a derrière et ont fait n'importe quoi.

                                Si je me souviens bien, ça provoquais un delete récursif, voire cyclique. Je me souviens plus trop, faudrait que je rattrape le copain qui m'avait expliqué ça.

                                De ce que j'en avais compris à l'époque, c'était la plus pur application de ce problème : http://www.joelonsoftware.com/articles/LeakyAbstractions.htm(...)

                                (sur le fait que hibernate connaisse mieux que toi et moi les bdd, oui evidemment, mais ce n'est pas le problème)

                                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                                • [^] # Re: Rien de transcendant dirait-on

                                  Posté par (page perso) . Évalué à 4.

                                  Oui hibernate n'empêche pas les mauvais développement fait par de mauvais développeurs, mais de même que le "pur" sql (une belle requête avec un produit cartésien sur une dizaine de table et un magnifique distinct, car le développeur de comprend pas la structure de la base...).

                                  On ne peut condamner un outil car une partie de ces utilisateurs sont des cancres.
                                  • [^] # Re: Rien de transcendant dirait-on

                                    Posté par (page perso) . Évalué à 1.

                                    >>> hibernate n'empêche pas les mauvais développement fait par de mauvais développeurs,

                                    mais est-ce que hibernate favorise les mauvais développement par les développeurs ?

                                    C'est ça le problème, l'abstraction favorise l'arrivée de gens qui ne comprennent plus les mécaniques internes.
                                    • [^] # Re: Rien de transcendant dirait-on

                                      Posté par . Évalué à 2.

                                      C'est ça le problème, l'abstraction favorise l'arrivée de gens qui ne comprennent plus les mécaniques internes.

                                      N'est-ce pas le but de l'informatique et sont développement en couche ?

                                      "La première sécurité est la liberté"

                                      • [^] # Re: Rien de transcendant dirait-on

                                        Posté par . Évalué à 2.

                                        tout à fait, et c'est par cette même logique par laquelle je tombe sur des gens se servant de map comme de vector, ou de vector à la place de stack ou file.
                                        "Bah oui un conteneur c'est un conteneur, l'implémentation derrière on s'en branle".

                                        Forcément quand j'entends ça je laisse tomber; déjà que pour faire entendre que faire un constructeur intelligent et pas tout mettre dans les setteurs derrière, c'est plus performant, ou au pire, si le compilo fait des miracles c'est équivalent, c'est pas évident, alors si je m'arrête aux «détails» de l'implémentation on est pas rendu...

                                        Mais bon c'est pas grave, on a des bécanes de plus en plus puissante, ce serait dommage de ne pas les utiliser.

                                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                        • [^] # Re: Rien de transcendant dirait-on

                                          Posté par . Évalué à 2.

                                          Certe mais est-ce que tu connais bien ce que va faire ton compilo ? Est-ce que tu connais l'archi hardware de ta machine pour estimer ce qui va être lent à cause de la pagination ou de la gestion du cache ?

                                          On peut aller loin comme cela. Je sais qu'un mauvais algo peut te pourrir les perfs d'un niveau 1000 et seulement 10 pour l'implémentation mais c'est juste une histoire de barrière entre ce que l'on considère à connaitre ou non.

                                          "La première sécurité est la liberté"

                                          • [^] # Re: Rien de transcendant dirait-on

                                            Posté par . Évalué à 2.

                                            Sans aller jusqu'à l'opti bas niveau, des choses simple peuvent être faites, comme ne pas initialiser 2 fois la même variable, choisir un conteneur en fonction de son utilisation; alors certes on peut espérer que le compilo, un jour, pourra estimer tout seul, la façon dont est utilisé un conteneur et déterminer quid du vector, list, map, hash_map, stack est le plus pertinent, mais aujourd'hui ils ne le font pas encore, et c'est au développeur de réfléchir.

                                            C'est comme les parcours de tableau a rebours en C, si le compilo ne le détecte pas, bonjour la galère.
                                            Dans le même genre, il y a une énorme différence entre

                                            for( int i=0 ; i < T_MAX ; i++)
                                            for( int k=0 ; k < T_MAX ; k++)
                                            somme+=tab[i][k];

                                            et

                                            for( int i=0 ; i < T_MAX ; i++)
                                            for( int k=0 ; k < T_MAX ; k++)
                                            somme+=tab[k][i];

                                            Encore une fois le compilo peut détecter ce genre de détail, mais, c'est «peut», ce n'est pas automatique, et justement si le développeur est au courant de la blague.

                                            L'implémentation peu aussi impacter d'un facteur 1000, voir plus, notamment lorsque les cache miss disparaissent.

                                            Ensuite je ne demande pas d'avoir une connaissance parfaite du processeur, de la taille de son cache ou autre, mais au moins connaître les pièges courant, et un minimum de jugeote.

                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                            • [^] # Re: Rien de transcendant dirait-on

                                              Posté par . Évalué à 2.

                                              Ton exemple est vrai si tab est bien plus gros que ton cache L1.

                                              C'est pour ça que les différences de perf sont de l'ordre de 10 et pas tellement plus.

                                              "La première sécurité est la liberté"

                          • [^] # Re: Rien de transcendant dirait-on

                            Posté par . Évalué à 2.

                            >Justement, avec hibernate tu ne fais que du java. Le développer n'a plus besoin d'être db admin...
                            Ça, ça doit passer sur les petites bases, mais si malheureusement elle grossit il se passe quoi?
                            L'intérêt du java, est théoriquement de s'affranchir de l'architecture sous-jacente; mais je ne pense pas que l'on puisse s'affranchir de l'administration d'une grosse base de donnée; c'est un vrai boulot, et à optimiser correctement ça prend du temps.

                            Et coté code...

                            Cat cat = new Cat();
                            cat.setName('Fritz');

                            C'est quoi cette manie de créer un objet vide? C'est pas plus simple de faire un

                            Cat cat = new Cat('Fritz');

                            Je hais cette façon de faire! un objet prend 20 ligne à créer en faisant machin.setBidule, machin.setTruc.
                            Si c'est pour faire ce genre de truc, autant rester au C avec ses struct, et encore en c, on a la décence, en général d'avoir un initBidule(&truc), et parfois même ça retourne un booléen pour savoir si l'initialisation s'est bien passé.

                            Enfin, si tu peux faire du code générique, je ne vois pas ce qui empêche de créer un fonction tout aussi générique pour une requête SQL.

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: Rien de transcendant dirait-on

                              Posté par (page perso) . Évalué à 2.

                              J'ai pas dit que l'on pouvait ce passer d'un admin de base de données. Au contraire, je dis qu'un développeur doit développer et un 'vrai' admin db va analyser la base et conseiller ou alerter les dev. Hibernate n'empêche en rien l'optimisation.

                              Sinon pour le code,il vient de la doc hibernate... Je te rassure, en java on peut faire des constructeurs avec des arguments. Mais à ta réaction, je vois que tu n'a sans doute jamais fait de java en entreprise et ;)

                              >Enfin, si tu peux faire du code générique, je ne vois pas ce qui empêche de créer un fonction tout aussi générique pour une requête SQL.

                              Moi je parle d'une classe générique, qui te fournit toutes les recherches de bases pour tes tables (genre les listerTout ...), pas seulement d'une requête.
                              • [^] # Re: Rien de transcendant dirait-on

                                Posté par . Évalué à 2.


                                Sinon pour le code,il vient de la doc hibernate... Je te rassure, en java on peut faire des constructeurs avec des arguments. Mais à ta réaction, je vois que tu n'a sans doute jamais fait de java en entreprise et ;)

                                Oh, je croise cette façon de faire aussi en C++; et je n'ai toujours pas trouvé de personne capable de me donner une explication correct sur la raison d'être de ce truc verbeux; si c'est pour les diff, (encore que la majorité des soft de diff peuvent de donner les mots qui on changé, il suffit de faire

                                Plop( int avance,
                                const Tonk &bidule,
                                Pipo *truc):

                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                • [^] # Re: Rien de transcendant dirait-on

                                  Posté par (page perso) . Évalué à 4.

                                  Souvent, dans les frameworks java, les objet sont instanciés et initialisés automatiquement grâce au setter/getter. De plus, les objets (mappant des tables) ont souvent beaucoup d'attributs, et faire un constructeur avec tous les arguments devient incompréhensible, genre avec

                                  new Cat( 'Fritz', 9, 4, 5, 'chatchat', 150, new Date() );
                                  on ne sait pas ce que l'on fait, il faut aller regarder la classe, alors que

                                  Cat c = new Cat();
                                  c.setNom('Fritz');
                                  c.setAge(9);
                                  c.setNombreDePatte(4);
                                  c.setPoids(5);
                                  c.setSurnom('chatchat');
                                  c.setPrixALaDecoupe(150);
                                  c.setDateDeMiseAMort( new Date() ); // on le tue le plus tôt possible

                                  c'est plus expressif (mais plus verbeux). Faut comprendre que le plus gros problème pour un programme, c'est qu'il doit être maintenable.
                                  Ceci peut être un début d'explication...
                                  • [^] # Re: Rien de transcendant dirait-on

                                    Posté par (page perso) . Évalué à 4.

                                    Qu'est qui assure que l'objet Cat soit dans un état cohérent à un moment T ? Comment on fait lorsqu'on rajoute des propriétés à Cat ?

                                    Le constructeur sert justement à créer un objet, sémantiquement cohérent (avant le constructeur il n'existe pas, après il existe et il est cohérent). Utiliser des setters dans tous les sens te fait juste perdre cette garantie (tu génère un objet Cat sans aucun sens, puis tu rajoute des informations en espérant ne rien oublier (et que personne ne l'utilise avant qu'il ne soit bien construit). Si on veut vraiment éclaircir le problème des arguments du constructeurs, les arguments nommés sont probablement une solution plus élégantes.
                                    • [^] # Re: Rien de transcendant dirait-on

                                      Posté par (page perso) . Évalué à 3.

                                      C'est un reproche que j'ai déjà entendu et que je trouve légitime (la non-construction atomique via un constructeur). Mais comme tu dis c'est une faiblesse de Java, c'est pas trop la faute d'Hibernate. Et c'est pour ça que la JSR 303 (Bean Validation) est née. Et son implémentation de référence est... Hibernate Validator.
                                    • [^] # Re: Rien de transcendant dirait-on

                                      Posté par (page perso) . Évalué à 1.

                                      > Qu'est qui assure que l'objet Cat soit dans un état cohérent à un moment T ?

                                      L'instant T, je m'en moque. Par contre lors de l'enregistrement en base, c'est mon schéma de table ou les contraintes hibernate qui m'assure que l'objet soit cohérent.

                                      >Le constructeur sert justement à créer un objet, sémantiquement cohérent

                                      new Cat( null, null, null, null, null, null, null );
                                      >Si on veut vraiment éclaircir le problème des arguments du constructeurs, les arguments nommés sont probablement une solution plus élégantes.

                                      Oui mais on fait comment en java ?

                                      Faut voir aussi, que ce type d'objet correspond souvent à un formulaire web dont les zones de saisie correspondent au attributs initialisés à l'aide des getter/setter.

                                      Sinon, je ne défend pas forcément cette méthode, j'essaie de l'expliquée...
                                      • [^] # Re: Rien de transcendant dirait-on

                                        Posté par . Évalué à 4.


                                        new Cat( null, null, null, null, null, null, null );


                                        Chez moi ça pète une exception...

                                        en général j'ai toujours un construceur par défaut ne faisant rien (pour pouvoir utiliser la stl), les setteurs n'existent QUE pour les valeurs/objets étant susceptible d'être modifiées, mais bon la norme est d'utiliser des IDE qui font toutes les conneries à nos place :D

                                        Pour coder avec ce genre de broutilles de m... je suis obligé de vérifier moi même si ce qu'on me file est valide, j'ai une plâtrée de lignes qui ne servent qu'à vérifier l'intégrité de ce que l'on me donne (sous prétexte que je peux toujours chopper des truc mal codés) Si la lib utilisée ne permettait pas d'avoir un objet à moitié initialisé ça poserait moins de soucis... (Et qu'on ne vienne pas me parler d'une fonction isValid(), c'est déjà assez laid comme ça! )

                                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                      • [^] # Re: Rien de transcendant dirait-on

                                        Posté par (page perso) . Évalué à 3.

                                        Je n'ai rien en particulier contre Hibernate, je connais uniquement de nom (moins j'utilise de Java, mieux je me porte). Je réagissais juste à cette "manie" de faire des ctor vide et de setter les propriétés par la suite, qui me semble une plaie du point de vue sémantique objet. De plus, arguer que ça matche la représentation interne de l'objet, c'est encore pire : un objet doit présenter une sémantique clair lié à son rôle, pas à son implémentation : a Cat is a Cat, quelque soit son implémentation.
                                        • [^] # Re: Rien de transcendant dirait-on

                                          Posté par . Évalué à 3.

                                          Mmmmmh... Quid du duck typing alors ? :)
                                        • [^] # Re: Rien de transcendant dirait-on

                                          Posté par . Évalué à 0.

                                          certes.
                                          Apres, forcer le constructeur a prendre les arguments, ca pose des problemes pratique:
                                          - Quand ton objet a un gros nombre de membres obligatoires, v'la la gueule du constructeur... 15 parametres au constructeur, c'est pas humain.
                                          - Ca rend le code absolument illisible. Surtout quand nombre des membres ont le meme type (genre string). T'as une probabilite de te planter quand tu construit manuellement l'objet qui est tres proche de 1. Et pour la relecture, bon courage.
                                          - Tu rajoutes un attribut, t'as *tout* ton code qui pete.
                                          - Ca fait exploser le code du constructeur. Tu te tapes en enorme if(param1 == null || param2 == null ....) throw new IllegalArgumentException("Param1, param2 ... must not be null").
                                          Et si en plus tu veux une exception au message pertinent, ben ton constructeur vient de prendre 56 (15 * 4) lignes pour rien.

                                          Et en pratique, des classes avec 15 membres obligatoires (ou plus meme...), ca se voit regulierement.

                                          Ca c'est pour les problemes les plus simples.
                                          Je sais pas pour les autres langages, mais le concept de bean en java est quand meme largement repandu, parce qu'il apporte beaucoup de souplesse et de genericite.
                                          C'est plus simple de construire un objet vide et de lui setter ses properties a la ligne d'apres dans le code que de devoir deviner quel parametre va ou en fonction de son nom.

                                          Alors on fait une entorse a la theorie, parce que c'est ingerable sinon.
                                          • [^] # Re: Rien de transcendant dirait-on

                                            Posté par . Évalué à 5.

                                            Quand ton objet a un gros nombre de membres obligatoires, v'la la gueule du constructeur... 15 parametres au constructeur, c'est pas humain.
                                            Oui c'est clair que coté lisibilité il y a une énorme différence entre

                                            Cat c new Cat( "Fluffy", // nom
                                            GRIS_TIGRE, // pelage
                                            VERT, // couleur des yeux
                                            4 ) ;// nombre de patte

                                            et

                                            Cat c();
                                            c.setNom("Fluffy"); // nom du chat
                                            c.setPelage(GRIS_TIGRE); // pelage
                                            c.setCouleurYeux(ROSE) ; // couleur des yeux
                                            c.setNbPattes(4); // nombre de pattes


                                            (oui pour les commentaires après les setteurs, j'ai déjà croisé)

                                            Ca rend le code absolument illisible. Surtout quand nombre des membres ont le meme type (genre string). T'as une probabilite de te planter quand tu construit manuellement l'objet qui est tres proche de 1. Et pour la relecture, bon courage.
                                            Marrant ça, avec les commentaires, tu peux en rajouter autant que tu veux, ça reste lisible.

                                            Tu rajoutes un attribut, t'as *tout* ton code qui pete.
                                            Entre un code qui ne compile pas et un code qui plante, mon choix va immédiatement vers celui qui ne compile pas.

                                            Ca fait exploser le code du constructeur
                                            C'est toujours mieux qu'exploser le code à chaque création d'objet..

                                            C'est plus simple de construire un objet vide et de lui setter ses properties a la ligne d'apres dans le code que de devoir deviner quel parametre va ou en fonction de son nom.
                                            Chez moi setBidule met à jour la propriété bidule_ de l'objet (ou _bidule, ou m_bidule selon la convention de nommage), et le paramètre bidule du constructeur, va, "Oh surprise" setter cette même propriété...

                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                            • [^] # Re: Rien de transcendant dirait-on

                                              Posté par . Évalué à 4.


                                              Cat c new Cat( "Fluffy", // nom
                                              GRIS_TIGRE, // pelage
                                              VERT, // couleur des yeux
                                              4 ) ;// nombre de patte


                                              Ton truc ça survit comment aux refactoring que subira ton code ? Après dix ans, tu crois vraiment que les commentaire voudront encore dire quelque chose ou qu'en fait le // nom est devenu le nom de la belle mère du propriétaire du chat sans que personne n'ait changé les 10 000 commentaires que tu as mis partout ?

                                              Constructeur ou setter y'a des avantages et des inconvénients aux deux, et j'adapte en fonction. Mais ta proposition, elle est naze. L'information sur la sémantique des arguments tu l'as déjà dans la javadoc, dupliquer cette information à chaque utilisation c'est un non sens total.
                                              • [^] # Re: Rien de transcendant dirait-on

                                                Posté par (page perso) . Évalué à 3.

                                                J'aimerai bien une explication sur le pourquoi de la nazitude de l'argument du monsieur plus haut, parce qu'il m'a assez convaincu. Pas pour la forme de la doc, mais pour l'idée que je préfère faire pêter la compil plutôt que le runtime.

                                                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                                                • [^] # Re: Rien de transcendant dirait-on

                                                  Posté par . Évalué à 5.

                                                  Je n'ai parlé que des commentaires pour d'écrire les paramètres des constructeurs: Marrant ça, avec les commentaires, tu peux en rajouter autant que tu veux, ça reste lisible.. Ca n'apporte rien et c'est totalement impossible à maintenir.

                                                  Pour l'aspect exploser à la compile, je ne vais pas ne pas être d'accord, moi qui ne supporte pas les langages à typage dynamique pour faire quoi que ce soit de sérieux. D'ailleurs le débat entre ctor contre setter se retrouve entre guice et spring. Par défaut j'essaie d'utiliser une approche ctor et objet immutable et d'adapter selon les cas. Parfois l'approche par setter est intéressante.
                                                  • [^] # Re: Rien de transcendant dirait-on

                                                    Posté par . Évalué à 3.

                                                    Tu as raison ! Les commentaires c'est le mal. Ils ne sont jamais à jour et le compilo ne t'aidera jamais pour les corriger.

                                                    L'approche setter parrait contraire à une approche OO propre car ton objet peut se retrouver dans des états qui ne correspondent à rien.

                                                    "La première sécurité est la liberté"

                                                    • [^] # Re: Rien de transcendant dirait-on

                                                      Posté par . Évalué à 1.

                                                      ben disons que si t'as tellement de parametres que t'es *oblige* de commenter chacun des parametres de ta fonction pour dire ce que c'est, c'est que, tres probablement, t'as un gros probleme de design de ta fonction non?
                                                      • [^] # Re: Rien de transcendant dirait-on

                                                        Posté par . Évalué à 3.

                                                        Pour moi devoir rajouter des commentaires montrent que le code est incompréhensible et dois être réécrit.

                                                        "La première sécurité est la liberté"

                                                        • [^] # Re: Rien de transcendant dirait-on

                                                          Posté par . Évalué à 4.

                                                          en général je suis d'accord avec cette remarque; tout comme celle devant limiter le nombre de paramètre d'une fonction.
                                                          Cependant il y aura toujours des cas où un commentaire sera utile.
                                                          comme par exemple l'explication d'une formule mathématique ou d'un raccourcis de calcul. Si on vois bien le calcul, la raison de celui ci ou la façon de l'effectuer peut ne pas être clair;

                                                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                        • [^] # Re: Rien de transcendant dirait-on

                                                          Posté par . Évalué à 1.

                                                          autant je suis pas d'accord avec ca en regle generale, mais autant devoir commenter l'appel d'une function juste pour copier les @param de la javadoc parce que c'est le seul moyen de pas rendre le relecteur chevre, oui, le code doit etre reecrit.
                                                          Et encore... qu'est ce qui te dit que le developpeur n'a pas inverse 2 params par megarde?
                                          • [^] # Re: Rien de transcendant dirait-on

                                            Posté par (page perso) . Évalué à 4.

                                            J'ai été sensibilisé au contrats avec SmartEiffel et Lisaac, et Mildred nous a jour secoué les méninges afin qu'on distingue ce qui relève du contrat pré et post, et des exceptions.

                                            L'exemple que tu cites est de l'ordre du contrat et non de l'exception.
                                            Amha (pour le moment), l'exception sert à gérer les erreurs externes qui perturbent le bon déroulement d'un programme : plus de place sur le disque, plus de mémoire, on arrive pas à établir ou à garder la connexion, etc...

                                            Là, c'est une erreur interne du programme : certains des argument sont à Null.
                                            C'est un contrat qui doit être posé pour péter s'il y a erreur.

                                            En java, il y a assert, mais c'est pas hérité. Et on a pas de mot clé Old qui permet de comparer l'état d'un paramètre au début avec ce paramètre modifié en sortie.

                                            Sur l'entorse à la théorie, là encore, c'est une histoire de contrats... au niveau de l'objet.
                                            En Eiffel, l'invariant de classe http://en.wikipedia.org/wiki/Class_invariant permet de vérifier à tout moment que le contrat est respecté.

                                            Je pense que ça peut apporter une solution au problème posé par Zul.

                                            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                                            • [^] # Re: Rien de transcendant dirait-on

                                              Posté par (page perso) . Évalué à 3.

                                              Oui un contrat de classe, ça pourrait être bien (enfin même c'est bien tout court). Après je suis pas sûr que des classes avec des ctor avec 15 arguments, ils aient des invariants de classe très clair :).

                                              Et sinon, je préfère largement aussi la solution où la compilation échoue, que les solutions où le runtime pourrait detecté une erreur (même si la systémisation via contrat / contrat de classe c'est mieux que rien). Y'a assez de trucs qui peuvent chier au runtime pour pas en plus rajouter des choses qui pourraient être correct par construction (typiquement ce genre de choses, la gestion des types, ....).

                                              My 2 cents, de quelqu'un qui est très très loin des j2ee et autres méga techno IT
                                  • [^] # Re: Rien de transcendant dirait-on

                                    Posté par (page perso) . Évalué à 2.

                                    Avec une syntaxe à mot clé, on peut écrire :


                                    c : CAT := CAT.create "Fritz" age 9 nombre_de_patte 4 poids 5 surnom "chatchat" prix_a_la_decoupe 150 date DATE.today;


                                    C'est moins verbeux :-)

                                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Rien de transcendant dirait-on

        Posté par (page perso) . Évalué à 3.

        Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate
        Je penses qu'il fait référence à la syntaxe LINQ disponible en C# et issu de SQL, pas directement à SQL.
      • [^] # Re: Rien de transcendant dirait-on

        Posté par (page perso) . Évalué à 4.

        - Qu'est ce que spring a de crade? L'IoC, dependancy injection et tout le tralala, c'est quand meme vachement elegant et rudement pratique pour des grosses applis.
        Pratique, c'est pas faux, élégant, j'en suis moins sûr.
        A débugger, en restant des heures coincés dans les couches de spring quand tu veux tomber simplement passer de l'appel de fonction à la fonction elle même, c'est moins élégant déjà.
        Et j'aime pas (mais c'est personnel) les goto cachés.

        N'empêche que ça ressemble énormément à un workaround sur les limites de langages à classe. (troll open)

        Et que ce soit au niveau de l'architecture ou du code, spring est clairement un tres bon exemple d'elegance.
        Les fichiers de conf en xml c'est l'horreur et surtout pas élégant, pas human readable en tout cas.
        Spring Webflow le pire de tous, avec ses fichiers de conf d'interface et tout le bordel que ça implique derrière (appel de fonction avec ses paramètres tordus et ses histoires de scope), c'est surtout pas élégant.

        M'enfin je comprend que ça fasse tripper les ingénieurs, c'est le plus pure style d'usine à gaz d'ingénieurs typiques.

        - Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate. La on se débarasse carrement de cette daube de sql.
        Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème. J'en suis heureux pour toi. Moi je préfère SQL : j'aime jouer avec les ensembles (intersection, différence, etc...), et je suis très à l'aise avec ça.

        HQL est pas mal, et j'aimerai bien le voir intégré au langage (cela dit je n'y toucherai pas : depuis que j'ai claqué la porte à la capa java dans ma boite, hors de question que je retouche à ce langage pourri). LINQ est intéressant à ce titre, puissant, mais asez tordu.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Rien de transcendant dirait-on

          Posté par . Évalué à 1.

          mouais...

          Pratique, c'est pas faux, élégant, j'en suis moins sûr.
          tu parles de l'IoC en elle meme ou de la facon dont spring le fait?

          A quoi ca ressemblerait si c'etait dans le langage (ie sans workaround?) J'ai du mal a comprendre comment tu peux integrer ce concept au langage sans soit casser le decouplage offert par l'IoC, soit pourrir ta classe injectee avec des trucs sans rapport.
          DIsons que le concept meme de l'IoC c'est de declare/effectuer les injections en dehors des classes concernees.

          De meme, comment tu ferais pour gerer la distinction prototype/singleton (desole le terme est pas adapte ici, mais l'adapte ne me revient pas), avoir plusieurs instances des beans injectes etc?

          Pour le cote usine a gaz, je te trouve tres dur avec spring.
          Je connais pas webflow, donc je m'abstiendrais de commenter dessus.

          Garde a l'esprit tout de meme que jee, spring et tout ces machins compliques, ca a un objectif: rendre des trucs tres complexes possible.
          Pas rendre le dev web simple, pas etre simple a utiliser, juste rendre une enorme appli metier faisable.
          Si tu veux qq chose de simple, jee n'est clairement pas le bon choix.

          Donc ouais, ya plein de couches, c'est un peu le bordel, mais sans ca, ca serait un bordel bien plus grand a gerer.

          En pratique, spring (en particulier) j'ai aucun reproche a lui faire, il m'injecte mes beans la ou je veux, ca me donne un point central pour les declarer, et vu comment l'appli devient touffue, je suis plutot content de declarer mes services/repository/assemblers de facon externe a l'appli, sans pour autant les transformer en singleton.
          Pour ce qui est de devoir debugger dans les couches de spring, soit tu as rate qq chose, soit je comprends pas ce que tu veux dire. Ca doit etre le framework web le moins intrusif et qui gene le moins le debuggage que je connaisse. J'ai peut etre pas compris ce que tu veux dire cela dit.

          Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème.
          ???
          On a le mapping de nos domain objects sur les objets eux meme via les annotations eeeeeet....
          C'est tout.

          @entity(table="plop")
          @OneToMany(joinColumn="shaby")
          @Column(bla)
          etc.

          On se prend parfois un peu la tete pour arriver a ecrire le mapping (mais bon, avec hibernate t'en chies un peu au debut, puis les meme pb reviennent, tu sais donc les resoudre et ca va vite au final).
          On a un systeme de filter pour les recherches qui utilise HQL. Bref, la partie repository dans notre appli, c'est getFromId, saveOrUpdate, delete et 50 lignes de construction de requete HQL.
          Apres que tu kiffes le SQL, ok, c'est ton droit le plus fondamental, mais quand tu vois la db purement comme une facon de persister ton graphe d'objet en ram, c'est agreable de ne (presque) pas y penser.

          Tu aimes peut etre certes ca, c'est cool, mais dans la plupart des cas, une requete sql c'est juste "bon ben, db, tu prends toutes ces lignes la, et eventuellement tu me choppes les autres lignes dans cette table avec le meme id et aussi dans cette autre table, pis apres tu me tries ca comme ca. Merci". Les cas ou le sql est rellement interessant sont pas si courant, et la plupart du cas c'est juste du boiler plate bien relou.
          Rajoutes par dessus la problematique du cache et celle de la mise a jour du graphe persiste a chaque modification, ca devient dur de trouver des arguments au SQL pur.
          By the end of the day, tout ce que veut, c'est un set d'objet de toutes facons, donc etre oblige de passer par un langage pas du tout adapte aux objet pour ca, je trouve ca particulierement casse bonbons.
          Et c'est vraiment ce qui me gene dans le sql avec les langages objet: t'introduis un paradigme relationnel qui n'a strictement rien a voir avec l'objet.
          • [^] # Re: Rien de transcendant dirait-on

            Posté par . Évalué à 4.

            Donc ouais, ya plein de couches, c'est un peu le bordel, mais sans ca, ca serait un bordel bien plus grand a gerer.

            Sauf que de ne nombreux de ces bordels de designs patterns ou autre frameworks imbattables sont juste dus au fait que le langage ne donne pas la citoyenneté de première classe à pas mal de ses constructions même celles les plus fondamentales (dans le cas de Java on pourrait citer les classes par exemple...).

            Utilise un langage dans lequel pratiquement tout à la citoyenneté de première classe (eg. Python) et tu verra que tu pourra faire tout ça simplement, de manière lisible, et qu'en plus tu pourra au besoin en inventer d'autres simplement.
            • [^] # Re: Rien de transcendant dirait-on

              Posté par . Évalué à 1.

              ah.
              Ben pourquoi ils se sont fait chier a implementer Spring en python et a mettre l'IoC en tete de liste des features, si ca se fait naturellement par construction du langage?

              Non, mais la, serieusement, le concept meme d'IoC et d'AOP, va falloir que vous m'expliquiez comment ca se construit par le langage, vu que le concept meme du truc, c'est d'etre totalement externe a la classe traitee et entierement dependant d'un contexte d'utilisation (ie une config de l'appli).

              Pour le reste de spring, en vrac la gestion des pools de connexion db, la transactionnalite et la secu (authent notamment) , serieux expliques moi comment on met tout ca dans le langage?!?
      • [^] # Re: Rien de transcendant dirait-on

        Posté par (page perso) . Évalué à 4.

        Tiens, je vais mettre les deux pieds joint dans le troll.
        Personnellement, j'aime beaucoup SQL. C'est un vieux langage, qui as pas trop mal évolué ces derniers temps, qui a certes ses limites (pas de possibilité de jouer avec les résultats en ligne, pas possibilité de "doublonner" une même table dans le from, etc...), mais qui reste très puissant pour exprimer en 2mn des trucs hyper gonflant à écrire avec des boucles imbriquées - et moins error prone.
        Je sais que je suis minoritaire, et que les j2ee fan boy aiment pas ça en général.

        Mais si c'était intégré en natif dans les langages, à la HQL/LINQ/whatever (d'aileurs ça commence à venir), et qu'on prenait l'habitude de les utiliser, l'industrie de l'informatique de gestion ferait beaucoup de gains de productivité.

        Et tu verrai que tu te prend beaucoup moins la tête à faire deux not in imbriqué en déclaratif, que d'écrire ta boucle qui risque de péter à cause de call on null....

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Rien de transcendant dirait-on

        Posté par . Évalué à 1.

        Je ne savais pas ce que c'était que "dependancy injection" et après avoir lu la page de wikipedia j'aurai en fait préféré continuer de ne pas savoir.

        Pour épargner aux autres une furieuse envie de vomir voir un immense suicide collectif je vais essayer de résumer : ça permet d'écrire des choses plus complexes et plus illisible que les factory pour les pauvres langages ayant besoin de telles conneries pour cause de non citoyenneté de première classe de la plupart de leur constructions. Pour dire l'étendue des dégâts : c'est presque aussi illisible que des templates C++.

        (je pourrais éventuellement dire ce que je pense des ORM une prochaines fois :p )
        • [^] # Re: Rien de transcendant dirait-on

          Posté par . Évalué à 2.

          wow.

          Je pense que t'as pas compris grand chose au concept vu ce que t'en dis.
          Comme j'ai demande plus haut ,je vois pas comme la DI peut etre integree dans le langage, vu que le concept meme du truc, c'est en gros:

          Une classe se base sur certains objets (dont l'implementation peut etre remplacee) pour faire ses operations.

          L'exemple de base, c'est un service qui a un besoin d'un DAO pour recuperer ses objets depuis la db et ensuite en faire ce qu'elle a faire.

          Demander au service d'instancier en dur sa dependance, ie le DAO ici, ca pose de gros problemes.
          Le premier evident etant que si ton DAO est thread safe, ce qu'on espere tous, c'est plutot idiot et meme dangereux d'en instancier plusieurs.

          Conceptuellement, ton service n'a pas a savoir comment ton dao est architecture, il ne possede pas le dao, se contente de l'utiliser. Un autre qu'il possede encore moins, c'est la config du dao (host db, login pass et ce genre de conneries).
          Et la pour le coup, la derniere chose que tu veux faire, c'est que ton service ai a connaitre tout ca.

          Ca va te donner, dans le constructeur du service:
          monDao = MonDAOORacle(hots, login, pass);

          et si tu passes a pgsql, faut que tu passes dans tous tes services et que tu changes par
          monDao = MonDAOPGsql(host, login, pass);

          C'est ballot quand meme...

          C'est encore plus idiot de demander a ton dao d'instancier les services, ca le lie a un composant qui lui est totalement etranger. Son boulot, c'est de cracher des objets depuis la db, et de les y remettre, c'est tout.

          Bref, le probleme est donc: comment faire pour que les dependances du service soient satisfaites?
          Le service ne peut pas creer le dao, mais le dao ne peut pas creer le service.
          Ben la solution c'est que ces objets n'ont pas a gerer leur dependances puisqu'ils n'ont pas, et n'ont pas a avoir, l'information necessaire. Par contre, une classe externe, dont le but est de gerer tout ce merdier, elle a l'information et le contexte elle, et peut donc coordoner tout ce bordel.

          Ton dao est un singleton? Tres bien, spring va t'en creer une seule instance et la donner a tout le monde.
          FInalemet singleton, c'etait pas une bonne idee et tu refactores le DAO?
          Pourquoi le service devrait connaitre les details d'implem du DAO? Il se contente d'appeler des methode publiques dessus.
          Pas grave, tu changes un attribut dans la config de spring, et chaque service aura son instance a lui.

          Le client a un sursaut de decence, et il passe la db d'oracle a PGSql?
          Pourquoi le service devrait savoir quelle db stocke le tout? il travaille avec des objets lui, pas des relation!
          Ben tu changes l'implem de ton dao dans spring et ca roule.

          Tu fais des tests unitaires et ton DAO est en fait un simple mockup? Pourquoi est ce que le service devrait avoir connaissance de l'existence meme de tests unitaires?
          Allez hop, tu changes l'implem de ton bean dans spring et paf, ton service n'est meme pas au courant qu'il parle a un dao bidon.

          Et sans toucher la moindre ligne de code.
          Ton service a besoin d'un DAO et il se fout eperdumment de savoir d'ou il vient. Et tant mieux, peut importe d'ou tu viens, dis moi plutot ou tu va.
          L'archi du dao ne fuit pas dans le service, celle du service ne fuit pas dans le dao, tout le monde est isole et ton appli est plus simple a maintenir, modifier et a developper.

          Ca t'eclaire un peu plus sur le DI et l'IoC en general?

          Apres, spring, ca se limite pas qu'a ca non plus, mais ca reste un de ses usages premiers.
          • [^] # Re: Rien de transcendant dirait-on

            Posté par (page perso) . Évalué à 4.

            Je reconnais tout ce que j'ai vu en entreprise, DTO, DAO, DTA, Services, vue..

            Je comprend bien la nécessité (mais il semble que ceux qui se sont creusés la tête ont trouvé des concepts plus intéressant), mais l'implémentation me dérange.

            Je la trouve inutilement lourde.

            Par exemple, pourquoi ne pas mettre une fichier java à la place du xml. Vue le niveau de profondeur (de l'arbre) du fichier de conf xml de spring, ça devrai pas poser de problèmes.

            Ca éviterai les emmerdes avec les typos, où tu comprend pas pourquoi ce foutu DTA se charge pas, parce qu'il y a une erreur d'un caractère dans le fichier de conf xml, qui bien entendu est examiné à l'exécution, et est bien sûr pas foutu de te donner un message d'erreur clair qui te dit "tu t ptet planté dans l'appellation de l'objet ou de sa méthode, regarde voir le fichier de conf".

            Bah non, a moins d'y avoir passé 2 ans, et d'être auréolé de la gloire d'être l'expert javouille dans la boite, tu galères et perd du temps con parce que le fichier de conf est pas lu avant que l'appli démarre.

            Et me dit pas que charger un .class à chaud dans une appli c'est difficile.
            Une VM ça sert à ça.
            Et ça s'automatise très bien.

            Ya plein de langages où ça pose pas de problèmes.

            Non, là, tout une couche monstreuse d'introspection pour faire un truc de base.
            Sans compter la désespérante et insupportable inflation d'objet.
            Ya en dans les sens ! 20 classes pour les collection, au minimum 5 pour les chaines.
            T'as trois fonction qui se battent en duel dans les libs de base (String, List).
            Les int, boolean pas objet, etc...
            Bref, je diverge.

            Java est un langage très limité, pas expressif, et t obligé d'utiliser des usine à gaz pour faire un truc simple.

            Ca marche oui, mais c'est très lourd.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Rien de transcendant dirait-on

              Posté par (page perso) . Évalué à 2.

              Par exemple, pourquoi ne pas mettre une fichier java à la place du xml. Vue le niveau de profondeur (de l'arbre) du fichier de conf xml de spring, ça devrai pas poser de problèmes.

              Eh bah tu vas être heureux quand ta boîte passera à Spring 3 alors. Depuis 2.5 ils géraient les annotations mais là dans le 3 avec toutes les nouvelles annotations et d'autres nouveautés que je trouve assez sexies, tu vas carrément pouvoir résumer ton fichier de conf xml à une balise scan-moi-le-projet.

              De la lecture : http://static.springsource.org/spring/docs/3.0.x/spring-fram(...)
          • [^] # Re: Rien de transcendant dirait-on

            Posté par . Évalué à 2.

            Tu peux aussi jeter un coup d'oeil aux langages orienté composants.

            On y définit bien des trucs qui sont chacun indépendant les uns des autre autrement que par leur requis (ou équivalent) et ce à tout les niveaux du dev (dont la compilation de chacun des composants).
            Puis on peut les brancher ensemble, au runtime si on veut.

            Tu peux aussi regarder les trucs à composants basés sur les flux où connecte des composants ensemble et les données sont des flux.
            On sort un peu du cadre de la programmation impérative, mais on peut modéliser beaucoup de trucs comme ça d'une manière élégante.

            Et comme le dit Ontologia, tout peut se faire directement en code et pas dans des ignobles fichiers xml.
          • [^] # Re: Rien de transcendant dirait-on

            Posté par . Évalué à 2.

            Ton exemple est trop simpliste ; c'est justement le genre de chose que tu peux résoudre facilement en Python grâce à la citoyenneté de première classe des fonctions, des classes, etc.

            Je ne dis pas que tel ou tel framework implémentant de manière très avancé tel ou tel concept dans un langage fut-il inadapté ne peut pas être parfois utile. Je dis qu'il sert beaucoup trop souvent d'enclume à écraser les mouches. (et quand c'est le cas et qu'on passe derrière, c'est assez énervant).
            • [^] # Re: Rien de transcendant dirait-on

              Posté par (page perso) . Évalué à 2.

              Comment on fait en Python ? Ca m'intéresse :-)

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Rien de transcendant dirait-on

                Posté par . Évalué à 2.

                Je vois pas la difficulté de son truc, donc je suis peut-être totalement à côté de la plaque, mais en python je ferais comme ça :


                class PGSqlDAO:
                …def __init__(self, config):
                ……self._dbConn = Postgres(config['user'], config['password'], config['database'])
                ……#etc.


                Avec une config (provenant par exemple d’un fichier YAML)


                config['dao']['constructor'] = 'PGSqlDAO'
                config['dao']['user'] = 'admin'
                config['dao']['password'] = 'admin'
                config['dao']['database] = 'test'


                et dans l’utilisateur du DAO:


                class DAOUser:
                …def __init__(self, config):
                ……self._dao = eval(config['dao']['constructor'])(config['dao']) # dans un cas réel, tu utiliserais un truc un peu moins bourrin que eval, mais l’idée est là
          • [^] # Re: Rien de transcendant dirait-on

            Posté par . Évalué à 2.

            Quelle est la différence avec une Factory (tu fais un DAOAbstractFactory, avec DAOPGSqlFactory, DAOMySQLFactory…) ?
          • [^] # Re: Rien de transcendant dirait-on

            Posté par (page perso) . Évalué à 2.

            Une doc intéressante sur l'inintérêt de la DoI en Ruby, par un repenti : http://groups.google.com/group/kyrug/browse_thread/thread/f3(...)

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Rien de transcendant dirait-on

      Posté par . Évalué à 4.

      Oui...
      Si vous voulez vraiment un vrai langage un peu innovateur (au niveau programmation concurrente notamment) qui tourne sur la JVM il faut plutôt regarder du coté de Clojure[1] ou éventuellement Scala[2]. Je vous recommande les présentations vidéos[3] de Clojure par Rich Hickey, son auteur.

      [1] : http://www.clojure.org
      [2] : http://www.scala-lang.org/
      [3] : http://clojure.blip.tv/
    • [^] # Re: Rien de transcendant dirait-on

      Posté par . Évalué à 3.

      « Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...) »

      Faudrait arrêter un peu de dire des bêtises des fois. :)

      Les mémoires transactionnelles, dans le principe c'est très bien, mais en pratique ça offre une perte de performances, et ce sera toujours le cas tant que ce sera fait en soft uniquement. Il faudrait d'abord convaincre les constructeurs de matériel ...

      Sinon, pour le moment en tout cas, dès qu'il s'agit de faire de la perf, malheureusement, utiliser des threads (et donc un modèle non-déterministe) est un peu obligatoire.

      J'attends beaucoup de trucs genre GCD et tout ce qui est closures cependant. Le boulot fait dans C# à ce niveau pour pouvoir générer du parallélisme est assez intéressant.
      • [^] # Re: Rien de transcendant dirait-on

        Posté par . Évalué à 2.

        Tu veux des "mémoires transactionnelles" en HW? j'ai des doutes sur ce qui est attendu exactement, mais j'ai l'impression que c'est encore un truc complexe que les softeux refilent au hardeux en croyant au Père noël.

        "La première sécurité est la liberté"

        • [^] # Re: Rien de transcendant dirait-on

          Posté par . Évalué à 2.

          Je ne dis pas que c'est nécessairement réalisable (enfin, réalisable selon des contraintes du genre coût, consommation supplémentaire, etc.), mais ce que je dis en tout cas, c'est que tous les papiers que j'ai pu lire concernant les mémoires transactionnelles, et qui se faisaient en soft avaient la plupart du temps un, voire deux problèmes :

          - ils plombent les perfs dans leurs implémentations actuelles; et parfois,
          - ils rajoutent (lire : surchargent) de nouveaux mots-clefs dans les langages (j'ai souvenir d'une implém de mémoire transactionnelle dans une JVM qui rajoutait encore des qualificatifs en plus des synchronize et autres joyeusetés).
          • [^] # Re: Rien de transcendant dirait-on

            Posté par . Évalué à 2.

            En gros, tu veux de l'atomicité sur la modification complète d'une zone mémoire. C'es très couteux à faire ça. C'est en gros un mécanisme de VM à un niveau de grain fin !

            "La première sécurité est la liberté"

            • [^] # Re: Rien de transcendant dirait-on

              Posté par . Évalué à 2.

              On est bien d'accord. :-) Je sais qu'il existe des tentatives pour faire des mémoires transactionnelles « light » au niveau soft. Je me demande si du coup, ça ne serait pas plus envisageable aussi pour les réaliser en hard...
  • # Noop

    Posté par . Évalué à 7.

    No opération

    Une des deux instructions assembleur qui m'on le plus facinées, avec brn (branch never en 6809).
    ...petite larme... :)

    Sinon, ma vrai question, c'est :
    "Il est ou le hello wolrd ?"

    J'ai cherché sur le site et je l'ai pas trouvé.

    A défaut de Hello world, j'aimerai bien voir un bout de code sans avoir a installer un projet depuis un scv
  • # Google ?

    Posté par . Évalué à 4.

    Mon anglais n'est pas des meilleurs mais j'ai plutôt l'impression que c'est un langage créé par des employés de Google. Quelqu'un pour confirmer ?


    "Noop is a side-project from a collection of like-minded developers and contributers. We hail from several companies, including (but not limited to) Google."
    • [^] # Re: Google ?

      Posté par (page perso) . Évalué à 1.

      En même temps, il me semble que google donne du temps à ses employés pour travailler sur des projets perso qui pourrait bien devenir une richesse pour la société. Après, je ne sais pas la license et la répartition des droits sur ce travail.

      Donc de Goggle ou de ses employés, c'est du pareil au même. Si le projet personnel fait dans les heures donné par Google à ses employé est interessant et que cela rentre dans une stratégie de l'entreprise, et bien le développeur passe à temps complet sur le projet.

      Enfin, c'est ce que j'ai compris du modèle Google dans un reportage sur Arte.
  • # Ca me fait penser ...

    Posté par . Évalué à 4.

    ... à une citation récente [http://lambda-the-ultimate.org/node/3619] :
    "Mock objects and dependency injection are just for people who don't know math" - Erik Meijer
    • [^] # Re: Ca me fait penser ...

      Posté par (page perso) . Évalué à 2.

      Franchement, j'ai essayé de suivre son intervention, j'ai absolument rien compris ! Tu as pigé qq chose toi ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.