У яких районах використання 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 × коротша, ніж код Fortran від опорної реалізації LAPACK, на 3 × швидше, ніж налаштована виробником Intel Math Бібліотека ядра та більш загальна, тому що наш код може обробляти матриці будь-якого типу, навіть символічні матриці!

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

Останні 6 або більше місяців я працював над емуляційним шаром Vim для Visual Studio 2010. Це безкоштовний продукт із усім джерелом, яке є у вільному доступі на github

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

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

1. Vim Engine: 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 #

EDIT, щоб включити відповідь на коментар

У C # не було реалізовано lex / yacc. (наскільки нам було відомо, і F # one був)

Можна було б, але відверто боліти, щоб власноруч розібратись.

У цій темі показано деякі інші пропозиції, такі як зовнішні бібліотеки, але наш головний архітектор - це стара функціональна мова, тому вибір для використання F # не сприймав.

Зараз я працюю над компіляцією для мови програмування. Компілятор повністю написаний на F #. Компілятор (крім побудови lex та парсера за допомогою lex / yacc) в основному будується як безліч перетворень складної дерева, як структура.

Як зазначають інші, дискримінація об'єднань та узгодження зразків спрощує роботу з такою структурою даних набагато простіше, ніж скидання коду у віртуальні методи "повсюдно"

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

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

Не особистий досвід, але ви можете прослухати епізод DNR (я думаю, це саме цей ), де вони розмовляють з Microsoft folk про F #. Вони написали більшість системи балів Xbox Live, яка була далеко не тривіальною, використовуючи F #. Система широко масштабувалась через сотні машин, і вони були дуже задоволені нею.

Я не знаю, чи він у виробництві, але AI для "Шлях іти" був написаний у F #:

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

Шлях іти: Дослідницька гра Microsoft для Xbox 360

У цій демонстраційній виставці представлена ​​гра Xbox 360, заснована на грі Go, виготовленій власною компанією Microsoft Research Cambridge. Go - одна з найвідоміших настільних ігор у Східній Азії, вона виникла в Китаї 4000 років тому. За оманливою простотою гри ховається велика складність. Навчитися потрібно лише кілька хвилин, але освоїти потрібно все життя. Хоча на шахах комп’ютери перевершили людські навички, впровадження конкурентного інструменту інтелектуальної власності для Go залишається дослідницькою проблемою. Гра підтримується трьома технологіями, розробленими в Microsoft Research Cambridge: AI, здатний грати Go, мову F # та TrueSkill ™, щоб відповідати онлайн-гравцям. AI реалізований у F # і відповідає проблемі ефективної роботи в .net компактній основі на Xbox 360. Ця гра розміщує вас у кількох візуально приголомшливих 3D сценах. Він був повністю розроблений в керованому коді з використанням середовища XNA.

(Хтось уже згадував "TrueSkill".)