Открыть список
Как стать автором
Обновить

Комментарии 22

Красивый язык! Респект автору за статью мотивирующую к изучению.
я выбираю F# вместо C#


Для каких целей? И не могу не задать вопрос почему не Nemerle =)
Nemerle хороший язык. Но почему MS не захотел двигаться в его сторону? Из-за его чрезмерной сложности?
Да, можно потратить кучу времени на изучение Nemerle, затем выложить резюме на хедхантере и ждать… и верить, что твой скилс будет востребован. Нерациональная трата времени, потому и приходится совмещать полезное с приятным. F# для этого подходит.
чрезмерной сложности? Напротив, порог вхождения в Nemerle ниже, чем в F#. Переписать код с C# на него очень просто.
Транслятор пишу.

Во-первых, интерактивный интерпретатор.
Во-вторых, когда я принимался за это дело, у Nemerle не было нормальных средств разработки и, по-моему, сопоставления образцов.

Надо посмотреть на него ещё раз.
Просто, если проект for fun или разрабатывается для внутреннего использования, то стоит задуматься между выбором между Nemerle и F#. Они достаточно похожи (алгебраические типы данных и pattern matching), но Nemerle выглядит, когда не используешь fun, как C# (порог вхождения ниже) и поддерживает метапрограммирование.

Pattern matching в нем был изначально =)

Надо посмотреть на него ещё раз.

Скоро как раз версия 1.0 выйдет.
А там есть те же ActivePatterns?
Нет, их нет. И если я правильно понял их идею, то иногда жалею об этом.

Верно, что они помогают разбить сложный, возможно, вложенный pattern matching в более простой благодаря выносу части этого сопоставления в отдельную функцию? Это было основной мотивацией для их вноса в язык?
Думаю именно это.
Мне тут, кстати, подсказывают, что в хаскелле тоже есть нечто подобное.
Ну вот в очередной раз про Nemerle :) пока не будет юз-кейсов по реальные поставки реального ПО заказчикам на Nemerle с подробным истолкованием почему он полезнее чем C#/F#/Boo, мне кажется вопрос «почему не Nemerle» можно оставлять без ответа.
Примерно это я и хотел спросить, какая особенность задачи повлияло на то, что был выбран именно F#, а не другой язык, например, Boo или Nemerle…

Например, про свой дипломный проект, это, конечно, не реальные поставки реального ПО заказчикам, но самый крупный проект, который я писал (около 24К строк) могу точно сказать, почему я перешел с C# на Nemerle. Я захотел уменьшить количество ошибок, связанных с тем, что функция изменяла аргументы, которые ей передавали, в то время, как вызывающая сторона это не предполагала, наилучший способ достичь этого — использовать immutable структуры данных, такие как алгебраические типы и правильные (: списки, которые есть в функциональных языках. Так как проект частично уже был написан и покрыт тестами, я предпочел F#'у Nemerle так как он очень похож на C# и в начале можно было переписать код с C# на Nemerle с минимальными изменениями.
А почему вы просто не сделали поля readonly?
Ээ, давно этот переход был, около года назад, поэтому точно не скажу, но, кажется, мне больше всего не нравилось изменяемость списка, то можно было случайно что-то где-то испортить, изменив список-аргумент, а с другой стороны можно было сохранить этот список внутри, не рассчитывая, что его кто-то может извне изменить. От первой ошибки можно было избавиться, передавая его как ReadOnlyCollection, но так как ReadOnlyCollection это только обертка, то от второй проблемы это не спасало.

Другой мотивацией с переходу было то, что в проекте происходила работа с чем-то похожим на AST, на C# для работы с ним я использовал паттерн Visiter, но синтаксический overhead по сравнению с pattern matching мне не нравился.
по моему очень слабая мотивация для перевода проекта на другой язык даже в рамках CLR
на самом деле с не-C# языками мотивацию для перехода очень сложно найти. например F# — он имеет «честную» хвостовую рекурсию, а другие приемущества они спорные, ведь на том же C# можно делать immutable-структуры например. синтаксис более «резвый» но его перевешивает любой юз-кейс где пахнет мутабельностью, да и ООП не фонтан как выглядит. то же самое насчет Boo — с одной стороны метапрограммирование это круто, но когда некоторые конструкты неправильно компилятся (т.е. компилятор банально не готов), то уже и непонятно, стоит ли.
В реальной жизни красивое сопоставление образцов может выглядеть очень сурово:

| (* CLASS *) "c" :: tail ->
  // get the name
  match tail with
  | [] -> raise(Exception("Class is missing a name"))
  | name :: _ ->
    let c = Class(name, visibility)
    let cv = c :> IVisitable
    context := Some cv
    match !rootContext with
    | Some(x) ->
      match x with
      | :? Namespace as ns -> ns.Classes <- c :: ns.Classes
      | _ -> ()
    | None -> ()
    setRootContext cv


И уже как бы непонятно, как балансируются его выгоды с обфускацией…
Просто не хватает подсветки кода блоков, имхо.
Но да, с проблемой столкнулся.
Да даже с подсветкой имхо легче построить dsl на boo чем написать кашу на паттернах которые потом никто прочесть не сможет.
По-моему, читается достаточно просто.
А что здесь сурового? Все нормально читается, особенно если учесть, что здесь 4 уровня вложенности.
Спасибо за интересную статью.
Сам сейчас изучаю этот язык. Из всех .NET языков (не считая IronScheme) он меня привлекает больше остальных, не в последнюю очередь богатством выразительных возможностей и при этом простотой синтаксиса.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.