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

V>>Потому что мои Op выполняются, считай, сразу, без стадии компиляции в CIL на моей стороне.
S>Ну, ок. Статика. Если удастся сконструировать их статически.

Конструируются динамически через зеркальную цепочку фабрик.
При конструировании происходит анбоксинг параметров до пятого уровня вложенности и всё сначала.
Результирующее выражение всё-равно боксированное к известному интерфейсу, но забоксирован сложный value-type.


V>>Берём серверную сторону, сервак работает 24x7.
V>>Серверная сторона не для красного словца — та задача изначально под серверную сторону потребовалась.
V>>Compile каждый раз порождает новый код, который остаётся в памяти процесса и нет способа этот мусор собрать.
S>А зачем делать это каждый раз, когда можно один раз проинициализировать статическое поле результатом Compile, а потом обращаться к нему за стоимость вызова IOperation<int>.Execute или даже быстрее?

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


V>>Перезагрузки доменов теперь тоже нет.
S>Почему не скомпилировать это в DynamicMethod, который прекрасно соберётся безо всякой выгрузки доменов?

Облом было ради такой задачи возиться аж с опкодами.


S>Эмм, если где-то есть парсер-билдер, то никакой статики уже не будет.

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


V>>https://docs.microsoft.com/ru-ru/dotnet/csharp/whats-new/csharp-8
S>Нет, "списочек" — вот: https://github.com/bartdesmet/ExpressionFutures/blob/master/CSharpExpressions/README.md

А да, я прочитал как .Net Core 3.0, а не версия языка.
ОК.


V>>В реальных коммерческих проектах всегда весы — трудоёмкость vs получаемые плюшки.
S>Точно. Именно это я и написал.

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


V>>А здесь ситуация вдвойне забавной получилась, бо поддержка статических локальных методов в expression builder не стоит дороже написания нового кода, который сгенерирует и выдаст новую ошибку компиляции с новым номером при попытке использовать статические локальные методы в expressions.
S>Возможно. Я в код компилятора не смотрел, не могу сказать, что было дороже.

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


V>>Рассуждая похожим образом:
V>>- отсутствие linq в дотнете аффектило примерно 0 человек в мире
V>>- отсутствие дотнета аффектило примерно 0 человек в мире
S>Вот эти натянутые аналогии показывают, что вам пока рано в продакт менеджмент

Не тебе судить.
Даже тут оценка "натяжка" — насос из пальца.
Т.е. ты среагировал на содержание, хотя показывался принцип.
И как может столь субъективный человек, с полутыка агрящийся на некие "маркеры", рассуждать о чьей-то там готовности?
Только через такую же точно неконтроллируемую субъективность.

Тут всё слишком стандартно — хотя я где-то приветствую увлекающихся людей и "болею" за них, но в деле принятия решений их слово последнее.


S>Отсутствие linq в дотнете аффектило миллионы человек в мире.

Дудки.
99% людей не знали что это такое и потому не желали этого.
Как можно желать того, о чём не в курсе? ))


S>Хейльсберг в своё время очень убедительно обосновывал, почему был разработан Linq — а ведь это потребовало огромных инвестиций. Уж очень дофига принципиально нового было добавлено в язык.

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

Ты опять цепляешься за конкретику, не понимая общего принципа разработки дотнета и языка C#.
(по каждому нововведению есть кучи и обсуждений, и убедительных обоснований)

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


S>Отсутствие дотнета аффектило, в первую очередь, позиции Microsoft

Ага, а теперь MS отпустил дотнет в свободное плавание.
И выглядит так, что практически совсем свободное.


S>которому хотелось делать свою JVM, но Sun не давала им пилить JVM в нужную микрософту сторону.

Sun не давала возможность пилить ни в какую.
То бишь, Sun боролась за то, чтобы новые версии Джавы выходили только из под её пера.

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


V>>Посмотри в зеркало, плиз, на каждый именно твой пост запросто можно отвечать "это никому не нужно" и "ты всё-равно до этого не доживёшь", бо ты пишешь сюда именно такой материал, заведомо допускающий именно таких оценок.
S>Ну естественно. По умолчанию, linq2d нафиг никому не упал.

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

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


V>>Решения принимаются в несколько этапов, происходящих итеративно: из формулирования целей и приоритетов, затем из анализа потенциальной трудоёмкости задач, соотнесения с располагаемыми ресурсами, goto на начало.
S>Именно. И вот этот процесс привёл к тем результатам, которые мы и наблюдаем.

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

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

Сейчас набежали добровольцы по интересам (особенно из нейтива) и делают лишь то, что считают необходимым.
(в т.ч. серьезно переделали SslStream уже дважды, и вообще принципы работы с X509-сертификатами).

Им этот Exression и даром не упал, они считают его за чушь/блажь, бо есть более срочные вещи.

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

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

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

V>>Потому что мои Op выполняются, считай, сразу, без стадии компиляции в CIL на моей стороне.
S>Ну, ок. Статика. Если удастся сконструировать их статически.

Конструируются динамически через зеркальную цепочку фабрик.
При конструировании происходит анбоксинг параметров до пятого уровня вложенности и всё сначала.
Результирующее выражение всё-равно боксированное к известному интерфейсу, но забоксирован сложный value-type.


V>>Берём серверную сторону, сервак работает 24x7.
V>>Серверная сторона не для красного словца — та задача изначально под серверную сторону потребовалась.
V>>Compile каждый раз порождает новый код, который остаётся в памяти процесса и нет способа этот мусор собрать.
S>А зачем делать это каждый раз, когда можно один раз проинициализировать статическое поле результатом Compile, а потом обращаться к нему за стоимость вызова IOperation<int>.Execute или даже быстрее?

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


V>>Перезагрузки доменов теперь тоже нет.
S>Почему не скомпилировать это в DynamicMethod, который прекрасно соберётся безо всякой выгрузки доменов?

Облом было ради такой задачи возиться аж с опкодами.


S>Эмм, если где-то есть парсер-билдер, то никакой статики уже не будет.

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


V>>https://docs.microsoft.com/ru-ru/dotnet/csharp/whats-new/csharp-8
S>Нет, "списочек" — вот: https://github.com/bartdesmet/ExpressionFutures/blob/master/CSharpExpressions/README.md

А да, я прочитал как .Net Core 3.0, а не версия языка.
ОК.


V>>В реальных коммерческих проектах всегда весы — трудоёмкость vs получаемые плюшки.
S>Точно. Именно это я и написал.

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


V>>А здесь ситуация вдвойне забавной получилась, бо поддержка статических локальных методов в expression builder не стоит дороже написания нового кода, который сгенерирует и выдаст новую ошибку компиляции с новым номером при попытке использовать статические локальные методы в expressions.
S>Возможно. Я в код компилятора не смотрел, не могу сказать, что было дороже.

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


V>>Рассуждая похожим образом:
V>>- отсутствие linq в дотнете аффектило примерно 0 человек в мире
V>>- отсутствие дотнета аффектило примерно 0 человек в мире
S>Вот эти натянутые аналогии показывают, что вам пока рано в продакт менеджмент

Не тебе судить.
Даже тут оценка "натяжка" — насос из пальца.
Т.е. ты среагировал на содержание, хотя показывался принцип.
И как может столь субъективный человек, с полутыка агрящийся на некие "маркеры", рассуждать о чьей-то там готовности?
Только через такую же точно неконтроллируемую субъективность.

Тут всё слишком стандартно — хотя я где-то приветствую увлекающихся людей и "болею" за них, но в деле принятия решений их слово последнее.


S>Отсутствие linq в дотнете аффектило миллионы человек в мире.

Дудки.
99% людей не знали что это такое и потому не желали этого.
Как можно желать того, о чём не в курсе? ))


S>Хейльсберг в своё время очень убедительно обосновывал, почему был разработан Linq — а ведь это потребовало огромных инвестиций. Уж очень дофига принципиально нового было добавлено в язык.

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

Ты опять цепляешься за конкретику, не понимая общего принципа разработки дотнета и языка C#.
(по каждому нововведению есть кучи и обсуждений, и убедительных обоснований)

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


S>Отсутствие дотнета аффектило, в первую очередь, позиции Microsoft

Ага, а теперь MS отпустил дотнет в свободное плавание.
И выглядит так, что практически совсем свободное.


S>которому хотелось делать свою JVM, но Sun не давала им пилить JVM в нужную микрософту сторону.

Sun не давала возможность пилить ни в какую.
То бишь, Sun боролась за то, чтобы новые версии Джавы выходили только из под её пера.

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


V>>Посмотри в зеркало, плиз, на каждый именно твой пост запросто можно отвечать "это никому не нужно" и "ты всё-равно до этого не доживёшь", бо ты пишешь сюда именно такой материал, заведомо допускающий именно таких оценок.
S>Ну естественно. По умолчанию, linq2d нафиг никому не упал.

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

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


V>>Решения принимаются в несколько этапов, происходящих итеративно: из формулирования целей и приоритетов, затем из анализа потенциальной трудоёмкости задач, соотнесения с располагаемыми ресурсами, goto на начало.
S>Именно. И вот этот процесс привёл к тем результатам, которые мы и наблюдаем.

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

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

Сейчас набежали добровольцы по интересам (особенно из нейтива) и делают лишь то, что считают необходимым.
(в т.ч. серьезно переделали SslStream уже дважды, и вообще принципы работы с X509-сертификатами).

Им этот Exression и даром не упал, они считают его за чушь/блажь, бо есть более срочные вещи.

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

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