Re[59]: В России опять напишут новый объектно-ориентированны - Компьютерные священные войны

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

_>Он сказал дословно:
_>

_>Да, для работы с массивами интов линк малополезен.

_>и предложил рассмотреть другие задачи. С которыми тоже в итоге оказалось всё гораздо сложнее, но там хотя бы было поле для дискуссии... )))
Опять нужно переводить с русского на русский? )) Малополезен — не означает "больше писать", это означает писать не сильно меньше.
Но самое интересное как раз в "других задачах", зачем их было выкидывать из цитаты? Заниматься фигурной резней по цитатам довольно забавный дискуссионный прием, но совершенно не конструктивный.

_>Потому как сказать нечего, так же как и в случае с более быстрым чем for linq? )))
Сказать есть много чего, но у меня тут италия, гарда, яхты, вино, гонки и другие, гораздо более привлекательные занятия, чем псевдотехнический срач, где оппонет выдергивает только выгодные цитаты. ))
У Антона не в пример больше терпения, поэтому я пока послежу, но оставляю за собой право вмешаться, если что...

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

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

_>Это неверная мысль, т.к. она следует из непонимания причин появления (точнее реинкарнации) nosql решений.
Ну давайте, расскажите мне о причинах реинкарнации nosql решений ))

_>Где там json/xml у какого-нибудь HBase или Redis'a? )))
да, вся мощщ nosql именно в key-value. )) вы же не предлагаете в сереьз выкинуть реляционные базы и заменить их на hadoop или еще какое key-value хранилище?

_>У linq есть множество очевидных недостатков. Причём как концептуальных (как раз связанных с моделью SQL), так и в реализации (динамическое построение выражений в рантайме, использование рефлексии и т.п.).
Ну это тема отдельной дискуссии, так ли эти недостатки очевидны )

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

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

_>- работа с коллекциями. Тут как раз главным недостатком является попытка использования модели SQL, которая в силу своей функциональной природы является сильно ограниченной по сравнению с классическим императивным кодом.
Ну, во-первых, мы так и не услышали, в чем же ограниченность функциональной природы SQL. Я было попытался это выяснить, но та дискуссия опять куда-то не туда зашла.
Во-вторых, во избежании дальнейших недоразумений, давайте определимся, "модель SQL" — это что? Декларативность, синтаксис или что-то еще?

_>Более того, используемая для работы с коллекциями реализация (IEnumerable) является даже более ограниченной (только последовательный доступ), чем классический SQL, для которого в СУБД происходит интерпретация в императивный код.
FYI, linq — не завязан на IEnumerable и не ограничен последовательным доступом.

_> Уже даже в этой дискуссии было упомянуто минимум три конкретных примера, в которых наблюдаются серьёзные проблемы: использования вычислений из соседних итерация ("строк"), использование отсортированных коллекций, использование коллекций типа деревьев и других вариаций на тему графов. А уж если вспомнить про множество задач с рекурсиями...
Уже в этой дискусии, было показано, что все это не является проблемой для линка.

_>В общем думаю тут можно придумывать такие примеры тысячами, просто в силу ограниченности изначального подхода.
Так в чем именно ограниченность?

_>Если рассматривать Linq, исключительно как генератор SQL (т.е. считая что SQL сам по себе идеален для любых подобных задач), то понятно что концептуально тут к Linq не может быть никаких претензий, банально в силу схожести моделей. Ну точнее в конкретных реализациях там до сих пор имеются проблемы (типа отсутствия поддержки CTE, оверхеда рантаймовой генерации на каждом запросе и т.п.), но вопрос был про концептуальные проблемы, а тут их очевидно нет.
Хорошо, хоть до этого договорились ))

_>Если же рассматривать Linq, как инструмент работы с СУБД, то тут Linq автоматически наследует все концептуальные проблемы SQL.
Так чтож за проблемы-то? )

_> Причём даже в ещё худшей степени, т.к. например большинство РСУБД помимо SQL поддерживают ещё какой-то свой императивный язык (интегрируемый с SQL), ну а у Linq с этим естественно никак.
Почему никак? Даже если отбросить сомнительную пользу этого подхода, то нет никаких проблем запихнуть в выражение произвольную (императивную) лямбду и даже попробовать поддержать ее на стороне сервера.

_> Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark).
И в чем тут у linq-а проблема? как раз наоборот, в силу декларативности можно поддержать распределенные, параллельные, перпендикулярные и какие угодно вычисления, не оглядываясь на особенности реализации

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

_>Ух как утомили эти глупости на пустом месте.
Ой, не говорите!

_>Простой вопрос: продукт под названием mysql появился в начале 90-ых или в конце?
Простой ответ: в контексте нашей дискусии, совершенно не важно когда он появился. Важно когда его начали делать и для чего.

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

_>>Мы же вроде вместе пошагово выяснили, что даже для реализации простейшего двоичного поиска по массиву int'ов тебе потребуется написать код разбора передаваемого тебе дерева предикатов, выполняющийся в рантайме. Какое тут ещё формирование кода компилятором и вообще какая-то эффективность?
S>Уфф. Тут опять происходит смешивание синтаксиса и реализации. В нынешнем C# — да, так и приходится делать, писать код разборки, выполняющийся в рантайме.
S>Его компилятор не содержит каких-либо средств, способных превратить where (p.Age >= 21) && (p.Name.BeginsWith("A") в .AgeIndex.Seek(21).Scan().Where(x=>x.Name.BeginsWith("A")).
S>Это не означает, что таких средств не может быть.
S>А если мы их применяем, то вместо дерева предикатов мы имеем вполне себе гражданский код, подверженный тому же инлайнингу и оптимизациям, что и аналогичная С++ реализация, выписанная вручную.

Ну так в таком случае у меня не будет никаких претензий по реализации. Хотя не уверен, что если подобное и реализуется когда-то, то оно станет тоже называться linq. )))

Кстати, я правильно понял, что ты под Linq подразумеваешь исключительно идею встраивания в язык SQL-подобного DSL, вне каких-либо привязок к определённым интерфейсам, языкам, платформам?

_>>Весь вопрос в том, как сделать это на этапе компиляции, а не в рантайме. На мой взгляд без подключения метапрограммирования не выйдет.
S>Вы так говорите, как будто это что-то плохое. Метапрограммирование в С++ работает с начала девяностых; Немерле так и вообще состоит из него чуть менее, чем полностью.

Ну собственно я тоже сторонник МП, если можно так выразиться. Нюанс в том, что текущие реализации Linq построены по сути без него (убогая рефлексия — это явно не то, что можно называть МП). Более того, в самом мире .net эта парадигма совсем не популярна (см. на тот же Nemerle).

S>Впрочем, меня не очень беспокоит вопрос применения метапрограммирования в рантайме — более того, я считаю эту тему весьма перспективной. Главное — уметь сохранять результаты.
S>То есть требовать перекомпиляции на каждую итерацию цикла — это, естественно, бред. Должны быть средства спекулятивной оптимизации — то есть мы проводим разбор дерева, трансформируем там всё, что надо, и прикапываем готовый результат вместе с guard conditions — предположениями, которые мы сделали при генерации. При следующем исполнении мы проходим сразу же по оптимизированному пути, избегая дорогостоящего этапа оптимизации.
S>Если guard conditions нарушаются — мы проходим по медленному пути. Если guard conditions нарушаются часто — мы выбрасываем оптимизированный код и выполняем оптимизацию заново.
S>Примерно так работают взрослые системы, рассчитанные на эксплуатацию 24*7.
S>Для настольного софта скорее всего будет более эффективна популярная ныне тема PGO.

PGO и т.п. — это конечно хорошо. Но я тебе уже не раз говорил, что это уже что-то вроде вишенки на торте. Т.е. в начале надо убедиться, что эффективно отработали все классические (статические) оптимизации, а уже потом можно задуматься об оптимизации под конкретные данные.

_>>Если у тебя в твоей конкретной задаче есть необходимость раскидать проверки абсолютно везде, то тебе никто не мешает вставить эту проверку в используемую тобой коллекцию (в тот же оператор [], если очень хочется). Ну и в любом случае совершенно непонятно какое это имеет отношения к обсуждаемому вопросу.
S>Прямое. Как только я вставил проверку в оператор [], так он сразу перестал быть эквивалентен *(+), в котором никакой проверки нет.

И что мешает добавить проверку и туда? )))

_>>Ну не только для них, но не суть. У меня то в примере был именно встроенный, не так ли?
S>Нет, у вас был iterator_range().begin(). Наверное, можно при помощи частичной специализации типизировать этот метод в int*, но в реальном коде (длиннее, чем hello world) гарантировать это довольно-таки затруднительно.

Причём тут частичная специализация? Оно в любом случае превращается в int* для встроенных массивов.

S>Потому что вы смотрите на строчку кода, которая выводит тип из окружения (auto it=begin(r)), и для получения точной информации о том, как устроен этот тип, вам надо определить тип r, просмотреть весь код begin, и так по цепочке. И завтра это может измениться, потому что ваш коллега закоммитил в репозиторий изменение, перейдя от int[] к vector<int> или ещё к чему-то.

Ну перейдёт он и что? От этого не появятся новые накладные расходы в том месте, которое мы обсуждаем. Нас же интересует не разница в коде между int[] и vector<int> (которой кстати тоже частенько может не быть, но это тема совершенно другой беседы). Нам важно чтобы не было никакой разницы между тупым кодом с int[] и кодом с range вокруг int[], и точно так же не должно быть разницы между кодом с vector<int> и range вокруг vector<int>. В таком случае, мы говорим, что абстракция range имеет нулевой оверхед.

_>>Да, в случае нетривиальной коллекции и отключённой оптимизации у нас будет call, а не обращение по адресу. Более того, это возможно и в случае включённой оптимизации, если код соответствующих операторов очень тяжёлый и оптимизатор решит что его невыгодно инлайнить. Но к обсуждаемому вопросу это отношения не имеет, т.к. моё утверждение было о "нулевом оверхеде", а не о какой-то конкретной ассемблерной инструкции. Ведь при использование нетривиальной коллекции с выключенной оптимизацией у тебя и при вызове a[] будет call.
S>В таком случае разговор об оверхеде не имеет смысла.

Почему?

S>Давайте вообще реализуем коллекцию в виде односвязного списка из пар {key, value}, оператор [] у нас будет работать как {for(i=head;i!=null;i=i.next} if (i->key == key) return i->value; throw new index_out_of_range()}.
S>И оператор + мы определим точно так же — даже не будем вызывать уже готовый [], чтобы избежать лишнего потенциального вызова.
S>"Оверхед", конечно же, будет по-прежнему нулевым. При этом код будет, мягко говоря, не вполне оптимальным в среднем случае.
S>Поэтому я термин "оверхед" не люблю, и предпочитаю пользоваться терминами performance и abstraction penalty.

Оверхед чего будет по прежнему нулевым? В твоём описание есть только некая специфическая коллекция и всё. Что с чем ты тут сравниваешь?

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

Вот жаль ты не ответил на самую интересную часть моего предыдущего сообщения, просто пропустив её. Хотя как раз эта часть и касалась по сути обсуждаемой изначально темы, в отличие от обсуждения hadoop'а, который тут только мимоходом затесался.

_>>Так я же уже кидал ссылки прямо в этой темке. Например вот эту https://www.cloudera.com/more/customers/bank-mandiri.html — стало считать 60 минут вместо двух суток. При этом затраты сократились до 1%. Мне кажется вполне очевидная причина... )))
S>(facepalm). Я выделил важное. Мне интересны технические детали. А вот этот вот маркетинговый булшит про удешевление в 100 и ускорение в 48 раз мне неинтересен.

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

Да, кстати, насчёт инсайда... А вот по поводу DWH построенных вокруг РСУБД он у меня как раз есть. Хотя это абсолютно не моя область деятельности, но я имел возможность мельком наблюдать за этим ужасом на рабочем ноуте знакомой, у которой есть доступ к DWH топового российского банка. Многостраничные уродливые запросы, часами генерирующие по ночам так называемые витрины... И за это убожество ещё и платятся неадекватные деньги всяким так Ораклам и т.п. Но ничего, думаю скоро и до них дойдёт прогресс. Во всяком случае там уже ходят слухи о поисках специалистов по hadoop и т.п.

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

_>> Более того, используемая для работы с коллекциями реализация (IEnumerable) является даже более ограниченной (только последовательный доступ), чем классический SQL, для которого в СУБД происходит интерпретация в императивный код.
MH>это ещё более спорное утверждение (если рассматривать linq именно как средство для работы с РСУБД). в linq реализация IEnumerable не используется. упрощённо можно считать, что IEnumerable<T> интерпретируется как источник данных (записей класса T), таблица например.

Вроде как ясно написано же, что в данном пункте речь идёт о работе с коллекциями (т.е. чем-то типа int[]), а не с РСУБД.

MH>да, РСУБД в рамках своей реализации sql поддерживают императивные возможности, но когда дело доходит до декларации/выполнения запроса к данным (именно sql) — сам запрос остается чисто функциональным (или может термин декларативный — тут больше подойдёт).
MH>но и linq ведь сделан в рамках языка общего назначения, а значит при построении linq-запросов, итерации по результатам можно использовать императивные приёмы, причём возможностей будет заметно больше. будет разница в том, что в 1-м случае это выполняется на сервере СУБД, во 2-м — на клиенте, но это IMHO не концептуальный недостаток, просто стоит учитывать.

Если linq научится отправлять прямо свой код (включая пользовательские лямбды) для выполнения на сервер, то это будет уже совсем другая история. Но это опять же будет возможно только при появление у СУБД какого-то иного интерфейса, помимо SQL. О чём собственно и была изначальная дискуссия.

_>>Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark).
MH>разве там используется какая-то другая концептуальная модель работы с данными, и не разновидность sql?
MH>полагаю что не другая, а значит это будет лиш вопрос реализации linq-провайдера к этой базе.

MapReduce очевидно не является разновидностью sql. ))) Более того, все эти императивные подходы очевидно являются более низкоуровневыми, чем декларативный подход sql. И соответственно можно относительно не сложно реализовать SQL интерфейс поверх того же Hadoop или Spark (и такие проекты есть), но не выйдет сделать обратное.

_>>Linq автоматически наследует все концептуальные проблемы SQL.
MH>ну раз уж упомянули про "концептуальные проблемы SQL", то было бы интересно услышать ваше видение их...

Эм, вроде как вся данная дискуссия про это. И я высказывался по этому вопросу уже не раз. )

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

_>Если linq научится отправлять прямо свой код (включая пользовательские лямбды) для выполнения на сервер, то это будет уже совсем другая история. Но это опять же будет возможно только при появление у СУБД какого-то иного интерфейса, помимо SQL. О чём собственно и была изначальная дискуссия.

В полной мере, это невозможно в принципе. Только если кастрировать linq максимально, включая не только соответствующие причиндалы, но и ручки-ножки, и голову, т.е. всё, что торчит. Проблема в том, что linq выражения, являясь полноценным кодом в терминах самого приложения, могут включать в себя фрагменты, уникальные только для этого приложения, о которых СУБД не имеет понятия.

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

_>>Он сказал дословно:
_>>

_>>Да, для работы с массивами интов линк малополезен.

_>>и предложил рассмотреть другие задачи. С которыми тоже в итоге оказалось всё гораздо сложнее, но там хотя бы было поле для дискуссии... )))
IB>Опять нужно переводить с русского на русский? )) Малополезен — не означает "больше писать", это означает писать не сильно меньше.
IB>Но самое интересное как раз в "других задачах", зачем их было выкидывать из цитаты? Заниматься фигурной резней по цитатам довольно забавный дискуссионный прием, но совершенно не конструктивный.

Оу, ну если у тебя такое понимание русского языка... То ты конечно же не испугаешься перейти к конкретному коду и его метрикам, не так ли? Потому как при беседе с Sinclair полного кода в теме не было, т.к. мы с ним оба приблизительно представляли его себе. Но раз у тебя особое мнение, то давай наконец перейдём от лозунгов и понтов к инженерным аргументам. Значит напомню обсуждаемую задачку: имеется отсортированный массив int[], требуется получить его подмассив со значениями между 0 и 1000, алгоритм должен работать не хуже чем O(log n). С данной задачкой легко справится школьник, вооружённый Паскалем или вообще Бейсиком. А что же сможет продемонстрировать вроде как профессионал, вооружённый вроде как идеальным инструментом для работы с коллекциями? ))) И да, естественно требуется полный компилируемый код, чтобы сравнить его с аналогичным императивным... )))

_>>Потому как сказать нечего, так же как и в случае с более быстрым чем for linq? )))
IB>Сказать есть много чего, но у меня тут италия, гарда, яхты, вино, гонки и другие, гораздо более привлекательные занятия, чем псевдотехнический срач, где оппонет выдергивает только выгодные цитаты. ))
IB>У Антона не в пример больше терпения, поэтому я пока послежу, но оставляю за собой право вмешаться, если что...

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

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

Не верный подход.

Вот смотри, в том же C++ компилятор уже давно научился создавать ассемблерный код эффективнее человека в большинстве случаев. Однако возможность встраивать произвольный ассемблерный код никто не убирает и она вполне себе используется в специфических случаях (например при работе с SIMD человек пока ещё частенько пишет более оптимальный код). Точно так же и с низкоуровневыми решениями из мира nosql. Поверх них легко можно накидать (и таких проектов есть множество, к большинству популярных nosql решений) высокоуровневый интерфейс в стиле SQL, покрывающий типовые задачи. Но при этом низкоуровневый доступ всё равно останется, позволяя легко реализовывать нестандартные или специально оптимизированные решения в нужных местах. А вот у классических РСУБД никакого низкоуровневого интерфейса что-то не видно, во всяком случае пока.

_>>Это неверная мысль, т.к. она следует из непонимания причин появления (точнее реинкарнации) nosql решений.
IB>Ну давайте, расскажите мне о причинах реинкарнации nosql решений ))

Всё очень просто: это отсутствие вменяемого масштабирования на множество узлов у sql решений.

_>>Где там json/xml у какого-нибудь HBase или Redis'a? )))
IB>да, вся мощщ nosql именно в key-value. )) вы же не предлагаете в сереьз выкинуть реляционные базы и заменить их на hadoop или еще какое key-value хранилище?

Вообще то этот подход (ключ-значение или ключ-документ или ключ-строка или даже ключ-функция — не суть) как раз и лежит в основе механизмов масштабирования на множество узлов.

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

_>>- работа с коллекциями. Тут как раз главным недостатком является попытка использования модели SQL, которая в силу своей функциональной природы является сильно ограниченной по сравнению с классическим императивным кодом.
IB>Ну, во-первых, мы так и не услышали, в чем же ограниченность функциональной природы SQL. Я было попытался это выяснить, но та дискуссия опять куда-то не туда зашла.

Вообще то это уже не раз тут проговаривалось, так что лень повторяться. Это я про общие положения. Но могу для разнообразия подкинуть ещё один примерчик для понимания. Простейшая, но очень нужная во многих областях задачка: имеем двухмерный массив чисел и надо получить из него новый массив, в котором каждая точка является средним от своих соседей (4-ёх или 8-ми, не суть). Что об этом скажет linq? )))

IB>Во-вторых, во избежании дальнейших недоразумений, давайте определимся, "модель SQL" — это что? Декларативность, синтаксис или что-то еще?

Всё вместе.

_>> Уже даже в этой дискуссии было упомянуто минимум три конкретных примера, в которых наблюдаются серьёзные проблемы: использования вычислений из соседних итерация ("строк"), использование отсортированных коллекций, использование коллекций типа деревьев и других вариаций на тему графов. А уж если вспомнить про множество задач с рекурсиями...
IB>Уже в этой дискусии, было показано, что все это не является проблемой для линка.

Ну это уже просто враньё.

_>>В общем думаю тут можно придумывать такие примеры тысячами, просто в силу ограниченности изначального подхода.
IB>Так в чем именно ограниченность?

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

_>> Причём даже в ещё худшей степени, т.к. например большинство РСУБД помимо SQL поддерживают ещё какой-то свой императивный язык (интегрируемый с SQL), ну а у Linq с этим естественно никак.
IB>Почему никак? Даже если отбросить сомнительную пользу этого подхода, то нет никаких проблем запихнуть в выражение произвольную (императивную) лямбду и даже попробовать поддержать ее на стороне сервера.

Вот если появится хоть одно подобное решение, то тогда и будем говорить. А пока что это всё исключительно фантазии. Я тоже могу тут написать что-нибудь вроде: "а я тут придумал гарантированно лучший язык программирования, у которого лёгкость написания Питона сочетается со статической верификацией в стиле Agda и всё это с быстродействием Ассемблера; осталась мелочь, всего лишь написать конкретную реализацию и можно захватывать мир".

_>> Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark).
IB>И в чем тут у linq-а проблема? как раз наоборот, в силу декларативности можно поддержать распределенные, параллельные, перпендикулярные и какие угодно вычисления, не оглядываясь на особенности реализации

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

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

_>Кстати, я правильно понял, что ты под Linq подразумеваешь исключительно идею встраивания в язык SQL-подобного DSL, вне каких-либо привязок к определённым интерфейсам, языкам, платформам?
По большому счёту да.
То есть штука, которая сочетает преимущества статической типизации (и вытекающие из неё плюшки типа рефакторинга), возможностей по декомпозиции, и динамического исполнения.
Современный linq уже лучше, чем тот же самый SQL, для работы с теми же RDBMS.
В нём всё еще трудно повторно использовать код — в частности, невозможно авто-типизировать методы, в которые мы хотим выносить интересные нам фрагменты.
В нём всё ещё крайне трудно переносить вычисления на сторону сервера — те же самые агрегаты. В идеале, для них нужно что-то типа iterator pattern, только наоборот. То есть из кода типа

public string Concatenate(IEnumerable<string> input, string delimiter = ", ")
{
  var s = string.Empty; // #1
  foreach(var i in input)
  {
    if (s.Length > 0) s+= delimiter; // #2
    s+=i;                            //
  }
  return s; // #3
}

мы автоматически порождаем код типа

class __Concatenate__aggregate
{
  private string s; 
  public void Init()
  {
    this.s = string.Empty; // #1
  }

  public void Accumulate(string i, string delimiter = ", ")
  {
    if (s.Length > 0) s+= delimiter; // #2
    s+=i;                            //
  }

  public string Terminate()
  {
    return s; // #3
  }
 
  public void Merge(__Concatenate__aggregate value)
  {
    Accumulate(value.Terminate());
  }
}

С попутными проверками на корректность — типа ассоциативности.

_>Ну собственно я тоже сторонник МП, если можно так выразиться. Нюанс в том, что текущие реализации Linq построены по сути без него (убогая рефлексия — это явно не то, что можно называть МП). Более того, в самом мире .net эта парадигма совсем не популярна (см. на тот же Nemerle).
Я не вижу принципиальной разницы между compile-time и run-time МП.

_>PGO и т.п. — это конечно хорошо. Но я тебе уже не раз говорил, что это уже что-то вроде вишенки на торте. Т.е. в начале надо убедиться, что эффективно отработали все классические (статические) оптимизации, а уже потом можно задуматься об оптимизации под конкретные данные.
Всё как раз наоборот. По крайней мере там, где касается данных. Там семантические оптимизации важнее "статических". То есть способность, к примеру, обнаружить в метаданных check constraint вроде order_date > date(2018, 1,1) позволяет нам мгновенно вернуть результат запроса where order_date < date(2017, 12, 1). На фоне этого умение заинлайнить вызов date() при вычислении предиката вообще выглядит экономией на спичках — ну получим мы миллион вызовов вместо двух миллионов. Там, где можно было обойтись десятком вызовов.

_>И что мешает добавить проверку и туда? )))
То, что указатель не оборудован длиной. В отличие от коллекции.

_>>>Ну не только для них, но не суть. У меня то в примере был именно встроенный, не так ли?
S>>Нет, у вас был iterator_range().begin(). Наверное, можно при помощи частичной специализации типизировать этот метод в int*, но в реальном коде (длиннее, чем hello world) гарантировать это довольно-таки затруднительно.

_>Причём тут частичная специализация? Оно в любом случае превращается в int* для встроенных массивов.
Вот тут моих способностей проводить в уме частичные вычисления не хватает. Каким именно образом у нас iterator_type превращается в int*?

_>Ну перейдёт он и что? От этого не появятся новые накладные расходы в том месте, которое мы обсуждаем. Нас же интересует не разница в коде между int[] и vector<int> (которой кстати тоже частенько может не быть, но это тема совершенно другой беседы). Нам важно чтобы не было никакой разницы между тупым кодом с int[] и кодом с range вокруг int[], и точно так же не должно быть разницы между кодом с vector<int> и range вокруг vector<int>. В таком случае, мы говорим, что абстракция range имеет нулевой оверхед.
Ок. А какой тогда у этой абстракции смысл? Я его что-то перестал улавливать.

S>>Давайте вообще реализуем коллекцию в виде односвязного списка из пар {key, value}, оператор [] у нас будет работать как {for(i=head;i!=null;i=i.next} if (i->key == key) return i->value; throw new index_out_of_range()}.
S>>И оператор + мы определим точно так же — даже не будем вызывать уже готовый [], чтобы избежать лишнего потенциального вызова.
S>>"Оверхед", конечно же, будет по-прежнему нулевым. При этом код будет, мягко говоря, не вполне оптимальным в среднем случае.
S>>Поэтому я термин "оверхед" не люблю, и предпочитаю пользоваться терминами performance и abstraction penalty.

_>Оверхед чего будет по прежнему нулевым? В твоём описание есть только некая специфическая коллекция и всё. Что с чем ты тут сравниваешь?
Я сравниваю O(1) c O(N). И не очень понимаю, зачем нам требовать одинаковости от операций адресной арифметики и операций индексации.

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

_>Так никто не мешает повесить поверх низкоуровневого "ручного" подхода (с императивным кодом) ещё и удобный высокоуровневый интерфейсе. Причём это можно сделать абсолютно тривиально, добавив простейшую функцию вида generate_code_by_sql(). Которую кстати можно сделать как на клиенте (как хотел тут vdimas), так и на сервере (как реализовано уже прямо сейчас и неявно вызывается при каждом sql запросе).

_>Вообще у нас тут несколько странная ситуация. В большинстве других областей программирования у нас всегда остаётся возможность добраться до низкого уровня. Т.е. развитие шло от некого базиса (исходящего от железа), до высокоуровневых абстракций. Но при этом доступ к низкому уровню всегда сохранялся. А в мире РСУБД у нас в качестве базиса используется уже весьма высокоуровневая абстракция, не позволяющая при надобности добираться до тонкой настройки (всяческие подсказки — это лишь жалкие костыли).
Прокомментирую вот этот вот момент, пропущенный в прошлый раз.
Во-первых, как справедливо заметил Иван, область применения "ручного привода" неуклонно снижается, по мере взросления индустрии. Вот, помнится, в ранних версиях С++ было ключевое слово register. Оно, возможно, и сейчас есть; но уже больше 20 лет оно никакой роли не играет — компилятор сам знает, какие переменные сложить в регистры, а какие оставить на стеке. То есть, "помогать" компилятору надо всё меньше и меньше.
Во-вторых, этот "ручной привод" постепенно начинает мешать. Он мешает программисту: например, в СУБД я могу пойти и добавить или убрать индекс, будучи спокоен за корректность кода. В предлагаемом вами императивном случае изменение критерия сортировки массива нахрен сломает весь код, и это невозможно даже обнаружить без тщательного тестирования. Почему? Потому, что компилятор не в курсе о моём "ручном приводе", он не может мне помочь.
И компилятору "ручной привод" тоже мешает — скажем, если бы мы требовали буквального исполнения модификатора register, то компилятор был бы вынужден жертвовать производительностью в тех случаях, когда он "знает лучше".

Каждый раз, когда мы навязываем среде свой способ исполнения, мы связываем ей руки. "Ой, хозяин наверное умный, он лучше знает" — вынуждена думать среда. Ассемблерный код, оптимальный для 80386, будет нифига не оптимальным для Пентиума. Но раз программист написал на ассемблере — мы вынуждены делать то, что он написал.
Хуже того — даже тот код, который написан на "высокоуровневом" интерфейсе рядом с "низкоуровневым", будет страдать.
Казалось бы — ну что там можно напороть в коде, который выполняет только чтение? Можно забыть применить нужные блокировки. Точнее, подумать, что "вот здесь они не нужны, потому что мне известно то, что не хранится в метаданных".
А завтра кто-то взял и применил этот код в другом месте — а чего? Вот у нас метод, который проверяет остатки на счетах. И вот у нас метод, который выполняет проводку — зачем нам дублировать код? Вызовем уже отлаженный метод проверки остатков. А послезавтра у нас изменились предположения, на основе которых мы делали оптимизацию, и в итоге в базу уезжает мусор. Иногда, но уезжает. И мы тратим месяцы на анализ race conditions, чтобы найти виновника — потому что каждый кусок кода выглядит полностью корректным. И даже почти всегда всё работает — косячит только под нагрузкой, и только когда данных много — то есть как раз тогда, когда хрен ты это отловишь в динамике.

Я бы хотел двигаться строго в противоположную сторону — чтобы движок видел весь код транзакции сразу, и сам выбирал стратегию удержания локов. Там, где нет повторных чтений — вот вам read committed, то есть отпускаем по мере чтения.
Там, где через строчку будет изменение — сразу захватываем update lock. Там, где мы перечитываем данные по многу раз — выполняем hold lock, т.е. делаем repeatable read.
В итоге у нас всё ещё гарантированная сериализуемость, но без снижения concurrency.

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

V>Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.

Интересные темы вы тут манчите, братва, ничего, если я тоже пару вопросиков подкину?

V>Этих курсов было как минимум 3 сильно разных.
V>Так перед кем ты опять пытаешься надуть своё ЧСВ?

V>Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.

АУТСники и ПОшники, ага!

V>Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))

V>Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.

ВМщики, понятно!

V>Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.

V>Чисто для сравнения (кому любопытно).

<поскипано>
То есть, я не понял: системных программистов только на ВМ готовили, а на ПО — нет? Хм..

V>Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.

V>На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".

<скип>

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

Значит ли это, что под каждую конкретную задачу системный аналитик создаёт новую, неповторимую модель велосипеда, вместо того, чтобы взять и адаптировать одну из существующих моделей? Например, если существующие СУБД не устраивают, то системный аналитик пишет новую СУБД?

V>"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
V>Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))

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

V>Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной причине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.

То есть, только ВМщик может стать "низкоуровневым системщиком", я правильно понял?

V>Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))

Есть такая буква в этом слове. Добавляешь константу — и индекс идёт лесом. Это имелось в виду? И с кучей одинаковых планов — тоже похоже на правду. Однако же, один запрос на разных базах (одной структуры), или даже на одной базе, но сделанный в разное время, может иметь разные планы. Как ты предлагаешь на этапе компиляции (или когда вообще?) определять, какой из планов этого конкретного запроса будет наиболее оптимальным в каждом конкретном случае? Реально же даже набор индексов может различаться от базы к базе, не только распределение данных.

V>Но хрен с ним, идём далее.
V>Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).

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

V>Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.

SCD — slowly changing dimensions? Или ты о том, что иногда называют "user dictionaries" и часто засовывают в одну-две таблицы (это просто сопоставление текстовой семантики какому-то числу, типа 1-накладная, 2-счет-фактура, и т.п.)? Если второе — мне не кажется, что это представляет большую проблему. Да, запросы становятся более объёмными, но сами эти таблицы весьма небольшие, поэтому с большой вероятностью постоянно висят в кэше данных.

V>Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.

Всё ешё не понятно, как ты собираешься подстраиваться под конкретную систему индексов и конкретное распределение данных в конкретное время.

V>И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))

Не, на самом деле, тема достаточно интересна. Разумеется, Секвел вовсе не единственный свет в окошке, те же NoSQL базы вполне живут себе и здравствуют, но — при вполне определённых условиях.

V>Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.

Правильно я понимаю, что ты предлагаешь всегда использовать rule-based оптимизацию, и не использовать cost-based?

V>>> если предположить гипотеитческий вариант "все запросы известны заранее".

Многовато будет запросов. Один и тот же запрос, с помощью добавления/удаления предикатов и изменения сортировки можно превратить в сотню. Хотя, в общем, да, большинство запросов известно заранее.

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

_>Вообще то это уже не раз тут проговаривалось, так что лень повторяться.
Так в том-то и дело, что не проговаривалось. Ну если только не считать туманные намеки на некие концептуальные проблемы.

_> Это я про общие положения. Но могу для разнообразия подкинуть ещё один примерчик для понимания. Простейшая, но очень нужная во многих областях задачка: имеем двухмерный массив чисел и надо получить из него новый массив, в котором каждая точка является средним от своих соседей (4-ёх или 8-ми, не суть). Что об этом скажет linq? )))
Опять конкретный пример, решение для которого будет не сильно отличаться от решения для предыдушей задачки про пару значений, текущее и предыдущее.
Концептуальность-то в чем? Пока вы занимаетесь тем, что пытаетесь высосать примеры, которые были бы для linq-а не удобны (встречаемость таких примеров в реальной жизни — отдельный вопрос), но и примеры довольно странные и фундаментальную проблему линка что-то не получается сформулировать.

IB>>Во-вторых, во избежании дальнейших недоразумений, давайте определимся, "модель SQL" — это что? Декларативность, синтаксис или что-то еще?
_>Всё вместе.
тогда нужны отдельно притензии к декларативности, отдельно к синтаксису, отдельно к чему-то еще, а то опять каша получится — ответ про одно, вопрос про другое.

_>Ну это уже просто враньё.
Вранье, то что это вранье ))

_>Ну раз никакой ограниченности нет, то совершенно непонятно что же останавливает тебя в демонстрации решений озвученных простейших задачек.
Раз ограниченность есть, то ничто не останавливает в том, чтобы ее сформулировать. Жду )

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

_>>> Что уж тут говорить о поддержке наиболее активно развиваемых сейчас распределённых вычислений (СУБД на базе hadoop и т.п.), в которых уже даже MapReduce становится устаревшим (см. Spark).
IB>>И в чем тут у linq-а проблема? как раз наоборот, в силу декларативности можно поддержать распределенные, параллельные, перпендикулярные и какие угодно вычисления, не оглядываясь на особенности реализации
_>В том, что ты не сможешь использовать все возможности этих систем. Тебе будет доступно только грубо говоря их sql подмножество.
Почему? В соседнем сообщении вы же сами пишите, что sql (а у нас даже не sql, а linq) — это более высокий уровень абстракции, и можно использовать хадуповские и другие map-reduce подобные низкоуровневые конструкции для получения нужного результата. Вы уж определитесь.

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

_>Оу, ну если у тебя такое понимание русского языка...
Да, с языком у меня все хорошо, спасибо )

_> То ты конечно же не испугаешься перейти к конкретному коду и его метрикам, не так ли?
Нет, не испугаюсь, но не ощущяю необходимости. ))

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

_>Не верный подход.
как раз единственно верный.

_>Вот смотри, в том же C++ компилятор уже давно научился создавать ассемблерный код эффективнее человека в большинстве случаев. Однако возможность встраивать произвольный ассемблерный код никто не убирает и она вполне себе используется в специфических случаях (например при работе с SIMD человек пока ещё частенько пишет более оптимальный код). Точно так же и с низкоуровневыми решениями из мира nosql. Поверх них легко можно накидать (и таких проектов есть множество, к большинству популярных nosql решений) высокоуровневый интерфейс в стиле SQL, покрывающий типовые задачи. Но при этом низкоуровневый доступ всё равно останется, позволяя легко реализовывать нестандартные или специально оптимизированные решения в нужных местах. А вот у классических РСУБД никакого низкоуровневого интерфейса что-то не видно, во всяком случае пока.
Ну вот вы же сами прекрасно описали все тренды на примере C++ — количество ручного вмешательства постепенно уменьшается. То же самое будет происходить и с nosql, с теми, которые до этого доживут.
Поэтому я совсем не улавливают логики в вашей аргументации, она скорее полностью подтверждает мой тезис.

_>Всё очень просто: это отсутствие вменяемого масштабирования на множество узлов у sql решений.
У sql решений с масштабируемостью на множество узлов не то чтобы все идеально, но есть что предложить. Причиной появления nosql стало появление класса задач, для которых отказоустойчивость не нужна, зато важна скорость в виду обьшего объема данных. масштабируемость и параллельность это уже следствие.

_>Вообще то этот подход (ключ-значение или ключ-документ или ключ-строка или даже ключ-функция — не суть) как раз и лежит в основе механизмов масштабирования на множество узлов.
Да, но причем тут масштабирование?

Gt_>>речь про параллелизм на разных нодах, но у меня и на десктопе с одним хдд в виртуалке хадуп заметно опережает. из рдбмс только db2 имеет федеративный кластер, но что-то не видно что бы эта ерунда хоть где-то использовалась реально. реально никто так не использует рдбмс, т.к. накладные расходы убивают весь смысл.
S>Не очень понятно, откуда берутся накладные расходы. Есть подозрение, что всё это — неуловимый Джо. Т.е. RDBMS умеют аналогичную функциональность в какой-то степени; могли бы и дальше развивать — но реального спроса нет, потому нет и мотивации развиваться.

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

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

сейчас у хадуп стека появились и другие подходы со spark, impala, kudu, но все равно под низом и новых подходов во многом идеология map-reduce.

S>Ну вот из описания монгодб возникает жосткое ощущение заката солнца вручную. Причём весь юмор — в том, что релизы монги последовательно приближают её к взрослой RDBMS как по функциональности, так и по производительности. Потому что чудес-то не бывает, и если мы коммитом называем коммит, то будь любезен сбегать в HDD и дождаться подтверждения. А пока мы коммитом называем то, что "в случае сбоя питания данные пропадут не более чем за 15 секунд", подвинуть RDBMS в OLTP никак не получится.

по моему у монго идея атомарного сохранения документа, т.е. тот самый развесистый объект запихиваешь данные со всех таблиц рдбмс и получаешь в принципе годную во многих задачах схему. что касается сбегать на hdd — это не единственный вариант, всякие in memory grids предлагают дублировать транзакции по нодам и надеяться, что все копии разом не упадут. если узлы в разных датацетрах, вполне может прокатить схема.

Gt_

От:	Sinclair	https://github.com/evilguest/
Дата:	07.05.18 06:13
Оценка:

От:	IB	http://rsdn.ru
Дата:	07.05.18 10:24
Оценка:	+1 -1

От:	IB	http://rsdn.ru
Дата:	07.05.18 10:43
Оценка:	+2

От:	IB	http://rsdn.ru
Дата:	07.05.18 11:01
Оценка:	-1

	От:	alex_public
	Дата:	07.05.18 13:26
	Оценка:

	От:	Ночной Смотрящий
	Дата:	08.05.18 18:52
	Оценка: