такое F # для IronPython / IronRuby как C # для VB.NET?

Question

Я только что прослушал подкаст Криса Смита, говорящего о F # , в котором он рассказывает о том, как F # является языком, который позволяет подходить к проблемам иначе, чем в C # / VB.NET, т. Е. Вместо того, чтобы «толкать биты» вокруг вас, «связать воедино преобразования данных» и то, как F # «станет похожим на XML», то, что вы используете в дополнение к вашему выбору языка (C # или VB.NET) в для более эффективного решения определенных проблем.

Это заставило меня задуматься об отношениях языков .NET, вот как я их понимаю:

• C # и VB.NET синтаксически синтаксически, но не существенно отличаются , т. Е. Программист C # не будет изучать VB.NET, чтобы «подойти к проблемам по-новому»
• однако программист на C # или VB.NET изучил бы F #, чтобы "функционально подходить к проблемам программирования "

А как же IronPython и IronRuby ? Крис упомянул, что «F # многому научился у Ruby и Python», поэтому я думаю, что F # имеет аналогичное отношение к IronRuby / IronPython, а C # - к VB.NET. Тем не менее, небольшое прибегание к поиску подсказывает мне, что IronRuby и IronPython оба построены на DLR, но F # не .

Как лучше всего понять отношения между F #, IronRuby и IronPython?

Answer 1

F # и IronPython / IronRuby - это световые годы с точки зрения языка. F # - это функциональный, типизированный скомпилированный язык. IronRuby / IronPython - это динамически типизированные, интерпретируемые языки.

Я считаю, что IronPython дополнительно поддерживает компиляцию, но я не уверен на 100%, и в меньшей степени насчет ruby.

Отношения между VB.Net и C # намного ближе.

Answer 2

Во многих отношениях F # и Ruby / Python внешне похожи. Все три языка позволяют вам выразить идеи кратко, не засоряя ваш код многими типами. Тем не менее, F # на самом деле сильно отличается от Ruby и Python, поскольку F # является языком статической типизации, а Ruby и Python динамически типизированы. Идиоматический код F # редко упоминает типы, но компилятор выводит типы, и любые ошибки типов будут отмечаться компилятором во время компиляции. Для Ruby и Python использование значения неправильного типа приведет к возникновению ошибок только во время выполнения. Динамизм Ruby и Python означает, что оба они более поддаются метапрограммированию, чем F # (например, типы могут быть изменены во время выполнения). С другой стороны, F # будет более производительным для большинства задач (сравнимым с C #) и предлагает много хороших функциональных абстракций, таких как различимые объединения с сопоставлением с образцом. Безусловно, правильное изучение любого из этих языков приведет к тому, что вы будете думать о проблемах иначе, чем в C # или VB.NET, но ваш подход, вероятно, будет сильно различаться между F # и Python / Ruby.

Answer 3

Я бы сказал, что F # узнал намного больше от OCaml, чем от Ruby и Python вместе взятых. Единственное реальное сравнение состоит в том, что F # переносит ML в .NET так же, как IronPython / Ruby переносит Python / Ruby в .NET.

Answer 4

ПРИМЕЧАНИЕ. В основном это сборник моих мыслей и наблюдений по этому вопросу. Я программист на C # днем, а Python ночью.

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

F # - функциональный язык. Что означает, что вы действительно больше озабочены глаголами, так сказать. Он по-прежнему статически типизирован и работает на CLR, но вы по-разному структурируете свой код и по-разному решаете проблемы. Обычно люди думают, что функциональные языки более математичны по структуре и их легче доказать формально. Конечно, это обычно считается академическим.

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

И, конечно, F # имеет некоторые функции и идеи, заимствованные из ОО-языков, в то время как C # имеет идеи и функции, заимствованные из функционала.

Сравнение Python и C # больше связано с разницей между динамической и статической типизацией (хотя python действительно предлагает некоторые функциональные возможности, которых C # до сих пор не имеет). Динамическая типизация, как правило, намного проще обрабатывать операции самоанализа / отражения и изменения во время выполнения, добавляя риск ошибок времени выполнения из-за опечаток или неправильных объектов, используемых в «обычном» коде.

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

Похоже, что со статическими языками гораздо проще управлять в больших командах. Кроме того, вы легко получаете преимущества рефакторинга со всеми инструментами проверки и проверки.

Answer 5

Есть аспекты F #, которые похожи на динамические языки; однако ответ JaredPar действительно подводит итог. F # находится в своей категории функционального программирования, где IronRuby и IronPython являются динамическими языками и C # / VB OO Languages Все они могут делать одни и те же вещи и зависят только от того, как вы хотите это сделать. У каждого есть свои плюсы и минусы для данной проблемы.

Answer 6

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