Non. Tu peux très bien en haskell mettre des effets de bord partout.
Suffit de tout coder dans la monade IO. C'est comme en POO : tu peux tout faire dans une seule classe et envoyer balader ces classes, ces interfaces et tout ça. Je peux « coder en C » aussi bien en Haskell qu'en Java.
Ce qui garde les effets de bords à un strict minimum, c'est le programmeur. J'en met là où j'en veux, quelque soit le langage.
Quand à la soupe (et haskell), j'aime et je trouve ça bon. En revanche, je n'aime pas qu'on dise « c'est grâce aux monades » quand ça n'a pas grand chose à voir… Mon code est quasi identique en OCaml et en Haskell, pourtant, en ML, je peux mettre des effets de bord partout…
La « pureté » n'a raison d'être qu'au niveau des types, dans la formalisation mathématique. En pratique, ça change que dalle. Ah si, ça te prend 3 fois plus de temps quand tu veux tracer ton code (bon, t'as des moyens, mais ça vaut pas un printf placé ça et là…)
Dans ton exemple pratique, tu penses uniquement à la monade IO qui est un gros hack pour les effets de bord. La pureté en question, c'est pour se donner bonne conscience; en pratique, c'est aussi sale qu'un effet de bord dans un autre langage. C'est un artifice, oui, et comme argument, ça vaut zéro. C'est pas la monade qui permet ça, c'est le style de programmation : « environment passing style. »
Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !
En revanche, l'idée d'encapsulation, elle, est meilleure.
Quand tu écris
do
x <- extraction
return (foo x)
c'est comme si tu écrivais
do
x <- extraction_hors_de_la_boite(boite)
met_dans_une_boite(foo x)
Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »
Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.
T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.
Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^
Ho ! Ça c'est excellentissime !
Je ne connaissais pas, mais je vais m'y mettre tout de suite, et proposer cette solution autour de moi (on verra s'il y a des inconvénients. La compatibilité avec les liens HTML usuels me parait très bien vue quand même !)
>> Les monades (avec un "e" en français, il me semble) sont assez complexes, et on met beaucoup de temps à les comprendre (plusieurs années pour moi, sans y être à plein temps dessus quand même).
Euh, une monade, en pratique (i.e. en programmation Haskell), c'est rien d'autre qu'un vulgaire design-pattern.
T'as une interface (les types des opérateurs), et les gars se masturbent pour coller tout et n'importe quoi qui colle à cette interface…
Des monades, j'en code en OCaml, en Scheme et en Common Lisp quand c'est pratique (typiquement la monade non déterministe (c-à-d la monade Liste)), sinon, je me fais pas chier…
Les monades, d'un point de vue catégorique (au sens mathématique du mot « catégorie », là, sont moins faciles à comprendre, oui), mais t'as aucunement besoin de comprendre ça pour coder en Haskell. Ça, c'est de la propagande ridicule (« wéé ! on a des monades, c'est trop top ») trop souvent clamée par des « newbies » qui n'ont rien compris mais qui se donnent l'impression d'appartenir à une classe de gens supra-intelligents. Dire « j'ai pu résoudre mon problème grace aux monades d'Haskell, » c'est comme dire « j'ai pu résoudre mon problème grace au pattern décorator de Java. » Comme si on pouvait pas faire autrement, ni avec un autre langage…
>> Voila, je cherche donc un logiciel qui me permet d'entrer les éléments et leurs contraintes et de calculer l'ensemble des possibilités, et de me dessiner ces possibilités sous forme d'arbre.
C'est un système de résolution de contrainte, donc tu veux juste taper tes règles dans un bête prolog (mais tu peux aussi le coder facilement en haskell avec la monade non-déterministe, où en Java avec la bibliothèque "Choco").
Tu veux juste trouver l'ensemble des solutions de ton système de contraintes (une liste de listes).
Éventuellement pour l'affichage, tu peux créer une forêt en prenant tous les racines différentes, puis en créant des arbres en fusionnant les listes qui ont la même racine…
>> Comment veux-tu passer à autre chose que IP sachant que IP V6 n'arrive même pas à s'imposer ?
Et aussi "Pourquoi voulait-on des DVD alors que le LaserDisc n'arrivait même pas à s'imposer". IPV6 est une solution au NAT, mais pas la solution à tous les problèmes…
Ensuite, je parle de l'API et de TCP/IP, les deux mon général !
Pour l'API, j'ai été convaincu en essayant moi même il y a longtemps, et j'ai été conforté dans mon opinion par http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/f(...) (si ton labo n'y est pas abonné, demande leur de le faire. C'est très bien comme magazine !)
Tu vois, qu'un GC ralentisse mon kernel, je m'en tape complètement, comparé à toutes les pertes qu'on subit à ne pas implanter dès il y a 10 ans des technologies développées pour la mobilité et la distribution. Je pense que de simples statistiques sur le nombre de possesseurs de terminaux mobiles reliés à internet suffit à justifier le changement sans réfléchir plus que ça.
>> Pour les vieilleries, il faudrait implementer une stack TCP/IP avec pour vraiment savoir si on en a toujours besoin ou pas :)
La pile TCP/IP, faut s'en séparer…
Elle a fait son temps et n'est plus adaptée (API de merde, limitée aux connexions fixes… La recherche a continué depuis la préhistoire !)
>> Ça risque d'être controversé, vu qu'en général on essaie d'éviter les garbage collector dans les kernels.
On évite les GC dans les kernels *écrits dans des langages où on a collé un GC sans réflechir aux applications*.
Un GC, c'est pas un .so que tu lies, et hop c'est fini !
Un GC, ça s'optimise, ça se configure aux petits oignons tant en même temps qu'on crée le langage (son compilateur ou son interprète) et aussi en même temps qu'on développe son application.
Alors, certes, ça fait pas plaisir aux gens qui ne jurent que par un seul langage, mais on ne construit pas toutes les voitures avec une seule et unique clef à pipe…
On citait les machines Lisp plus bas, mais il me semble aussi que Lisaac possède un GC et qu'il a servi à prototyper un OS potable…
Ontologia, si tu nous lis, ton avis sur ce journal m'intéresse beaucoup !
Le matériel était effectivement adapté au langage utilisé pour logiciels qui tournaient dessus. C'était bien codé dans des LISPs à typage dynamique et avec GC.
Alors non, ce n'était pas dépourvu de bugs (car les dialectes de LISP étaient nombreux, et pas forcément aussi agréables que l'actuel Common Lisp), tout comme le rappelle Joe Marshall dans son très bon blog où il raconte des histoires de debuggage qu'il a vécues dans les années 80 [1].
Mais bon, les GC d'alors, c'était pas la panacée, hein. Ni les interprètes et compilateurs…
Sinon, tu dis : « De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ? », mais je ne vois pas le rapport avec le GC. Enfin, avec le typage dynamique, tu as un tag sur tes données, donc le GC sais différencier un entier d'une adresse, une chaîne de caractères d'un symbole… Ça se nettoie très bien tout ça.
Puis le typage dynamique n'impose pas qu'on ne type rien ! T'as pleins d'optimisations de typage local, d'évaluation partielles qu'on peut faire quand même…
>> S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ?
Quel rapport entre la vitesse et la gestion de la mémoire ?
>> En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ben, tu prends un GC temps-réel, et hop.
Ou alors un GC-hybride…
Choisir son GC fait aussi partie du développement d'une appli ou du choix d'un langage pour un problème donné…
>> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?
Ça dépend du langage. Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique). Inversement, Scheme se compile très bien…
Après, je te rappelle que les langages de scripts peuvent aussi se compiler, non seulement vers du code machine, mais aussi pour une VM…
C'était combien de temps ?
Car 75 pages de présentation, avec beaucoupbeaucoup de redondance (car je fais pas la différence entre deux pages dont seul le checksum du commit change), c'est pas mal indigeste !
Je rententerai de lire tout ça plus tard, car là, ça m'a vite achevé…
Ben, perso, moi qui ne suis pas *du tout* orienté matos, j'ai découvert ça avec le TP en question à l'époque. J'ai des préoccupations différentes quand je fais un programme, et du moment que mon algo est de même complexité que la solution optimale théorique, je suis content. La tenue des données en cache, c'est tellement rarement l'un de mes soucis que j'ai vite fait de n'en avoir plus rien à faire.
Évidemment, ça dépend de l'industrie dans laquelle tu travailles (et pour avoir lu ton parcours, je me doute bien qu'à toi, ça te parait évident), mais c'est à mon avis une évidence et un critère de développement pour moins de la moité des programmeurs.
D'autant plus que ce sont des optimisations qui ne sont pas forcément algorithmiques et qui ne sont valides que dans certains langages bas-niveau…
>> Le débat porte donc sur le fait que code plus court = code tenant mieux dans le cache code du processeur, donc meilleur exécution...
Des générations entières de programmeurs Fortran à la belle époque te remercie d'avoir rappelé le lien fort entre optimisations et matériel, notamment taille des caches du processeur.
--
Axioplase, qui avait eu un TP sur l'optimisation de code fortran dans un cours orienté compilation et matériel ^^
main = let x = "etmonculcestdupoulet?" in putStrLn x
>> - Pas de notion d'objet (trop restrictif)
Objets et fermetures sont (grossièrement) isomorphes
>> - Essaie de réduire au maximum les effets de bord
Sur le papier.
En pratique, c'est pareil que partout ; simplement les utilisateurs vont préférer tout passer en paramètre plutôt que de stocker dans une variable (et en pratique, une monade State, c'est des effets de bords, sinon c'est pas super efficace)
>> - Permet de créer facilement des modules génériques et réutilisables
Comme partout. Quand t'es prêt à passer trois fois plus de temps à généraliser ton code que t'en as passé à le créer pour résoudre ton problème.
Bref, haskell (que j'adore), c'est pas la panacée, loin de là…
En revanche, c'est hype, ça donne le poil luisant et ça attire les financements anglo-saxons.
Encore une fois, le langage est un outil, et le langage X peut être super pour planter des clous, mais une bouse impossible pour tourner des vis.
Quand j'ai besoin de Haskell, je sors mon ghc, mais quand j'ai besoin de perl ou de postscript, je vais pas me faire chier avec haskell.
Ouais, enfin, t'as des sites légitimes qui vont s'écrire avec « é » ( U+00C9) et d'autres avec « é » (U+0065 suivi de U+0308).
Et là, bonjour la sécurité (car bien sûr, tu crois que ta banque va te filer une clef publique la prochaine fois que tu iras au guichet et que les sites vont avoir une sécurité fiable ?)
Tu me files une pétition contre cette extension des noms, je signe de suite.
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Suffit de tout coder dans la monade IO. C'est comme en POO : tu peux tout faire dans une seule classe et envoyer balader ces classes, ces interfaces et tout ça. Je peux « coder en C » aussi bien en Haskell qu'en Java.
Ce qui garde les effets de bords à un strict minimum, c'est le programmeur. J'en met là où j'en veux, quelque soit le langage.
Quand à la soupe (et haskell), j'aime et je trouve ça bon. En revanche, je n'aime pas qu'on dise « c'est grâce aux monades » quand ça n'a pas grand chose à voir… Mon code est quasi identique en OCaml et en Haskell, pourtant, en ML, je peux mettre des effets de bord partout…
La « pureté » n'a raison d'être qu'au niveau des types, dans la formalisation mathématique. En pratique, ça change que dalle. Ah si, ça te prend 3 fois plus de temps quand tu veux tracer ton code (bon, t'as des moyens, mais ça vaut pas un printf placé ça et là…)
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 3.
Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !
En revanche, l'idée d'encapsulation, elle, est meilleure.
Quand tu écris
do
x <- extraction
return (foo x)
c'est comme si tu écrivais
do
x <- extraction_hors_de_la_boite(boite)
met_dans_une_boite(foo x)
Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »
Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.
T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.
Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^
[^] # Re: FTP
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 2.
Je ne connaissais pas, mais je vais m'y mettre tout de suite, et proposer cette solution autour de moi (on verra s'il y a des inconvénients. La compatibilité avec les liens HTML usuels me parait très bien vue quand même !)
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Euh, une monade, en pratique (i.e. en programmation Haskell), c'est rien d'autre qu'un vulgaire design-pattern.
T'as une interface (les types des opérateurs), et les gars se masturbent pour coller tout et n'importe quoi qui colle à cette interface…
Des monades, j'en code en OCaml, en Scheme et en Common Lisp quand c'est pratique (typiquement la monade non déterministe (c-à-d la monade Liste)), sinon, je me fais pas chier…
Les monades, d'un point de vue catégorique (au sens mathématique du mot « catégorie », là, sont moins faciles à comprendre, oui), mais t'as aucunement besoin de comprendre ça pour coder en Haskell. Ça, c'est de la propagande ridicule (« wéé ! on a des monades, c'est trop top ») trop souvent clamée par des « newbies » qui n'ont rien compris mais qui se donnent l'impression d'appartenir à une classe de gens supra-intelligents. Dire « j'ai pu résoudre mon problème grace aux monades d'Haskell, » c'est comme dire « j'ai pu résoudre mon problème grace au pattern décorator de Java. » Comme si on pouvait pas faire autrement, ni avec un autre langage…
[^] # Re: Dans le même genre: marionnet
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse à la dépêche Émulateur de réseau basé sur des machines virtuelles. Évalué à 2.
J'avais vu une présentation de marionnet au ML workshop 2007, et j'avais trouvé ça vraiment bath comme logiciel !
Je me demande quand même si c'est répandu, ce genre d'applications…
À noter, une fois qu'on a un beau réseau, y a plein d'applis sympas pour installer des logiciels partout (TakTuk, GXP, etc)
# Xfig
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au message Schemas reseaux.... Évalué à 2.
Ou Sinon, un petit coup de LaTeX ? http://met.guc.edu.eg/OnlineTutorials/LaTeX/Automata%20in%20(...)
[^] # Re: Orthographe
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au message Schemas reseaux.... Évalué à 2.
# Prolog
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au message Logiciel de génération d'arbres. Évalué à 2.
C'est un système de résolution de contrainte, donc tu veux juste taper tes règles dans un bête prolog (mais tu peux aussi le coder facilement en haskell avec la monade non-déterministe, où en Java avec la bibliothèque "Choco").
Tu veux juste trouver l'ensemble des solutions de ton système de contraintes (une liste de listes).
Éventuellement pour l'affichage, tu peux créer une forêt en prenant tous les racines différentes, puis en créant des arbres en fusionnant les listes qui ont la même racine…
[^] # Re: FTP
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 1.
J'adore faire des proz -k=10 ftp://ftp.example.com/pub/data/grosfichier.tgz et télécharger en 10 morceaux d'un coup à une vitesse d'enfer…
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 3.
Et aussi "Pourquoi voulait-on des DVD alors que le LaserDisc n'arrivait même pas à s'imposer". IPV6 est une solution au NAT, mais pas la solution à tous les problèmes…
Ensuite, je parle de l'API et de TCP/IP, les deux mon général !
Pour l'API, j'ai été convaincu en essayant moi même il y a longtemps, et j'ai été conforté dans mon opinion par http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/f(...) (si ton labo n'y est pas abonné, demande leur de le faire. C'est très bien comme magazine !)
Pour TCP/IP en soit, je te renvois sur Mobile IP par exemple (mais il existe d'autres solutions encore) : http://www.tcpipguide.com/free/t_MobileIPOverviewHistoryandM(...) et http://www.acm.org/crossroads/xrds7-2/mobileip.html
Tu vois, qu'un GC ralentisse mon kernel, je m'en tape complètement, comparé à toutes les pertes qu'on subit à ne pas implanter dès il y a 10 ans des technologies développées pour la mobilité et la distribution. Je pense que de simples statistiques sur le nombre de possesseurs de terminaux mobiles reliés à internet suffit à justifier le changement sans réfléchir plus que ça.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
La pile TCP/IP, faut s'en séparer…
Elle a fait son temps et n'est plus adaptée (API de merde, limitée aux connexions fixes… La recherche a continué depuis la préhistoire !)
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 4.
On évite les GC dans les kernels *écrits dans des langages où on a collé un GC sans réflechir aux applications*.
Un GC, c'est pas un .so que tu lies, et hop c'est fini !
Un GC, ça s'optimise, ça se configure aux petits oignons tant en même temps qu'on crée le langage (son compilateur ou son interprète) et aussi en même temps qu'on développe son application.
Alors, certes, ça fait pas plaisir aux gens qui ne jurent que par un seul langage, mais on ne construit pas toutes les voitures avec une seule et unique clef à pipe…
On citait les machines Lisp plus bas, mais il me semble aussi que Lisaac possède un GC et qu'il a servi à prototyper un OS potable…
Ontologia, si tu nous lis, ton avis sur ce journal m'intéresse beaucoup !
[^] # Re: Programmation noyau et ramasse-miettes
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Alors non, ce n'était pas dépourvu de bugs (car les dialectes de LISP étaient nombreux, et pas forcément aussi agréables que l'actuel Common Lisp), tout comme le rappelle Joe Marshall dans son très bon blog où il raconte des histoires de debuggage qu'il a vécues dans les années 80 [1].
Mais bon, les GC d'alors, c'était pas la panacée, hein. Ni les interprètes et compilateurs…
Sinon, tu dis : « De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ? », mais je ne vois pas le rapport avec le GC. Enfin, avec le typage dynamique, tu as un tag sur tes données, donc le GC sais différencier un entier d'une adresse, une chaîne de caractères d'un symbole… Ça se nettoie très bien tout ça.
Puis le typage dynamique n'impose pas qu'on ne type rien ! T'as pleins d'optimisations de typage local, d'évaluation partielles qu'on peut faire quand même…
[1] : http://funcall.blogspot.com/2009/03/talk-to-greenblatt.html cette série d'articles s'étale sur plusieurs mois.
[^] # Re: Interrogations...
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 4.
Quel rapport entre la vitesse et la gestion de la mémoire ?
>> En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ben, tu prends un GC temps-réel, et hop.
Ou alors un GC-hybride…
Choisir son GC fait aussi partie du développement d'une appli ou du choix d'un langage pour un problème donné…
>> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?
Ça dépend du langage. Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique). Inversement, Scheme se compile très bien…
Après, je te rappelle que les langages de scripts peuvent aussi se compiler, non seulement vers du code machine, mais aussi pour une VM…
# Pareil chez moi !
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal nvidia: this is not a method, this is provocation, you want me to go back to OpenBSD?. Évalué à 10.
C'est comme les clignotants de ma voiture !
Une fois ils marchent, une fois ils marchent plus, une fois ils marchent, une fois ils marchent plus…
# Durée
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Présentation sur "git bisect" au Linux Kongress 2009. Évalué à 2.
Car 75 pages de présentation, avec beaucoupbeaucoup de redondance (car je fais pas la différence entre deux pages dont seul le checksum du commit change), c'est pas mal indigeste !
Je rententerai de lire tout ça plus tard, car là, ça m'a vite achevé…
Quel a été, objectivement, l'accueil du public ?
[^] # Re: dbench
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 4.
Évidemment, ça dépend de l'industrie dans laquelle tu travailles (et pour avoir lu ton parcours, je me doute bien qu'à toi, ça te parait évident), mais c'est à mon avis une évidence et un critère de développement pour moins de la moité des programmeurs.
D'autant plus que ce sont des optimisations qui ne sont pas forcément algorithmiques et qui ne sont valides que dans certains langages bas-niveau…
[^] # Re: dbench
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 2.
Des générations entières de programmeurs Fortran à la belle époque te remercie d'avoir rappelé le lien fort entre optimisations et matériel, notamment taille des caches du processeur.
--
Axioplase, qui avait eu un TP sur l'optimisation de code fortran dans un cours orienté compilation et matériel ^^
# Simon ?
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Un exemple interessant de ce qui se fait au Venezuela. Évalué à 5.
C'est marrant !
Enfin, on a bien un porte avion Charles de Gaulle…
# Scrapbook
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au message Archivage de pages web. Évalué à 5.
Elle te permet même de ne sauver que les parties qui t'intéressent dans une page web…
La page : http://amb.vis.ne.jp/mozilla/scrapbook/index.php?lang=en
Une bonne grosse doc : http://amb.vis.ne.jp/mozilla/scrapbook/files/ScrapbookTutori(...)
[^] # Re: Très bon
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 3.
/me -> [ ]
[^] # Re: Mouais...
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 3.
main = let x = "etmonculcestdupoulet?" in putStrLn x
>> - Pas de notion d'objet (trop restrictif)
Objets et fermetures sont (grossièrement) isomorphes
>> - Essaie de réduire au maximum les effets de bord
Sur le papier.
En pratique, c'est pareil que partout ; simplement les utilisateurs vont préférer tout passer en paramètre plutôt que de stocker dans une variable (et en pratique, une monade State, c'est des effets de bords, sinon c'est pas super efficace)
>> - Permet de créer facilement des modules génériques et réutilisables
Comme partout. Quand t'es prêt à passer trois fois plus de temps à généraliser ton code que t'en as passé à le créer pour résoudre ton problème.
Bref, haskell (que j'adore), c'est pas la panacée, loin de là…
En revanche, c'est hype, ça donne le poil luisant et ça attire les financements anglo-saxons.
Encore une fois, le langage est un outil, et le langage X peut être super pour planter des clous, mais une bouse impossible pour tourner des vis.
Quand j'ai besoin de Haskell, je sors mon ghc, mais quand j'ai besoin de perl ou de postscript, je vais pas me faire chier avec haskell.
# La bonne nouvelle,
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal L'internationalisation des adresses internet. Évalué à 6.
[^] # Re: chezmoiçamarche
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au message ffmpeg incompréhensible... et pourtant RTFM ;-). Évalué à 2.
[^] # Re: Le petit cadena !!
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal L'internationalisation des adresses internet. Évalué à 5.
Et là, bonjour la sécurité (car bien sûr, tu crois que ta banque va te filer une clef publique la prochaine fois que tu iras au guichet et que les sites vont avoir une sécurité fiable ?)
Tu me files une pétition contre cette extension des noms, je signe de suite.