Здравствуйте, PhantomIvan, Вы писали:
PI>пролистнул описание — аппетитно с виду PI>надо будет как-нибудь для Немерле подобную макробиблиотеку придумать
Такую — не надо. Если вдруг будет нечем заняться лучше реализуй EBNF-нотацию. Она читается лучше и мощьнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, raskin, Вы писали:
R>Многие действия по обработке текста и общению с R>системой на нём в три раза короче при той же читаемости.
Короче? Мозможно. А на счет читабельности я сильно поспорю.
А так как короче она исключительно из-за наличия готовых утилит которые без проблем переводятся в классы или функции, то приемущество это очень гипотетическое.
R> Да, две строчки R>вместо семи более коротких, но писать обвязки больше, чем кода, всё R>равно не хочется. Да и сделаны "библиотеки" под конкретную задачу, из-за R>чего повышается уровень.
Обвязка пишется один раз. А вот если у тебя мощьности скрипта не хватает (у меня такие случаи были). То ты быстренько бежишь писать скрипты или полноценные программы на чем-то еще.
R>И трудно предположить, что писать даже экран кода в REPL, имея R>completion, хуже, чем в компилируемом языке.
Значит плохое воображение. Комплейшон то у компилируемого яыка по круче будет. С подсказками, рефактроингом и т.п. Плюс банально гибче.
Вот как-то понадобился нам бинарный diff. Перепробывали тонну всего. Но файлы размером более 4 гиг. Все что нашли банально падало. Ну и чем дело кончилось? Нашли исходник дифа на Яве. Переписали по человечески на Шарпе и используем для создания дифа бэкапа БД на РСДН вот уже два года.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Влад, ты пытаешься говорить о параллельности не беря в расчёт характер решаемой задачи совсем? Несколько странный подход
Конкретной конечнь нет. Это бред полнейший был бы. Но требования я учитываю. Читай внимательнее.
К>Т.е. всё сошлось на многопроцессорности?
А ты залешь за несколько сообщений вверх и погляди с чем я там несоглашался.
К>В данной задаче узким местом может оказаться, конечно пересылка сообщений
Ага. С вероятностью 99%.
К>(если массив достаточно большой),
А иначе смысла параллелить нет. Просто переключение контекста займет больше времени, а там еще накладных расходов море.
К> но никто и не позиционирует Эрланг как числодробилку или инструмент для обработки данных заметного объёма.
Вокруг Эрлэнга разные болоболы с РСДН пытаются создать ореол волшебности. Если их послушать, то это вообще мега-средсво. Само параллелит, все паралеллит (астралябия... все меряет... сама меряет...).
Меж тем это решение для конкретных задач.
К>Но в Немерле/Скале нет OTP, поэтому для массовой параллелизации Эрланг вещь заметно более подходящая.
Да, да. Нет ОТР, ЁПРСТ и еще ЁКЛМН. Жуть просто.
Жаль ЁПРСТ не делает из фрэймворка панацею. А то испоьзование разных базвордов и првда помоглао бы решать любые задачи.
VD>>Вы оба не правы. Эрлэнг хорош не тем что он куруто распараллеливает выполнение на разных процессорах. Эрлэнг крут своей моделью паралеллизма. Он обеспечивает автоматическое и безконфликтное распараллеливание. Это позволяет выполнять (псевдо) параллельно множество нерисорсоемких задач. При этом мы избавлены от необходимости думать о синхронизации. Но за это мы платим разбиением алгоритма на отдельные процессы и обязаны обемниваться данными между ними с помощью сообщений. Такой подход очень хорош когда надо обеспечить отклик множеству параллельных клиентов. Но практически ничего не дает в алгоритмическом плане.
К>Блин, кто говорил про выполнение на разных процессорах?
Блин, ты, ТЫ и сказал. И не раз еще повторл. Задолбал ежу. Цитирую этот ... последний раз:
Нет там потоков.
В том весь и смысл, что параллельность получается не на потоках ОС, т.е. нет постоянных переключений контекста, что позволяет ускорить работу приложения (при наличии нескольких процессов).
К>Речь шла именно о паралеллизме и как раз о множетве задач.
Ну, да? Да, ну? Видимо я читать разучился. В отличии от трепа в жизни тут все ходы записываются. Поднимись на несколько сообщений вверх и почитай что писал.
К> Эрланг далеко не серебрянная пуля,
Ну, салава богу происходит протрезвление. Осталось еще научитсья осмысленные термины использвать вроде панацеи, а не эту дебильную алегорию.
К> но в своей нише он даёт очень хорошие преимущества, но платить приходится именно другим подходом к реализации решения задачи.
Да не дает он сам по себе ничего. Обмен сообщениями для корпоративных нужд был давно реализован в куче серверов. Используется из разных мест. Если говорить о распараллеливание, то опять же куча ограничений. Устойчивость к сбокя? Надженость? Ну, ну, давай померяем пенис с тем же MSMQ который обеспечивает транзакционность в распределенной среде и гарантированную доставку сообщений. Производительность? Идем курить то же решение из Oz. Да и опять таки производительность чего? Вроучную всегда моно создать более шустрое решение. В концео концов Эрлэнг интерпретатор.
В общем, не надо обожествлять техническое решение. Оно от этого менее ценным становится. Эрлэнг предоставляет интересную модель вычислений пригодную во многих случаях. Причем это не чисто научное ислледование, а уже работающих продукт. Этим он и хорош. Никаких сверестественных способностей он не имеет. Модель эту можно воспроизвести и в универсальных языках. О чем сами авторы и говорят.
В общем, удивительно, что авторы любопытных технологий намного более адекватны, чем фанатичные поклонники оных.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Работает, правда поддержку добавили не так давно Но можно было с лёгкостью запустить несколько инстансов ВМ эрланга на разных процах, если ОС это поддерживает. Возможно накладные расходы на пересылку сообщений были бы побольше, конкретики не знаю, не скажу. Сижу на однопроцессорном селероне
Думаю тебя удивит, что передача сообщений между процессами работающими на разных камнях тоже будет медленее нежели в рамках псевда-параллельных).
Меж тем все элементарно. Физически данные это память. Передать ее процессору нельзя. Это процессор к ней может обращаться. А раз к памяти могут обращаться сразу два процессора, то нужна синхронизация. Функциональная природа языка уберегает от сериализации данных, но чтобы записать что-то в очередь нужно хотя бы итерлокед-функцию вызвать. Ну, а межпроцессное (в терминах ОС) взаимодействие вообще в сотни или даже тысчи раз медленее.
PI>>потому что я когда говорю о параллельности, я понимаю несколько ядер/процессоров К>Т.е. многозадачность не считается уже совсем? К>Скажем вебсервер на однопроцессорной системе без гипертрединга уже параллельно запросы обслуживать не может?
Строго говоря нет. Он будет выполнять их последовательно с переключением. Ускорения это не даст. Скорее замедлит. Если обработка короткая, то по любому лучше ее последовательно организовать. Псевда-параллилизм дает ложное ощущение быстроты. Реально же все работает медленее. Быстрее только отклик. Для многих задач отклик важен. Для того же веб-сервера — нет. Ему проще в очередь запросы ставить и по одному разгребать.
К>Я понимаю, что будущее за многопроцессорностью, но всёже многозадачность всёже играет значительную роль.
Тут нехилая игра слов получается. Потому и путаются многие. Ты же сам всех и путашь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PhantomIvan, Вы писали:
PI>не согласен, особенно в свете async-макроса в Немерле
Макросы как раз и пытаются пуростить решение задачи. Под традиционным я понимаю разные fork-и и CerateThread-ы. Но конкрено эти делают это не лучшим образом.
PI>как по-твоему, какую модель нужно взять для параллельной немерле-библиотеки, для упрощения этих делов?
Я уже сказал, что первый подход в библиотеку не положишь. В макрос с большим турдом.
Да и цели у них разные. IT тут
очень правильно сказал.
PI>не согласен PI>вот есть у меня какие-то вычисления, завязанные на потоках, но на 1 компе PI>и тут у меня появляется доступ к сетке из компов... конечно я хочу быстро переключиться на модель "кластер" PI>классический пример — рендеринг 3д-сцен
Рендеринг 3Д-сцен на сегодня распараллеливается врнучную. Фрэймворк второго типа поможет тебе только упростить разнесение уже внучную распараллелиных задач на разные машины в сети. Но чтобы действительно параллилить автоматом вычисления унжно куда как более сложные средства. По сравнению с ним фрэймворки обмена сообщениями просто детство.
VD>> В рамках второй модели можно применять первую.
PI>итого, какой вывод?
Никакого. Есть две модели с разными целями, разными проблемами и разными побочными эффектами. Где-то хороша одна, где-то другая, а где-то их можно совмещать.
Эрлэнг и его модель — это одна из возможных реализаций. Еще есть тонны эксперментов и когда-то они выродятся в красивую и стройную концепцию. Но пока что все на уровен слов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PI>>итого, какой вывод?
VD>Никакого. Есть две модели с разными целями, разными проблемами и разными побочными эффектами. Где-то хороша одна, где-то другая, а где-то их можно совмещать.
а если упростить, и говорить исключительно о вычислениях
без требования автоматического распараллеливания (эту проблему решает пользователь)
но с требованием максимально использовать все типы ресурсов (ядра, процессоры, участники кластера)
TBG>>Это где комплита нет? Везде же уже есть.
VD>И параметры комплитит? И контекстую помощь для них показывает? Значит прогресс в командных строках ушел далеко вперед...
надо изучить апи к юниксовским командным строкам, и переписать интеграцию на них
PI>>пролистнул описание — аппетитно с виду PI>>надо будет как-нибудь для Немерле подобную макробиблиотеку придумать
VD>Такую — не надо. Если вдруг будет нечем заняться лучше реализуй EBNF-нотацию. Она читается лучше и мощьнее.
к сожалению, профан в этих вопросах
насущной проблемы нет, поэтому в ближайший год даже изучать подробно этот момент не буду
(на ближайший год, скажем так, есть чем заняться)
но что ты имеешь в виду под реализуй EBNF-нотацию? как с помощью неё можно матчи искать? или ты что-то другое имеешь в виду?
VladD2 wrote: > R>Многие действия по обработке текста и общению с > R>системой на нём в три раза короче при той же читаемости. > > Короче? Мозможно. А на счет читабельности я сильно поспорю.
Гм, pipe читается лучше явного буфера. if-then-fi выносит if(){} по
читаемости.. А regexp где ни используй — одинаково. Простые regexp читаемы.
> А так как короче она исключительно из-за наличия готовых утилит которые > без проблем переводятся в классы или функции, то приемущество это очень > гипотетическое.
Скорее, гипотетически это не преимущество, а вот все ныне заметные
языки, использующие эти термины — скриптовые. Ну или LISP, который
иногда компилируется, и в котором, вроде, есть with-input-from-file. К
чему бы это?
> R> Да, две строчки > R>вместо семи более коротких, но писать обвязки больше, чем кода, всё > R>равно не хочется. Да и сделаны "библиотеки" под конкретную задачу, из-за > R>чего повышается уровень. > > Обвязка пишется один раз. А вот если у тебя мощьности скрипта не хватает
А потом копируется, а потом выясняется, что чуть не подходит. Да, open
во всех проявлениях — тоже иногда, скорее, обвязка.
> (у меня такие случаи были). То ты быстренько бежишь писать скрипты или > полноценные программы на чем-то еще.
Пишу тот кусок, который не делается на Паскаль и легко вставляю в
скрипт, остальная логика — остаётся пока на скрипте. Но это если резко
поменялась задача, если надо исходно писать на другом языке — это видно.
По требованиям к скорости или функциональности.
> R>И трудно предположить, что писать даже экран кода в REPL, имея > R>completion, хуже, чем в компилируемом языке. > > Значит плохое воображение. Комплейшон то у компилируемого яыка по круче > будет. С подсказками, рефактроингом и т.п. Плюс банально гибче.
Рефакторинг — на одном экране кода? А подсказки.. Напомню, что кода
экран. И просто скопировать имя функции мышью — не проблема. И дело в
REPL. То есть подсказки учитывают run-time ситуацию, включая файлы на диске.
> Вот как-то понадобился нам бинарный diff. Перепробывали тонну всего. Но > файлы размером более 4 гиг. Все что нашли банально падало. Ну и чем дело > кончилось? Нашли исходник дифа на Яве. Переписали по человечески на > Шарпе и используем для создания дифа бэкапа БД на РСДН вот уже два года.
Ну так у вас были требования по производительности... Я не отрицаю, что
у shell — ограниченная ниша.
Здравствуйте, VladD2, Вы писали:
TBG>>Это где комплита нет? Везде же уже есть.
VD>И параметры комплитит? И контекстую помощь для них показывает? Значит прогресс в командных строках ушел далеко вперед...
5 лет назад (когда это было мне актуально) zsh умел.
Например пишем kill жмём tab он выводит список процессов, если ввели начало pid'а, то он фильтровал соответственно.
Там была инфрастуктура позволяющая вкрутить эту функциональность для произвольной команды.
Но учитывая, что она была реализована для очень малого числа команд (на тот момент) делаю вывод, что это почти никому не надо.
И вообще есть масса вещей, которые гораздо эффективней (по скорости и наглядности результата) делать в правильной коммандной строке, как бы дико это не звучало для человека, который хорошо знаком только с Windows.
VladD2 wrote: > TBG>Это где комплита нет? Везде же уже есть. > > И параметры комплитит? И контекстую помощь для них показывает? Значит
Completion и показ подсказок — в соответствии с выводом --help . Если
команда в списке "признающих ключ --help". > прогресс в командных строках ушел далеко вперед...
И давно ушёл.. Просто не все это ставят и включают (никаких
сложных/длительных действий не надо), поэтому это не так известно.
Здравствуйте, IT, Вы писали:
IT>Если у тебя есть рецепты как сделать язык распространённым, то мы с удовольствием их выслушаем.
Вопрос к тебе как к автору BLToolkit.
Позволяет ли Nemerle сделать всё статически то, что делается линамически в BLToolkit?
По описаниям возможностей макросов мне показалось что да.
Возможно ли создать некий framework в котором можно было бы описывать модель данных и способ её отбражения на БД (что-то другое), чтобы это потом компилировалось в CLS совместимую сборку? Чтобы код маппинга создавался статически, чтобы в отладчике легко можно было исследовать, что там нагенерилось? Если да, то есть ли у такого подхода какие-то преимущества перед тем, что реализован в BLToolkit (помимо устранения накладных расходов на кодогенерацию времени выполнения)? Есть ли какие-то специфичные для Nemerle выразительные языковые возможности которые могуть выдыинуть Nemerle вперёд в решении этой задачи?
raskin wrote: >> Тут точно так же — Немерль нормально работает на всех системах, при >> условии, что эта система — Windows. > Да нет, утверждению, что один из разработчиков работает с Nemerle под > Mono на GNU/Linux можно поверить.
Так я с этим не спорю.
Я спорю с утверждением, что вся система .NET достаточно
кросс-платформенна. В реальности программы для .NET не работают в
Mono/DotGNU, а программы для Mono (тот же MonoDevelop) не работают в .NET.
Надо сказать, что с Java такого безобразия меньше.
Cyberax wrote: >>> Тут точно так же — Немерль нормально работает на всех системах, при >>> условии, что эта система — Windows. >> Да нет, утверждению, что один из разработчиков работает с Nemerle под >> Mono на GNU/Linux можно поверить. > Так я с этим не спорю.
> Я спорю с утверждением, что вся система .NET достаточно > кросс-платформенна. В реальности программы для .NET не работают в
Но зачем было брать чуть ли не единственный пример, который работает и
там, и там? Или это опечатка?
> Mono/DotGNU, а программы для Mono (тот же MonoDevelop) не работают в .NET.
Легко.
> Надо сказать, что с Java такого безобразия меньше.
Не знаю. Но не знаю ни одного примера java-программы, которая работала
бы по-разному под Windows и под GNU/Linux...
Андрей Хропов wrote: > LCR>1. real-time ограничения на приём и посылку сообщения > То есть? А в библиотеке это сделать нельзя?
Нет. Сама платформа не-realtime.
> LCR>2. сверхбыстрый GC > Это как это он сверхбыстрый . Ну и ссылку дай, подтверждающую это.
Более того, он еще и real-time (хотя и soft).
Там используется generational gc, но за счет того, что объекты в старом
поколении иммутабельны, избегается самая сложная проблема в дизайне
generational GC — ссылки из старого поколения в новое. Нам уже не нужны
card-marking таблицы или игры с виртуальной памятью.
Андрей Хропов wrote: > C>Тут точно так же — Немерль нормально работает на всех системах, при > C>условии, что эта система — Windows. > Сколько раз можно повторять что авторы пишут компилятор Немерле на > Линукс с Моно и лишь проверяют его под MS.NET.
Сколько раз можно повторять, что сам по себе язык нафиг никому не нужен?
Программы на .NET де-факто некроссплатформенны по большей части.
RSDN@Home, MonoDevelop и Beagle служат этому замечательным примером.
Андрей Хропов wrote: > LCR>gc в Эрланге не делает того, что другие вынуждены делать. Плюс гарантии. > Например?
Об этом можно со мной пофлеймить.
> LCR>>>3. selective receive > АХ>>Что это? Почему это нельзя сделать библиотекой? > LCR>Можно, но будет медленно, и опять же никаких гарантий. > Почему обязательно медленно? Почему никаких гарантий? Это уж тогда можно > сказать что Эрланг не дает никаких гарантий поскольку он динамически > типизирован.
Для мутирующих языков для GC _очень_ сложно дать точные гарантии для
произвольного случая. Я бы даже сказал, что невозможно — даже для
two-space копирующего GC (то есть у нас есть куча, она заполняется с
одной стороны, затем на другую сторону копируют живые объекты и начинают
рост в другую сторону) с резервом свободного места в 100% можно подбрать
режим, в котором он не будет успевать за мутатором (кодом, выполняющем
полезную работу).
А realtime generational GC мне вообще сложно представить.
Для Erlang'а при желании можно вообще сделать hard-realtime GC —
достаточно взять счетчик ссылок с deferred-удалением.
Если нам не помогут, то мы тоже никого не пощадим.
