я в следующей статье собираюсь выложить код небольшой утилиты на F#, которую лично написал, и которая действительно была мне полезна по работе. Она конечно не бог весть что, но явно не числа Фибоначчи (которые кстати везде где я видел на хабре написаны неправильно, потому что не учитывают возможный StackOverflow :)).
Думаю дня через три-четыре будет, а то я еще от написания этой не отошел. Можете заглянуть.

Честно отвечу — не знаю. Я Nemerle смотрел в свое время, но не так сильно, чтобы мог хоть с какой-то убедительностью пытаться их сравнивать.

вопрос конечно фундаментальный, и в двух словах не ответить.
На самом деле у ФП в целом и F# много преимуществ перед императивными языками, например простота в распараллеливании вычислений, вытекающая из самой идеологии (что кстати очень актуально в связи с хз сколькими ядрами на проце, которые толком и не использует-то никто), обработка больших объемов данных кстати, из бд, тоже будет писаться проще и выглядеть красивее. Linq то глядите как приглянулся всем (ну многим по крайней мере), а ведь по сути — это и есть шажок к ФП. Ну с другой стороны конечно интерфейсы пока явно не стезя F#. =)
Насчет быстродействия — конечно плюсам он на одном ядре проигрывает, а уже C# — не так чтобы очень сильно (голословно, пруфлинка нету). С другой стороны если взять в расчет распараллеливание, то уже могут быть варианты.

Мне кажется что Nemerle тоже рассматривался в качестве прототипа. Но отдали предпочтение Ocaml.
А писать Begin end, ставить ;; в конце операторов и использовать функции внутри друг друга с помощью in вполне можно и сейчас, #light не отключает эту возможность, а всего лишь добавляет другую. Ну в крайнем случае можно эту директиву стереть, чтобы не смущала :)

Лишний код в CIL наверно поправят, насчет видимости — в F# есть все те же самые модификаторы private, inline, public, только порядок другой — здесь модификатор должен непосредственно предшествовать идентификатору.
Написав val mutable private prVal: string получим изменяемое поле видимое только внутри класса. То же самое с member, причем модификаторы как и в сишарп можно ставить и перед get и set отдельно, если есть необходимость.
Почему по умолчанию поля члены класса сделаны публичными — могу только догадываться. Вроде в Object Pascal так же было (вспоминая школьные годы =))

могу сказать по личному опыту — далеко не так, как кажется на первый взгляд. На поверку все оказывается довольно логично.

не припомню так уж много новых ЯП у MS. Вроде уже x последних лет упорно держатся за C#.

Знаете, я скажу так: это дело привычки, что там, что там. На ФЯП во многих случаях код получается значительно короче и декларативней, чем на ООЯП — это правда. Но не всегда.
А вообще любой сложный код читается хорошо в первую очередь когда есть комменты, без них и в сишном коде закопаться легче легкого :)

С другой стороны этот синтаксис можно довольно легко прочитать, а чтобы прочитать более-менее длинную программу на лисп или хаскелл, нужно кажется постичь дзен. =)

Возразить особо нечего. Ну так это ведь не тайна за семью печатями, что F# — новый «сын» ML серии. Однако и нельзя на этом основании делать вывод, что он бесполезен, поскольку есть OCaml.

возможно в чем-то вы правы, но во-первых это язык еще развивается, и последняя версия — всего лишь CTP. Так что возможно кое-какие шероховатости исправят.
Питон сам по себе на данный момент наверняка более вылизан и продуман, однако пара F#- .NET CLR выглядит очень перспективно имхо.

ну я примерно с этой целью ее и писал — как введение.
Я конечно уже апостериори думал поделить ее на три, но поскольку изначально мысль была именно показать рядом все три стороны, то уж решил будь как будет.

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

ну потенциальные втыкатели на работе на F# вовсе не программируют, да и на OCaml с Haskell тоже думаю не то чтобы очень часто, так что так получается можно вовсе не писать =))
на самом деле, как бы это банально ни звучало, я пишу то, что интересно в первую очередь мне. Если это будет интересно еще кому-то — прекрасно, нет — я обойдусь. Я же не путаюсь запихнуть свои посты в какие-нибудь группы, все в своем блоге. как-то так )))

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

Но ведь и Java тоже привязана к своей платформе, это у нее тоже недостаток? Отсутствие необходимости для каждой задачи изобретать велосипед трудно назвать недостатком на мой взгляд. Или же вы имеете ввиду отсутствие операционной кроссплатформенности — но тогда существует Mono например. Или может быть имелась ввиду слишком сильная привязка программиста к одной платформе — тогда я с вами соглашусь полностью! =)

спасибо, в следующий раз рассмотрю задачу посерьезнее, может к тому времени и новая доза появится.
ну да, по сути функции те же, только называются в перле короче. =)
Что мне в верхнем коде нравится, что он читается в ту же сторону, в которую и выполняется, благодаря |>, хотя можно было бы написать и что-то в этом роде:
printfn ("%d") List.fold_left (+) 0 List.filter (fun x -> x%3=0 or x%5=0) [1..999]

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

это точно. даже удивительно от такой серьезной компании видеть такой странный интерфейс. Громадная окантовка, столько места для клавиатуры — к чему все это? Даже если экран меньше чем у конкурентов, сделали бы размеры меньше, вот это может сошло бы за фичу, хотя мне размеры PRS-505 излишними не кажутся.

Ну с Silverlight все то же самое, если не ошибаюсь…