Шаблоны для смешивания F # и C # в одном решении

Question

Я изучал несколько функциональных языков, в основном для академических целей. Тем не менее, когда мне приходится проектировать клиент-серверное приложение, я всегда начинаю использовать доменно-управляемый дизайн, строго ООП.

Сложное решение, написанное в среде .Net, может получить преимущества, используя не только язык, а иногда и больше, чем парадигму. Смешивание C или C ++ с LUA или Python является обычной практикой, иногда внедрение пролога может быть очень интересным. Я никогда не пытался смешать ООП и функциональную парадигму.

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

Когда и как, как вы думаете, будет хорошей идеей смешать эти два языка вместе? Интересно, существует ли набор шаблонов, который пытается это сделать?

Вы действительно используете F # в решении C #?

Answer 1

Есть определенные места, где традиционные функциональные методы имеют много смысла и приводят к тому, что код становится меньше и более кратким. Классическим примером является разбор текста и обработка дерева, которые часто появляются вместе при реализации DSL. Функции F #, такие как анонимные итераторы, расширяемое сопоставление с образцом и возможность определять пользовательские инфиксные операторы, служащие комбинаторами, действительно очень помогают здесь. Между тем, на стороне C # LINQ - хорошее начало, но оно не займет у вас всего пути.

Я предлагаю вам взглянуть на FParsec и убедиться, насколько он лучше подходит для расширенной обработки / анализа текста, чем любая библиотека, которую вы могли бы написать в C #.

Answer 2

Я написал WCF-сервис на F #, который действует как плагин переводчика для чтения сервиса WFS (геопространственных данных). Код получился красивым и лаконичным.

В то время как автономная dll, которую я скомпилировал, работала нормально в решении C # моего коллеги, он попытался задушить меня, когда я показал ему код. Культурный шок, я думаю.

Так мы использовали F # и C # в одном проекте? И да и нет. Нет, потому что я переписал эту вещь на C #. Да, потому что создание и тестирование прототипа в F # сэкономило мне больше времени, чем перевод его в C # LINQ-style.

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

Answer 3

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

Часть F # соответствует интерфейсу, определенному в C #, а приложение C # понятия не имеет он имеет дело с частью F # (кроме зависимости от fsharp.dll).

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

Мы выбираем язык, который лучше всего подходит для решения конкретной проблемы, и MEF абстрагируется от нас, поэтому нам не о чем беспокоиться.

Answer 4

Вы заставили меня задуматься, и я попытался решить, где я это сделаю. На ум приходят две ситуации:

1. Если я делаю замковый проект (MVC), у меня, вероятно, будут контроллеры на C #, в то время как все BL и модели находятся на F # (я склонен к проектированию на основе домена и подключаю BL к моделям или с помощью встроенных компонентов [ аля Д.И.])
2. Начинаем новый проект, но включаем существующие библиотеки, чтобы не изобретать велосипед.

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

Answer 5

Я использую F # для исследовательского программирования в моих решениях на C #. Например. Я запускаю свое приложение C # WPF через интерактивную консоль визуальных студий F # и копаюсь в запущенном приложении. Может сэкономить вам много сеансов edit-compile-debug ..

Answer 6

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

Что касается того, как это сделать, см .:

Можете ли вы смешивать языки .net в рамках одного проекта?

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

Answer 7

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

http://steve -yegge.blogspot.com / 2006/03 / выполнение-в-царстве-оф-nouns.html

Я хотел бы просто назвать это как глагол и выполнить его

CalculateSomething () вместо SomtingCalculator.Execute ()

Answer 8

Да, в будущем я думаю, что мы должны объединить такие языки, как ООП (C #) и Функциональный язык (F #), чтобы воспользоваться преимуществами многоядерной обработки. В C # 4 есть классы для поддержки этого, но некоторые вещи лучше выполняются в F #.