> parceque ce n'est pas à la machine de s'auto-reguler et de deviner que vous etes 10 sur le reseaux à partager la meme connexion internet.
C'est pas à la machine de s'auto-réguler, c'est a TCP.
Une des caractéristiques très importante de TCP est de se comporter en bon citoyen (fairness ou congestion avoidance dans le texte). Pour résumer grossièrement, si N connexions partagent un même lien ayant un débit D, alors chaque connexion devrait obtenir un débit D/N.
Si tu fais le bourrin avec un connexion UDP, tu vas saturer le réseau et perturber les autres. Si tu fais la même chose avec une connexion TCP, si une congestion est détectée alors TCP va de lui même ralentir pour partager les ressources.
Pour collecter: abonnement RSS à différents blogs/planètes qui traite de la thématique. Il est important de ne sélectionner que ceux qui ont un bon rapport signal/bruit. Et tu passes de temps en temps sur les sites spécialisés (site de conf, portail type infoq).
Pour archiver: delicious + de bons tags. C'est super pratique, et tu perds jamais rien.
C'est quoi le rapport entre les chiffres que tu sors sur l'info industrielle et ce dont on parlait avant ? Y'a quelques équipes d'automaticiens, mais c'est pas la foule non plus. Les employeurs potentiels des personnes dont on parle, ça reste les labs des grosses boites IT/hardware et les petites société innovantes IT. On compare les salaires pour un même boulot...
BTW, si tu acceptes d'être aussi mal payé avec une qualification élevée, devient chercheur en France t'auras au moins les avantages du statut de fonctionnaire...
Les grosses boites ça paye vraiment beaucoup mieux que les SSII... Et généralement ceux qui recrutent les "hautes compétences" c'est pas vraiment les SSII. De plus ces profils sont en général mobiles (tu te déplaces la où la R&D est et tu ne cherches pas ta région).
Oui faire du 45K€ en moins de 5 ans c'est possible. En poussant les bonnes portes tu peux même faire beaucoup mieux pour un job pas forcement dégueu... Demande à des @(google|ms|sap|oracle|apple|cisco|ebay) combien ils gagnent.
Y'a pas si longtemps, les écoles d'ingés te vendaient un salaire de sortie à 20KF/mois...
Est-ce que ceux qui moinssent peuvent se justifier ? Pour info, je suis ex-ingé INRIA qui bosse dans une startup INRIA. Je pense pas que mon commentaire soit inutile ou ni complètement stupide...
Ce n'est pas la mission de transfert que d'embaucher du personnel pour le compte des sociétés, ce n'est pas une agence d'interim ! Ils peuvent t'aider à trouver des fonds pour que tu puisses embaucher par contre. Mon propos n'était pas qu'un chercheur n'a rien à faire dans une startup. Simplement que ta remarque était invalide (et ce quel que soit le type de poste).
Pour rebondir sur ta réponse; embaucher des mecs pour faire de la recherche fondamentale dans les deux premières années ce n'est pas forcement la meilleure idée... Ça ne veut pas dire non plus qu'un chercheur ne peut pas se retrouver sur un poste "industriel" si il en a l'envie et les compétences.
Excellente idée, je vais tout de suite appliquer ça au boulot. Si chaque développeur utilise sa langue maternelle, il fera moins d'erreur dans son code et dans ses docs. Son code devrait donc être meilleur et on aura moins de bugs.
Maintenant chaque devel s'exprime aisément et avec peu de fautes. Bon le problème c'est que plus personne est capable de comprendre ce qu'il dit. De mémoire on a des français, des russes, des roumains, des espagnols, des portugais, des brésiliens, des chinois, des vietnamiens, des pakistanais, des polonais. J'en oublie certainement.
Personnellement je préfère lire du code dans un anglais charabiesque qu'en roumain (variable comprises sinon c'est pas drôle). De même quand tu cherches quelques choses, t'es bien avancé si la seule doc est en russe... Avoir une langue commune permet d'éviter la duplication d'effort et favorise les échanges et la réutilisation. D'ailleurs pour suivre ton principe j'espère que tu ne lis jamais de documentation en anglais.
Ça permet d'utiliser le langage le mieux adapté à la tache et d'arrêter de réinventer la roue ou de faire des bindings dégueulasses dans tout les sens. En plus, ca permet enfin aux nouveaux/petits langages d'avoir une chance d'être utilisés car ils héritent des bibliothèques de leur grand frère (autrement c'est comme arriver avec un nouveau noyau mais aucun support matériel, ça n'intéresse personne).
Bref, on t'impose une plateforme d'exécution : CLR, JVM, parrot ou ce que tu veux. Et après en négociant un peu, tu peux utiliser C#/F#/VB/IronPython ou Java/Scala/Clojure/Jython/Javascript etc.
Un utilisateur préférera peut être écrire son appli de 100 lignes de code en python, mais par contre pour les 500 000 lignes de bibliothèques derrière ce n'est peut être pas le meilleur choix...
Par ce que selon le type de site tu as des motifs de trafique qui apparaissent.
Si tu as un site d'upload de photo, tu as des pics de fréquentation les dimanches/lundi quand les gens upload les photos du weekend et envoient le lien à leurs amis.
Tu as un site sur une activité saisonnière, disons le ski, tu as 10x plus de trafic sur decembre - mars que le reste de l'année.
Tu es linuxfr, tu verras sûrement les vacances scolaires apparaitre. Ou le retour du beau temps.
Quand on prend la même période sur deux années on essai de lisser ces motifs pour avoir des chiffres comparable. Le 23 24 25 décembre sont trois jours qui se suivent, mais les valeurs de chaque jour sont totalement incomparables . Bien entendu il faut faire ca logiquement en fonction des motifs propres du site. C'est tout un métier. Le métier inverse à celui là, c'est faire du "capacity planning". C'est à dire d'assurer que ton site ne sera jamais surchargé en fonction de la charge actuelle des machines et de tes connaissances sur l'utilisation de ton site. Je recommande très fortement ce bouquin la d'ailleurs: http://oreilly.com/catalog/9780596518578/
En gros tu peux faire des threads en python mais ça ne te permettra pas d'exploiter plusieurs cœurs en même temps. Ça peut toujours améliorer le débit de ton appli en ne restant pas bloqué bêtement sur des IO.
D'autres implémentation que CPython pourrait proposer un vrai threading.
Il y a une différence entre gérer, et être performant/scaler pour une application quelconque.
De mémoire il me semble que tu bosses dans le HPC. Dans ce contexte oui, pour du code dédié à un hardware et qui fait des choses assez "limité" ca fonctionne. Le multicore expose les problèmes que l'on a dans le HPC depuis quelques dizaines d'années...
Dire qu'actuellement les OS sont capables de scaler linéairement sur 1024 cores pour une charge de travail généraliste n'est pas vrai.
Tu sais que tu peux faire un modèle actor en Java en zero copy et sans avoir à commuter de thread à chaque fois ?
Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.
On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.
De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.
Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.
Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...
[1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.
Au contraire: chaque connexion à une instance Oracle correspond à un nouveau processus/thread démarré sur le système (en mode serveur dédié, donc par défaut), donc bénéficie parfaitement du nombre de CPU.... plus il y en a, mieux c'est !!! (indépendamment du reste: IO, bus, mémoire, etc...)
Et bien sur Oracle à une architecture shared nothing entre tout ces threads qui devine le résultat de ta requête grâce à un oracle.... Rappelle moi de ne jamais t'embaucher pour bosser sur une appli parallèle.
Même si c'était le cas, les OS actuels galèrent pas mal si tu augmentes significativement le nombre de coeurs. Genre simplement pour se partager une carte réseau et réussir à saturer du 10Gb. On peut aussi aller jouer dans le VFS ou dans le VMM si tu veux aussi.
Tu dis un peu n'importe quoi. La création de startup est fortement poussé en avant à l'INRIA. Tu pars même dans des conditions que beaucoup pleureraient pour les avoir... À chaque directeur de recherche de faire ce qu'il veut.
Après ça n'empêche pas des collaboration avec d'autres boîtes. C'est à la discrétion de chaque équipe de recherche de choisir ses contrats.
Pour le cas du partenariat avec MS c'est encore autre chose. Les mecs de cambridge avaient envie de faire un tour à Paris. Pour être sérieux 5 minutes, Microsoft Research est un très gros acteur de la recherche fondamentale. Y'en a pas beaucoup qui hésiteraient entre un poste chez MS Research à cambridge, seattle ou Mountain View et un poste à l'INRIA. Bon c'est un tantinet plus difficile d'y rentrer mais c'est un détail...
Et autrement il y a quoi de plus sale de bosser avec MS Research, google labs, Yahoo Research et autres qu'avec des universités ?
La normalisationqui est le fait d'établir des normes et standards industriels, c'est-à-dire un référentiel commun et documenté destiné à harmoniser l'activité d'un secteur.. C et Ada sont normalisés auprès de l'ISO. Java à sont propre comité, le JCP. Pour python je ne connais pas suffisamment les détails. Savoir lequel des processus de l'ISO ou du JCP sont le plus ouvert est laissé en exercice aux lecteurs. Dans tout les cas les spécifications existes.
Je ne sais pas pour python, mais pour Java un bug dans l'implémentation de référence est un bug. C'est très simple tu as une spec. À partir de cette spec une suite de test (TCK) est faite, une implémentation est conforme si elle passe la suite de test.
L'implémentation de ces normes par les compilateurs et la disponibilité des bibliothèques standard sur des plateformes moderne. Ce n'est pas par ce que le C89 ou Ada83 sont normalisés à l'ISO que du code de cette époque est toujours compilable. C'est le choix des compilateur de toujours supporter les anciens standards. Gcc pourrait très bien décider de ne plus supporter le C89 un jour. Avoir une norme est un prérequis mais n'est pas suffisante.
Notons que la partie syntaxique/lexicale du langage n'est qu'une toute petit partie de l'iceberg. L'évolution des bibliothèques standard est tout aussi importante. Si des changements non backward compatibles sont fait aux bibliothèques standard ca devient un peu plus compliqué à gérer les anciens standards. Du coup cela peut impliquer de se trimbaler des API merdiques et totalement délirantes pendant 30+ années (qui à parlé de la libc ?).
Et enfin tu as les bugs des implémentations. Ton programme peut tomber en marche à cause d'une zone floue dans la spec ou tout simplement d'un bug présent dans une release donnée du compilateur/libs. En passant sur une autre implémentation, il va exploser en vol. Dans un monde parfait ca ne devrait pas exister, dans le monde réel si. Toutes les implémentations sont buggées et toutes les specs ont des zones floues.
J'aimerai que tu me démontres en quoi Java se préoccupe moins de la pérennité du code legagy que C ou Ada. C'est presque ce qu'on leur reproche...
Le fait de pouvoir tout mettre dans les list|hash en python pousse les devs a faire des API minimalistesimbitables, où la notion d'abstraction est un lointain souvenir. Au hasard choisissons un petit bout de code utilisant imaplib, http://www.python.org/doc/2.5.2/lib/imap4-objects.html . Nous voulons simplement lister tout les messages non lu et matcher sur un sujet.
server = imaplib.IMAP4(host)
server.login(user, passwd)
inbox = server.select()
typ, data = server.search(None, 'UNSEEN')
urls = []
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
for line in data[0][1].split("\r\n"):
# header & body part
(junk, sep, url) = line.partition("magic_key:")
if not url is "":
urls.append(url)
return urls
C'est sur ca fait facilement 5x moins de ligne que son équivalent en javamail. Par contre on peut le voir, c'est tout aussi pénible à utiliser. Je préfère écrire 5x plus de lignes, mais manipuler des abstractions et que je sache ce que je manipule. Je m'explique:
typ, data = server.search(None, 'UNSEEN')
Qu'est ce que peut bien me retourner server.search ? Allons voir la doc: Search mailbox for matching messages. charset may be None, in which case no "CHARSET" will be specified in the request to the server. The IMAP protocol requires that at least one criterion be specified; an exception will be raised when the server returns an error. . Je suis bien avancé aucune idée de ce que peuvent être typ ou data. Moi je voulais manipuler une liste de message non lu. Il me retourne une structure dont je ne sais rien...
En "printant" la structure on découvre ce qui nous intéresse. C'est super pro comme démarche... On découvre qu'il "suffit" de faire un data[0].split() pour avoir tout les ID des messages. Bon si ils changent la map dans une prochaine release tout va péter silencieusement mais c'est une autre histoire.
Après on veut manipuler les messages. Rebelote on va voir la doc Fetch (parts of) messages. message_parts should be a string of message part names enclosed within parentheses, eg: ""(UID BODY[TEXT])"". Returned data are tuples of message part envelope and data.
Encore une fois aucune abstraction, on me balance un tuple dont l'un des éléments est le message sous forme d'une string. C'est un peu plus précis mais pas trop quand même. Et le message surtout je me démerde avec ma string hein.
Moi tout ce que je voulais c'est "Pour chaque message non lu chercher dans le corp du message les lignes contenant magic_key et en extraire la suite".
Le code python est peut être beaucoup plus court, mais a utiliser il est super pénible, casse gueule. Les notions d'objet et d'abstraction sont bien loin...
> A l'utilisation, tu peux te limiter à quelques constructions qui te permettront de couvrir tous les cas que tu traiteras.
Ca marche bien quand tu es tout seul et sur une période assez courte (< 2 ans).
Dans une vraie équipe, chacun à beau se limiter, la somme des limitations reste tout de même un gros bordel. Je bosse actuellement sur un projet qui a vu 71 devs en 10 ans, moins y'a de cowboy dans le lot mieux je me porte.
Ce qui fait la force des langages de scripting à typage dynamique/failble est que tu peux facilement fourrer tout et n'importe quoi dans ta structure de données. Le langage repousse la responsabilité de faire les choses correctement vers le développeur. Si tu es statiquement et fortement typé tu ne peux et ne veux surtout pas faire ça.
La solution des Pair/Tuple typé via generics est la solution la moins sale si tu veux faire ce genre de choses. Mais certainement pas une hashmap ou toute autre dégueulasserie (encore une fois ce qui est acceptable et plaisant en scripting ne l'est pas pour une appli).
Si si ca à été envisagé. Gossling à d'ailleurs dit qu'il regrettait de ne pas l'avoir fait à la base.
There are a bunch of things that I'd do differently. There are a number of things that I'm not entirely happy with and it's not clear what the right answer is. I'm not really happy with the schism between interfaces and classes; in many ways it feels like the right solution wouldn't get in the way.
There have been a number of things -- like, for example, multiple return values -- that these days I kind of wish I had added. That was one where I really liked the feature and most other people just sort of went, "Huh?"
Il y a d'ailleurs eu quelques RFE n'ont pas eu de suite puisqu'il faudrait péter la compatibilité de la VM pour le supporter. Normalement pour le langage ca peut rester compatible (de mémoire).
[^] # Re: Comment configurer son apt
Posté par ckyl . En réponse au journal Mon Linux n'est pas partageur. Évalué à 5.
C'est pas à la machine de s'auto-réguler, c'est a TCP.
Une des caractéristiques très importante de TCP est de se comporter en bon citoyen (fairness ou congestion avoidance dans le texte). Pour résumer grossièrement, si N connexions partagent un même lien ayant un débit D, alors chaque connexion devrait obtenir un débit D/N.
Si tu fais le bourrin avec un connexion UDP, tu vas saturer le réseau et perturber les autres. Si tu fais la même chose avec une connexion TCP, si une congestion est détectée alors TCP va de lui même ralentir pour partager les ressources.
[^] # Re: Outils de veille
Posté par ckyl . En réponse à la dépêche Veille technologique sur le web. Évalué à 2.
Pour archiver: delicious + de bons tags. C'est super pratique, et tu perds jamais rien.
# delicious
Posté par ckyl . En réponse à la dépêche Veille technologique sur le web. Évalué à 1.
[^] # Re: Bon bon bon...
Posté par ckyl . En réponse au journal Support Mercurial sur google code. Évalué à 2.
Y'a une bonne centaine d'autres raisons, mais rien que git-svn ca improve ta life. Après chacun choisi l'outil qui lui convient.
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 1.
BTW, si tu acceptes d'être aussi mal payé avec une qualification élevée, devient chercheur en France t'auras au moins les avantages du statut de fonctionnaire...
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 4.
Oui faire du 45K€ en moins de 5 ans c'est possible. En poussant les bonnes portes tu peux même faire beaucoup mieux pour un job pas forcement dégueu... Demande à des @(google|ms|sap|oracle|apple|cisco|ebay) combien ils gagnent.
Y'a pas si longtemps, les écoles d'ingés te vendaient un salaire de sortie à 20KF/mois...
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 4.
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 3.
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 3.
Pour rebondir sur ta réponse; embaucher des mecs pour faire de la recherche fondamentale dans les deux premières années ce n'est pas forcement la meilleure idée... Ça ne veut pas dire non plus qu'un chercheur ne peut pas se retrouver sur un poste "industriel" si il en a l'envie et les compétences.
[^] # Re: Gains de performance
Posté par ckyl . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 2.
Des trucs hallucinants y'en a des tonnes, mais la je vois pas...
[^] # Re: Dommage
Posté par ckyl . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 5.
Maintenant chaque devel s'exprime aisément et avec peu de fautes. Bon le problème c'est que plus personne est capable de comprendre ce qu'il dit. De mémoire on a des français, des russes, des roumains, des espagnols, des portugais, des brésiliens, des chinois, des vietnamiens, des pakistanais, des polonais. J'en oublie certainement.
Personnellement je préfère lire du code dans un anglais charabiesque qu'en roumain (variable comprises sinon c'est pas drôle). De même quand tu cherches quelques choses, t'es bien avancé si la seule doc est en russe... Avoir une langue commune permet d'éviter la duplication d'effort et favorise les échanges et la réutilisation. D'ailleurs pour suivre ton principe j'espère que tu ne lis jamais de documentation en anglais.
[^] # Re: confus
Posté par ckyl . En réponse au journal Publication de Parrot 1.0. Évalué à 1.
Ça permet d'utiliser le langage le mieux adapté à la tache et d'arrêter de réinventer la roue ou de faire des bindings dégueulasses dans tout les sens. En plus, ca permet enfin aux nouveaux/petits langages d'avoir une chance d'être utilisés car ils héritent des bibliothèques de leur grand frère (autrement c'est comme arriver avec un nouveau noyau mais aucun support matériel, ça n'intéresse personne).
Bref, on t'impose une plateforme d'exécution : CLR, JVM, parrot ou ce que tu veux. Et après en négociant un peu, tu peux utiliser C#/F#/VB/IronPython ou Java/Scala/Clojure/Jython/Javascript etc.
Un utilisateur préférera peut être écrire son appli de 100 lignes de code en python, mais par contre pour les 500 000 lignes de bibliothèques derrière ce n'est peut être pas le meilleur choix...
[^] # Re: J'ai pas les mêmes chiffres
Posté par ckyl . En réponse au journal Stats LinuxFr.org 2009-02. Évalué à 7.
Si tu as un site d'upload de photo, tu as des pics de fréquentation les dimanches/lundi quand les gens upload les photos du weekend et envoient le lien à leurs amis.
Tu as un site sur une activité saisonnière, disons le ski, tu as 10x plus de trafic sur decembre - mars que le reste de l'année.
Tu es linuxfr, tu verras sûrement les vacances scolaires apparaitre. Ou le retour du beau temps.
Quand on prend la même période sur deux années on essai de lisser ces motifs pour avoir des chiffres comparable. Le 23 24 25 décembre sont trois jours qui se suivent, mais les valeurs de chaque jour sont totalement incomparables . Bien entendu il faut faire ca logiquement en fonction des motifs propres du site. C'est tout un métier. Le métier inverse à celui là, c'est faire du "capacity planning". C'est à dire d'assurer que ton site ne sera jamais surchargé en fonction de la charge actuelle des machines et de tes connaissances sur l'utilisation de ton site. Je recommande très fortement ce bouquin la d'ailleurs: http://oreilly.com/catalog/9780596518578/
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par ckyl . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 2.
En gros tu peux faire des threads en python mais ça ne te permettra pas d'exploiter plusieurs cœurs en même temps. Ça peut toujours améliorer le débit de ton appli en ne restant pas bloqué bêtement sur des IO.
D'autres implémentation que CPython pourrait proposer un vrai threading.
[^] # Re: Où est le problème ?
Posté par ckyl . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 3.
De mémoire il me semble que tu bosses dans le HPC. Dans ce contexte oui, pour du code dédié à un hardware et qui fait des choses assez "limité" ca fonctionne. Le multicore expose les problèmes que l'on a dans le HPC depuis quelques dizaines d'années...
Dire qu'actuellement les OS sont capables de scaler linéairement sur 1024 cores pour une charge de travail généraliste n'est pas vrai.
Le premier papier intéressant qui me vient à l'esprit est corey, qui à des propositions intéressantes pour des archis fortement multicore: http://www.mit.edu/~y_z/papers/corey-osdi08.pdf
[^] # Re: perf
Posté par ckyl . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 7.
Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.
On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.
De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.
Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.
Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...
[1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.
[^] # Re: Où est le problème ?
Posté par ckyl . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 1.
Et bien sur Oracle à une architecture shared nothing entre tout ces threads qui devine le résultat de ta requête grâce à un oracle.... Rappelle moi de ne jamais t'embaucher pour bosser sur une appli parallèle.
http://forge.mysql.com/w/images/7/73/Mysqlscale.pdf pour te faire un peu de culture. C'est une introduction, c'est un peu plus compliqué dans la réalité.
Même si c'était le cas, les OS actuels galèrent pas mal si tu augmentes significativement le nombre de coeurs. Genre simplement pour se partager une carte réseau et réussir à saturer du 10Gb. On peut aussi aller jouer dans le VFS ou dans le VMM si tu veux aussi.
[^] # Re: Troll spotted
Posté par ckyl . En réponse au journal Le labo commun Inria-Microsoft. Évalué à 5.
Après ça n'empêche pas des collaboration avec d'autres boîtes. C'est à la discrétion de chaque équipe de recherche de choisir ses contrats.
Pour le cas du partenariat avec MS c'est encore autre chose. Les mecs de cambridge avaient envie de faire un tour à Paris. Pour être sérieux 5 minutes, Microsoft Research est un très gros acteur de la recherche fondamentale. Y'en a pas beaucoup qui hésiteraient entre un poste chez MS Research à cambridge, seattle ou Mountain View et un poste à l'INRIA. Bon c'est un tantinet plus difficile d'y rentrer mais c'est un détail...
Et autrement il y a quoi de plus sale de bosser avec MS Research, google labs, Yahoo Research et autres qu'avec des universités ?
[^] # Re: Merci pour l'information
Posté par ckyl . En réponse au journal Explorez les richesses du langage Python. Évalué à 3.
La normalisationqui est le fait d'établir des normes et standards industriels, c'est-à-dire un référentiel commun et documenté destiné à harmoniser l'activité d'un secteur.. C et Ada sont normalisés auprès de l'ISO. Java à sont propre comité, le JCP. Pour python je ne connais pas suffisamment les détails. Savoir lequel des processus de l'ISO ou du JCP sont le plus ouvert est laissé en exercice aux lecteurs. Dans tout les cas les spécifications existes.
Je ne sais pas pour python, mais pour Java un bug dans l'implémentation de référence est un bug. C'est très simple tu as une spec. À partir de cette spec une suite de test (TCK) est faite, une implémentation est conforme si elle passe la suite de test.
L'implémentation de ces normes par les compilateurs et la disponibilité des bibliothèques standard sur des plateformes moderne. Ce n'est pas par ce que le C89 ou Ada83 sont normalisés à l'ISO que du code de cette époque est toujours compilable. C'est le choix des compilateur de toujours supporter les anciens standards. Gcc pourrait très bien décider de ne plus supporter le C89 un jour. Avoir une norme est un prérequis mais n'est pas suffisante.
Notons que la partie syntaxique/lexicale du langage n'est qu'une toute petit partie de l'iceberg. L'évolution des bibliothèques standard est tout aussi importante. Si des changements non backward compatibles sont fait aux bibliothèques standard ca devient un peu plus compliqué à gérer les anciens standards. Du coup cela peut impliquer de se trimbaler des API merdiques et totalement délirantes pendant 30+ années (qui à parlé de la libc ?).
Et enfin tu as les bugs des implémentations. Ton programme peut tomber en marche à cause d'une zone floue dans la spec ou tout simplement d'un bug présent dans une release donnée du compilateur/libs. En passant sur une autre implémentation, il va exploser en vol. Dans un monde parfait ca ne devrait pas exister, dans le monde réel si. Toutes les implémentations sont buggées et toutes les specs ont des zones floues.
J'aimerai que tu me démontres en quoi Java se préoccupe moins de la pérennité du code legagy que C ou Ada. C'est presque ce qu'on leur reproche...
[^] # Re: Critique
Posté par ckyl . En réponse au journal Explorez les richesses du langage Python. Évalué à 6.
server = imaplib.IMAP4(host)
server.login(user, passwd)
inbox = server.select()
typ, data = server.search(None, 'UNSEEN')
urls = []
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
for line in data[0][1].split("\r\n"):
# header & body part
(junk, sep, url) = line.partition("magic_key:")
if not url is "":
urls.append(url)
return urls
C'est sur ca fait facilement 5x moins de ligne que son équivalent en javamail. Par contre on peut le voir, c'est tout aussi pénible à utiliser. Je préfère écrire 5x plus de lignes, mais manipuler des abstractions et que je sache ce que je manipule. Je m'explique:
typ, data = server.search(None, 'UNSEEN')Qu'est ce que peut bien me retourner server.search ? Allons voir la doc: Search mailbox for matching messages. charset may be None, in which case no "CHARSET" will be specified in the request to the server. The IMAP protocol requires that at least one criterion be specified; an exception will be raised when the server returns an error. . Je suis bien avancé aucune idée de ce que peuvent être typ ou data. Moi je voulais manipuler une liste de message non lu. Il me retourne une structure dont je ne sais rien...
En "printant" la structure on découvre ce qui nous intéresse. C'est super pro comme démarche... On découvre qu'il "suffit" de faire un
data[0].split()pour avoir tout les ID des messages. Bon si ils changent la map dans une prochaine release tout va péter silencieusement mais c'est une autre histoire.Après on veut manipuler les messages. Rebelote on va voir la doc Fetch (parts of) messages. message_parts should be a string of message part names enclosed within parentheses, eg: ""(UID BODY[TEXT])"". Returned data are tuples of message part envelope and data.
Encore une fois aucune abstraction, on me balance un tuple dont l'un des éléments est le message sous forme d'une string. C'est un peu plus précis mais pas trop quand même. Et le message surtout je me démerde avec ma string hein.
Moi tout ce que je voulais c'est "Pour chaque message non lu chercher dans le corp du message les lignes contenant magic_key et en extraire la suite".
Le code python est peut être beaucoup plus court, mais a utiliser il est super pénible, casse gueule. Les notions d'objet et d'abstraction sont bien loin...
J'aime pas du tout l'API de javamail mais entre imaplib:
http://www.python.org/doc/2.5.2/lib/module-imaplib.html
http://www.python.org/doc/2.5.2/lib/imap4-objects.html
et javamail:
http://java.sun.com/products/javamail/javadocs/com/sun/mail/(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Fo(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Me(...)
je sais lequel est plus facile à manipuler et que c'est totalement indépendant de devoir écrire 50 lignes de plus...
[^] # Re: Fedora 11 Feature List
Posté par ckyl . En réponse à la dépêche ext4 et Btrfs pour Fedora 11. Évalué à 10.
Autrement la contribution upstream n'est vraiment pas dans la mentalité de Fedora....
[^] # Re: Explicit is better than implicit.
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
Ca marche bien quand tu es tout seul et sur une période assez courte (< 2 ans).
Dans une vraie équipe, chacun à beau se limiter, la somme des limitations reste tout de même un gros bordel. Je bosse actuellement sur un projet qui a vu 71 devs en 10 ans, moins y'a de cowboy dans le lot mieux je me porte.
[^] # Re: javascript
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
Ce qui fait la force des langages de scripting à typage dynamique/failble est que tu peux facilement fourrer tout et n'importe quoi dans ta structure de données. Le langage repousse la responsabilité de faire les choses correctement vers le développeur. Si tu es statiquement et fortement typé tu ne peux et ne veux surtout pas faire ça.
La solution des Pair/Tuple typé via generics est la solution la moins sale si tu veux faire ce genre de choses. Mais certainement pas une hashmap ou toute autre dégueulasserie (encore une fois ce qui est acceptable et plaisant en scripting ne l'est pas pour une appli).
[^] # Re: javascript
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 3.
There are a bunch of things that I'd do differently. There are a number of things that I'm not entirely happy with and it's not clear what the right answer is. I'm not really happy with the schism between interfaces and classes; in many ways it feels like the right solution wouldn't get in the way.
There have been a number of things -- like, for example, multiple return values -- that these days I kind of wish I had added. That was one where I really liked the feature and most other people just sort of went, "Huh?"
Il y a d'ailleurs eu quelques RFE n'ont pas eu de suite puisqu'il faudrait péter la compatibilité de la VM pour le supporter. Normalement pour le langage ca peut rester compatible (de mémoire).
Si tu veux jouer avec ca, regarde du côté de javatuple: http://javatuple.com/index.shtml
[^] # Re: javascript
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
Tu viens de découvrir pourquoi on préfère créer un vrai objet. Bravo ! Tu viens de démontrer par toi même à quel point c'est casse gueule :-)
Comme je l'ai dit, si tu veux t'amuser avec les retours multiples, regarde du côté de javatuple. Mais >90% du temps tu veux un vrai objet.
Rappel pour ceux qui ont raté le premier épisode: Java n'est pas un langage de scripting.