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/
Journal Noop : encore un nouveau langage ou bien nouvelle génération de langage
25
sept.
2009
# Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . Évalué à 2.
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 Brioche4012 (site web personnel) . Évalué à 3.
[^] # Re: Rien de transcendant dirait-on
Posté par Xavier MOGHRABI (site web personnel) . Évalué à 5.
Une fois par le développeur avec la commande javac et une 2e fois à la volée par la compilation JIT (Just In Time) par la JVM.
[^] # Re: Rien de transcendant dirait-on
Posté par BAud (site web personnel) . Évalué à 10.
- quand tu y arrives
- quand tu en repars
?
[^] # Re: Rien de transcendant dirait-on
Posté par cosmocat . Évalué à 5.
T'es en train de sous-tendre que ceux qui font du java sont deux fois plus des hommes?
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . Évalué à 1.
- 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 yellowiscool . Évalué à 9.
Daube et SQL ?
Nous n'avons pas les mêmes valeurs.
Envoyé depuis mon lapin.
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . Évalué à 1.
[^] # Re: Rien de transcendant dirait-on
Posté par yellowiscool . Évalué à -3.
Envoyé depuis mon lapin.
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . Évalué à 0.
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 allcolor (site web personnel) . Évalué à 6.
Pas envi de répéter ce que j'ai déjà dit plusieurs foisTu *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 yellowiscool . Évalué à 0.
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 thedude . Évalué à 0.
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 yellowiscool . Évalué à 4.
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 thedude . Évalué à -8.
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 yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Rien de transcendant dirait-on
Posté par kahal (site web personnel) . Évalué à 3.
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 yellowiscool . Évalué à 2.
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 allcolor (site web personnel) . Évalué à 2.
Mais d'un coup tu perds presque tout les avantages d'hibernatePour ç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 kahal (site web personnel) . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 1.
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 kahal (site web personnel) . Évalué à 1.
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 Ontologia (site web personnel) . Évalué à 2.
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 kahal (site web personnel) . Évalué à 4.
On ne peut condamner un outil car une partie de ces utilisateurs sont des cancres.
[^] # Re: Rien de transcendant dirait-on
Posté par grid . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 fearan . Évalué à 2.
"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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 fearan . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 fearan . Évalué à 2.
Ç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 kahal (site web personnel) . É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 ;)
>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 fearan . É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 kahal (site web personnel) . Évalué à 4.
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 zul (site web personnel) . Évalué à 4.
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 Sufflope (site web personnel) . Évalué à 3.
[^] # Re: Rien de transcendant dirait-on
Posté par kahal (site web personnel) . Évalué à 1.
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 fearan . É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 zul (site web personnel) . Évalué à 3.
[^] # Re: Rien de transcendant dirait-on
Posté par lasher . Évalué à 3.
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . Évalué à 0.
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 fearan . Évalué à 5.
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 ckyl . É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 Ontologia (site web personnel) . Évalué à 3.
« 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 ckyl . Évalué à 5.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 thedude . Évalué à 1.
[^] # Re: Rien de transcendant dirait-on
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Rien de transcendant dirait-on
Posté par fearan . Évalué à 4.
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 thedude . Évalué à 1.
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 Ontologia (site web personnel) . Évalué à 4.
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 zul (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 4.
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 thedude . Évalué à 1.
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 Guillaume Knispel . Évalué à 4.
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 thedude . Évalué à 1.
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 Ontologia (site web personnel) . Évalué à 4.
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 Guillaume Knispel . Évalué à 1.
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 thedude . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 4.
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 Sufflope (site web personnel) . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
« 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 Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Rien de transcendant dirait-on
Posté par Victor . Évalué à 2.
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 Guillaume Knispel . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
« 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 Moonz . Évalué à 2.
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 Moonz . Évalué à 2.
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . Évalué à 2.
« 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 Ummon . Évalué à 4.
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 hsyl20 (site web personnel) . Évalué à 2.
[^] # Re: Rien de transcendant dirait-on
Posté par lasher . Évalué à 2.
[^] # Re: Rien de transcendant dirait-on
Posté par lasher . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Rien de transcendant dirait-on
Posté par lasher . Évalué à 2.
- 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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Rien de transcendant dirait-on
Posté par lasher . Évalué à 2.
# Noop
Posté par blobmaster . Évalué à 7.
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
[^] # Re: Noop
Posté par jiyuu . Évalué à 4.
Dont 'hello world' ici: http://code.google.com/p/noop/source/browse/examples/noop/he(...)
PS: Je ne savais pas que code.google.com proposait mercurial. Ça serait bien qu'il propose git aussi. Bon ça, c'est fait. --> []
[^] # Re: Noop
Posté par ribwund . Évalué à 1.
Le protocol natif de git c'est plutôt l'enfer à integrer dans leur infra (où tout est http based).
# Google ?
Posté par jiyuu . Évalué à 4.
"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 Samaty Tramo . Évalué à 1.
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 benoar . Évalué à 4.
"Mock objects and dependency injection are just for people who don't know math" - Erik Meijer
[^] # Re: Ca me fait penser ...
Posté par Ontologia (site web personnel) . Évalué à 2.
« 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.