Что такое F #, недостающее OO или императив?

Ответ 1

Что касается материалов OO, мой список может быть

• Вы упомянули о интерфейсах и виртуальных играх, которые могут быть неприятностями или помехами; отсутствие авторезистов, о котором вы упомянули, также является позором.
• Структуры OO иногда требуют много взаимно-рекурсивных классов, которые F # в настоящее время заставляет вас помещать в один файл (в блок "тип... и... и..." )
• Если вам нужно вызвать два разных базовых конструктора в производном классе, вы должны использовать синтаксис "явного" класса (как упоминалось здесь)

Тем не менее, у F # есть сильные стороны в отделе OO, такие как вывод типа, локальные функции, сжатый синтаксис... так что в целом я мог бы назвать это мойкой в ​​отделе "сильно OO".

(Я практически не программировал ни одного пользовательского интерфейса, поэтому не могу вешать там.)

(EDIT: Я также хочу вставить это, хотя вы явно решили исключить "инструментарий" из вопроса, я думаю, что инструментарий имеет значение, и в этом отношении другие управляемые языки VS превосходят.)

Ответ 2

Я не большой поклонник этого вопроса, поскольку он жалуется на то, что F # не поддерживает идиоматический С#. Например, я не считаю справедливым критиковать F # за использование < - и: = для назначения переменной, потому что язык делает вещи неизменяемыми по умолчанию.

Несмотря на это, в С# есть несколько обязательных/объектно-ориентированных вещей, которые вы просто не можете использовать в F #.

• F # не поддерживает вложенные классы. В С# вы можете объявить класс внутри тела другого класса как механизм для типов охвата. F # не поддерживает это.

• F # не позволяет вам реализовать один и тот же общий интерфейс дважды. Например, в С# вы можете реализовать IComparable<int> и IComparable<string> для одного и того же типа.

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

• F # не имеет "родной" поддержки LINQ, так как в ней нет слова. Однако вы можете использовать LINQ API и лямбда-выражения для достижения того же результата.

То, что F # может сделать, что С# не может:

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

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

• Совпадение шаблонов и активные шаблоны.

• Единицы измерения для устранения ошибок, связанных с использованием неправильных единиц. (Например, добавление "футов" в "метры".)

• и др.

Вам не следует сосредотачиваться на том, что F # не может делать, как С#, потому что вся точка обучения F # должна быть представлена ​​новым способом думать о решении проблемы. Если вы пишете идиоматический код С# в F #, вы на самом деле ничего не получаете.

AFAIK F # не пропускает никаких "обязательных условий" для взаимодействия .NET/COM. В F # вы можете делать такие вещи, как параметры out и byref, объявлять строковые литералы и поддерживать атрибуты только что-нибудь.

Ответ 3

Императивное программирование в F # намного лучше, чем люди заставляют вас поверить. F # утверждение соответствия является удивительным. Почему другие языки не реализовали это, я не знаю. Что касается синтаксиса (mutable, ref и т.д.), То с ними легко работать. Вы получаете испорченность F # и легко жаловаться, когда синтаксис больше обычного. Кортежи также великолепны. Они также будут в С# 4.0. Currying - еще один бонус для Imperative.

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

F # - не все розы.

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

Отчасти проблема заключается в моей неопытности в стиле функционального программирования, который заключается в использовании Seq, List, Map и всех их сопутствующих методов, таких как map, iter, fold, scan. Мое первое функциональное решение почти никогда не является самым быстрым, а мое первое процедурное решение почти всегда близко к лучшему. Я хочу сказать, что часть этого не я. В некоторых ситуациях это функциональное программирование не дает себе результатов.

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

EDIT:

Много месяцев прошло, так как я опубликовал это, и у меня больше нет проблем с производительностью. Мои первые функциональные решения часто проще и почти оптимальны, и неизменные структуры данных просты. Единственные проблемы с производительностью, которые у меня есть сейчас, - это CLI, и я всегда могу сделать С++/cli, если мне нужно. Я использую некоторое наследование, кроме интерфейсов, но это только для анонимных объектов.

Ответ 4

Моя самая большая боль со статически типизированными функциональными языками - неспособность иметь переменные аргументы для метода, который должен быть выведен. Как функция карты. В F # вам нужно map2 map3 и т.д.

С другой стороны, С# тоже не хватает этого, если вы не хотите идти через отражение.

Возьмите схему, например, не статически типизированную. У вас нет проблемы для определения одной функции, которая может обрабатывать все случаи map_1... map_n. Конечно, вы теряете статическую безопасность, но она бледнеет по сравнению с дополнительным удобством написания сжатого кода.

Ответ 5

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

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