Подтвердить что ты не робот

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

Ты заставил меня думать, и я попытался решить, где бы я это сделал. Есть две ситуации, в которых spring:

  • Если я создаю проект замка (MVC), у меня, вероятно, были бы контроллеры на С#, а все BL и модели были бы в F # (я, как правило, делаю проект, управляемый доменом, и подключаю BL к моделям или через инжекционные компоненты [ ala DI])
  • Запуск нового проекта, но включение существующих библиотек, чтобы не изобретать колесо.

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

Как это сделать, см.

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

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

Ответ 7

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

Ответ 8

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

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

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

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