Что имеет место против F#? [закрытый]

Простой код C # / Java чрезвычайно сложно распараллелить

Нет, если вы используете Библиотеку параллельных задач .

Станет ли F # огромным, зависит от того, будет ли там соотношение затрат и выгод, что совсем не очевидно. Если разработчики .NET обнаруживают, что они могут писать некоторые программы за 1/3 времени, используя функциональный, а не императивный подход (что, я думаю, может быть верным для определенных типов программ), тогда должна быть определенная мотивация для принятия F #.

Рассказ Пола Грэма об использовании Lisp в стартапе является иллюстрацией этого процесса. Lisp предоставил им огромное конкурентное преимущество, но Lisp не захватил мир не потому, что он не был мощным, а по другим причинам, например, из-за отсутствия поддержки библиотеки. То, что F # имеет доступ к платформе .NET, дает ему шанс на победу.

http://www.paulgraham.com/avg. html

Я не согласен с предположением, что C # трудно распараллеливать. На самом деле это не так, если вы знаете, что делаете. Кроме того, параллельный linq сделает это еще проще. Хотел бы я, чтобы для C # был OpenMP? Конечно, но инструменты, которые предоставляет C #, позволяют делать почти все, что вы хотите, если вы достаточно хороши (и я чувствую, что никто больше не должен быть таким хорошим).

На самом деле нет никаких доводов против F #, но вы должны понять контекст ситуации, в которой мы, как разработчики, находимся в настоящее время.

Многоядерная архитектура все еще находится в зачаточном состоянии. Основная движущая сила для перехода от однопоточных приложений к параллельной архитектуре займет время.

F # очень полезен по ряду причин, и параллелизм является одной из них, но не единственной. Функциональное программирование также чрезвычайно полезно для научных целей. Это будет огромно во многих сферах.

Однако то, как вы формулируете свой вопрос, звучит так, как будто вы ' повторяя, что F # уже ведет проигрышную битву, что определенно не так. На сегодняшний день я разговаривал со многими учеными, которые используют такие вещи, как MatLab и тому подобное, и многие из них уже знают о F # и рады этому.

1. Задайте вопрос по программированию SO и укажите, что вы используете F #.
2. Задайте тот же вопрос и укажите, что вы используете C #.
3. Сравните ответы.

Использование романа язык программирования - это рассчитанный риск: вы можете получить больше встроенных функций и синтаксического сахара, но вы потеряете поддержку сообщества, возможность нанимать программистов и работу по обходу слепых пятен в языке.

Я не выбираю на F # - каждое решение языка программирования - это уравнение риска, которое вам необходимо решить. Если бы люди не пошли на такой риск в C #, мы бы все по-прежнему использовали VB6 и C ++. То же самое с этими языками по сравнению с их предшественниками. Вы должны решить для своего проекта , перевешивают ли преимущества риски.

Функциональное программирование труднее разобраться, чем императивное программирование. F # - более сложный язык во многих отношениях, чем C #. Большинство «разработчиков» не понимают концепций функционального программирования и даже не могут написать очень хороший императивный код на C #. Так что же они надеются написать хороший функциональный код на F #?

И если учесть, что каждый в команде должен уметь понимать, писать, отлаживать, исправлять и т.д. выбранный вами язык означает, что вам нужна очень сильная команда, а не просто очень сильный человек, чтобы иметь возможность использовать F # так, как он предназначен для использования. И их не так много.

Добавьте к этому тот факт, что существует 8-летний код C # / VB, который вряд ли будет перенесен, и что он '

1. Императивный код писать легче, чем функциональный. (По крайней мере, легче найти людей, которые могут сопоставить приемлемый императивный код с функциональным кодом)
2. Некоторые вещи по своей сути однопоточные (UI * - самый известный пример).
3. Существует много C # / C / C ++ кода уже существует, и несколько языков в одном проекте затрудняют управление указанным проектом.

Лично я думаю, что функциональные языки будут становиться все более популярными (черт возьми, сам F # является тому свидетельством), но, вероятно, никогда не получит lingua franca статус как C / C ++ / Java / C # / и т. д. иметь или будет.

* Это, по-видимому, несколько спорная точка зрения, поэтому я расширю ее.

В многопоточном пользовательском интерфейсе каждое событие пользовательского интерфейса отправляется асинхронно и в отдельном потоке (фактическое управление потоками, вероятно, более сложное, чем просто запуск нового, но это не совсем уместно для обсуждения).

Представьте себе, если бы это было так , и вы визуализируете окно.

1. Диспетчер окон просит вас нарисовать каждый элемент (ожидайте сообщения или вызова функции для каждого элемента).
2. Каждый элемент считывает свое состояние (неявно считывая состояние приложения)
3. Каждый элемент отрисовывается сам.

На этапе 2 каждый элемент ДОЛЖЕН блокировать состояние приложения (или его подмножество, которое влияет на отображение). В противном случае, в случае обновления состояния приложения, конечный результат визуализации окна может включать элементы, отражающие два разных состояния приложения.

Это конвой блокировок. Каждый поток рендеринга блокируется, рендерится и затем освобождается; поэтому они будут выполняться последовательно.

А теперь представьте, что вы имеете дело с вводом пользователя. Во-первых, пользователи работают довольно медленно, поэтому преимуществ не будет, если вы не проделаете значительную работу над (одним из многих) потоком пользовательского интерфейса; так что я собираюсь предположить, что дело обстоит именно так.

1. Диспетчер окон информирует ваше приложение о вводе пользователем (опять же, сообщение, вызов функции, что угодно).
2. Прочтите, что необходимо, из состояния приложения. (Здесь необходимы блокировки)
3. Заметно потратьте время на вычисление некоторых чисел.
4. Обновите состояние приложения. (Здесь также необходимы блокировки)

Все, что вы сделали, - это изменение с явного запуска рабочего потока на неявное выполнение этого; ценой потенциальных ошибок heisenbug и тупиковых ситуаций, если вы Освободитесь от блокировки своего состояния.

Фундаментальная проблема с API пользовательского интерфейса состоит в том, что вы имеете дело с отношениями «многие к одному» (или «один ко многим» в зависимости от того, как вы на это смотрите). Либо много окон, либо много элементов, либо много «типов ввода», которые влияют на одно окно / поверхность. Должна произойти какая-то синхронизация, а когда она имеет место, многопоточность больше не дает никаких преимуществ, только недостатки.

• Связывание сборок вместе нетривиально.

• F # привязан к системе типизации .NET, которая значительно более ограничена, чем, скажем, PHP. Это, вероятно, прямо там с Java в стране Strong Typing. Это делает входной барьер довольно высоким для тех, кто плохо знаком с типами .NET.

• Код с одним присваиванием сложно написать; большинство алгоритмов используют типичную модель машины Тьюринга, которая допускает множественные назначения, а код с одним назначением не совсем подходит для хорошей модели того, как мы мыслим. По крайней мере, для тех из нас, кто зарабатывает на жизнь написанием кода машины Тьюринга. Возможно, для тех из нас, кто пишет код Lambda Machine, все по-другому ...

• F # привязан к Microsoft, что вызывает у многих фанатов коленную ненависть. Они предпочли бы использовать Lisp, Scheme или Haskell (или что-то еще). Хотя моно поддерживает его, оно не поддерживает его, когда в прошлый раз я пытался работать с моно (это было довольно медленно).

• Большая часть нашего существующего кода живет в императивных, последовательных базах кода, и большинство наших приложений ориентированы на вокруг императивных, последовательных операций с побочными эффектами.

Это все, чтобы сказать, чисто функциональные подходы не моделируют аккуратно реальный мир, поэтому F # придется вырезать нишу, где он легко справляется с проблемами реального мира. Это не может быть языком общего назначения, потому что он не решает проблемы общего назначения.

Это все, чтобы сказать, чисто функциональные подходы не моделируют аккуратно реальный мир, поэтому F # придется занять нишу, в которой он легко справляется с проблемами реального мира. Это не может быть языком общего назначения, потому что он не решает проблемы общего назначения.

Это все, чтобы сказать, чисто функциональные подходы не моделируют аккуратно реальный мир, поэтому F # придется занять нишу, в которой он легко справляется с проблемами реального мира. Это не может быть языком общего назначения, потому что он не решает проблемы общего назначения.

Что не так в таком образе мышления? Почему не очевидно, что F # станет огромным?

Вы предполагаете, что большие массы действительно пишут программы, которые нуждаются в поддержке многоядерности - или программы получат значительную выгоду от распараллеливания. Это ложное предположение.

На стороне сервера необходимость в параллельном языке еще меньше. Обработка внутреннего сервера уже использует достаточно преимуществ поддержки многоядерности / процессора, поскольку по своей природе является параллельной (работа распределяется между клиентами через потоки и между процессами (например, один сервер приложений, один сервер базы данных, один веб-контейнер ...).

Единственный «аргумент» против этого (если он существует) состоит в том, что большинство современных профессиональных разработчиков используют разные инструменты (а также разные типы инструментов). F # привносит в игру некоторые уникальные инструменты, и те из нас, кто их использует, найдут наши соответствующие специализированные таланты полезными для других задач программирования - особенно тех, которые включают анализ и управление большими коллекциями данных.

Что я видел F # меня поистине поражает. Каждая демонстрация вызывает у меня улыбку, потому что F # кажется мне продвинутым вариантом того, что я помню из « старых добрых дней», когда функциональное программирование было гораздо более распространенным (вероятно, более «старым» , чем «хорошо» , конечно, но это ностальгия).

Если предположить, что битва идет между C # и F #, я не думаю, что F # победит C # в течение 2 лет по следующим причинам:

1. Возможности F #, которых нет в C # это не функции, которые люди упускали. Например, я считаю, что Seq.map, Seq.iter, Seq.fold и другие - это здорово, но я не вижу, чтобы большинство разработчиков переключались с foreach на эти конструкции.

2. Повышение производительности многоядерных процессоров для большинства не имеет значения. существующих программ, так как только несколько программ связаны с процессором. Для тех программ, где действительно важна производительность (например, видеоигры), C ++ останется преобладающим, по крайней мере, в ближайшие 2 года. Не так уж и сложно использовать потоки в C ++, если предполагается, что они избегают побочных эффектов (которые вы можете решить даже в C ++). Разве Это то, что делает Google?

Я думаю, что для того, чтобы F # стал действительно популярным, он должен стать одним из основных языков, используемых в обучении, как это было до Java. На самом деле это вполне вероятно, учитывая, насколько академический мир любит функциональные языки. Если это произойдет, я не думаю, что последствия станут заметны раньше, чем через 5 лет.

What is wrong with this line of reasoning is that it assumes that everything will work out as planned.

There is the assumption that it will be easier to write multithreaded programs in F# than in C#. Historically, functional languages have not done all that well in popularity, and there's probably reasons why. Therefore, while it is generally easier to multithread functional than imperative languages, it's generally been easier to find people to program in imperative languages. These two things balance out somehow, depending probably on the people and the app. It may or may not be easier in general to write multithreaded applications in functional or imperative languages. It's far too early to tell.

There's the assumption that people are going to demand efficient use of their 1K-core computers. There are always applications that can take as much CPU power as they can find, but these aren't the most common applications. Most applications people run are not in any way limited by CPU power nowadays, but by delays in local I/O, networking, and users. This may change, but it won't change at all quickly.

Also, it isn't clear that massively multicore processors are the wave of the future. There may be a fairly small market for them, so chip manufacturers will produce smaller chips instead of more powerful, or will devote resources to other things that we aren't clear about right now.

There's the assumption that F# is going to be the winner among functional languages. As the VS 2010 functional language, it does have a considerable advantage. However, the race hasn't really started yet, and there's plenty of time for things to happen. It may turn out that F#.NET isn't a particularly good language to program massively parallel PCs, and something else may come about. It may happen that Microsoft and .NET won't be all that important by the time 64-core processors routinely come on cheap laptops. (Shifts like that aren't all that common, but they tend to come by surprise. They also are more likely to happen during times of conceptual change, and a mass move to functional languages would qualify.)

On the assumption that F# will continue to be the primary Microsoft functional language, that Microsoft programming languages will continue to be dominant, that getting maximum performance out of massively multicore processors will be important, that all the technical arguments won't be swamped by business inertia, and that F# will be considerably better than C# and other such languages at writing massively multithreaded applications, and that you're right. However, that's a whole lot of assumptions strung together and linked by plausible reasons rather than rigid logic.

You seem to be trying to predict the future as a combination of next year's stuff extended by one line of reasoning about technical issues, and that's extremely unreliable.

Следует отметить несколько моментов технология

• Лучшее техническое решение не всегда является самым популярным или наиболее часто используемым. (И я не знаю, хорош ли F #). Я бы сказал, что SQL - это наиболее используемый, наиболее востребованный работодателями язык программирования, и в моей книге это не самый приятный, крутой, быстрый, дружелюбный и забавный язык. Если лучшее техническое решение всегда «побеждало», как объяснить qwerty-клавиатуры? И если вы когда-нибудь читали «проект» для процессоров x86 / x64 ...;)
• Azul с 864-ядерными серверами использует исключительно Java, и в будущем будет наблюдаться тенденция к увеличению размера серверов.