Чего не хватает F # для объектно-ориентированного проектирования или что является императивом?

Что касается OO, мой список мог бы быть

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

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

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

(РЕДАКТИРОВАТЬ: я также хочу добавить, что, хотя вы явно решили исключить «инструменты» из вопроса, я думаю, что инструменты имеют немного значение, и в этом отношении другие управляемые языки VS превосходны.)

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

Тем не менее, есть несколько императивных / объектно-ориентированных вещей, которые вы можете сделать на C #, чего вы просто не можете сделать в F #.

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

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

• В F # у вас должно быть архитектурное наслоение. Из-за вывода типа F # вы можете использовать только классы, которые были объявлены «раньше» или в том же «блоке» объявлений типов. Однако в C # вы можете иметь любую ссылку на любой другой класс. (На самом деле это требует некоторых хороших практик программирования.)

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

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

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

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

• Сопоставление с образцом и активные образцы.

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

• и Т. Д.

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

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

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

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

F # - это не только розы.

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

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

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