ckyl a écrit 3877 commentaires

Pas trop quand même. Sinon ça ne sert plus à rien de chercher à ce comprendre.

Pour te montrer comme être pointilleux quand il n'y a pas d'ambiguïté ne mène nul part.

parce qu'il n'existe pas de logiciel assembleur qui va traduire le bytecode de la JVM en langage machine.

N'importe quelle JVM fait ca c'est son job (Astuce pour Hotspot par exemple). Autrement pour sortir des JVM standards, GCJ est capable de compiler directement vers du natif. Il y a eu un paquets d'autres projets qui ont fait ca.

J'aurais du ne parler uniquement de langage machine car il existe des machine qui décodent directement le bytecode JVM.

Tu arrêtes pas de le ressortir mais on peut faire ca pour n'importe quel bytecode, voir langage si vraiment on s'ennuie. On le fait pas par ce que ca n'a aucun sens. Toutes les tentatives de CPU mangeant du JVML ont été des échecs cuisants.

Je cherche pas à troller je demande réellement qu'elle est la différence dans la démarche d'un coté (bytecode JVM) et de l'autre (jeu d'instructions x86).

Y'en a un qui est du soft et l'autre du hard ca n'a rien de comparable.

Pourquoi cibler la JVM ?
- S'intégrer avec l'existant (compétence, compatibilité, bootstraper avec un eco-systeme déjà prêt)
- Profiter des efforts absolument monstrueux qui ont été fait dessus depuis 15 ans

C'est exactement les mêmes raison qui font actuellement fleurir les langages ciblant JS. Et c'est bien là le changement. L'informatique est arrivée à un point où c'est extrêmement difficile d'être disruptif et de pousser de l'innovation. Et c'est pour ca que c'est "la mode". Sauf cas particulier on a plus vraiment le choix, même pour les mastodontes qui quand ils tentent n'arrivent plus à pousser leurs technos. Ça ne marche que si tu es environnement clos.

Moi mon dada principal c'est l'étude des langages de programmation. Je viens voir les discussions sur les langages de programmation (Coffeescript, Go, TypeScript, Ceylon, whatever) quand elles ont lieu sur LinuxFR, et je suis systématiquement déçu.

Perso quelque soit le sujet je trouve le ratio signal/bruit de plus en plus mauvais. Très peu de discussions techniques, factuelles, objectives ou de bonnes blagues pour beaucoup de cours de recrée et de je critique tout. Je crois que ceux qui codaient vraiment sont majoritairement plus ou moins partis…

Ton assertion supposant qu'une entreprise était un tout dirigé par une tête pensante me paraissait déconnectée de la réalité. Tu le confirmes ;)

Note qu'en faisant le même test ce matin depuis la même ligne (regarder quel serveur est utilisé pour servir une vidéo populaire et une autre vidéo non populaire) je me fais router vers les data centers de google plutôt que vers un cache Google chez Limelight. On ne passe donc pas non plus par le même point d'interco. Je me suis jamais intéressé à Youtube, ca demande de faire quelques petits tests pour voir leur politique. En général Google fait des choses assez intéressantes pour amener le trafic la où ils veulent. Et théoriquement ils ne sont plus client de Limelight depuis longtemps.

Dans tout les cas, même si ce n'est pas servi par un cache en bout de réseau mais dans un de leurs datacenters, la densité est suffisamment bonne en Europe et US pour avoir une très bonne proximité.

Il a l'air sympa ton petit frère faudra qu'il vienne manger à la maison…

T'as déjà mis les pieds dans une grosse boite ?

Hey choupinet le comportement par défaut n'a pas changé et personne ne te demande d'avoir un comportement qui dévie de ce que disent les RFC. Après de toute façon si tu veux cradouter tu cradoutes…

Et ce problème de congestion illustre quand même le fait que c'est "légèrement" crétin d'aller poster sa vidéo sur les serveurs de Youtube (donc, "loin" sur Internet), surtout si le but c'est de la montrer à des gens qui sont dans le même pays.

Et ton commentaire montre qu'il est crétin de parler de chose dont on ne connaît visiblement rien ;)

Même si tu n'as absolument aucun début d'idée de comment peut fonctionner une plate-forme comme youtube ou des pratiques usuelles de Google, un simple ping te dira que tu dis des bétises plus grosses que toi:

    --- 208.117.245.36 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 44.128/44.626/45.180/0.512 ms

Malgré le fait que les ingés de Google soient très fort ils n'ont pas encore trouvé comment faire aller les lutins du réseau plus vite que la vitesse de la lumière. 40ms de latence c'est grosso modo ce qu'il me faut pour atterrir au grand max en: France, UK, Irlande, Italie.

Maintenant pourquoi blâmer Free ? Grace a la deuxième commande la plus simple du monde: traceroute

 8  lyon-crs16-1-be1008.intf.routers.proxad.net (212.27.59.153)  38.245 ms  38.491 ms  38.718 ms
 9  th2-crs16-1-be2001.intf.routers.proxad.net (212.27.59.29)  42.433 ms  44.021 ms  44.512 ms
10  limelight-pni.proxad.net (212.27.40.154)  46.094 ms  46.475 ms  47.690 ms
11  ve6.fr4.par.llnw.net (69.28.172.118)  48.337 ms  54.119 ms tge4-4.fr3.lon.llnw.net (69.28.171.50)  58.889 ms
12  google.tge5-1.fr3.lon.llnw.net (87.248.208.170)  44.504 ms !X google.tge5-3.fr3.lon.llnw.net (178.79.195.2)  55.338 ms !X google.tge8-1.fr4.lon.llnw.net (178.79.195.6)  47.405 ms !X

Note que le traceroute te confirme que les serveurs sont pas loin… Y'a 6ms entre lyon et les serveurs.

Donc non poster ses videos sur Youtube ce n'est clairement pas les poster loin. Dans bien des cas ca sera même beaucoup plus près qu'un service franchouillard pour franchouillards.

Si on critique quelque chose de vague (comme l'ensemble des compilateurs),

Tu vois tu veux lire le truc au premier degré. Tu veux utiliser la définition stricte de compilateur, que tout étudiant qui à mis les pieds en première année connait au passage, pour occulter le message intéressant de sa phrase.

JS pose un paquet de problèmes, mais comme on personne n'espère pouvoir le virer et que les VM JS ont fait des progrès phénoménaux ces dernières années on a en ce moment énormément de propositions de langage qui ciblent le JS comme langage cible. On cible par dépit et non par choix ce qui influence grandement le design des solutions (interaction entre les langages, possibilité de debugging etc.).

Et lire comme ca c'est vachement plus intéressant que de tuer toute discussion utile en sortant "Un compilateur de toute façon ca compile d'un langage A vers un langage B rien de nouveau". Certes mais après ?

J'apportais une précision rien de plus. Le bytecode java est une forme d'assembleur

Encore une fois c'est enfoncer une porte ouverte, tout le monde le sait ca. Par contre réfléchir à pourquoi tant de projets visant la JVM comme cible ont éclos ces 5 dernières années alors que la plateforme n'a pas été conçue pour cela et qu'auparavant on préférait (ou avait la possibilité de) se réécrire toute sa stack ca c'est intéressant.

Et c'est encore plus intéressant de voir qu'il y a autant d'arguments techniques qu'une évolution profonde du marché de l'informatique. Ce qui était possible il y a dix ans ne l'est souvent plus.

Je n'ai pas dis le contraire. J'ai juste dis que sous-entendre que le fait d'écrire des compilateurs n'avait rien d'un effet de mode.

D'autres portes ouvertes à enfoncer en se forcant à lire les choses au premier degré ? ;)

C'est un peu différent. Rare sont les compilateurs qui génèrent du Java. Il est plus simple est agréable de générer du bytecode pour la JVM que de faire une double compilation (nouveau langage -> Java -> Bytecode).

Exactement la même chose: Tu es obligé de cibler la plateforme cible s'est imposée. Là encore tu lis ce que tu veux lire.

Oui enfin il y a eu un changement assez fondamental ces dernières années. Les contraintes d'interopérabilité, de gestion de l'existant, de disponibilité de la compétence sur le marché du travail, de contraintes d'ecosystème, des efforts pour industrialiser et optimiser une plateforme etc. font qu'il devient très difficile de pousser une nouvelle technologie.

C'est le cas ici avec le langage de programmation côté client pour les webapps. Vouloir remplacer Javascript est un doux rêve. Il y a 10 ou 15 ans on aurait totalement pu imaginer qu'un acteur arrive avec son langage en tant que plugin et prenne le marché. Actuellement pas grand monde n'imagine pouvoir réussir ce tour de force. Donc on travail à fournir des outils qui vont compléter ou améliorer le socle de base que l'on considère comme acquis.

Tu constates le même schema avec Java. C'est là, la VM est là personne ne veut lutter de manière frontale alors on vise l'existant comme plateforme cible.

Bref avant on faisait soit du fait d'un choix technique ou de la facilité (juste un frontend à coder), maintenant c'est bien plus une obligation.

Et ca se produit dans beaucoup de domaines (combien de système d'exploitation de recherche ces dernières années ?).

Ça pourrait ne pas être open source tout en visant tout les navigateurs. Ca compile vers du Javascript. Rien ne t'empêche de vendre le produit.

Après si tu veux pousser ton langage, dans ce domaine et actuellement c'est juste suicidaire de ne pas le rendre le Open Source. Trop de compétition et trop dirigé les webdevs pour réussir actuellement réussir ce tour de force sans leur aide.

Aucun argument d'autorité simplement commencer par se dire que les autres ne sont pas forcément plus cons que soi. Donc chercher à comprendre, et leur demander si on arrive pas à trouver la réponse. Après on peut exprimer son désaccord sur ce point, voir émettre des doutes sur les compétences de la personne en cas extrème. C'est vachement plus constructif et respectueux que d'arriver avec ses gros sabots.

Maintenant oui pour moi ça s'applique encore plus que le CV du mec est l'un des plus rempli de son domaine et qu'il ne sort pas de n'importe où. Ce qui n'empêche pas de faire des conneries hein.

C'est juste l'un des top contributeur de la pile réseau de Linux et des outils associés depuis près de 10 ans, je suis sur qu'il serait intéressé si tu donnais des cours.

Avec un peu d'expérience dans le développement et en étant un peu moins imbus de soit même on peut imaginer de manière non exhaustive que:
- Il y a une raison architectural au changement (comme indiqué plus haut ça peut nettoyer en évitant des exceptions)
- Il y a des gens qui en ont le besoin et qui ont réussi à le convaincre (ou le payer). Ça n’entraîne aucune régression pour les autres donc pas de soucis.
- Il y a une bonne raison, sans qu'un client ait eu besoin de le demander
- Il a tord

Mais même si il avait tord sur ce coup, vouloir persister à dire que c'est une branque alors que toi t'es un gros cador du réseau qui a tout compris c'est un peu lamentable comme comportement. La version constructive, si on pense avoir quelque chose d'intéressant à dire sur le sujet, c'est d'aller discuter en public du sujet avec l'auteur. Par exemple si on regarde là: http://permalink.gmane.org/gmane.linux.network/233392 il y a un début de réponse sur la motivation du changement.

Pour moi, ce patch c'est du gros n'importe quoi de gars qui n'a jamais fait de réseau de sa vie.

Faut être sévèrement burné, ou avoir des problèmes mentaux, pour dire que Thomas Graf est un gars "qui n'a jamais fait de réseau de sa vie". Je te conseil vivement d'aller interroger l'historique de ta copie locale du repository git de Linux…

Et toi ?

Source ?

Vite fait, mal fait, jamais fini et on boucle en passant à autre chose c'est un peu l'école de pensée de la gestion de projet française ;)

C'est un peu la French touch !

Bof pour 5 boolléen, tu peux très bien faire 1 paramètre par ligne suivi d'un // estLetal ou // estLiquide. On est pas non plus obligé de faire un gros truc de porcasse hein.

Le code ca se maintient sur 10 ans et plus. Le truc qui te parait évident, le sera pas forcément pour le gars qui se tapera un refactoring 5 ans plus tard. On essai donc d'utiliser la méthode qui sera le moins casse gueule. Et comme souvent ca dépend du contexte.

J'ai rien contre les builders,

Bha si puisque tu dis des choses honteusement fausses comme "et ça permet de créer un objet incomplet qui pétera lorsqu'on devra utiliser un truc en plus qu'on avait pas prévu à l'origine.".

mais les mettre à toutes les sauces

Comme tout ca s'utilise intelligemment, c'est un outil. Dire qu'il ne faut pas l'utiliser quand ce n'est pas approprié c'est enfoncer une porte ouverte.

comme j'ai tendance à le voir dans le code, ça rend le truc illisible, y a pas moyen de créer un objet simplement, tout passe par un builder ou une factory, ou un constructeur vide.

Le problème c'est donc les devs pas l'outil. Change de devs…

Je te propose toujours de me faire une API équivalente du Cache. Tu disais que tu n'avais jamais vu de classe nécessitant un builder de toute ta longue carrière. Pourtant des classes du type de Cache j'en croise et j'en écris régulièrement.

Tu n'as juste rien compris au pattern builder. Le constructeur vide il est sur le builder pas sur l'objet. Et tu verifies la validité de la config au moment ou tu retournes l'objet. Et génial ca simplifie aussi la création des objets immutables qui ont pas mal de variables internes. C'est justement ce type de pattern qui te permet de te passer des vérifications au court de l'utilisation.

Aller un exemple gratos: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/CacheBuilder.html

Une fois que ton cache est construit tu ne peux plus le reconfigurer afin de rester dans un état cohérent. Tu m'expliqueras comment tu fais ca sans builder et sans une API immonde; y'a juste une quinzaine de paramétrage possibles.

Un constructeur avec 30 paramètre j'ai jamaisvu, et pourtant j'en ai vu du code, (dont des template avec plus de 30 paramètre Template. )

Oh 5 ou 6 paramètres suffisent. Il suffit d'avoir 5 bool dans le tout pour faire un truc illisible et casse gueule.

Ca se nomme un builder et c'est très utilisé dans les langages qui ne permettent pas le nommage des paramètres et les valeurs par défaut pour éviter les constructeurs imbitables avec 30 paramètres.

Example: http://www.drdobbs.com/jvm/creating-and-destroying-java-objects-par/208403883?pgno=2

Et dieu inventa les tests unitaires.

J'ai lu l'article et il est totalement creux; il n'y a absolument rien dedans hormis deux chiffres sans grande signification et contexte sortis dont ne sait où.

Maintenant ce qui ne me passe pas au dessus de la tête, c'est qu'il est évident que ce sont les traitements lourds qui coûtent cher. Ces même traitements lourds sont évidement destinés aux pathologies gravent et il est donc normal qu'une forte mortalité s'en suivent. Ce que tu proposes ça revient simplement à dire qu'on ne soigne plus les pathologies ayant de fort risques de décès, où tout du moins plus après un certain âge (on le décide comment ?). Le patient ne prendra pas la décision qu'il s'est engagé à tenir au moment de payer, il faudra donc quelque chose d'imposé dont les règles auront forcément changées entre ton choix et son application. De même ça implique de ne pouvoir JAMAIS changer d'avis (enfin que dans un seul sens).

Bref d'un côté c'est irréalisable. La seule chose faisable qui est de permettre aux patients de demander l'arrêt des soins; ce qui est bien loin de ce que tu proposes "Cotisation variable pour soin variable". De l'autre sans vrais chiffres c'est du pipeau intégral et une discussion digne du café du commerce.

Et comme par magie ton logarithme qui va suivre de très prés le taux d'imposition réel actuel changerait ta façon de te comporter ? C'est totalement irrationnel.

Bha ouai c'est comme les dealers et ceux qui travaillent au black qui dépense leur fortune en TVA ;) MERCI