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

FR>В OCaml если конструктор АлгТД без параметров

Вхождение без параметров в немерле переписывается в синглтон. Он тоже практически бесплатен. Ну, а если все элементы без параметров, то на то есть enum.

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

V>>Дык, ссылочные поля могут как раз могут перекрывать друг друга, и GC отлично работает.

H>Всё это очень здорово. Если бы не одно но — в дотнете есть генерики. Вся эта оптимизация для контейнерных variant-ов идет лесом, она также идет лесом для вариантов наследованных от обыных классов.

Тогда тем более, стоит ввести еще одно ключевое выражение, типа

struct A {}
struct B {}

variant value UnionAB { |A:A; |B:B; };

Никто же не страдает, что структуру в дотнете нельзя от класса унаследовать.

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

VD>>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
B>Отсутствие практической необходимости. Имеющегося знания asm,C,Java,JavaScript,HTML,SQL достаточно для решения любых задач, которые у меня появляются или могут возникнуть. Ради интереса смотрел на Scala, haskell, C#, но в этом всем нет никакого смысла. Может быть, изучил бы Ceylon, когда под него будет IDE.

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

А до тех пор все эти языки для тебя будут непонятными хреновинвами.

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

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

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

S>>См. так же пример с Where

Автор: Undying
Дата: 23.04.11

.

U>И где там мусорный код и лишние сущности?
Сущности? Про сущности не было речи.
foreach, if, Add — мусор. Кроме того что много буков, еще и пространство для потенциальных ошибок, увеличение сложности кода по сравнению с Where.
обозначил места ошибок, которые невозможно допустить с вариантом Where:

var result = new List();
foreach (var x in coll)
  if (test(y))
    list.Add(t);

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

V>Так можно:

Стопицот строк бессмысленного и по сути ненужного кода хэлперов супротив оригинальных 100?

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

V>>Дык, ссылочные поля могут как раз могут перекрывать друг друга, и GC отлично работает. Эти ссылочные поля нельзя перекрывать нессылочными. Только ты GC все-равно не поломаешь, среда исполнения просто не загрузит такую сборку. Я же не зря упомянул процесс "упаковки". Должен быть внутри адресного поля объекта некий "пул" под объединение нессылочных и отдельно ссылочных полей.

H>И еще, если мы имеем в варианте структуру, состоящую более чем из одного поля, а также без LayoutKind, то оптимизация опять же идет лесом.

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

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

V>Никто же не страдает, что структуру в дотнете нельзя от класса унаследовать.

Это какой-то слишком специальный случай.

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

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.
VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.
VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".
VD>...

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

если не брать во внимание аспект сложности (кому-то легко, кому-то сложнее, кто-то вообще останется на уровне "Hello world"), то все определяется стимулом, а вернее его отсутствием. синтаксические, идеологические и уж политические заморочки взламываются легче тогда когда стимул сильнее
а вот уже стимул — это сложная штука. я щас вообще с трудом нахожу стимул на работе

вот последний мой пример возможно переберусь на другую работу осенью и вернусь к старым делам ... а там вроде бы появлися свет в тунеле — стандард uTCA и уж FPGA, которое я уже лет 5-10 хочу научится программировать, рулит по полной. взял софт, и даже плату к нему. установил на рабочем компе, поковырялся часок и решил дома продолжить. а дома софт на home edition не встал ... все пипец — уже неделю на работе не остаюсь по вечерам и в выходные не приезжаю ... это воскресенье хотел, очень хотел, а еще хотел до бассейна добраться поплавать хоть разок за прошедшую неделю ... в итоге пошел хайкать до дюн

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

V>Это понятно, просто сия задача оптимизации сильно привязана к типу узла, и я многократно видел (и сам так же организовывал оптимизацию графов выражений) именно через ее реализацию в теле соответствующего объекта, представляющего узел. Бо задача как бы обязательная при построении графов выражений. Как минимум от лишних скобок (ваше And(And))) всегда избавляются.
И что тут лишнего?

V>Хотя, после пояснения относительно ограничений хвостовой рекурсии в N все вопросы отпадают. Беда, тут нечего обсуждать.
V>Вот этим стоило заняться в первую очередь. Просто все остальное бросить и заняться этим. Ибо (посмотри чуть со стороны) влияние фичи конкретной реализации компилятора на стиль писания на языке (а компилятор и язык, по идее, не одно и то же, хоть и верно для ваших реалий), это жирный такой минус. Факт: приведенный код сразу же сказал о св-вах компилятора заглянувшему человеку со стороны. Показательно.
Показательно что ты снова несешь бред на ровном месте.
Я этот код писал не задумываясь о каких либо оптимизациях.
И я не вижу ни одной причины написать его иначе.

V>Смотреть надо. Посетитель тоже тормоз порядочный, хоть и быстрее обычно на порядок, чем развесистый ПМ.
Лол.
Учитывая что ПМ очень даже может тупо по таблицам работать...

V>Если не привязываться в AST к виртуальным вызовам и некоему "базовому интерфейсу", который не облокотился при наличии структурной типизации на шаблонах в С++, то конечно! бежать по файлам и добавлять легковесные операции в специализированные легковесные объекты, всё в инлайне и без виртуальных вызовов.
Чего? Тут ссылки на базовый класс.
Какие к черту шаблоны?

V>Так можно:

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

VD>>Особо ценная информация вынесена в Q&A. Ну, а если язык интересен, то вряд ли форум будет для тебя мусором.

A>Где можно посмотреть список фич, которые добавились после поляков?

Ну, вот если глянуть те же Q&A начиная с 2008-го года, то все это новые фичи.

Из особо интересныех я бы выделил улучшение вывода типов позволяющиее использовать линк-ту-обжект. Поддержка линка. ComputationExpressions (async, yeild внутри выражений), оператор .?. ПМ по обычным объектам.

Специальным образом мы не делили Немерл на эпоху поляков и после них.

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

Мне это обсуждение надоело. Так что отвечу только на это:

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

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

Вот когда ты вместо того чтобы изрекать громкие фразы вроде "реализовали не подумав" (или как там?) начал продумывать реализацию, то с тобой стало можно общаться. Ты стал более адекватен. И заметь! Громкие оскорбительные выкрики сами собой исчезли сами собой.

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

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

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

V>>>Дык, ссылочные поля могут как раз могут перекрывать друг друга, и GC отлично работает. Эти ссылочные поля нельзя перекрывать нессылочными. Только ты GC все-равно не поломаешь, среда исполнения просто не загрузит такую сборку. Я же не зря упомянул процесс "упаковки". Должен быть внутри адресного поля объекта некий "пул" под объединение нессылочных и отдельно ссылочных полей.

H>>И еще, если мы имеем в варианте структуру, состоящую более чем из одного поля, а также без LayoutKind, то оптимизация опять же идет лесом.

V>Из-за этого очевидного аргумента я сделал пример чуть более избыточным, чем надо было. Просмотри еще раз на код, рассмотрен именно сей случай.

Я посмотрел внимательно. Я просто знаю, что sizeof можно вычислить в компайлтайме лишь для примитивных типов (int, double...). Попробуй в свой пример вместо int подставить GCHandle.

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

ВВ>>Обвертки так или иначе делать придется. Собственно, посмотри на F#. Хочешь писать в функциональном стиле — только через обвертки, без этого имеешь тупые tupled функции, с которыми ничего интересного не сделать.
A>Так в N вроде без оберток. Или но не функциональный?

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

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

VD>Из особо интересныех я бы выделил улучшение вывода типов позволяющиее использовать линк-ту-обжект. Поддержка линка. ComputationExpressions (async, yeild внутри выражений), оператор .?. ПМ по обычным объектам.

Что такое ПМ?

VD>Специальным образом мы не делили Немерл на эпоху поляков и после них.

Это понятно. Просто язык учил по польским талмудам + первые твои статьи.

ЗЫ. Поддерживаются ли фичи 4.0 фреймворка?

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

A>Это понятно. Просто язык учил по польским талмудам + первые твои статьи.

A>ЗЫ. Поддерживаются ли фичи 4.0 фреймворка?

DLR — нет. Но он не особенно востребован.

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

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

VD>>Из особо интересныех я бы выделил улучшение вывода типов позволяющиее использовать линк-ту-обжект. Поддержка линка. ComputationExpressions (async, yeild внутри выражений), оператор .?. ПМ по обычным объектам.

A>Что такое ПМ?

Pattern matching — сопоставление с образцом.

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

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

ВВ>>>Обвертки так или иначе делать придется. Собственно, посмотри на F#. Хочешь писать в функциональном стиле — только через обвертки, без этого имеешь тупые tupled функции, с которыми ничего интересного не сделать.
A>>Так в N вроде без оберток. Или но не функциональный?

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

Ну то что Ela вещь в себе ты согласен? Сначала глянул — вау, зашибись, а потом подумал — как его использовать?
По сути текст на входе — текст на выходе. Можно и так вообще-то, но если что-то посложнее строки текста — начинаются проблемы. Вот и предлагаю — сделай поддержку xml или json — будет проще объекты серелизовать.

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

VD>Это да. Но это не декларируется. Стало быть это будет закладывание на особенности реализации. Вот перепишут ЖЦ и что будет тогда?

Ничего не измениться. GC пользует информацию о типах времени исполнения, поэтому все ссылки для него аналогичны ссылкам на нетипизированный Object. Это принципиально, иначе как бы он работал, например, для полей типа Object?

VD>Еще как загрузит. Уж не знаю к счастью или к огорчению. Вот верификацию может такая сборка и не пройдет. Но верификация при запуске не делается.

Попробуй еще раз на 3.5. Опять же, я ломать не призываю. Наоборот — надо корректно распределять поля.

VD>Потом такая оптимизация изменит семантику. Ведь у вэлью-вариантов будет семантика копирования. Если для неизменяемых вариантов это еще как-то прокатит, то для изменяемых может привести к очень странным эффектам.

Таким же точно как и у обычных value-типов сейчас, когда некое св-во имеет value-тип. Например Rectangle Control::Bounds {get;}. Что в случае попыток изменения полей временных объектов говорит компилятор C# — этого вполне достаточно.

И замечание насчет иммутабельности — отличное. Есть ли возможность объявлять иммутабельные типы как таковые в N? Если есть — то это тоже первые кандидаты, даже со ссылочными полями.


VD>Да и по жизни это все не нужно. Варианты обычно используются для описания сложны структур данных. Обычно они являются рекурсивными. Тот мизерный процент простых вариантов просто не даст никакого эффекта (кроме усложнения компилятора).

Это потому что у вас такая область деятельности — компилятор писать. А сколько я видел примеров на том же Хаскель — приличная доля вариантов очень простые.

VD>Я прекрасно знаю семантику этого дела. В таком варианте работать будет. Только вот это ты для конкретного примера поля подобрал. В раельности все будет не так радужно. Будут вхождения только с вэлью-типами, а будут только со ссылочными. В итоге получим полное дублирование.

Логично, я же предложил явно управлять этой фичей, т.е. остаавить прежнее поведение по-умолчанию. Программист же сейчас каким-то макаром разбирается, где ему на шарпе писать class, а где struct. Разберется и тут. Это всё часть знаний о плюшках языка.


VD>Уже четрые поля размером по 32 бита делают делаю структуру невыгодной с точки зрения производительности.

Не прав. Зависит исключительно от сценариев. Можно подобрать сценарий, где и 8 байт будет неэффективно юзать по значению.

VD>Получается, что подобная оптимизация будет распространяться на очень малое количество применений.

Разумеется, как и все value-типы сейчас. Но речь идет о самых узких в плане эффективности местах, только там идут на все жертвы и неудобства, связанные с value-типами (а они дейсвительно очень неудобны в сравнении с классами в дотнете). Я вот экспериментировал прилично с мультимедиа на дотнете, так вот, многие сценарии без value-type просто не работают. Непрерывного выделения 100к объектов в секунду никакой GC не выносит, получаются паузы, влияющие на кач-во звука и плавность видео. На value-типах напротив, без проблем.

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

Для всяких протоколов discriminated union очень вкусная фича. Я же говорю — у вас специфика особенная. Одни AST вокруг.

VD>И вообще, говорить о производительности по синтетическим тестам и предполжения — это верх безрассудсва. Я этого уже наелся. Недавняя история с переводом вариантов на мсильныые switch-и очень характерна. Предположения об ускорении не оправдались ни на грош.

Не понял, вы начали переделывать код ДО экспериментов? Или тебя огорчил сам факт проведения эксперимента?

VD>Если ты считаешь свои предположения верными, я тебе могу предоставить полигон для исследований. Делай брэнч и реализуй свою идею. А там посмотрим во что это тебе станет, и что это даст на практике. Скомпилируем измененным компилятор компилятор же и посмотрим насколько изменилась его производительность. Уверен, что выхлоп будет нулевой. Но если я все же не прав, то я сниму шляпу и попрошу прощения.

Лучше поискать задачу с большим кол-вом маленьких АлгТД.

VD>Потому что это лишняя сущность не дающая ничего кроме производительности.

Логично.

VD>Пойми, если нужно создать очень быстырй код, то в нем просто не место ни вариантам, ни объектам, ни даже полиморфизму. Погляди на код который порождает тот же PegGrammar. Это ужасный код в стиле С времен К&Р. Но он действительно быстр!

На дотнете тоже можно писать быстрый код, поверь. Бесит лишь сценарий обработки массивов, когда массивы используются как предвыделенные буфера памяти, т.е. без возможности использовать оптимизацию for для массивов. Приходится пользовать unsafe для пробежки по памяти. В случае же обработки графов объектов, дотнет никакому нейтиву не уступает. И как везде, чем меньше косвенность, тем эффективнее.

VD>У немерла свой путь. Его путь — это очень высокий уровень при статическйо типизации с возможность, если надо, сгенерировать очень быстрый код.

И я так считаю, что все сложности — это внутреннее дело компилятора в итоге. А в жизни оно по-всякому бывает. Например, когда мы активно использовали тогдашний RFD, по моим замерам мы много теряли на нетипизированном чтении всех полей как object из db-ридера. Я еще тогда предлагал IT сделать матрицу типизированных ридеров, но был полный игнор сего предложения. В итоге, кое-как у себя для пары самых критичных мест сделали, на этом всё. Через 3 года они таки это сделали в BLT в общем виде, и тесты на производительность говорят сами за себя.

VD>Описанный код оптимизации правил работает именно во время компиляции.

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

А тесты можно и нужно провести ДО переделки компилятора. Т.е. подобрать пример, где будет много маленьких АлгТД, прогнать бинарник через рефлектор (подшаманить, где надо, чтобы рефлектор не спотыкался), восстановить в C# (ибо там value-type доступны), и уже там экспериментировать. Дорогостоящие по времени эксперименты никому не нужны.

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

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

A>>Это понятно. Просто язык учил по польским талмудам + первые твои статьи.

A>>ЗЫ. Поддерживаются ли фичи 4.0 фреймворка?

H>DLR — нет. Но он не особенно востребован.

Зря ты так. Cейчас изучаю ASP.Net MVC 3 — там без этого никак

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

H>Я посмотрел внимательно. Я просто знаю, что sizeof можно вычислить в компайлтайме лишь для примитивных типов (int, double...). Попробуй в свой пример вместо int подставить GCHandle.

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