Существует ли менее многословная (как в F#) альтернатива C# for.NET а императив ОО?

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

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

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

4 2
c# f#

4 ответа:

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

Даже изменяемый тип, представляющий, например, запись базы данных 

class Employee {
    public Employee(string firstName, string lastName, int age) {
        this.FirstName = firstName;
        this.LastName = lastName;
        this.Age = age;
    }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

Можно свести к следующему в F#: 

type Employee =
  { mutable FirstName : string
    mutable LastName : string
    mutable Age : int }

И это должно быть чашкой чая C#.

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

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

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

6

F# 3.0 получает некоторые функции для лучшей поддержки императивного объектно-ориентированного программирования (что часто требуется при работе с императивными библиотеками .NET для доступа к данным). Он будет иметь автоматически реализованные свойства (см. документацию MSDN):

type MyClass() =
    let random  = new System.Random()
    member val AutoProperty = random.Next() with get, set
    member this.ExplicitProperty = random.Next()

Он также позволяет вычислить начальное значение с помощью конструкции member let (в отличие от просто member, которая повторно оценивает тело каждый раз, когда оно вызывается).

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

И просто Примечание относительно ваших комментариев, где "чистое функциональное программирование-плохое соответствие". Я думаю, что это действительно зависит от доступных библиотек и ментальной модели, которой вы следуете. Я совершенно убежден, что FP на самом деле довольно хорошо для GUIs, просто нет библиотек F#, которые могли бы это доказать. Вы можете найти этот вопрос интересным: возможно ли функциональное программирование GUI?

7

В .net есть несколько нишевых языков, которые могут иметь нужные вам свойства.

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

Из-за низкой популярности поддержка IDE довольно слаба, особенно для Cobra.

IronPython и IronRuby с другой стороны, только поддержка динамического набора текста. Это снижает безопасность компиляции и значительно усложняет статический анализ (полезный для Intellisense или рефакторинга).

6

Я также скажу, что вы, кажется, перепутали понятия императива и ОО-это не одно и то же. С-это императивный язык, но это, конечно, не ОО. И из текстов, цитируемых в этом вопросе, кажется, что доктор Кей действительно имел в виду, что Smalltalk будет функциональным языком, а Smalltalk является прародителем большинства концепций OO. Императивное "свойство" языка ортогонально его объектно-ориентированным свойствам. Так что если вы действительно спрашиваете, будет ли F# имейте лучшую поддержку для ОО, тогда я думаю, что Томас уже ответил на ваш вопрос очень хорошо. Все, что я говорю, это быть осторожным в размышлениях о императивном кодировании и ОО-кодировании-это не одно и то же.

0