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


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

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

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

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

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

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

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

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

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

| (* 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


И уже как бы непонятно, как балансируются его выгоды с обфускацией…
0
Просто не хватает подсветки кода блоков, имхо.
Но да, с проблемой столкнулся.
+1
Да даже с подсветкой имхо легче построить dsl на boo чем написать кашу на паттернах которые потом никто прочесть не сможет.
0
А что здесь сурового? Все нормально читается, особенно если учесть, что здесь 4 уровня вложенности.
0
Спасибо за интересную статью.
Сам сейчас изучаю этот язык. Из всех .NET языков (не считая IronScheme) он меня привлекает больше остальных, не в последнюю очередь богатством выразительных возможностей и при этом простотой синтаксиса.
Only those users with full accounts are able to leave comments. , please.