Здравствуйте, thesz, Вы писали:
T>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь. T>Я воздержусь от описания всех этих невероятно полезных вещей и даже не буду намекать на выгоду от их использования. T>Да я вообще о них не буду упоминать. T>Вот.
Уломали)
Поставил GHC.Купился исключительно из-за синтаксиса,больно нравится.Производительность вроде схожая с Ocaml в синтетических тестах.
Будем смотреть.
Всем спасибо за советы.
T>>Да я вообще о них не буду упоминать. T>>Вот. А>Уломали) А>Поставил GHC.Купился исключительно из-за синтаксиса,больно нравится.Производительность вроде схожая с Ocaml в синтетических тестах. А>Будем смотреть. А>Всем спасибо за советы.
Прошу высокое жюри учесть, что я вообще не делал попыток хоть как-то рекламировать Хаскель.
Ну, если что, спрашивай.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Сколько раз я её упоминал? Q>>Я, право, сбился со счёта. T>То есть, ты не собираешься отвечать за свои слова.
Нет, Сергей Зефиров, я могу ответить за свои слова. Вот только станет ли тебе от этого легче? Я просто добродушно подшутил над твоим хвастовством, не со зла. Конкретизировать я не хотел, просто чтобы не выставить тебя в неприглядном свете. Но ты всё тянешь и тянешь меня за язык, при том обидеть норовишь. Раз уж ты настаиваешь...
1) В давней дискуссии с zabivator'ом твоё ораторское мастерство проявилось во всей красе:
На фотографии под штангой — я. Ну, чтобы ты знал, если что.
T>То есть, ты не собираешься отвечать за свои слова. T>Что ж, Qbit86, grown up indication set to off. For a longer time now.
Что ж, таким вот нехитрым приёмом ты и поставил меня в дурацкое положение, вынудив кому-то что-то доказывать, откапывать твои нелицеприятные высказывания. Ты доволен?
T>>>>Сколько раз я её упоминал? Q>>>Я, право, сбился со счёта. T>>То есть, ты не собираешься отвечать за свои слова.
Q>Нет, Сергей Зефиров, я могу ответить за свои слова. Вот только станет ли тебе от этого легче? Я просто добродушно подшутил над твоим хвастовством, не со зла. Конкретизировать я не хотел, просто чтобы не выставить тебя в неприглядном свете. Но ты всё тянешь и тянешь меня за язык, при том обидеть норовишь. Раз уж ты настаиваешь...
Q>1) В давней дискуссии с zabivator'ом твоё ораторское мастерство проявилось во всей красе: Q>
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, thesz, Вы писали:
T>>Grown up check failed for not following the discussion in time.
T>>Plase, try again later.
Q>Засчитан.
Думаю из этой беседы будут сделаны правильные выводы и выбран Ocaml
T>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь.
Ну если REPL — образец великолепия... Впрочем, я достаточно либерален и спокойно отношусть к мазохизму. Это ж надо, ловить кайф от того, что софтина пишется в одном месте (скажем, в текстовом редакторе), а проверка типов, разного рода экспериментирование и т.д. — в другом (REPL).
Конечно, реализовать REPL проще чем приличный IDE где все то же самое было бы прямо в редактируемом модуле. Кстати, нечто подобное Common LISPеры сделали в своем Slime. Для языков типа Haskell это было бы еще удобнее. Но "Emacs это наше все" и нет света в конце тоннеля. Разве что может Leksah?
GADT это сила, сомнений нет. Одна из тех вещей, что подчеркивают убожество языков типа Java. Вот только разве нет их в том же Ocaml? В хаскель, конечно, через GADT все делается. Прямо как в одном бородатом анекдоте. Даже records. И никого не смущает ни мусор из-за валяющихся под ногами функций доступа к полям, ни бредовый синтаксис этих самых records, ни прочие прелести. Впрочем, тут я преувеличиваю. Были какие-то предложения это исправить, но воз и ныне там.
Увидительно эффективный и мощный компилятор. Когда глядел на него последний раз, то результат непосредственной компиляции в native был в разы тормознее окольного пути генерации Cшного кода и потом компиления оного. Далее, пробовал чисто формально обернуть в монаду фнкцию что проходит по строке и выбрасывает символы удовлетворяющие простенькому условию. Результат удручающий — скорость упала в 10 (десять) раз. Видимо это так сей компилятор умеет выбрасывать ненужные ветви исполнения и именно так в хаскеле демонстрируется мощь ленивых вычислений.
Изящество синтаксиса. Хочешь передать функции foo пару отрицательных чисел — будь добр обернуть их в скобки.
foo (-1) (-2)
Сравниваем с LISP:
(foo -1 -2)
Да, конечно это не часто нужно. Но я что слышал это имено в LISP сильно много скобок.
Система типов. Да, typeclassы это хорошо. Действительно удобная штука. Вот только почему-то в стандартных библиотеках начхать всем на них. Вот что мешало сделать штуки типа "null", "empty", "singleton" методами абстрактных TypeClass'ов? А так импортнешь IntSet и Seq и сразу же каша получается.
Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
Поддержка Unicode... Эх, не будем о грустном и вечном.
Но особенно радует runtime. Если ни дай Бог программа съест много памяти — бах, и лежит труп с out of memory. Понять, из-за чего она сдохла почти не реально. Тем более, что она вся такая модная и ленивая и на такие мелочи как нормальный мониторинг потребления ресурсов и экономное расходование памяти не отвлекается. Да, я в курсе что есть такая штука как нагрузочное тестирование. Вот только лишь для самых простых случаев это потребление памяти можно им надежно отследить. На все остальное самый действенный способ — неистовая молитва.
P.S. И несмотря на все вышеперечисленное, Haskell действительно (не, я серьезно) один из самых лучших языков на данных момент. Прямо как Unix: "Unix — паршивая ОС, но лучше пока ничего не придумали".
I cannot emphasize this enough. GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser. Ocaml takes 1-2-3 seconds. I use a 2Ghz Core Duo MacBook Pro and Topdog is decidedly not a large project which makes the difference all the more glaring. With Haskell I was loath to touch the parser or my syntax tree definition, with OCaml I look forward to tweaking things to my hearts content. Normal recompilation time of Topdog is so far as to be almost unnoticeable.
Интересно неужели за два года GHC смог ускорится на порядок.
FR>I cannot emphasize this enough. GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser. Ocaml takes 1-2-3 seconds. I use a 2Ghz Core Duo MacBook Pro and Topdog is decidedly not a large project which makes the difference all the more glaring. With Haskell I was loath to touch the parser or my syntax tree definition, with OCaml I look forward to tweaking things to my hearts content. Normal recompilation time of Topdog is so far as to be almost unnoticeable.
FR>Интересно неужели за два года GHC смог ускорится на порядок.
Тут про сборку написано а не про время работы собранного софта. Так что все логично и GHC не ускорялся.
А воообще-то 2-4 минуты на сборку это нехило. И легко объясняет приверженность REPLу. Т.к. "на безрыбье и рак — рыба".
Здравствуйте, Rtveliashvili Denys, Вы писали:
FR>>Интересно неужели за два года GHC смог ускорится на порядок.
RD>Тут про сборку написано а не про время работы собранного софта. Так что все логично и GHC не ускорялся.
Да что-то меня прерклинило
RD>А воообще-то 2-4 минуты на сборку это нехило. И легко объясняет приверженность REPLу. Т.к. "на безрыбье и рак — рыба".
T>>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь. RD>Ну если REPL — образец великолепия... Впрочем, я достаточно либерален и спокойно отношусть к мазохизму. Это ж надо, ловить кайф от того, что софтина пишется в одном месте (скажем, в текстовом редакторе), а проверка типов, разного рода экспериментирование и т.д. — в другом (REPL). RD>Конечно, реализовать REPL проще чем приличный IDE где все то же самое было бы прямо в редактируемом модуле. Кстати, нечто подобное Common LISPеры сделали в своем Slime. Для языков типа Haskell это было бы еще удобнее. Но "Emacs это наше все" и нет света в конце тоннеля. Разве что может Leksah?
Сразу после проверки типов ты проверяешь функциональность. И это нормально,
RD>GADT это сила, сомнений нет. Одна из тех вещей, что подчеркивают убожество языков типа Java. Вот только разве нет их в том же Ocaml? В хаскель, конечно, через GADT все делается. Прямо как в одном бородатом анекдоте. Даже records. И никого не смущает ни мусор из-за валяющихся под ногами функций доступа к полям, ни бредовый синтаксис этих самых records, ни прочие прелести. Впрочем, тут я преувеличиваю. Были какие-то предложения это исправить, но воз и ныне там.
Синтаксис записей наилучший из возможных в чистом функциональном языке.
RD>Изящество синтаксиса. Хочешь передать функции foo пару отрицательных чисел — будь добр обернуть их в скобки. RD> foo (-1) (-2) RD>Сравниваем с LISP: RD> (foo -1 -2)
Бляха муха!
Я понял, отчего у меня программа-то такая большая! У меня на 2500 строк кода есть строка с отрицательными числами!
Вот она, зараза:
noPos = Pos "<artifical position>" (-1) (-1)
RD> RD>Да, конечно это не часто нужно. Но я что слышал это имено в LISP сильно много скобок.
Перехожу на Liskell или как его там. Сегодня же.
RD>Система типов. Да, typeclassы это хорошо. Действительно удобная штука. Вот только почему-то в стандартных библиотеках начхать всем на них. Вот что мешало сделать штуки типа "null", "empty", "singleton" методами абстрактных TypeClass'ов? А так импортнешь IntSet и Seq и сразу же каша получается.
Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь.
RD>Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
Как ты им тип будешь задавать?
Но если ты хочешь, есть вариант.
RD>Но особенно радует runtime. Если ни дай Бог программа съест много памяти — бах, и лежит труп с out of memory. Понять, из-за чего она сдохла почти не реально. Тем более, что она вся такая модная и ленивая и на такие мелочи как нормальный мониторинг потребления ресурсов и экономное расходование памяти не отвлекается. Да, я в курсе что есть такая штука как нагрузочное тестирование. Вот только лишь для самых простых случаев это потребление памяти можно им надежно отследить. На все остальное самый действенный способ — неистовая молитва.
Программист только тогда по настоящему программировал на ЯП, когда он профилировал свои программы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>Grown up check failed for not following the discussion in time. T>>>Plase, try again later. Q>>Засчитан. FR>Думаю из этой беседы будут сделаны правильные выводы и выбран Ocaml
Ты прав.
Нафиг Лискель, перехожу на ОКамл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>Сразу после проверки типов ты проверяешь функциональность. И это нормально,
Да, конечно это нормально. Просто если пользуешься REPL то это зверски неудобно. Разве Вам не кажется, что проще делать это прямо в IDE и не возиться с постоянным перебрасыванием кода в REPL (что еще более-менее приемлемо) и обратно (что уже совсем изврат)?
В упомянутом мной Slime это делается на раз. Пишешь код, жмешь shortcut и он выполнился. Результат выполнения виден. Не нравится — подправил, проверил снова. А из REPL вытащить когда-то определенную там ф-цию или структуру почти невозможно.
Но все это проблема не языка, конечно, а его инфраструктуры.
T>Бляха муха!
T>Я понял, отчего у меня программа-то такая большая! У меня на 2500 строк кода есть строка с отрицательными числами!
T>Вот она, зараза: T>
T>noPos = Pos "<artifical position>" (-1) (-1)
T>
Я думал заметят, что это — шутка... Ладно, шутить не буду.
T>Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь.
Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
a -> Set a
a -> Seq a
Неужели type inference в haskell не просечет что если я делаю singleton "1" и дальше пользуюсь им как Set, то я использую singleton из Set а не из Seq? Особенно, если есть некий typeclass Singletonable с этим методом и Set с Seq являются частными случаями.
RD>>Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
T>Как ты им тип будешь задавать?
"Не осилили ф-ций с переменным числом аргументов" в данном случае значит само описание типа функций предполагает что число аргументов фиксировано. Думаю, на это есть какая-то причина. Например, что если это число не фиксировано, то type inference работать не будет.
T>Но если ты хочешь, есть вариант.
О! Спасибо за ссылку. Будет интересно почитать.
T>Программист только тогда по настоящему программировал на ЯП, когда он профилировал свои программы.
Как я уже говорил, профилирование не всегда спасает. Если софт достаточно сложный, то можно просто не догадаться о каком-то случае, где пойдет резкий рост потребления ресурсов. Преставьте себе, что речь идет не о программе в 100-1000 строк написанной одним человеком а скажем о софте в 100K, который писали человек 20.
Кроме того, если софт уже работает в продакшн, то желательно иметь возможность следить за тем, сколько он уже отъел. Хотя бы чтобы не произошло неожиданной беды. В Java для мониторинга есть JMX. А есть ли для хаскеля нормальные средства мониторинга? Лично я не видел ни разу. Что весьма прискорбно.
Обратно же, если у софта out of memory, то желательно чтобы сдохла не более чем одна нить, и было ясно где она умерла. Но этого, насколько я понимаю, от GHC добиться не получится.
Аноним 538 пишет:
> Важна скорость и удобство.Собственно интересует пока только > прототипирование,но если скорость будет приличной можно и остановиться > на выборе,по сему важны привязки к C(++) .
На сколько я знаю, вызов лиспового кода из С(++) — проблемы
большие (наоборот — легко, как правило). Т.е. вполне возможно
придётся использовать всякие IPC, доступные с двух сторон.
> О LISP слышал много чего хорошего,причём использовать/реализовать можно > любую парадигму программирования.Но вот о скорости не нашёл ни > чего.
Естественно, как напишешь, и какую реализацию возмёшь (есть компиляторы,
есть даже может быть, если остались, голые интерпретаторы, есть и
a la Java virtual machine.
но в некоторых случаях она достигает С-шную.
Т.е. быстро.
