Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
Здравствуйте, ArtDenis, Вы писали:
AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
Думаю слабая кросс-платформенность не устраивает.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Здравствуйте, demi, Вы писали:
D>Здравствуйте, ArtDenis, Вы писали:
AD>>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
D>Думаю слабая кросс-платформенность не устраивает.
не слабже чем у C#-а
Здравствуйте, ArtDenis, Вы писали:
AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме.
Популярность у него не только на этом форуме маленькая. Она так же мала и на stackowerflow, и на GitHub, и на reddit.
Лично я о своем (небольшом) опыте написания программ на нем сюда не пишу, чтоб не докучать своими жалобами, для этого у меня есть специальный микроблог, который никто не читает.
AD>Казалось бы есть удобная среда
Лично мне среда показалась не очень удобной.
AD>поддержка солидной компании.
Солидная компания не только не сделала для F# среды разработки на уровне C#, но даже не может найти в себе достаточно "поддержки" чтоб на codeplex была подсветка кода для F#.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, Klapaucius, Вы писали:
AD>>>Казалось бы есть удобная среда K>>Лично мне среда показалась не очень удобной.
AD>А что именно там неудобно?
Нет дизайнера форм -- самый большой недостаток F# на фоне C#
Здравствуйте, ArtDenis, Вы писали:
AD>А что именно там неудобно?
Сразу уточню, что все что я тут напишу — про стандартную интеграцию F# поставляемую с VS2010 без сервиспака. Если ситуация изменилась к лучшему — я буду только рад.
Я, конечно, ожидал, что интеграция для F# будет несколько отставать от других официально поддерживаемых языков, но не ожидал такого сурового аскетизма.
Хуже всего, что нет нормальной навигации по коду, только возможность прыгнуть к определению — вот и все. Места использования не найти, панель навигации в верхней части окна с кодом отсутствует (я даже и предположить не мог, что так и должно быть — думал что ошибка какая-то, посмотрел скринкасты и убедился, что у других все то же самое), Class View не работает. Можно скачать экстеншн FSharpJump или что-то вроде того, но он какой-то неудобный и инородный (если не сказать — инопланетный).
Рефакторинга нет (стороннее расширение у меня вообще не заработало), даже сворачивания блоков кода нет "из коробки". да проще сказать что есть:
Крайне аскетичная подсветка кода, беднее чем в ином продвинутом блокноте: выделяются цветом комментарии (но видимых различий между xml и обычными нет), ключевые слова и литералы. Т.е. типы и конструкторы, например, не подсвечиваются. Хотя бы вложенные коментарии правильно подствечивает — и то хорошо.
Всплывающая подсказка, показывающая тип, но работающая для имени, а не для выделенного выражения. Да и не со всяким именем работает, операторы — исключение.
Автокомплит, но тоже какой-то странный, по мере набора имени спосок вариантов не сокращается — меняется только позиция курсора в нем, да и окно вариантов открываться не спешит, только специальная комбинация клавиш или точка заставляет автокомплит проснуться.
Вообще, все будто бы вопиет о необходимости серьезной доработки напильником. Плюс падения, в случае набора open Blah.Blah.Blah — регулярные.
Поэтому сравнивать все это следует, скорее, не с нормальными IDE промышленного качества для C# или Java, а со средами разработки всяких экзотических языков, при этом даже им интеграция F# во многом проиграет. Для экзотических языков есть всякие интересные инструменты вроде REPL и поиска по типам. В F# и то и другое формально присутствует (поиск по типам — не в стандартной поставке), но показалось мне неюзабельным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, desco, Вы писали:
D>так вы этот список не сюда публикуйте, а на connect — пользы точно будет больше.
Думаю, что не на много. Такие проблемы — доволно очевидны, нет какой-то насущной необходимости на них в очередной раз указывать. Полагаю, что с течением времени они все будут решены.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, desco, Вы писали:
D>>так вы этот список не сюда публикуйте, а на connect — пользы точно будет больше.
K>Думаю, что не на много. Такие проблемы — доволно очевидны, нет какой-то насущной необходимости на них в очередной раз указывать. Полагаю, что с течением времени они все будут решены.
будем стараться
Re[3]: Популярность F#
От:
Аноним
Дата:
09.09.11 13:18
Оценка:
AD>А зачем нужна кросс-платформенность для тех задач, для решения которых выбирают .net и Visual Studio?
Для тех задач для решения которых выбирают .NET и C# эфсярп ненужен
Здравствуйте, Аноним, Вы писали:
AD>>А зачем нужна кросс-платформенность для тех задач, для решения которых выбирают .net и Visual Studio?
А>Для тех задач для решения которых выбирают .NET и C# эфсярп ненужен
Глубокомысленно... Было бы интересно услышать обоснование хотя бы одному из экспертных высказываний. Потому что я слышал и абсолютно противоположное мнение, когда человек перейдя на F# всячески его расхваливал и уже нивкакую не хотел писать на C#.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Глубокомысленно... Было бы интересно услышать обоснование хотя бы одному из экспертных высказываний. Потому что я слышал и абсолютно противоположное мнение, когда человек перейдя на F# всячески его расхваливал и уже нивкакую не хотел писать на C#.
Я еще не перешел, но уже на C# не хочу
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, samius, Вы писали:
S>>Я еще не перешел, но уже на C# не хочу
BZ>так ты перейди. может тогда назад захочешь
Вряд ли. По отношению к C#-у у него множество преимуществ.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, samius, Вы писали:
S>>Я еще не перешел, но уже на C# не хочу
ПМ>Тогда можешь пропустить F#. Всё равно потом перейдёшь на Хаскель, если программировать не надоест совсем.
Для себя — возможно и перейду. Вобщем-то буквари прочитаны, тут уже либо переходить либо не переходить. F# ближе средой/платформой. А работу работаю на C++.
D>>>так вы этот список не сюда публикуйте, а на connect — пользы точно будет больше.
K>>Думаю, что не на много. Такие проблемы — доволно очевидны, нет какой-то насущной необходимости на них в очередной раз указывать. Полагаю, что с течением времени они все будут решены.
D>будем стараться
О! Инсайдеры засветились!
Не поделитесь какие планы у Майкрософта на этот язык? Включая продвижение.
Здравствуйте, Олег К., Вы писали:
D>>>>так вы этот список не сюда публикуйте, а на connect — пользы точно будет больше.
K>>>Думаю, что не на много. Такие проблемы — доволно очевидны, нет какой-то насущной необходимости на них в очередной раз указывать. Полагаю, что с течением времени они все будут решены.
D>>будем стараться
ОК>О! Инсайдеры засветились!
ОК>Не поделитесь какие планы у Майкрософта на этот язык? Включая продвижение.
Скорее всего не поделятся. Т.к. рекламировалось как новый серебрянный пуль от MS,
а в результате вышла банальная доставалка данных.
Все изменния в версии 3.0 относятся только к внешним рюшкам типа
запросов и тайп-провайдеров, что для самого языка ортогонально.
Старые косяки скорее всего не исправили (ибо не похвастались), новые концепции тоже не внесли,
и даже ни одного зарезервированного слова не имплементировали (хоть бы const для приличия сделали).
Так что если все будет и дальше в таком же духе можно смело забивать на F#
Здравствуйте, InCus, Вы писали:
IC>Старые косяки скорее всего не исправили (ибо не похвастались), новые концепции тоже не внесли, IC>и даже ни одного зарезервированного слова не имплементировали
А какие ошибки нужно исправить по вашему мнению? И какие "новые концепции" вы хотели бы в F# увидеть?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K> А какие ошибки нужно исправить по вашему мнению?
В первую очередь сделать нормальный вывод типов, а не так как разработчики компилятора смогли реализовать.
Потом была песня, что расширение класса операторами невозможно использовать в других модулях (они их просто не видят).
По форумам поскрести много чего еще можно найти, вспоминать лень уже.
K> И какие "новые концепции" вы хотели бы в F# увидеть?
Все идеи и концепции которые создалеи натырыли с разних мест перечислены в последней таблице на http://msdn.microsoft.com/en-us/library/dd233249.aspx
Хочу много из этого, но ничего из этого за год не родилось даже в зачаточном виде.
Уж если банальные let [<Literal>] на const поменять времени не нашлось, то об остальном и мечтать, видно, не приходится.
Здравствуйте, InCus, Вы писали:
IC>В первую очередь сделать нормальный вывод типов
Ну, это сделать в принципе не получится, из-за необходимости взаимодействовать с .net библиотаками где сплошной сабтайпинг и перегрузки. Этого можно не ждать.
IC>Все идеи и концепции которые создалеи натырыли с разних мест перечислены в последней таблице на IC>http://msdn.microsoft.com/en-us/library/dd233249.aspx IC>Хочу много из этого,
Там только ключевые слова перечислены. В основном из C# и OCaml, по поводу некоторых можно пофантазировать или сделать какие-то предположения (например, atomic, вероятно, зарезервирован был еще в те времена, когда не известно было, что STM под .net не сделать, соответственно этого уже можно не ждать), ключевые слова типа functor могут намекать на то, что они все-таки рассматривают возможность сделать нормальные модули, как в нормальном ML, но каких-то других подтверждений этого я не слышал — наоборот, что-то было в том смысле , что в такой колбасе потребности нет.
IC>но ничего из этого за год не родилось даже в зачаточном виде.
С самого начала было очевидно, что после добавления F# в стандартную студийную поставку скорость изменений упадет до скорости дрейфа материков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
IC>>В первую очередь сделать нормальный вывод типов K>Ну, это сделать в принципе не получится, из-за необходимости взаимодействовать с .net библиотаками где сплошной сабтайпинг и перегрузки. Этого можно не ждать.
Nemerle однако...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, InCus, Вы писали:
IC>>В первую очередь сделать нормальный вывод типов
K>Ну, это сделать в принципе не получится, из-за необходимости взаимодействовать с .net библиотаками где сплошной сабтайпинг и перегрузки. Этого можно не ждать.
В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
K>Там только ключевые слова перечислены. В основном из C# и OCaml, по поводу некоторых можно пофантазировать или сделать какие-то предположения (например, atomic, вероятно, зарезервирован был еще в те времена, когда не известно было, что STM под .net не сделать, соответственно этого уже можно не ждать), ключевые слова типа functor могут намекать на то, что они все-таки рассматривают возможность сделать нормальные модули, как в нормальном ML, но каких-то других подтверждений этого я не слышал — наоборот, что-то было в том смысле , что в такой колбасе потребности нет.
break, const, continue, event делаются на раз
functor, mixin, pure, trait, parallel, process как минимум не помешали бы
остальное сложно идетифицировать, но раз оно там есть, значит идеи о примении были.
вспомнилось еще совершенно отвратильное развертывание хвостовой рекурсии в циклы.
басня сайма и ко, о том что мол "jit сооптимиздит" в реальном мире не работает.
K> ... в такой колбасе потребности нет.
Нет, так нет. С таким подходом и F# будет такой колбасой.
Здравствуйте, desco, Вы писали:
K>>Думаю, что не на много. Такие проблемы — доволно очевидны, нет какой-то насущной необходимости на них в очередной раз указывать. Полагаю, что с течением времени они все будут решены.
D>будем стараться
А вы не хотите стараться так, чтобы в результате получались свободно доступные базовые классы которые можно использовать в других интеграциях?
Тогда другие (мы, например) могли бы вам помогать в работе над ними. А то по своему опыту знаю, что информации в мсдне не хватает чтобы реализовать нужные вещи самостоятельно. Вы же имеете доступ к коду студии и можете отлаживать ее по человечески.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, InCus, Вы писали:
K>>Ну, это сделать в принципе не получится, из-за необходимости взаимодействовать с .net библиотаками где сплошной сабтайпинг и перегрузки. Этого можно не ждать.
IC>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
Особенно смешно эти рассказы выглядят на фоне Nemerle, где ввод типов работает намного лучше. Причем автор базового алгоритма работает в команде контактирующей с F#-поской и, если не ошибаюсь, использует F# в своей работе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, InCus, Вы писали:
IC>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
Здравствуйте, Димчанский, Вы писали:
Д>Здравствуйте, InCus, Вы писали:
IC>>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
Д>А что, действительно такое есть? Можно пример?
Такое сплошь и рядом, когда используются объекты. Я образно воспринимаю так: типы выводятся слева направо и сверху вниз. Тогда у выражения x |> f есть преимущество. Прикольно, конечно, наблюдать это, но что поделаешь?
Здравствуйте, Димчанский, Вы писали:
Д>Здравствуйте, InCus, Вы писали:
IC>>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
Д>А что, действительно такое есть? Можно пример?
typeof<int>.GetMembers() |> Array.map (fun e -> e.Name)
vs
Array.map (fun e -> e.Name) <| typeof<int>.GetMembers()
Здравствуйте, WolfHound, Вы писали:
K>>Ну, это сделать в принципе не получится, из-за необходимости взаимодействовать с .net библиотаками где сплошной сабтайпинг и перегрузки. Этого можно не ждать. WH>Nemerle однако...
Ну, вывод типов в Немерле локальный и не выводит наиболее общий тип. При таких условиях тип можно выводить и при наличии сабтайпинга и перегрузок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, InCus, Вы писали:
IC>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
Это не сказка, а суровая правда. Раз система типов расширена, чистый Х-М не работает, и по всей видимости, нужно как-то изворачиваться, используя эвристики. Эвристики всех случаев не покрывают, разумеется, и не во всех случаях ведут к правильному решению.
IC>break, const, continue, event делаются на раз
Но зачем? Это какие-то костыли, а F# и так со всех сторон в подпорках.
IC>functor
Это я уже комментировал. Без нормальных ML-ных модулей F#, разумеется, ML-инвалид, но и модули эти, скажем так, не только музыка и цветы, так что отказ от них может быть мотивирован не только ленью разработчика языка.
IC>mixin, trait
Тут не понятно, зачем два разных слова для одного и того же по сути.
IC>pure
Тут все с ног на голову поставлено. Аннотированная чистота при обратных умолчаниях еще нигде не заработала хоть как-то. Да и бенефиты какие-то извлечь в таком случае проблематично. А аннотация "нечистого" кода при дефолтной ссылочной прозрачности осложнит взаимодействие с .net библиотеками.
IC>parallel
Если это ключевое слово для создания чего-то типа хаскельной "искры" — то от языкостроителей это не зависит. тут поддержка рантайма требуется.
IC>process
Тут я даже предположить не могу, что подразумевается.
IC>остальное сложно идетифицировать, но раз оно там есть, значит идеи о примении были.
Не обязательно.
IC>вспомнилось еще совершенно отвратильное развертывание хвостовой рекурсии в циклы.
Например?
K>> ... в такой колбасе потребности нет. IC>Нет, так нет. С таким подходом и F# будет такой колбасой.
Ну, сравнивать-то надо с реальными альтернативами. А реальность такова, что при всей убогости и кривости F# кол-во языков, которые лучше него можно пересчитать по пальцам одной руки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, InCus, Вы писали:
IC>>В эту сказку для детей я не верю. В случае, когда вот так x |> f мы можем вывести тип, а вот так f x внезапно разучились, рассказы об ограничениях .net библиотек выглядят мягко говоря странно.
K>Это не сказка, а суровая правда. Раз система типов расширена, чистый Х-М не работает, и по всей видимости, нужно как-то изворачиваться, используя эвристики. Эвристики всех случаев не покрывают, разумеется, и не во всех случаях ведут к правильному решению.
Сказка даже хорошо пропиареная все равно остается сказкой.
Разницы, для нормальной системы вывода типов, между
typeof<int>.GetMembers() |> Array.map (fun e -> e.Name)
и
Array.map (fun e -> e.Name) <| typeof<int>.GetMembers()
нет. Но в F# это не так.
Но, если проанализировать это http://stackoverflow.com/questions/3162387/why-is-fs-type-inference-so-fickle/3162832#3162832
И отбросить байку Брайена от мифических трудностях ООП в Net (см п.3), то окажется, что
1) Такое убожество родили намеряно, для понижения порога вхождения
2) Ocaml с нормальным выводом типов и объектной моделью в себе не имеет такой болезни
3) Сайм, сам признался, что сделать более внятный вывод типов можно, но его ломает анализировать ошибки
В соотвествии с п.3., на рассказы о том, что не работает из-за того, что "система типов расширена" можно не обращать внимание.
А теперь смертельный номер. Берем
Array.map (fun e -> e.Name) <| typeof<int>.GetMembers() |> printfn "%A"
разумеется не компилится. Выносим (fun e -> e.Name) в виде инлайна
Опа! Чудо! Фактически для системы вывода типов не было сделано ни одной! подсказки,
(и (fun e -> e.Name) и GetName имеют тип ^a -> ^b), но все заработало.
Самое смешное в происходящем, что компилятор мог бы автоматически выносить
(fun e -> e.Name) в GetName и никаких бы проблем с анализом ошибок при этом не произошло,
но это же делать надо, а у нас п.3.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Klapaucius, Вы писали:
IC>>>вспомнилось еще совершенно отвратильное развертывание хвостовой рекурсии в циклы.
K>>Например?
H>Вероятно речь идет о tail call, который невероятно тормозит на x86.
Может речь об этом?
let rec fac n a x =
match n with
| 1 -> a
| _ -> fac (n-1) (a * n) x
[CompilationArgumentCounts(new int[] { 1, 1, 1 })]
public static int fac<a>(int n, int a, a x)
{
while (true)
{
switch (n)
{
case 1:
return a;
}
x = x; // Надо или не надо, все параметры переприсваиваются на очередной итерации.
a *= n;
n--;
}
}
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Klapaucius, Вы писали:
IC>>>вспомнилось еще совершенно отвратильное развертывание хвостовой рекурсии в циклы.
K>>Например?
H>Вероятно речь идет о tail call, который невероятно тормозит на x86.
tail call отдельная песня и к F# отношение вряд ли имеет
А вот то, что простейшие вещи
let rec y a b c =
match a with
| 0 -> b
| _ -> y (a - 1) (b + c) c
в лучшем случае проседают на 5-10%, по сравнению с мутабельным циклом, уже не радует.
F# упорно делает c = c; в середине цикла. Вопрос зачем? Уж такую то элементарщину (чай не клиновский Graph Rewriting) можно было сделать?
Здравствуйте, samius, Вы писали:
S>Может речь об этом?
S>
S>let rec fac n a x =
S> match n with
S> | 1 -> a
S> | _ -> fac (n-1) (a * n) x
S>
S>
S>[CompilationArgumentCounts(new int[] { 1, 1, 1 })]
S>public static int fac<a>(int n, int a, a x)
S>{
S> while (true)
S> {
S> switch (n)
S> {
S> case 1:
S> return a;
S> }
S> x = x; // Надо или не надо, все параметры переприсваиваются на очередной итерации.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, InCus, Вы писали:
IC>>F# упорно делает c = c; в середине цикла.
DM>А разве JIT это не выкинет?
А должен? В лучшем случае на NOPы заменит, а кеши и такты не резиновые.
Ключевой вопрос в том какого F# вообще гадит подобными конструкциями,
и почему за него должен расплачиваться JIT? JIT в отличии от F# не
позиционировался как интелектуальный оптимизарующий компилятор, насколько я помню.
Здравствуйте, InCus, Вы писали:
IC>Ключевой вопрос в том какого F# вообще гадит подобными конструкциями, IC>и почему за него должен расплачиваться JIT? JIT в отличии от F# не IC>позиционировался как интелектуальный оптимизарующий компилятор, насколько я помню.
Здравствуйте, InCus, Вы писали:
IC>Сказка даже хорошо пропиареная все равно остается сказкой. IC>Разницы, для нормальной системы вывода типов, между
typeof<int>.GetMembers() |> Array.map (fun e -> e.Name)
и
IC>Array.map (fun e -> e.Name) <| typeof<int>.GetMembers()
IC>
нет. Но в F# это не так.
Правильно, я и говорю — система ненормальная и нормальной никогда не будет.
IC>2) Ocaml с нормальным выводом типов и объектной моделью в себе не имеет такой болезни
Объектная модель Окамла проектировалась под вывод типов. Объектная система .net — нет.
IC>3) Сайм, сам признался, что сделать более внятный вывод типов можно,
... но он не сделан, а значит утверждение о том, что это будто бы можно — ничем не обоснованное заявление.
IC>но его ломает анализировать ошибки
Не его. Он пишет что не сможет написать вывод типов, обрабатывающий такие случаи так, чтоб сообщения об ошибках вывода типов были понятными.
IC>В соотвествии с п.3., на рассказы о том, что не работает из-за того, что "система типов расширена" можно не обращать внимание.
Если бы система типов не была расширена — ничего особенного Сайму изобретать и не пришлось.
IC>Самое смешное в происходящем, что компилятор мог бы автоматически выносить IC>(fun e -> e.Name) в GetName и никаких бы проблем с анализом ошибок при этом не произошло, IC>но это же делать надо, а у нас п.3.
Единичный пример не доказывает возможности делать это в общем случае.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, VladD2, Вы писали:
K>А какие ошибки нужно исправить по вашему мнению? VD>Макросы и C-подобный синтаксис.
К счастью эти ошибки в F# уже исправлены. Осталось убрать ООП, добавить ссылочную прозрачность и нормальное type-level программирование (можно начать с добавления hihg-kinded типов).
Здравствуйте, Klapaucius, Вы писали:
K>Ну, вывод типов в Немерле локальный и не выводит наиболее общий тип. При таких условиях тип можно выводить и при наличии сабтайпинга и перегрузок.
Это тут не причем. Перегрузки реально мешают. А вот вывод обобщенного типа или конкретного на сложность не влияет. В F# банально слабый алгоритм. Там используется не сильно модифицированный Хиндли-Милнер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klapaucius, Вы писали:
K>Это не сказка, а суровая правда. Раз система типов расширена, чистый Х-М не работает, и по всей видимости, нужно как-то изворачиваться, используя эвристики. Эвристики всех случаев не покрывают, разумеется, и не во всех случаях ведут к правильному решению.
Нужно просто делать вывод типов в несколько проходов. Москаль описал алгоритм почти 7 лет назад. Могли бы за 7 лет уже и прочесть. Тем более что москаль во всю использует F# и работает в МС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Klapaucius, Вы писали:
K>>Ну, вывод типов в Немерле локальный и не выводит наиболее общий тип. При таких условиях тип можно выводить и при наличии сабтайпинга и перегрузок.
VD>Это тут не причем. Перегрузки реально мешают. А вот вывод обобщенного типа или конкретного на сложность не влияет. В F# банально слабый алгоритм. Там используется не сильно модифицированный Хиндли-Милнер.
А почему алгоритм Хиндли-Милнера слабый? Я помню что там вариантность generic параметров не поддерживается, что-то еще, но это не такая большая цена за глобальный вывод типов. Мне кажется, что это просто такой tradeoff. В конечном счете, важнее всего читаемость кода, а в этом плане у F# все немного лучше чем у конкурентов, по крайней мене чисто субъективно, с моей колокольни.
Здравствуйте, Lazin, Вы писали:
L>А почему алгоритм Хиндли-Милнера слабый?
Ну, примитивный он. Что тут еще можно сказать то? Много ограничений. Много случаев когда он не работает. Классика F#-а — f g не срабатывает, в то время как g |> f срабатывает. Потом этот алгоритм не дружит с перегрузкой и приведением типов.
L>Я помню что там вариантность generic параметров не поддерживается, что-то еще, но это не такая большая цена за глобальный вывод типов.
Дык глобальный то вывод типов по жизни никому не нужен. А вот качество вывода типов нужно везде и всегда.
L>Мне кажется, что это просто такой tradeoff. В конечном счете, важнее всего читаемость кода, а в этом плане у F# все немного лучше чем у конкурентов, по крайней мене чисто субъективно, с моей колокольни.
У F# с выводом типов все довольно плохо. О чем тут народ и жалуется. Я не понимю как можно влезть в тему где народ жалуется на вывод типов в F# и при этом как не в чем не бывало утверждать обратное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>А почему алгоритм Хиндли-Милнера слабый?
VD>Ну, примитивный он. Что тут еще можно сказать то? Много ограничений. Много случаев когда он не работает. Классика F#-а — f g не срабатывает, в то время как g |> f срабатывает.
А можешь показать, как конкретно этот баг получается в Хиндли-Милнере? По-моему, никак не должен.
VD>Дык глобальный то вывод типов по жизни никому не нужен.
Зря ты так, очень даже нужен. Т.е. ты, может, и привык без него обходиться, но мой опыт с окамлом говорит, что когда такой вывод типов есть, это очень хорошо и удобно. У меня в компиляторе на две с лишним тыщи строк очень мало где у функций задан явно тип, для подавляющего большинства он просто выводится. А там, где задан, это не из необходимости, а для задания "центра кристаллизации".
Здравствуйте, D. Mon, Вы писали:
DM>Зря ты так, очень даже нужен. Т.е. ты, может, и привык без него обходиться, но мой опыт с окамлом говорит, что когда такой вывод типов есть, это очень хорошо и удобно. У меня в компиляторе на две с лишним тыщи строк очень мало где у функций задан явно тип, для подавляющего большинства он просто выводится. А там, где задан, это не из необходимости, а для задания "центра кристаллизации".
В свое время меня заинтересовали этим языком, сказав что код на нем очень легко читается. Я проверил, взял исходники первого попавшегося проекта, написанного на ocaml который мне удалось найти и начал читать. Так вот, код действительно читается очень хорошо, даже человеком не знакомым с языком. Во многом благодаря тому что очень мало всяких аннотаций и прочего синтаксического мусора. Плюс, паттерн маттчинг и алгебраические типы данных — очень интуитивны и опять же читаются легко. Так что глобальный вывод типов — штука полезная.
Здравствуйте, D. Mon, Вы писали:
VD>>Ну, примитивный он. Что тут еще можно сказать то? Много ограничений. Много случаев когда он не работает. Классика F#-а — f g не срабатывает, в то время как g |> f срабатывает. DM>А можешь показать, как конкретно этот баг получается в Хиндли-Милнере? По-моему, никак не должен.
Этот баг получается потому, что система типов не System F и не какое-то ее расширение, которое придумано с учетом возможности выводить типы. Это система типов .net, в которой нет типа
< foo : 'a; .. >
(это некоторое упрощение, для inline функций нечто похожее есть, но это пока можно оставить за скобками) и, соотвественно, код вроде такого
let foo e = e.Foo;;
Не может быть типизирован. Чтобы как-то с этим справится, Х-М в f# расширен некоей подпоркой, выводящей тип, используя информацию, которая доступна сверху-слева от типизируемого выражения (видимо, чтоб типизировать в один проход). Вот и получается, что так все работает:
> Array.map (fun e -> e.Name) <| typeof<int>.GetMembers()
- ;;
Array.map (fun e -> e.Name) <| typeof<int>.GetMembers()
--------------------^^^^^^
stdin(1,21): error FS0072: Lookup on object of indeterminate type based on information
prior to this program point. A type annotation may be needed prior to this program
point to constrain the type of the object. This may allow the lookup to be resolved.
Если же никакие сабтайпинги-перегрузки не используются — разницы нет:
> Array.map ((+) 1) <| [|1; 2; 3|];;
val it : int [] = [|2; 3; 4|]
> [|1; 2; 3|] |> Array.map ((+) 1);;
val it : int [] = [|2; 3; 4|]
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, D. Mon, Вы писали:
DM>А можешь показать, как конкретно этот баг получается в Хиндли-Милнере? По-моему, никак не должен.
В этом алгоритме вывод типов идет в одни проход. Это требует чтобы тип всех выражений мог быть выведен из предыдущего кода. И если складывается ситуация, что тип f можно вычислить только когда будет известен тип g, то получается вот такая вот дурь — f g не прокатывает, а g |> f проходит.
Кроме того оригинальный HM не поддерживал подтипы (читай ООП), параметрический полиморфизм и т.п. Потом было много работ решающий эти проблемы. Но успеха добились только Мартин Одесски и разработчики немерла. (хотя, возможно я чего-то не знаю)
Одесски (автор Скалы) предложил свой алгоритм для локального вывода типов в ООЯ (если не ошибаюсь — это было расширение HM). Москаль (автор вывода типов Немерла) усовершенствовал его сделав его многопроходным. Потом алгоритм Немерла допиливался мой еще несколько раз (сам себя не похвалишь... ).
На сегодня, на мой взгляд, алгоритм вывода типов немерла самый "умный". Найти разумный случай в котором споткнется современный алгоритм немерла очень не просто.
VD>>Дык глобальный то вывод типов по жизни никому не нужен.
DM>Зря ты так, очень даже нужен.
Я то тут прчим? Любой толковый программист тебе сразу скажет, что по крайней мере, типы для публичного интерфейса всегда нужно описывать явно.
DM>Т.е. ты, может, и привык без него обходиться, но мой опыт с окамлом говорит, что когда такой вывод типов есть, это очень хорошо и удобно. У меня в компиляторе на две с лишним тыщи строк очень мало где у функций задан явно тип, для подавляющего большинства он просто выводится. А там, где задан, это не из необходимости, а для задания "центра кристаллизации".
Ну, вот ты и сам подтверждаешь мои слова. Только нужно понять, что твоя "центра кристаллизация" — это на самом деле описание "контракта" коим и является публичный интерфейс.
В Немерле тоже в 99% случаев описывать типы не нужно. Основной (по объему) код расположен в телах методов. В теле метода ты можешь описывать десятки вложенных функций не вписав ни одного типа. Типы же требуется задавать для полей и сигнатур методов, тем самым специфицируя интерфейс.
Писать же объемный код не указывая типов — это форменный идиотизм. Первая ошибка в типах может обернутся в кашу из сообщений компилятора который будет указывать куда угодно, только не в место где появилась реальная проблема.
Так что глобальный вывод типов — это такая игрушка в которую можно поиграть, но которую лучше не использовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
DM>>А можешь показать, как конкретно этот баг получается в Хиндли-Милнере? По-моему, никак не должен.
VD>В этом алгоритме вывод типов идет в одни проход. Это требует чтобы тип всех выражений мог быть выведен из предыдущего кода.
Это Х-М такой? Правда?
VD>Я то тут прчим? Любой толковый программист тебе сразу скажет, что по крайней мере, типы для публичного интерфейса всегда нужно описывать явно.
Прямо так и всегда? Вот есть у меня объявление
let my_global_const = 42
неужели так нужно выписывать рядом очевидный факт, что это int?
Или есть оператор композиции
let (|>) x f = f x
тип которого тоже тривиален, зачем его явно выписывать?
Для чего-нибудь сложного да, явные типы работают документацией и несут пользу.
DM>>Т.е. ты, может, и привык без него обходиться, но мой опыт с окамлом говорит, что когда такой вывод типов есть, это очень хорошо и удобно. У меня в компиляторе на две с лишним тыщи строк очень мало где у функций задан явно тип, для подавляющего большинства он просто выводится. А там, где задан, это не из необходимости, а для задания "центра кристаллизации".
VD>Ну, вот ты и сам подтверждаешь мои слова. Только нужно понять, что твоя "центра кристаллизация" — это на самом деле описание "контракта" коим и является публичный интерфейс.
Не-а. Какой еще контракт, когда из 10 функций описан тип одной или даже менее одной (можно задать тип отдельного параметра, не задавая остальных).
VD>Писать же объемный код не указывая типов — это форменный идиотизм. Первая ошибка в типах может обернутся в кашу из сообщений компилятора который будет указывать куда угодно, только не в место где появилась реальная проблема.
Собственно, чтобы не появлялась такая каша, у меня и указан тип в паре мест, этого хватает, чтобы компилятор не выдумывал глупостей и не порождал каши. Это я и называю центром кристаллизации — когда вокруг одного правильно указанного типа как в домино или в кристалле складываются правильно остальные типы.
VD>Так что глобальный вывод типов — это такая игрушка в которую можно поиграть, но которую лучше не использовать.
Да нет же, это просто удобный инструмент, который надо использовать с пользой — пусть хотя бы там, где типы вполне очевидны, выводит их сам. Я не против их ручного описания там, где это полезно или необходимо программисту, но обычно это далеко не 100% методов / функций.
Здравствуйте, D. Mon, Вы писали:
VD>>В этом алгоритме вывод типов идет в одни проход. Это требует чтобы тип всех выражений мог быть выведен из предыдущего кода.
DM>Это Х-М такой? Правда?
По крайней мере та разновидность что используется в F#.
Вообще, чистый Х-М, наверно, вообще не применим в современных языках, так как трудно сере представить, чтобы IDE на каждый чих парсила бы весь проект, строила бы уравнение типов, а потом его заново решала бы. Плюс это не работает в условиях перегрузки.
VD>>Я то тут прчим? Любой толковый программист тебе сразу скажет, что по крайней мере, типы для публичного интерфейса всегда нужно описывать явно.
DM>Прямо так и всегда? Вот есть у меня объявление DM>let my_global_const = 42 DM>неужели так нужно выписывать рядом очевидный факт, что это int?
Для констант и даже для константных выражений можно сделать исключение. В немерле так и сделано, кстати.
DM>Или есть оператор композиции DM>let (|>) x f = f x DM>тип которого тоже тривиален, зачем его явно выписывать?
Затем, чтобы его нельзя было нечаянно применить в неверном контексте.
С константами все ясно, так как они сами задают тип (не явно).
С функциями же все не так очевидно.
Потом не ясно где провести границу между простыми и сложными выражениями. Человеку легко сказать "выражение простое", но что это означает для компилятора?
Еще одной проблемой глобального вывода типов является то, что типы это негативно влияет на работу IDE, которым нужно икрементально обновлять внутреннюю информацию.
Если у нас есть модули типы которых могут меняться в зависимости от контекста их использования, то система становится принципиально не масштабируемой и не надежной.
Ну, а если типы не могут выходить за пределы модулей (классов для ООЯ), то логично было бы заставить явно декларировать типы для того что экспортируется во вне.
DM>Для чего-нибудь сложного да, явные типы работают документацией и несут пользу.
А где провести эту границу?
По жизни же будет так — если можно не писать типы, то найдутся те кто не будет их писать нигде и ни когда. А потом от этого будут страдать окружающие.
Так не логичнее было бы заранее определить те места где нужно писать типы, введя некоторый стандарт?
VD>>Ну, вот ты и сам подтверждаешь мои слова. Только нужно понять, что твоя "центра кристаллизация" — это на самом деле описание "контракта" коим и является публичный интерфейс.
DM>Не-а. Какой еще контракт, когда из 10 функций описан тип одной или даже менее одной (можно задать тип отдельного параметра, не задавая остальных).
Публичный. Главное, что описание сигнатур публичных функций — это ни разу не напряжно. Их действительно очень не много, по сравнению с кодом реализации.
VD>>Писать же объемный код не указывая типов — это форменный идиотизм. Первая ошибка в типах может обернутся в кашу из сообщений компилятора который будет указывать куда угодно, только не в место где появилась реальная проблема.
DM>Собственно, чтобы не появлялась такая каша, у меня и указан тип в паре мест, этого хватает, чтобы компилятор не выдумывал глупостей и не порождал каши.
Ну, а есть какие-то четки правила в каких местах нужно указывать типы? Ты может и можешь найти золотую середину, но дргие нет.
Потом для языка на котором ты пишешь есть IDE (или дугой тул) которая может показать типы любой части программы? Если нет, то твой код будет ой как не просто изучать непосвященному.
Я вот имею не малый опыт чтения и правки кода где типы указываются раз в год по обещанию. И я четко вижу, что понять смысл кода намного проще в условиях когда можно легко узнать какой тип имеет то или иное выражение/идентификатор.
DM>Это я и называю центром кристаллизации — когда вокруг одного правильно указанного типа как в домино или в кристалле складываются правильно остальные типы.
А я это называю безалаберностью. Пока ты работаешь над кодом один, может это и прокатит. В промышленном коде — это неприемлемо. Должны быть стандарты обеспечивающие качество. И лучше, если эти стандарты гарантируются зыком и его компилятором.
VD>>Так что глобальный вывод типов — это такая игрушка в которую можно поиграть, но которую лучше не использовать.
DM>Да нет же, это просто удобный инструмент, который надо использовать с пользой — пусть хотя бы там, где типы вполне очевидны, выводит их сам. Я не против их ручного описания там, где это полезно или необходимо программисту, но обычно это далеко не 100% методов / функций.
Дык никто не говорит о 100%. Если посмотреть на немерл (за скалу не скажу, но наверно и так примерно так же), то на каждый публичный метод приходится по несколько локальных функций. Понятно, что тут работает специфика ООЯ. Но для чистого ФЯ (читай для чисто процедурного языка ) такой границей могут выступать границы модуля.
Ну, а уточнять типы в местах что программист сочтет нужным — это уже полезная возможность.
Главное, что есть четка граница не дающая получить сильно связанный код и вытекающие из этого проблемы.
Потому я и утверждаю, что глобальный вывод типов не нужен. И между хреновым, но глобальным выводом типов F# и локальным, но качественным выводом типов Nemerle я не задумываясь выберу второй вариант.
Для языков типа Хаскеля, где нет перегрузки функций (за исключением классов типов, которые только с натяжкой можно отнести к перегрузки) и приведения типов можно создать довольно эффективный глобальный вывод. Но для ООЯ это уже слишком сложно. F# и так жертвует приведением типов и совместимостью с другими языками .Net ради эфемерных преимущество.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>А где провести эту границу?
А зачем ее проводить? У каждого человека(команды) свой стиль программирования, если кому то хочется глобальный вывод и они прикрасно с ним живут, зачем их застовлять что то там описывать?
Вот пишут я на хаскеле, в начале все сигнатуры методов могут менятся по сто раз, как только более менее устаканится можно нажать волшебное сочитание и у метода автоматов пропишется тип.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, VladD2, Вы писали: VD>>А где провести эту границу?
D>А зачем ее проводить? У каждого человека(команды) свой стиль программирования, если кому то хочется глобальный вывод и они прикрасно с ним живут, зачем их застовлять что то там описывать?
Какой еще стиль? Это смелый и решительный шаг к завалу проекта даже средней сложности.
D>Вот пишут я на хаскеле, в начале все сигнатуры методов могут менятся по сто раз, как только более менее устаканится можно нажать волшебное сочитание и у метода автоматов пропишется тип.
Ну, вот и экспериментируй себе в песочнице. А когда добавляешь код в большой проект, то будь добр нажать свою волшебную кнопку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Потом не ясно где провести границу между простыми и сложными выражениями. Человеку легко сказать "выражение простое", но что это означает для компилятора?
Ну так границу человек будет проводить, а не компилятор. Так что формализовать ее не нужно. Кому как удобнее, тот так и проведет. Главное, чтобы компилятор не мешал это делать.
VD>Потом для языка на котором ты пишешь есть IDE (или дугой тул) которая может показать типы любой части программы? Если нет, то твой код будет ой как не просто изучать непосвященному.
Да, в моем случае OcaIDE по наведению мыши показывает тип любого выражения и функции.
С твоими соображениями про IDE, про работу в команде и пр. я согласен.
Здравствуйте, VladD2, Вы писали:
D>>Вот пишут я на хаскеле, в начале все сигнатуры методов могут менятся по сто раз, как только более менее устаканится можно нажать волшебное сочитание и у метода автоматов пропишется тип. VD>Ну, вот и экспериментируй себе в песочнице. А когда добавляешь код в большой проект, то будь добр нажать свою волшебную кнопку.
Так экспериментировать-то даже в песочнице нельзя, если глобального вывода типов нет — приходится всегда указывать. Кроме того, отображение сигнатуры с типами в случае их автоматического вывода — это чисто технический вопрос, его можно, например, так решить:
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[24]: Популярность F#
От:
Аноним
Дата:
06.10.11 11:05
Оценка:
Здравствуйте, Klapaucius, Вы писали:
О! К картинке вопросик: это что ж, живой VisualHaskell к 2010 студии? Где такие раздают?
Здравствуйте, Klapaucius, Вы писали:
K>Так экспериментировать-то даже в песочнице нельзя, если глобального вывода типов нет — приходится всегда указывать.
Ой, да ладно придумывать то. Для песочницы локальный вывод типов отличается от глобального только тем, что приходится указывать типы у описаний типов. Все игры ведутся на базе локальных функций (которые, кстати, ничем не отличаются от глобальных в языках типа F#), в которых так же действует вывод типов.
На то она и песочница чтобы быть маленькой. В рамках песочницы можно на каждый раз перепарсивать и перетипизировать весь код. А вот в большом проекте так не удастая.
То что в F# слабый вывод типов — это как раз, плата за совмещение глобальности с необходимостью интерактивной работы (в IDE).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
K>>Так экспериментировать-то даже в песочнице нельзя, если глобального вывода типов нет — приходится всегда указывать. VD>Для песочницы локальный вывод типов отличается от глобального только тем, что приходится указывать типы у описаний типов. Все игры ведутся на базе локальных функций (которые, кстати, ничем не отличаются от глобальных в языках типа F#), в которых так же действует вывод типов.
"Песочница" — это, допустим, модуль, который сейчас разрабатывается. Можно его писать "от типов" — указать сначала типы функций, а потом уже писать код. А можно комбинировать имеющиеся — а типы будут какие получатся, и пока идет активное экспериментирование с кодом сигнатуры бы приходилось постоянно переисывать — зачем это нужно? На завершающем этапе их можно записать явно для документации (причем это можно сделать автоматически). Плюс некоторые комбинации первого и второго подходов. Второй подход без глобального вывода типов не работает, так что и выбора никакого не будет.
VD>На то она и песочница чтобы быть маленькой. В рамках песочницы можно на каждый раз перепарсивать и перетипизировать весь код. А вот в большом проекте так не удастая.
Зачем весь код? Модуль с которым мы работаем и те модули, которые на него ссылаются. Для автокомплита/подсказок и т.д. внутри модуля, с которым сейчас работаем перекомпилировать/тайпчекать те, которые от него зависят не нужно.
Вообще, под локальным выводом типов понимаются локальные функции и значения — вложенные в методы функции в Немерле, например. Поэтому не нужно говорить, что в случае "Локального" вывода типов нужно указывать типы только для публичных контрактов, которые и так нужно указывать и которые, в общем-то, часто зарание известны. Потому, что для локальных, неэкспортируемых методов, которые за пределами класса никто не видит — тоже придется сигнатуры с типами указывать. Вот в них-то как раз и проблема. Для ФЯ — это серьезная проблема, потому как в них пишется масса простых функций, для которых тип будет длиннее кода и который не особенно полезен. И функции эти постоянно изменяются в ходе экспериментов и поэтому переписывать для них типы каждый раз — элементарно неудобно. Не все из них можно сделать вложенными, да и те что можно — часто лучше не делать, потому как вложенные недоступны из REPL.
VD>То что в F# слабый вывод типов — это как раз, плата за совмещение глобальности с необходимостью интерактивной работы (в IDE).
Не согласен. Это плата за совмещение с ситемой типов .net, которая на глобальный вывод типов не рассчитана. И да, не факт, что глобальный вывод типов для .net-языка — это хорошая идея. Но это не означает, что для языка с другой системой типов, спроектированной с учетом возможности выводить типы, глобальный вывод типов оказется плохой идеей. как раз наоборот — там глобальный вывод типов желателен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, InCus, Вы писали:
IC>>в лучшем случае проседают на 5-10%, по сравнению с мутабельным циклом, уже не радует.
K>Впечатляющий недостаток, конечно, на фоне остальных, ухудшающих производительность в разы.
С этого места подробнее. Только без обуждения убогости разработки гуев. Что в разы садит производительность кода на F#?
Здравствуйте, dsorokin, Вы писали:
D>Здравствуйте, InCus, Вы писали:
IC>>Ключевой вопрос в том какого F# вообще гадит подобными конструкциями, IC>>и почему за него должен расплачиваться JIT? JIT в отличии от F# не IC>>позиционировался как интелектуальный оптимизарующий компилятор, насколько я помню.
D>А зачем писать такие функции?
Здравствуйте, InCus, Вы писали:
IC>Что в разы садит производительность кода на F#?
CLR. Всё так называемое ФП в F# натянуто натянуто на CLR-ные объекты. Их получается ну очень много (каждый элемент списка, или каждая функция — отдельный объект), больше чем в классическом ООП. А логика их работы сложнее, чем тех же санков, бо проектировались они для решения более широкого круга задач.
Ну и отсутсвие оптимизаций, свойственных ФЯ. Не будет в F# stream fusion (т.к. список — набор обычных CLR-ных объектов, фьюзить их не совсем корректно), не будет распаковки пареметров туплов (т.к. тупл — тоже CLR-ный объект, с чего бы его распаковывать?) и тому подобного.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, InCus, Вы писали:
IC>>Что в разы садит производительность кода на F#?
ПМ>CLR. Всё так называемое ФП в F# натянуто натянуто на CLR-ные объекты. Их получается ну очень много (каждый элемент списка, или каждая функция — отдельный объект), больше чем в классическом ООП. А логика их работы сложнее, чем тех же санков, бо проектировались они для решения более широкого круга задач.
ПМ>Ну и отсутсвие оптимизаций, свойственных ФЯ. Не будет в F# stream fusion (т.к. список — набор обычных CLR-ных объектов, фьюзить их не совсем корректно), не будет распаковки пареметров туплов (т.к. тупл — тоже CLR-ный объект, с чего бы его распаковывать?) и тому подобного.
Натануто естессно. А как же иначе. F# _обязан_ поддерживать совместимость по типам с фреймфорком. Сейчас F# это просто доставалка данных, а данные приходится визуализировать, чем то более вменяемым для построения гуйни. Если F# не будет натянут на CLR, то визуализатор не сможет ни иницировать получение данных, ни распознать их, что сведет смысл существования F# к 0. Утверждать, что проблемой является то без чего F# просто лишен смысла, в целом некорректно.
ПМ>... stream fusion ...
Я правильно понимаю что это такой хаскельный аналог модуля Seq?
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, InCus, Вы писали:
IC>>но его ломает анализировать ошибки
K>Не его. Он пишет что не сможет написать вывод типов, обрабатывающий такие случаи так, чтоб сообщения об ошибках вывода типов были понятными.
Че он там пишет, я понимаю. В переводе на человечий это назвается. "Кто хочет — тот делает, кто не хочет — ищет причины".
IC>>В соотвествии с п.3., на рассказы о том, что не работает из-за того, что "система типов расширена" можно не обращать внимание.
K>Если бы система типов не была расширена — ничего особенного Сайму изобретать и не пришлось.
Да что ж это за мантра то такая про "расширенную систему типов".
В GetName она не мешает, а в fun e -> e.Name она вот никак.
При этом, что типы обеих функций совершенно! одинаковые. Ну при чем тут расширение системы типов?
IC>>Самое смешное в происходящем, что компилятор мог бы автоматически выносить IC>>(fun e -> e.Name) в GetName и никаких бы проблем с анализом ошибок при этом не произошло, IC>>но это же делать надо, а у нас п.3.
K>Единичный пример не доказывает возможности делать это в общем случае.
Это не единичный пример. Это стандарный шаблон обхода ограничений F#.
Здравствуйте, InCus, Вы писали:
IC>Утверждать, что проблемой является то без чего F# просто лишен смысла, в целом некорректно.
Вопрос был про производительность, я ответил.
IC>Я правильно понимаю что это такой хаскельный аналог модуля Seq?
С очень большой натяжкой. Stream fusion нужно, чтобы не создавать промежуточные структуры данных, Seq тоже в какой-то степени позволяет избегать создания промежуточных списков, но Seq:
1. Seq не Stream. Seq слабее. Ты не сможешь, например, пробежаться до 5-го элемента, запомнить его, потом пробежать дальше, потом вернуться к 5-му элементу и снова пробежаться с него. Seq позволяет только заново пройти по всему списку.
2. Seq не поддерживает Fusion. Поскольку не устраняет промежуточных структур, а просто заменяет их другими (т.е. самой Seq). По идее Seq.map a << Seq.map b долно преврящаться в Seq.map (a << b) но этого не происходит.
Здравствуйте, Klapaucius, Вы писали:
K>Если же никакие сабтайпинги-перегрузки не используются — разницы нет: K>
>> Array.map ((+) 1) <| [|1; 2; 3|];;
K>val it : int [] = [|2; 3; 4|]
>> [|1; 2; 3|] |> Array.map ((+) 1);;
K>val it : int [] = [|2; 3; 4|]
K>
Не совсем так. Все еще хуже. В данных примерах типы вводятся только потому, что работа идет с константами (которые по определению имеют конерктный тип).
Но в главном я с тобой согласен — алгоритм вывода типов в F# очень слабенький. В МС могли бы и почитать работы авторов Скалы и Немерла. Там есть все ответы на все вопросы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Популярность F#
От:
Аноним
Дата:
10.10.11 09:13
Оценка:
Здравствуйте, VladD2, Вы писали:
K>>Я не считаю, что C-подобный синтаксис подходит для ФЯ.
VD>Он подходит для популярных языков. VD>Если популярность не важна, то можно иметь любой синтаксис.
Ну ну, расскажи это тем, кто пишет на популярнейшем языке Delphi или на популярнейшем языке Python.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ> не будет распаковки пареметров туплов (т.к. тупл — тоже CLR-ный объект, с чего бы его распаковывать?) и тому подобного.
Здравствуйте, Аноним, Вы писали:
А> Ну ну, расскажи это тем, кто пишет на популярнейшем языке Delphi или на популярнейшем языке Python.
На фоне си-подобных языков, я бы не осмелился назвал их особо популярными.
Но в сравнении с ML-ым синтаксисом, алгол-подобные языки (вроде Дельфи) выглядят классикой.
Не трудно заметить, что все, хоть сколько-нибудь популярные языки, имеют привычный по математике средней школы синтаксис вызова функций. Языки же с ML-ным синтаксисом так на всегда и останутся маргинальными. Массы их никогда не примут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не трудно заметить, что все, хоть сколько-нибудь популярные языки, имеют привычный по математике средней школы синтаксис вызова функций. Языки же с ML-ным синтаксисом так на всегда и останутся маргинальными. Массы их никогда не примут.
Как хорошо, что еще остались люди, готовые делать маргинальные языки. Благодаря им мы имеем хорошие вещи. А yet another java не нужна. По крайней мере мне, как деплоймент-иженеру.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Как хорошо, что еще остались люди, готовые делать маргинальные языки. Благодаря им мы имеем хорошие вещи.
Ага, замечательно! Это называется научные исследования. Жаль только, что в нашей, компьютерной, сфере наука живет отдельно, а производство отдельно. Во всех других сферах жизнедеятельности человека наука разрабатывает новые идеи, а практики адаптируют их для реальной жизни и внедряют в практику. У нас же складывается страннейшая ситуация. В реальную практику попадают только микроскопические крохи научных разработок.
ПМ>А yet another java не нужна. По крайней мере мне, как деплоймент-иженеру.
А я, вот, как программист, не только не против, но и пригрел одну такую. И мне на фиг не упали разные Хаскели и тем более F#-ы (в которых интересного для меня ноль целых ноль десятых). Потому как для того чтобы писать реальный софт нужны тонны библиотек, IDE с рефакторингом блэкджеком и шлюхами и многое другое, а не мегафичи единственным осмысленным применением которых является удовлетворение своего ЧСВ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ага, замечательно! Это называется научные исследования. Жаль только, что в нашей, компьютерной, сфере наука живет отдельно, а производство отдельно. Во всех других сферах жизнедеятельности человека наука разрабатывает новые идеи, а практики адаптируют их для реальной жизни и внедряют в практику. У нас же складывается страннейшая ситуация. В реальную практику попадают только микроскопические крохи научных разработок.
Ты драматизируешь. Разработки, имеющие реальный экономический эффект, попадают в практику очень быстро. Вспомни, как быстро стали популярными языки с мусоросборниками или реляционные базы данных. Не думаю, что в каком-нибудь автобизнесе путь от исследования до реализации на конвеере проходится быстрее.
VD>Потому как для того чтобы писать реальный софт нужны тонны библиотек, IDE с рефакторингом блэкджеком и шлюхами и многое другое, а не мегафичи единственным осмысленным применением которых является удовлетворение своего ЧСВ.
Кстати, конкретно у Хаскеля с библиотеками не всё так плохо — часто легко можно найти то, что трудно найти для C# (если вообще возможно). Качество самих библиотек, конечно, не промышленное, но благодаря языку они довльно компактны и легко допиливаются без боязни что-либо сломать. Часто это даже быстрее чем разбираться в донетовских боингах, с которыми уже, как правило, ничего не сделать, если там что-то не так.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>А IDE для девочек. Настоящие мужики разводят костёр с одной спички, бреются остро заточенным топором и программируют в голом текстовом редакторе.
Ну, да. Имели мы в виду этот прогресс! Бриться электробритвой, для разведения костра использовать стакан бензина, и писать много качественного кода с первой попытки — это все для слабаков!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ArtDenis, Вы писали:
AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
Учитавая реакцию Сайма на самое популярное предложение про тайпклассы
(в переводе "а-а-а... мне мешает CRL, который я и разрабатывал и, вообще,
что это вы мне предлагаете, что б я работал, это другие должны делать"),
все что займет на разработку больше 2 недель (больше никак нельзя —
времени на поездки в лондон на презентухи не останется) сделано
не будет. Ни одной акцепнутой идеи для F# на текущий момент нет.
Значит нам на все ваши хотелки ... — мы все равно будем в песочнице делать,
что нам интересно, а для отмаза у нас есть стандарный набор фраз, которые
будут использоваться пока народ ведется, и группа верующих, несущих эти
кривые отмазы в народ.
Re[18]: Популярность F#
От:
Аноним
Дата:
18.10.11 08:25
Оценка:
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Кстати, конкретно у Хаскеля с библиотеками не всё так плохо — часто легко можно найти то, что трудно найти для C# (если вообще возможно). Качество самих библиотек, конечно, не промышленное, но благодаря языку они довльно компактны и легко допиливаются без боязни что-либо сломать. Часто это даже быстрее чем разбираться в донетовских боингах, с которыми уже, как правило, ничего не сделать, если там что-то не так.
Ставил тут на днях yesod поиграться через cabal (haskell). Порой веселое занятие. Некоторые пакеты не хотели собираться. В одном пакете вообще была опечатка в коде.
Здравствуйте, VladD2, Вы писали:
VD>В этом алгоритме вывод типов идет в одни проход. Это требует чтобы тип всех выражений мог быть выведен из предыдущего кода. И если складывается ситуация, что тип f можно вычислить только когда будет известен тип g, то получается вот такая вот дурь — f g не прокатывает, а g |> f проходит.
Проверил, как с этим обстоят дела в Немерле:
def f(x) { x.ToLower() }
_ = f("ABC") // OK
def f(x) { x.ToLower() } // Error: typing fails on accessing member ToLower in the ? type_ = "ABC" |> f // Error: typing fails on ambiguity between operator |>(string, ? -> ?) overloads
Прокатывает, но не проходит. Как говорится, у каждого свои недостатки
N>def f(x) { x.ToLower() } // Error: typing fails on accessing member ToLower in the ? type
N>_ = "ABC" |> f // Error: typing fails on ambiguity between operator |>(string, ? -> ?) overloads
N>
N>Прокатывает, но не проходит. Как говорится, у каждого свои недостатки
Это скорее недоработка реализации. В принципе тут можно вывести тип, так как x.ToLower() для void не может быть стипизированна. Вот так вот все будет работать:
Здравствуйте, Klapaucius, Вы писали:
K>Популярность у него не только на этом форуме маленькая. Она так же мала и на stackowerflow, и на GitHub, и на reddit. K>Лично я о своем (небольшом) опыте написания программ на нем сюда не пишу, чтоб не докучать своими жалобами, для этого у меня есть специальный микроблог, который никто не читает.
Честно говоря, не все твои жалобы понятны. Взять тот же Eval Selected. Честно говоря, я вообще не очень представляю как *должна* работать эта фича. Она по любому странная. Что она должна делать? Выдирать выражение из контекста и исполнять его в глобальном скопе? Лексах так и делает:
sumIt x y = x + y
x = <sumIt 2 2>where sumIt x y = x - y
Выделяем <выделенное>, исполняем. Результат — 4. Хорошо ли это?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Взять тот же Eval Selected. Честно говоря, я вообще не очень представляю как *должна* работать эта фича. Она по любому странная. Что она должна делать? Выдирать выражение из контекста и исполнять его в глобальном скопе?
Для начала было бы неплохо, чтоб она хоть как-то работала. Это не самый плохой вариант.
ВВ>Лексах так и делает: ВВ>
ВВ>sumIt x y = x + y
ВВ>x = <sumIt 2 2>
ВВ> where sumIt x y = x - y
ВВ>
ВВ>Выделяем <выделенное>, исполняем. Результат — 4. Хорошо ли это?
Хорошего тут, конечно, мало, но это пример (по моему опыту) не типичный. Даже убогая leksah-овая реализация работает в достаточном числе случаев, чтоб быть полезной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Для начала было бы неплохо, чтоб она хоть как-то работала. Это не самый плохой вариант.
Не знаю, мне кажется вначале имеет смысл определиться в том, как именно должна работать та или иная фича. В противном случае вообще непонятно, о чем разговор. Пока что видно, что в visual f# она делает ровно то, что "на заборе написано", а именно — eval selected. В Лексах же присутствует некая химия, причем по ходу выражение просто выполняется в контексте топ левела. Если это и есть идеал, к которому хочется стремииться, то почему бы просто не пользоваться реплом?
K>Хорошего тут, конечно, мало, но это пример (по моему опыту) не типичный. Даже убогая leksah-овая реализация работает в достаточном числе случаев, чтоб быть полезной.
Полезной для чего? В каких случаях ты пользуешься этой фичей? И как, согласно твоим ожиданиям, она должна работать в visual f#? Ты ведь прекрасно понимаешь, что f# — это stateful язык с форвард декларацией, что вносит свои нюансы.
В любом случае все это так — мелкие фишки. Их наличие или отсутствие погоды не делает. Мне, например, куда важнее, как работает подсветка ошибок в редакторе — отличная почва для сравнения лексах и вижуал шарпа. Или интегрированный дебаг.
Пока что получается, что VisualF# — это пускай и простенькая, но все же весьма употребимая IDE. Но вот про Лексах, к сожалению, я не могу сказать того же. Вот когда Visual Haskell перейдет из категории анимированных гифок в состояние хотя бы употребимой беты, то тогда можно будет сранивать и критиковать. Пока же то, что есть у эф шарпа гораздо лучше того, что есть у Хаскелла — поэтому и критика Visual F# в стиле "я нашел фичу, которая реализована в нем даже хуже, чем в Лексах" мне кажется несколько странной.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не знаю, мне кажется вначале имеет смысл определиться в том, как именно должна работать та или иная фича. В противном случае вообще непонятно, о чем разговор. Пока что видно, что в visual f# она делает ровно то, что "на заборе написано", а именно — eval selected.
Т.е. ничего. Потому, что в "stateful языке с форвард декларацией" вычислить выделенный текст можно только в одном случае — если выделение начинается с первой строки первого файла и заканчивается тем выражением, которое мы хотим вычислить. Именно такого поведения я и ожидаю. Т.е. загрузки в репл всего проекта до выбранной строчки.
ВВ>В Лексах же присутствует некая химия, причем по ходу выражение просто выполняется в контексте топ левела. Если это и есть идеал, к которому хочется стремииться, то почему бы просто не пользоваться реплом?
Но репл f# отличается от репла хаскеля тем же. Репл хаскеля вычисляет выражение в контексте топлевела (кстати, репловый топлевел хаскеля тоже "stateful с форвард декларацией" т.е. находится внутри do блока). Все нужные зависимости он подгрузит сам. fsi ничего этого не делает — т.е. и репл не работает нормально. Все зависимости и порядок файлов для загрузки известны — они в файле проекта. Но никакой загрузки не происходит.
Кроме того, репл хаскеля может вычислять не только в контексте топлевела, но и в контексте любого выражения — чтоб в него попасть нужно поставить там брекпойнт и вычислить. В ghci это все сделано небезупречно. Например, нельзя поставить брекпойнт на функцию объявленную в репле:
Prelude> let foo x = bar 2 x where bar = (+)
Prelude> :break foo
cannot set breakpoint on foo: foo is not defined in an interpreted module
Но в f# этого всего вообще нет.
ВВ>Полезной для чего? В каких случаях ты пользуешься этой фичей?
Для того же, для чего и репл полезен. Опробовать функцию так и эдак. Быстро и без излишних хлопот. В leksah можно еще и тип выражения узнать — а в интеграции f# со студией — только тип символа, что довольно таки бесполезно.
ВВ>И как, согласно твоим ожиданиям, она должна работать в visual f#? Ты ведь прекрасно понимаешь, что f# — это stateful язык с форвард декларацией, что вносит свои нюансы.
Про нюансы выше. Репл у всех стат. языков с лексическим скоупом одинаковый. По другому только во вской динамике типа pure.
ВВ>В любом случае все это так — мелкие фишки. Их наличие или отсутствие погоды не делает.
Наличие более-менее работающего репл и его интеграция в иде с одной стороны и репл сделанный для галочки, который нормально работать не может с другой — это погоду лично для меня делает.
Кроме того, репл хаскеля с каждой версией становится лучше (про его интеграцию с leksah, правда, такого не скажешь) — в случае fsi никаких улучшений нет вообще. В интеграции f# со студией я улучшений тоже не заметил.
ВВ>Мне, например, куда важнее, как работает подсветка ошибок в редакторе — отличная почва для сравнения лексах и вижуал шарпа.
И в чем тут принципиальное различие?
ВВ>Или интегрированный дебаг.
На мой взгляд, дебаг в visual f# интегрирован отвратительно. После остановки на брекпойнте почти все окружающие значения не просматриваются. В этом плане отладчик у хаскеля получше — там в точке остановки полноценный репл доступен. Плюс дотнетного отладчика, конечно, в том, что скомпилированный для отладки код быстро работает. В случае хаскеля все иначе.
ВВ>Пока что получается, что VisualF# — это пускай и простенькая, но все же весьма употребимая IDE.
Я, как употребитель, очень недоволен. Сейчас даже больше, чем тогда, когда писал претензии первый раз. Потому, что с тех пор я успел ознакомится с бетой новой студии и выяснил, что там все то же самое. Прогресс невооруженным взглядом не заметен.
ВВ>Но вот про Лексах, к сожалению, я не могу сказать того же.
Что visual f#, что leksah — жалкие поделки, к сожалению. Играют они в одной лиге — принципиальных различий между ними нет. С нормальными иде индустриального качества вроде тех, что есть для Java/c# их просто смешно сравнивать. При этом официальная поддержка f# совсем не подготавливает к встрече с поделкой вроде leksah, как раз наоборот, ожидаешь поддержку приближенную по качеству к visual c#.
ВВ>Вот когда Visual Haskell перейдет из категории анимированных гифок в состояние хотя бы употребимой беты, то тогда можно будет сранивать и критиковать.
Полагаю, что этого никогда не произойдет.
ВВ>Пока же то, что есть у эф шарпа гораздо лучше того, что есть у Хаскелла — поэтому и критика Visual F# в стиле "я нашел фичу, которая реализована в нем даже хуже, чем в Лексах" мне кажется несколько странной.
Все гораздо хуже. Фич, которые в leksah реализованы лучше, чем в Visual f# больше одной и их не нужно искать. В f# в отличие от leksah, например, нет аутлайна, браузера имен. Найти готовую функцию из библиотеки, когда пишешь на f# — серьезный челлендж. В случае хаскеля такой проблемы нет. У f# даже явного преимущества по качеству автокомплита нет — что особенно удивительно (автокомплит для f# все-таки сделать проще, особенно в условиях библиотеки, которая состоит из "неоткрываемых" модулей и прочих милых (для автокомплита, но не для программиста) вещей).
Самое смешное тут в том, что положительные стороны leksah я и не заметил бы, если бы не знакомство с Visual f# — до этого самого знакомства я считал leksah эталоном кривизны и убогости. Обиду к боли добавляет и то, что F# как бы имеет официальную поддержку корпорации — что никак не проявляется на практике, интеграция никак не развивается. Так что от моего оптимистичного заявления
Здравствуйте, Klapaucius, Вы писали:
ВВ>>Не знаю, мне кажется вначале имеет смысл определиться в том, как именно должна работать та или иная фича. В противном случае вообще непонятно, о чем разговор. Пока что видно, что в visual f# она делает ровно то, что "на заборе написано", а именно — eval selected. K>Т.е. ничего. Потому, что в "stateful языке с форвард декларацией" вычислить выделенный текст можно только в одном случае — если выделение начинается с первой строки первого файла и заканчивается тем выражением, которое мы хотим вычислить. Именно такого поведения я и ожидаю. Т.е. загрузки в репл всего проекта до выбранной строчки.
Ты всерьез что ли? F# с точки зрения грязи мало чем отличается от того же C#. Не хотел бы я, чтобы мне в грязном языке среда разработки по-тихому так, исподтишка, выполняла код, который я пишу. Черт его знает, что у меня там происходит — может, я диск С форматирую.
Нельзя в грязных языках делать то, что делает Лексах. Это будет просто саботажем каким-то. Зачем в VisualF# такая фича, от которой вред может быть огромен, а польза — сомнительна? Учитывая, что корректность работы этой фичи вызывает сомнения даже в Лексах.
ВВ>>В Лексах же присутствует некая химия, причем по ходу выражение просто выполняется в контексте топ левела. Если это и есть идеал, к которому хочется стремииться, то почему бы просто не пользоваться реплом? K>Но репл f# отличается от репла хаскеля тем же. Репл хаскеля вычисляет выражение в контексте топлевела (кстати, репловый топлевел хаскеля тоже "stateful с форвард декларацией" т.е. находится внутри do блока). Все нужные зависимости он подгрузит сам. fsi ничего этого не делает — т.е. и репл не работает нормально. Все зависимости и порядок файлов для загрузки известны — они в файле проекта. Но никакой загрузки не происходит.
О каких зависимостях речь? Все прописанные в open модули загружаются. После этого дергай из топ-левела все, что тебе заблагорассудится — ты же этого хочешь? В C# вот и такого РЕПЛА нет. У Хаскелла же по большому счету один РЕПЛ и есть — он там за все отдувается. И Лексах есть некий кривой ГУИ к этому РЕПЛу. Что-то я не вижу здесь каких-то кардинальных преимуществ.
K>Кроме того, репл хаскеля может вычислять не только в контексте топлевела, но и в контексте любого выражения — чтоб в него попасть нужно поставить там брекпойнт и вычислить. В ghci это все сделано небезупречно. Например, нельзя поставить брекпойнт на функцию объявленную в репле: K>
K>Prelude> let foo x = bar 2 x where bar = (+)
K>Prelude> :break foo
K>cannot set breakpoint on foo: foo is not defined in an interpreted module
K>
K>Но в f# этого всего вообще нет.
В F# есть настоящий отладчик, а не этот сомнительный интерпретатор.
ВВ>>Полезной для чего? В каких случаях ты пользуешься этой фичей? K>Для того же, для чего и репл полезен. Опробовать функцию так и эдак. Быстро и без излишних хлопот. В leksah можно еще и тип выражения узнать — а в интеграции f# со студией — только тип символа, что довольно таки бесполезно.
Речь фактически идет о том, что вместо:
1. Засветить мышкой
2. Выбрать пункт в контекстном меню
надо
1. Ctrl+A
2. Выбрать пункт контекстном меню
3. Засветить мышкой
4. Выбрать пункт в контекстном меню
Ага, два лишних действия. Я бы не назвал это лишними хлопотами. Скажем так, не настолько все остальное хорошо, чтобы именно на это обращать какое-то особенное внимание.
ВВ>>И как, согласно твоим ожиданиям, она должна работать в visual f#? Ты ведь прекрасно понимаешь, что f# — это stateful язык с форвард декларацией, что вносит свои нюансы. K>Про нюансы выше. Репл у всех стат. языков с лексическим скоупом одинаковый. По другому только во вской динамике типа pure.
Да, вот только последствия исполнения кода могут быть разные.
ВВ>>В любом случае все это так — мелкие фишки. Их наличие или отсутствие погоды не делает. K>Наличие более-менее работающего репл и его интеграция в иде с одной стороны и репл сделанный для галочки, который нормально работать не может с другой — это погоду лично для меня делает.
Я не согласен про "репл сделанный для галочки" — вполне нормальный репл. Да, цикл разработки на него так не ориентирован как в мире Хаскелла, может быть, он и неудобен в чем-то, но "нормально не может работать" — это явно перебор. В VisualF# нет такой интеграции с РЕПЛ, т.к. нет такой ориентированности на РЕПЛ, вот и все. По сути для дебага есть отдельный репл — Immediate. Это, кстати, по аналогии с тем же C# сделано.
K>Кроме того, репл хаскеля с каждой версией становится лучше (про его интеграцию с leksah, правда, такого не скажешь) — в случае fsi никаких улучшений нет вообще. В интеграции f# со студией я улучшений тоже не заметил. ВВ>>Мне, например, куда важнее, как работает подсветка ошибок в редакторе — отличная почва для сравнения лексах и вижуал шарпа. K>И в чем тут принципиальное различие?
В том, что в одном случае она работает, а в другом — не работает.
Смысл подчеркивания ошибок в том, чтобы показывать текст ошибки прямо в редакторе по месту. Но Лексах об этом не знает, и ошибки надо все равно вылавливать в аутпуте. На фоне того, что раскраска постоянно запаздывает, ничего, кроме раздражения, она не вызывает.
ВВ>>Или интегрированный дебаг. K>На мой взгляд, дебаг в visual f# интегрирован отвратительно. После остановки на брекпойнте почти все окружающие значения не просматриваются. В этом плане отладчик у хаскеля получше — там в точке остановки полноценный репл доступен. Плюс дотнетного отладчика, конечно, в том, что скомпилированный для отладки код быстро работает. В случае хаскеля все иначе.
Дебуггер в F# — это обычный дотнетовский дебуггер. Где там значения не просматриваются? Можешь привести пример кода, который воспроизводит проблему?
В .NET — несколько другой подход к дебагу, не РЕПЛ-ориентированный. Очевидно для F# никто не станет всю инфраструктуру переделывать. Собственно, они даже свой EE для него не сделали (хотя на мой взгляд — это не принципиально). Аналог репла в точке останова — это immediate. Кстати, ни разу не припомню, чтобы мне не хватало его возможностей. В точке останова хочется не код писать, а скажем вызвать ф-цию, нырнуть в другой брейкпоинт и пр. Это все прекрасно делается.
При этом у отладчика есть куча возможностей, которые в Лексах отсутствуют. Вся инфраструктура с визуалайзерами работает. Многопоточная отладка. На бряки можно вводить условия и пр. Как вообще это сравнивать можно?
ВВ>>Пока что получается, что VisualF# — это пускай и простенькая, но все же весьма употребимая IDE. K>Я, как употребитель, очень недоволен. Сейчас даже больше, чем тогда, когда писал претензии первый раз. Потому, что с тех пор я успел ознакомится с бетой новой студии и выяснил, что там все то же самое. Прогресс невооруженным взглядом не заметен.
Это вообще другой вопрос. Прогресс будет только при росте популярности языка — но тут замкнутый круг. Я в данном случае не хочу играть роль нострадамуса. Ты же, видимо, просто привык к особенностям Лексаха и РЕПЛу и другая идеология IDE тебе не нравится. По уровню же возможностей — при всей своей убогости — IDE для F# одна из лучших IDE для ФЯ. Что, впрочем, печально.
ВВ>>Но вот про Лексах, к сожалению, я не могу сказать того же. K>Что visual f#, что leksah — жалкие поделки, к сожалению. Играют они в одной лиге — принципиальных различий между ними нет. С нормальными иде индустриального качества вроде тех, что есть для Java/c# их просто смешно сравнивать. При этом официальная поддержка f# совсем не подготавливает к встрече с поделкой вроде leksah, как раз наоборот,
VisualF# по крайней мере две вещи делает достаточно нормально — репортинг ошибок и дебаг. Автокомплит также вполне сносный.
Лексах предоставляет кривой GUI к GHCi. И по большому счету ничего кроме этого в нем и нет. Идеологии у сред разные, так что если подходить к одной из них с позиций другой, то получается критика, как у тебя. Я же вижу, что VisualF# сделан качественее. Не качественно, а качественнее. И построен на весьма удачной IDE-платформе, благодаря чему кучу фич ты получаешь уже "из коробки" вместе c Visual Studio Shell.
K>ожидаешь поддержку приближенную по качеству к visual c#.
Внезапно
С чего это вдруг?
Во-первых, VisualC# — это, не считая урезанного Express, коммерческий продукт. VisualF# — нет. Что как бы уже намекает.
Во-вторых, чтобы иметь поддержику приближенную по качеству к VisualC# денег придется потратить больше, т.к. F# сложнее в плане поддержки в IDE. C# — это вообще IDE ориентированный язык, который как язык затачивается под хорошую поддержку в IDE.
ВВ>>Вот когда Visual Haskell перейдет из категории анимированных гифок в состояние хотя бы употребимой беты, то тогда можно будет сранивать и критиковать. K>Полагаю, что этого никогда не произойдет.
Почему? Visual Haskell никогда не выйдет?
ВВ>>Пока же то, что есть у эф шарпа гораздо лучше того, что есть у Хаскелла — поэтому и критика Visual F# в стиле "я нашел фичу, которая реализована в нем даже хуже, чем в Лексах" мне кажется несколько странной. K>Все гораздо хуже. Фич, которые в leksah реализованы лучше, чем в Visual f# больше одной и их не нужно искать.
Для слушателей, которые не видели Лексах, я сначала объясню о чем речь.
Это такое приложение. Когда запускаешь — сначала открывается консолька. Потом открывается ГУИ.
У ГУИ есть меню, причем практически все пункты — enabled, кроме загадочных next error/previous error. Ясное дело, что когда ты щелкаешь на эти пункты, то половина из них не работает, т.к. ты что-то еще не открыл или не сделал. Но ладно.
Основное пространство выглядит так — слева редактор, справа два окна с четырьмя рядами кнопок, какие-то кнопки переключают содержимое в окнах, какие-то, видимо, контекстные, но все, разумеется, enabled и при нажатии — тишина.
Ладно, запустили новую IDE. Первым делом что? Смотрим справку, правильно. Выбираем — Help/Manual. Тишина. Переключаемся в консольку. Консоль пишет: Can't find browser executable firefox.
Внезапно.
Ну ладно, идем дальше. Начинаем кодить. При наборе кода заголовок окна постоянно (!!) мигает красным. Однако.
Причем судя по тем высерам, которые идут в аутпут оно компиляет мне код при вводе каждого символа. Печатаю я быстро, и естественно, оно не успевает. Аутлайна, кстати, никакого не видно, хотя в рекламе его обещали. Но ладно.
Зато браузер имен работает! Правда, показывает какую-то ерунду. А, это я забыл на кнопочку Refresh нажать.
Ладно, теперь надо подебажить. Ставим бряку. Что, не включен дебуггер? Нажимаем на кнопоку Включить дебуггер.
Ставим бряку еще раз. Тишина. В консольке — Please select module file in the editor. Чего где как выбрать?
Продолжать можно долго. Правда, не очень хочется. Я, кстати, теперь понимаю, почему Лексах так назвали — там же все шиворот навыворот.
K>В f# в отличие от leksah, например, нет аутлайна, браузера имен. Найти готовую функцию из библиотеки, когда пишешь на f# — серьезный челлендж. В случае хаскеля такой проблемы нет.
Вот только причем тут Лексах
K>У f# даже явного преимущества по качеству автокомплита нет — что особенно удивительно (автокомплит для f# все-таки сделать проще, особенно в условиях библиотеки, которая состоит из "неоткрываемых" модулей и прочих милых (для автокомплита, но не для программиста) вещей).
Преимущество есть. В F# автокомплит работает. В Лексах нет. Я там даже символов локальных не вижу — или надо сначала было нажать Refresh package, потом Rebuild package — и так после каждого изменения?
K>Самое смешное тут в том, что положительные стороны leksah я и не заметил бы, если бы не знакомство с Visual f# — до этого самого знакомства я считал leksah эталоном кривизны и убогости. Обиду к боли добавляет и то, что F# как бы имеет официальную поддержку корпорации — что никак не проявляется на практике, интеграция никак не развивается. Так что от моего оптимистичного заявления
Здравствуйте, SilentNoise, Вы писали:
VD>>Это скорее недоработка реализации.
SN>То есть, в F# это принципиальная убогость алгоритма вывода типов, а в немерль — всего-лишь недоработка?)
А ты сам-то не понимаешь, чем баг от слабости алгоритма отличается?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не хотел бы я, чтобы мне в грязном языке среда разработки по-тихому так, исподтишка, выполняла код, который я пишу.
Не "по-тихому" и совсем не "исподтишка", а после явного выбора в меню команды "выполнить выражение, загрузив весь код выше". Лучше, конечно, необходимый код.
ВВ>Черт его знает, что у меня там происходит — может, я диск С форматирую.
Ну а если вы там диск це форматируете — не пользуйтесь этим пунктом меню.
ВВ>Нельзя в грязных языках делать то, что делает Лексах. Это будет просто саботажем каким-то. Зачем в VisualF# такая фича, от которой вред может быть огромен, а польза — сомнительна? Учитывая, что корректность работы этой фичи вызывает сомнения даже в Лексах.
Я вовсе не требую точного соотвествия поведению leksah. Я ожидаю какой-то минимальной интеграции repl и ide.
ВВ>О каких зависимостях речь?
О необходимых для выполнения кода в repl.
ВВ>Все прописанные в open модули загружаются.
Вы шутите? Нет, не загружаются.
ВВ>Речь фактически идет о том, что вместо:
ВВ>1. Засветить мышкой ВВ>2. Выбрать пункт в контекстном меню
ВВ>надо
ВВ>1. Ctrl+A ВВ>2. Выбрать пункт контекстном меню ВВ>3. Засветить мышкой ВВ>4. Выбрать пункт в контекстном меню
Ну давайте попробуем:
Создадим проект с двумя файлами: Foo.fs
module Foo (* Файл должен начинатся так или с объявления неймспейса *)let foo x = x + 1
Program.fs
open Foo
printfn "%A" <| foo 41
Ctrl+F5 — все работает.
Теперь сделаем как вы предложили в файле Program.fs
Program.fs(1,6): error FS0039: The namespace or module 'Foo' is not defined
Т.е open не обрабатывается.
Ну ладно, два файла — это, видимо, непозволительная роскошь.
Попробуем загрузить в repl только первый.
Foo.fs(2,5): error FS0010: Unexpected start of structured construct in definition. Expected '=' or other token.
Ну правильно — repl не понимает такого объявления модуля. Ладно, с кем не бывает. Foo.fs
module Foo =
let foo x = x + 1
Такое не поймет уже компилятор:
Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'
Хорошо, есть еще альтернативный вариант:
namespace Bar
module Foo =
let foo x = x + 1
Foo.fs(1,1): error FS0010: Incomplete structured construct at or before this point in interaction
Как видите, то, что функция "не работает", "существует для галочки" — именно это и означает. Буквально. А вовсе не какое-то преувеличение того, что "надо просто еще и Ctrl+A набирать".
Понятно, что изолированный код — т.е. в данном случае module Foo можно выделить и отправить в интерперетатор. Он загрузится. после этого можно будет выполнить и выражение
printfn "%A" <| Foo.foo 41 (* код для загрузки, правда, пришлось отредактировать *)
Но в реальной практике мы столкнемся с большим числом зависимостей и воспроизводить рабочее окружение копированием множества кусочков кода в интерпретатор достаточно затруднительно.
Собственно, требуется возможность загружать файлы в интерпретатор. такого пункта в меню нет.
Чтож поделать — пишем в репле:
#load "Program.fs";;
Тут он пожалуется, что в папке Temp такого файла нет. Ну правильно, кто бы мог подумать, что нам понадобится один из файлов проекта загрузить? Хорошо, у нас есть директива #I — добавим с ее помощью путь к проектным файлам (оцените уровень интеграции). Теперь попробуем #load "Program.fs";; снова:
error FS0222: Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'
У компилятора же к этому файлу претензий нет. Мы, конечно можем добавить неймспейс (дальше, конечно, ошибка — значений в неймспейсах быть не должно и нужно будет явно прописывать main функцию)
После переписывания всего кода...
module Program
open Bar.Foo
[<EntryPoint>]
let main _ = printfn "%A" <| foo 41; 0
Ну, теперь заживем!
#load "Program.fs";;
Или нет...
Program.fs(2,10): error FS0039: The namespace or module 'Bar' is not defined
Ах да, я и забыл — потребности в колбасе нескольких файлах нет. open файлы не загружает.
Но мы, конечно, упорные. Начнем загрузку, вручную, с самого верха:
namespace FSI_0003.Bar
val foo : int -> int
И так далее.
... быстрая перемотка вперед ...
Не смотря на то, что описание отношений между файлами, подключаемые библиотеки (это отдельная история, fsi сам их не подключит) и вообще все что нужно уже есть в мсбилд файле, который и формируется как бы сам собой (по большей части) нам пришлось воспроизвести (и, разумеется, заскриптовать — вручную все это делать невозможно даже для хэллоу-ворлда) все то же самое для fsi. Что, я полагаю, отлично иллюстрирует степень интеграции fsi со студией (нулевой), так удобство его использования без всякой студии (стремящееся к нулю). Впереди — увлекательная работа по поддержанию консистентности между загрузочным скриптом и описанием проекта.
ВВ>После этого дергай из топ-левела все, что тебе заблагорассудится — ты же этого хочешь?
Так точно. Но, желательно, не ценой всех вышеперечисленных приседаний.
ВВ> В C# вот и такого РЕПЛА нет. У Хаскелла же по большому счету один РЕПЛ и есть — он там за все отдувается.
Все так. У F# же, нет ни того, что есть у C#-а, ни того, что есть у хаскеля. Как F# позиционируется? Как "ФЯ с ИДЕ". Что он из себя предстваляет на самом деле? C# без ИДЕ.
ВВ>В F# есть настоящий отладчик
Настоящий отладчик есть в .NET. Понятно, что на отладку кода на ФЯ он не расчитан.
ВВ>Смысл подчеркивания ошибок в том, чтобы показывать текст ошибки прямо в редакторе по месту.
А, это-то конечно все верно. В leksah от нее никакого толку.
ВВ>Где там значения не просматриваются? Можешь привести пример кода, который воспроизводит проблему?
Легко:
type Foo(bar) =
member self.Buz() = bar |> Seq.map (fun x -> x)
Foo([1..5]).Buz() |> printf "%A"
Брекойнт на x — не можем просмотреть bar. Разумеется, если заменить Seq на List или убрать ООП — проблема исчезнет, но в этом примере вся суть F#-а: вынужденное использование объектов + костыльная ленивость.
Кстати, автокомплит после точки предлагает методы списка, а не класса Foo.
ВВ>В .NET — несколько другой подход к дебагу, не РЕПЛ-ориентированный.
О чем и речь. Отладчик в .net, конечно, отличный (для языка "Java с перламутровыми пуговицами"), а в ФЯ их можно считать, что и нет вовсе. Но repl это средство отладки — вполне логично было бы совместить его с отладчиком. Только в этом ключе — интеграцию отладчика и репл — я положительно лексаховский (правильнее, конечно, GHC-ный) отладчик и оценил.
ВВ>Очевидно для F# никто не станет всю инфраструктуру переделывать.
Т.е. очевидно, что никакой реальной поддержки F# нет.
ВВ>Это вообще другой вопрос. Прогресс будет только при росте популярности языка — но тут замкнутый круг. Я в данном случае не хочу играть роль нострадамуса. ВВ>Ты же, видимо, просто привык к особенностям Лексаха и РЕПЛу и другая идеология IDE тебе не нравится.
Ну нет. К Лексаху я, к счастью, не привык. Я привык к нормальной ИДЕ. Действительно, в мейнстриме подход к разработке один, а в ФЯ — другой. Но речь-то о том, что F# инвалид в обеих парадигмах. Вместо того, чтоб объединать что-то хорошее из разных лагерей, он объединяет худшее. Среди мейнстримных программистов он может сойти за "академическую игрушку", а среди функциональщиков — за C# с улучшенным синтаксисом или ML-инвалид (для тех, кто и про C# не слыхивал). Грандиозный успех!
ВВ>IDE для F# одна из лучших IDE для ФЯ.
Звучит как... Ладно, не будем никого обижать сравнением с ИДЕ для ФЯ.
K>>ожидаешь поддержку приближенную по качеству к visual c#. ВВ>С чего это вдруг? ВВ>Во-первых, VisualC# — это, не считая урезанного Express, коммерческий продукт. VisualF# — нет. Что как бы уже намекает.
С того, что он поставляется в составе коммерческого продукта второй раз. Имеет версию, теперь уже, 3.0, а не 0.3 и заявлен как продукт Microsoft (не Research).
ВВ>Visual Haskell никогда не выйдет?
Именно так. Судите сами: Visual Haskell 2010 разрабатывал один человек. Кода никто не видел, вся информация о проекте доступна только из его блога. Последнее сообщение, касающееся проекта непосредственно, датируется январем прошлого года. В нем с подозрительной настойчивостью автор уверяет, что проект не мертв. Последнее сообщение связаное косвенно датируется сентябрем — что уже позволяет заподозрить — не мертв ли автор, не говоря уже о проекте.
ВВ>Продолжать можно долго. Правда, не очень хочется. Я, кстати, теперь понимаю, почему Лексах так назвали — там же все шиворот навыворот.
Это точно.
ВВ>Самое смешное тут в том, что ты вообще заметил какие-то положительные стороны Лексах.
Смешного тут ничего нет, потому что как я сказал, leksah — это "эталон кривизны и убогости". То, что что-то оказывается может быть сделано хоть в чем-то хуже, чем в leksah — произвело на меня сокрушительное впечатление.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, ArtDenis, Вы писали:
AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
А какие функциональные языки популярны? Возьмем вот крупнейшую биржу фрилансеров в Германии — гульп. У них есть статистика по всем предлагавшимся за 13 лет проектам. Смотрим по языкам (Язык, все проекты с мая 1999, проекты за последний год):
VD>А ты сам-то не понимаешь, чем баг от слабости алгоритма отличается?
Понимаю, вот только внешнее проявление абсолютно одинаковое — что и вызывает сомнения в одном из:
а) убогости алгоритма вывода типов F#;
б) неубогости алгоритма Nemerle;
Здравствуйте, SilentNoise, Вы писали:
SN>Понимаю, вот только внешнее проявление абсолютно одинаковое — что и вызывает сомнения в одном из: SN>а) убогости алгоритма вывода типов F#; SN>б) неубогости алгоритма Nemerle;
Внешнее проявление тоже совершенно разное. Ты присмотрись внимательнее. Пример что нарисовал nikov совершенно искусственный. А в F# вывод типов в прицепи слабый. Он на вполне рабочем логичном коде лажает. Я когда пишу код на немерле не заморачиваю себе голову тем, что надо писать код так чтобы его понял вывод типов. В F# же это надо делать обязательно. И необходимость в ручных аннотациях типов в нем тоже насущная реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Не хотел бы я, чтобы мне в грязном языке среда разработки по-тихому так, исподтишка, выполняла код, который я пишу.
K>Не "по-тихому" и совсем не "исподтишка", а после явного выбора в меню команды "выполнить выражение, загрузив весь код выше". Лучше, конечно, необходимый код.
Вот эта эвристика "загрузка необходимого кода" мне не очень понятна. Биндинги могут содержать какие-либо действия. Это никак не отслеживается.
Вообще непонятно, почему мы акцентируем внимание на этой проблеме — тут проблемы-то нет. "Выполнить выражение, загрузив весь код выше" — это сначала загрузить весь код выше, а потом выполнить выражение. Проблема же не в том, что два раза на кнопку жамкать приходится.
ВВ>>Черт его знает, что у меня там происходит — может, я диск С форматирую. K>Ну а если вы там диск це форматируете — не пользуйтесь этим пунктом меню.
Ну дык, я же выделенное хочу выполнить, а не "формат це". Впрочем, ладно об этом.
ВВ>>Нельзя в грязных языках делать то, что делает Лексах. Это будет просто саботажем каким-то. Зачем в VisualF# такая фича, от которой вред может быть огромен, а польза — сомнительна? Учитывая, что корректность работы этой фичи вызывает сомнения даже в Лексах. K>Я вовсе не требую точного соотвествия поведению leksah. Я ожидаю какой-то минимальной интеграции repl и ide.
А есть какие-либо интересные примеры интеграции REPL и IDE? Не Лексах, а что-то чуть более прямое. Просто посмотреть, как оно вообще должно выглядеть.
В моих глазах тут по сути два разных мира — REPL и IDE. IDE в формате Вижуал Студии предоставляет средства по сути эквивалетные реплу, но делает это по-другому.
ВВ>>Все прописанные в open модули загружаются. K>Вы шутите? Нет, не загружаются.
Внешние референсы — типа на какой-нибудь Core — загружаются. Проектные — да, надо прописывать вручную. Такой же путь все равно есть. Есть и альтернативный — дебаг.
K>Все так. У F# же, нет ни того, что есть у C#-а, ни того, что есть у хаскеля. Как F# позиционируется? Как "ФЯ с ИДЕ". Что он из себя предстваляет на самом деле? C# без ИДЕ.
Дебаг в F# вполне нормальный. Может, там и не работает что, но основные вещи вполне себе работают.
ВВ>>В F# есть настоящий отладчик K>Настоящий отладчик есть в .NET. Понятно, что на отладку кода на ФЯ он не расчитан.
А как должен выглядеть отладчик, расчитанный на ФЯ и в чем заключается "не рассчитанность" дотнетовского отладчика?
ВВ>>Где там значения не просматриваются? Можешь привести пример кода, который воспроизводит проблему? K>Легко: K>
K>type Foo(bar) =
K> member self.Buz() = bar |> Seq.map (fun x -> x)
K>Foo([1..5]).Buz() |> printf "%A"
K>
K>Брекойнт на x — не можем просмотреть bar. Разумеется, если заменить Seq на List или убрать ООП — проблема исчезнет, но в этом примере вся суть F#-а: вынужденное использование объектов + костыльная ленивость.
Поставил брейкпоинт на х — ввожу в watch bar — отлично показывается и разворачивается. Все это в нормальном интерфейсе, сделанном для людей. Все, что я ввожу в watch, остается. Значения удобно рефрешатся. Их можно менять, можно вводить выражения. Ну в общем все так же, как и в C#.
В Locals, кстати, тоже есть bar.
K>Кстати, автокомплит после точки предлагает методы списка, а не класса Foo.
Да, некрасиво. Неправильно определяется выражение слева. Но, честно говоря это похоже на то, что ты специально пытался такой код написать, чтобы автокомплит обмануть. В реальности же ты так не напишешь? Такое выражение и читается плохо. Вот так:
(Foo [1..5]).Buz() |> printf "%A"
Все уже корректно работает.
Большой проблемой — особенно на фоне Лексаха — я это считать отказываюсь.
ВВ>>В .NET — несколько другой подход к дебагу, не РЕПЛ-ориентированный. K>О чем и речь. Отладчик в .net, конечно, отличный (для языка "Java с перламутровыми пуговицами"), а в ФЯ их можно считать, что и нет вовсе.
Ну ведь не так это. Отладчик есть, и он работает. Было бы, конечно, неправдой утверждать, что он настолько хорош (сиречь адекватен языку), как отладчик C#. Но все же он... ну работает он, не знаю, что еще сказать.
K>Но repl это средство отладки — вполне логично было бы совместить его с отладчиком. Только в этом ключе — интеграцию отладчика и репл — я положительно лексаховский (правильнее, конечно, GHC-ный) отладчик и оценил.
Оговорка в паренсах весьма примечательна. Вот именно что оцениваешь ты на самом деле GHCi. И сравниваешь именно GHCi. Лексах тут выступает только как неимоверно кривой ГУИ к этому самому GHCi и непонятно, каким образом он получает тут какие-то баллы.
GHCi есть и без Лексаха. Хугл тоже. И на практике даже банальный блокнот с подвсветкой раздражает меньше, чем этот Лексах.
ВВ>>Очевидно для F# никто не станет всю инфраструктуру переделывать. K>Т.е. очевидно, что никакой реальной поддержки F# нет.
Нет, следствие неправильное. Сама по себе инфраструктура хорошая. Пусть она и не настолько хороша именно для F#, как могла бы быть.
Остальные поделки, которые я видел, как правило хуже. И грешат ахтунгами в стиле — а давайте сначала соберем весь проект, и тогда мы вам сможем тултипы с типами показать.
В VisualF# таких вещей на самом деле гораздо меньше.
ВВ>>Это вообще другой вопрос. Прогресс будет только при росте популярности языка — но тут замкнутый круг. Я в данном случае не хочу играть роль нострадамуса. ВВ>>Ты же, видимо, просто привык к особенностям Лексаха и РЕПЛу и другая идеология IDE тебе не нравится. K>Ну нет. К Лексаху я, к счастью, не привык. Я привык к нормальной ИДЕ.
К какой?
K>Действительно, в мейнстриме подход к разработке один, а в ФЯ — другой. Но речь-то о том, что F# инвалид в обеих парадигмах. Вместо того, чтоб объединать что-то хорошее из разных лагерей, он объединяет худшее. Среди мейнстримных программистов он может сойти за "академическую игрушку", а среди функциональщиков — за C# с улучшенным синтаксисом или ML-инвалид (для тех, кто и про C# не слыхивал). Грандиозный успех!
VisualF# не так уж и плох и существует он по большей степени в парадигме именно VisualStudio, а не РЕПЛА. Проблема в том, что он попросту не доделан. Вернее, даже не так. Проблема в том, что он он не доделывается. Почему и отчего — это уже в общем-то другой вопрос.
ВВ>>IDE для F# одна из лучших IDE для ФЯ.
ВВ>>Во-первых, VisualC# — это, не считая урезанного Express, коммерческий продукт. VisualF# — нет. Что как бы уже намекает. K>С того, что он поставляется в составе коммерческого продукта второй раз. Имеет версию, теперь уже, 3.0, а не 0.3 и заявлен как продукт Microsoft (не Research).
Если бы он имел версию 0.3 и распространялся только как к аддон к шеллу, то претензий не было бы?
Вообще я не понимаю, какое это имеет значение — кто с кем поставляется.
ВВ>>Самое смешное тут в том, что ты вообще заметил какие-то положительные стороны Лексах. K>Смешного тут ничего нет, потому что как я сказал, leksah — это "эталон кривизны и убогости". То, что что-то оказывается может быть сделано хоть в чем-то хуже, чем в leksah — произвело на меня сокрушительное впечатление.
РЕПЛ в F# хуже, чем GHCi. Вот только причем тут Лексах
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А есть какие-либо интересные примеры интеграции REPL и IDE? Не Лексах, а что-то чуть более прямое. Просто посмотреть, как оно вообще должно выглядеть. ВВ>В моих глазах тут по сути два разных мира — REPL и IDE. IDE в формате Вижуал Студии предоставляет средства по сути эквивалетные реплу, но делает это по-другому.
Здравствуйте, ArtDenis, Вы писали:
AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
Может я чего не понимаю, но зачем нужен F# если есть C#?
> Странно, что F# пользуется такой маленькой популярностью на этом форуме. > Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, > что MS вот-вот прикроют лавочку?
Здравствуйте, -n1l-, Вы писали: N>Может я чего не понимаю, но зачем нужен F# если есть C#?
Нет, что бы объяснить человеку, спрашивающему что к чему, они тупо лезут минусы ставить.
Вы думаете, что это очень крутой аргумент в споре или беседе в он-лайне?
Заспамить минусами?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, MasterZiv, Вы писали:
MZ>>Да всё очень просто. Где кроссплатформ ?
FR>Ну сам же компилятор под mono нормально идет.
Вот бы еще под monodroid/monotouch шел
Здравствуйте, -n1l-, Вы писали:
N>>Может я чего не понимаю, но зачем нужен F# если есть C#?
N>Нет, что бы объяснить человеку, спрашивающему что к чему, они тупо лезут минусы ставить.
Мне показалось, или формат вопроса подразумевал иронию?
Здравствуйте, samius, Вы писали: S>Мне показалось, или формат вопроса подразумевал иронию?
Конечно нет. Если бы я иронизировал, то я бы "утверждал" что f# нужен.
А так я, честно, не понимаю.
Здравствуйте, -n1l-, Вы писали:
N>Нет, что бы объяснить человеку, спрашивающему что к чему, они тупо лезут минусы ставить. N>Вы думаете, что это очень крутой аргумент в споре или беседе в он-лайне? N>Заспамить минусами?
Тролишь же.
Однозначного ответа все-равно не будет.
Но существование F# вполне в духе идеологии ms которая с самого начала
позиционировала (в отличии скажем от Sun с их java) что NET поддерживает
множество разных языков.
Внезапно нет, не тролю. Да и кто будет так тролить, слишком толсто же.
Я немножко наверное не так выразился.
Вот есть так сказать столпы дотнета — c# vb.net. Которые точно так же могут работать с дотнетом как и f#.
В чем тогда преимущества f# для разработчика? Я понимаю сугубо научный интерес — изучить и понять, но все же совсем прям переходить не получиться же.
Если параллельно использовать только.
Здравствуйте, -n1l-, Вы писали:
N>Внезапно нет, не тролю. Да и кто будет так тролить, слишком толсто же. N>Я немножко наверное не так выразился. N>Вот есть так сказать столпы дотнета — c# vb.net. Которые точно так же могут работать с дотнетом как и f#. N>В чем тогда преимущества f# для разработчика? Я понимаю сугубо научный интерес — изучить и понять, но все же совсем прям переходить не получиться же. N>Если параллельно использовать только.
F# как язык более выразительный чем шарп или бейсик.
На нем гораздо проще и удобнее писать в функциональном стиле.
Он более жестко типизирован.
Для кого эти преимущества важные тот и будет переходить, остальным смысла нет.
> В чем тогда преимущества f# для разработчика? Я понимаю сугубо научный интерес — > изучить и понять, но все же совсем прям переходить не получиться же.
Другой язык. Мощный.
К тому же ещё он и распараллеливаться должен АВТОМАТОМ.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, FR, Вы писали: FR>>Тролишь же.
N>Внезапно нет, не тролю. Да и кто будет так тролить, слишком толсто же. N>Я немножко наверное не так выразился. N>Вот есть так сказать столпы дотнета — c# vb.net. Которые точно так же могут работать с дотнетом как и f#. N>В чем тогда преимущества f# для разработчика? Я понимаю сугубо научный интерес — изучить и понять, но все же совсем прям переходить не получиться же. N>Если параллельно использовать только.
Разнесли понятие null и понятие "нет значения". Уже за это, по моему, стоит переходить на F#.
Здравствуйте, Kluge, Вы писали:
K>Разнесли понятие null и понятие "нет значения". Уже за это, по моему, стоит переходить на F#.
Нормальным образом это сделать и не потерять в интеропе с остальным .NET миром не получится. Для этого option[T] нужно поднимать на уровень CLR, что по очевидным причинам вряд ли будет сделано.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Kluge, Вы писали:
K>>Разнесли понятие null и понятие "нет значения". Уже за это, по моему, стоит переходить на F#.
H>Нормальным образом это сделать и не потерять в интеропе с остальным .NET миром не получится. Для этого option[T] нужно поднимать на уровень CLR, что по очевидным причинам вряд ли будет сделано.
Это можно делать на границе интеропа, а алгоритмы внутри F# части выиграют в чистоте и наглядности.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот эта эвристика "загрузка необходимого кода" мне не очень понятна.
Я согласен на консервативную оценку необходимого. Т.е. если загрузится что-то лишнее — я не очень расстроюсь.
ВВ>Биндинги могут содержать какие-либо действия. Это никак не отслеживается.
Конечно могут. И это никак не отслеживается автоматически. Да, загрузка repl ничего не отлеживает и выполняет все действия в "биндингах". Вы пытаетесь мне доказать, что репл возможен только в чистых языках? Нет, в остальных он тоже возможен, разумеется, требуется прилежание и усидчивость, но программистам на таких языках не привыкать.
ВВ>Вообще непонятно, почему мы акцентируем внимание на этой проблеме — тут проблемы-то нет. "Выполнить выражение, загрузив весь код выше" — это сначала загрузить весь код выше, а потом выполнить выражение. Проблема же не в том, что два раза на кнопку жамкать приходится.
Разумеется не в том. Проблема в том, что "загрузить весь код выше" — нетривиальная проблема даже для программы из 4-х строк, что я показал выше. Отдельно загружать и отдельно выполнять я тоже согласен, но в ml-ном репле "загрузка" и "выполнение" — это все равно примерно одно и то же. Иначе в строгом и императивном языке и быть не может (ну, в каком-нибудь Alice, если мне память не изменяет, модули загружаются лениво — но это как раз тот самый язык с "опциональной ленивостью" про которую говорят, добавляя в библиотеку погремушку типа Lazy, которой для этого на практике недостаточно).
ВВ>А есть какие-либо интересные примеры интеграции REPL и IDE? Не Лексах, а что-то чуть более прямое.
Я таких примеров не видел.
ВВ>В моих глазах тут по сути два разных мира — REPL и IDE. IDE в формате Вижуал Студии предоставляет средства по сути эквивалетные реплу, но делает это по-другому.
По-моему, средства эти не эквивалентные, одно и то же разными способами они не делают — но пересечение по функционалу у них, разумеется, есть.
ВВ>Внешние референсы — типа на какой-нибудь Core — загружаются.
Скорее уж не "типа", а "только". Загружаются они из очень небольшого набора сборок. Собственно только из mscorlib, System.Core и FSharp.Core +/- они и грузятся. Т.е с open LazyList или open System.Xml.Linq ничего не получится — нужно грузить библиотеки вручную, как и файлы.
ВВ>А как должен выглядеть отладчик, расчитанный на ФЯ и в чем заключается "не рассчитанность" дотнетовского отладчика?
Я на этот вопрос как-нибудь отвечу отдельно и развернуто.
ВВ>Поставил брейкпоинт на х — ввожу в watch bar — отлично показывается и разворачивается. Все это в нормальном интерфейсе, сделанном для людей. Все, что я ввожу в watch, остается. Значения удобно рефрешатся. Их можно менять, можно вводить выражения. Ну в общем все так же, как и в C#. ВВ>В Locals, кстати, тоже есть bar.
Ну я, конечно, рад за вас, но у меня вот не показывается, не разворачивается, нет.
ВВ>Да, некрасиво. Неправильно определяется выражение слева. Но, честно говоря это похоже на то, что ты специально пытался такой код написать, чтобы автокомплит обмануть.
Нет, я обнаружил это случайно.
ВВ>В реальности же ты так не напишешь? Такое выражение и читается плохо. Вот так:
Нет, я конструкторы классов так вызываю достаточно часто.
ВВ>Большой проблемой — особенно на фоне Лексаха — я это считать отказываюсь.
Кстати, хорошие новости. В бете новой студии автокомплит тут сработал нормально. так что что-то они все-таки поправили.
ВВ>>>В .NET — несколько другой подход к дебагу, не РЕПЛ-ориентированный. K>>О чем и речь. Отладчик в .net, конечно, отличный (для языка "Java с перламутровыми пуговицами"), а в ФЯ их можно считать, что и нет вовсе.
ВВ>Ну ведь не так это. Отладчик есть, и он работает. Было бы, конечно, неправдой утверждать, что он настолько хорош (сиречь адекватен языку), как отладчик C#. Но все же он... ну работает он, не знаю, что еще сказать.
ВВ>непонятно, каким образом он получает тут какие-то баллы.
Что тут непонятного? Баллы получены за хоть какую-то интеграцию с ghci. Интеграции с fsi у Visual F# можно сказать что и нет.
ВВ>И грешат ахтунгами в стиле — а давайте сначала соберем весь проект, и тогда мы вам сможем тултипы с типами показать.
Сравение некорректно — как я уже писал, тултипов с типами в случае F# нет вообще (в тултипах — документация, фактический тип просматреть нельзя).
ВВ>К какой?
К VS.
ВВ>VisualF# не так уж и плох и существует он по большей степени в парадигме именно VisualStudio, а не РЕПЛА. Проблема в том, что он попросту не доделан. Вернее, даже не так. Проблема в том, что он он не доделывается.
Вот именно. О чем я и говорю.
ВВ>Если бы он имел версию 0.3 и распространялся только как к аддон к шеллу, то претензий не было бы?
Претензий было бы меньше, по крайней мере у меня. Потому что позиционирование совпадало бы с фактическим положением дел. В принципе, заявления о поддержке F# могут быть полезны для распространения ФП в мейнстрим, но разве что тактически, потому что это, скажем прямо, обман — с понятными последствиями в долгосрочной перспективе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, -n1l-, Вы писали:
N>>Может я чего не понимаю, но зачем нужен F# если есть C#?
K>А зачем вообще программирование, если есть прилежание и усидчивость?
Вы конечно сравнили дуб с обезьяной, шикарный аргумент.
Отсыпьте мне тоже, я хочу попробовать.
Здравствуйте, Klapaucius, Вы писали:
K>Конечно могут. И это никак не отслеживается автоматически. Да, загрузка repl ничего не отлеживает и выполняет все действия в "биндингах". Вы пытаетесь мне доказать, что репл возможен только в чистых языках? Нет, в остальных он тоже возможен, разумеется, требуется прилежание и усидчивость, но программистам на таких языках не привыкать.
Нет, я не пытаюсь доказать, что репл возможен в чистых языках. Я высказываю мнение, что в энергичных грязных языках какой-либо код не должен выполняться неявно. Вот если я выделил мышкой директиву открытия модуля, то вполне логично ожидать, что выполнится код в do-блоках этого модуля. Если же я выделил 2+2, то исполнение этого кода я нахожу не очень логичным.
K>Разумеется не в том. Проблема в том, что "загрузить весь код выше" — нетривиальная проблема даже для программы из 4-х строк, что я показал выше. Отдельно загружать и отдельно выполнять я тоже согласен, но в ml-ном репле "загрузка" и "выполнение" — это все равно примерно одно и то же.
Отдельно значит, что ты сначала выполняешь весь код, создавая тем самым нужный тебе топ левел в репле, а потом гоняешь уже нужные тебе выражения.
Лексах, кстати, примерно это и делает. Собственно, загружать весь код вше было бы неправильно с т.з. семантики Хаскелла.
K>Иначе в строгом и императивном языке и быть не может (ну, в каком-нибудь Alice, если мне память не изменяет, модули загружаются лениво — но это как раз тот самый язык с "опциональной ленивостью" про которую говорят, добавляя в библиотеку погремушку типа Lazy, которой для этого на практике недостаточно).
А можно пример ленивого кода на Хаскелле, который нельзя перевести на код с явными санками?
ВВ>>А есть какие-либо интересные примеры интеграции REPL и IDE? Не Лексах, а что-то чуть более прямое. K>Я таких примеров не видел.
Вот, а почему интересно? Может, это все-таки "два разных человека"?
ВВ>>В моих глазах тут по сути два разных мира — REPL и IDE. IDE в формате Вижуал Студии предоставляет средства по сути эквивалетные реплу, но делает это по-другому. K>По-моему, средства эти не эквивалентные, одно и то же разными способами они не делают — но пересечение по функционалу у них, разумеется, есть.
А какая область не пересекается? Давай все же конкретнее. По большому счету свой эквивалент репла в студии и так есть.
ВВ>>А как должен выглядеть отладчик, расчитанный на ФЯ и в чем заключается "не рассчитанность" дотнетовского отладчика? K>Я на этот вопрос как-нибудь отвечу отдельно и развернуто.
Ну что ж, буду ждать.
ВВ>>Поставил брейкпоинт на х — ввожу в watch bar — отлично показывается и разворачивается. Все это в нормальном интерфейсе, сделанном для людей. Все, что я ввожу в watch, остается. Значения удобно рефрешатся. Их можно менять, можно вводить выражения. Ну в общем все так же, как и в C#. ВВ>>В Locals, кстати, тоже есть bar. K>Ну я, конечно, рад за вас, но у меня вот не показывается, не разворачивается, нет.
Ну я не обманываю же? Какой у тебя f#?
Я вообще окошками locals/autos обычно вообще не пользуюсь, может, там иногда и пропадает что.
Что, если в вотч самому bar ввести тоже не показывается?
N>def f(x) { x.ToLower() } // Error: typing fails on accessing member ToLower in the ? type
N>_ = "ABC" |> f // Error: typing fails on ambiguity between operator |>(string, ? -> ?) overloads
N>
N>Прокатывает, но не проходит. Как говорится, у каждого свои недостатки
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нет, я не пытаюсь доказать, что репл возможен в чистых языках. Я высказываю мнение, что в энергичных грязных языках какой-либо код не должен выполняться неявно.
Согласен, не должен. Я же говорю, явная загрузка меня тоже устроит. Меня не устраивает загрузка ручная до такой степени, что и загружать ничего не хочется.
ВВ>Вот если я выделил мышкой директиву открытия модуля, то вполне логично ожидать, что выполнится код в do-блоках этого модуля. Если же я выделил 2+2, то исполнение этого кода я нахожу не очень логичным.
Это не логично, но это вырожденный пример, который практического значения не имеет. Тот код, что интересно запустить на практике зависит от объявленных и вычисленных значений выше. 2+2 и так прекрасно работает, так что вместо калькулятора fsi использовать можно, но речь о других применениях, а именно — написании программ.
ВВ>Отдельно значит, что ты сначала выполняешь весь код, создавая тем самым нужный тебе топ левел в репле, а потом гоняешь уже нужные тебе выражения.
Да, это и надо.
ВВ>Собственно, загружать весь код вше было бы неправильно с т.з. семантики Хаскелла.
Конечно, но с точки зрения ML это вполне правильно (с поправками на всякие and и объекты, где они есть)
ВВ>А можно пример ленивого кода на Хаскелле, который нельзя перевести на код с явными санками?
Речь не о том, что можно перевести в принципе, а о том, что можно использовать на практике, т.е. то, что удобно и работает с приличной скоростью. Lazy и прочее не обеспечивают ни первого ни второго, и, соотвественно, почти никогда не используются.
ВВ>Вот, а почему интересно?
По той же самой причине, по которой, например, никто не видел сверхзвукового самолета в 1939-ом году.
K>>По-моему, средства эти не эквивалентные, одно и то же разными способами они не делают — но пересечение по функционалу у них, разумеется, есть. ВВ>А какая область не пересекается? Давай все же конкретнее. По большому счету свой эквивалент репла в студии и так есть.
IDE появились для языков и библиотек в которых на каждое 2+2 полагается три экрана бойлерплейтной обвязки, а сам + именуется как-нибудь вроде НоВГорлоЯУспелВоткнутьИТамДваРазаПовернутьМоеОружье (перегружено для 256 вариантов аргументов). Отсюда очевидны и виды проблем, которые ИДЕ решают, т.е. генерация бойлерплейта и, что более актуально, потому что никаким совершенствованием языка тут делу не поможешь — автоматизированное преобразование кода и навигация по коду. Функциональность репла — т.е. возможность быстро испробовать небольшой фрагмент кода в ИДЕ появится могла только в самой зачаточной форме — ведь в языках, для которых иде разрабатывались не бывает кусков кода одновременно работающих и небольших. Наоборот, репл характерен для языков в которых не нужно писать мегабайты бойлерплейта, а типичная программа вычисляет факториал — так что навигация по ней тривиальна, как, собственно, и ее ручное преобразование. Когда же эти языки внезапно стали применять на практике — проблема навигации по коду встала в полный рост.
ВВ>Ну я не обманываю же?
Да я вас и не обвиняю в этом. Я просто констатирую, что у меня проблема существует.
ВВ>Какой у тебя f#?
4.0.30319.1
ВВ>Что, если в вотч самому bar ввести тоже не показывается?
Нет, не показывается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, -n1l-, Вы писали:
K>>А зачем вообще программирование, если есть прилежание и усидчивость? N>Вы конечно сравнили дуб с обезьяной, шикарный аргумент.
Аналогия самая прямая. При наличии прилежания и усидчивости в товарных количествах все, что автоматизируется с помощью программирования можно и вручную делать. Но человеческому падению предела нет, даже программировать некоторые не хотят как положено, как отцы и деды завещали: смирять плоть, крепить дух, страдать, становясь лучше — нести свой крест (кресты, решетки и т.д.) т.е. писать на С# и других похожих душеспасительных языках. Вместо этого некоторые программисты, представьте себе, хотят идти по легкому пути — а это уже лень и разложение в квадрате.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, -n1l-, Вы писали:
N>Может я чего не понимаю, но зачем нужен F# если есть C#?
а вб.нет зачем нужен?
он же в отличие от фа диеза пратически ничего не предлагает — но при этом популярность имеет.
Собственно, если подытожить, я вижу здесь достаточно простую ситуацию. В виде VisualF# я вижу некоторую базу, которая может стать хорошей IDE. Безусловно, работы еще много. Но фундамент есть. А вот в Лексахе я такой базы не вижу. Поэтому с точки зрения IDE именно — не с точки зрения РЕПЛа и его возможностей — ситуация у F# на мой взгляд гораздо лучше.
ВВ>>А можно пример ленивого кода на Хаскелле, который нельзя перевести на код с явными санками?
K>Речь не о том, что можно перевести в принципе, а о том, что можно использовать на практике, т.е. то, что удобно и работает с приличной скоростью. Lazy и прочее не обеспечивают ни первого ни второго, и, соотвественно, почти никогда не используются.
Неочевидно. Почему санки, неявно создаваемые компилятором, будет более эффективны, чем явные? Скорее, наоборот. Возможность, явного аннотирования как раз является некоторым средством оптимизации и позволяет использовать ленивость только там, где она действительно нужна.
Если все так хорошо с lazy by default, то откуда вообще берутся всяческие Eager Haskell, Concurrent Haskell?
Складывается впечатление, что ты имеешь в виду некий конкретный язык, где эти явные санки реализованы не лучшим образом. Я не знаю, как дела обстоят в Алисе, но неужели в Омеге или Pure все тоже настолько плохо?
K>IDE появились для языков и библиотек в которых на каждое 2+2 полагается три экрана бойлерплейтной обвязки, а сам + именуется как-нибудь вроде НоВГорлоЯУспелВоткнутьИТамДваРазаПовернутьМоеОружье (перегружено для 256 вариантов аргументов). Отсюда очевидны и виды проблем, которые ИДЕ решают, т.е. генерация бойлерплейта и, что более актуально, потому что никаким совершенствованием языка тут делу не поможешь — автоматизированное преобразование кода и навигация по коду. Функциональность репла — т.е. возможность быстро испробовать небольшой фрагмент кода в ИДЕ появится могла только в самой зачаточной форме — ведь в языках, для которых иде разрабатывались не бывает кусков кода одновременно работающих и небольших. Наоборот, репл характерен для языков в которых не нужно писать мегабайты бойлерплейта, а типичная программа вычисляет факториал — так что навигация по ней тривиальна, как, собственно, и ее ручное преобразование. Когда же эти языки внезапно стали применять на практике — проблема навигации по коду встала в полный рост.
Как-то ты сгущаешь краски. Современные IDE появились в общем не так давно — на то они и "современные". То, что там раньше так называлось, сейчас уже в общем и неважно. Я не уверен, что генерация бойлерплейта — основная задача ИДЕ. Основная задача ИДЕ, на мой взгляд, сократить кол-во ошибок компиляции. Ну т.е. пишу я блокноте, компилирую, у меня получается n>100 ошибок, я их начинаю исправлять. Задача ИДЕ сократить это n до минимально возможной цифры — т.е. ИДЕ должна уметь показывать мне ошибки по мере набора кода. Это ИМХО главная задача. Плюс рефакторинг. Но рефакторинг тоже не должен сводиться к генерации бойлерплейта. Я вообще ни разу не пользовался этими "генераторами бойлерплейта", но пользу от ИДЕ тем не менее вижу.
Да и языки современные не настолько плохие. Так или иначе присутствует все же некоторая "модульность" — пусть и не на уровне функции (хотя может и на уровне функции). Нет таких законов природы, по которым в том же C# "не бывает кусков кода одновременно работающих и небольших". Да, пусть там этот кусок будет классом, а не функцией — но какая разница? Идеологии РЕПЛа это никак не противоречит. Сильно связанный код, конечно, встречается, но по-моему это в рамках любой парадигмы плохо.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Kluge, Вы писали:
K>>Разнесли понятие null и понятие "нет значения". Уже за это, по моему, стоит переходить на F#.
Ф>а зачем тогда нужен null?
Здравствуйте, SilentNoise, Вы писали:
SN>Понимаю, вот только внешнее проявление абсолютно одинаковое — что и вызывает сомнения в одном из: SN>а) убогости алгоритма вывода типов F#; SN>б) неубогости алгоритма Nemerle;
Проявления совершенно разные. У немерла проблема проявлялась только в условиях наличия перегрузи. У F# всегда.
Собственно это дело я уже пофиксил. Так что пример никова компилируется корректно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, G-Host, Вы писали:
GH>Здравствуйте, -n1l-, Вы писали:
N>>Может я чего не понимаю, но зачем нужен F# если есть C#? GH>а вб.нет зачем нужен? GH>он же в отличие от фа диеза пратически ничего не предлагает — но при этом популярность имеет.
Он знаком многим гораздо больше, это раз, а два, его сам майкрософт позиционирует как основной для .net
