Есть ли менее многословная (как в F #) альтернатива C # для .NET и императивного OO?

Question

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

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

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

Answer 1

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 на самом деле очень хорош для графического интерфейса, просто нет библиотек F #, которые бы это доказали.Вы можете найти этот вопрос интересным: Возможно ли функциональное программирование GUI?

Answer 2

Мне не ясно, что вам не нравится в 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 # может заключаться в том, что это мультипарадигмальный язык. Вы можете использовать ОО для структурирования вашего проекта и функциональное программирование «в малом» для организации ваших модулей - ни один стиль не должен доминировать. Это просто увеличивает размер вашей панели инструментов.

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

Answer 3

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

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

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

---

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

Answer 4

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