Re: Programmation fonctionnelle et vulgarisation (etait : Re: import)

On 31 jan, 22:33, Mihamina Rakotomandimby <miham...@rktmb.org> wrote:
> Bruno Desthuilliers wrote:
> >> D'après moi, la problématique quotidienne réelle est que les
> >> applications (je m'en tiens à l'open source) deviennent de jour en
> >> jour plus pointues et lourdes.
> > Disons que les utilisateurs demande des fonctionnalités de plus en plus
> > complexes sans avoir la moindre idée du degré de complexité auquel on
> > est déjà rendu.
>
> Oui mais... au fil du temps le code s'alourdi quand meme
> irremediablement. L'entropie, qu'ils appellent ça, je crois.

L'entropie étant la tendance des systèmes vers la désorganisation. Il
y a aussi une tendance vers l'organisation, heureusement !-)

Plus sérieusement: les *systèmes* deviennent plus complexes, et
nécessitent donc de plus en plus des approches permettant de gérer
cette complexité. Ca n'implique pas forcément que le code d'*un*
élément donné du système devienne plus "lourd" ou compliqué. A vrai
dire, ça tends même parfois vers le contraire - des éléments simples
agencés de façon complexe, au lieu d'éléments compliqués agencés de
façon simpliste. Ca n'élimine bien sûr pas la complexité, mais ça la
déplace à un autre niveau.

> >> Pour diverses raisons dont le fait qu'on embauche des grosses tetes
> >> pour écrire le code.
> > Je pense que tu inverses un peu la cause et l'effet.
>
> Ben... Si on embauche un docteur en informatique pour développer, ça ne
> m'étonnerais pas que le code soit... de ce niveau.

J'ai peu d'expérience avec les docteurs en informatique (et je ne
considère pas nécessairement la possession d'un bout de papier comme
un gage de compétence), mais les bouts de code les plus lourds et
compliqués que j'ai eu à contempler à ce jour n'étaient certes pas
l'oeuvre de docteurs en informatique. Il s'est généralement avéré
qu'on pouvait faire la même chose de façon plus efficace, plus robuste
et plus correcte (au sens de 'renvoie le résultat correct') avec 2 à 4
fois moins de code.

> >> Pour suivre ce mouvement, il est de bonne guerre de sensibiliser le
> > le ??? manque un bout de phrase, là !-)
>
> Bref, je voulais dire il est de bonne guerre de "tirer vers le haut" le
> niveau.
> Maintenant, je n'ai aucune idée de comment faire. J'ai juste comme idée
> que les auteurs de certain bouquin ont supposé que leur méthode était la
> bonne.

Heu... Excuse moi, mais je doute qu'appeler  un ramasse-miette
"Glaneur de cellules", utiliser indifférement les termes "programme"
et "application" pour désigner une fonction, ou utiliser des
identifiants comme f, g et h pour les fonctions et a, b, c, x, y, z
pour les variables aide en quoi que ce soit à relever le niveau. Ce
n'est pas un problème de fond, mais de forme: en utilisant
(arbitrairement qui plus est) un "langage" trop différent de celui de
ton auditoir, tu forces ce dernier à des efforts de traduction tout à
fait inutiles, ce qui se fait bien sûr au détriment de la
compréhension. Accessoirement, ça n'a rien de nouveau, c'est une règle
de base la communication.


> >> Euh... oui, peut-etre.
> >> Mais je ne retrouve plus les references, mais il me semble qu'en
> >> Python l'introduction des declaration/utilisation partielles des
> >> fonctions fut accidentel.
> > Tu parles de l'application partielle ? (via, depuis la 2.5, l'objet
> > partial) Si oui, ce n'est pas vraiment accidentel, non. Sinon, merci de
> > préciser de quoi tu parles.
>
> Oui, c'est ça. J'ai lu un post sur une ML en anglais qui disait que
> c'était accidentel.

Dans la mesure où d'une part il existe depuis longtemps diverses
"recettes" pour obtenir ce résultat - soit par des fermetures
lexicales (comme dans Django), soit par des classes (comme c'est
finalement le cas dans Python 2.5), et où d'autre part l'introduction
du type 'partial' dans la bibliothèque standard a suivi le processus
classique (pep, discussion etc), j'avoue avoir du mal à voir comment
ça pourrait être un "accident" ???

> Mais ça ne veut pas la peine qu'on s'y attarde.

oops, pardon.

> >>> Les bouquins sur PHP s'adressent majoritairement à des non-programmeurs
> >> Mais un mec qui s'interesse à se documenter sur un langage de
> >> programmation est un programmeur!
> > Non.
>
> Ok, d'accord!

Bon ok, j'ai pas beaucoup argumenté, là.  Je vais au moins te mettre
sur la piste:

Marc est graphiste, devenu intégrateur un peu par hasard, et comme il
en a marre des bouts de code PHP ou Javascript foireux qu'il trouve
sur le net et qui soient lui pête à la gueule soit ne font jamais
exactement ce qu'il voudrais, et qu'il ne comprend pas bien les
explications qu'on lui donne sur divers forums, il décide de se donner
les moyens de gérer au moins ce genre de problème.  Jean-Pierre, un
jeune lecteur du Var, aimerait devenir programmeur. Comme il utilise
beaucoup internet et qu'il a déjà appris le html en faisant son propre
site web, il se tourne évidemment vers le langage le plus répandu dans
ce domaine. Les deux font connaissance en allant à la bibliothèque du
coin acheter un bouquin sur PHP. Lequel des deux est à ce moment là un
programmeur ?