En ce début d’été, je vous propose d’aller faire un tour du côté des langages et de leurs communautés. Les auteurs profitent du sujet pour aborder des problématiques plus vastes, telles que l’architecture ou la gestion de projet.
Pour commencer, parlons un peu d’architecture et d’écosystème. L’auteur nous explique "pourquoi il ne veut plus utiliser le framework rails". Il aborde la notion de simplicité ou comment avoir des fonctions qui ne font qu’une seule unique et chose. Ce qui n’a pas l’air d’être le cas avec rails…
Cependant, lâcher rails amène un autre problème : pour travailler avec le langage Ruby, il faut faire du Rails. Ce qui pose la question d’un monopole qui tue la diversité au sein de l’écosystème du langage.
http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html
Continuons avec un article sur la frustration qui règne autour de la prise en compte des bugs au sein de Clojure. Ce qui pose pas mal de questions : quelle est la qualité de suivi des bugs ? les personnes qui gèrent le projet sont-elles assez nombreuses ? ou encore la frustration n’est-elle pas due à un manque de communication ?
Bref, dans cet article, c’est de l’animation d’une communauté autour d’un projet open-source qu’on nous parle.
http://ashtonkemerling.com/blog/2016/06/11/my-increasing-frustration-with-clojure/
Parlons aussi du paysage des langages dans sa globalité. Ici, l’auteur, par le biais de son utilisation de clojure(script), nous dépeint sa vision de ce monde.
https://swannodette.github.io/2016/06/03/tools-for-thought
Comment enseigner la programmation ? Comment vulgariser pour ne transmettre que l’essentiel lorsque l’on débute ? Tant de questions que se pose l’auteur dans cet article.
https://dev.to/pbeekums/teach-writing-code-first
Partons maintenant du côté de haskell avec un retour sur l’utilisation du langage et les problèmes majeurs rencontrés :
https://chadaustin.me/2016/06/the-story-of-haskell-at-imvu/
Enfin, un peu de méthodologie avec la notion de « quand faut-il utiliser TDD ? ». La question essentielle soulevée par cet article est le coût induit par l’utilisation de TDD. L’auteur explique comment, dans certains cas, le coût s’avère plus élevé que le bénéfice apporté.
https://zeroturnaround.com/rebellabs/if-and-when-you-should-use-test-driven-development/