En tant que débutant dans les langages fonctionnels (j'ai commencé à toucher Erlang, il y a quelques semaines - la première langue fonctionnelle que je pourrais obtenir mes mains).
J'ai commencé à écrire quelques petits algorithmes (tels que Après un certain temps, j'ai trouvé cette programmation fonctionnelle (supporter avec moi si ce que je parle n'a aucun sens du tout) encourage un design "haut en bas": c'est-à-dire quand je fais merge_sort, vous écrivez d'abord toute la fusion trier les étapes et les nommer en tant que fonctions individuelles d'assistance; Et ensuite, vous mettez en œuvre ces fonctions d'assistance un par un (et si vous avez besoin de diviser davantage ces fonctions d'assistance, faites-la dans la même approche).
Cela semble contredire un design OO un peu, dans lequel vous pouvez commencer à partir du bas pour construire la structure de données de base, puis assembler la structure de données et les algorithmes dans ce que vous voulez.
Merci pour des commentaires. Oui, je veux obtenir des conseils sur la façon de "penser dans la langue fonctionnelle" (tout comme "penser à Java", "penser à C ++"). gaucher_rotate_list , bubble_sort, fusion_sort etc.). Je me suis retrouvé souvent à perdre des décisions telles que "Devrais-je utiliser une liste d'assistance pour le stockage de résultats intermédiaire?" et "devrais-je créer une fonction d'assistance pour faire cela?"
5 Réponses :
Après un certain temps, j'ai trouvé que la programmation fonctionnelle [...] encourage un design "haut en bas".
Je ne suis pas sûr que ce soit une déclaration précise. J'ai récemment essayé de m'apprendre à moi-même une programmation fonctionnelle et j'ai découvert qu'un style de programmation "ascendant up" aident vraiment à moi. Pour utiliser votre exemple de trier de fusion:
- examine d'abord le cas de base. Comment triez-vous un tableau de 0/1 éléments?
- Suivant, regardez la base + 1, base + 2, ... étuis. Finalement, vous devriez voir un motif (division en sous-émérillants, résoudre les sous-émérules, combinaison de sous-performances) qui vous permet d'écrire un cas récursif général plutôt que d'atteindre le boîtier de base.
- La fractionnement en subproblèmes est facile, mais la combinaison des substructions est un peu plus difficile. Vous avez besoin d'un moyen de fusionner deux tableaux triés dans une matrice triée.
- Maintenant maintenant tout mis ensemble. Félicitations, vous venez d'écrire un type de fusion.
:)Je pourrais avoir une mauvaise utilisation du terme, mais cela ressemble à un design ascendant pour moi. La programmation fonctionnelle est différente de la programmation orientée objet, mais vous ne devriez pas avoir besoin d'abandonner totalement les techniques de conception existantes lorsqu'elle est commutée entre les deux.
Une réponse est que la programmation fonctionnelle consiste à programmer à l'aide de fonctions, car elles sont définies en mathématiques (en bref, des éléments sans effets secondaires qui plantent des valeurs du domaine à la codomaine). Traduire en réalité que la partie "Comment penser" est la partie agitant par la main qui est difficile à être exhaustive, mais j'étillonnerai certaines de mes pensées:
Le numéro un est associé au vague: "Code élégant". La liste des compréhensions peut présenter des équations très succinctes et mathématiques telles que des définitions des fonctions. Il suffit de regarder la sorte quick-trace implémentée avec des LCS. C'est ainsi que je définis l'élégance, succinct et rend tous les comportements clairs. Pas que Perl code-golf où vous êtes le plus souvent terres et cryptique.
numéro deux est quelque chose que j'utilise quotidiennement jour dans la programmation. Divisez le code en fonctions (méthodes, routines, etc.) de l'état actuel qui sont des calculs libres d'effet secondaire donnant des intrants à la prochaine action à prendre (même que la prochaine action à prendre est). Lorsque la valeur est renvoyée, donnez-la à une routine qui effectue l'action décrite, puis recommencez.
Dans ma tête I Diagramme Un processus Erlang en tant que graphique de la machine à états, où chaque sommet est un effet secondaire et une fonction dont la sortie est le bord pour choisi le sommet du sommet. Le paradigme de programmation fonctionnelle m'a appris à considérer les effets secondaires. Surtout à Erlang, étant donné que les effets secondaires comptent vraiment en concurrence et Erlang rend la concurrence très disponible.
De la même manière, certaines tribus isolées n'ont qu'un mot pour les nombres ci-dessus 3 ou aucun mot pour "mien" / "le vôtre". On sent que les langues populaires ne disposent pas de mots pour "cela entraînera un effet secondaire", mais la programmation fonctionnelle l'a fait. Il vous oblige à être conscient de tout le temps, et c'est une bonne chose.
Je me suis retrouvé souvent à perdre des décisions telles que "Devrais-je utiliser une liste d'assistance pour le stockage de résultats intermédiaire?" et "devrais-je créer une fonction d'assistance pour faire cela?"
Mes conseils pour cela: Lisez Le petit SCHEMER . Vous pouvez le suivre à Erlang. C'est un bon livre pour vous exercer une idée de cela.
Vous voulez des suggestions pour «Guide de programmation fonctionnelle pour les programmeurs de l'OOP»?
Mahin, mettez à jour la question. Merci pour votre réponse.