Duplicaté possible:
Pourquoi les langues fonctionnelles?J'ai commencé à programmer avec C / C ++, VB et éventuellement Python - toutes les langues impératives. J'ai suivi un cours sur les langages de programmation et j'ai appris ma première langue fonctionnelle - OCAML. C'était terrible.
Syntaxe et autres horreurs de côté, Ocaml a pris mon processus de pensée impératif et jeté la fenêtre. C'était frustrant. J'ai insisté sur le fait que tout ce qui pouvait être fait fonctionnellement pourrait également être fait impérativement. J'ai pensé à une programmation fonctionnelle en tant que programmation impérative sans membre (effets secondaires). En réponse à ma frustration, le seul avantage que mon professeur pourrait proposer était la capacité d'une FPL à parallementer des fonctions latérales sans effet.
Quoi qu'il en soit, suffisamment convaincu.
- Quels sont certains avantages que FPLS offre au-dessus des IPLS?
- Y a-t-il quelque chose qui peut facilement être fait dans une FPL qui ne peut pas facilement être fait dans une IPL?
- Y a-t-il des exemples réels de FPLS en cours d'utilisation ou servez-ils principalement d'exercices académiques? (Quand je dis du monde réel, je veux dire un projet qui s'appuie fortement sur l'aspect fonctionnel de la langue et ne contient pas de FPL dans un scénario où il n'appartient pas).
merci,
Advaître
3 Réponses :
Tout d'abord, presque toutes les langues en usage commun d'aujourd'hui est équivalente à un pouvoir expressif, que ce soit impératif ou fonctionnel, il est donc naturel de penser que tout ce que vous pouvez faire dans une langue fonctionnelle que vous pouvez probablement faire dans un impératif, car C'est probablement vrai.
L'une des choses vraiment belles sur les langues fonctionnelles est que leur structure permet l'application de l'inférence de type Hindley-Milner. C'est le système de type utilisé dans SML, OCAML et un groupe d'autres langues fonctionnelles. Il semble véritablement conduire à réduire les taux d'erreurs et est capable de vous économiser beaucoup de temps et d'énergie en trouvant des bogues au-dessus d'erreurs compilées.
L'argument automatique de la parallélisation est un peu surutilisé, notamment parce que la promesse n'a tout simplement pas été inventée. J'ai écrit du code explicitement parallèle dans les langages fonctionnelles et c'est plus agréable, imho, que de faire quelque chose de similaire en Java ou similaire.
Au moins au moins, je ne serais pas la première personne à prétendre que l'apprentissage d'une langue fonctionnelle vous fait un meilleur programmeur impératif! Cet inconfort que vous avez ressenti de votre processus de pensée «impératif» interrompu lors de l'utilisation de OCAML est en fait un très bon processus à parcourir. Cela vous propose des hypothèses de questions et vous empêche de rédiger un code de manière particulière simplement parce que vous l'avez toujours fait de cette façon.
En ce qui concerne l'utilisation du monde réel, vous aimerez peut-être examiner les débats du Utilisateurs commerciaux de la programmation fonctionnelle ateliers . Il existe également des projets très importants rédigés dans diverses langues fonctionnelles, bien que la plupart d'entre elles soient probablement des intérêts limités extérieurs aux petites petites communautés. Les prouves théorémiques Coq et Isabelle sont écrites dans OCAML et SML, respectivement.
Peu importe ce que vous faites, je persévérerais. J'ai passé beaucoup de temps à me frapper la tête contre ML avant de finir finalement. De nos jours, je ne suis pas sûr de me souvenir même de la façon dont Java ou C travaille C, parce que je n'ai pas eu de besoin d'eux depuis longtemps ... je viens d'utiliser ml!
Plus précisément, cette vidéo sur les utilisations de la programmation fonctionnelle sur Facebook est vraiment intéressante et plutôt convaincante: CUFP.org / Vidéos / Programmation fonctionnelle-Facebook
Le «pouvoir expressif» vous achète pas beaucoup. Vous pouvez vous rendre dans un bateau dans le monde entier ou utiliser un navire. Les deux ont le «pouvoir expressif» de vous emmener dans le monde entier. La plupart des gens ne prennent pas le bateau à rames.
@Rrainer, je ne suis pas sûr que si vous acceptiez avec moi ou non, mais c'était fondamentalement le point que je faisais. C'est trivialement vrai que vous pouvez mettre en œuvre la plupart des choses dans une langue raisonnable, il s'agit simplement de savoir si vous voudriez ou non cela compte.
Si vous avez un périphérique portable avec une petite mémoire, la langue «peut» implémenter des choses ne vous aidera pas si le temps d'exécution est plus grand que la mémoire disponible. Ou de l'application exige certains temps de réponse et la langage donné nécessite une heure d'exécution avec GC, il pourrait donc ne pas être possible de fournir ces temps de réponse. Il y a des cours de langues qui ne s'appliquent tout simplement pas alors. Il existe de nombreuses exigences dans les systèmes techniques qui ont peu à voir avec «pouvoir expressif» ou «désirant». Il y a des exigences non fonctionnelles difficiles qui influencent le choix d'un outil de mise en œuvre.
Oui, je conviens que c'est certainement vrai que les exigences non fonctionnelles devraient affecter le choix de la langue. Ma lecture de la question initiale a été beaucoup dans le cadre de la programmation quotidienne de matériel de produits standard, mais vous avez raison que la situation change quelque peu si ce n'est pas le cas. Cela dit, il y a des langues fonctionnelles bien adaptées à la programmation intégrée :)
+1 pour le système de type et "fait de vous un meilleur programmeur impératif". Bien que je prolongeais cela: cela vous fait un meilleur programmeur dans l'ensemble. Ni FP ni IP sont parfaits, mais plutôt différents et parfois complémentaires. Les deux brillent pour certaines applications et sucer pour les autres (par exemple: Pure FP ne joue pas bien d'état changeant, mais des envioments étatiques sont difficiles à paralléliser). Connaître les deux vous pouvez utiliser celui qui convient le mieux à votre problème actuel.
Quand on parvient enfin à faire taire son esprit d'entraînement imperaturé (MIS), FP devient plus facile et plus amusant que la propriété intellectuelle.
FP a tendance à être plus sûr, moins sujette de bogue, en raison de sa nature déclarative.
J'aime penser que la paralléling Code impératif double sa complexité (essayez-vous avec une application parallèle non triviale). IMO, FP réduit beaucoup l'écart, grâce au manque de syncronisation dans de nombreux cas.
citant Gian, apprendre FP Faites de vous un PROGRAMMUER IMPERATIF
Il n'y a pas que beaucoup de données réelles sur le point 2. C'est surtout une attente. Si vous regardez des ordinateurs dans des aéronefs, ils peuvent utiliser ADA, qui constitue une langue typiquement impérative. La quantité comparable de code écrite dans une langue FP (OCAML, HASKELLL, ...) qui fonctionne réellement sur un ordinateur de vol est probablement proche de zéro. Le seul endroit où les langues de la FP sont utilisées sont en vérification des programmes impératifs, toujours le code FP ne fonctionne pas sur un ordinateur de vol. Leur pourrait être des exceptions, mais presque tout le code de sécurité du monde réel n'est pas dans l'une de ces langues, vous vous attendez à être plus sûre ou moins sujette de bug.
Oui, il est vrai que la plupart des preuves du point 2 sont anecdotiques, mais il y a beaucoup de preuves anecdotiques pour cela! Et en toute justice, il n'y a pas beaucoup d'informations solides sur les techniques d'amélioration de la qualité du logiciel dans toute langue .
Il existe une grande quantité de littérature sur l'écriture de systèmes sûrs pour les aéronefs et les systèmes similaires. Si le logiciel FP est plus sûr ou moins de buggy, pourquoi n'est-il pas largement utilisé dans les logiciels critiques de mission (autres que pour la vérification)? Les systèmes d'exécution de ces langues sont-ils vérifiés?
@ Rainer-Joswig: Eh bien, ils ont utilisé Ada car il a été approuvé il y a 30 ans et personne ne veut s'inquiéter de changer les "règles". La vérification des performances et de l'exécution sont également un problème: les langues impératives font des compilateurs «plus faciles».
Principalement dupliquer: Stackoverflow.com/Questtions/36504/why-fonctions-languages
Juste un bref indice: une langue oo "empêche" d'accéder à toutes les variables, de les cacher derrière des abstractions. Cela vous aide à contrôler la complexité. De même, un FP vous empêche de manipuler l'état partagé et vous aide donc à écrire un code parallélizable, entre autres choses.
J'ai vu ce post et remarqué comment tout le monde a mentionné un parallélisme facile. Je n'étais pas vraiment satisfait d'aucune des réponses. Je pense que la parallélisation des appels de fonction standard ne fournira pas de bienfaits de performances pour permettre au programmeur de paralléliser explicitement son propre code (en particulier depuis que la surcharge de démarrage d'un nouveau thread pour exécuter une fonction potentiellement triviale est assez grande). Lorsque le choix est laissé au programmeur (quand / quoi parléliser), il / elle obtient le plus de liberté - les avantages de la performance du parallélisme sans béquilles d'un FPL.
Ne prenez pas cela dans le mauvais sens, mais je pense que vous devriez vous asseoir et essayer d'écrire un code multi-threading robuste dans une langue impérative pour au moins deux projets majeurs, de préférence en coopération avec quelques autres programmeurs et à la fois. et pressions de coûts. Je prédis que vous serez beaucoup moins intéressé par la liberté ... De plus: Il était une fois une fois, l'assemblée était la voie à suivre pour tirer le meilleur parti de la CPU. De nos jours, les programmeurs humains peuvent correspondre rarement à de bons compilateurs dans la planification d'instructions et l'optimisation des pipelines. Il en va de même avec la parallélisation, en particulier pour les langues FP.
Je peux certainement voir les maux de tête de l'écriture de code parallèle, mais je pense que l'imposition de restrictions sur un programmeur n'est pas la solution. D'autres paradigmes tels que la CNC détiennent beaucoup plus de promesses pour atténuer le parallélalisme Head-Explosions: logiciel.intel.com/en-us/articles/...
@Pontus: J'ai écrit un code multi-fileté robuste dans des styles fonctionnels et impératifs. La pureté peut être précieuse dans le contexte de la concurrence, mais c'est une catastrophe dans le contexte du parallélisme, certainement pas la panacée que vous décrivez. Si vous voulez des performances décentes, surtout pour les programmes parallèles exécutés sur des multicores, il est toujours essentiel de muter l'état partagé.
@Jon: Je n'essayais certainement pas de vendre FP comme une balle d'argent - nous savons tous qu'il n'y a pas d'autre chose. Si vous êtes assez intelligent, vous pouvez écrire et maintenir des programmes concurrents en toute sécurité dans n'importe quelle langue ou style. Et, accordé, l'État partagé sera un goulot d'étranglement. Mon argument est simplement qu'il est beaucoup plus facile pour les moins expérimentés de rester à l'écart des pratiques dangereuses en FP. Même pour l'expérience, sûrement, vous accepteriez que la minimisation des interactions partagées est nécessaire, avec d'autres interactions ajoutées uniquement après le profilage indique un besoin réel? Bien sûr, tous les problèmes ne sont pas facilement parallélédiques!
@Pontus: "Même pour l'expérience, vous accepteriez sûrement que la minimisation des interactions partagées est nécessaire, avec d'autres interactions ajoutées uniquement après le profilage indiquant un besoin réel?". Je ne peux pas accepter mais il y a un problème subtil ici: vous impliquez que l'introduction de la mutation est une optimisation prématurée qui doit être précédée de profilage, mais le contexte était une programmation parallèle qui est entièrement sur la performance et, par conséquent, vous devez déjà avoir optimiser.
Dans le contexte de la programmation parallèle, je n'utiliserais pas de structures de données purement fonctionnelles en premier lieu car elles sont si lentes. Par exemple, l'Idiomatic Haskell Quicksort est × 6 000 plus lentement qu'une simple solution F #. Même si vous pouviez obtenir une vitesse décente de paralléliser le haskell, ce serait une perte de temps complète car la performance absolue est si affreuse. La seule exception notable est lorsque vous écrivez dans une langue fonctionnelle avec une mise en œuvre qui s'attaque aux performances de la mutation. Haskell est particulièrement mauvais à cet égard.