Здравствуйте, 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# как бы имеет официальную поддержку корпорации — что никак не проявляется на практике, интеграция никак не развивается. Так что от моего оптимистичного заявления

Автор: Klapaucius
Дата: 07.09.11

я вынужден отказаться.

Самое смешное тут в том, что ты вообще заметил какие-то положительные стороны Лексах.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Для слушателей, которые не видели Лексах, я сначала объясню о чем речь.

Leksah написан на GTK. На этом можно было остановиться.

Здравствуйте, 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 — произвело на меня сокрушительное впечатление.

Здравствуйте, Qbit86, Вы писали:

Q>Leksah написан на GTK. На этом можно было остановиться.

Верно. Вообще, leksah выглядит как то, чем она и является. Поэтому все ожидания оправдывает на 100%.

Здравствуйте, ArtDenis, Вы писали:

AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?
А какие функциональные языки популярны? Возьмем вот крупнейшую биржу фрилансеров в Германии — гульп. У них есть статистика по всем предлагавшимся за 13 лет проектам. Смотрим по языкам (Язык, все проекты с мая 1999, проекты за последний год):

Language  | 3/1999 | 6/2011 |
----------------------------|
Java      | 33659  |   3211 |
C++       | 16136  |   1287 |
C#        |  5864  |   1054 |
PHP       |  3570  |    467 |
----------------------------|
Lisp      |    25  |      3 |
Scala     |    23  |      2 |
Erlang    |    16  |      0 |
Haskell   |    11  |      2 |
Nemerle ))|     0  |      0 |
----------------------------

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 в формате Вижуал Студии предоставляет средства по сути эквивалетные реплу, но делает это по-другому.

В OcaIDE довольно неплохо интегрирован.
Посмотреть видео демонстрацию можно тут http://www.algo-prog.info/ocaide/tutorials/3-projects/projects.htm

Здравствуйте, ArtDenis, Вы писали:

AD>Странно, что F# пользуется такой маленькой популярностью на этом форуме. Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться, что MS вот-вот прикроют лавочку?

Может я чего не понимаю, но зачем нужен F# если есть C#?

> Странно, что F# пользуется такой маленькой популярностью на этом форуме.
> Казалось бы есть удобная среда и поддержка солидной компании. Или все бояться,
> что MS вот-вот прикроют лавочку?

Да всё очень просто. Где кроссплатформ ?

On 06/22/2012 08:19 AM, -n1l- wrote:

> Может я чего не понимаю, но зачем нужен F# если есть C#?

Ты действительно ничего не понимаешь.

Здравствуйте, MasterZiv, Вы писали:

MZ>Да всё очень просто. Где кроссплатформ ?

Ну сам же компилятор под mono нормально идет.
Да и насчет "прикроют лавочку" не так страшно, open source все-таки.

Объясни же мне, о великий!

Здравствуйте, -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 поддерживает
множество разных языков.