PHWinfo - Afficher un message

05/09/2007, 09h57

Laurent vilday a écrit :
> ASM a écrit :
>
(snip)
>> - je continue à penser que ça n'évite pas les dérives et mésemplois du
>> code html/css/script-client/script-serveur,
>
>
>

Si peu. Dernièrement j'ai vu un truc à peu près comme ça :
>
> <div style="display:inline" id="link_23">Check my realisations</div>
> <script>
> $('link23').click(function() { window.location = itemGetter(23); };
> </script>

mmmouaaarffffffffffffff

(sniff)

Alors là, franchement, c'est un *grand* WTF !

>> - incompréhensible
>
>
> Meuh non lol.
>
> librairie PlotKit, Layout.js, ligne 344 à 350
>
> var collapse = PlotKit.Base.collapse;
> var map = PlotKit.Base.map;
> var getter = MochiKit.Base.itemgetter;
> var items = PlotKit.Base.items;
>
> var xvalues = map(parseFloat, map(getter(0), collapse(map(getter(1),
> items(this.datasets)))));
>
> Ou tu vois du compliqué toi ?

C'est pas compliqué, c'est LISPesque. Hein ? C'est pareil ? Mais non
c'est pas pareil !-)

> Petite explication de ce que ça fait. En gros ça transforme un tableau
> comme ceci :
>
> var datasets = [
> [1,23], [2,10], [3,40], [10,50],
> [0,17], [1,40], [2,20], [3,40], [4,10]
> ];
>
> en ceci : [0,1,2,3,4,5,6,7,8,9,10]
>
> Je me rend bien compte qu'une bête boucle " for " c'était pas assez
> hype, map(itemgetter()) ca le fait tellement plus

Plus sérieusement, là, c'est plus une question d'habitude. Un
programmeur habitué aux langages fonctionnels comprendra plus facilement
un truc à base de map/filter/reduce et autres opérations
'ensemblistes' que la version impérative à base de boucles. Le cas que
tu cites est limite pathologique (soit c'est un lispeur, soit le gars
vient de découvrir l'approche fonctionnelle), mais bien utilisé, c'est
AMHA souvent plus lisible que les idiomes purements impératifs.

(snip)

>> Néanmoins je ne peux que reconnaitre leur utilité dans le
>> développement d'un site *bien pensé*.
>> (je suis idiot mais pas au point de dire qu'elles sont à bannir)
>
>
> Tant pis, je vais tenir le rôle de l'idiot alors. Je comptais sur toi
> pourtant :p
>
> Les librairies *sont* à bannir car il n'existe que 2 cas de figure
>
> 1) vous connaissez javascript et par conséquent vous avez vos propres
> librairies adaptées à vos besoins et donc pas besoin de YUI, jQuery,
> Prototype et autre Ext
>
> 2) vous ne connaissez pas javascript et par conséquent il est recommandé
> de ne pas approcher ces librairies qui ne feront que vous embrouiller.
> On fait du javascript, pas du javascript à la ruby comme Prototype fait
> par exemple.
>
> Moralité, pas de librairies ! D'autant qu'il suffit de mettre le nez 2
> minutes dans n'importe lesquelles de ces librairies pour se demander si
> c'est un humain qu'à réellement pondu une telle sal... oops pardon une
> telle chose.

Amis extremistes, bonsoir.

Plus une bibliothèque (parlons français) est utilisée, plus il y a de
chances qu'elle soit débuggée (en tous cas pour les biblios open
source). En ce qui me concerne, je ne vois pas l'intérêt de réinventer
la roue carrée quand d'autres se sont déjà donné du mal à l'arrondir.

Accessoirement, avec ce genre de raisonnement, on ne développe qu'en
langage machine ou avec son propre langage et son propre
compilo/interpréteur (rayer la mention inutile).

Par ailleurs, dans un contexte professionnel, on développe rarement
"from scratch", et la plupart des frameworks/CMS/whatever existants
intègrent déjà une de ces bibliothèques. Dans ce cas, il serait inepte
de l'ignorer.

Bref, le purisme, c'est bien joli, mais c'est pas ça qui fait bouillir
la marmite. Ca ne veut pas dire qu'il faille mettre des décos de Noël
partout juste parce qu'on les a sous la main, ni qu'il faille se
contenter d'utiliser l'existant sans chercher à comprendre (et
éventuellement à contribuer), mais honnêtement, si je développe une
extension pour un CMS qui embarque déjà jQuery (au hasard), je ne voit
aucune raison de coder mes appels XHR à la mano (ce que je sais faire
aussi) quand je peux avoir le même résultat en une ligne de code.

05/09/2007, 09h57	#45
Bruno Desthuilliers Messages: n/a Hébergeur:	Re: divers problemes Ajax Laurent vilday a écrit : > ASM a écrit : > (snip) >> - je continue à penser que ça n'évite pas les dérives et mésemplois du >> code html/css/script-client/script-serveur, > > > Si peu. Dernièrement j'ai vu un truc à peu près comme ça : > > <div style="display:inline" id="link_23">Check my realisations</div> > <script> > $('link23').click(function() { window.location = itemGetter(23); }; > </script> mmmouaaarffffffffffffff (sniff) Alors là, franchement, c'est un grand WTF ! >> - incompréhensible > > > Meuh non lol. > > librairie PlotKit, Layout.js, ligne 344 à 350 > > var collapse = PlotKit.Base.collapse; > var map = PlotKit.Base.map; > var getter = MochiKit.Base.itemgetter; > var items = PlotKit.Base.items; > > var xvalues = map(parseFloat, map(getter(0), collapse(map(getter(1), > items(this.datasets))))); > > Ou tu vois du compliqué toi ? C'est pas compliqué, c'est LISPesque. Hein ? C'est pareil ? Mais non c'est pas pareil !-) > Petite explication de ce que ça fait. En gros ça transforme un tableau > comme ceci : > > var datasets = [ > [1,23], [2,10], [3,40], [10,50], > [0,17], [1,40], [2,20], [3,40], [4,10] > ]; > > en ceci : [0,1,2,3,4,5,6,7,8,9,10] > > Je me rend bien compte qu'une bête boucle " for " c'était pas assez > hype, map(itemgetter()) ca le fait tellement plus Plus sérieusement, là, c'est plus une question d'habitude. Un programmeur habitué aux langages fonctionnels comprendra plus facilement un truc à base de map/filter/reduce et autres opérations 'ensemblistes' que la version impérative à base de boucles. Le cas que tu cites est limite pathologique (soit c'est un lispeur, soit le gars vient de découvrir l'approche fonctionnelle), mais bien utilisé, c'est AMHA souvent plus lisible que les idiomes purements impératifs. (snip) >> Néanmoins je ne peux que reconnaitre leur utilité dans le >> développement d'un site bien pensé. >> (je suis idiot mais pas au point de dire qu'elles sont à bannir) > > > Tant pis, je vais tenir le rôle de l'idiot alors. Je comptais sur toi > pourtant :p > > Les librairies sont à bannir car il n'existe que 2 cas de figure > > 1) vous connaissez javascript et par conséquent vous avez vos propres > librairies adaptées à vos besoins et donc pas besoin de YUI, jQuery, > Prototype et autre Ext > > 2) vous ne connaissez pas javascript et par conséquent il est recommandé > de ne pas approcher ces librairies qui ne feront que vous embrouiller. > On fait du javascript, pas du javascript à la ruby comme Prototype fait > par exemple. > > Moralité, pas de librairies ! D'autant qu'il suffit de mettre le nez 2 > minutes dans n'importe lesquelles de ces librairies pour se demander si > c'est un humain qu'à réellement pondu une telle sal... oops pardon une > telle chose. Amis extremistes, bonsoir. Plus une bibliothèque (parlons français) est utilisée, plus il y a de chances qu'elle soit débuggée (en tous cas pour les biblios open source). En ce qui me concerne, je ne vois pas l'intérêt de réinventer la roue carrée quand d'autres se sont déjà donné du mal à l'arrondir. Accessoirement, avec ce genre de raisonnement, on ne développe qu'en langage machine ou avec son propre langage et son propre compilo/interpréteur (rayer la mention inutile). Par ailleurs, dans un contexte professionnel, on développe rarement "from scratch", et la plupart des frameworks/CMS/whatever existants intègrent déjà une de ces bibliothèques. Dans ce cas, il serait inepte de l'ignorer. Bref, le purisme, c'est bien joli, mais c'est pas ça qui fait bouillir la marmite. Ca ne veut pas dire qu'il faille mettre des décos de Noël partout juste parce qu'on les a sous la main, ni qu'il faille se contenter d'utiliser l'existant sans chercher à comprendre (et éventuellement à contribuer), mais honnêtement, si je développe une extension pour un CMS qui embarque déjà jQuery (au hasard), je ne voit aucune raison de coder mes appels XHR à la mano (ce que je sais faire aussi) quand je peux avoir le même résultat en une ligne de code.