Внезапно, F* теперь под Apache 2.0. Пруф: github.com
erlang-factory.com — Some F# for the Erlang programmer.
gist.github.com
Версия на F# работает заметно быстрее хаскельной, по ощущениям. Попробовать разогнать, что ли.
Явно, явно этот язык придумывали люди, которые не любили pattern matching и не хотели, чтобы им пользовались. Это ж надо, чтобы матчить аргументы функции, надо или делать это по-одному и вручную, или хаком, работающим только для функций с одним аргументом.
Пытаюсь переписать маленькую программку на F#. Грабли, грабли, грабли. У Seq есть take, но нет split и drop. Я напишу свою версию, конечно, но как-то они совсем иначе живут в этом мире.
Посмотрел поверхностно на F# и испытал чувства как от питона: язык, недостаточно сковывающий программиста. Мультипарадигменность еще можно списать на вкусовщину и необходимость как-то жить в рамках .NET, хотя из нее вечно получается jack of all trades, master of none. А вот отсутствие pure функций даже в виде аннотаций это плохо, я уже испорчен, что код за пределами IO в хаскеле ничего втихую сломать-изгадить не может. А тут фигак — и снова C++ с его "вася в фунцкии какой-то библиотеки завел shared state в файле на диске". Пичалька.
Warning FS0062: This construct is for ML compatibility. Consider using the '+' operator instead. This may require a type annotation to indicate it acts on strings. This message can be disabled using '--nowarn:62' or '#nowarn "62"'. (FS0062)
Тут у гипотетического читателя прошлого поста, ошарашенного феноменальной полезностью файла Script.fsx, закономерно возникнет вопрос: получается, что можно открыть файл Script.fsx — и мы получим откртое окно интерпретатора, в который все нужное для работы уже подгружено. Ведь верно? Ведь правильно? Нет. Не верно. Скрипт отработает без вывода на экран и интерпретатор закроется. И это не шутка, как бы абсурдно это не звучало.
Отдельная история — это "индеграция" fsi с VS. Даже в такой кривой поделке как leksah есть работающая команда в контекстном меню Eval. Интуитивно понятно, что она сделает: запустит интерпретатор, если он не запущен, загрузит модуль и все зависимости, если они еще не загружены и выполнит выделенный код. В "интеграции" F# c VS ничего такого не произойдет: программист должен страдать! Команда Send to Interactive — тут просто для галочки, не предполагается. что кто-то этим будет пользоваться — так что и команда делает буквально то, что написано: отправляет код в интепретатор и выводит ошибку. Это действие в F#, разумеется, вовсе не имеет смысла. Имело бы смысл отправлять в интерпретатор, по крайней мере, все файлы расположенные выше данного по порядку и ту часть открытого файла, что выше выделенного текста. Ха! Мечтайте больше. Вопиющая бессмысленность функции создателей "интеграции" не полнует. Но что это? При создании проекта в нем создается и файл Script.fsx. Может в него автоматически пишется загрузочный скрипт для проекта? Нет писать нужно вручную. Сидите и пишите:
#r "FSharp.PowerPack.dll"
#load "Fancy.fs"
open Henry.Every
open Fancy
#load "Revenge.fs"
open HMS
open Revenge
Ну, может, он хоть загружается автоматически или нажатием одной кнопки? Где-то такая кнопка может и есть, но из коробки все так: выделяете весь текст скрипта -> Send To Interactive!
Пока у меня складывается впечатление, что самые нижние этажи F#-ада, стигийские лиды — это REPL. Предположим, вы пишете в командной строке fsi Fancy.fs — ну понятно, Fancy.fs должен существовать. Если бы вместо fsi был ghci, а вместо fs был hs, мы бы получили открытое окно интерпретатора в котором загружен модуль, можно было бы что-то делать с объявленными в модуле и импортированными функциями, конструкторами и т.д. Но мы-то имеем дело с F# и тут ничего такого не получится по ряду причин. Во-первых, не знаю как у вас, но у меня fsi при установке VS не прописался в путях, так что команда fsi просто не будет найдена. Ну это легко исправить. Дальше — хуже. Файл Fancy.fs не представляет из себя какой-то самодостаточной единицы — это просто один из кусков кода, которые нужно подгрузить в определенном порядке в духе суровых инклюдов. Ghci подгрузил бы установленные пакеты, от которых зависит открываемый файл, но fsi это делать не станет. Да, FSharp.PowerPack в Assembly Cache — ну так что с того? Давайте, не ленитесь, ручками, ручками — #r "FSharp.PowerPack.dll";; Автоматика, модульность — это все зло и грех, все необходимо отсечь: программист на F# должен знать только келью, духовника и все!
Пастебины люто ненавидят F#. Всем своим пехепешным сердцем. Если пройтись по списку пастебинов из википедии окажется, что поддерживают подсветку кода на нем только pastebin.com и pzt.me, ну это если нет желания пользоваться каким-нибудь голландскоязычным plakkert.nl. При этом в списке языков вполне может оказаться какой-нибудь ioke, но F# там не будет. Возможно это связано с тем, что все думают, будто бы F# — это такой окамл и можно пользоваться окамловой подстветкой. Косвенно это подтверждается тем, что gist.github позволяет выбрать F# в списке, но подстветку использует от окамла — т.е. минимальное требование — визуальное отличие кода от комментариев не выполняется. // комментарии как комментарии не распознаются.
Раньше мне казалось, что вокруг f# существует какой-никакой но хайп, есть многочисленное коммьюнити, поддержка МЕГАКОРПОРАЦИИ и все такое. На практике же оказалось, что F# — язык эзотерический. Посудите сами, на stackoverflow тегом f# помечено 2256 вопросов. Для сравнения: haskell 3123, хотя по сравнению с ocaml (494) и sml (176) популярность просто бешеная. Каждую неделю задается сопоставимое (общему количеству вопросов про F#) число вопросов по "языкам программирования" C# и Java. Субреддит /r/fsharp читают 611 человек (/r/haskell 6948), свежайшая новость там запощена 12 дней назад. О существовании F# даже в МЕГАКОРПОРАЦИИ многие не подозревают, например, на codeplex нет подсветки кода для F#. На GitHub и BitBucket ее, разумеется, тоже нет. О чем говорить? На гитхабе F# (37-е место по популярности) нет в выпадающем списке языков в поиске (хаскель там в блоке "популярные", 15-е место).
Земную жизнь пройдя до середины, я очутился в жизненной ситуации, которая заставляет меня изучить *fsharp. Это, конечно, полуправда. Никто заставлять изучать F# не станет, но если можно писать на работе на нем, а не на *csharp — то почему бы и нет? Уж если приходится есть пирожки с булавками — пусть они будут хотя бы английскими. Не пирожки, а булавки, конечно. Такой оптимизм основан на том, что я поверхностно знаком с "функциональными языками" *ml семейства и примерно представляю, чего от них ожидать. Чтоб смыть железное послевкусие булавок, я параллельно продегустирую что-нибудь заведомо приятное, *agda 2, например.
Ковыряюсь с f#, плююсь на каждом шагу, но продолжаю настойчиво грызть.
Нельзя писать:
type 'a SyntaxTree
= Literal of string * 'a
| Ident of string * 'a
| BinaryOp of { Op : BinOperator; Left, Right : 'a SyntaxTree; }
говорит deprecated, советует заводить отдельный тип для рекорда:
type 'a SyntaxTree
= Literal of string * 'a
| Ident of string * 'a
| BinaryOp of 'a _BinaryOp
and 'a _BinaryOp = { Op : BinOperator; Left : 'a SyntaxTree; Right : 'a SyntaxTree; T : 'a }
Я конечно понимаю, у них там что-то сломалось, и пришлось запретить. Но ведь пользоваться теперь совсем не удобно!
А как монады у них сделаны?! Просто навалили в кучу и ST, и Plus, и Maybe со списками: нате, юзайте!
И компилятор настолько тормознутый, что у меня даже музыка в наушниках замирает.
Зато к релизу студии успели.