В каких областях использование F # может быть более подходящим, чем C #? [закрыто]

За последние несколько лет F # превратился в один из полностью поддерживаемых языков Microsoft, использующий множество идей, воплощенных в OCaml, ML и Haskell.

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

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

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

Я написал заявление, чтобы сбалансировать национальный график выработки электроэнергии для портфеля электростанций с торговой позицией для энергетической компании. Компоненты клиента и сервера были на C #, но механизм вычислений был написан на F #.

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

Единицы измерения Промышленность, в которой я работаю, изобилует единицами измерения. Уравнения, которые я реализовал (часто геометрического характера), касались единиц времени, мощности и энергии. Наличие системы типов, проверяющей правильность единиц входов и выходов функций, значительно экономит время, как с точки зрения тестирования, так и чтения / понимания кода. Это устраняет целый класс ошибок, которые были подвержены предыдущим системам.

Исследовательское программирование Работа с файлами сценариев и REPL (F # Interactive) позволила мне более эффективно исследовать пространство решений перед фиксацией реализации, чем более традиционный цикл редактирования / компиляции / запуска / тестирования. Для программиста это очень естественный способ выстроить понимание проблемы и напряженности дизайна в игре.

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

Взаимодействие Я определил интерфейс для механизма вычислений в C # и реализовал вычисления в F #. Затем механизм вычислений может быть внедрен в любой модуль C #, который должен был его использовать, без каких-либо опасений по поводу совместимости. Бесшовные. Программист C # никогда не должен знать.

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

Отсутствие ошибок. Функциональное программирование может показаться странным. Я могу работать над алгоритмом, изо всех сил пытаясь заставить код пройти проверку типов, но как только проверка типов будет удовлетворена, все будет работать. Он почти двоичный, либо не компилируется, ни корректен. Странные ошибки крайних случаев сведены к минимуму, функции рекурсии и более высокого порядка удаляют большой объем кода бухгалтерского учета, который вводит ошибки крайних случаев.

Параллелизм . Функциональная чистота результирующей реализации делает ее зрелой для использования присущего ей параллелизма при обработке векторов данных. Может быть, именно здесь я пойду дальше, когда выйдет .NET 4.

Во время моей стажировки в Microsoft Research я работал над некоторыми частями Visual Studio IntelliSense для F # (который сам написан на F #). У меня уже был некоторый опыт работы с IntelliSense из более ранних проектов C #, поэтому я думаю, что могу сравнить их.

• Расширение Visual Studio по-прежнему основано на COM, поэтому вам нужно иметь дело с объектами, которые не являются очень хорошими объектами .NET (и определенно не функционируют), но я не чувствую, что между C # и F # есть какое-либо существенное различие (оно работает гладко из F #)

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

Ранее я также работал над провайдером CodeDOM для F # (также написанным на F #). Я на самом деле делал первые эксперименты на C #, но затем преобразовал код в F #.

• Поставщику CodeDOM необходимо пройти через некоторую структуру, представленную с использованием объектов .NET, поэтому у вас не так много места для изобретения ваших собственных представлений данных (в этой области F # может предложить хорошие преимущества).

• Однако было много небольших функций F #, которые облегчили задачу. Поскольку вам нужно создать строку, я определил пользовательские операторы для построения строк (используя StringBuilder) и реализовал код, используя их и функции более высокого порядка (например, для форматирования списка объектов, разделенных с помощью указанной строки и т. Д.), Которые удалили много повторение (и утомительные foreachпетли).

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

Мы отправили первый в мире коммерческий продукт, написанный на F # ( F # для визуализации ) и второй ( F # для числовых ), а также первую коммерческую литературу по F # ( The F # .NET Journal ), а также написали и опубликовали единственную книгу о текущей версии. F # ( Visual F # 2010 для технических вычислений ).

Мы поставляли продукты в том же духе, написанном на C # (например, это ), но мы также имели большой опыт коммерческого использования OCaml. Мы с энтузиазмом относились к раннему внедрению F #, когда он еще был исследовательским прототипом в 2006 году, потому что мы осознали потенциал наличия достойного современного языка, похожего на OCaml, на промышленной платформе .NET, и, следовательно, мы стремились к его производству. Результат оказался невероятно успешным, и F # намного превзошел наши высокие ожидания.

Для нас F # имеет много различных преимуществ, и мы используем его для самых разных приложений. У нас есть сотни тысяч строк кода на F #. Теперь мы используем F # для всех наших LOB-приложений: наши транзакции по кредитным картам обрабатываются с использованием кода F #, уведомления о наших продуктах отправляются с использованием кода F #, наши подписки обрабатываются с использованием кода F #, наши учетные записи выполняются с использованием кода F # и так далее. Возможно, главной особенностью языка, которая приносит дивиденды, является сопоставление с образцом. Мы даже использовали F #, чтобы раскрасить синтаксис, чтобы выделить нашу последнюю книгу ...

Наша библиотека визуализации является крупным продавцом, и ее функциональные возможности сосредоточены на интерактивном F #, работающем в Visual Studio. Наша библиотека дополняет это возможностью создавать интерактивные 2D и 3D визуализации с минимальными усилиями (например, простоPlot([Function sin], (-6., 6.))построить синусоидальную волну). В частности, все проблемы с потоками полностью автоматизированы, поэтому пользователям не нужно беспокоиться о потоках пользовательского интерфейса и их распределении. Первоклассные функции и лень были чрезвычайно полезны при написании этой части библиотеки, и алгебраические типы данных широко использовались в других местах. Предсказуемая производительность также оказалась здесь полезной, когда наши клиенты столкнулись с ошибками производительности при тестировании хитов WPF и легко смогли переопределить соответствующий код в F # для повышения производительности в 10 000 раз. Из-за свободной формы GUI этого продукта конструктор GUI и C # не были бы полезны.

Большая часть нашей работы вращается вокруг численных методов, включая наши коммерческие библиотеки и книги. F # намного сильнее в этой области, чем C #, потому что он предлагает абстракции высокого уровня (например, функции высшего порядка) с минимальными потерями производительности. Нашим наиболее убедительным результатом в этом контексте стало создание простой, но обобщенной реализации QR-разложения по линейной алгебре, которая была в 20 раз короче, чем код Фортрана из эталонной реализации LAPACK, в 3 раза быстрее, чем настроенная производителем Intel Math. Библиотека ядра и более универсальная, потому что наш код может обрабатывать матрицы любого типа, даже символьные!

В настоящее время мы разрабатываем компоненты WPF / Silverlight в сочетании F # (для кишок) и C # (для прокладки), создавая приложения WPF, которые будут действовать в качестве интерактивных руководств для наших программных продуктов, и я пишу новую книгу, Multicore F #, в которой будет исчерпывающим руководством по параллельному программированию с общей памятью в .NET.

Последние 6 месяцев я работал над уровнем эмуляции Vim для Visual Studio 2010. Это бесплатный продукт со всем исходным кодом, который свободно доступен на github.

• GitHub: http://github.com/jaredpar/VsVim
• VsVim в галерее Visual Studio

Проект разделен на 3 библиотеки DLL, представляющие отдельный слой. Каждый слой имеет соответствующий модульный тест DLL.

1. Vim Двигатель: F #
2. WPF-слой для украшений и интеграции редактора: C #
3. Уровень интеграции Visual Studio: C #

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

Что мне больше всего нравится в F #, так это то, насколько он лаконичен. Движок Vim составляет основную часть логики, но он составляет всего 30% от общей базы кода.

Многие модульные тесты для компонентов F # Visual Studio написаны на F #. Они бегают за пределами VS, высмеивая различные биты Visual Studio. Возможность использовать анонимные объекты, которые реализуют интерфейсы, полезна вместо насмешливого фреймворка / инструмента. Я могу просто написать

let owpe : string list ref = ref []
let vsOutputWindowPane = 
    { new IVsOutputWindowPane with
        member this.Activate () = err(__LINE__)
        member this.Clear () = owpe := []; 0
        member this.FlushToTaskList () = VSConstants.S_OK
        member this.GetName(pbstrPaneName) = err(__LINE__)
        member this.Hide () = err(__LINE__)
        member this.OutputString(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
        member this.OutputStringThreadSafe(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
        member this.OutputTaskItemString(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText) = err(__LINE__)
        member this.OutputTaskItemStringEx(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText, pszLookupKwd) = err(__LINE__)
        member this.SetName(pszPaneName) = err(__LINE__)
    }            
DoSomethingThatNeedsA(vsOutputWindowPane)
assert( !owpe = expectedOutputStringList )

когда мне нужен экземпляр, например, IVsOutputWindowPaneдля перехода к другому компоненту, который будет в конечном итоге вызывать OutputStringи Clear, а затем проверить string list refобъект в конце теста, чтобы увидеть, был ли записан ожидаемый результат.

Мы написали собственный язык механизма правил, используя реализацию Lex-Yacc в F #

РЕДАКТИРОВАТЬ, чтобы включить комментарий комментарий

В C # не было реализации lex / yacc. (насколько нам было известно, и F # один был)

Было бы возможно, но прямая боль, чтобы построить анализ самостоятельно.

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

В настоящее время я работаю над компиляцией для языка программирования. Компилятор полностью написан на F #. Компилятор (кроме сборки lex и парсера с помощью lex / yacc) в основном построен как большая трансформация сложной древовидной структуры.

Как отмечалось другими, разграничение союзов и сопоставление с образцом делает работу с такого рода структурой данных намного проще, чем выкидывание кода в виртуальные методы «повсюду».

Я не делал никакой работы на F # до того, как начал работать над компилятором (у меня были, однако, бульдокомпиляторы в другом варианте OCaml, называемом MoscowML), и, как утверждает Джаред, из кода видно, какие части я делал в первую очередь, но в целом я нашел F # простым Чтобы снова научиться понимать FP после того, как кодирование, в основном, ОО, в течение десятилетия займет немного больше времени.

Работая с деревьями в стороне, я считаю возможность писать декларативный код главным преимуществом FP ​​(включая F #), имеющего код, описывающий алгоритм, который я пытаюсь реализовать в отличие от C #, описывающий, как я реализовал алгоритм, - огромное преимущество.

Не личный опыт, но вы можете слушать эпизод DNR (я думаю , что это одна ) , где они говорят с Microsoft фолка о F #. Они написали большую часть системы скоринга Xbox Live, что было далеко не тривиально, с использованием F #. Система масштабировалась на сотни машин, и они были ей очень довольны.

Я не знаю, находится ли он в производстве, но ИИ для «Путь Го» был написан на F #:

http://research.microsoft.com/en-us/events/techvista2010/demolist.aspx#ThePathofGo

Путь Го: исследовательская игра Microsoft для Xbox 360

В этой демонстрации демонстрируется игра для Xbox 360, основанная на игре Go, созданной в Microsoft Research Cambridge. Го является одной из самых известных настольных игр в Восточной Азии, она возникла в Китае 4000 лет назад. За обманчивой простотой игры скрывается большая сложность. Это займет всего несколько минут, чтобы освоить, но это займет всю жизнь, чтобы освоить. Хотя компьютеры превзошли человеческие навыки в Шахматах, внедрение конкурентоспособного ИИ для Го остается проблемой исследования. Игра основана на трех технологиях, разработанных в Microsoft Research Cambridge: AI, способный играть в Go, язык F # и TrueSkill ™, чтобы соответствовать онлайн-игрокам. AI реализован на F # и отвечает требованиям эффективной работы в .net compact framework на Xbox 360. Эта игра ставит вас в ряд потрясающих 3D сцен. Он был полностью разработан в управляемом коде с использованием среды XNA.

(Кто-то уже упоминал "TrueSkill".)