De nombreuses autres réponses ont mis l'accent sur la performance (parallélisme) du côté de la programmation fonctionnelle, qui, je crois, est très important. Cependant, vous n'avez poser des questions sur la productivité, comme dans, votre programme peut-il la même chose plus vite dans un paradigme fonctionnel que dans un impératif de paradigme.
Je trouve (par expérience personnelle) que les émissions en F# correspond à la façon dont je pense que mieux, et il est donc plus facile. Je pense que c'est la plus grande différence. J'ai programmé dans les deux F# et C#, et il y a beaucoup moins de "lutte contre la langue" en F#, que j'aime. Vous n'avez pas à penser aux détails en F#. Voici quelques exemples de ce que j'ai trouvé, j'ai vraiment apprécier.
Par exemple, même si le F# est statiquement typé (tous les types sont résolus au moment de la compilation), l'inférence de type chiffres de quel type que vous avez, de sorte que vous n'avez pas à le dire. Et si il ne peut pas comprendre, c'rend automatiquement votre fonction/classe/quel que soit générique. Vous n'avez donc jamais à écrire le générique que ce soit, tout est automatique. Je trouve cela signifie que je vais passer plus de temps à réfléchir au problème et de moins en moins comment la mettre en œuvre. En fait, chaque fois que je reviens à C#, je trouve que je manque vraiment cette inférence de type, vous n'avez jamais à comprendre comment distraire, il est tant que vous n'avez pas besoin de faire plus.
Aussi en F#, au lieu d'écrire des boucles, vous pouvez appeler les fonctions. C'est un changement subtil, mais significative, parce que vous n'avez pas à penser à propos de la boucle de construire plus. Pour exemple, voici un morceau de code qui permettrait de passer et de correspondre à quelque chose (je ne me souviens pas quoi, c'est à partir d'un projet Euler puzzle):
let matchingFactors =
factors
|> Seq.filter (fun x -> largestPalindrome % x = 0)
|> Seq.map (fun x -> (x, largestPalindrome / x))
Je me rends compte que faire un filtre puis une carte (c'est une conversion de chaque élément) en C# serait assez simple, mais vous devez penser à un niveau inférieur. En particulier, vous devriez écrire la boucle elle-même, et vous avez votre propre explicite si la déclaration, et ce genre de choses. Depuis qu'il a appris F#, j'ai réalisé que j'ai trouvé plus facile à code dans la manière fonctionnelle, où si vous voulez filtrer, vous écrivez "filtre", et si vous voulez la carte, vous écrivez "la carte", au lieu de la mise en œuvre de chacun des détails.
J'aime aussi l' |> opérateur, qui, je pense, sépare F# à partir de ocaml, et peut-être d'autres langages fonctionnels. C'est le tube de l'opérateur, il vous permet de "pipe" de la sortie d'une expression dans l'entrée d'une autre expression. Elle rend le code de suivre la façon dont je pense de plus. Comme dans l'extrait de code ci-dessus, en disant: "prenez les facteurs de la séquence, le filtre, puis la carte". C'est d'un très haut niveau de réflexion, que vous n'en faites pas un language de programmation impératif, parce que vous êtes tellement occupé à l'écriture de la boucle et si les déclarations. C'est la seule chose qui me manque le plus quand je vais dans une autre langue.
Donc, juste en général, même si je programme en C# et F#, je le trouve plus facile à utiliser F# parce que vous pouvez penser à un niveau plus élevé. Je dirais que, parce que les plus petits détails sont retirés de la programmation fonctionnelle (en F#, au moins), que je suis plus productif.
Edit: j'ai vu dans un des commentaires que vous avez demandé un exemple de "l'état" dans un langage de programmation fonctionnel. F# peut être écrite de manière impérative, voici donc un exemple concret de la façon dont vous pouvez avoir mutable état en F#:
let mutable x = 5
for i in 1..10 do
x <- x + i
