raskin wrote:
>> Я спорю с утверждением, что вся система .NET достаточно
>> кросс-платформенна. В реальности программы для .NET не работают в
> Но зачем было брать чуть ли не единственный пример, который работает и
> там, и там? Или это опечатка?
Это ты про Beagle или RSDN@Home?

>> Mono/DotGNU, а программы для Mono (тот же MonoDevelop) не работают в .NET.
> Легко.
Не легко — только недавно заработал. После того, как портировали GTKшные
либы.

Cyberax wrote:
>>> Я спорю с утверждением, что вся система .NET достаточно
>>> кросс-платформенна. В реальности программы для .NET не работают в
>> Но зачем было брать чуть ли не единственный пример, который работает и
>> там, и там? Или это опечатка?
> Это ты про Beagle или RSDN@Home?
А кто из них на Nemerle?

>>> Mono/DotGNU, а программы для Mono (тот же MonoDevelop) не работают в .NET.
>> Легко.
> Не легко — только недавно заработал. После того, как портировали GTKшные
> либы.
Я имел в виду "Легко ведут себя именно так, как Вы написали". Впрочем,
портирование Gtk было весьма вероятным событием. Но это не помешает
сломаться чему-нибудь ещё. Вон VS, как утверждают, может сломаться под
Vista, куда там сторонним разработчикам угадать, что втихую изменили...

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

PI>но что ты имеешь в виду под реализуй EBNF-нотацию? как с помощью неё можно матчи искать? или ты что-то другое имеешь в виду?

Регекспы — это наиболее убогий вид регулярных грамматик. BNF — это форма Бэкуса/Науэра описания контекстно свободных грамматик. Регулярные грамматики — это подкласс контекстно свободных грамматик. EBNF — это расширенный (extended) BNF. BNF расширенный некоторыми полезными вещами. Например на регексах описание строки будет выглядеть так:

"(\\"|[^"])"

а на EBNF так:

strChars   = ANY - '"';
strLiteral = '"' (strChars | '\"') '"';

В отличии от регулярных грамматик контекстно свободные (КС) могут иметь рекурсивные правила. Ну, и вообще правила. Рабиение описания грамматики на правила само по себе позволяет разбить сложную задачу на подзадачи и повторно использовать описания.

В приципе КС описывают очень большой класс грамматик. Но для парсинга используют их подмножества. Например, леворекурсивные грамматики которые можно парсить методом рекурсивного спуска. Или праворекурсивные грамматики которые можно парсить путем построения магазинного автомата. Регулярные же грамматики парсятся с помощью ДКА.

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

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

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

Забавный вывод. С тем же успехом можно сделать вывод, что сами командные строки никому не нужны.

EC>И вообще есть масса вещей, которые гораздо эффективней (по скорости и наглядности результата) делать в правильной коммандной строке, как бы дико это не звучало для человека, который хорошо знаком только с Windows.

Если скрипт прост, то я и под виндовс наверно остановлюсь на cmd. Но если сложный, то где угодно предпочту полноценный язык.

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

PI>какой тогда вывод?

Такой — ты не понял моих слов.

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

EC>Вопрос к тебе как к автору BLToolkit.
EC>Позволяет ли Nemerle сделать всё статически то, что делается линамически в BLToolkit?

Позволяет на 100%.

EC>По описаниям возможностей макросов мне показалось что да.
EC>Возможно ли создать некий framework в котором можно было бы описывать модель данных и способ её отбражения на БД (что-то другое), чтобы это потом компилировалось в CLS совместимую сборку?

Можно.

EC>Чтобы код маппинга создавался статически,

Это, конечно, очень жёсткое ограничение, но можно.

EC>чтобы в отладчике легко можно было исследовать, что там нагенерилось?

Влад обсуждал это с компиляторщиками и похоже какое-то решение для этого существует. Правда я не уверен в том, что оно уже реализовано.

EC>Если да, то есть ли у такого подхода какие-то преимущества перед тем, что реализован в BLToolkit (помимо устранения накладных расходов на кодогенерацию времени выполнения)?

Дело в том, что всё то, что генерирует BLToolkit может быть писано руками. Т.е. мы имеем просто автоматизацию рутинных операций. Макросы, в принципе, позволяют делать тоже самое. Из преимуществ следует отметить, что уйдёт необходимость использования абстрактных классов и все неудобства связанные с этим.

EC>Есть ли какие-то специфичные для Nemerle выразительные языковые возможности которые могуть выдыинуть Nemerle вперёд в решении этой задачи?

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

raskin wrote:
>> Это ты про Beagle или RSDN@Home?
> А кто из них на Nemerle?
Они на CLI — а это важно.

>> Не легко — только недавно заработал. После того, как портировали GTKшные
>> либы.
> Я имел в виду "Легко ведут себя именно так, как Вы написали". Впрочем,
> портирование Gtk было весьма вероятным событием. Но это не помешает
> сломаться чему-нибудь ещё. Вон VS, как утверждают, может сломаться под
> Vista, куда там сторонним разработчикам угадать, что втихую изменили...
Ну так в этом-то и проблема.

Для .NET нет спеков или де-факто спецификаций (aka "исходник").

Cyberax wrote:
>>> Это ты про Beagle или RSDN@Home?
>> А кто из них на Nemerle?
> Они на CLI — а это важно.

На что я отвечал:
C> Немерль нормально работает на всех системах, при
C> условии, что эта система — Windows.

Я не говорил, что .NET хорошо подходит для кросс-платформенного
программирования. Я говорил только про то, что Немерле авторы пишут не
под Windows.

>>> Не легко — только недавно заработал. После того, как портировали GTKшные
>>> либы.
>> Я имел в виду "Легко ведут себя именно так, как Вы написали". Впрочем,
>> портирование Gtk было весьма вероятным событием. Но это не помешает
>> сломаться чему-нибудь ещё. Вон VS, как утверждают, может сломаться под
>> Vista, куда там сторонним разработчикам угадать, что втихую изменили...
> Ну так в этом-то и проблема.
Я не спорю. Но компилятору даже окон создавать не надо. Жизненно
необходима только самая базовая часть framework. Для удобства, правда,
могут использоваться вещи, которые пока что глючат/не глючат одинаково
на двух реализациях.

Здравствуйте, Lazy Cjow Rhrr, а также VladD2, Андрей Хропов, eao197 и прочие многоуважаемые участиники треда !

Хотелось бы принести в дискуссию долю конструктива
Предлагаю вместо того чтобы меряться возможностями \ невозможностями сферического Эрланга на сферических задачах следующий манёвр.

Свести вопрос Erlang sux\rulez к вопросу "Как можно сделать аналог Erlang на Scala или Nemerle".
Допустим для меня решение этой задачи отнюдь не выглядит очевидным. VladD2 может описать как он это видит, получит долю конструктивных замечаний от людей знающий Erlang, замечания по возможным проблемам от eao197, пару глупых уточняющих вопросов от меня, и т.д.

Глядишь через некоторое врямя начнется обсуждение почему аналог Erlang на .NET или Java получился таким-то и таким-то Очень бы этого хотелось.

Peace!

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

C>Сколько раз можно повторять, что сам по себе язык нафиг никому не нужен?
C>Программы на .NET де-факто некроссплатформенны по большей части.
C>RSDN@Home, MonoDevelop и Beagle служат этому замечательным примером.

На счет MonoDevelop и Beagle не могу сказать, но вот Rsdn@Home писался под определенную архитектуру, с завязкой на некроссплатфоремнные компоненты. Думаю, Java при таких условиях будет выглядить не лучше.

rameel wrote:
> C>Сколько раз можно повторять, что сам по себе язык нафиг никому не нужен?
> C>Программы на .NET де-факто некроссплатформенны по большей части.
> C>RSDN@Home, MonoDevelop и Beagle служат этому замечательным примером.
> На счет MonoDevelop и Beagle не могу сказать, но вот Rsdn@Home писался
> под определенную архитектуру, с завязкой на некроссплатфоремнные
> компоненты. Думаю, Java при таких условиях будет выглядить не лучше.
Честно говоря, я не помню ни одного некроссплатформенного компонента для
Java, который мне вообще хотелось бы использовать. Там по большей части
все 100% на Java, так что переносится куда угодно.

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

VD>И параметры комплитит? И контекстую помощь для них показывает? Значит прогресс в командных строках ушел далеко вперед...

Некоторые параметры комплитит. Помощь не показывает, ессесно. Но мы же про комплит?

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

VD>Если скрипт прост, то я и под виндовс наверно остановлюсь на cmd. Но если сложный, то где угодно предпочту полноценный язык.

А что есть "полноценный язык"? Инфраструктура Windows Host Script подойдет?

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

IT>Но вот что твоё руководство скажет при начале работ над новыми проектами — это очень хороший вопрос. Лет десять назад моё руководство

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

IT>сказало — лучшее враг хорошего. Через год мы остались без заказов и практически вылетели из бизнеса, контора только чудом уцелела. Тогда это был переход с DOS на Windows и случай, конечно не совсем равноценный. Но зато очень поучительный.

Во многих случаях лучшее — враг хорошего. Данное исключение лишь подтверждает правило.

IT пишет:
> Народ должен знать своих демагогов в лицо.
Народ и сам разберется, кого считать демагогом, а кого нет. К тому же,
непонятно, зачем нужно обвинять eao197 в демагогии в диалоге с другим
участником форума (эдак как бы невзначай сказав "не будь таким плохим
как он" — после этого еще не ясно, кто тут больший демагог).

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

VD>Строго говоря нет. Он будет выполнять их последовательно с переключением. Ускорения это не даст. Скорее замедлит. Если обработка короткая, то по любому лучше ее последовательно организовать.
Точнее, если эта обработка состоит ровно из CPU-интенсивных операций. В жизни таких веб-запросов практически не бывает; обычно значительную долю времени обработки занимает ожидание.
Еще точнее, в процессе обработки запроса используются разные ресурсы компьютера. И выглядит это как-то примерно так:

CPU:                 |------|                         |-----------|
RAM:              |-------------|                  |-------| |-------|
Ethernet Adapter: |--|                                               |-----|
Disk:                           |---------------------|

Как видно, ни один из ресурсов не используется 100% времени. Поэтому даже на классической однопроцессорной машине псевдопараллельное исполнение может дать преимущества.

VD>Псевда-параллилизм дает ложное ощущение быстроты. Реально же все работает медленее. Быстрее только отклик. Для многих задач отклик важен. Для того же веб-сервера — нет. Ему проще в очередь запросы ставить и по одному разгребать.

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


VD>Ну, а на РСДН Эрланг откровенно распиарили. Ни одного реального сравнения быстродействия я пока что не видел. О том, что аналогичную фукнциоальность предоставляют системы и серверы обработки сообщений вроде MSMQ, IMB MQ Series и т.п. никто вообще не говорит.

Т.е. ты предлагаешь софт свичей, или http-сервак на базе MSMQ строить?
Часть функционала между Эрлангом и очередями сообщений, наверное, пересекается, но вот боюсь, что лишь часть и к тому же как минимум накладные расходы на инфраструктуру во втором случае будут больше (если рассматривать именно случай массовой параллельности, а не что-то абстрактное типа квиксорта).

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

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

LCR>>Только не надо создавать впечатления, что для создания клона Эрланг VM достаточно наваять минипоточки и посыпать это дело сахарком. Это совсем не так.
АХ>Ну так аргументируй убедительно почему это не так. Пока я только список buzzwordов увидел.

Если честно, то для клона как раз надо наваять минипоточки, только чтобы они были эквивалентны потокам Эрланга. Один из таких моментов — как защитить параллельность от зацикливания. В Эрланге единицей выполнения является редукция (что-то типа вызова функции). В императивных языках есть другие конструкции типа циклов, которые могут быть чреваты. Допустим мы можем организовать бесконечный цикл и в итоге текущий поток "ляжет" (а т.к. число потоков в системе скорее всего будет конечным, хотя как бесконечное организовать?, то в итоге ляжет весь процесс клона Эрланга).
Другой момент — заметная разница в сборщиках мусора из-за того, что в Эрланге разделяемых данных нет и все переменные иммутабельны.
Возможно есть ещё моменты, допустим я вот не могу пока придумать, но должны быть последствия того, что мы допустим динамику на статику. Скорее всего это скажется на обновлении кода. Но тут надо думать.
Я считаю, что клон Эрланга написать реально, только вот это не такая простая задачка, как тут пытаются многие это изобразить (причём чисто на словах, пока только 2 попытки вижу в данном направлении и оба не из Немерле: собжектайзер и акторы скалы, первый пугает плюсами и поэтому далеко не лёгким синтаксисом, а вторые лишь попытка, кроме отсылки сообщений надо реализовать ещё целый ряд вещей), и ещё раз скажу, что не уверен, что можно достаточно просто (без лишней крови) заменить динамический язык языком со статической типизацией.

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

К>>Блин, кто говорил про выполнение на разных процессорах?

VD>Блин, ты, ТЫ и сказал. И не раз еще повторл. Задолбал ежу. Цитирую этот ... последний раз:
VD>

Нет там потоков.
VD>В том весь и смысл, что параллельность получается не на потоках ОС, т.е. нет постоянных переключений контекста, что позволяет ускорить работу приложения (при наличии нескольких процессов).

К>>Речь шла именно о паралеллизме и как раз о множетве задач.

VD>Ну, да? Да, ну? Видимо я читать разучился. В отличии от трепа в жизни тут все ходы записываются. Поднимись на несколько сообщений вверх и почитай что писал.

Ну а теперь возьми и прочитай сам!
При наличии нескольких процессов, а не процессоров.
Разницу чувствуешь или помощь нужна?

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

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

К>> но в своей нише он даёт очень хорошие преимущества, но платить приходится именно другим подходом к реализации решения задачи.

VD>Да не дает он сам по себе ничего. Обмен сообщениями для корпоративных нужд был давно реализован в куче серверов. Используется из разных мест. Если говорить о распараллеливание, то опять же куча ограничений. Устойчивость к сбокя? Надженость? Ну, ну, давай померяем пенис с тем же MSMQ который обеспечивает транзакционность в распределенной среде и гарантированную доставку сообщений. Производительность? Идем курить то же решение из Oz. Да и опять таки производительность чего? Вроучную всегда моно создать более шустрое решение. В концео концов Эрлэнг интерпретатор.

ОК, возьмём конкретный пример: Apache vs. YAWS (веб-сервер на эрланге).
Первый падает при 4 000 одровременных запросов, второй при 80 000.
См. http://www.sics.se/~joe/apachevsyaws.html
Есть мнение, что MSMQ будет очень далеко даже от первого по производительности.
Хотя, конечно, это частный случай, будут частные случаи выгодные для MSMQ.
Для каждой задачи свой инструмент.

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

Ммм, авторы чего?
Воспроизвести можно, весь вопрос в том когда и как. И встаёт вопрос — почему это не сделано?
Т.е. есть реально работающий Эрланг. Есть экзотический Oz. (всё руки не дойдут посмотреть подробней, но до мейнстрима явно ему дальше чем Немерле).


VD>В общем, удивительно, что авторы любопытных технологий намного более адекватны, чем фанатичные поклонники оных.

Интересно, если под 2-ми подразумеваешь меня, то кого ты подразумеваешь под 1-ми?