Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из:
haskel
ocaml
erlang
?
Готов тратить некоторые усилия и писать библиотеки, которых недостает.
На данный момент импонирует haskel
Нравится еще что по результатам тестов haskel близок по производительности к C/C++ и опережает большинство других языков:
Здравствуйте, maq, Вы писали:
maq>Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из: maq>haskel maq>ocaml
Я бы не стал доверять этим тестам, во первых ресурс хоть сейчас и исправляется, но знаменит не качественностью.
Во вторых надо различать тесты и реальные приложения. Например у того же Хаскеля для реальных приложений есть очень большой недостаток непредсказуемые тормоза из-за ленивости. Кроме того на Хаскеле в отличии от Эрланга, Окамла и Лиспов практически нет достаточно объемного промышленного кода.
maq>Кстати на форуме и вообще встречал утверждения о медленном haskel, как-то результаты тестов показывают обратное.
Здравствуйте, maq, Вы писали:
maq>Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из: maq>haskel maq>ocaml maq>erlang maq>?
Для Scala есть интересный фреймфорк Lift (как мимнимум seaside сессии заслуживают внимания).
Преподносится, как все новое, что появилось в веб разработке за последние годы.
Здравствуйте, maq, Вы писали:
maq>Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из: maq>haskel maq>ocaml maq>erlang maq>?
В последнее время наметилась (думаю, вполне оправданная) тенденция писать клиент-серверные веб-приложения с Javascript RIA клиентом и что-там-нравится на сервере.
Я сейчас (по наводке коммерческих разработчиков) ковыряю qooxdoo RIA библиотеку. Она — ООП.
На сервере для её поддержки можно использовать любой язык с поддержкой HTTP запросов-ответов, JSON парсером и интерфейсом к Вашей любимой базе данных.
maq> Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из: maq> haskel maq> ocaml maq> erlang maq> ?
Любой, какой понравится
maq> Готов тратить некоторые усилия и писать библиотеки, которых недостает. maq> На данный момент импонирует haskel maq> Нравится еще что по результатам тестов haskel близок по производительности к C/C++ и опережает большинство других языков:
Wikipedia, Flickr — PHP
Youtube — Python
Myspace — сначала Coldfusion, сейчас C#
Какой из этих языков близок по производительности к С/С++?
Здравствуйте, Аноним, Вы писали: MC>>Scheme, если быть точным. А>Почему?
Ну кроме достоинств самой scheme, которые, полагаю, вне топика — у plt довольно годный веб-фреймворк с определеной историей практического применения. Для plt еще есть leftparen, для chicken — spiffy&Ко.
Здравствуйте, Mamut, Вы писали: M>Wikipedia, Flickr — PHP M>Youtube — Python M>Myspace — сначала Coldfusion, сейчас C# M>Какой из этих языков близок по производительности к С/С++?
C#?
M>Wikipedia, Flickr — PHP M>Youtube — Python M>Myspace — сначала Coldfusion, сейчас C#
M>Какой из этих языков близок по производительности к С/С++?
C# близок. Помимо этого, обычно на таких проектах пишут некоторые части на C/C++, так как PHP (или кто там еще) не справляются. Хочется этого избежать.
Здравствуйте, maq, Вы писали:
maq>Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из: maq>haskel maq>ocaml maq>erlang maq>?
есть опыт использования erlang (библиотека yaws) для написания веб страниц — админки для игрового сервера, написанного на эрланге. для этой цели очень хорошо подходит. для erlang также есть хитрые mvc фреймворки, но пока в них не было необходимости. если бы писал веб проект не привязанный к игровому серверу, то выбрал бы хаскель.
PM>Настоящие функциональщики, маргиналы и социопаты, выбирают: PM>* Links — детище аспирантов Филипа Вадлера. PM>* Ur — язык для веба с зависимыми типами.
Здравствуйте, maq, Вы писали:
maq>Хочу использовать один из функциональных языков для разработки веб проекта. Пока стремление исключительно для саморазвития, но кто его знает чем закончится. Что посоветуете из:
Посоветую смотреть на SISCweb. First class continuations (отсутствующие в вышеперечисленных языках) для веба — самое то.
Здравствуйте, lant, Вы писали:
L>есть опыт использования erlang (библиотека yaws) для написания веб страниц — админки для игрового сервера, написанного на эрланге. для этой цели очень хорошо подходит. для erlang также есть хитрые mvc фреймворки, но пока в них не было необходимости. если бы писал веб проект не привязанный к игровому серверу, то выбрал бы хаскель.
А какие проблемы с хаскелем для игрового сервера? Или там уже было все на эрланге?
FR>Во вторых надо различать тесты и реальные приложения. Например у того же Хаскеля для реальных приложений есть очень большой недостаток непредсказуемые тормоза из-за ленивости.
"Уж сколько раз твердили миру!"
К тому моменту, как программа на неленивом языке хоть как-то начнёт работать, в программу на Хаскеле уже будут внесены все аннотации строгости.
FR>Кроме того на Хаскеле в отличии от Эрланга, Окамла и Лиспов практически нет достаточно объемного промышленного кода.
Да что ты говоришь!
maq>>Кстати на форуме и вообще встречал утверждения о медленном haskel, как-то результаты тестов показывают обратное.
FR>По моему здесь наоборот только говорят
Это если читать вполне определённым способом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>К тому моменту, как программа на неленивом языке хоть как-то начнёт работать, в программу на Хаскеле уже будут внесены все аннотации строгости.
Не будут, нормальный вариант для Хаскелитстов сделать прототип и забить
FR>>Кроме того на Хаскеле в отличии от Эрланга, Окамла и Лиспов практически нет достаточно объемного промышленного кода.
T>Да что ты говоришь!
Правду!
FR>>По моему здесь наоборот только говорят
T>Это если читать вполне определённым способом.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>К тому моменту, как программа на неленивом языке хоть как-то начнёт работать, в программу на Хаскеле уже будут внесены все аннотации строгости.
FR>Не будут, нормальный вариант для Хаскелитстов сделать прототип и забить
Прототип-то рабочий, в отличии от.
FR>>>Кроме того на Хаскеле в отличии от Эрланга, Окамла и Лиспов практически нет достаточно объемного промышленного кода.
T>>Да что ты говоришь!
FR>Правду!
Как человек, писавший 4 года на кемле, скажу -- на хаскеле библиотек больше и уровень их выше.
FR>>Не будут, нормальный вариант для Хаскелитстов сделать прототип и забить
V>Прототип-то рабочий, в отличии от.
Проблема в том что он только прототипом и остается, до продукта не доходит.
V>Как человек, писавший 4 года на кемле, скажу -- на хаскеле библиотек больше и уровень их выше.
Угу библиотек больше, популярность языка и размер комьюнити гораздо больше, а продуктов и промышленного кода почему-то меньше.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>К тому моменту, как программа на неленивом языке хоть как-то начнёт работать, в программу на Хаскеле уже будут внесены все аннотации строгости. FR>Не будут, нормальный вариант для Хаскелитстов сделать прототип и забить
А почему? А потому, что либо и так нормально работает, либо прототип подтвердил худшие опасения насчёт алгоритма вообще.
FR>>>Кроме того на Хаскеле в отличии от Эрланга, Окамла и Лиспов практически нет достаточно объемного промышленного кода. T>>Да что ты говоришь! FR>Правду!
"Научный факт меняется постоянно" (С) Грегори Хаус.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vshabanov, Вы писали:
FR>>>Не будут, нормальный вариант для Хаскелитстов сделать прототип и забить
V>>Прототип-то рабочий, в отличии от.
FR>Проблема в том что он только прототипом и остается, до продукта не доходит.
Значит не надо было. Такое ощущение от хаскеля возникает не потому, что делают прототип и забивают, а потому, что большинство интересных/известных прототипов сейчас делаются на хаскелле (что тоже показатель). Соотношение кол-ва прототип/production одинаковое.
V>>Как человек, писавший 4 года на кемле, скажу -- на хаскеле библиотек больше и уровень их выше.
FR>Угу библиотек больше, популярность языка и размер комьюнити гораздо больше, а продуктов и промышленного кода почему-то меньше.
Да как-то не сильно меньше. На эрланге проектов достаточно мало, кажется много из-за того, что они обычно обслуживают много клиентов. На кемле проектов может и чуть больше (кемл постарше хаскеля будет), но они уже старые, новые проекты на кемле почти никто не делает. На лиспе проектов еще больше, но, опять же, старые, новых никто не делает.
Если смотреть по кол-ву проектов, то стоит сразу выбирать кобол и не думать. Надо смотреть на тенденции. Хаскель, как язык, всегда был на голову выше остальных. В последние годы он имеет очень неплохой рантайм, да еще и hackage появился. Т.е. если лет 5-10 назад еще как-то можно было отмазываться, что мол медленный/библиотек нет, то сейчас уже нет.
maq> M>Wikipedia, Flickr — PHP maq> M>Youtube — Python maq> M>Myspace — сначала Coldfusion, сейчас C#
maq> M>Какой из этих языков близок по производительности к С/С++?
maq> C# близок. Помимо этого, обычно на таких проектах пишут некоторые части на C/C++,
Можно примеры? Кстати, помимо РНР в вебе еще, например, используются Питон или Руби (как на Твиттере). Или Coldfusion. Или Java. И вообще — highscalability.com в руки. икто не жалуется на скрипты, все говорят о том, как бороться с базами данных и файлами.
maq> так как PHP (или кто там еще) не справляются. Хочется этого избежать.
Планируется 15 миллионов пользователей и миллионы хитов в день сразу?
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, lant, Вы писали:
L>>есть опыт использования erlang (библиотека yaws) для написания веб страниц — админки для игрового сервера, написанного на эрланге. для этой цели очень хорошо подходит. для erlang также есть хитрые mvc фреймворки, но пока в них не было необходимости. если бы писал веб проект не привязанный к игровому серверу, то выбрал бы хаскель.
V>А какие проблемы с хаскелем для игрового сервера? Или там уже было все на эрланге?
1) когда сервер уже написан на эрланге, писать к нему админку на хаскеле очень интересно, но не выгодно.
2) сервер писали на эрланге по многим причинам, главная из которых — простота изучения эрланга, что не характерно для Хаскеля.
Здравствуйте, vshabanov, Вы писали:
V>Да как-то не сильно меньше. На эрланге проектов достаточно мало, кажется много из-за того, что они обычно обслуживают много клиентов. На кемле проектов может и чуть больше (кемл постарше хаскеля будет), но они уже старые, новые проекты на кемле почти никто не делает. На лиспе проектов еще больше, но, опять же, старые, новых никто не делает.
Э... ну это уже полнейший оговор. Не скажу за Кэмл, а вот на разновидностях Лиспа проектов делается не мало. Все же макры лиспа способны затмить любые проблемы этого старичка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vshabanov, Вы писали:
V>>Да как-то не сильно меньше. На эрланге проектов достаточно мало, кажется много из-за того, что они обычно обслуживают много клиентов. На кемле проектов может и чуть больше (кемл постарше хаскеля будет), но они уже старые, новые проекты на кемле почти никто не делает. На лиспе проектов еще больше, но, опять же, старые, новых никто не делает.
VD>Э... ну это уже полнейший оговор. Не скажу за Кэмл, а вот на разновидностях Лиспа проектов делается не мало. Все же макры лиспа способны затмить любые проблемы этого старичка.
Если бы это было так, то мы бы все сейчас использовали Лисп.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: ФЯ для WEB
От:
Аноним
Дата:
23.09.09 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Э... ну это уже полнейший оговор. Не скажу за Кэмл, а вот на разновидностях Лиспа проектов делается не мало. Все же макры лиспа способны затмить любые проблемы этого старичка.
В случае с вебом, это не лисп, а схема, и не макры, а first class continuations.
Здравствуйте, vshabanov, Вы писали:
V>Да как-то не сильно меньше. На эрланге проектов достаточно мало, кажется много из-за того, что они обычно обслуживают много клиентов. На кемле проектов может и чуть больше (кемл постарше хаскеля будет), но они уже старые, новые проекты на кемле почти никто не делает. На лиспе проектов еще больше, но, опять же, старые, новых никто не делает.
Насчет OCaml у меня складывается ситуация что он уходит из академической ниши и пусть хоть и достаточно робко, но проникает в индустрию. Эрланг по моему уже достаточно широко используется, но его мало видно снаружи.
V>Если смотреть по кол-ву проектов, то стоит сразу выбирать кобол и не думать. Надо смотреть на тенденции. Хаскель, как язык, всегда был на голову выше остальных. В последние годы он имеет очень неплохой рантайм, да еще и hackage появился. Т.е. если лет 5-10 назад еще как-то можно было отмазываться, что мол медленный/библиотек нет, то сейчас уже нет.
Да Хаскель неплохо подтянулся, OCaml в этом отстает, но подвижки тоже есть, те же батарейки скоро зарелизятся.
Если смотреть на такие тенденции то надо пересаживатся на F#
V>>Если смотреть по кол-ву проектов, то стоит сразу выбирать кобол и не думать. Надо смотреть на тенденции. Хаскель, как язык, всегда был на голову выше остальных. В последние годы он имеет очень неплохой рантайм, да еще и hackage появился. Т.е. если лет 5-10 назад еще как-то можно было отмазываться, что мол медленный/библиотек нет, то сейчас уже нет.
FR>Да Хаскель неплохо подтянулся, OCaml в этом отстает, но подвижки тоже есть, те же батарейки скоро зарелизятся. FR>Если смотреть на такие тенденции то надо пересаживатся на F#
Здравствуйте, thesz, Вы писали:
VD>>Э... ну это уже полнейший оговор. Не скажу за Кэмл, а вот на разновидностях Лиспа проектов делается не мало. Все же макры лиспа способны затмить любые проблемы этого старичка.
T>Если бы это было так, то мы бы все сейчас использовали Лисп.
А это так. Но не для всех. Просто кто-то ценит качества лиспа выше чем то что может предоставить другие языки. А кто-то нет.
Точно так же это и про твой любимый Хаскель. Для тебя он идеален. А для меня — нет. И ты по-своему прав. Как и я по-своему прав.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> В случае с вебом, это не лисп, а схема, и не макры, а first class continuations.
Ваши континюэшоны есть много где. И их почти куда угодно можно приделать. А вот Мары есть только в 3-4 языках из которых широко используется только Лисп.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Ваши континюэшоны есть много где.
Только в половине случаев они будут escape-only.
Плюс, в scheme уже есть готовая инфраструктура работы с континуациями и готовое комьюнити, которое знакомо с континуациями.
Достаточно хорошо продуманы и реализованы на уровне библиотек (в той же plt) вещи более высокого уровня, чем простой call/cc (например, shift/reduce, composable continuations, serializable continuations).
А в этом "много где" — кто даст гарантию, что не придется писать shift/reduce руками и найдутся в комьюнити люди, у которых можно будет консультироваться?
VD>И их почти куда угодно можно приделать.
И будет БДСМ: либо бондаж с чем-то типа монады Cont, либо садо-мазо с ручным CPS.
Re[10]: ФЯ для WEB
От:
Аноним
Дата:
23.09.09 13:40
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Ваши континюэшоны есть много где.
Где, например? First class, причём, а не такие, которые можно на исключениях эмулировать.
VD> И их почти куда угодно можно приделать.
Если бы всё было так красиво. Но в действительности всё совсем не так, увы.
Здравствуйте, FR, Вы писали:
FR>Кстати нужность не исключает интересности, это две ортогональные оси для оценок.
так может точечную диаграмму изобразишь с разными языками и со шкалой от 0 до 10?
FR>>Кстати нужность не исключает интересности, это две ортогональные оси для оценок. D>так может точечную диаграмму изобразишь с разными языками и со шкалой от 0 до 10?
А смысл?
У каждого будут свои диаграммы, к тому же меняющиеся со временем.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Denom, Вы писали:
FR>>>Кстати нужность не исключает интересности, это две ортогональные оси для оценок. D>>так может точечную диаграмму изобразишь с разными языками и со шкалой от 0 до 10?
FR>А смысл? FR>У каждого будут свои диаграммы, к тому же меняющиеся со временем.
А если голосованием а потом по средним значениям диаграмму
Здравствуйте, Denom, Вы писали: D>А если голосованием а потом по средним значениям диаграмму
Это будет интересно, конечно. Нужно прикинуть шкалу и список сравниваемых языков.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Ты смотришь на языки, как на "нужные языки".
FR>Нет, иначе бы я начал свой небольшой проектик не на OCaml а на смеси питона и C++
А почему выбрал OCaml?
T>>На F# никогда не будет интересно.
FR>Да ладно на нем гораздо интересней чем на C#
Но при этом он всё равно нужный.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
FR>>Нет, иначе бы я начал свой небольшой проектик не на OCaml а на смеси питона и C++
T>А почему выбрал OCaml?
Потому что хаскель не осилил
Если серъезно, то куча причин и все субъективные.
FR>>Да ладно на нем гораздо интересней чем на C#
T>Но при этом он всё равно нужный.
Здравствуйте, Mr.Cat, Вы писали:
VD>>Ваши континюэшоны есть много где. MC>Только в половине случаев они будут escape-only.
Что означает сие высказывание?
MC>Плюс, в scheme уже есть готовая инфраструктура работы с континуациями и готовое комьюнити, которое знакомо с континуациями.
Ну, комьюнити — это сильно конечно. А инфраструктура дело наживное. Вон даже в Моно хотя всроить континюэшоны в рантайм.
MC>Достаточно хорошо продуманы и реализованы на уровне библиотек (в той же plt) вещи более высокого уровня, чем простой call/cc (например, shift/reduce, composable continuations, serializable continuations). MC>А в этом "много где" — кто даст гарантию, что не придется писать shift/reduce руками и найдутся в комьюнити люди, у которых можно будет консультироваться?
Ну, если вспомнить, что Схема язык не лучше и не хуже чем другие и что комьюнити у него не самый огромный, то на все вопросы можно смело ответить — "да".
VD>>И их почти куда угодно можно приделать. MC>И будет БДСМ: либо бондаж с чем-то типа монады Cont, либо садо-мазо с ручным CPS.
Да какая разница что там будет? Фанатство каое-то. Это чисто технический аспект. К тому же для веб-фрэймворков вообще не важны аспекты производительности, так как передача континиэшонов не будет в этой задаче занимать основное время. Есть туча фрэймворков использующих интерпретируемые языки для описания вокфлоу веб-сайтов и никто не жалуется на производительность.
Меж тем кроме вокфлоу, проблему которого и решают континюэшоны, есть еще и обычный код которого по любому прийдется писать много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
VD>>Ваши континюэшоны есть много где.
А> Где, например?
Ява, Питон, F#, туча фрэймворков... Скоро будет даже в Моно. Короче гугль тебе в помощь.
Если же вспомнить о сопрограммах и зеленых потоках, то это почти любое средство разработки.
А>First class, причём, а не такие, которые можно на исключениях эмулировать.
А вот это уже не важно для задач которые в веб-приложения с их помощью решаются.
VD>> И их почти куда угодно можно приделать.
А> Если бы всё было так красиво. Но в действительности всё совсем не так, увы.
В действительности все совсем так. И не используют их в большей степени из-за того, что не понимаю, что это такое.
Просто кому-то хочется видеть выдать некоторую фичу за мега-приемущество забивающие все остальное.
Может быть макры и можно было бы за таковое выдать, так как ни хороших макрах можно много чего реализовать. Но континиэшоны вещь весьма специфичная. Конечно хорош иметь ее в своем арсенале, но ею мир не заканчивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: ФЯ для WEB
От:
Аноним
Дата:
23.09.09 16:19
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Ява, Питон, F#, туча фрэймворков...
Нет, нет, нет, тем более нет.
VD> Скоро будет даже в Моно. Короче гугль тебе в помощь. VD>Если же вспомнить о сопрограммах и зеленых потоках, то это почти любое средство разработки.
Опа. По потоку на каждый запрос, и прибивать по таймауту? Стильно.
А>>First class, причём, а не такие, которые можно на исключениях эмулировать.
VD>А вот это уже не важно для задач которые в веб-приложения с их помощью решаются.
Нет, именно это как раз и важно. Прошу посмотреть на SISCweb внимательнее. Там не просто continuations нужны, а вообще сериализируемые.
VD>Просто кому-то хочется видеть выдать некоторую фичу за мега-приемущество забивающие все остальное.
Ага. В случае в вебом, и вообще с любым асинхронным взаимодействием клиента с сервером, это мегафича, забивающая начисто всё остальное.
VD>Может быть макры и можно было бы за таковое выдать, так как ни хороших макрах можно много чего реализовать.
Много чего можно, а вот first class continuations нельзя.
VD> Но континиэшоны вещь весьма специфичная. Конечно хорош иметь ее в своем арсенале, но ею мир не заканчивается.
Для асинхронного обмена сообщениями — можно считать, что и заканчивается. Все остальные фичи уже и не нужны, когда есть такое.
Re[12]: ФЯ для WEB
От:
Аноним
Дата:
23.09.09 16:28
Оценка:
Здравствуйте, VladD2, Вы писали:
MC>>Только в половине случаев они будут escape-only.
VD>Что означает сие высказывание?
Я так понимаю — то, что нельзя взять текущий continuation, сериализовать его в БД, а ключик послать клиенту. И потом по этому ключику достать и исполнить.
Здравствуйте, Аноним, Вы писали:
VD>>Ява, Питон, F#, туча фрэймворков...
А> Нет, нет, нет, тем более нет.
Не надо говорить ерунду.
VD>> Скоро будет даже в Моно. Короче гугль тебе в помощь. VD>>Если же вспомнить о сопрограммах и зеленых потоках, то это почти любое средство разработки.
А> Опа. По потоку на каждый запрос, и прибивать по таймауту? Стильно.
По зеленому потоку. Это не так накладно для многих применений.
VD>>А вот это уже не важно для задач которые в веб-приложения с их помощью решаются.
А> Нет, именно это как раз и важно. Прошу посмотреть на SISCweb внимательнее. Там не просто continuations нужны, а вообще сериализируемые.
а) Это не накладывает ограничений на скорость; б) Это не обязательное требование для веба.
А> Ага. В случае в вебом, и вообще с любым асинхронным взаимодействием клиента с сервером, это мегафича, забивающая начисто всё остальное.
См. выше. Я по этому поводу уже все сказал.
VD>>Может быть макры и можно было бы за таковое выдать, так как ни хороших макрах можно много чего реализовать.
А> Много чего можно, а вот first class continuations нельзя.
См. Выше.
VD>> Но континиэшоны вещь весьма специфичная. Конечно хорош иметь ее в своем арсенале, но ею мир не заканчивается.
А> Для асинхронного обмена сообщениями — можно считать, что и заканчивается. Все остальные фичи уже и не нужны, когда есть такое.
Есть и другие решения. Скажем туча веб-фрэймворков использует передачу сообщений и идеи акторов. Другие пользуются теми же континюэшонами или сопрограммами реализованными разным образом.
По любому интерпретатор (я правильно понял, что используемая схема там интерпретируется?) проиграет компилятору на большой задаче.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> Я так понимаю — то, что нельзя взять текущий continuation, сериализовать его в БД, а ключик послать клиенту. И потом по этому ключику достать и исполнить.
Ну, кое-где это наверно можно. Только не очень ясно зачем же в БД пихать? Народ вон от вюстэйта избавляется, а тут...
Не проще ли держать в памяти, а тех что давнно не ворочаются выкидывать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: ФЯ для WEB
От:
Аноним
Дата:
23.09.09 17:09
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Ну, кое-где это наверно можно. Только не очень ясно зачем же в БД пихать? Народ вон от вюстэйта избавляется, а тут...
Затем, что вернуться за ним могут весьма не скоро. Это вовсе не обязательно в рамках одной сессии.
VD>Не проще ли держать в памяти, а тех что давнно не ворочаются выкидывать?
Того врага народа, который придумал таймауты, надо выпороть публично. Чтоб другим неповадно было.
Здравствуйте, VladD2, Вы писали:
PM>>* Ur — язык для веба с зависимыми типами. VD>На первый взгляд весьма интересная штука. VD>Вот только неформального описания языка я так и не нашел. Интересно есть по нему статьи?
Похоже, что статей нет, иначе в анонсе на LtU и на офсайте были бы ссылки.
VD>Плюс, похоже что это экспериментальная хреновина работающая только под линуксом.
Понятно, что экспериментальная. Проект энтузиаста-одиночки. Я же говорил, что для социопатов .
Здравствуйте, palm mute, Вы писали:
PM>Понятно, что экспериментальная. Проект энтузиаста-одиночки. Я же говорил, что для социопатов .
Жаль. Проектное решение весьма грамотное + весь хайтек CS в одном флакоен.
Приятно что на практике все монады и другие классы типов спрятаны (похоже что средствами метапрограммирования) под красивыми абстракциями и конечный код смотрится чисто и понятно даже непосвященному.
В общем, я бы с удовольствием почитал бы про это дело статейку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> Затем, что вернуться за ним могут весьма не скоро. Это вовсе не обязательно в рамках одной сессии.
Ага. Хранение viewstate в БД тоже так же обосновывали... Сейчас вот переходят на ASP MVC, так как оказалось, что состояние проще не хранить вовсе.
VD>>Не проще ли держать в памяти, а тех что давнно не ворочаются выкидывать?
А> Того врага народа, который придумал таймауты, надо выпороть публично. Чтоб другим неповадно было.
Публично надо пороть тех кто заходит на сайт и держит там сессии без надобности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: MC>>Только в половине случаев они будут escape-only. VD>Что означает сие высказывание?
Ну континуации можно реализовать полноценно (т.е. континуация и обычная функция неразличимы) — а можно сделать видимость их реализации. Например, если континуацию, захватываемую через call/cc, можно использовать только для "преждевременного" возврата — и больше никак — то говорят об escape-only.
VD>Вон даже в Моно хотя всроить континюэшоны в рантайм.
Это они глядя на parrot? Но идея хороша, да.
VD>Меж тем кроме вокфлоу, проблему которого и решают континюэшоны...
Я бы отнес континуации к средствам метапрограммирования по части control flow.
Здравствуйте, Mr.Cat, Вы писали:
MC>Ну континуации можно реализовать полноценно (т.е. континуация и обычная функция неразличимы) — а можно сделать видимость их реализации. Например, если континуацию, захватываемую через call/cc, можно использовать только для "преждевременного" возврата — и больше никак — то говорят об escape-only.
Это уже хрень какая-то а не континюэшоны... если я тебя правильно понял.
VD>>Вон даже в Моно хотя всроить континюэшоны в рантайм. MC>Это они глядя на parrot? Но идея хороша, да.
Х.з. Просто наткнулся недавно на роадмап Моно. Увидел много нового.
VD>>Меж тем кроме вокфлоу, проблему которого и решают континюэшоны... MC>Я бы отнес континуации к средствам метапрограммирования по части control flow.
А не надо это делать. Для МП есть куда более подходящие средства.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Это уже хрень какая-то а не континюэшоны... если я тебя правильно понял.
Конечно хрень.
MC>>Я бы отнес континуации к средствам метапрограммирования по части control flow. VD>А не надо это делать. Для МП есть куда более подходящие средства.
Почему не надо? С помощью континуаций делаются эксепшены, корутины и прочая ересь, которую уже используют прикладные программисты. По мне так и есть — метасредство.
Здравствуйте, VladD2, Вы писали:
А>> Того врага народа, который придумал таймауты, надо выпороть публично. Чтоб другим неповадно было.
VD>Публично надо пороть тех кто заходит на сайт и держит там сессии без надобности.
На всяких гос. сайтах заполнение анкет часто занимает немалое время — надо найти разные документы, просмотреть. Очень потом приятно, после часа работы, увидеть по сабмиту что мол опа, таймаут.
Не, таймауты — это редкостный идиотизм, которому нет никакого оправдания.
Здравствуйте, Mr.Cat, Вы писали:
MC>Почему не надо?
Я уже отвечал на этот вопрос. Для этого есть лучшие средства.
MC>С помощью континуаций делаются эксепшены, корутины и прочая ересь, которую уже используют прикладные программисты. По мне так и есть — метасредство.
Сопрограммы и континиэшоны во многом похожи, но имеют принципиальные различия. Вольфхаунд где-то очень хорошо это продемонстрировал. Так что сделать качествнно из одного другое будет затруднительно.
Исключения же точно не стоит делать. Они просто должны быть в языке, если его дизайн на них расчитан. Опять же реализовать исключения эффективно не выйдет, так как эффективная их реализация — это их отсутствие в коде. Континюэшоны же принципиально не эффективны, так как не ложатся на архитектуру процессора на котором исполняется программа.
И исключения, и сопрограммы — это системные вещи. Метапрограммирование же призвано решать прикладные задачи.
Тут вообще какая-то подмена понятий. То что через одну фичу можно с горем пополам выразить другую не делает саму фичу метапрограммированием. Скажем через функции можно выразить циклы, но функции не дают поддержку МП.
Покажи мне как с помощью континюэшонов создать какую-то новую синтаксическую конструкцию. Тогда и поговорим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> На всяких гос. сайтах заполнение анкет часто занимает немалое время — надо найти разные документы, просмотреть. Очень потом приятно, после часа работы, увидеть по сабмиту что мол опа, таймаут.
А зачем для заполнения анкеты держать соединение?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: ФЯ для WEB
От:
Аноним
Дата:
24.09.09 17:21
Оценка:
Здравствуйте, VladD2, Вы писали:
А>> На всяких гос. сайтах заполнение анкет часто занимает немалое время — надо найти разные документы, просмотреть. Очень потом приятно, после часа работы, увидеть по сабмиту что мол опа, таймаут.
VD>А зачем для заполнения анкеты держать соединение?
А это надо "программистов" так называемых спрашивать, кто эти сайтики клепает. Обычно сессия выглядит так — авторизация (вот тут контекст сессии и создаётся) — две-три страницы с вопросами, а потом большая страница с большой формой. И вот при её сабмите таймаут и происходит.
Но вопрос не в этом. Вопрос простой — зачем вообще эти таймауты?!?
Здравствуйте, Аноним, Вы писали:
А> А это надо "программистов" так называемых спрашивать, кто эти сайтики клепает. Обычно сессия выглядит так — авторизация (вот тут контекст сессии и создаётся) — две-три страницы с вопросами, а потом большая страница с большой формой. И вот при её сабмите таймаут и происходит.
А> Но вопрос не в этом. Вопрос простой — зачем вообще эти таймауты?!?
Я вообще не понимаю о каких таймаутах речь.
Авторизация может тупо вернуть некий билет который можно хранить в куках. Сессия тут просто не нужна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Сопрограммы и континиэшоны во многом похожи, но имеют принципиальные различия. Вольфхаунд где-то очень хорошо это продемонстрировал. Так что сделать качествнно из одного другое будет затруднительно.
Не так.
Сопрограммы конечно же выражаются через продолжения. Через продолжения можно выразить вообще любую конструкцию управляющую потоком исполнения.
Но у полноценных продолжений есть очень большая проблема которой нет у сопрограмм.
Продолжения в общем случае не совместимы с детерминированной финализацией. Сопрограммы этой проблемы не имеют.
А детерминированная финализация не практике необходима.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Сопрограммы и континиэшоны во многом похожи, но имеют принципиальные различия. Вольфхаунд где-то очень хорошо это продемонстрировал. Так что сделать качествнно из одного другое будет затруднительно. WH>Продолжения в общем случае не совместимы с детерминированной финализацией. Сопрограммы этой проблемы не имеют. WH>А детерминированная финализация не практике необходима.
Продолжения не совместимы с детерминированной финализацией не более, чем обычные замыкания. Всегда при желании можно захватить ссылку на закрытый ресурс в environment долго-живущей лямбды.
Насколько я понимаю, Влад противопоставляет макросы и продолжения в качестве средств метапрограммирования. Опять же, в отношении детерминированной финализации они ничем не отличаются. Ничем не ограниченные трансформации AST в общем случае ничуть не безопаснее ничем не ограниченных манипуляций потоком управления.
з.ы. Заметьте, я не утверждаю, что при применении продолжений проблем совсем не возникает.
Здравствуйте, VladD2, Вы писали: VD>Сопрограммы и континиэшоны во многом похожи, но имеют принципиальные различия. Вольфхаунд где-то очень хорошо это продемонстрировал.
А ссылочку можно?
VD>Исключения же точно не стоит делать. Они просто должны быть в языке, если его дизайн на них расчитан.
Ну это, пожалуй, один из немногих примеров механизма "нелокальных переходов", который стал общепризнанным. А вот корутинами каждый в своем языке называет что-то свое.
VD>И исключения, и сопрограммы — это системные вещи. Метапрограммирование же призвано решать прикладные задачи.
Я смотрю на МП как на инструмент разработчика библиотек, которыми потом пользуются прикладные программисты. И континуации к таким инструментам тоже отношу. Впрочем, по вопросам классификации понятий мне спорить не хотелось бы.
VD>Тут вообще какая-то подмена понятий. То что через одну фичу можно с горем пополам выразить другую не делает саму фичу метапрограммированием.
Не с горем пополам одно через другое, а реализовать на основе одного целый класс схожих механизмов.
Так, гигиенические макросы позволяют создавать новые синтаксические конструкции, обладающие свойством лексической области видимости.
А континуации — создавать механизмы нелокального перехода.
Здравствуйте, VladD2, Вы писали:
VD>Тут вообще какая-то подмена понятий. То что через одну фичу можно с горем пополам выразить другую не делает саму фичу метапрограммированием. Скажем через функции можно выразить циклы, но функции не дают поддержку МП. VD>Покажи мне как с помощью континюэшонов создать какую-то новую синтаксическую конструкцию. Тогда и поговорим.
Синтаксическую конструкцию, конечно же, сделать нельзя. Но сделать так, чтобы вызов обычной функции выглядел как ключевое слово, можно.
Например, можно сделать некое подобие list-comprehensions:
(* test() возвращает [(1, 11); (1, 13); (2, 12); (3, 11); (3, 13)] *)let test () = generate (fun () ->
let x = oneof [1;2;3] in
let y = oneof [11;12;13] in
begin
guard ((x + y) mod 2 == 0);
return (x, y)
end)
oneof, guard, return кажутся ключевыми словами, но таковыми не являются.
Вот их определение (без комментариев, там происходит монадная рефлексия и прочее колдунство):
open Delimcc
let p = new_prompt ()
let shift f = take_subcont p (fun sk () ->
push_prompt p (fun () -> (f (fun c ->
push_prompt p (fun () -> push_subcont sk c)))))
let generate f = push_prompt p f
let bind m k = List.concat (List.map k m)
let return x = [x]
let oneof m = shift (fun k -> bind m (fun x -> k (fun () -> x)))
let guard cond = if cond then oneof [()] else oneof []
Признаю, для данной задачи макросы подходят гораздо лучше. А вот для веба, если мы хотим программировать серверную часть так, будто это обычный десктопный ГУЙ, показывающий модальные диалоги и дожидающийся ответа, все не так очевидно.
Здравствуйте, palm mute, Вы писали:
PM>Продолжения не совместимы с детерминированной финализацией не более, чем обычные замыкания. Всегда при желании можно захватить ссылку на закрытый ресурс в environment долго-живущей лямбды.
Ты не прав.
Засовываем все ресурсы в uniqueness типы и нет проблем.
Более того ты сейчас говоришь о искусственном продлении жизни ресурса.
Это не проблема особенно если обязать разработчика делать это явно и не давать продлевать жизнь уже убитым ресурсам. С uniqueness типами это получается автоматом.
С продолжениями другая беда.
Покажу на псевдокоде:
Не трудно заметить что file.Close() может быть вызвана более одного раза.
Что является фундаментальной проблемой и не может быть устранено при наличии полноценных продолжений вне зависимости от модели детерминированной финализации.
PM>Насколько я понимаю, Влад противопоставляет макросы и продолжения в качестве средств метапрограммирования. Опять же, в отношении детерминированной финализации они ничем не отличаются. Ничем не ограниченные трансформации AST в общем случае ничуть не безопаснее ничем не ограниченных манипуляций потоком управления.
Если за детерминированной финализацией следит система типов то ты хоть затрансформируйся... проверяльщик типов просто не пропустит программу в которой финализацию поломали.
Причем эти проверки могут быть осуществлены даже без зависимых типов.
PM>з.ы. Заметьте, я не утверждаю, что при применении продолжений проблем совсем не возникает.
Ты просто сильно занижаешь их вредность...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, palm mute, Вы писали:
PM>Признаю, для данной задачи макросы подходят гораздо лучше. А вот для веба, если мы хотим программировать серверную часть так, будто это обычный десктопный ГУЙ, показывающий модальные диалоги и дожидающийся ответа, все не так очевидно.
Сам же ссылку на Ur/Web давал
Вот из такого кода
fun counter n = return <xml><body>
Current counter: {[n]}<br/>
<a link={counter (n + 1)}>Increment</a><br/>
<a link={counter (n - 1)}>Decrement</a>
</body></xml>
fun main () = counter 0
получаем вот такой HTML
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><body><sc>
Current counter: 0<br />
<a href="/ur/demo/Demo/Counter/counter/1">Increment</a><br />
<a href="/ur/demo/Demo/Counter/counter/-1">Decrement</a>
</body></html>
Обошлось без всяких там продолжений.
Просто сериализовали имя и аргументы функции в url и все.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, palm mute, Вы писали:
PM>>Продолжения не совместимы с детерминированной финализацией не более, чем обычные замыкания. Всегда при желании можно захватить ссылку на закрытый ресурс в environment долго-живущей лямбды. WH>Ты не прав. WH>Засовываем все ресурсы в uniqueness типы и нет проблем.
Подтягивается тяжелая артиллерия . Только что у нас были только макросы, теперь уже навороченные системы типов появились. Какие есть принципиальные трудности реализации такой же системы типов, которая поддерживает продолжения?
WH>С продолжениями другая беда. WH>Покажу на псевдокоде:
... WH>Не трудно заметить что file.Close() может быть вызвана более одного раза. WH>Что является фундаментальной проблемой и не может быть устранено при наличии полноценных продолжений вне зависимости от модели детерминированной финализации.
Предположим, у нас есть система типов, о которой ты говоришь.
Компилятор делает CPS-преобразование, callcc в псевдокоде превращается в:
Твоя система типов должна справиться с кодом после преобразования, если лямбды для нее не проблема.
PM>>з.ы. Заметьте, я не утверждаю, что при применении продолжений проблем совсем не возникает. WH>Ты просто сильно занижаешь их вредность...
Ни в коем случае. Я вообще не делаю оценочных утверждений типа "фича икс зло, а фича игрек — рулит". Мне просто не нравится, что о продолжениях создаются мифы.
Здравствуйте, WolfHound, Вы писали:
PM>>Признаю, для данной задачи макросы подходят гораздо лучше. А вот для веба, если мы хотим программировать серверную часть так, будто это обычный десктопный ГУЙ, показывающий модальные диалоги и дожидающийся ответа, все не так очевидно. WH>Сам же ссылку на Ur/Web давал WH>... WH>Обошлось без всяких там продолжений. WH>Просто сериализовали имя и аргументы функции в url и все.
Как это обошлось без продолжений? "сериализовали имя и аргументы функции в url" — это и есть продолжение. Думаю, если бы у функции counter были локальные переменные — их мы бы тоже увидели в url.
Обошлось без first-class продолжений, что неудивительно в прикладном DSL, зачем они там? Т.к. автор выбрал трудный путь — создать полноценный язык, с компилятором и стандартной библиотекой, написанными с нуля, — юзеру ничего не нужно знать о продолжениях, ими занимается компилятор.
А вот если general-purpose язык поддерживает first-class продолжения, то, теоретически, использовать его для веба проще, т.к. можно легко создать embedded DSL. Что важно, не нужно переписывать стандартную библиотеку, запросы пользователю можно отправлять из глубин библиотечных функций, подсунув им правильный callback.
Здравствуйте, WolfHound, Вы писали: WH>Что является фундаментальной проблемой и не может быть устранено при наличии полноценных продолжений вне зависимости от модели детерминированной финализации.
Я не согласен, что это фундаментальная проблема континуаций. С аналогичной проблемой можно столкнуться (а можно и не столкнуться) хотя бы в C#:
...если в Enumerate используется yield.
Если бы компилятор мог такие ошибки предотвращать — было бы хорошо. Но то, что это фундаментальная проблема — не согласен.
Здравствуйте, palm mute, Вы писали:
PM>Как это обошлось без продолжений? "сериализовали имя и аргументы функции в url" — это и есть продолжение. Думаю, если бы у функции counter были локальные переменные — их мы бы тоже увидели в url.
Это не продолжение. Это замыкание. Стек вызовов не сохраняется. Пожалуйста не путай их.
Кстати сам автор говорит о том же
Pressing the button triggers a call to loop, with the first argument given explicitly as count+1. Notice that this means that we are using closures, stored on the client side, to track state.
PM>А вот если general-purpose язык поддерживает first-class продолжения, то, теоретически, использовать его для веба проще, т.к. можно легко создать embedded DSL. Что важно, не нужно переписывать стандартную библиотеку, запросы пользователю можно отправлять из глубин библиотечных функций, подсунув им правильный callback.
Да не нужны продолжения.
Замыканий более чем достаточно.
Ur/Web это прекрасно демонстрирует.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mr.Cat, Вы писали:
WH>>Что является фундаментальной проблемой и не может быть устранено при наличии полноценных продолжений вне зависимости от модели детерминированной финализации. MC>Я не согласен, что это фундаментальная проблема континуаций.
Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений.
MC>С аналогичной проблемой можно столкнуться (а можно и не столкнуться) хотя бы в C#: MC>
MC>...если в Enumerate используется yield.
То что можно себе отстрелить голову и без продолжений ни кто не спорит.
Но в данном случае ты приводишь проблему которая есть только в конкретном языке с весьма позорной системой типов.
Простейшие uniqueness решают данную проблему на корню.
MC>Если бы компилятор мог такие ошибки предотвращать — было бы хорошо.
То что C# не может не значит что другие языки не могут.
MC>Но то, что это фундаментальная проблема — не согласен.
С корутинами типа yield действительно проблем нет.
Вот смотри:
def ReadLines(file : File) : Stream[string]
match (file.ReadLine())
| Some(line) =>
yield line;
ReadLines(file);
| None =>
Stream.End;
end
end
def DoSome(...) : Stream[string]
...
def file = File.Open(...);
...//если тут будет исключение файл будет закрыт
ReadLines(file);
end
Типы File и Stream[T] uniqueness.
Это значит что в один момент времени на объект может существовать одна и только одна ссылка.
Если ссылка на объект uniqueness типа вышла из зоны видимости то у объекта вызывается деструктор.
В данном случае функция ReadLines забирает владение открытым файлом, создает корутину в контексте которой будет жить открытый файл. И возвращает объект Stream[string].
При разрушении Stream[string] будет вызван деструктор объекта File.
Таким образом мы гарантировали что файл будт закрыт один и только один раз.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
12.8 Rpcify
Pieces of code are determined to be client-side, server-side, neither, or both, by figuring out which standard
library functions might be needed to execute them. Calls to server-side functions (e.g., query) within mixed
client-server code are identified and replaced with explicit remote calls. Some mixed functions may be
converted to continuation-passing style to facilitate this transformation.
Здравствуйте, palm mute, Вы писали:
PM>Подтягивается тяжелая артиллерия . Только что у нас были только макросы, теперь уже навороченные системы типов появились.
Пожалуйста не путай меня и Влада.
PM>Какие есть принципиальные трудности реализации такой же системы типов, которая поддерживает продолжения?
Если только продолжения то ни каких.
А если мы еще и детерминированную финализацию хотим то придется выбирать либо то либо другое.
PM>Предположим, у нас есть система типов, о которой ты говоришь. PM>Компилятор делает CPS-преобразование, callcc в псевдокоде превращается в:
И отвергается проверяльщиком типов. Ибо нефиг плодить ссылки на uniqueness тип.
PM>Ни в коем случае. Я вообще не делаю оценочных утверждений типа "фича икс зло, а фича игрек — рулит". Мне просто не нравится, что о продолжениях создаются мифы.
Какие мифы? Только факты.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений.
В языках, как ты говоришь, с "позорными" системами типов — так же, как и в присутствии yield в C# или в присутствии нескольких потоков. Если программист хочет бесконтрольно шарить ресурс между корутинами/потоками — программист должен сам определить, где надо освобождать ресурс.
WH>Простейшие uniqueness решают данную проблему на корню.
Что мешает uniqueness-типам решать ту же проблему на корню в коде с континуациями? Ты же сам сказал, что твой исходный бажный пример с call/cc uniqueness-типы не пропустят. Вот и замечательно — этого нам и было надо.
Здравствуйте, Mr.Cat, Вы писали:
WH>>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений.
Ответ на вопрос будет?
MC>В языках, как ты говоришь, с "позорными" системами типов — так же, как и в присутствии yield в C# или в присутствии нескольких потоков. Если программист хочет бесконтрольно шарить ресурс между корутинами/потоками — программист должен сам определить, где надо освобождать ресурс.
А давай ты расскажешь при решении какой задачи нужно бесконтрольно шарить ресурс?
MC>Что мешает uniqueness-типам решать ту же проблему на корню в коде с континуациями? Ты же сам сказал, что твой исходный бажный пример с call/cc uniqueness-типы не пропустят. Вот и замечательно — этого нам и было надо.
Так они и решают. Примерно как гильотина лечит головную боль.
При появлении хоть одного uniqueness типа программа с продолжениями компилироваться перестанет ибо у нее не будет шансов пройти проверку типов.
А если учесть что любой внешней ресурс это uniqueness тип и в программе есть хотя бы один внешней ресурс (иначе она не сможет оставить следов своей жизнедеятельности) то ни одна программа с продолжениями не скомпилируется.
Спрашивается: Если все равно ни одна программа с продолжениями не скомпилируется то нахрена их вообще добавлять?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, palm mute, Вы писали:
PM>Насколько я понимаю, Влад противопоставляет макросы и продолжения в качестве средств метапрограммирования. Опять же, в отношении детерминированной финализации они ничем не отличаются. Ничем не ограниченные трансформации AST в общем случае ничуть не безопаснее ничем не ограниченных манипуляций потоком управления.
А можно объяснить почему продолжения вообще относятся к средствам метапрограммирования?
Ну, и за одно хотелось бы услышать определение термина "метапрограммироваине". Может дело в трактовании?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, palm mute, Вы писали:
PM>oneof, guard, return кажутся ключевыми словами, но таковыми не являются.
Не знаю. Может у меня фантазия слабая? Они мне кажутся вызовами функций.
PM>Признаю, для данной задачи макросы подходят гораздо лучше.
Я что-то в этой задаче не углядел место где было метапрограммирование.
То что макросы подходят для МП — это и ёжику понятно, так как они и есть МП.
PM> А вот для веба, если мы хотим программировать серверную часть так, будто это обычный десктопный ГУЙ, показывающий модальные диалоги и дожидающийся ответа, все не так очевидно.
Все как раз очевидно. Макры == МП. Они позволяет реализовать тот синтаксис и ту семантику что нужно.
Что до примеров применения МП для Веба, то Вольфхаунд дал тебе отличный пример (твой же, если не ошибаюсь).
ЗЫ
И все же хотелось бы объяснений того каким боком продолжения относятся к МП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, palm mute, Вы писали:
PM>Как это обошлось без продолжений? "сериализовали имя и аргументы функции в url" — это и есть продолжение. Думаю, если бы у функции counter были локальные переменные — их мы бы тоже увидели в url.
Не обязательно. Их примеры это хорошо демонстрируют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr.Cat, Вы писали:
VD>>Тут вообще какая-то подмена понятий. То что через одну фичу можно с горем пополам выразить другую не делает саму фичу метапрограммированием. MC>Не с горем пополам одно через другое, а реализовать на основе одного целый класс схожих механизмов.
Да по фигу с горем или без. Мой вопрос был — "Какое отношение имеет возможность реализации одной фичи через другую к метапрограммированию?".
MC>Так, гигиенические макросы позволяют создавать новые синтаксические конструкции, обладающие свойством лексической области видимости.
Макры позволяют определять синтаксис и семантику. Отсюда понятно почему они могут помогать менять язык. Но МП — это возможность написания программ пишущих программы. И причем тут продолжения? Макры == МП. Заметь, не макры позволяют релизовать МП, а макры сами являются МП. Как только ты их применил, так сразу у тебя появилось МП. Но разве с продолжениями будет тоже самое?
MC>А континуации — создавать механизмы нелокального перехода.
Ну, и что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
вот для этого и существуют тесты — чтобы проталкивать мусор дуракам, которые не способны сами разобраться в предмете. ценность этих конкретных тестов — нулевая. одни из них говорят о том, что в c++ нет стандартной green threads библиотеки, а в ghc она есть. другие — о том, что и на хаскеле можно писать в assembler style.
там в одном тесте кажется php был на первом месте вообще, большая часть тех тестов зависела исключительно от библиотек, причём запрещалось использовать third-party ones, оставшиеся три теста были изрядно низкоуровнево оптимизированы любителями хаскела, дело дошло даже до включения в стандартные билиотеки ghc функции, необходимой для ускорения одного из них
VladD2 wrote:
> А> Я так понимаю — то, что нельзя взять текущий continuation, > сериализовать его в БД, а ключик послать клиенту. И потом по этому > ключику достать и исполнить. > > Ну, кое-где это наверно можно. Только не очень ясно зачем же в БД > пихать? Народ вон от вюстэйта избавляется, а тут... > Не проще ли держать в памяти, а тех что давнно не ворочаются выкидывать?
Я вот только что подумал тоже, что если параллельно с выполнением
сессии писать всё в БД с поддержко MVCC, в одной транзакции от
начала сессии, -- очень было бы удобно. Но я не понимаю тоже,
в чём там могли бы быть проблемы.
Здравствуйте, FR, Вы писали:
FR>В этом наверно тоже, но вот недавно в рассылке плач был на тему что французы ничего про OCaml не знают и пишут на вражеских языках.
Как-то странно. Ничего не знают, но в то же время что-то пишут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>> Но вопрос не в этом. Вопрос простой — зачем вообще эти таймауты?!?
VD>Я вообще не понимаю о каких таймаутах речь. VD>Авторизация может тупо вернуть некий билет который можно хранить в куках. Сессия тут просто не нужна.
Здравствуйте, Lloyd, Вы писали:
VD>>Я вообще не понимаю о каких таймаутах речь. VD>>Авторизация может тупо вернуть некий билет который можно хранить в куках. Сессия тут просто не нужна.
L>Дык, сессия именно так и работает.
Тут кто-то хотел хранить состояние сессии в БД. И это точно был не я.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали: WH>>>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений. WH>Ответ на вопрос будет?
Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился. Из твоих доводов остались uniqueness-типы. Я не знаком с ними настолько, чтобы аргументированно спорить, но на мой взгляд их внесение в язык окажет не большее влияние, чем монада IO, а она, как видно, ничуть не мешает писать код в cps — для него в хаскеле даже хелпер в виде монады Cont есть. Т.е. максимум надо будет разделять чистый и нечистый код, и в чистом можно будет использовать в том числе и континуации. Что касаетсмя использования континуаций в коде с побочными эффектами — с ходу не могу сформировать мнение. Возможно, стоит полистать ветку, где ты расписывал прелести uniqueness-типов Ремарку, но пока я плохо знаком с их основами — не вижу для себя в этом смысла.
WH>При появлении хоть одного uniqueness типа программа с продолжениями компилироваться перестанет ибо у нее не будет шансов пройти проверку типов. WH>А если учесть что любой внешней ресурс это uniqueness тип и в программе есть хотя бы один внешней ресурс (иначе она не сможет оставить следов своей жизнедеятельности) то ни одна программа с продолжениями не скомпилируется. WH>Спрашивается: Если все равно ни одна программа с продолжениями не скомпилируется то нахрена их вообще добавлять?
Здравствуйте, Mr.Cat, Вы писали:
MC>Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился.
Ты что-то не так понял.
Цитату можно?
MC>Из твоих доводов остались uniqueness-типы. Я не знаком с ними настолько, чтобы аргументированно спорить, но на мой взгляд их внесение в язык окажет не большее влияние, чем монада IO, а она, как видно, ничуть не мешает писать код в cps — для него в хаскеле даже хелпер в виде монады Cont есть.
Тут вот в чем дело.
Если uniqueness-тип попадает в продолжение то программа не сможет пройти проверку типов.
Проблема в том что call/cc засовывает в продолжение весь стек на момент вызова call/cc.
И в ста процентах случаев мы будем иметь в стеке хоть один uniqueness-тип. Иначе программа просто не сможет ничего сказать внешнему миру.
В случае с ручным CPS мы сами контролируем содержание стека. И можем избежать попадание в стек чего не надо.
MC>Возможно, стоит полистать ветку, где ты расписывал прелести uniqueness-типов Ремарку, но пока я плохо знаком с их основами — не вижу для себя в этом смысла.
Задача простая: Гарантировать что на объект существует одна и только одна ссылка.
Решается тоже очень просто: в переменную uniqueness-типа можно записать и прочитать из нее ровно один раз.
Таким образом мы просто реализуем семантику передачи владения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: MC>>Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился. WH>Ты что-то не так понял. WH>Цитату можно?
Но в данном случае ты приводишь проблему которая есть только в конкретном языке с весьма позорной системой типов.
Простейшие uniqueness решают данную проблему на корню.
Я это понял как согласие с тем, что детерминированная финализация в языках без uniqueness-типов возможна только в самых простых случаях.
WH>Если uniqueness-тип попадает в продолжение то программа не сможет пройти проверку типов.
Тут ты пожалуй прав. Сами по себе континуации и сими по себе uniqueness плохо сочетаются. Но из этого только следует то, что компилятор должен знать о контунцациях. Например, можно встроить поддержку delimited continuations, которые позволяют ограничить захватываемую континуацию. Также, я полагаю, в некоторых случаях можно доказать, что континуация, захваченная с call/cc вызывается не более одного раза.
WH>Задача простая: Гарантировать что на объект существует одна и только одна ссылка. WH>Решается тоже очень просто: в переменную uniqueness-типа можно записать и прочитать из нее ровно один раз. WH>Таким образом мы просто реализуем семантику передачи владения.
Ну на концептуальном-то уровне все понятно. Просто я ни разу не писал на языках с uniqueness. А дьявол-то наверняка в деталях.
Здравствуйте, Mr.Cat, Вы писали:
MC>Я это понял как согласие с тем, что детерминированная финализация в языках без uniqueness-типов возможна только в самых простых случаях.
Нет. Это о том что решение проблем неформальными механизмами это очень простой способ отстрелить себе голову.
MC>Тут ты пожалуй прав. Сами по себе континуации и сими по себе uniqueness плохо сочетаются.
Продолжения вообще с детерминированной финализацией не совместимы.
Просто в случае с uniqueness-типами ты получишь по голове во время компиляции, а в случае с try/finally во время исполнения.
MC>Но из этого только следует то, что компилятор должен знать о контунцациях.
Гм. А компилятор языка с продолжениями вообще может не знать о продолжениях?
Или даже так: Может ли компилятор языка не знать о какой бы то ни было фиче языка который он компилирует?
MC>Например, можно встроить поддержку delimited continuations, которые позволяют ограничить захватываемую континуацию.
О! Пошли ограничения. delimited continuations действительно можно засунуть в ту часть программа которая не общается с внешним миром.
Еще можно использовать escape-only continuations которые по сути исключения вид в профиль.
Вопрос лишь в том, а оно нужно? Учти что придется под них наворачивать систему типов, а она если говорить о языке удобном для практического использования и так получается весьма кучерявой.
MC>Также, я полагаю, в некоторых случаях можно доказать, что континуация, захваченная с call/cc вызывается не более одного раза.
А это уже получается корутина... совсем другой зверь.
MC>Ну на концептуальном-то уровне все понятно. Просто я ни разу не писал на языках с uniqueness. А дьявол-то наверняка в деталях.
uniqueness-типы это лучший из известных мне способов контролировать ресурсы. Он очевидно более гибкий чем try/finally и деструкторы С++. И его нельзя использовать не правильно. Программа просто не скомпилируется.
Что касается практики использования то: Ты на С++ писал? std::auto_ptr знаешь? Вот это оно самое и есть. Только не формализовано и интерфейс дырявый. На практике std::auto_ptr обычно используется когда нужно выпустить объект из функции (внутри функции справляются обычные дуструкторы) и при этом не потерять гарантии его удаления.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
MC>>Ну на концептуальном-то уровне все понятно. Просто я ни разу не писал на языках с uniqueness. А дьявол-то наверняка в деталях. WH>uniqueness-типы это лучший из известных мне способов контролировать ресурсы. Он очевидно более гибкий чем try/finally и деструкторы С++. И его нельзя использовать не правильно. Программа просто не скомпилируется.
А как делать разделяемое владение в твоей схеме?
Всё равно кроме счётчиков ссылок ничего не придумывается, со всеми их недостатками.
Здравствуйте, Cyberax, Вы писали:
C>А как делать разделяемое владение в твоей схеме?
Ты мне лучше скажи какую задачу ты решаешь.
А потом я тебе скажу как ее решить.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>А как делать разделяемое владение в твоей схеме? WH>Ты мне лучше скажи какую задачу ты решаешь. WH>А потом я тебе скажу как ее решить.
Не, понятно что всегда разделяемый ресурс можно на уровень выше вынести и сделать его уникальным. Только это иногда ведёт к тому, что ресурсы выносятся на самый верх. У region inference (для управления памятью) проблема с этим есть как раз, и решается как раз полумерами в виде счётчиков.
Здравствуйте, Cyberax, Вы писали:
WH>>Ты мне лучше скажи какую задачу ты решаешь. WH>>А потом я тебе скажу как ее решить. C>Не, понятно что всегда разделяемый ресурс можно на уровень выше вынести и сделать его уникальным. Только это иногда ведёт к тому, что ресурсы выносятся на самый верх. У region inference (для управления памятью) проблема с этим есть как раз, и решается как раз полумерами в виде счётчиков.
Ты на вопрос пожалуйста ответь.
А то у меня есть сомнения что разделяемые ресурсы вообще нужны.
Я вот что-то не могу вспомнить ни одного случая из моей практики когда был нужен разделяемый ресурс.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Не, понятно что всегда разделяемый ресурс можно на уровень выше вынести и сделать его уникальным. Только это иногда ведёт к тому, что ресурсы выносятся на самый верх. У region inference (для управления памятью) проблема с этим есть как раз, и решается как раз полумерами в виде счётчиков. WH>Ты на вопрос пожалуйста ответь.
К примеру, логгер пишущий в файл, который должен жить пока не закроется последняя ссылка на него.
Или случай, когда временем жизни управляет внешняя система (графическое окно, к примеру).
WH>А то у меня есть сомнения что разделяемые ресурсы вообще нужны. WH>Я вот что-то не могу вспомнить ни одного случая из моей практики когда был нужен разделяемый ресурс.
У меня есть примеры, но пока не могу придумать простой случай, где всё было бы понятно.
Здравствуйте, Cyberax, Вы писали:
C>К примеру, логгер пишущий в файл, который должен жить пока не закроется последняя ссылка на него.
Лично я давно пришел к выводу что временем жизни логера и ему подобных компонентов гораздо проще и надежнее управлять явно.
C>Или случай, когда временем жизни управляет внешняя система (графическое окно, к примеру).
Вот окно и будет жить в другом процессе (они у нас дешевые типа ерланговских) а с окном мы будет разговаривать через типизированный канал типа тех что в сингулярити.
В данном случае нашим ресурсов будет конец этого канала. Шарить его нет никакого смысла.
C>У меня есть примеры, но пока не могу придумать простой случай, где всё было бы понятно.
А может когда ты доведешь до состояния "все понятно" то будет понятно что никаких разделяемых ресурсов и не надо было?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>К примеру, логгер пишущий в файл, который должен жить пока не закроется последняя ссылка на него. WH>Лично я давно пришел к выводу что временем жизни логера и ему подобных компонентов гораздо проще и надежнее управлять явно.
Ну вот так оно и получается.
C>>Или случай, когда временем жизни управляет внешняя система (графическое окно, к примеру). WH>Вот окно и будет жить в другом процессе (они у нас дешевые типа ерланговских) а с окном мы будет разговаривать через типизированный канал типа тех что в сингулярити. WH>В данном случае нашим ресурсов будет конец этого канала. Шарить его нет никакого смысла.
А разница-то? Для твоего кода время жизни соединения с окном будет непредсказуемо. Особенно, если это не диалог, а основное окно приложения.
C>>У меня есть примеры, но пока не могу придумать простой случай, где всё было бы понятно. WH>А может когда ты доведешь до состояния "все понятно" то будет понятно что никаких разделяемых ресурсов и не надо было?
Они всё равно есть и будут, пока у нас есть реальный мир — он разделяемый между всеми.
Здравствуйте, Cyberax, Вы писали:
WH>>Лично я давно пришел к выводу что временем жизни логера и ему подобных компонентов гораздо проще и надежнее управлять явно. C>Ну вот так оно и получается.
А оно в любом случае именно так и получается.
Иначе свихнешься.
C>А разница-то? Для твоего кода время жизни соединения с окном будет непредсказуемо. Особенно, если это не диалог, а основное окно приложения.
Что значит не предсказуемо?
C>Они всё равно есть и будут, пока у нас есть реальный мир — он разделяемый между всеми.
Понеслась...
Твоя методика фигня по тому что есть случае которые туда не вписываются.
Какие?
Не скажу. Но они есть и твоя методика фигня.
Вот к этому у нас сводятся все разговоры.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Нет. Это о том что решение проблем неформальными механизмами это очень простой способ отстрелить себе голову.
Ну я про то и говорю. Неформальный механизм try/finally даже в сишарпе с лямбдам не является серебряной пулей.
WH>Продолжения вообще с детерминированной финализацией не совместимы.
Пока, как я понял, под этим ты понимаешь: "Продолжения несовместимы с зависимыми типами, которые гарантируют, что время владения ресурсом совпадает со временем использования".
Так вот я с этим не согласен.
WH>Просто в случае с uniqueness-типами ты получишь по голове во время компиляции, а в случае с try/finally во время исполнения.
Стоп. Способов получить по голове во время исполнения — вагон и маленькая тележка. Я так понял, мы тут обсуждаем способы не получить во время исполнения.
MC>>Но из этого только следует то, что компилятор должен знать о контунцациях. WH>Гм. А компилятор языка с продолжениями вообще может не знать о продолжениях? WH>Или даже так: Может ли компилятор языка не знать о какой бы то ни было фиче языка который он компилирует?
Зависит от того, как фича реализована. Континуации можно приделать, если произвести над кодом cps-преобразование до проверки типов и добавить в библиотеку функцию call/cc. Т.е. континуации типам будут ортогональны. А можно ввести примитивы shift и reset (для delimited continuations), а то и сам call/cc, о которых известно системе типов.
WH>О! Пошли ограничения.
А что ты хотел? Впихнуть садистскую систему типов в язык — и чтобы ничего не поменялось?
WH>delimited continuations действительно можно засунуть в ту часть программа которая не общается с внешним миром.
Ну по крайней мере не держит ссылок на ресурсы.
WH>Учти что придется под них наворачивать систему типов, а она если говорить о языке удобном для практического использования и так получается весьма кучерявой.
Ну это неспортивно. Сперва объявить, что некоторая система типов лучше других, а потом объявить, что некоторая фича Х не нужна, потому что в этой системе типов реализуется слишком сложно.
MC>>Также, я полагаю, в некоторых случаях можно доказать, что континуация, захваченная с call/cc вызывается не более одного раза. WH>А это уже получается корутина... совсем другой зверь.
Это может быть что угодно. Возможностью несколько раз вызывать континуацию не так уж часто приходится пользоваться.
Здравствуйте, WolfHound, Вы писали:
C>>Ну вот так оно и получается. WH>А оно в любом случае именно так и получается. WH>Иначе свихнешься.
А таки в С++ я могу использовать счётчик ссылок и всё ОК.
C>>А разница-то? Для твоего кода время жизни соединения с окном будет непредсказуемо. Особенно, если это не диалог, а основное окно приложения. WH>Что значит не предсказуемо?
Время жизни объекта не совпадает с лексическим диапазоном.
WH>Твоя методика фигня по тому что есть случае которые туда не вписываются. WH>Какие? WH>Не скажу. Но они есть и твоя методика фигня.
Ну вот, такой пример:
void someFunc(resource res1, resource res2)
{
window win=new window(res1, res2);
win.show();
window win2=new window(res1, res2);
win2.show();
//Окна продолжают жить дальше
}
unique resource res1;
unique resource res2;
someFunc(res1, res2);
Что произойдёт в этом случае с ресурсами?
Можешь представить окна как процессы, с которыми ты обмениваешься сообщениями — это тоже ничего не изменит. Тем более, что mutlithreaded GUI ещё ни у кого не получился на практике, слишком уж это сложная задача: http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
Здравствуйте, WolfHound, Вы писали:
WH>Вот к этому у нас сводятся все разговоры.
Дополню ещё. То что ты предлагаешь — это по-сути вариант region'ов без автоматического region inference.
Region inference изначально разрабатывался для автоматического управления памятью без классического GC (неудивительно, просто рассматриваем память как ресурс, который надо освободить). Очевидно, что добавив к выделяемым объектам деструктор — мы получим твою схему.
На практике, в OCaml'е с регионами и в Cyclon'е пришлось добавить refcounted-регионы, слабые ссылки и прочие аналоги С++-ности.
Здравствуйте, Cyberax, Вы писали:
C>А таки в С++ я могу использовать счётчик ссылок и всё ОК.
С логером ОК не будет. Это не та штука с которой можно так поступать.
C>Время жизни объекта не совпадает с лексическим диапазоном.
Ну так это тебе не С++ деструкторы. Примеры кода когда объект уходил далеко от того места где его создали я уже приводил в этой теме.
WH>>Твоя методика фигня по тому что есть случае которые туда не вписываются. WH>>Какие? WH>>Не скажу. Но они есть и твоя методика фигня. C>Ну вот, такой пример:
хъ C>Что произойдёт в этом случае с ресурсами?
Программа не скомпилируется.
Но ты опять придумал оторванный от реальности пример в котором нет никакой логики и пытаешься что-то доказать.
C>Можешь представить окна как процессы, с которыми ты обмениваешься сообщениями — это тоже ничего не изменит. Тем более, что mutlithreaded GUI ещё ни у кого не получился на практике, слишком уж это сложная задача: http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
А я и не собираюсь делать mutlithreaded. Я вообще считаю что mutlithreaded нужно искоренить ибо программисты него не понимают. Ага практически 100% не понимает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>А таки в С++ я могу использовать счётчик ссылок и всё ОК. WH>С логером ОК не будет. Это не та штука с которой можно так поступать.
Как раз будет ОК, так как логгер обычно "листовой" объект, и мала вероятность возникновения циклических ссылок.
C>>Ну вот, такой пример: WH>хъ C>>Что произойдёт в этом случае с ресурсами? WH>Программа не скомпилируется.
Я понимаю. Но как такое сделать?
WH>Но ты опять придумал оторванный от реальности пример в котором нет никакой логики и пытаешься что-то доказать.
Пример абсолютно жизненный — у меня есть два окна, в котором показываются два вида одного ресурса. Как быть? Это просто как раз случай, когда нужно реальное разделение ресурсов.
Или более другой пример — HTTP-сессия с данными. И клиент, который с ней работает из двух табов в браузере.
Вероятно, ты просто слишком много серверного кода писал, а там обычно с временем жизни как раз всё просто — оно привязано к времени жизни вызова.
Здравствуйте, Cyberax, Вы писали:
C>Как раз будет ОК, так как логгер обычно "листовой" объект, и мала вероятность возникновения циклических ссылок. Ссылки кончились, а через минуту он снова понадобился.
Что делать?
Геморрой все это. Логгер должен быть вечно живым.
C>Я понимаю. Но как такое сделать?
Сделать что? Передать один файл в два окна? Зачем на уровне ГУИ файл?
C>Пример абсолютно жизненный — у меня есть два окна, в котором показываются два вида одного ресурса. Как быть? Это просто как раз случай, когда нужно реальное разделение ресурсов.
Как ты собрался сокет в окне показывать?
C>Или более другой пример — HTTP-сессия с данными. И клиент, который с ней работает из двух табов в браузере.
Данные они и есть данные. Ими ГЦ рулит. Не понятно что ты тут вообще придумываешь.
C>Вероятно, ты просто слишком много серверного кода писал, а там обычно с временем жизни как раз всё просто — оно привязано к времени жизни вызова.
С временем жизни внешних ресурсов всегда все просто.
А если нет это значит косяк в дизайне.
Примеров обратного я не видел.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Как раз будет ОК, так как логгер обычно "листовой" объект, и мала вероятность возникновения циклических ссылок. WH> Ссылки кончились, а через минуту он снова понадобился.
Если он понадобиться, то на него будет ссылка.
WH>Что делать?
Ну заново создай, если уж совсем криво сделал.
WH>Геморрой все это. Логгер должен быть вечно живым.
Не-не. Вечноживые объекты — это статики в миниатюре. А они суть зло.
C>>Я понимаю. Но как такое сделать? WH>Сделать что? Передать один файл в два окна? Зачем на уровне ГУИ файл?
Ну не файл, а модель, привязанная к соединению в БД, в котором открыта транзакция.
C>>Пример абсолютно жизненный — у меня есть два окна, в котором показываются два вида одного ресурса. Как быть? Это просто как раз случай, когда нужно реальное разделение ресурсов. WH>Как ты собрался сокет в окне показывать?
См. выше.
C>>Или более другой пример — HTTP-сессия с данными. И клиент, который с ней работает из двух табов в браузере. WH>Данные они и есть данные. Ими ГЦ рулит. Не понятно что ты тут вообще придумываешь.
Ну представь, что там у тебя не просто данные.
C>>Вероятно, ты просто слишком много серверного кода писал, а там обычно с временем жизни как раз всё просто — оно привязано к времени жизни вызова. WH>С временем жизни внешних ресурсов всегда все просто. WH>А если нет это значит косяк в дизайне. WH>Примеров обратного я не видел.
Это не значит, что их нет.
Здравствуйте, Cyberax, Вы писали:
C>Ну не файл, а модель, привязанная к соединению в БД, в котором открыта транзакция.
Ахринеть! Ты это серьезно? Держать открытой транзакцию пока юзер чай пьет? Тебя где программы писать учили?
C>Ну представь, что там у тебя не просто данные.
Не могу.
Зачем сесии что-то кроме данных?
C>Это не значит, что их нет.
В науке принято доказывать существование.
Причем это должен сделать тот кто утверждает что что-то существует.
Вот и доказывай.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Ну не файл, а модель, привязанная к соединению в БД, в котором открыта транзакция. WH>Ахринеть! Ты это серьезно? Держать открытой транзакцию пока юзер чай пьет? Тебя где программы писать учили?
А почему бы и нет?
Hint: оптимистические транзакции ещё никто не отменял.
C>>Ну представь, что там у тебя не просто данные. WH>Не могу. WH>Зачем сесии что-то кроме данных?
А просто так.
C>>Это не значит, что их нет. WH>В науке принято доказывать существование. WH>Причем это должен сделать тот кто утверждает что что-то существует. WH>Вот и доказывай.
Я тебе привёл пример.
Здравствуйте, Cyberax, Вы писали:
C>А почему бы и нет? C>Hint: оптимистические транзакции ещё никто не отменял.
Мы наверное очень разный софт разрабатываем.
Лично я считаю длинные транзакции очень серьезной кривью.
C>А просто так.
Понятно. Значит не надо.
WH>>Вот и доказывай. C>Я тебе привёл пример.
Где? Там все либо совсем левое либо откровенные косяки.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>А почему бы и нет? C>>Hint: оптимистические транзакции ещё никто не отменял. WH>Мы наверное очень разный софт разрабатываем.
Как ты догадался?
WH>Лично я считаю длинные транзакции очень серьезной кривью.
Они кривы в общем случае. В частных случаях зато иногда полезны.
Я по этому поводу всё хочу написать в "Архитектуру"...
WH>>>Вот и доказывай. C>>Я тебе привёл пример. WH>Где? Там все либо совсем левое либо откровенные косяки.
Ну так то что не укладывается в твою модель — у тебя по определению косяк. Это, конечно, классный подход.
Ссылки кончились, а через минуту он снова понадобился.