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

K>>Я не считаю, что C-подобный синтаксис подходит для ФЯ.

VD>Он подходит для популярных языков.
VD>Если популярность не важна, то можно иметь любой синтаксис.

Ну ну, расскажи это тем, кто пишет на популярнейшем языке Delphi или на популярнейшем языке Python.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ> не будет распаковки пареметров туплов (т.к. тупл — тоже CLR-ный объект, с чего бы его распаковывать?) и тому подобного.

Это есть, но не в public surface, естественно

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

А> Ну ну, расскажи это тем, кто пишет на популярнейшем языке Delphi или на популярнейшем языке Python.

На фоне си-подобных языков, я бы не осмелился назвал их особо популярными.

Но в сравнении с ML-ым синтаксисом, алгол-подобные языки (вроде Дельфи) выглядят классикой.

Не трудно заметить, что все, хоть сколько-нибудь популярные языки, имеют привычный по математике средней школы синтаксис вызова функций. Языки же с ML-ным синтаксисом так на всегда и останутся маргинальными. Массы их никогда не примут.

Здравствуйте, Пельмешко, Вы писали:

П>Это есть, но не в public surface, естественно

Дай ссылку.

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

VD>Не трудно заметить, что все, хоть сколько-нибудь популярные языки, имеют привычный по математике средней школы синтаксис вызова функций. Языки же с ML-ным синтаксисом так на всегда и останутся маргинальными. Массы их никогда не примут.

Как хорошо, что еще остались люди, готовые делать маргинальные языки. Благодаря им мы имеем хорошие вещи. А yet another java не нужна. По крайней мере мне, как деплоймент-иженеру.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Как хорошо, что еще остались люди, готовые делать маргинальные языки. Благодаря им мы имеем хорошие вещи.

Ага, замечательно! Это называется научные исследования. Жаль только, что в нашей, компьютерной, сфере наука живет отдельно, а производство отдельно. Во всех других сферах жизнедеятельности человека наука разрабатывает новые идеи, а практики адаптируют их для реальной жизни и внедряют в практику. У нас же складывается страннейшая ситуация. В реальную практику попадают только микроскопические крохи научных разработок.

ПМ>А yet another java не нужна. По крайней мере мне, как деплоймент-иженеру.

А я, вот, как программист, не только не против, но и пригрел одну такую. И мне на фиг не упали разные Хаскели и тем более F#-ы (в которых интересного для меня ноль целых ноль десятых). Потому как для того чтобы писать реальный софт нужны тонны библиотек, IDE с рефакторингом блэкджеком и шлюхами и многое другое, а не мегафичи единственным осмысленным применением которых является удовлетворение своего ЧСВ.

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

VD>Ага, замечательно! Это называется научные исследования. Жаль только, что в нашей, компьютерной, сфере наука живет отдельно, а производство отдельно. Во всех других сферах жизнедеятельности человека наука разрабатывает новые идеи, а практики адаптируют их для реальной жизни и внедряют в практику. У нас же складывается страннейшая ситуация. В реальную практику попадают только микроскопические крохи научных разработок.

Ты драматизируешь. Разработки, имеющие реальный экономический эффект, попадают в практику очень быстро. Вспомни, как быстро стали популярными языки с мусоросборниками или реляционные базы данных. Не думаю, что в каком-нибудь автобизнесе путь от исследования до реализации на конвеере проходится быстрее.

VD>Потому как для того чтобы писать реальный софт нужны тонны библиотек, IDE с рефакторингом блэкджеком и шлюхами и многое другое, а не мегафичи единственным осмысленным применением которых является удовлетворение своего ЧСВ.

Кстати, конкретно у Хаскеля с библиотеками не всё так плохо — часто легко можно найти то, что трудно найти для C# (если вообще возможно). Качество самих библиотек, конечно, не промышленное, но благодаря языку они довльно компактны и легко допиливаются без боязни что-либо сломать. Часто это даже быстрее чем разбираться в донетовских боингах, с которыми уже, как правило, ничего не сделать, если там что-то не так.

А IDE для девочек. Настоящие мужики разводят костёр с одной спички, бреются остро заточенным топором и программируют в голом текстовом редакторе.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>А IDE для девочек. Настоящие мужики разводят костёр с одной спички, бреются остро заточенным топором и программируют в голом текстовом редакторе.

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

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

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

Занятные движения в MS. Фшарперы тоже решили сделать вид что им интересно мнение пользоватлей
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30935-languages-f-

Учитавая реакцию Сайма на самое популярное предложение про тайпклассы
(в переводе "а-а-а... мне мешает CRL, который я и разрабатывал и, вообще,
что это вы мне предлагаете, что б я работал, это другие должны делать"),
все что займет на разработку больше 2 недель (больше никак нельзя —
времени на поездки в лондон на презентухи не останется) сделано
не будет. Ни одной акцепнутой идеи для F# на текущий момент нет.
Значит нам на все ваши хотелки ... — мы все равно будем в песочнице делать,
что нам интересно, а для отмаза у нас есть стандарный набор фраз, которые
будут использоваться пока народ ведется, и группа верующих, несущих эти
кривые отмазы в народ.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Кстати, конкретно у Хаскеля с библиотеками не всё так плохо — часто легко можно найти то, что трудно найти для C# (если вообще возможно). Качество самих библиотек, конечно, не промышленное, но благодаря языку они довльно компактны и легко допиливаются без боязни что-либо сломать. Часто это даже быстрее чем разбираться в донетовских боингах, с которыми уже, как правило, ничего не сделать, если там что-то не так.

Ставил тут на днях yesod поиграться через cabal (haskell). Порой веселое занятие. Некоторые пакеты не хотели собираться. В одном пакете вообще была опечатка в коде.

Здравствуйте, InCus, Вы писали:
IC>рекламировалось как новый серебрянный пуль от MS,

Можно ссылку на рекламу? А то у меня такое ощущение, что я пропустил что-то очень важное.

Здравствуйте, 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

Прокатывает, но не проходит. Как говорится, у каждого свои недостатки

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

N>Прокатывает, но не проходит. Как говорится, у каждого свои недостатки

Такое, кстати, тоже не прокатило:

def f = _.ToLower; // Error: typing fails on ambiguity between overloads
_ = f("ABC")

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

N>

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 не может быть стипизированна. Вот так вот все будет работать:

  def f(x) { x.ToLower() }
  def x(_ : string) : void { }
  x("ABC" |> f);

так как будет откуда вывеси тип возвращаемого значения функции.

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

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

VD>Это скорее недоработка реализации.

То есть, в F# это принципиальная убогость алгоритма вывода типов, а в немерль — всего-лишь недоработка?)

Здравствуйте, 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
Дата: 07.09.11

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