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

T>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".

T>Увы, ты начал понимать только общее для Axum и Erlang.

Удивительные вы люди, все таки. Я уже практически прямо сказал — что это за проект и для чего он нужен. Это эксперимент на тему того, что будет C# 5 (точно так же как C omega был прототипоМ ряда фич C# 3), и от этого и надо плясать при оценке. Не верите?

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

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

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

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

IT>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression.

Метод типа R If<R>(Func<bool> predicate, Func<R> @then, Func<R> @else) не спасет? Или это слишком тормозной вариант для твоих целей?

T>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
T>>Увы, ты начал понимать только общее для Axum и Erlang.
AVK>Удивительные вы люди, все таки. Я уже практически прямо сказал — что это за проект и для чего он нужен. Это эксперимент на тему того, что будет C# 5 (точно так же как C omega был прототипоМ ряда фич C# 3), и от этого и надо плясать при оценке. Не верите?

От этого моя оценка не меняется, поверь.

И то, что это тот самый fire, чтобы не было motion, и всего остального.

Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут.

Поэтому это очередная умеренно удобная фича, стоящая не более, чем очередная библиотека/DSeL на Haskell.

G>>>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.
T>>>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?
G>>>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.
T>>Вот уж совсем не проблема.
G>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.

Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.

T>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
G>А зачем? С такой платформой как .NET отдельный язык может быть гораздо выгоднее, чем впихивать теже особенности в DSEL.

Строгая типизация страдает.

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

Нет. Попробуй написать на Хаскеле, должно хорошо получиться.

T>>>>А все подхватили.
G>>>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда.
T>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества.
G>Ну давай посмотрим. В чем Erlang настолько больше?

Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.

Горячая замена кода.

Let it fail.

Пожалуй, достаточно.

T>>(обнаружил себя в непривычной ситуации защиты Эрланга)
G>(а я вроде как и не против Erlang был)

Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.

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

G>>>>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.
T>>>>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?
G>>>>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.
T>>>Вот уж совсем не проблема.
G>>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.

T>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
С чего бы? Только потому что pattern-matching нету?

T>>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
G>>А зачем? С такой платформой как .NET отдельный язык может быть гораздо выгоднее, чем впихивать теже особенности в DSEL.
T>Строгая типизация страдает.
Чем страдает?

G>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
T>Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.

T>>>>>А все подхватили.
G>>>>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда.
T>>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества.
G>>Ну давай посмотрим. В чем Erlang настолько больше?

T>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.
Неизменяемые данные есть и в Axum, там это называется схемами. Только схемы там сериализуемые должны быть, поэтому ФВП непердавать нельзя.
Хотя не знаю насколько необходимо передавать ФВП, там ведь полностью поддерживается ООП.

T>Горячая замена кода.
Горячая замена кода есть и в .NET, только больше приседаний для нее надо.


T>>>(обнаружил себя в непривычной ситуации защиты Эрланга)
G>>(а я вроде как и не против Erlang был)

T>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
Улыбнуло. Разве кто-то говорит что надо срочно бросить все и писать на axum?

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

IT>>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression.

AVK>Метод типа R If<R>(Func<bool> predicate, Func<R> @then, Func<R> @else) не спасет? Или это слишком тормозной вариант для твоих целей?

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

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

Z>>Вторая причина по которй Erlang поддерживает selective-receive — горячая замена кода.
E> А можно развернуть этот тезис?
Это не то, чтобы отдельная причина, скорее следствие того, что сообщение может быть в том числе и новым кодом для агента. А сообщение новому агенту может прийти до того, как будет установлен новый код.

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

T>>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества.
G>>Ну давай посмотрим. В чем Erlang настолько больше?

T>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.

T>Горячая замена кода.

T>Let it fail.

T>Пожалуй, достаточно.

Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.

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

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

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

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

Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все.

Файберы — лишь иллюстрация того, как этого можно достичь в С++. Другие способы, кроме файберов, для достижения данного свойства в С++, мне не известны. Кроме того, эта хардкорная магия снаружи выглядит весьма просто, приятно и понятно. Ведет себя предсказуемо, дает программисту контроль на ситуацией, и облегчает чтение кода. Данная "декларативность" его имхо затрудняет.

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

E>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.

Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях. High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно. И она достаточно уныла, чтобы не возникало такого желания.

G>>>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.
T>>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
G>С чего бы? Только потому что pattern-matching нету?

Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля. В нём не будет разделения типов выражений с эффектом и без.

Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом.

T>>Строгая типизация страдает.
G>Чем страдает?

Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе).

Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка.

G>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
T>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
G>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.

Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом.

G>>>Ну давай посмотрим. В чем Erlang настолько больше?
T>>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.
G>Неизменяемые данные есть и в Axum, там это называется схемами. Только схемы там сериализуемые должны быть, поэтому ФВП непердавать нельзя.
G>Хотя не знаю насколько необходимо передавать ФВП, там ведь полностью поддерживается ООП.

Ты, вообще, HOF пользовался?

Оно понятно, что closures (HOF) are poor man objects, но они настолько удобней, что просто ах!

T>>Горячая замена кода.
G>Горячая замена кода есть и в .NET, только больше приседаний для нее надо.

И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.

T>>>>(обнаружил себя в непривычной ситуации защиты Эрланга)
G>>>(а я вроде как и не против Erlang был)
T>>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
G>Улыбнуло. Разве кто-то говорит что надо срочно бросить все и писать на axum?

Да вообще о нём забыть надо.

T>>Пожалуй, достаточно.
E>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.

HPC не означает отсутствия устойчивости к сбоям.

Но в любом случае я точно буду использовать .Net только как одну из альтернатив.

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

T>От этого моя оценка не меняется, поверь.

Дело не в твоей оценке, а в тех предпосылках и гаданиях на каофейной гуще, что я вижу в этом топике.

T>Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут.

Разумеется. Потому что цели сделать еще один Ерланг не стоит. Стоит цель улучшить поддержку асинхронного программирования в языке C#. И, сразу скажу, под асинхронным программированием в МС в данном конкретном случае понимают не решение коммуникационных задач и прочего ввода-вывода (это опять же к вопросу о ерланге), а для утилизации мультикоров с целью ускорения числомолотилок. Соотв., скажем, обсуждать библиотечку eao в приложении к Axim малоосмысленно.

T>Поэтому это очередная умеренно удобная фича, стоящая не более, чем очередная библиотека/DSeL на Haskell.

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

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

IT>Это выкривление одной кривизны с помощью другой. Короче говоря извратство.

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

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

T>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.

Он уже достаточно функционален, чтобы можно было использовать функциональный стиль. Бесскомпромиссным, навроде Clean или Haskell, он, разумеется, никогда не будет. Впрочем, это все вопрос терминологии.

T>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.

Ну я знал, что этим все закончится.

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

G>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях. High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно

Тем не менее, Евгений мыслит в абсолютно правильном направлении — в МС рассматривают прежде всего реюз мультикора для ускорения рассчетов.

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

T>Да и неизменяемых значений тоже не будет.

Я бы 100 рублей на это не поставил.

T>>От этого моя оценка не меняется, поверь.
AVK>Дело не в твоей оценке, а в тех предпосылках и гаданиях на каофейной гуще, что я вижу в этом топике.

Ну, у тебя тоже аргументы так себе.

T>>Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут.
AVK>Разумеется. Потому что цели сделать еще один Ерланг не стоит. Стоит цель улучшить поддержку асинхронного программирования в языке C#. И, сразу скажу, под асинхронным программированием в МС в данном конкретном случае понимают не решение коммуникационных задач и прочего ввода-вывода (это опять же к вопросу о ерланге), а для утилизации мультикоров с целью ускорения числомолотилок. Соотв., скажем, обсуждать библиотечку eao в приложении к Axim малоосмысленно.

1) Откуда ты знаешь, что понимают в MS?
2) Использовать агенты в HPC — немного совсем малоэффективное решение. Очень легко получить бутылочное горлышко, насколько я могу судить по своему опыту.

Твои аргументы очень слабые, с моей точки зрения.

T>>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
AVK>Он уже достаточно функционален, чтобы можно было использовать функциональный стиль. Бесскомпромиссным, навроде Clean или Haskell, он, разумеется, никогда не будет. Впрочем, это все вопрос терминологии.

Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.

Вопрос: какой порядок упрощения в функциональном подмножестве C#?

И другой: как скоро порядок упрощения в функциональном подмножестве C# дойдёт до алгоритма Common Lisp?

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

T>>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
AVK>Ну я знал, что этим все закончится.

Я с самого начала это сказал. С этого и начался мой путь в этом топике.

Я считаю, что Axum — это PR .Net.