Андрей Хропов,
VD>>>Дело в том, что единственное в чем имеет приемущетсво Эрлэнг — это в том, что его упрощенный контекст очень мал.
LCR>>Нет, это отнюдь не единственное преимущество. Ты забыл о ещё нескольких не менее важных вещах: LCR>>1. real-time ограничения на приём и посылку сообщения АХ>То есть? А в библиотеке это сделать нельзя?
Нужен рантайм и тесное взаимодействие языка с рантаймом. Ни в distel, ни в скале этого даже близко нет.
LCR>>2. сверхбыстрый GC АХ>Это как это он сверхбыстрый . Ну и ссылку дай, подтверждающую это. АХ>Программы на Эрланге далеко не сверхбыстрые, в случае если они делают еще что-то кроме посылки-приема сообщений.
gc в Эрланге не делает того, что другие вынуждены делать. Плюс гарантии.
LCR>>3. selective receive АХ>Что это? Почему это нельзя сделать библиотекой?
Можно, но будет медленно, и опять же никаких гарантий.
LCR>>4. интеллектуальный шедулер АХ> А остальные шедулеры у нас неинтеллектуальны?
Эпитет не тот. На самом деле он просто обеспечивает гарантии того, что если процессу нужно управление в течение таймфрейма, то он его получит. С вероятностью 0.99.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Только не надо создавать впечатления, что для создания клона Эрланг VM достаточно наваять минипоточки и посыпать это дело сахарком. Это совсем не так.
Ну так аргументируй убедительно почему это не так. Пока я только список buzzwordов увидел.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Андрей Хропов,
VD>>>>Дело в том, что единственное в чем имеет приемущетсво Эрлэнг — это в том, что его упрощенный контекст очень мал.
LCR>>>Нет, это отнюдь не единственное преимущество. Ты забыл о ещё нескольких не менее важных вещах: LCR>>>1. real-time ограничения на приём и посылку сообщения АХ>>То есть? А в библиотеке это сделать нельзя? LCR>Нужен рантайм и тесное взаимодействие языка с рантаймом. Ни в distel, ни в скале этого даже близко нет.
LCR>gc в Эрланге не делает того, что другие вынуждены делать. Плюс гарантии.
Например?
LCR>>>3. selective receive АХ>>Что это? Почему это нельзя сделать библиотекой? LCR>Можно, но будет медленно, и опять же никаких гарантий.
Почему обязательно медленно? Почему никаких гарантий? Это уж тогда можно сказать что Эрланг не дает никаких гарантий поскольку он динамически типизирован.
В конце концов рантайм Эрланга написан на C, значит на всем что по скорости далеко не ушло от C можно сделать и не слишком медленно.
LCR>>>4. интеллектуальный шедулер АХ>> А остальные шедулеры у нас неинтеллектуальны? LCR>Эпитет не тот. На самом деле он просто обеспечивает гарантии того, что если процессу нужно управление в течение таймфрейма, то он его получит. С вероятностью 0.99.
А остальные шедулеры что нельзя такими сделать?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Андрей, извини. Развёрнутый ответ я постараюсь дать позже (на этой неделе).
Ну сегодня последний день недели . Да на самом деле достаточно дать ссылки (если таковые существуют), подтверждающих твои слова хотя бы частично.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Эпитет не тот. На самом деле он просто обеспечивает гарантии того, что если процессу нужно управление в течение таймфрейма, то он его получит. С вероятностью 0.99.
Гарантия с вероятностью — это супер!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Но, поскольку Nemerle не позволяет разруливать конфликты имен синтаксических макросов, то решил, что толку от них будет не так уж много. Внешний DSL и pre-compile-time генерация дают гораздо больше свободы и возможностей.
конфликты имён?????????
а namespace-ы по-твоему на макросы не действуют???
VD>>>1. Для распараллеливания вычислений современными средствами (то есть потоками ОС) необходимо прикладывать много усилий.
PI>>в каком смысле много?
VD>В смысле писать много кода в котором можно сделать много ошибок.
не согласен, особенно в свете async-макроса в Немерле
VD> Держать очень много мелких условий в голове (синхронизация, модель взаимодействия...). Много сил тратить на отладку, так как оталадка многопоточных приложений совершенно не продумана.
согласен
как по-твоему, какую модель нужно взять для параллельной немерле-библиотеки, для упрощения этих делов?
VD>>>2. Явное разделение задач на подзадачи и организация фрэймворков позволяющих бесшовно связывать эти параллельные задачи.
PI>>и такой вопрос, нельзя ли фреймворк (библиотеку) построить, которая позволяла бы быстро переключаться между 2 моделями (на псевдопараллелизме/потоках/участниках кластера)?
VD>Первая модель должна поддерживаться компилятором. Вторая реализуема в виде библиотеки или фрэймворка. Переключаться между ними не то что бы нельзя, а попросту не надо.
не согласен
вот есть у меня какие-то вычисления, завязанные на потоках, но на 1 компе
и тут у меня появляется доступ к сетке из компов... конечно я хочу быстро переключиться на модель "кластер"
классический пример — рендеринг 3д-сцен
VD> В рамках второй модели можно применять первую.
PI>>я думаю, тут лучше прыгунов в высоту представлять... PI>>тренируются, соревнуются... PI>>бежит такой прыгун "джава", прыг — 1.75 PI>>бежит прыгун "дотнет", прыг — 2.10 PI>>...и тут такой красавец... с шестом...
ANS>Дисквалификация, однако. Просто с шестом на другой дорожке прыгают.
а у нас у всех один путь однако
и планки одни и те же
просто кто-то одни высоты берёт, а кто-то большие
лирическое отступление
умные немцы в 30х годах изобрели велосипед лежачего типа (видели, думаю, по телеку)
и на олимпиаде взяли все призы в разделе "велосипедизм", т.к. эти лисапеды реально быстрее обычных
естественно, олимпийский комитет запретил использование этих великов на олимпиаде после этого случая
Здравствуйте, eao197, Вы писали:
PI>> конфликты имён????????? PI>> а namespace-ы по-твоему на макросы не действуют???
E>После того как сделали using и на синтаксические макросы (которые объявляются с помощью syntax), как мне тогда объяснили, не действуют.
не знаю, что тебе наговорили, а я только что проверил (я ж с ума ещё не сошёл, вроде)
синтаксические макросы без импорта ихнего пространства имён (using-a) не работают
PI>>на самом деле, Nemerle — это хороший такой пинок под зад Билли PI>>а чё, пусть шевелит булками быстрее...
ANS>Ты до сих пор не понял, что качество языка никакого отношения к его распространённости не имеет?
вообще-то, есть
1. мнение любителей малораспространённых языков:
наш язык лучше всех, остальные просто тупы, чтобы понять это
2. мнение прагматичного, но тем не менее, умного девелоперского люда:
если язык недостаточно распорстранён, то он недостаточно качественен
Немерле — недостаточно качественен, да: на данный момент:
— нет WindowsForms-дизайнера
— нет поддержки рефакторинга
— нет ASP.NET-поддержки (и пока не предвидится)
— интеграционная среда глючит
— не продемонстрировано ни одного killer-application-а, нет testimonial-ов
а считать всех подряд программеров тупыми — плохое качество программирующих на "экзотике"
лучше считать, что глупые программеры к программерам не относятся вообще
Здравствуйте, PhantomIvan, Вы писали:
PI>не знаю, что тебе наговорили, а я только что проверил (я ж с ума ещё не сошёл, вроде) PI>синтаксические макросы без импорта ихнего пространства имён (using-a) не работают
Смотри, есть две библиотеки: sobjectizer и smtp. Делаем для обоих using-и. В обоих библиотеках есть синтасические макросы с именами agent, message, subscribe. Мне нужно сделать агента SObjectizer, который одновремено является MTA агентом. Приходится в одной области видимости использовать ключевые слова agent и message для разных целей.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ты до сих пор не понял, что качество языка никакого отношения к его распространённости не имеет?
Имеет, но не прямое. Существуют еще такие факторы как качество реализации компилятора и VM (если она нужна), маркетинг, объем, документированность и качество стандартной библиотеки. В конце концов этому языку должно быть просто научится, а для этого должны быть туториалы, книжки, курсы, в самом лучшем случае (для языка) ему обучают в школах и университетах.
А также часто нужны достаточно весомые аргументы для перехода с другого языка.
PI>>не знаю, что тебе наговорили, а я только что проверил (я ж с ума ещё не сошёл, вроде) PI>>синтаксические макросы без импорта ихнего пространства имён (using-a) не работают
E>Смотри, есть две библиотеки: sobjectizer и smtp. Делаем для обоих using-и. В обоих библиотеках есть синтасические макросы с именами agent, message, subscribe. Мне нужно сделать агента SObjectizer, который одновремено является MTA агентом. Приходится в одной области видимости использовать ключевые слова agent и message для разных целей.
ага, то есть юзер использует оба неймспейса в одном и том же файле, я понял
советую:
— разнести смтп-логику и агентную логику в разные файлы
— учесть, что using (открытие пространства имен) можно делать не в самой шапке файла, а после объявления своего namespace-а
— можно обратится к любому макросу, не используя кейворд, а используя его полное имя (при этом нельзя использовать синтаксис, а придется наставить скобок — подобно вызову функции, это позволяет сделать любой макрос)
— и наконец, юзер может обернуть макрос в свою макросную обертку и назвать его как хочет, если уж конечно, хочется использовать оба синтаксиса...
зы. честно говоря, это всё разговоры о сферическом коне
тем более, твой с++ -ный подход заведомо проигрывает немерле-вскому (как видно по названию — SObjectizer) гыгы
Здравствуйте, Сергей, Вы писали:
VD>>Не бери пример с еао197 и ему подобных. Не квоть сообщения до потери смысла и не на летай на выдранные из контекста слова.
С>Влад, а это-то ты зачем написал?
Народ должен знать своих демагогов в лицо.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Ага, но это уже не list comprehension.
ЗХ>Код достаточно близок ко второму варианту на Хаскеле. ЗХ>ы?
Ага. Но не list comprehension.
ЗХ>Ну, понятно, что sort, это, конечно, не вполне уже list comprehension — но в парадигме остаемся той же. Может быть, корректнее обозвать этот вариант "использование генераторов", а не "использование компрехенсионов".
Не, не той же. Ты используешь не list comprehension, а тот факт, что функция в языке является первокласной сущьностью. Короче ты используешь не сахар языка, а функциональный подход. Именно так и усроен ЛИНКС. Толко в нем еще и сахар есть который лишние скобочки убирает и причесывает все.
ЗХ>Впрочем, если у Фила Вадлера хватает наглости называть свою версию на Links "list comprehension" (Фил Вадлер — таки ж один из создателей Хаскеля), то почему мне нельзя?
Я не знаю у кого на что наглости хватает. Но в Лиспе аналог был уже очень давно и называлось это query comprehension.
ЗХ>ЗЫ: хотя, понятное дело, спор о терминологии — самый идиотский и безнадежный вид дискуссии
Есть немного.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.