ckyl a écrit 3877 commentaires

Je n'aime pas les lambda. Même si c'est pratique, ça brise le principe DRY

Il ne faut pas se focaliser sur les lambdas. Java 8 amène en même temps les lambdas, une API stream et les méthodes reference. Ils marchent ensemble.

Si tu regardes le style Java moderne c'est déjà ce qu'on utilisait sauf que c'était dégueulasse syntaxiquement.

Maintenant regardons du côté du DRY. Reprenons mon exemple d'hier

  public Collection<String> lambda(Collection<String> c) {
    return c.stream()
            .map((s) -> "foo" + s)
            .collect(Collectors.toList());
  }

Tu vas dire "foo" + s c'est pas DRY. Ca mériterait d'être défini proprement quelque part pour être réutilisé. Ca tombe bien c'est pour ca que les method references ont été ajoutées en même temps

  static final String addPrefix(String str) {
    return "foo" + str;
  }

  public Collection<String> methodHandle(Collection<String> c) {
    return c.stream()
            .map(Main::addPrefix)
            .collect(Collectors.toList());
  }

Voilà c'est magique j'ai maintenant un bout de code nommé et isolé qui défini une opération précise. Avant il fallait instancier une fonction statique à la Guava. C'est plus clair et plus performance.

Maintenant tu vas me dire que c'est cool tant que ton opération à effectué ne dépend que de l'élément lui même. Ca ne marche pas si tu dois paramétrer l'opération avec quelque chose d'autre. Reprenons depuis le début.

  public Collection<String> lambdaWithCustomPrefix(Collection<String> c, String prefix) {
    return c.stream()
            .map(s -> prefix + s)
            .collect(Collectors.toList());
  }

Retour à la case départ j'ai une lambda que je ne pourrais pas réutiliser et qui n'est pas définie précisément. Dans ce cas la solution method reference ne marche pas car que je peux pas passer mon paramètre supplémentaire. Je peux bidouiller avec le stream API mais c'est pas une bonne idée en soit. Du coup on peut faire quelque chose qui ressemble à ce qu'on faisait avant avec une classe:

  static class PrefixAdder implements  Function<String, String> {
    private final String prefix;

    PrefixAdder(String prefix) { this.prefix = prefix; }

    @Override
    public String apply(String str) { return prefix + str; }
  }

  public Collection<String> classWithCustomPrefix(Collection<String> c, String prefix) {
    return c.stream()
            .map(new PrefixAdder(prefix))
            .collect(Collectors.toList());
  }

Ok ca marche c'est propre à l'appel mais la déclaration est un peu verbeuse. Et ce que je viens d'écrire ca ressemble fortement à une fonction currifiée non ? Java n'est pas fonctionnel pour un sous mais est ce que je pourrais définir une fonction avec un invocation partielle ? Essayons

  Function<String, Function<String, String>> partialPrefixAdder = prefix -> str -> prefix + str;

  public Collection<String> currifyWithCustomPrefix(Collection<String> c, String prefix) {
    return c.stream()
            .map(partialPrefixAdder.apply(prefix))
            .collect(Collectors.toList());
  }

Oui c'est donc possible. La syntaxe pique les yeux et je suis pas certain que je l'utiliserais en Java mais ca marche.

Donc oui les lambdas utilisée comme un gros bourrin c'est pas DRY. Maintenant si tu regardes la solution dans son ensemble et que tu branches ton cerveau c'est un très bon outil. lambda pour des trucs qui n'ont pas de sens en dehors de ce traitement précis. Unitée logique nommées pour les opérations réutilisables. L'ajout de Java 8 c'est l'API du stream et les interfaces fonctionnelles. À la limite on aurait presque pu se passer des lambdas.

Après Java reste Java, ca fait pas grand chose de plus que ce que j'ai décris et t'es loin de Scala par exemple.

Non l'équivalent de getMethod serait: monObjet.maMethod (note l'absence de parenthèse). Method c'est juste "une jambe de bois" par ce que les fonctions ne sont pas d'ordre supérieur.

Encore une fois oui ce genre de mécanisme est implémentable de manière efficace sur la JVM, c'est invokeDynamic + MethodHandle. Non ce n'est pas utilisable en Java. Tu ne pourras jamais écrire monObject.pzoeizjdfc si pzoeizjdfc n'existe pas dans la hierarchie de classe de ton objet.
Un autre exemple: explication de comment JRuby fonctionne par Charles Nutter.

J'arrête la. Il y a des liens dans mes différents posts si tu veux chercher à comprendre la différence.

Oui les default methods ont clairement été faite pour cela, permettre de faire évoluer les veilles API sans tout casser. L'ajout des lambda demandait d'introduire des méthodes dans des classes existantes. Leur solution n'est pas trop folle.

Maintenant en pratique on peut voir ca comme des traits stateless. Scala a des traits stateful de son côté. Il y a six mois, Guillaume Laforge disait y reflechir pour Groovy mais ne savait pas trop de quel côté il allait pencher. Je sais pas si ca a bougé.

Pour ceux qui sont intéressé sur par les lambda et les défaut méthodes voici quelques liens qui peuvent être intéressants:

State of the lambda
Translation of lambda expressions
Les autres workings document du projet Open JDK

Conf: Les bridges méthodes pour l'implémentation des default methods
Conf: Benchmark des lambdas

Le deux présentations sont dispo au téléchargement là.

Vu le champ de mine que c'était ils ont fait du bon boulot. Faire évoluer ce truc avec les contraintes qu'ils ont c'est l'enfer. Bon y'a encore du boulot pour 3 ou 4 releases comme ca :)

Au passage c'est pas le sujet, mais le talk d'Aleksey Shipilev sur JVM Benchmarking. Il vulgarise très bien son travail sur JMH et la méthodologie.

GORM fait exactement pareil. Django pas exactement par ce qu'il fait ca avec le nom des paramètres et non des méthodes.

import java.util.Arrays;

public class Main {

    public static void main(String[] args) {

        System.out.println(
                Arrays.asList(args).stream()
                        .map((input) -> "foo" + input)
                        .toArray()
        );
    }
}

La signature de map est:

<R> Stream<R> map(Function<? super T, ? extends R> mapper);

Function est une SAM puisque seul R apply(T t); n'est pas implémentée.

Si tu regardes du côté de l'implémentation de tout ca, c'est actuellement fait comme ca:

/javap -c -p Main.class
Compiled from "Main.java"
public class Main {
  public Main();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: aload_0
       4: invokestatic  #3                  // Method java/util/Arrays.asList:([Ljava/lang/Object;)Ljava/util/List;
       7: invokeinterface #4,  1            // InterfaceMethod java/util/List.stream:()Ljava/util/stream/Stream;
      12: invokedynamic #5,  0              // InvokeDynamic #0:apply:()Ljava/util/function/Function;
      17: invokeinterface #6,  2            // InterfaceMethod java/util/stream/Stream.map:(Ljava/util/function/Function;)Ljava/util/stream/Stream;
      22: invokeinterface #7,  1            // InterfaceMethod java/util/stream/Stream.toArray:()[Ljava/lang/Object;
      27: invokevirtual #8                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
      30: return

  private static java.lang.String lambda$0(java.lang.String);
    Code:
       0: new           #9                  // class java/lang/StringBuilder
       3: dup
       4: invokespecial #10                 // Method java/lang/StringBuilder."<init>":()V
       7: ldc           #11                 // String foo
       9: invokevirtual #12                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      12: aload_0
      13: invokevirtual #12                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      16: invokevirtual #13                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      19: areturn
}

La raison a très bien été expliquée dans un talk du JVM language submit. C'est assez similaire a ce qui aux bridges methods qui ont été fait pour les generics dans Java 5.

Maintenant en pratique ca fait des années quoi se balade des lambda illisible de avec 7 lignes de boilerplate et un gros coup d'exec. C'était tellement ridicule que les IDE détectaient les patterns
lambda et les affichaient avec la syntax 8 pour que ca soit lisible…

J'ai comme l'impression que c'est, pour des raisons pragmatiques, la fin de la pureté de Java comme langage orienté objet.

Je pense que tu n'as aucune idee de comment sont implementées les lambdas dans Java 8.

Les méthodes ne sont toujours pas des objets de premier ordre et les fonctions ne sont pas anonymes. Ce sont juste de interface fonctionelle (SAM). C'est juste du sucre syntaxique quoi avec un gros boulot dans la JVM pour que ca rame pas trop.

Des interfaces où on peut mettre du code : c'est quoi cette horreur, et ça sert à quoi ? Évidemment que ça introduit un problème d'héritage en losange…

Ca existe dans beaucoup d'autres langages ca se nomme un trait. En Java 8 tu as des traits stateless qui limites très fortement leur interet. Ca permet juste de pas péter des API quand tu as besoin de les faire évoluer.

Les trait sont en général utiles pour introduire de la composition et faciliter la réutilisation. Ca peut introduire quelque probleme mais en general ca en resoud plus que ca en introduit.

Faire des pseudos interfaces à des choses non connues à la compilation voir à l'exécution (il faut essayer pour savoir).

Ca peut s'utiliser pour créer des DSL, des fonctionalité d'ORM, de metaprogramming, du sucre syntaxique (BeautifulSoup l'utilise par exemple pour permettre un accès via des pseudo membre aux élements de la data structure) etc.

Ta vision est bornée a un faire un proxy sur un type d'un langage statique. Et encore plus borné que Java n'étant pas fonctionnel pour un sou et n'ayant pas de fonction du premier ordre tu es obligé d'utiliser des Proxy et de l'AOP crado. Chaque plate forme à son idiome et tu ne concois et n'écris pas les choses de la même façon selon l'outil que tu as en main. Pour revenir au commentaire original "_PHP possède une dynamicité que Java n'a pas (comme la possibilité d'avoir une méthode « par défaut » quand on appel une méthode sur un objet avec le mauvais nom - moche sur bien des aspects, pratique pour faire des proxy)._" c'est vrai. En soit ce n'est pas une critique de Java c'est une constatation. Tu peux faire bien plus de chose avec des langages dynamique (dont un bon nombre de choses horribles).

Tu ne peux toujours pas écrire ton code client c'est sacrement utile ;)

Juste au passage ce que tu décris, je l'ai fait pendant 5 ans pour génerer des proxy type RMI à runtime pour un système RPC (et oui c'est une mauvaise idée).

Ce que tu décris c'est générer des Proxy pour une interface Java (que ce soit via Proxy ou en générant du bytocde à runtime c'est juste la modalité qui change) et éventuellement générer du code avant pour créer ton interface. Tout cela existe et est pratique.

Mais pourquoi tu ne veux juste pas voir que ce dont on parle ne peut pas exister en Java car c'est antinomique avec un langage statiquement typé. Personne ne dit que tu as absolument besoin de cette fonctionalité ou qu'il faut en abusé. Mais c'est un fait __getattr__, __call ou methodMissing tu ne peux pas avoir de concept similair en Java.

J'ai vraiment l'impression que tu ne comprends pas la différence. Tu focalises sur une utilisation possible du mécanisme qui a été donnée en exemple mais on peut beaucoup d'autre chose avec. Prend le temps de lire les docs et d'essayer de t'en servir. Tu devrais finir par comprendre.

Qu'est ce que tu ne comprends pas dans typage dynamique et dans la phrase originale qui était " (comme la possibilité d'avoir une méthode « par défaut » quand on appel une méthode sur un objet avec le mauvais nom - moche sur bien des aspects, pratique pour faire des proxy)." ?

Je comprends parfaitement ce que tu m'expliques. Par contre tu ne comprends juste pas qu'à chaque fois ce que tu prends comme exemple ne fait qu'implementer automatiquement un proxy à partir d'une interface Java définie (il existe des dizaines de variantes possible). Derrière il te faut une Method ou un MethodHandle.

Si ca peut t'aider à comprendre regarde du côté de la doc de Groovy:
http://groovy.codehaus.org/Using+invokeMethod+and+getProperty
http://groovy.codehaus.org/Using+methodMissing+and+propertyMissing

Si tu veux comprendre comment ca s'implemente sur une JVM regarde ca: http://www.oracle.com/technetwork/articles/javase/dyntypelang-142348.html

Maintenant non cette fonctionalité ne peut pas exister en Java.

Non, toujours non et ce sera toujours non.

En Java tu as un typage static. Tu peux creer des proxy autour d'interfaces CONNUES.

Dans un langage dynamique tu peux evidement creer ce type de proxy. Basiquement en Python:

class wrapper:
    def __init__(self, object):
        self.wrapped = object
    def __getattr__(self, attrname):
        print('Trace:', attrname)
        return getattr(self.wrapped, attrname)

Mais tu peux aussi faire un proxy sur quelque chose qui n'est pas decrit dans ton langage. Par exemple quand tu ecris un client rest generique tu n'as aucune idee de ce qui existe vraiment dans l'API et ce n'est jamais decrit. Tu as juste un mapping dynamique 'GET /foo/bar?p=v' en client.get.foo.bar(p=v).

Ce type de construction tu ne pourras jamais le faire en Java.

Non. C'est possible, oui, en 2 coups de cuillère à pot, non.

Non c'est pas possible, quelque soit le nombre de cuillère à pot.

Tu peux effectivement essayer d'implémenter call, __gettattr ou missingMethod en Java. C'est par exemple ce que fait PyObject dans Jython qui wrap tout les objets Java qui sont visibles côté Python. Bon AFAIK l'implémentation des méthodes fournies par PyObject tu ne peux pas la modifier et surement pour une très bonne raison.

Mais tu ne pourras jamais appeler ce mécanisme depuis Java, typage static oblige. D'ailleurs c'est pour ça que si tu veux manipuler un objet Python depuis Java il faut qu'une interface Java soit définie.

Après tu peux penser faire du Canada-dry avec une méthode unique doit et un varargs d'Object en paramètre. Mais la c'est juste du mauvais goût et le pire des deux mondes. Dan la vraie vie tu vas utiliser un patron du type multi-dispatch.

Bah en deux coups de cuillère à peau avec un peu de réflexivité on fait la même chose moche

Non.

Ce que te permet facilement de faire Java c'est un proxy pour une interface déjà existante. L'exemple classique, et qui est généralement une très mauvaise idéee, c'est un système de RPC qui veux faire croire à une API locale. Tu vas automatiquement générer des proxy sur des interfaces et masquer tout le bordel à l'utilisateur. Pour lui il manipule un POJO.

Ce que permettent de faire les langages dynamiques c'est de faire un proxy pour n'importe quoi dont la signature est totalement inconnue même à l'exécution (getattr en Python, methodMissing en Groovy etc.). Le proxy fait simplement des transformations syntaxiques bêtes et méchantes à partir du nom de méthode et des arguments passés puis effectue une action, il ne connait rien de l'API sous jacente et n'expose rien. L'exemple typique c'est client pour une API web. À partir du moment ou elle est régulière, ça marche. Ça a des avantages et des inconvénients par rapport à fournir une "vraie" API côté client. Mais dans tout les cas c'est pas faisable en Java.

people may use your money to make a lot more money without ever properly starting a successful company in the first place.

C'était pas le but à la base ?

Tu files du blé a quelqu'un qui a un projet mais pas de quoi le financer ou préfère le financement collaboratif à un autre. Trois solutions:

• C'est de la merde ou le mec est pas capable de livrer: tu perds ton blé ou tu es remboursé
• C'est une idée comme une autre, le mec livre mais n'ira pas plus loing: tu recois quelque chose de fixe pour ce que tu as payé. Bref tu as acheté un service ou un bien. Si c'était le seul but ca ne s'appelerait pas kickstarter mais freelancer.
• C'est une très bonne idée et le mec à la gniak. Il va poursuivre et il va faire du pognon. Tu as financé son démarage contre une contrepartie fixée dans un contrat c'était le deal.

Tu peux ne pas du tout adhérer au concept. Mais être surpris faut pas plaisanter. C'est le but du truc.

Franchement pour certains type de projet je ferais exactement la même. En gros tu te finances en freelance en ayant beaucoup de clients pour atteindre ta vitesse de croisière. J'ai pas a lever de fond ou emprunter et si ca marche je ne dois rien à personne. 100% gagnant.

Plus maintenant, le produit va certes en profiter aussi (selon les contraintes ca peut ne pas etre forcement des ameliorations…) mais des primes personnelles ayant etés signées en fonctions de differents objectifs, les createurs s'en mettent plein les fouilles…

En fait on devrait tuer les gens une fois que le projet kickstarter arrive à terme !

Sérieusement le nom même du truc c'est "KICKSTARTER". Bref tu investis pour permettre à d'autres d'en profiter plus tard. La différence avec un investissement classique, c'est que tu monaies ton investissement contre un bien à court terme alors que normalement tu ne sais pas du tout ce que tu vas en retirer qui dépendra de l'évolution du projet à long terme. Bref tu es plus dans une logique d'achat qui sert de levier pour les porteur de projet pour se développer. Forcément si tu penses que tu as acheté un truc et qu'après les porteurs devraient passer à autre chose et ne rien en retirer ou qu'il te devrait un pourcentage des benefs, il y a une incompréhension quelque part.

Si effectivement c'est ce que tu souhaites, tu peux très bien investir de l'argent dans des projets, startups ou PME. Tu n'auras rien immédiatement en échange, tu vas la plupart du temps perdre ton argent mais si tu tombes sur le bon poulain ca peut payer.

j'ai juste besoin de lire la valeur t correspondant à x,y - on est en client serveur, peu de connexions, même le truc le plus pourri, avec des objets java sur une base oracle passerait. Mon questionnement, sur un truc aussi simple est " variable php (dc 250Ko en ram) ou bdd et 1 seule ligne (5 ko) à lire. c'est juste de la curiosité.

Je comprends parfaitement que tu cherches à le faire pour le fun.

Maintenant si tu veux une seule valeur alors essaies de faire des implémentation comparables. Si tu es basé sur un fichier ou un mmap, tu peux seeker directement à la bonne position par exemple. Ou être row based. A l'inverse en BDD tu peux retourner le blob entier ou faire un record par case. Mais si tu commences à mixer les implémentation sans raison ca limite encore l'intêret de la démarche.

Après les methodologies de mesure pour des choses <ms sont assez "compliqué" et demande de la rigeur. Enfin définir son critère de mesure est impératif: Que mesure ton, dans quel context, dans quel but. Sans ca l'intêret est extrêment limité d'autant plus quand tu peux savoir d'avance que l'ordre de grandeur est le même.

ouais, sauf qu'en mode déconnecté, il est tout sauf certain que le fichier texte reste dans l'espace d'adressage

Ce n'est pas le but.

et qu'il faille le relire à chaque fois.

Lire un fichier de 250K depuis le cache VFS ne coute "rien" que ce soit via l'API standard ou mmap.

Si tu en est là, tu fais fausse route avec PHP et ton modèle d'exécution. Mais tu n'as pas de problème à résoudre.

Lorsque 2 personnes visitent une page à 2 secondes d'intervalles, le fichier reste en cache ou il ne l'est plus ?

Théoriquement tu ne peux pas savoir. Mais sauf a avoir un demon qui stock tes valeurs en memoire tu ne peux pas faire mieux. Et clairement ce n'est pas ce que tu veux et ca n'en vaudra jamais le coup.

En pratique la reponse sera oui. Si tu n'utilises jamais ton appli alors tu as des chances qu'une éviction ait eu lieu et de faire un miss. Mais tu t'en balance car ca veut dire que tu as une requete / jour. Que ca prenne 5ms on s'en fou. De toute facon ton script PHP à aussi été dégager dans ce cas…

Note que tu as le même problème avec une DB, et que tu n'as toujours pas de problème à résoudre.

Et comme la base de donnée est aussi un fichier, il faut des 2 cotés lire un fichier, en mode texte on lit les 500 lignes, en mode base on lit une seule ligne. C'est quoi le plus rapide ?

Ca depend de ton utilisation.

C'est justement pour ca que ton test est pourri.

D'une part tu ne définis rien. Vas tu requeter une seule fois ou souvent ? As tu besoins de seulement quelques valeurs ? Etc.

D'autre part tes deux implementation n'ont rien de comparables. Ta version fichier elle est pratique si tu veux faire plein de requêtes sur une case en particulier. Ta version DB elle ne le permet pas. Tu compares des choux et des carottes. Quel est le but de la mesure au final ?

et c'est quoi la "bonne structure de représentation des données" ?

Ca demande de savoir comment tu vas utiliser et quel est le problème. Et vu que ton bench ne veut rien dire, qu'il n'y a pas de contexte et que les deux implementations divergent…

Effectivement si tu veux mimiser la conso mémoire et gagner 250K par instance, tu mmap directement ta matrice définie dans un fichier. Au passsage ca enlève la limite à 80 caractère et tu ne peux pas avoir un accès moins couteux à une cellule. Par sur que tu puisses mmap en PHP par contre.

Je ne charge pas la map. Il n'y a pas de map, juste une grille de 25 000 cases dans laquelle on se balade et qui ne sert juste qu'à délimiter le monde et poser des villes. Pour le moment il n'y a pas d'images, mais je ne vais pas redire ce que j'ai déjà écrit, suffit juste de lire. J'ai l'impression de voir mes étudiants qui répondent au titre de la question sans avoir lu la question.

Je sais lire et c'est ce qu'on appele une map puisque ca defini ton terrain.

Basiquement une map c'est un fonction (x, y) => t qui te retourne le type de la case. Tu peux l'implémenter comme tu veux. Tu as choisi de la représenter par une matrice textuelle.

Ta grille fait 250K cases, avec une représentation bête et méchante: un octet par case => 250K. Tu peux facilement faire ton estimation au dos d'une envelope à partir de ca. Tu compares ca au reste des coûts de ton chemin d'exécution complet en prod et par rapport à la "résolution" du client. Et tu arrives facilement à estimer si ca vaut le coup de faire autre chose que l'implémentation élégante.

J'ai l'impression de voir mes étudiants qui répondent au titre de la question sans avoir lu la question.

Merci.

Le but n'est pas de gagner ou de perdre, mais de tester, pour le fun

Ce qui est fun c'est de faire des choses qui ont un sens même si ca n'a absolument aucune utilité pratique. Autrement c'est juste faire n'importe quoi.

La ton "benchmark" ne t'apprend rien de nouveau par rapport à un calcul au dos de l'envelope et ne mesure rien de significatif. La conclusion tu pouvais la connaitre avant de la faire:

• Tu ne peux pas mesurer de cette facon des opérations estimées sous la ms
• Le cout de lire 250K en cache VFS ou sur une DB locale n'est pas significatif par rapport au coup d'exécution de ton script
• L'implémentation DB est stupide et ne se compare pas à la version fichier. Dans un cas tu caches ton dans ton espace d'adressage dans l'autre tu vas bourriner la DB à chaque requette. Soit l'implémentation est mauvaise, soit ton test n'a aucun sens
• Tu ne peux absolument rien extrapoler de ces mesures. Une regle générale du benchmark est que ca suppose que connaitre ce que tu veux mesurer ainsi que le modèle de performance de ce qu'on mesure AVANT. J'ai appris quoi avec cette mesure ? Comment je peux l'extrapoler pour une grille NxN ou quand j'ai 1000 req/s ? Comment ca se traduit dans mon application ?
• Si tu veux être rapide pour le fun commence avec une bonne structure et représentation des données.

mais pour le "procédural", j'ai toujours entendu dire que c'était plus rapide et moins gourmand que du objet, mais moins confortable pour le développeur. C'est vrai ou pas? SI ce programme était écrit en objet, ça irait plus vite? moins vite?

On s'en balance un peu. Bencher comme ca sans raison le DL d'une matrice 500x500 ça ne sert absolument à rien. Si tu fais ton petit truc dans ton coin pour 5 utilisateurs ca sera de toute façon suffisamment rapide pour ne pas avoir a t'en soucier (c'est bien d'avoir une idée des ordres de grandeur). Si tu fais un truc qui va prendre de la charge dans la face ou que ton besoin c'est pas 500x500 mais NxN alors tu prends en compte ces paramètres dans ta conception et dans tes tests:

• Si tu charges toujours toute la map, pourquoi la stocker par ligne dans la BDD ?
• Si tu n'es intéressé que par une sous partie de la map alors tu vas faire en sorte de pouvoir chopper que cette partie de la matrice
• Si tu as 3 utilisateurs par semaine alors de toute façon tu vas passer tout ton temps en I/O vu que tu taperas pas dans ton cache VFS
• Si tu as plein d'utilisateurs alors le bench mono utilisateur n'a aucun sens
• Etc.

Mais surtout si ton besoin c'est vraiment de stocker du 500x500 pour tes gamins pourquoi tu benchs ? T'as 250Ko à lire ! ~5 ms à froid pour le seek quoi que tu fasses et quelques dizaines/centaines de µs à chaud. Y'a rien à gagner ou à perdre avant d'avoir très très sérieusement scalé.

Bref en règle générale:

• Tu designs quelque chose de simple et élégant jusqu'à ça soit prouvé que c'est un problème
• Les trucs simple et élégant qui fonctionnent bien se reposent souvent sur les concepts de l'OS. Tirer bêtement partie du cache VFS et d'un format de fichier adéquat te permettra déjà d'aller très loin.

Alors le dos ou les yeux il faut choisir …

Ou alors t'arrêtes de rester assis à fixer ton écran sans bouger en mode autiste pendant des heures.

La bonne nouvelle c'est qu'en général ça correspond aussi aux bonnes pratiques pour améliorer la qualité et sa productivité: tâches courtes, pair programming, design/spécification collaboratif ou simplement s'arrêter pour prendre du recul et se reconcentrer. Même en mode autiste, se forcer à bouger ses fesses toutes les 1h30, 2h est finalement très bon pour soi, le produit et sa capacité à estimer les tâches. On se rend vachement plus compte du temps qui passe qu'en passant 10h de suite derrière son écran.

Ben oui, les standards ouverts c'est le mal absolu ;-)

Ce n'était pas le sens du message. Le SOA est une approche architecturale. Tu utilises le moyen de communication adapté à ton service, après analyse.

Pour beaucoup de besoins tu vas trouver un truc sur étagère standardisé ou pseudo-standardisé qui convient. Mais de fois tu vas tomber sur des problèmes qui demandent des approches adhoc (bonjour les TX à gros volumes ou la finance de marché).

Un bon engineering c'est réutiliser les trucs standards autant que possible mais ne pas avoir peur de construire ce dont on à besoin quand c'est justifié.

Qu'est ce qui remplace SOAP pour du SOA aujourd'hui ?

Heu tu implémentes bien ton bus comme tu veux avec ce que tu veux. Même avec une techno proprio bien maison si ça correspond aux besoins de ton business.

En terme de coût CPU, je trouve que c'est assez coûteux.

JSON et XML c'est kif kif en terme de perf et de poids. Le XML lourd et lent est un mythe que les incompétents aiment se raconter le vendredi au coin du feu.

http://balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html

C'est orienté web mais tu retrouves la même chose sur des implementations backend. Tu peux aller un peu plus vite si tu te fais un parser custom qui ne respecte pas les API standards qui limite en général la perf possible.

Après c'est a quelques ordres de grandeur de ce qui est faisable avec un bon protocole binaire, mais c'est vraiment pas le même usage…

je me souviens d'une seat ibiza qui était capable de retenir la voiture à l'arrêt en côte pendant quelques secondes quand on lâchait la pédale de frein sans faire appel au frein à main électrique

C'est juste une énorme fausse bonne idée. Tu ne peux juste plus reculer en débrayant et en gérant au frein quand t'es en pente… Enfin si tu peux en attendant 5 secondes avec un frein qui lâche d'un coup ou en te forcant à passer la marche arrière à chaque fois.

En gros ca sert pas à grand chose pour les gens qui vivent sur le plat et ca pourri la vie de ceux qui passent leur temps à faire des crénaux en pente. Franchement l'aide au démarage en côte je ne sens pas la différence en marche avant par contre quand tu as besoin de reculer… (j'ai les deux)

À partir du moment, où il y a une assistance au démarrage en côte

C'est juste le truc encore plus insupportable que le frein à main électrique ;)