[Haskell-fr] Demande de revue de code

[Alp Mestanogullari]

Peut être devrais-tu attendre un peu d'avoir un chouilla plus de bouteille.
Pour l'instant je trouve que ca manque un peu de profondeur, que ca
s'inscrit dans les discussions qu'on voit partout où on lit beaucoup de
choses mais où il nous manque une vraie percée qui change notre
perspective. Quand cela arrive, tu le sais, tu peux alors tout expliquer
sans te poser de questions.

Pour le coup, l'auteur de hspec est un de mes coworkers, et il y a quelques
jours il a fait un mini talk à l'équipe où il parlait de TDD en haskell
précisément. Et oui il faut parler des libs centrales, certaines avec des
idées si intéressantes qu'elles ont fait l'objet de papers. Il faut parler
de pureté aussi, et aussi de comment ca se rattache aux types (plus un type
est abstrait, moins tu peux te reposer sur ses spécificités, moins il y a
d'implémentations possibles, plus il y a de chances que ton code soit
correct par construction, i.e juste par le fait qu'il typecheck, en gros la
façon dont Edward Kmett écrit ses libs -- et là tu ne fais plus du TDD même
si on a en général quand même des tests mais ils ont une place moins
importante).

En gros je pense que pour démontrer des choses sur tout ca en Haskell, il
faut avoir une bonne idée de la vue globale, et que du coup ca demande un
certain temps. Si tu te sens assez à l'aise avec tout ça fonce, mais sinon
j'ai peur que tu leur montres juste limite "une autre syntaxe" pour faire
des tests et qu'ils verront juse ça comme quelqu'un qui présente les trucs
cools de son langage. Alors que je pense vraiment que Haskell a d'énormes
longueurs d'avance sur pleins de sujets, et c'est parce qu'on pense tous ça
dans mon équipe que l'on s'est lancé dans un sacré défi :)
Le 3 avr. 2014 16:10, "Gautier DI FOLCO" <gautier.difolco at gmail.com> a
écrit :

> Le 3 avril 2014 11:00, Gautier DI FOLCO <gautier.difolco at gmail.com> a
> écrit :
>
>> Le 3 avril 2014 10:44, Sylvain Henry <hsyl20 at gmail.com> a écrit :
>>
>> Pour l'immutabilité, je montrerais les Lenses.
>>>
>>
>> Bonne idée
>>
>>
>>> Eviter d'utiliser des listes partout, notamment dans DayStmt, WeekStmt
>>> et MonthStmt, vu que le nombre de champs est fixe.
>>>
>>
>> Pas forcément, tu ne peux avoir que les relevés de 40 jours par exemple,
>> ce qui fais que tu as un mois et une semaine incomplète.
>>
>>
>>> Utiliser des lenses ici serait pas mal, surtout pour réécrire la
>>> fonction finale. Si je comprends bien elle fait une sélection et une
>>> réduction, donc parfait avec des lenses.
>>>
>>
>>
>>
>>> Je ne suis pas convaincu par le Monoid, une simple fonction de réduction
>>> suffirait :
>>> toStats :: [Temperature] -> Statistics
>>> Là c'est compliqué inutilement je trouve.
>>>
>>
>>  Du coup tu perds la notion de groupes de relevés (jour, semaines, mois)
>> et tu te retrouve à gérer le "conflit" °C/°F en même temps que le calcul
>> des stats.
>>
>
> si je donne l'impression de vous rembarrer pour le plaisir, il n'en est
> rien, je tente juste d'exposer mes choix et de comprendre ce qui ne va pas
> (et j'ai l'impression de mal m'exprimer).
> Le but c'est de montrer le TDD, il y a un aspect incrémental à mettre en
> valeur et arriver à quelque chose de complexe en partant de choses simple à
> mettre en valeur.
> Le coding dojo en lui même n'est pas spécifiquement fonctionnel (je pense
> qu'on sera 3/20 à coder dans un langage fonctionnel, au sens large), mon
> but est de dire : la POO ne résout pas tout proprement, regardez en FP.
> Je pense mes intentions sont plus claires.
>
> _______________________________________________
> Haskell-fr mailing list
> Haskell-fr at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-fr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-fr/attachments/20140403/99149417/attachment-0001.html>