Quelles sont les bonnes pratiques lorsque vous essayez d'enseigner la programmation déclarative à des programmeurs impératifs?

J'ai proposé de faire un peu de formation en F # dans mon entreprise et ils semblaient manifester un certain intérêt. Ce sont généralement des programmeurs VB6 et C # qui ne suivent pas la programmation avec trop de passion. Cela étant dit, je pense qu'il est plus facile d'écrire du code correct lorsque vous pensez à une question fonctionnelle, donc ils devraient certainement en tirer un avantage.

Quelqu'un peut-il offrir des conseils sur la façon dont je dois aborder cela?

Des idées

• Ne vous concentrez pas sur la syntaxe, mais plutôt sur la façon dont ce langage et les idiomes qu'il promeut peuvent être utilisés.
• Essayez de penser à des exemples qui sont pénibles à écrire de manière impérative mais qui se traduisent par un code élégant lorsqu'ils sont écrits de manière déclarative.

La programmation fonctionnelle est une bête étrange pour moi. J'ai appris F # et Haskell, écrit quelques programmes simples et j'adore les utiliser, mais je n'ai jamais eu le "flash de révélation" dont certains parlent. Mais lentement, j'ai remarqué que de plus en plus j'écrivais du code qui devait être immuable, divisant les tâches en fonctions plus petites et essayant d'utiliser beaucoup plus les délégués. C'est une chose qui, si vous l'aimez, se glisse dans votre travail parce que la valeur de ces techniques va de soi.

Maintenant, plus concrètement pour la formation: je trouve que deux concepts cliquent vraiment sur la programmation fonctionnelle comme style pour moi.

Premièrement, le style FP est basé sur la structure des données, pas sur la composition comme dans la POO. J'ai regardé quelque chose comme List en C # comme une astuce pour générer des listes de type sécurisé, quelque chose qui a composé le type (chaîne) dans l'autre type (liste). Après avoir appris la PF, je regarde les génériques plus comme des monades maintenant. La liste est une forme structurée que le code peut prendre et elle décore les chaînes.

Deuxièmement, et peut-être plus utile aux programmeurs C # / ASP, l'idée que FP fonctionne sur la récursivité et la répétition, tandis que la POO travaille sur la mutabilité et la boucle. J'ai tendance à considérer le cycle de vie de la page ASP comme une sorte de FP maintenant: chaque demande est traitée à partir de zéro tout au long du cycle de vie, de sorte que la page entière est, en fait, un grand programme à récurrence lente. Si vous pouvez affiner cette notion, vous aurez une meilleure idée de la façon dont un programme impératif peut être structuré autour de boucles de fonctions qui prennent des données, fonctionnent dessus et retournent de nouvelles données au lieu de modifier les anciennes.

L'obstacle le plus délicat, du moins pour moi, à surmonter avec cette approche est que le sentiment de naufrage que vous gaspillez des tonnes de ressources lorsque vous utilisez des objets mutables économiserait une tonne de mémoire. Dans GC, nous avons confiance, et j'ai juste dû apprendre à laisser tomber les problèmes de performances jusqu'à ce que j'aie vu le programme s'exécuter et vérifié s'il y en avait, et si oui, utiliser un profileur pour voir exactement où étaient les problèmes.

Je recommanderais:

• la présentation Taming Effects with Functional Programming par Simon Peyton-Jones
• le livre Real World Functional Programming: With Examples in F # and C # par Tomas Petricek et Jon Skeet

De nombreux langages de programmation impératifs (Ada, C / C ++, Turbo Pascal, FoxPro) ont la capacité de définir un pointeur vers des fonctions ou des littéraux de nom de procédure qui peuvent être évalués (et les procédures nommées d'après le littéral invoqué) au moment de l'exécution.

L'exemple traditionnel est qsort en C. Construisez sur cette notion que vous pouvez définir des algorithmes qui exécutent d' autres algorithmes sur des structures de données. Évidemment, ce n'est qu'une fraction de ce qu'est la programmation fonctionnelle. Mais j'ai trouvé que c'est un bon point de départ pour faire germer l'idée.

Une fois que cela s'enfonce, vous pouvez commencer à plonger dans d'autres choses (immuabilité, partage de rien, etc.)

Quelqu'un peut-il offrir des conseils sur la façon dont je dois aborder cela?

Sûr:

• Choisissez soigneusement vos exemples afin que votre code F # résout non seulement un problème avec élégance, mais aussi beaucoup plus élégamment que ce qui est possible avec C # / VB . La correspondance de modèles et l'inférence de type sont vos amis ici.

• Utilisez un exemple pour mettre en évidence les avantages d'une nouvelle fonctionnalité trouvée en F #, par exemple les flux de travail asynchrones, les modèles actifs.

• N'ayez pas peur de donner des exemples impurs en utilisant des structures de données mutables lorsque cela est approprié. F # est impur pour une raison.

• Ne présentez pas F # comme une panacée. Décrire les applications pour lesquelles F # n'est pas bien adapté ainsi que celles pour lesquelles il est beaucoup mieux adapté que les autres langages .NET.

• Indiquez des échantillons de jouets qu'ils peuvent étudier ainsi que des projets concrets réussis utilisant F # (Bing AdCenter, Halo 3, etc.).

• Expliquez tout en termes de comment F # peut les aider à résoudre les problèmes plus facilement. Évitez les débats religieux. Restez positif sur F #, pas négatif sur les autres langues. Munissez-les de faits et de preuves, mais laissez-les tirer leurs propres conclusions.