Ленивость или Энергичность по умолчанию? - Декларативное программирование

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

LCR>Gaperton,

G>>Строгая семантика, конечно. Дефолтовая ленивость вынуждает полностью отказаться от побочных эффектов (как в Хаскеле), и делать ввод-вывод и взаимодействие с внешним миром через задний проход, а это неприятно.
LCR>Зато за поддержание чистоты в грязном мире заботится компилятор, а не программистские головы и жопы. Ну и специально для тех, кто привык программировать спинным мозгом, можно вывесить плакат с большой надписью "ДЕЛАЙ ТАК". Короче, здесь банальная разница в точках зрения.

О поддержании чистоты может позаботится компилятор и в грязном языке, если вы введете модификатор pure (или наоборот — dirty

) для функций. В этом случае компилятор проверит и докажет чистоту.

Монадный ввод-вывод не сильно будет отличаться по сути — монады точно так же "заражают" код, и выглядит он все равно императивно. В любом случае будет разумно отделить одно от другого, нет? Так в чем реальная разница?

G>>Второй минус — слабопредсказуемое поведение программы в плане производительности и расхода памяти.
LCR>Согласен, и это вычёркивает Хаскелл из целого ряда задач. Но там уже такая толкотня, что прямо скажем, невелика потеря

Угу, а что остается?

Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.

LCR>Ленивость — это трейдофф между относительно простой моделью выполнения (можно легко оценивать производительность и расход памяти) и семантической простотой (то есть бета-преобразование без ограничений, лёгкость преобразования и склейки программ).

Семантическая простота

. Вы в состоянии рассчитать асимптотическую сложность и расход памяти для ленивой программы большого объема, особенно если над кодом поработал strictness analyzer? Это у нас семантическая простота называется (не, ну я понимаю, бета-преобразование, амфибрахий там, то, се...)?

LCR>Я не знаю, какие техники программирования должен использовать ЯП будущего, но стопудово уверен, что он не должен использовать техники программирования прошлого и не тащить за собой грабли пятидесятилетней давности.

Какие конкретно техники и грабли он не должен за собой тащить?

G>>Для явной (опциональной) ленивости — интересен более общий подход с фьючерсами, который дает не только ленивость, но и много других полезностей. Это, мне кажется, то, что нужно. Примерно как тут: http://www.ps.uni-sb.de/alice/manual/futures.html

LCR>Интересен, ага. Впрочем, я это уже видел, и мне не нравится, что нужно опять ручками отщипывать потоки — я это расцениваю как шаг назад.

А для Хаскеля у нас автоматических распараллеливателей дофига, да?

Кстати, фортрановские и сишные программы уже давно параллелят автоматически — это например интеловские компиляторы умеют.

С фьючерсами же явное управление параллелизмом упрощено по предела — как и должно быть. И от него (явного) никто никогда никуда не денется — по причине разности в скоростях передачи данных внутри кристалла, на плате, внутри стойки, и внутри сети (что было, и всегда будет). Это вынуждает управлять локальностью (и параллелизмом) явно в том или ином виде (автоматом это из программы в принципе не вытащить), если не хотите быстого деградирования производительности на большом числе узлов.

LCR>К тому же забота о независимости отщипываемых вычислений от основных на кого ложится? По сравнению с традиционными деревянными потоками это разумеется супер-гипер, но на светлое будущее (упс, коламбур) не тянет.

А что у нас тянет на светлое будущее?

Забота о независимости вычислений всегда ложится на программиста.

LCR>Да, и это может быть реализовано на монадах.

Ну мало-ли, что может быть реализовано на монадах.

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

L>>Такого примера у меня нет, потому что "сильно упрощает", это, наверное, не то слово. Ленивость позволяет использовать другие идиомы и паттерны при построении программы. Ключевое слово — "другие".

VD>Ну, дык, никто не мешает использовать эти же паттерны. Просто прийдется самому указать, что вот здесь тебе нужна ленивость.

Обратное тоже справедливо, и?

VD>В общем, это сотрясение воздуха и попытка раздуть слона из мухи.

Меня спросили — я ответил. Если ты с чем то не согласен, озвучь это. А то непонятно зачем ты всё это пишешь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Gaperton,

LCR>>Зато за поддержание чистоты в грязном мире заботится компилятор, а не программистские головы и жопы. Ну и специально для тех, кто привык программировать спинным мозгом, можно вывесить плакат с большой надписью "ДЕЛАЙ ТАК". Короче, здесь банальная разница в точках зрения.

G>О поддержании чистоты может позаботится компилятор и в грязном языке, если вы введете модификатор pure (или наоборот — dirty) для функций. В этом случае компилятор проверит и докажет чистоту.

G>Монадный ввод-вывод не сильно будет отличаться по сути — монады точно так же "заражают" код, и выглядит он все равно императивно. В любом случае будет разумно отделить одно от другого, нет? Так в чем реальная разница?

Таак, ты (можно на "ты"?) наступил на ту же самую граблю, искры от удара которой я имел возможность лицезреть здесь. Если немного подумать, то окажется, что

1. грязь бывает очень разная — то есть грязь имеет тип.
2. часто хочется выполнить грязный код внутри чистого — а это значит, что все проверки компилятора накрываются медным тазом.
3. монадические значения — это обычные значения. Их можно сохранять в коллекциях, частично выполнять, передавать в ФВП, (де)сериализовывать и прочее. Их нужно только выполнять в нужном контексте и об этом следит система типов. Что может предложить 'dirty' в качестве ответа?
4. если идти дальше, то модификатор dirty должны иметь не только функции, но типы параметров в таких функциях как map. То есть

map      :: dirty(a -> b) -> [a] -> [b ]
map_pure :: (a -> b) -> [a] -> [b ]

должны рассматриваться как разные функции и тогда каждую функцию нужно реализовывать в 2х экземплярах, а это не может не напрягать. Либо надо обеспечить преобразование чистой функции в грязную (

изобрели лифтинг). Теперь предположим мы проектируем какой-нибудь общий интерфейс — нам придётся повсюду воткнуть туда dirty, мы же не хотим проблем в будущем... И где теперь поддержка компилятора?
5. и как избежать транзитивного замыкания грязи, когда у нас 99.9% функций становятся грязными лишь потому, что мы где-то в глубине немножечко замарались?

Получается, что dirty нужно расширять так, чтобы он стал полноправным типом, и систему типов так, чтобы обеспечить комфорт с манимуляцией такими типами. Ты уже понял, куда мы пришли?

Единственное, что напрягает — это императивный код в Хаскелле выглядит совсем не так, как скажем в Йаве. И это реально беспокоит новичков. Надо было или насахарить побольше, или что-то другое. Но уже в общем-то не нужно.

G>>>Второй минус — слабопредсказуемое поведение программы в плане производительности и расхода памяти.
LCR>>Согласен, и это вычёркивает Хаскелл из целого ряда задач. Но там уже такая толкотня, что прямо скажем, невелика потеря

G>Угу, а что остается?

Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.
Не надо крайностей. Так получилось, что killer-app пока нет. Однако, Хаскелл применяется в целой куче областей и небезуспешно. Думаю что с помощью чистого нестрогого языка будет возможно строить сверхбольшие системы — это может быть killer-app. Может быть это будет Хаскелл, может Clean, а может быть и Хаскелл-2

А _доказать_ здесь всё равно невозможно ничего, сам понимаешь. Так что в определённый момент нам нужно будет просто остановить наше бодание.

G>Семантическая простота

. Вы в состоянии рассчитать асимптотическую сложность и расход памяти для ленивой программы большого объема, особенно если над кодом поработал strictness analyzer?
Возможность чего-то там рассчитать как раз имеет дело с вычислительной простотой. Семантическая простота — это "копать от забора до обеда, а выбор траектории и формы лопат меня не волнует".

Трудности с расчётами возникают очевидно из-за того, что если у нас f имеет сложность O(N), g имеет сложность O(N^2), то композиция (f . g) совсем необязательно будет иметь сложность O(N^3) как в энергичном языке, а может быть всё, что угодно — от O(N^3) до O(1) — зависит от условий на входные данные. И это я считаю очень интересной особенностью нестрогих языков.

В конце концов,

The physical causality works as follows. The brain issues the orders which propagate sequentially through the nerves, make the articulations and the limbs move, and finally the end effector — the hand — grasps the kettle and put in on the fire. Anybody protests?

Время реакции на раздражитель тоже недетерминировано и ничего — живём и даже радуемся. Возвращаясь к расчётам: часто на практике статистических данных достаточно. А отсутствие гарантий — это нормально в том числе и для энергичных языков и достаточно больших систем.

LCR>>Я не знаю, какие техники программирования должен использовать ЯП будущего, но стопудово уверен, что он не должен использовать техники программирования прошлого и не тащить за собой грабли пятидесятилетней давности.

G>Какие конкретно техники и грабли он не должен за собой тащить?

многословность,
отсутствие проверяемого разделения чистого и грязного кода,
слабый клей

LCR>>Интересен, ага. Впрочем, я это уже видел, и мне не нравится, что нужно опять ручками отщипывать потоки — я это расцениваю как шаг назад.

G>А для Хаскеля у нас автоматических распараллеливателей дофига, да?

Кстати, фортрановские и сишные программы уже давно параллелят автоматически — это например интеловские компиляторы умеют.

Ещё раз — я не утверждаю, что Хаскелл — рулез форева. Давай не будем скатываться в пинание конкретного языка, а то и компилятора.

G>С фьючерсами же явное управление параллелизмом упрощено по предела — как и должно быть. И от него (явного) никто никогда никуда не денется — по причине разности в скоростях передачи данных внутри кристалла, на плате, внутри стойки, и внутри сети (что было, и всегда будет). Это вынуждает управлять локальностью (и параллелизмом) явно в том или ином виде (автоматом это из программы в принципе не вытащить), если не хотите быстого деградирования производительности на большом числе узлов.

Хм. А чем обусловлена такая "невытаскиваемость в принципе"? Или ты априори предполагаешь, что переллелизатор не может быть оформлен в виде библиотеки? Или передать туда информацию кроме как исходный код в принципе невозможно?
На всякий случай, может быть ты не видел:
Параллельный OCaml. Вот это шаг в светлое будущее.

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

VD>>Ну, дык, никто не мешает использовать эти же паттерны. Просто прийдется самому указать, что вот здесь тебе нужна ленивость.

L>Обратное тоже справедливо, и?

Несомненно. Это вопрос предпочтений в дизайне языка. И на мой взгляд, если язык разрабатывается для реальной жизни (причем, здесь и сейчас), то надо по умолчанию выбирать "энергичнось", а ленивость делать по запросу. Возможно когда-нибудь, когда оптимизация станет очень качественной и доступной всем, все и изменится. Но это время явно еще не настало.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>1. грязь бывает очень разная — то есть грязь имеет тип.

Это довольно бессмысленная мысль.

LCR>2. часто хочется выполнить грязный код внутри чистого — а это значит, что все проверки компилятора накрываются медным тазом.

Ничего. Лично мне бы хватило бы возможности сказать компилятору, что за отсуствие побочных эффектов в этом "грязном фрагменте" несу я лично, и чтобы он не смущался по этому поводу.

LCR>3. монадические значения — это обычные значения. Их можно сохранять в коллекциях, частично выполнять, передавать в ФВП, (де)сериализовывать и прочее. Их нужно только выполнять в нужном контексте и об этом следит система типов. Что может предложить 'dirty' в качестве ответа?

1. Отсуствие монодического булшита.
2. Простоту модели и реализации.
3. Эффективность исполнения (порождение эффективного кода).

LCR>4. если идти дальше, то модификатор dirty должны иметь не только функции, но типы параметров в таких функциях как map.

Это продолжение монодического, точнее пуританского, образа мысли. На практике никаких таких проблем нет. Достаточно создать некие фунции воде MapLazy и все бдет ОК.

LCR>5. и как избежать транзитивного замыкания грязи, когда у нас 99.9% функций становятся грязными лишь потому, что мы где-то в глубине немножечко замарались?

Не надо этого избегать. Пусть в коде помеченном как чистый все контролирует компилятор, а в непомеченном программист. Этого более чем достаточно для написания хороших, и что не маловажно, быстрых программ.

LCR>Получается, что dirty нужно расширять так, чтобы он стал полноправным типом, и систему типов так, чтобы обеспечить комфорт с манимуляцией такими типами. Ты уже понял, куда мы пришли?

Этлучается у тех кому абстракные рассуждения давно затмили разум.
Практика же давно доказала, что все это не более чем пустопорожний тереп.
Я не всегда согласен с Гапертоном (мягко говоря), но тут я целиком и полностью не его стороне.
Тот же Intel C++ давно доказал, что параллелить можно даже до мозга костей импереативый С++. Совершенно плевые подсказки компилятору позволяют сделать программу параллельной и получать реальный выигрышь от наличия несколькоих процессоров. Компьюет же еще очень долго не смоежет распараллеиливать вычисления сам, так как он не всилах предугадать, какие участки имеет смысл параллелить, а какие нет. Фактически для таких вещей нужен искуственный интелект. Ну, или по крайней мере очень сложные системы которые просто не позубам любителям.
Так что введение в язык простых декларативных средств позволяющих подксказать компилятору что и как надо параллелить на мой взгляд лучшее решение на сегодня. И пометки кода "как чистого" вполне достаточно для облегчения жизни компилятора.

LCR>Единственное, что напрягает — это императивный код в Хаскелле выглядит совсем не так, как скажем в Йаве. И это реально беспокоит новичков. Надо было или насахарить побольше, или что-то другое. Но уже в общем-то не нужно.

Ты сильно оторвался от реальности. Новичков у Хаскеля практически нет. И веной тому как раз тот пуританский подход его авторов. Язык при всех его достоинствах в итоге больше похож на метод шифрования, а не на язык на котором легко и удобно писать прикладные программы для реальных нужд.

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

Лично я когда пытался читать что-то по Хаскелю лико хпроходил первые разделы, но мой мозг откровенно отключался на разделах из вотрой половины (где как раз и начинался весь этот монойдный булшит). И ведь я далеко не самый тупой. Средний императивный программист скорее всего отрубится еще раньше.

G>>Угу, а что остается?

Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.
LCR>Не надо крайностей.

Где ты увидел крайности? Гапертон прав. Фанаты Хаскеля обычно замечательно чувствуют себя в теоретических спорах, но полностью пасуют когда их просят продемонстрировать крутость на практике.

И все потмоу, что умолчальная ленивость не дает какого-то поразительного эффекта в рельном примененеии (в других языках ведь тоже есть сресдва "линивизации" вычислений). А по остальным параметрам Хаскель в бщем-то конкурирует на равных со многими современными языками хорошо поддерживающими ФП. Так что выигрывает он только у пресловутых чистых ИЯ. И то если дело не доходит до чистого (или грязного, как будет угодно) императивного программировния, где Хаскель становится похож на урода.

LCR> Так получилось, что killer-app пока нет.

Да не нужно какого-то "killer-app" просто покажите этот супер-выигрыш на практике. И не в дурных никому не нужных примерах из области показной математики, а что-то более практичное.
А если таких примеров нет, то давайте признаем, что Хаскель позволят писать приблизительно так же как и на других ФЯ.

LCR> Однако, Хаскелл применяется в целой куче областей и небезуспешно.

И что это доказывает? Ассемблер наверно тоже где-то применяется и точно не без успешно.

LCR> Думаю что с помощью чистого нестрогого языка будет возможно строить сверхбольшие системы — это может быть killer-app. Может быть это будет Хаскелл, может Clean, а может быть и Хаскелл-2

Большие системы уже много лет создают на С++, Яве и C#-е, то есть на в доску императивных ООЯ. Ведь главное для больших систем это возможность выделения абстракций и модульность. Так что это вообще не разговор. Монады Хаскеля вряд ли что-то тут решат.

ФП интересен не тем что позволит решать более слоные задачи. А тем что позволит сделать многие решения более простыми для понимания. То есть он позволит упростить реализацию абстракций. Посуму лично я вижу огромную перспективу в соеденении ООЯ и ФЯ.

Но мы то тут обсуждали совсем другое. Мы обсуждали дизайнерский выбор языкостроителей — "Делать ли по умолчанию язык ленивым или сделать ленивость опциональной возможностью?". Заметь, никто не спорит о том, что ленивость иногда очень полезна! И никто не спорит, что было бы приятно иметь в языке программирования возможность делать некоторые вычисления ленивыми. Чем проще это будет, тем лучше. Мы говорим о другом... Ести ли насущьная необходимость делать ленивым (да и чисто фукнциональнм) все подряд? И нужно ли ради того чтобы сделать что-то не линивым или не чистым изобретать малопонятные абстрации вроде монад?

Лично я на оба вопроса отвечаю однозначно — нет. Потому как все должно быть просто, очень простно, но не проще чем того требует задача (с).

LCR>А _доказать_ здесь всё равно невозможно ничего, сам понимаешь. Так что в определённый момент нам нужно будет просто остановить наше бодание.

Дык доказывать тут просто невозможно. Оба подхода — это дизайнерские решения. Оба они будут работать. Так что пытаться доказать, что "пометка кода как чистого или ленивого — это глпость" — это само по себе глупо. Так же как глупо доказывать обртное. Но вот необходимости выбора это не устраняет. Мне кажется "чистые" решения Хаскеля не приспособлены для реальной жизни. Возможно когд-нибудь все поменяется. Но жить нужно сейчас. И выбор нужно делать сейчас.
Ведь по сей день львиная доля софта пишется на языках дизайн которых устарлен еще 10 лет тому назад.
Почитай "Дизайн и эволющию С++". Это же рассказ о том как принимались плохие решения и чем они были обоснованы. И ведь все эти плохие решения в итоге создали ЯП который доминирует в мире последние 13 лет! Если бы в С++ в те времена было принято хотя бы одно решение в стиле монад, то язык с треском бы провалился. Сегодня не те веремена, но подобные решения все равно практически не приемлемы. Принимая их ты обрекаешь свой язык быть вечным эксперементом.

LCR>>>Я не знаю, какие техники программирования должен использовать ЯП будущего, но стопудово уверен, что он не должен использовать техники программирования прошлого и не тащить за собой грабли пятидесятилетней давности.

G>>Какие конкретно техники и грабли он не должен за собой тащить?

LCR>многословность,
LCR>отсутствие проверяемого разделения чистого и грязного кода,
LCR>слабый клей

Ага, точно! И если нам вдруг в библиотеке нужно создать эффективную сортировку массива, то мы обосремся, но не позволим тупо написать QuickSort в императивном сител. Отличное решение! Очень в духе пуританства.

G>>А для Хаскеля у нас автоматических распараллеливателей дофига, да?

Кстати, фортрановские и сишные программы уже давно параллелят автоматически — это например интеловские компиляторы умеют.

LCR>Ещё раз — я не утверждаю, что Хаскелл — рулез форева. Давай не будем скатываться в пинание конкретного языка, а то и компилятора.

Дык тебе просто продемонстрировали неверность твоего утвреждения о том, что без "чистоты" невозможно параллелить программы.

G>>С фьючерсами же явное управление параллелизмом упрощено по предела — как и должно быть. И от него (явного) никто никогда никуда не денется — по причине разности в скоростях передачи данных внутри кристалла, на плате, внутри стойки, и внутри сети (что было, и всегда будет). Это вынуждает управлять локальностью (и параллелизмом) явно в том или ином виде (автоматом это из программы в принципе не вытащить), если не хотите быстого деградирования производительности на большом числе узлов.

LCR>Хм. А чем обусловлена такая "невытаскиваемость в принципе"?

Тем что компилятор мозгов не имеет. Он может распараллелить то что параллелится и получить проигрышь, так как на разделение управления и синхронизацию тоже нужно время. И может не суметь распараллелить ту часть программы которая дала бы нибольший эффект. Ведь только программист знает об объемах данных которые будут обрабатываться в тех или иных фунциях. И только он знает какая часть кода действительно трбеует распарллеливания. Конечно в будущем люди обязательно попытаются автоматизировать этот прцесс (с помощью профайлинга и т.п.), но задача это очень не простая.
Да и какая разница? Ведь параллелить можно не только чистый и ленивый код. Чистота и ленивость возоможно облегчают задачу, но они не являются обязательными для ее решения.

LCR> Или ты априори предполагаешь, что переллелизатор не может быть оформлен в виде библиотеки? Или передать туда информацию кроме как исходный код в принципе невозможно?
LCR>На всякий случай, может быть ты не видел:
LCR>Параллельный OCaml. Вот это шаг в светлое будущее.

Читаем первый же коментарий к этому сообщению:

С их сайта ссылка на более подробную статью о сути дела здесь. Я так понял (пробежавшись краем глаза), что скелетоны — это паттерны для параллельного программирования, не особо oCamlоспецифичные. Так что, вроде, можно и в N. Было бы желание

К тому же заметь. ОКамл это не ленивый, не чистый ЯП. Так что ты привел замечательный пример того что чистота и ленивость по умолчанию не являются обязательными для эффективного распараллеливания.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Несомненно. Это вопрос предпочтений в дизайне языка. И на мой взгляд, если язык разрабатывается для реальной жизни (причем, здесь и сейчас), то надо по умолчанию выбирать "энергичнось", а ленивость делать по запросу.

Вполне возможно. Скорее всего, в большинстве случаев именно так. Только ты за своей категоричностью совершенно забываешь, что "реальные жизни" они разные даже у одного человека.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Вполне возможно. Скорее всего, в большинстве случаев именно так. Только ты за своей категоричностью совершенно забываешь, что "реальные жизни" они разные даже у одного человека.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>>О поддержании чистоты может позаботится компилятор и в грязном языке, если вы введете модификатор pure (или наоборот — dirty) для функций. В этом случае компилятор проверит и докажет чистоту.

G>>Монадный ввод-вывод не сильно будет отличаться по сути — монады точно так же "заражают" код, и выглядит он все равно императивно. В любом случае будет разумно отделить одно от другого, нет? Так в чем реальная разница?

LCR>Таак, ты (можно на "ты"?) наступил на ту же самую граблю, искры от удара которой я имел возможность лицезреть здесь. Если немного подумать, то окажется, что

LCR>1. грязь бывает очень разная — то есть грязь имеет тип.
?! В самом деле, сэр? ("И прекратите говорить мне "в самом деле", Дживс. Каждый раз мне слышится вместо этого, "обалдели, сэр?"" — из рассказов про Дживса) Пример, плз.

LCR>2. часто хочется выполнить грязный код внутри чистого — а это значит, что все проверки компилятора накрываются медным тазом.
Разумеется, нет. Это всего-навсего означает, что компилятор даст тебе по рукам, если ты весь код не пометишь как грязный. Попробуй в Хаскеле вставить логгирование куда-нибудь вниз гражданского кода — огребешь тоже самое в точности. Или будешь вынужден протащить параметр наверх, или расставишь везде свой монадный dirty. Нет?

LCR>3. монадические значения — это обычные значения. Их можно сохранять в коллекциях, частично выполнять, передавать в ФВП, (де)сериализовывать и прочее. Их нужно только выполнять в нужном контексте и об этом следит система типов. Что может предложить 'dirty' в качестве ответа?

Ужос. Dirty (и строгий язык) может предложить в качестве ответа простой и интуитивно понятный интерфейс с внешним миром — COM и CORBA интерфейсами, файлами, сокетами, библиотеками, а также нормальные эксцепшены, которых в хаскеле нету, и приходится протаскивать ошибку наверх. И не надо мне говорить, что их можно через монады сделать

.

LCR>4. если идти дальше, то модификатор dirty должны иметь не только функции, но типы параметров в таких функциях как map. То есть
LCR>

LCR>map      :: dirty(a -> b) -> [a] -> [b ]
LCR>map_pure :: (a -> b) -> [a] -> [b ]
LCR>

LCR>должны рассматриваться как разные функции и тогда каждую функцию нужно реализовывать в 2х экземплярах, а это не может не напрягать.

Ты абсолютно прав. Можно, кстати, шибко далеко не идти, и сразу заглянуть, как это сделано в... С++.

Делаем dirty частью сигнатуры (как const), разрешаем описывать generic-функции без указания модификатора.

LCR>Либо надо обеспечить преобразование чистой функции в грязную (

изобрели лифтинг). Теперь предположим мы проектируем какой-нибудь общий интерфейс — нам придётся повсюду воткнуть туда dirty, мы же не хотим проблем в будущем... И где теперь поддержка компилятора?

Разумеется, нет. Процесс проектирования в грязном языке несколько другой, не так все плоско. На крупном уровне декомпозиции делают "грязные" классы — это удобно. Логика которых внутри описываются чисто. Пример языка, где сделано так — Эрланг. Таким же образом разумно проектировать и в OCaml c Nemerle. Я как-то об этом уже писал.

LCR>5. и как избежать транзитивного замыкания грязи, когда у нас 99.9% функций становятся грязными лишь потому, что мы где-то в глубине немножечко замарались?
Вспомни mutable. Очень, очень хорошо помогает, например, для генераторов случайных чисел, которые по сути чистые, а технически — грязные.
А вообще — проблема решается не так. См выше.

LCR>Получается, что dirty нужно расширять так, чтобы он стал полноправным типом, и систему типов так, чтобы обеспечить комфорт с манимуляцией такими типами. Ты уже понял, куда мы пришли?

Не типом, а модификатором типа. Да, система типов усложнится. Если у тебя строгая статическая типизация, конечно

.

G>>Угу, а что остается?

Назовите полезные, не академические задачи, где Хаскель рвет всех. А то на пустом множестве, сами понимаете, доказать можно все что угодно — на нем верно все.
LCR>Не надо крайностей. Так получилось, что killer-app пока нет. Однако, Хаскелл применяется в целой куче областей и небезуспешно. Думаю что с помощью чистого нестрогого языка будет возможно строить сверхбольшие системы — это может быть killer-app. Может быть это будет Хаскелл, может Clean, а может быть и Хаскелл-2

Сверхбольшие?

Вот это — сильно вряд-ли. Практика применения Хаскела у нас показывает, что у него все очень херово с maintainability — практически как у злого С++. Если code standard не ввести — то в программе уже среднего размера черт ногу сломит. Что будет на больших системах — подумать страшно. Это раз.

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

Для сверхбольшой системы простота доказательства свойств программ, таких как расход памяти и быстродействие и время отклика (с чем у Хаскеля отвратительно), приобретает огромное значение. Так что — уж чего-чего, а это киллер апом не станет никогда.

LCR>А _доказать_ здесь всё равно невозможно ничего, сам понимаешь. Так что в определённый момент нам нужно будет просто остановить наше бодание.

Можно обосновать.

G>>Семантическая простота

. Вы в состоянии рассчитать асимптотическую сложность и расход памяти для ленивой программы большого объема, особенно если над кодом поработал strictness analyzer?
LCR>Возможность чего-то там рассчитать как раз имеет дело с вычислительной простотой. Семантическая простота — это "копать от забора до обеда, а выбор траектории и формы лопат меня не волнует".

Семантическая простота (как мне кажется из моего опыта maintenance — это когда человеку понять проще), мне думается, связана с indirection level применяемых конструкций. Вот, у монад с indirection level все плохо, как и у макросов. То же самое касается комбинаторного стиля, столь любимого Хаскелистами. Хрен разберешь без бутылки.

LCR>Трудности с расчётами возникают очевидно из-за того, что если у нас f имеет сложность O(N), g имеет сложность O(N^2), то композиция (f . g) совсем необязательно будет иметь сложность O(N^3) как в энергичном языке, а может быть всё, что угодно — от O(N^3) до O(1) — зависит от условий на входные данные. И это я считаю очень интересной особенностью нестрогих языков.

Особенность безусловно интересная с теоретической точки зрения, меня она тоже приводит в восторг. Но проектировать и отлаживать из-за этой возможности на практике очень тяжело. Лучше застрелится сразу, чтобы не мучатся. Особенно, на сверхбольшой системе.

LCR>В конце концов,
LCR>

LCR>The physical causality works as follows. The brain issues the orders which propagate sequentially through the nerves, make the articulations and the limbs move, and finally the end effector — the hand — grasps the kettle and put in on the fire. Anybody protests?

LCR>Время реакции на раздражитель тоже недетерминировано и ничего — живём и даже радуемся. Возвращаясь к расчётам: часто на практике статистических данных достаточно. А отсутствие гарантий — это нормально в том числе и для энергичных языков и достаточно больших систем.

"Оставьте лирику нашим партийным бонзам. Мы, сыщики, должны выражаться конкретно — существительными и глаголами. Он пришел, она сказала" (Мюллер, Семнадцать Мгновений Весны). Это я о физической казуальности.

Что будет происходить на практике — сие науке не известно, за отсутствием широкой практики. Результаты нашего evaluation Хаскеля показывают следующее:
1) Хаскель — довольно быстрый язык.
2) Чужой код на хаскеле очень трудно понимать — требуется жестко ограничить выразительные средства и стиль кодирования code standard-ом.
3) Отладчика нет, и это плохо.
4) Просто никакая обработка ошибок — реальную систему с логгированием и "промышленными" реакциями на ошибки хрен напишешь — вот это реально showstopper.
5) Интероп делается через задний проход. Это тоже почти приговор.
6) Ленивость надо давить, проставляя строгость руками. Иначе будет плохо очень. Например — ленивость может давать мемори лики (накапливается где-то невычисленая цепочка по редкой ветке, отжирая память). Это отдельный этап отладки, отсутствующий в нормальных языках.
7) Отдельные вопросы вызывает тестирование ленивых программ — это что ж такое надо сделать, чтобы обеспечить 100%-е тестовое покрытие, а? А мерять его как? Здесь, может, и все ок, но что-то не верится.

LCR>>>Я не знаю, какие техники программирования должен использовать ЯП будущего, но стопудово уверен, что он не должен использовать техники программирования прошлого и не тащить за собой грабли пятидесятилетней давности.

G>>Какие конкретно техники и грабли он не должен за собой тащить?

LCR>многословность,
LCR>отсутствие проверяемого разделения чистого и грязного кода,
это даже в С++ есть. const + mutable
LCR>слабый клей
Это не предполагает чистоты, не так ли?

G>>А для Хаскеля у нас автоматических распараллеливателей дофига, да?

Читату из "мгновений" я уже приводил

G>>С фьючерсами же явное управление параллелизмом упрощено по предела — как и должно быть. И от него (явного) никто никогда никуда не денется — по причине разности в скоростях передачи данных внутри кристалла, на плате, внутри стойки, и внутри сети (что было, и всегда будет). Это вынуждает управлять локальностью (и параллелизмом) явно в том или ином виде (автоматом это из программы в принципе не вытащить), если не хотите быстого деградирования производительности на большом числе узлов.

LCR>Хм. А чем обусловлена такая "невытаскиваемость в принципе"? Или ты априори предполагаешь, что переллелизатор не может быть оформлен в виде библиотеки? Или передать туда информацию кроме как исходный код в принципе невозможно?

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

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

LCR>2. часто хочется выполнить грязный код внутри чистого

А зачем это делать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

AndreiF,

LCR>>2. часто хочется выполнить грязный код внутри чистого

AF>А зачем это делать?

Матрички умножить или в лог вывести.

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

G>Ужос. Dirty (и строгий язык) может предложить в качестве ответа простой и интуитивно понятный интерфейс с внешним миром — COM и CORBA интерфейсами, файлами, сокетами, библиотеками, а также нормальные эксцепшены, которых в хаскеле нету, и приходится протаскивать ошибку наверх. И не надо мне говорить, что их можно через монады сделать

.

Вы не моглы бы уточнить в 2 словах, что такое "нормальные эксцепшены" и "протаскивать ошибку наверх"?

G>Ты абсолютно прав. Можно, кстати, шибко далеко не идти, и сразу заглянуть, как это сделано в... С++.

Делаем dirty частью сигнатуры (как const), разрешаем описывать generic-функции без указания модификатора.

А зачем этот детский лепет??? Что не так с IO???
В монадах нет совершенно никакой мистики. С точки зрения ЯЗЫКА они ВООБЩЕ НИКАК не отличаются от любых других классов типов, кроме 2 вещей:
1. Специального do-синтаксиса. То, что он есть, ОЧЕНЬ хорошо и важно, но он не является необходимым
2. Наличия выделенной монады IO для "внешнего мира"
Система типов Хаскелла + монада IO просто тривиально мощнее чем эти *НЕ ПОНЯТНО ЗАЧЕМ НУЖНЫЕ* предложения.
FFI Хаскелла вообще великолепен — считается одним из лучших (если не лучшим) для языков такого высокого уровня. Какие проблемы, например, с COM? Я, например, легко сделал свою библиотеку для работы с COM таким образом, что там все работает абсолютно прозрачно, то есть буквально как в VB — все нужные преобразования делаются в compile-time.

LCR>>5. и как избежать транзитивного замыкания грязи, когда у нас 99.9% функций становятся грязными лишь потому, что мы где-то в глубине немножечко замарались?
G>Вспомни mutable. Очень, очень хорошо помогает, например, для генераторов случайных чисел, которые по сути чистые, а технически — грязные.

*ЛЮБЫЕ* "по сути чистые, а технически — грязные" вещи в Хаскелле можно с помощью unsafePerformIO. Зачем что-то выдумывать?

Проблем с чистотой/грязью в сегодняшнем Хаскелле просто НЕТ.

G>У хаскеля все не очень гут со взаимодействием с внешним миром
У хаскеля все распрекрасно со взаимодействием с внешним миром.

G>Что будет происходить на практике — сие науке не известно, за отсутствием широкой практики. Результаты нашего evaluation Хаскеля показывают следующее:
G>1) Хаскель — довольно быстрый язык.
G>2) Чужой код на хаскеле очень трудно понимать — требуется жестко ограничить выразительные средства и стиль кодирования code standard-ом.
G>3) Отладчика нет, и это плохо.
G>4) Просто никакая обработка ошибок — реальную систему с логгированием и "промышленными" реакциями на ошибки хрен напишешь — вот это реально showstopper.
G>5) Интероп делается через задний проход. Это тоже почти приговор.
G>6) Ленивость надо давить, проставляя строгость руками. Иначе будет плохо очень. Например — ленивость может давать мемори лики (накапливается где-то невычисленая цепочка по редкой ветке, отжирая память). Это отдельный этап отладки, отсутствующий в нормальных языках.
G>7) Отдельные вопросы вызывает тестирование ленивых программ — это что ж такое надо сделать, чтобы обеспечить 100%-е тестовое покрытие, а? А мерять его как? Здесь, может, и все ок, но что-то не верится.

В принципе, не вызывает возражений кроме:
4. так и не понял в чем проблема
5. уже писал про FFI, среди высокоуровневых языков считается фактически лучшим, какого рожна еще нужно?
3. отладчик будет (уже есть в CVS HEAD)

Но пусть оно даже так, ВЫВОДЫ-то каковы? Вы чего хотели на Хаскелле сделать? Вместо чего его использовать?

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

LCR>Матрички умножить или в лог вывести.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

AndreiF,

LCR>>Матрички умножить или в лог вывести.

AF>Умножение матриц — это разве грязная операция? На вход подаем два значения, на выходе получаем третье, значение функции зависит только от аргументов, при каждом вызове результат один и тот же.

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

AF>А вывод в лог — он хотя и создает побочные эффекты, но по своей сути это чистая операция, т.к. его побочные эффекты не оказывают влияния на результат работы программы. Если подходить к задаче практически, то проще всего считать вывод в лог "чистой" функцией.

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

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

G>>Что будет происходить на практике — сие науке не известно, за отсутствием широкой практики. Результаты нашего evaluation Хаскеля показывают следующее:
G>>1) Хаскель — довольно быстрый язык.
G>>2) Чужой код на хаскеле очень трудно понимать — требуется жестко ограничить выразительные средства и стиль кодирования code standard-ом.
G>>3) Отладчика нет, и это плохо.
G>>4) Просто никакая обработка ошибок — реальную систему с логгированием и "промышленными" реакциями на ошибки хрен напишешь — вот это реально showstopper.
G>>5) Интероп делается через задний проход. Это тоже почти приговор.
G>>6) Ленивость надо давить, проставляя строгость руками. Иначе будет плохо очень. Например — ленивость может давать мемори лики (накапливается где-то невычисленая цепочка по редкой ветке, отжирая память). Это отдельный этап отладки, отсутствующий в нормальных языках.
G>>7) Отдельные вопросы вызывает тестирование ленивых программ — это что ж такое надо сделать, чтобы обеспечить 100%-е тестовое покрытие, а? А мерять его как? Здесь, может, и все ок, но что-то не верится.

А>В принципе, не вызывает возражений кроме:
А>4. так и не понял в чем проблема
А>5. уже писал про FFI, среди высокоуровневых языков считается фактически лучшим, какого рожна еще нужно?
А>3. отладчик будет (уже есть в CVS HEAD)

А>Но пусть оно даже так, ВЫВОДЫ-то каковы? Вы чего хотели на Хаскелле сделать? Вместо чего его использовать?

Мы обсуждали ленивость/строгость по умолчанию. Мои выводы — язык должен быть строгим по умолчанию, с честными побочными эффектами и вводом-выводом без монад.

Gaperton,

G>>>О поддержании чистоты может позаботится компилятор и в грязном языке, если вы введете модификатор pure (или наоборот — dirty) для функций. В этом случае компилятор проверит и докажет чистоту.

LCR>>1. грязь бывает очень разная — то есть грязь имеет тип.
G>?! В самом деле, сэр? ("И прекратите говорить мне "в самом деле", Дживс. Каждый раз мне слышится вместо этого, "обалдели, сэр?"" — из рассказов про Дживса) Пример, плз.
Да, сэр, абсолютно серьёзно! Если гадим в stdio — это один тип, гхм... извините, грязи, если используем императивный доступ к массивам — это другой, используем FFI — это третий, рисуем окошечки — это четвёртый. Можно даже дальше пойти, и захотеть чтобы операции над разными файлами тоже разруливались компилятором, если этого очень хочется. Вот, вкратце такие примеры-с.

G>Попробуй в Хаскеле вставить логгирование куда-нибудь вниз гражданского кода — огребешь тоже самое в точности. Или будешь вынужден протащить параметр наверх, или расставишь везде свой монадный dirty. Нет?
И да, и нет. Есть ещё liftM и monad transformers, которые сделают преобразования обычных или монадических функций в монадические. Также есть unsafePerformIO, но это уже когда одолевает бессилие

G>Можно, кстати, шибко далеко не идти, и сразу заглянуть, как это сделано в... С++.

Делаем dirty частью сигнатуры (как const), разрешаем описывать generic-функции без указания модификатора.
Способ, которым это сделано в C++ вызывает лёгкое головокружение.

И всё-таки. Не мог бы ты, глубокоуважаемый Джин, ответить мне на маненький вопрос:

-- Функция map - она чистая или грязная?
map :: (a -> b) -> [ a ] -> [ b ]

Возможно у тебя есть небанальный ответ, а вот мой ответ мне же самому прост как дверь — зависит от типа функции переданной в качестве параметра. Значит "грязнота" должна разруливаться на уровне типов. Развивая мысль далее в этом духе, я прихожу к мысли, что твой dirty будет или синонимом звёздочки в Clean, или монадой в Haskell, или он вообще не будет проверяться в compile-time, как в Эрланге, Окамле, Скале и прочих заслуживающих внимание языках, потому что их системы типов не рассчитаны на такую проверку (т.е. недостаточно мощны). Я не прав?

G>Процесс проектирования в грязном языке несколько другой, не так все плоско. На крупном уровне декомпозиции делают "грязные" классы — это удобно. Логика которых внутри описываются чисто. Пример языка, где сделано так — Эрланг. Таким же образом разумно проектировать и в OCaml c Nemerle. Я как-то об этом уже писал.

Я совершенно согласен, это хороший подход к. Но коли уж мы хотим проверяемости компилятором, я осмелюсь повторить, что мы столкнёмся с 99% грязных функций, то есть по сути проверять окажется нечего. Коли уж ты упомянул Эрланг, позволь мне процитировать Джо:

Notice that I have chosen a particularly simple definition of “dirty.” At first sight it might appear that it would be better to recursively define a module as being dirty if any function in the module calls a “dangerous” BIF or a dirty function in another module. Unfortunately with such a definition virtually every module in the system would be classified as dirty.

И та же самая фигня с функциями. Ниже он определяет грязную функцию, как

A function will be considered dirty if a single call is made to unclean BIF.

что разумеется некорректно, если мы заботимся о проверке "грязноты" компилятором.

G>Сверхбольшие? ... Результаты нашего evaluation Хаскеля показывают следующее...

Хм, огромное спасибо. Мне очень интересно почитать о чужом негативном опыте. "И пепел твоих поражений станет залогом будущих побед". Не так давно была ссылка на ещё один неудачный опыт применения Haskell, там человек попробовал писать на Хаскелле "как на Йаве", и много жаловался на монады.
Вывод: возлюби монады если хочешь обуздать Хаскелл.

G>Семантическая простота (как мне кажется из моего опыта maintenance — это когда человеку понять проще), мне думается, связана с indirection level применяемых конструкций. Вот, у монад с indirection level все плохо, как и у макросов. То же самое касается комбинаторного стиля, столь любимого Хаскелистами. Хрен разберешь без бутылки.
Судя по приведённым примерам, а также по критике макросов тут твой indirection level — это просто удалённая избыточная информация такая, что трактовка оставшегося куска по прежнему остаётся однозначной.
Получается, что любой подъём по абстрактной лесенке от низкоуровневых до высокоуровневых абстракций увеличивает этот самый indirection level, независимо от того, как мы подымаемся — новыми функциями, макросами, монадами или абстрактными типами. Почему тогда монады и комбинаторы стоят так особняком?
(Я обещаю дальше не развивать этот оффтоп, но мне интересно, что ты ответишь).

G>Особенность безусловно интересная с теоретической точки зрения, меня она тоже приводит в восторг. Но проектировать и отлаживать из-за этой возможности на практике очень тяжело. Лучше застрелится сразу, чтобы не мучатся. Особенно, на сверхбольшой системе.
А как насчёт возможности комбинировать функции и компоненты без abstraction penalty?

LCR>>Хм. А чем обусловлена такая "невытаскиваемость в принципе"? Или ты априори предполагаешь, что переллелизатор не может быть оформлен в виде библиотеки? Или передать туда информацию кроме как исходный код в принципе невозможно?
G>Информацию о параллелизме ты вытащишь, это не фокус. Ты не вытащишь информацию о локальности вычислений в программе и о потоках данных — она в статике не получается. Из-за этого и происходит просадка в производительности при увеличении узлов — причина в плохом управлении локальностью вычислений.
Я о том, чтобы не оставлять компилятор бороться в одиночку а помочь ему декларативными директивами типа "все эти функции должны выполняться в контекстах потоков внутри платы, а вот эти — внутри стойки, эти можно внутри кластера"... (впрочем это тоже оффтоп).

От:	VladD2	www.nemerle.org
Дата:	22.02.07 23:03
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	23.02.07 12:36
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	24.02.07 11:46
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	24.02.07 13:28
Оценка:	10 (2) +1

От:	VladD2	www.nemerle.org
Дата:	24.02.07 23:16
Оценка:

	От:	AndreiF
	Дата:	26.02.07 10:46
	Оценка:

	От:	Аноним
	Дата:	26.02.07 12:06
	Оценка:

	От:	AndreiF
	Дата:	26.02.07 13:30
	Оценка:

	От:	Аноним
	Дата:	26.02.07 15:27
	Оценка: