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

G>>В больших программах на Хаскеле встречаются трудноуловимые утечки памяти, независимо от области применения.

T>"Встречаются" — это просто песня.

T>Сейчас попробую развить...

T>Вот!

А ведь ты свой мемлик-то так и не нашел . Прикинь — а если б это не модель процессора МИПС была, а сервер, который должен работать месяцами? А? Лапками кверху?

Вот и выставляешь сейчас заслоны из теории и шуток. Заслон из практики — слабо? Научился бы ловить эти лики, блин. Так нет — шутишь.

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


G>Отвечу кратко. <skipped> Аналогичный код в "строгом Хаскеле", с предлагаемой (примерной) аннотацией ленивости.

G>

G>-- | переключалка между несколькими сценами
G>scene = state1
G>    where state1 = ? switch scene1 [event1 --> state2, event2 --> state3]
G>          state2 = ? switch scene2 [event3 --> ...]
G>          ...
G>          stateN = ? ...

G>Разница только в том, что места, где вы полагаетесь на ленивость, указаны явно. А не наоборот. И все. Насчет счетчика, я уверен, вы сами проставите ленивость, где надо. ? - говорит о том, что вычисления на том же уровне ленивы. Его scope ограничен скобками, например.

G>-- | тупой счетчик
G>counter n = switch (pure n) [tick --> counter (n+1)]
G>

Вы замечательно придумали, на N+1 строчку N аннотаций ленивости. Спасибо, очень удобно. А всё то, что будет использовать этот код, мне тоже помечать?

Получается, что аннотация расползается всё дальше и дальше, и на каком-то этапе проще забить на неё и сделать дефолтной.

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

А>Вы замечательно придумали, на N+1 строчку N аннотаций ленивости. Спасибо, очень удобно.

Да, я замечательно придумал. Не за что.

А>А всё то, что будет использовать этот код, мне тоже помечать?

Нет, то что будет использовать этот код, помечать не нужно. Если включить мозг в положение ON, можно было бы и догадаться.

А>Получается, что аннотация расползается всё дальше и дальше, и на каком-то этапе проще забить на неё и сделать дефолтной.

Получается, что не будет. Кроме того, крайне любопытно, как вы будете искать лики, если вам проще сделать все дефолтной и не думать о строгости и ленивости. Полный strictness analyzis который расставляет строгость автоматически — NP-полная задача, что означает, что лики у вас будут.

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

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

G>>>В больших программах на Хаскеле встречаются трудноуловимые утечки памяти, независимо от области применения.

G>А ведь ты свой мемлик-то так и не нашел . Прикинь — а если б это не модель процессора МИПС была, а сервер, который должен работать месяцами? А? Лапками кверху?

"В больших программах на <вставьте-что-угодно> встречаются трудноуловимые утечки памяти, независимо от области применения".

Вот тут вы сами сказали — "сервера, которые должны работать месяцами". Для решения таких задач есть erlang, он очень хорошо сюда вписывается. Да, гайки можно откручивать пассатижами, тут никто не спорит, но ключами всё-таки удобнее. Доказывать то, что такие задачи *физически выполнимы*
на хаскеле я не буду, это и так ясно. Вопрос только во времени и в ресурсах.

Coverage и profiling (включая использование памяти) есть по дефолту в ghc. Можно посмотреть и найти мемлики. Не думаю, что будет очень сложно (не сильно сложнее попыток исправить трудновоспроизводимый лик в программах на других языках).

Вообще, я часто пишу утилиты "на выброс" с мемликами и кривой отчисткой ресурсов, так как по закрытию ОС сама всё почистит. А на работе требования к софту другие. Идиального софта нет, везде есть ошибки. И если сейчас всё устраивает заказчика, то всё ок.

Пример: эмулятор, который запускается 16 раз в день, каждый запуск — 15 секунд. Но у эмулятора есть проблема — через 2-3 часа непрерывной работы у него кончается хип. Так стоит ли в этом случае тратить время на поиск и исправление этой ошибки?

Это я к тому, что говорить о том, что наличие *возможных* *трудноуловимых* мемликов ставит крест на использовании lazy evaluation — неверно.

G>Вот и выставляешь сейчас заслоны из теории и шуток. Заслон из практики — слабо?

Тебе thesz привёл пример с исключением, можешь открыть ghci/hugs/etc и проверить. На "пальцах" показана ошибка, которая возникает из-за форсирования результатов. Что не так?

G>>>В больших программах на Хаскеле встречаются трудноуловимые утечки памяти, независимо от области применения.
T>>"Встречаются" — это просто песня.
T>>Сейчас попробую развить...

T>>Вот!

G>А ведь ты свой мемлик-то так и не нашел . Прикинь — а если б это не модель процессора МИПС была, а сервер, который должен работать месяцами? А? Лапками кверху?

Я бы немного по другому писал.

Или вообще написал бы на Хаскеле описание проблемы.

G>Вот и выставляешь сейчас заслоны из теории и шуток. Заслон из практики — слабо? Научился бы ловить эти лики, блин. Так нет — шутишь.

Просто у всех встречаются разные вещи.

Как, например, ловить опечатку в большой программе на K?

T>>>Первый релиз Clean 1994.
G>>Надо же, я думал Клин старше...
К>Это именно первый публичный релиз по ходу дела, перый "внутренний" был ещё в 1987-м вроде как (здесь).
К>SPJ вроде не раз упоминал, что Плазмейер активно участвовал в работе над Хаскелем и по первости были идеи "слить" 2 языка.

Или наоборот:

[url=http://www.computerworld.com.au/index.php/id;1974033854;fp;2;fpid;4]Most of the researchers we approached said yes; I think at that stage probably the only one who said no was David Turner, who had a language called Miranda, and Rinus Plasmeijer, who had a language called Clean. He was initially in the committee but he then dropped out.[/url

Вот как-то так.

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

T>Или наоборот:
T>

Most of the researchers we approached said yes; I think at that stage probably the only one who said no was David Turner, who had a language called Miranda, and Rinus Plasmeijer, who had a language called Clean. He was initially in the committee but he then dropped out.

Вот именно факт про dropped out я и имел в виду.

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

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

А>>Да, ты верно говоришь, что у хаскеля другой уровень и другая область применения. Никто не станет писать ray-tracer на erlang, и от того, что erlang медленнее хаскеля/clean/etc в какой-то области его никто не станет выбрасывать, так как он затачивался под другие задачи.

G>Вся дискуссия, к сожалению, построена на том, что большинство участников за неимением ответов на вопрос Гапертона, тупо игнорируют его, пытаясь ему в ответ ему выливать все что угодно. Писал я про класс применений, если ты не заметил.

Да, видимо не заметил. Если так — прощу прощения. Прочитал первое сообщение в теме и почему-то пропустил область применеия.

G>В больших программах на Хаскеле встречаются трудноуловимые утечки памяти, независимо от области применения

То же самое говорили разработчики Явы про С++ и С. Но ведь "трудноуловимость" зависит от квалификации программиста и от его мозга, не так ли? Если джуниор не может что-то понять и "уловить утечку" в своей второй/третьей программе на Хаскеле/<чём угодно>, то язык тут винить нужно в последнюю очередь. Имхо, конечно.

G>Остаются быстро работающие консольные аппликухи, которые не ограниченны памятью, и не жуют обчень больших данных. Только в данном классе приложений нам данная проблема не доставит проблем. Офигенный "класс приложений". Рекомендую.

Ага, спасибо за рекомендацию, чтоб я без неё делал! А какая проблема с обработкой "обчень больших данных"?

Бесконечные списки это недостаточно "большие данные"?

Вы же на С++ (или на любом другом языке) не будете реализовывать всё сами, а возьмёте либу (буст/что угодно) и напишите "обработку". Не вижу проблем. Или это опять намёк на "отстойность" хаскеля при реализации "альфа-блендера"?

А>>Именно поэтому что-то обьяснить ему не получится — так как всегда можно найти примеры, где ленивость не нужна (опять же, real-time приложения, интенсивные вычисления и т.п.). Вот так и получается, что раз "плоской" отвёрткой крутить шурупы с другим шлицом неудобно, то отвёртку нужно выбрость, потому что она больно не универсальная, и ещё нужно думать, какие отвёртки выбирать.

G>Объяснить ничего не получается, если не понимаешь, о чем идет разговор. Сочувствую. Я нигде не говорил, что "ленивость не нужна". Я говорил, что у полной ленивости по умолчанию есть проблемы. Это очень сложно понять? Очень сложно, блин, не заметить разницы между этими двумя тезисами?

У полной ленивости по умолчанию? Где вы такое говорили? Я почему прочитал как:

G> явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.

Теперь я знаю, что это нужно читать как "у полной ленивости по умолчанию есть проблемы". Если переформулировать это выражение вот так:

"Есть задачи, где полная ленивость по умолчанию приносит много проблем" — то я буду полностью с вами согласен. Действительно, использовать "полную ленивость" смысла нет — слишком много проблем. Но ведь именно для их решения и придумали вещи для управления ленвостью, разве нет??

Так что можно форсировать вычисление некоторых частей, точно так как же, как и пометить остальные части "ленивыми" в случае ващего подхода. Что вам не нравится? Мне вот в вашем подходе не нравится вставлять в N/(N+1) строк кода аннотации ленвости, уж лучше я поставлю 1/(N+1) аннотацию строгости. Не люблю мартышкин труд.

P.S. Не могу удержаться и не намекнуть на наличие ленивых/не ленивых версий разных модулей в хаскеле "из коробоки",
и не намекнуть на то, что проблемы всё-таки не у ленивости, а у тех, кто криво её использует (ну, или пытается использовать).

Всё, что я хотел от вас — это услышать то, что вы написали после чуть ли не десятка страниц, а именно — что использование "полной дефолтной ленивости" в embedded приложениях (если это значит использование языка haskell), а так же написание 24/7 телеком/high reliability серверов на ленивом языке (зачем, есть же ерланг, который для этого и делался??) и разный софт-риал-тайм неоправданно, так как есть более подходящие инструменты. Про это я вам и говорил.

И ещё одно замечание, а если я вставлю явные аннотации строгости, то программа всё ещё будет попадать под категорию "полная ленивость по умолчанию"? Или это будет просто ленивость, а не "полная"? А если за заимпортирую неленивую реализацию какого-нить модуля, и напишу код с использованием этого модуля, то ленивость останется?

Простые вещи нужно делать просто. И одна из главных черт хорошего специалиста — это выбор правильного инструмента для решения задачи. Писать что-то на том, что плохо подходит — это можно делать либо ради интереса (aka fun), либо что-бы занять команду и обеспечить им много удовольствия от решения созданных проблем, либо чтоб развести заказчки на много денег и продлить радости общения (и получения прибыли) (j/k)

А про то, что остались только консольные приложения, которые хаскелл (в качестве примера ленивого языка) может "потянуть" — да, это самое очевидное, но это далеко не всё, не так ли?

T>Как, например, ловить опечатку в большой программе на K?

Ну, например падением сптника на Венеру

Здравствуйте, FR, Вы писали:
FR>По Хаскелею вообще хоть что-то бы, а то я кроме компиляторов, Булатовского архиватора и оконого менеджера для linux и не слышал больше ничего.
Ещё darcs есть.

Здравствуйте, geniepro, Вы писали:
G>Gtk2Hs требует GTK+, QtHaskell и wxHaskell как-то нетривиально устанавливаются, с полпинка у меня не получилось... Ужасно всё...
С установкой QtHaskell на винде никаких проблем не заметил.
Правда пользоваться пока не пробовал.

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

FR>По Хаскелею вообще хоть что-то бы, а то я кроме компиляторов, Булатовского архиватора и оконого менеджера для linux и не слышал больше ничего.

Cryptol ?

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

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

FR>>По Хаскелею вообще хоть что-то бы, а то я кроме компиляторов, Булатовского архиватора и оконого менеджера для linux и не слышал больше ничего.

К>Cryptol ?

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

T>С установкой QtHaskell на винде никаких проблем не заметил.
T>Правда пользоваться пока не пробовал.

До установки QtHaskell я так и не дошёл, так как споткнулся на установке Qt. Вот все эти нетривиальности отбивают желание пользоваться неродными библиотеками ГУИ...

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

G>Вся дискуссия, к сожалению, построена на том, что большинство участников за неимением ответов на вопрос Гапертона, тупо игнорируют его, пытаясь ему в ответ ему выливать все что угодно. Писал я про класс применений, если ты не заметил.

G>В больших программах на Хаскеле встречаются трудноуловимые утечки памяти, независимо от области применения.

я так понимаю, у тебя большой опыт в этом деле? расскажи нам про эти утечки

из моего опыта: да, в моём архиваторе утечки есть. поскольку написан он на хаскел и c++, и утечки как раз в этой сишной части. поскольку без выделения памяти не обойтись, а освобождать всё выделенное явно — это ещё больше усложнять программу. плюс к этому память фрагментируется, так что сжать скажем миллион файлов поодиночке не получится. в хаскеловской же части наоборот — была одна крупная "утечка", в смысле невычислявшийся thunk, болтавшийся в памяти. когда я просёк что такое l;azy evaluation, я эту проблему нашёл и изничтожил. но, надо сказать, произошло это только через полтора года после начала написания архиватора, т.е. после полутора лет использования языка. так что предположение о том, что не очень опытные в хаселе программисты будут допускать такие утечки — совершенно верно

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

А>>Да, ты верно говоришь, что у хаскеля другой уровень и другая область применения. Никто не станет писать ray-tracer на erlang, и от того, что erlang медленнее хаскеля/clean/etc в какой-то области его никто не станет выбрасывать, так как он затачивался под другие задачи.

FR>Вот мне как раз интересна реальная область применения Хаскеля. И я пока вижу что она очень узка и в основном сводится к прототипированию и компиляторам.

на мой взгляд хаскел нет смысла применять в двух областях — 1) там где требуется высокая эффективность — пишите на С++. 2) там где уже есть готовые RAD toold — в частности при разработке "бизнес-приложений", вы просто не получите от хаскела выигрыша

во всём остальном его применять выгодно — будь то веб-сервисы, манипуляции с текстами или игры

конкретно, в моей программе алгоритмы сжатия написаны на C++, управляющая логика — на хаскеле, и GUI я надеюсь приписать на C#. и это — оптимальное разделение ролей