Le code C # simple / Java est extrêmement difficile à paralléLiser, multi-thread, etc. En conséquence, le code de C # / Java simple utilisera moins en moins de la puissance de traitement totale sur une boîte (parce que tout va maintenant être multicœur).
Résoudre ce problème en C # et Java n'est pas simple. La mutabilité et les effets secondaires sont essentiels pour obtenir des trucs réalisés dans C # et Java, mais c'est exactement ce qui rend la programmation multi-noyau et multi-threading si difficile.
Par conséquent, la programmation fonctionnelle va devenir de plus en plus importante.
Étant donné que le monde J2EE / RUBY s'échappera parmi de nombreuses approches fonctionnelles / multicœutaires (tout comme celle-ci pour tout ce qui est à peu près tout au reste), tandis que les personnes .NET utilisent tous F #, cette ligne de pensée suggère que f # sera énorme en deux ans.
Quel est le problème avec cette ligne de pensée? Pourquoi n'est-il pas évident que f # va être énorme?
(éditer) Larry O'Brien se cloque dans Ce blog post :" Langue-sage, à mon avis, il s'agit d'un ensemble d'exercices où C et C ++ brillent - au moins jusqu'à ce que des trucs multithreading. Les langues avec des idioms de traitement de la liste vont également bien faire au départ, mais peuvent avoir des problèmes de consommation de mémoire (en particulier des langues fonctionnelles). En fin de compte, je pense que la langue gérée de C-dérivée (Java et C #) a la voie la plus facile à faire de l'exercice. 9 et ensuite faire face à de graves lacunes avec l'exercice 10, où les problèmes de concurrence jouent le rôle majeur. À mon avis, la concurrence va devenir la question centrale du développement professionnel au cours de la prochaine demi-décennie, de sorte que ces lacunes sont donc très importantes. "
12 Réponses :
Personnellement, je pense que les langues fonctionnelles deviendront de plus en plus grand public (Heck F # lui-même témoigne de cela) mais ne gagnez probablement jamais statut de Lingua Franca comme C / C ++ / Java / C # / etc. avoir ou la volonté.
* C'est apparemment une vue quelque peu litigieuse, donc je vais l'élargir.
Dans une interface utilisateur multi-threadée, chaque événement d'assurance-chômage est envoyé de manière asynchrone et sur un thread de ses propres (la gestion réelle des threads est probablement plus sophistiquée que de tourner un nouveau, mais ce n'est pas vraiment germe à la discussion) .
Imaginez si c'était le cas et que vous rendant la fenêtre.
à l'étape 2, chaque élément Ceci est un convoi de verrouillage. Chaque thread de rendu verrouille, rendu, puis libérer; donc ils vont exécuter en série.
Maintenant, imaginez que vous traitez avec la saisie de l'utilisateur. Premièrement, les utilisateurs sont assez lents afin que les avantages soient inexistants, à moins que vous fassiez un travail considérable sur le fil d'interface utilisateur (un de plusieurs); Donc, je vais supposer que c'est le cas.
Tout ce que vous avez accompli consiste à changer de Le problème fondamental avec l'interface utilisateur est que vous traitez de nombreux à-un (ou un à plusieurs en fonction de la façon dont vous le regardez). Soit de nombreuses fenêtres, de nombreux éléments ou de nombreux "types d'entrée" qui affectent tout ce qui affecte une seule fenêtre / surface. Une sorte de synchronisation doit se produire et quand il ne contient aucun avantage, il suffit de détractions.
L'interface utilisateur n'est que "filetée unique unique" car la mise en œuvre de Microsoft donne tout l'affinité du fil.
Nommez un cadre UI qui n'est pas unique. Le fil affinité provoque simplement un comportement «Fail-Fast» et après avoir travaillé avec Swing / AWT pendant des années, c'est un comportement très bienvenu lorsque je saute sur terre .Net Terre.
Je suis d'accord avec 1-3. (1) signifie qu'il y aura un grand schisme, tout comme il y avait lorsque nous avons passé une programmation procédurale à OO. (2) signifie que cela prendra certaines personnes très longtemps pour déterminer qu'ils devraient écrire dans une voie de sécurité. (3) signifie qu'il y a une énorme opportunité commerciale. Si vous ne pensez pas que F # va être aussi gros que Java et C #, comment les programmeurs Java et C # vont-ils résoudre le problème multi-noyau / multi-threading?
Vous pouvez toujours faire un multi-filetage dans des langues impératives, son juste plus de travail. Ces projets qui ont absolument besoin, il faudra dans l'effort supplémentaire et tant que cet effort est inférieur à celui requis pour réécrire l'ensemble du projet dans le puits architeck-ed f #, ils sortent.
@Kevin Montrose Je pense que c'est une ligne de pensée intéressante. La question devient alors: étant donné le choix entre apprendre à la multiplication de la multiplication C # / Java et à apprendre un nouveau langage de programmation, que feront-ils les gens? Est-ce analogue à noter que s'il est possible de faire OO en Fortran, il est beaucoup plus facile de passer à C # / Java?
Microsoft a conçu leur UI pour être uniformisé pour une bonne raison - dans un environnement où les utilisateurs sont potentiellement capables de faire de nombreuses choses à la fois multithreading pourraient facilement faire même l'interface utilisateur la plus simple un cauchemar de concurrence!
@Kevin Juste parce que tout le cadre utile utile à ce jour est un seul fileté, cela ne signifie pas que cela continuera à être de cette façon. Il y a beaucoup de mérite pour que l'interface utilisateur soit multi-thread capable. Ce mérite deviendra de plus en plus évident et important car nous commençons à utiliser une architecture multicœur.
@Josph - Pouvez-vous penser à un avantage à l'interface utilisateur multi-threadé? Vous avez un utilisateur *, un écran, un clavier, une souris; Où est l'avantage de compliquer la pile? [* Ceci est par "bureau" / session / autre, pas par machine.]
L'entrée utilisateur @Kevin n'est pas la seule justification de la modification de l'interface utilisateur. C'est le plus grand avantage que je suis au courant. Avec un cadre d'interface utilisateur parléculé, vous pouvez théoriquement traiter avec plusieurs éléments d'interface utilisateur en parallèle au lieu de séquence. Imaginez combien de fenêtres plus rapides pourraient charger / décharger / réagir si vous pouviez diviser le rendu de l'interface utilisateur sur plusieurs cœurs. Il y a des avantages abondants.
@Jospheh vous devez verrouiller l'état de la fenêtre ou les éléments de rendu des risques "hors de synchronisation" (faute d'un meilleur terme). Cela se décourage dans un convoi de verrouillage, clairement et ne fonctionne donc pas mieux que la seule version filetée. Ainsi, en échange d'une API UI plus compliquée (mais multi-filedue), vous obtenez ... rien que le potentiel de heisenbugs?
@Kevin Il ne fait aucun doute dans mon esprit que cela présentera un modèle beaucoup plus compliqué que nous n'utilisons actuellement. Cependant, c'est certainement quelque chose qui va se passer. À mesure que le multi-noyau devient plus grand public, nous commencerons à voir un changement de paradigme dans la manière dont le travail de l'interface utilisateur sera effectué. Nous devrons abstraits ces concepts parrallèles pour pouvoir accomplir ces choses, mais ce sera comme tout le reste. La première abstraction sera compliquée et difficile à utiliser, les plus performantes seront meilleures et meilleures. Je suis tout à fait d'accord avec vous, cependant, cela sera compliqué au début.
@Jospheh La chose est, je ne pense pas qu'il y aura un quart de travail. Il n'y a aucun avantage à faire de l'UI multithreadé; Comme les gains de multithreading sont principalement accrus de ressources de la CPU. L'interface utilisateur ne doit pas, et ne devrait jamais nécessiter de beaucoup de temps dans la voie de la CPU, faisant une API compliquée qui permet à une UI PEG Un CPU à 100% est de bénéficier de non-celles-ci.
@Kevin alors je suis respectueusement en désaccord avec vous. Il existe de nombreux secteurs de l'industrie qui peuvent et profiteront énormément de permettre aux ressources de la CPU d'être mieux gérées en ce qui concerne les préoccupations de l'interface utilisateur. Même dans les applications de LOB typiques, il y a beaucoup de possibilités d'augmenter l'utilisation des ressources de la CPU. Votre affirmation selon laquelle l'interface utilisateur n'aurait jamais besoin de beaucoup de temps de la CPU peut s'appliquer à de larges applications LOB, mais n'est pas vraie dans beaucoup de cas. Dans les deux cas, la demande de telles choses conduira ce qui est construit. Je suppose que nous devrons attendre et voir ce qui se passe =)
@Joseph assez juste. Je voudrais personnellement voir un cadre d'interface utilisateur multi-fileté purement à court de curiosité professionnelle, donc si vous êtes assis sur une grande théorie unifiée de l'UI: "Happy piratage", :)
Y a-t-il des études qui montrent une écriture dans un style fonctionnel pour être intrinsèquement plus dure que l'impératif? Comment réduisez-vous le biais de tant de gens commençant par C ou Java ou similaires? Bien sûr, une fois que vous vous êtes forcé à penser en termes de poussoir des bits autour, cela pourrait être difficile - mais je ne vois pas pourquoi cela devrait être le moyen plus facile en général.
@Michaelgg Si nous commençions avec 100% de nouveaux développeurs qui pourraient importer. C'est pourquoi j'ai écrit la partie (...).
La programmation fonctionnelle est plus difficile à obtenir votre tête que la programmation impérative. F # est une langue plus difficile à bien des égards que c #. La plupart des "développeurs" ne comprennent pas les concepts de programmation fonctionnelle et ne peuvent même pas écrire un très bon code impératif en C #. Donc, quel espoir ont-ils eu d'écrire un bon code fonctionnel dans F #?
Et lorsque vous considérez que tout le monde sur l'équipe doit pouvoir comprendre, écrire, déboguer, corriger, etc. Le code dans la langue que vous choisissez, cela signifie que vous avez besoin d'une équipe très forte - Pas seulement une personne très forte - pour pouvoir utiliser F # car il est censé être utilisé. Et il n'y en a pas beaucoup d'entre eux.
Ajoutez dans le mélange le fait qu'il y a 8 ans de code C # / VB qui se trouvait qui est peu susceptible d'être migré, et qu'il est plus facile de créer des bibliothèques qui ressemblent à la BCL en C # / VB, car il est moins facile de Des trucs de fuites comme des tuples, etc. à travers des interfaces publiques, et je pense que F # aura du mal à gagner plus d'une utilisation par des équipes fortes sur de nouveaux projets internes.
Mais que fait le développeur C # / Java lorsqu'il utilise 10% de la puissance de traitement de la machine tandis que le programmateur F # utilise 80%? Comment le développeur C # / Java justifit-il son existence?
@uknown - L'industrie survivait depuis de nombreuses années avec beaucoup de dossiers de développeurs connaissant à peine leur cul de leur coude (juste vérifier TheDailyWTF.com). Les cadres moyens et seniors, en grande partie, n'ont aucune idée de l'un de ces problèmes et embauchent toujours des développeurs de la merde qui renverser le code de merde. Le fait que cela ne fonctionne que sur 10% du matériel est probablement le moindre des inquiétudes de quiconque.
De plus, de nombreuses choses ne sont pas facilement parallélisables, même si vous utilisez une langue fonctionnelle comme F #, et certaines choses n'ont pas besoin d'être parallélédiées.
Oui, f # ne décollera pas parce que, malheureusement, sa syntaxe n'est pas assez semblable à celle de CM :). Mais je suis sérieux - même si la langue de base f # est beaucoup plus simple que c #, c'est trop de changement pour trop de personnes. Cela restera probablement vrai, même si C ++ ajoute un soutien de Lambda. Alors, interopérabilité et ... capacité (est-ce une façon non offensive de le dire?) ... vont être les principales raisons pour lesquelles F # ne reçoit pas aussi populaire ...
La programmation fonctionnelle peut être plus difficile à apprendre que la programmation impérative, mais c'est Way plus facile à apprendre que la programmation moderne orientée objet.
@Jon - Je n'ai même pas mentionné une programmation orientée objet? Ma comparaison était entre le code fonctionnel et impératif. Le code impératif n'implique pas l'orientation objet; Vous pouvez écrire un code d'impératif procédural très heureux. Et mon point est qu'il y a un grand nombre de développeurs qui ne peuvent même pas écrire du code procédural de l'impératif, donc quel espoir aurait-il avec la programmation fonctionnelle? Je suis tout à fait sûr que les mêmes personnes lutteraient aussi avec l'orientation de l'objet.
@Greg heech: Vous parlez de C #. Vous ne pouvez pas aller loin dans C # sans toucher OOP.
@Jon - sans le toucher, non. Sans comprendre, oui. Je parierais que l'énorme majorité des développeurs C # ne comprennent pas vraiment les concepts orientés objet et ont encore moins une idée de la manière de les appliquer. Bien sûr, ils peuvent construire des objets simples, mais il y a une énorme différence entre pouvoir construire des objets simples et comprendre l'orientation de l'objet.
@Greg: Dans ce cas, ne pouvez-vous pas faire la même chose avec f #? Utilisez la programmation fonctionnelle (par exemple des pipelines) sans avoir à le comprendre?
le code C # simple / java est extrêmement difficile à paralléliser
pas si vous utilisez le Bibliothèque parallèle de tâche .
Si F # devient énorme dépend de la question de savoir si le coût / avantage est là, ce qui n'est pas du tout évident. Si .NET Les développeurs découvrent qu'ils peuvent écrire des programmes en 1/3 du temps en utilisant une approche fonctionnelle plutôt qu'une approche impérative (que je pense pourrait être vraie pour certains types de programmes), il devrait y avoir une certaine motivation pour l'adoption F # .
L'histoire de Paul Graham de son utilisation de LISP dans une société de démarrage est illustrant ce processus. Lisp leur a fourni un énorme avantage concurrentiel, mais Lisp n'a pas pris le monde, pas parce que ce n'était pas puissant, mais pour d'autres raisons, comme le manque de soutien de la bibliothèque. Que f # a accès au .NET Framework lui donne une chance de combattre.
Oui, mais vous voyez TPL, comme chaque autre solution C # / Java que j'ai vu à ce problème, oblige le développeur à (plus ou moins) explicitement parallélise le code. C'est extrêmement difficile à faire car il oblige que le développeur ait une compréhension profonde de ce qui se passe dans le matériel. Cela contraste fortement avec la programmation fonctionnelle où le développeur est multi-threading gratuitement.
Pour utiliser efficacement la bibliothèque de FX parallèle, il vous suffit de savoir comment écrire un bien pour la boucle. Vous voudrez peut-être consulter le podcast de 30 minutes sur la bibliothèque canal9.msdn.com/shows/ing+deep/...
De plus, il y a des chevauchements entre la bibliothèque de FX parallèle et les internes de F #: voir canal8.msdn. com / messages / 401
Je ne vois pas comment TPL nécessite de nombreuses connaissances sur le matériel / OS en tant que TPL résumant la parallélisation à un niveau supérieur: à celui des tâches (unités de travail) plutôt que threads . Vous ne traitez jamais de fil, juste des tâches. Si vous pouvez couper le travail que vous voulez faire dans plusieurs morceaux, vous avez terminé.
@ user128807: La parallélisation automatique est toujours très expérimentale, même pour Haskell, où la recherche de programmation fonctionnelle de pointe se produit.
Il n'y a pas vraiment de cas contre F #, mais vous devez comprendre le contexte de la situation que nous, en tant que développeurs, sont actuellement.
L'architecture multicœur est toujours à la petite enfance. La principale force motrice pour modifier les applications à une seule-fileté à une architecture de Parrellel va prendre du temps.
F # est très utile pour un certain nombre de raisons, le parellisme étant l'un d'entre eux, mais pas le seul. La programmation fonctionnelle est également extrêmement utile à des fins scientifiques. Ce sera énorme dans de nombreux secteurs.
Cependant, la façon dont vous vous rendez votre question, il semble que vous stipulez que f # combat déjà une bataille perdue, ce qui n'est certainement pas le cas. J'ai parlé à de nombreux scientifiques à ce jour qui utilisent des choses telles que Matlab et similaires, et beaucoup d'entre eux sont déjà au courant de F # et d'excité à ce sujet.
Droit sur. Tout le monde avec qui j'ai parlé avec qui a apporté le changement à F # pour un projet a été écrasement positif à ce sujet. J'ai encore entendu parler de quiconque apprenant F #, en l'utilisant, puis en retournant, dis, c #.
L'utilisation d'un nouveau langage de programmation est un risque calculé - vous pouvez obtenir une fonctionnalité plus intégrée et une sucre syntaxique plus intégrée, mais vous perdrez dans le soutien de la communauté, la capacité de recruter des programmeurs et de travailler autour des angles morts dans la langue.
Je ne cueille pas sur F # - chaque la décision de programmation est une équation de risque que vous devez travailler. Si les gens n'avaient pas pris ce risque sur C #, nous utiliserions tous toujours VB6 et C ++ maintenant. Même avec ces langues par rapport à leurs prédécesseurs. Vous devez décider
Deux ans plus tard, cela vraiment retourné. Les questions F # ont certaines des meilleures réponses sur Stackoverflow. La plupart du temps même par les membres de l'équipe Microsoft F #, véritablement experts, mais également par des utilisateurs de langue régulière.
Je suis en désaccord avec le principe que c # est difficile à paralléser. Ce n'est vraiment pas si vous savez ce que vous faites. De plus, LINQ parallèle rendra cela encore plus facile. Est-ce que je souhaite qu'il y ait une openmp pour C #? Bien sûr, mais les outils C # vous permettent de faire presque tout ce que vous voulez si vous êtes assez bon (et je sens que l'on ne doit même plus être aussi bon).
Je dirais la même chose à propos de Java ... Azul est très java lourd et ils ont construit leurs activités sur la prestation de la performance sur beaucoup de (centaines) de cœurs. Mes propres clients exécutent généralement leurs applications Java sur une 32 cœurs et elles vont très bien. Même si nous sommes fiers des outils, nous leur donnons que ce n'est pas la science de la fusée à l'échelle à plusieurs cœurs en Java ou C #.
Il y a quelques points à noter de la technologie
Quel est le problème avec cette ligne de pensée? Pourquoi n'est-il pas évident que f # va être énorme?
Vous supposez que les grandes masses réellement rédigèrent des programmes qui nécessitent un soutien multicœur - ou que les programmes gagneraient significatifs avantage d'être parallellisé. C'est une fausse hypothèse.
côté serveur, il y a encore moins besoin d'une langue parallèle. Le traitement du serveur Backend prend déjà suffisamment d'avantage de la prise en charge de multicœurs / processeurs par sa nature inhérente à la simultanée (le travail est divisé sur des clients via des threads et parmi les processus (par exemple un serveur d'applications, un serveur DB, un conteneur Web ..).
Je pense que c'est une question clé. Est-ce le cas que de nombreux programmes sont déjà assez rapides et il y a un avantage minime pour les rendre plus rapides (au-delà de l'accélération, ils recevront des noyaux simples plus rapides)? Il serait agréable de caractériser quel ensemble de programmes bénéficierait d'une vitesse et de ce qui ne serait pas. Votre commentaire sur la parallélisation latérale du serveur ne fait pas de distinction entre le grain grossier et le parallélisme de grain fin. De nombreuses applications latérales du serveur bénéficieront d'être multithreadées. Par exemple, toutes les trucs de traitement des transactions que je connais des avantages de la parallélisation.
Assemblage de liaison ensemble n'est pas trivial.
f # est lié au système de frappe .NET, ce qui est significativement plus restreint que, disons, PHP. C'est probablement juste là-haut avec Java dans le pays de la dactylographie forte. Cela rend la barrière d'entrée assez grande pour une personne qui ne connaît pas intimement les types .NET.
Le code d'affectation unique est difficile à écrire; La plupart des algorithmes utilisent le modèle de machine Turing Turing, qui permet de multiples affectations et un code d'affectation unique ne correspond pas vraiment à un bon modèle pour la façon dont nous pensons. Au moins, pour ceux d'entre nous qui écrivent le code de la machine de Turing pour gagner leur vie. Peut-être que c'est différent pour ceux d'entre nous qui écrivent du code machine Lambda ...
f # est attaché à Microsoft, qui produit la haine des genoux de nombreux geeks. Ils préfèrent utiliser Lisp ou schéma ou Haskell (ou autre). Bien que mono le soutient, il ne le supporte pas bien la dernière fois que j'ai essayé de travailler sur mono (c'était assez lent).
La plupart de notre code existant vit dans des bases de code séquentielles impératives et la plupart de nos applications sont orientées autour des opérations séquentielles impératives avec des effets secondaires.
Qui est tout à dire, les approches fonctionnelles pures ne modélisent pas soigneusement le monde réel, donc F # va devoir tailler une niche où elle gère facilement des problèmes du monde réel. Il ne peut pas être une langue générale, car elle ne résout pas proprement de problèmes d'usage général.
F # est une langue multi-paradigme. Vous n'êtes pas obligé d'utiliser des motifs fonctionnels où ils ne seront pas adaptés. En fait, même en utilisant uniquement ses fonctions orientées objet, vous pouvez écrire un code très concis et puissant.
perspective utile, même si elle est en désaccord avec. +1
Qu'est-ce qui ne va pas avec cette ligne de raisonnement, c'est qu'il suppose que tout fonctionnera comme prévu.
Il y a l'hypothèse qu'il sera plus facile d'écrire des programmes multithreads en F # que dans C #. Historiquement, les langues fonctionnelles n'ont pas fait tout cela bien en popularité et il y a probablement des raisons pour lesquelles. Par conséquent, s'il est généralement plus facile de multiplier la multiplication fonctionnelle que les langues impératives, il est généralement plus facile de trouver des personnes de programmer des langues impératives. Ces deux choses équilibrent d'une manière ou d'une autre, selon probablement sur le peuple et l'application. Il peut être plus facile d'écrire des applications multithreadées dans des langues fonctionnelles ou impératives. Il est beaucoup trop tôt pour dire.
Il y a l'hypothèse que les gens vont exiger une utilisation efficace de leurs ordinateurs de base 1k. Il y a toujours des applications qui peuvent prendre autant de pouvoir de processeur que possible, mais ce ne sont pas les applications les plus courantes. La plupart des applications Les personnes qui fonctionnent ne sont en aucune manière limitées par la puissance de la CPU, mais par des retards dans les E / S locaux, la mise en réseau et les utilisateurs. Cela peut changer, mais cela ne changera pas du tout rapidement.
En outre, il n'est pas clair que les transformateurs massivement multicoles sont la vague de l'avenir. Il peut y avoir un marché assez petit pour eux, alors les fabricants de puces produiront des copeaux plus petits au lieu de plus puissants, ou consacreront des ressources à d'autres choses que nous ne sommes pas clairs en ce moment.
Il y a l'hypothèse que f # va être le gagnant parmi les langues fonctionnelles. En tant que langue fonctionnelle du VS 2010, il a un avantage considérable. Cependant, la course n'a pas encore commencé, et il y a beaucoup de temps pour que les choses se produisent. Il peut s'avérer que f # .NET n'est pas une langue particulièrement bonne pour programmer des PC énormément parallèles et quelque chose d'autre peut venir. Il peut arriver que Microsoft et .net ne soient pas tout ce qui est important au moment où les processeurs de 64 cœurs sont régulièrement sur des ordinateurs portables bon marché. (Les changements comme ça ne sont pas tout ce qui est commun, mais ils ont tendance à se surprendre. Ils sont également plus susceptibles de se produire pendant les périodes de changement conceptuel, et une masse de déplacement en langues fonctionnelles serait admissible.)
sur l'hypothèse que F # continuera d'être la principale langue fonctionnelle Microsoft, que les langues de programmation Microsoft continueront à être dominantes, que la performance maximale des transformateurs de multicores massivement sera importante, que tous les arguments techniques ne seront pas submergé par l'inertie des affaires et que F # sera considérablement meilleur que c # et d'autres langues de ce type pour écrire massivement des applications multithreadées, et que vous avez raison. Cependant, c'est une grande partie d'hypothèses enfilées ensemble et liées par des raisons plausibles plutôt que par une logique rigide.
Vous semblez essayer de prédire l'avenir comme une combinaison des affaires de la prochaine année étendues par une ligne de raisonnement sur les problèmes techniques, et c'est extrêmement peu fiable.
Des hypothèses que vous énumérez dans la deuxième paragraphe dernier, le seul que je suis préoccupé par le fait est "F # sera considérablement meilleur que c #" à Multhreading. Certes, tous les développeurs C # Je parle de dire que Microsoft va leur donner une solution qui résout le problème. Je trouve difficile de croire cela, cependant, puisque tout en C # est mutable et a des effets secondaires, mais je ne suis peut-être pas au courant des dernières approches dans ce domaine.
C # ne ressemble pas à un langage multithreading particulièrement prometteur, mais je ne peux pas dire immédiatement à quel point F # sera meilleur. Les processeurs avec plus de quatre cœurs ne sont pas encore dans une utilisation populaire et nous n'avons pas l'expérience d'écrire des logiciels utilisateur multicœurs massivement multiples.
Si nous supposons que la bataille est entre c # et f #, je ne pense pas que f # gagnera plus de C # dans les 2 ans pour les raisons suivantes:
Les caractéristiques de F # que c # n'a pas de fonctionnalités ne sont pas manquantes. Par exemple, je pense que seq.map, seq.iter, seq.fold et amis sont excellents, mais je ne vois pas une majorité de développeurs qui passent de la part de ces constructions.
Les avantages de la performance des multicores ne sont pas pertinents pour la plupart des programmes existants, car peu de programmes sont liés à la CPU. Pour les programmes où la performance est vraiment importante (par exemple, les jeux vidéo), C ++ restera prédominant, au moins pour les 2 ans à venir. Ce n'est pas si difficile d'utiliser des threads en C ++, en supposant que l'on évite les effets secondaires (que vous pouvez décider de le faire même en C ++). N'est-ce pas ce que fait Google?
Pour F # Pour devenir vraiment grand, je pense que cela doit devenir l'une des principales langues utilisées dans l'enseignement, la façon dont Java a été. C'est en fait assez probable, voyant comment le monde académique aime les langues fonctionnelles. Devrait-il arriver, je ne pense pas que les effets deviendront visibles avant 5 ans.
Mais le monde académique compter sur les unes ... beaucoup! Le support de F # sur mono est faible, au mieux. À moins que Microsoft change de cours, je doute que c # ou f # envahira le monde adamique.
@Shinka: Microsoft a maintenant engagé des ressources au support f # sur mono.
Le seul "cas" contre celui-ci (s'il y a une telle chose) est que les développeurs professionnels les plus modernes utilisent différents outils (ainsi que différents types d'outils). F # apporte des outils uniques au jeu, et ceux d'entre nous qui les embrassent trouveront nos talents spécialisés respectifs utiles pour d'autres tâches de programmation - en particulier les tâches impliquant une analyse et une manipulation de collections de données importantes.
Qu'est-ce que j'ai vu de F # m'étonne vraiment. Chaque démo me laisse sourire parce que f # me frappe comme une édition avancée de ce que je me souviens de ce que je me souviens de "The bon vieux vieux jours" lorsque la programmation fonctionnelle était beaucoup plus commune (probablement plus
Si vous devez demander pourquoi alors il est clair que ce n'est pas évident.
@OCDECIO "Pourquoi n'est-il pas évident que f # va être énorme?" signifie: "Pourquoi n'est-ce pas évident pour tout le monde que f # va être énorme?" Évidemment, ce n'est pas évident. Je demande pourquoi ce n'est pas le cas.
Alors pourquoi est-il évident pour vous que f # va être énorme? Pourquoi f # en particulier? C'est à peine une langue parfaite pour la multithreading. Il repose toujours fortement sur les bibliothèques standard de la langue impérative .NET, après tout. Ce n'est pas une langue libre d'effet latéral. En supposant que les gens vont sauter aveuglément à des langues fonctionnelles uniquement à cause des possibilités de parallélisme, pourquoi pensez-vous que f # en particulier va être "celui"?
@jalf Ma réponse à votre question est dans l'op: tout le monde sur .net utilisera f #. Vous avez raison de dire que f # n'est pas parfait. Mais ce sera de loin l'option la plus prise en charge sur .NET. Par conséquent, presque tout le monde sur .net l'utilisera.
Depuis quand Java (je ne sais pas Re. C #) extrêmement difficile à paralceler? Je pense que cela en dit plus sur le questionneur que toute autre chose
Pour répondre à la question "Qu'est-ce qui ne va pas avec cette ligne de pensée?", Je ne peux pas dire avec certitude de C # mais de mon point de vue, la partie la plus incorrecte est la première phrase "Le code Java est extrêmement difficile à paralléliser, multi -Thread, etc. ". Ce n'est tout simplement pas vrai du tout.
@Brian agnew, ce n'est pas ~ facile ~ à paralléler à coup sûr. Les effets secondaires, l'état partagé, etc. peuvent tous lancer une clé à singe dans des applications multi-threadées et ne sont pas un problème trivial à faire correctement.
La question suivante est de savoir combien de problèmes avec la parallélisation de Java et C # ont à voir avec les installations de la langue et combien les difficultés ont à voir avec le fait que la programmation parallèle est intrinsèquement difficile. Si les langues fonctionnelles font mieux la programmation parallèle en général, c'est une chose. S'ils échangent un ensemble de problèmes pour un autre, c'est une chose différente.
Cette question n'est-elle pas tirée du titre, juste l'opposé des questions qui demandent "quel est le cas pour F #?" Ces questions ne sont-elles pas déjà posées à ces questions?
@unknown - La chose que le blog post oublie est que f # gère à peu près tout ce que c # fait avec une facilité similaire. Donc, au pire, F # est aussi encombrant que C # si vous devez faire une tâche spécifique - et, avec une inférence de type, elle est souvent encore plus facile. Quelques cas où c # fait mieux certains scénarios interopers spécifiques et quelques éléments de OO, comme des interfaces implicites.