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

FR>Да я понял пуговицы обязательно должны быть перламутровые, извините не учел-с

Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

Как только такой объединяющий концепт есть — то все асинхронное программирование можно видеть как нити различных данных/событий, которые можно связывать запросами, порождать новые и раставлять обработчики. Причем это интегрируется к существующему коду на раз-два как раз из-за дуальности коллекций. Вот именно это я называю новым концептом. И мне действительно интересно посмотреть, если именно вот такой подход уже был применен раньше.

Кэр>>А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.

FR>В хаскелевских уже давно все в монады запаковано http://conal.net/fran/tutorial.htm
FR>Удобные реактивные библиотеки совсем не новинка, даже питоновскому Trellis уже года три наверно.

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

Кэр>>А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?
FR>Нет до вас мне далеко, так что не претендую, долго не смогу в таком тоне.

Да я такой тон выдерживаю только в разговоре, где основным аргументом является личный авторитет. Нет никакого уважения к личным авторитетам — вот что вы поделаете?

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

Кэр>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

tcl/tk?

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

Кэр>>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

L>tcl/tk?

Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.

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

Кэр>Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.

Затруднит

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

Кэр>>Вас не затруднит привести аналог вот этого примера? Ну или выберите другой пример, который вы считаете показательным.

L>Затруднит

тут хотелось бы заметить, что язык позволяет такое сделать.
проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
как-то так

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

NB>тут хотелось бы заметить, что язык позволяет такое сделать.
NB>проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
NB>как-то так

Таки очень хотелось бы увидеть пример на tcl Вас не затруднит?

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

NB>>тут хотелось бы заметить, что язык позволяет такое сделать.
NB>>проблема в том что кто знает tcl, не знает rx, а кто знает rx, тому не нужен tcl.
NB>>как-то так

Кэр>Таки очень хотелось бы увидеть пример на tcl Вас не затруднит?

ок. код

class GroupBy_Simple
{
    static IEnumerable<ConsoleKeyInfo> KeyPresses()
    {
        for (; ; )
        {
            var currentKey = Console.ReadKey(true);

            if (currentKey.Key == ConsoleKey.Enter)
                yield break;
            else
                yield return currentKey;
        }
    }
    static void Main()
    {
        var timeToStop = new ManualResetEvent(false);
        var keyPresses = KeyPresses().ToObservable();

        var groupedKeyPresses =
            from k in keyPresses
            group k by k.Key into keyPressGroup
            select keyPressGroup;

        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

        groupedKeyPresses.Subscribe(keyPressGroup =>
        {
            int numberPresses = 0;

            keyPressGroup.Subscribe(keyPress =>
            {
                Console.WriteLine(
                    "You pressed the {0} key {1} time(s)!",
                    keyPress.Key,
                    ++numberPresses);
            },
            () => timeToStop.Set());
        });

        timeToStop.WaitOne();
    }
}

объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )

PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй

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

NB>ок. код

class GroupBy_Simple
{
    // Получаем ввод с клавиатуры в виде псевдо-бесконечной последовательности клавиш.
    // Enter прерывает эту последовательность.
    static IEnumerable<ConsoleKeyInfo> KeyPresses()
    {
        for (; ; )
        {
            var currentKey = Console.ReadKey(true);

            if (currentKey.Key == ConsoleKey.Enter)
                yield break;
            else
                yield return currentKey;
        }
    }
    static void Main()
    {
        // Определяем флаг, который будет держать основной поток, пока мы тарабаним по клавиатуре.
        var timeToStop = new ManualResetEvent(false);

        // Используя дуальность коллекции переворачиваем блокирующую последовательность в поток
        // событий. С IEnumerable тоже все будет работать, но не будет асинхронного вывода, все 
        // будет распечатано в самом конце после финального Enter.
        var keyPresses = KeyPresses().ToObservable();

        // Используя LINQ поверх push based collections опредеяем, что нас интересует не поток 
        // событий "нажатия на клавиши" - мы хотим, чтобы этот поток был сгруппирован по нажатым 
        // клавишам. И мы подпишемся уже на группы событий. Могли бы еще, например, отфильтровать,
        // или сджойнить с другими событиями, или...
        var groupedKeyPresses =
            from k in keyPresses
            group k by k.Key into keyPressGroup
            select keyPressGroup;

        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

        // Поехали. Для каждой группы определим делегат с внутренним состоянием, который будет вести 
        // учет текущего количества элементов в группе.
        groupedKeyPresses.Subscribe(keyPressGroup =>
        {
            int numberPresses = 0;

            // Для каждого события в группе будем распечатывать уведомление на экран и увеличивать счетчик заодно.
            keyPressGroup.Subscribe(keyPress =>
            {
                Console.WriteLine(
                    "You pressed the {0} key {1} time(s)!",
                    keyPress.Key,
                    ++numberPresses);
            },

            //  Когда события иссякнут (будет нажата клавиша Enter) - отпустить флаг блокирующий основной поток
            () => timeToStop.Set());
        });

        // Подождать, пока клавиша Enter будет нажата.
        timeToStop.WaitOne();
    }
}

NB>объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )
NB>PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй

Жду вашего кода. Если нужно еще подробнее — не стесняйтесь спрашивать. Мне интересно увидеть вариант на tcl

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

Кэр>Здравствуйте, night beast, Вы писали:

NB>>ок. код
Кэр>

Кэр>class GroupBy_Simple
Кэр>{
Кэр>    // Получаем ввод с клавиатуры в виде псевдо-бесконечной последовательности клавиш.
Кэр>    // Enter прерывает эту последовательность.
Кэр>    static IEnumerable<ConsoleKeyInfo> KeyPresses()
Кэр>    {
Кэр>        for (; ; )
Кэр>        {
Кэр>            var currentKey = Console.ReadKey(true);

Кэр>            if (currentKey.Key == ConsoleKey.Enter)
Кэр>                yield break;
Кэр>            else
Кэр>                yield return currentKey;
Кэр>        }
Кэр>    }
Кэр>    static void Main()
Кэр>    {
Кэр>        // Определяем флаг, который будет держать основной поток, пока мы тарабаним по клавиатуре.
Кэр>        var timeToStop = new ManualResetEvent(false);

Кэр>        // Используя дуальность коллекции переворачиваем блокирующую последовательность в поток
Кэр>        // событий. С IEnumerable тоже все будет работать, но не будет асинхронного вывода, все 
Кэр>        // будет распечатано в самом конце после финального Enter.
Кэр>        var keyPresses = KeyPresses().ToObservable();

Кэр>        // Используя LINQ поверх push based collections опредеяем, что нас интересует не поток 
Кэр>        // событий "нажатия на клавиши" - мы хотим, чтобы этот поток был сгруппирован по нажатым 
Кэр>        // клавишам. И мы подпишемся уже на группы событий. Могли бы еще, например, отфильтровать,
Кэр>        // или сджойнить с другими событиями, или...
Кэр>        var groupedKeyPresses =
Кэр>            from k in keyPresses
Кэр>            group k by k.Key into keyPressGroup
Кэр>            select keyPressGroup;

Кэр>        Console.WriteLine("Press Enter to stop.  Now bang that keyboard!");

Кэр>        // Поехали. Для каждой группы определим делегат с внутренним состоянием, который будет вести 
Кэр>        // учет текущего количества элементов в группе.
Кэр>        groupedKeyPresses.Subscribe(keyPressGroup =>
Кэр>        {
Кэр>            int numberPresses = 0;

Кэр>            // Для каждого события в группе будем распечатывать уведомление на экран и увеличивать счетчик заодно.
Кэр>            keyPressGroup.Subscribe(keyPress =>
Кэр>            {
Кэр>                Console.WriteLine(
Кэр>                    "You pressed the {0} key {1} time(s)!",
Кэр>                    keyPress.Key,
Кэр>                    ++numberPresses);
Кэр>            },

Кэр>            //  Когда события иссякнут (будет нажата клавиша Enter) - отпустить флаг блокирующий основной поток
Кэр>            () => timeToStop.Set());
Кэр>        });

Кэр>        // Подождать, пока клавиша Enter будет нажата.
Кэр>        timeToStop.WaitOne();
Кэр>    }
Кэр>}
Кэр>

NB>>объясни что и как там происходит, и я попробую реализовать это на тикле ( хотя не прогал на нем 100 лет )
NB>>PS: не знаю ни Rx, ни шарпа, так что если можно, подробнее объясняй

Кэр>Жду вашего кода. Если нужно еще подробнее — не стесняйтесь спрашивать.

нужно
интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.

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

NB>нужно
NB>интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.

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

Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?

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

NB>>нужно
NB>>интересует и как все происходит. то есть что и в какой последовательности вызывается при нажатии клавиши.

Кэр>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.

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

Кэр>Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?

извиняюсь за глупые вопросы, я сразу предупредил что с шарпом не знаком
твой запрос ждет пока ввод закончится, или уведомляет подписчиков по мере поступления данных?
что делает "group k by k.Key"? я правильно понимаю, что для каждой группы создается свой подписчик?

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

Кэр>>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.

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

Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.

Кэр>>Но работает примерно так — Subscribe декларирует подписчик на сгенерированную цепочку событий. Сама цепочка нашими усилиями начинает ожидать нажатия клавиш и потом преобразует нажатия клавиш в нечто более удобное, с чем мы работаем уже в подписчике. В каком месте нужно еще подробнее?

NB>извиняюсь за глупые вопросы, я сразу предупредил что с шарпом не знаком
NB>твой запрос ждет пока ввод закончится, или уведомляет подписчиков по мере поступления данных?

Уведомляет по мере.

NB>что делает "group k by k.Key"?

Описывает запрос к цепочке событий. Конкретно здесь декларируется, что события должны быть сгруппированы по нажатой клавише. После этой декларации мы будем работать с группами событий. Ключом каждой группы будет значение клавиши: "Q", "W", "E", "R", etc.

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

Подписчик в виде лямбда-функции декларируется один раз, но он параметризирован группой событий.

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

Кэр>>>Хм, не очень понимаю, как это влияет на семантику, чтобы переписать это на tcl, тем более что утверждается, что он умеет работать с запросами поверх цепочки событий.

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

Кэр>Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.

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

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

Кэр>>Ааа. Ну тогда мне сразу неинтересно. Вы ответили в ветке, в которой обсуждалось, что в Rx ничего нового нет. На просьбу показать где было — в конце концов договорились, что было в tcl. На просьбу показать как именно это было в tcl откликнулись вы. Этот код можно написать очень различными способами, благо сама программа несложная. Мне интересно было посмотреть на запросы к цепочке событий в другом языке, как было обещано.

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

В таком случае ценность такого утверждения крайне невелика. Покажите мне язык, на котором этого нельзя сделать.

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

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

Кэр>В таком случае ценность такого утверждения крайне невелика. Покажите мне язык, на котором этого нельзя сделать.

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

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

Кэр>Нет, вы не поняли Я здесь вижу главным то, что Rx это именно язык запросов поверх push based collections, которые являются дуальными к обычным pull based collections. Просто это получается чертовски удобно. И именно этого я не вижу в ваших примерах.

Кэр>Как только такой объединяющий концепт есть — то все асинхронное программирование можно видеть как нити различных данных/событий, которые можно связывать запросами, порождать новые и раставлять обработчики. Причем это интегрируется к существующему коду на раз-два как раз из-за дуальности коллекций. Вот именно это я называю новым концептом. И мне действительно интересно посмотреть, если именно вот такой подход уже был применен раньше.

Смотрел пример ниже, возможно я блаб, но ничего чем можно восхитится не увидел.
Возможно на фоне C# это что-то, на фоне функциональщины похоже на обычный код.

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

MS>А важно то, собственно, к чему это я? А важно то, что не бывает универсальных инструментов. Универсальный инструмент противоречил бы законам природы, так же, как универсальный растворитель — его просто не в чем было бы хранить!

Инструменты нужны не универсальные, а адаптируемые. Мы же все-таки с софтом имеем дело, а не со стальными кусачками.

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

FR>Смотрел пример ниже, возможно я блаб, но ничего чем можно восхитится не увидел.
FR>Возможно на фоне C# это что-то, на фоне функциональщины похоже на обычный код.

У меня и не стояло задачи вас восхитить Мне было интересно, сможете ли вы подтвердить свои слова, что это было раньше — но так и не дождался. Без этого ваше аторитетное мнение — мне не очень интересно, уж извините.

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

Кэр>У меня и не стояло задачи вас восхитить Мне было интересно, сможете ли вы подтвердить свои слова, что это было раньше — но так и не дождался. Без этого ваше аторитетное мнение — мне не очень интересно, уж извините.

Мне все же интересно что ты там нового и потрясающего увидел, выше ты писал:

Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.

как руки дойдут, дай пожалуйста ссылку сюда.

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

K>Ну а чем деятельность программиста отличается от деятельности микроэлектронщика?

Разное соотношение кол-ва и качества информации на разработчика. Электронщики работают по относительно небольшому набору тщательно спроектированных протоколов/интерфейсов, а программист, например, нашел новый сниппет/либу, применил, — вот тебе очередная порция спецификаций. На всех уровнях суммарно набегает ого. И прилично кода пляшет вокруг именно совмещения разнородных либ, использующих данные в разных форматах, с порой совершенно разными подходами. Ну а так как ничего бесплатно не дается, то компенсируется такое отношение кол-ва информации к ее качеству гораздо меньшей надежностью, что в свою же очередь компенсируется возможностью дешевого апгрейда версий/патчей. Чем и живем пока.

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

Хотя... "серьезный" софт делают не так много производителей, и этот серьезный софт, что логично, стоит довольно дешево, особенно оптом (вспомним подписку MSDN). Зато всякие поделки по-месту из разряда "решения уровня предприятия" толкаются за десятки-сотни тысяч аж бегом.

K>И те и другие переводят неформальные требования в формальное описание автомата, решающего поставленную задачу. Единственная разница — тиражирование автоматов, которые разрабатывают программисты тривиально, а значит в программировании есть только R&D а вся деятельность связанная с налаживанием серийного производстав отсутствует в принципе.

Как правильно заметили где-то недалеко — компиляция/сборка конечного продукта/пакета и есть аналог "серийного" производства. И деятельность по её налаживанию вовсе не бесплатна. Хотя, ты совершенно прав, вложения на разработку софта относительно невелики. Проблема лишь в том, все все делают одно и то же, деля небесконечный пирог. И за рамки разумной рыночной конкуренции тут все выскочило еще в конце 80-х. Современная "переконкуренция" — не меньший вред, чем отсутствие конкуренции вообще, ибо пользователю постоянно подсовывают сырое г-но, и это уже не считается чем-то постыдным. Разве мы обсуждаем со смешком в курилках какую-нить знаменитую ошибку какого-нить известного пакета, как это было лет 20 назад? Да сейчас их сотни и тысячи ошибок регулярно в автообновлениях исправляется, это сегодня норма...

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

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

ИМХО, вот этому современному романтизму в IT, когда небольшая группа энтузиастов может что-то толковое сделать с 0-ля осталось не так много лет. Так что, если у кого есть какие идеи — лучше поторопиться. Через пару десятков лет поздновато будет. Как поздно сейчас разрабатывать компьютеры в одиночку.