В чем F# испытывает недостаток OO или императива? [закрытый]

Imperative programming in F# is much better than people would lead you to believe. F#'s match statement is awesome. Why other languages have not implemented it I don't know. As far as things like syntax (mutable, ref, etc) they are easy to work with. You get spoiled by F#'s sparseness and it's easy to complain when the syntax is bigger than normal. Tuples are also great. They will be in C# 4.0 too. Currying is another bonus for Imperative.

Concerning OO I find I rarely use inheritance in pure F# projects and favor composition and interfaces instead. This is mainly due to using the primary contructor that allows you to use it's parameters as private properties in your methods (not sure if I worded that correctly). Other language constructs such as pattern matching pull you away from inheritance too. I've not done any mixed projects C#/F# so I can't comment on that.

F# isn't all roses.

My biggest issue with F# and game programming is performance. Implementing in F# is really fast and I often get a prototype up and running for what I want to do the same day I think of it however I find myself rewriting code for performance reasons way more often than in C#.

Part of the problem is my inexperience with functional programming style that is to use Seq, List, Map and all their accompanying methods such as map, iter, fold, scan. My first functional solution is almost never the fastest while my first procedural solution is almost always close to the best possible. I want to say part of this isn't me. That functional programming doesn't lend its self to performance in some situations.

I use less of the functional data types in F# now than when I started.

EDIT:

Many months have gone by since I've posted this and I no longer have issues with performance. My first functional solutions are often simpler and nearly optimal now and immutable data structures are simple. The only performance issues I have now are with the CLI and I can always do c++/cli if I need to. I do use some inheritance besides interfaces now but it's only for anonymous objects.

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

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

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

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

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

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

• F # не позволяет реализовать один и тот же универсальный интерфейс дважды. Например, в C # вы можете реализовать IComparable и IComparable на том же типе.

• В 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 # не может делать как C #, потому что весь смысл изучения F # должен быть представлен новый способ думать о решении проблем. Если вы напишете идиоматический код C # на F #, вы на самом деле ничего не получите.

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

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

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

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

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

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

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

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

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