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

_>Советую тебе прикупить словарь Даля и ознакомиться там с понятием "вдохновения". )))
Советую не советовать, а научиться выражаться так чтобы понимали окружающие ))
Хоть с "вдохновением" хоть без, смысл не меняется.

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

_>Смотря где. В определённых областях естественно никогда не будет перехода, т.к. они идеально ложатся на РСУБД. А в каких-то процесс идёт...
Да что-то не идет уже, по этому же графику и видно.

_>Очень аргументированно. )))
Ну блин. В MySQL не было ни consistency, ни durability и вообще хоть какого-либо ACID и поддержки транзакций до встраивания InnoDB. Мне казалось, что это достаточно известный факт, чтобы его нужно было здесь упоминать.

_>Как раз на днях встретилась в рассылке статья: https://habrahabr.ru/post/353008/. Кстати, в случае с крупнейшем банком Индонезии там указано не просто масштабное внедрение, но и как раз замена РСУБД с огромной выгодой... )))
Пффф, опять BigData, да еще вот:

Источниками данных для технологического решения по прежнему остаются 27 реляционных БД, профайлы клиентов, данные о транзакциях по пластиковым картам и (как ожидаемо) данные социальных сетей

Какая же это замена?

_>>Очень аргументированно. )))
IB>Ну блин. В MySQL не было ни consistency, ни durability и вообще хоть какого-либо ACID и поддержки транзакций до встраивания InnoDB. Мне казалось, что это достаточно известный факт, чтобы его нужно было здесь упоминать.

innodb был у mysql еще 16 лет назад, т.е. за много, много лет до того как в mssql появилось нормальное consistency. достаточно известный факт, до IL snapshot лишь в mssql2005 появился и до сих пор прикручен сбоку, через tempdb. так что ты не прав, а у mysql все так, уже второе десятилетие.

_>>Как раз на днях встретилась в рассылке статья: https://habrahabr.ru/post/353008/. Кстати, в случае с крупнейшем банком Индонезии там указано не просто масштабное внедрение, но и как раз замена РСУБД с огромной выгодой... )))
IB>Пффф, опять BigData, да еще вот:
IB>

IB>Источниками данных для технологического решения по прежнему остаются 27 реляционных БД, профайлы клиентов, данные о транзакциях по пластиковым картам и (как ожидаемо) данные социальных сетей

IB>Какая же это замена?

обычная замена реляционного DWH, на хадуп

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

Gt_>innodb был у mysql еще 16 лет назад, т.е. за много, много лет до того как в mssql появилось нормальное consistency.
Ох.. Вы, наверное, под Consistency понимаете что-то свое, но в MSSQL она была еще пока он был Sybase-ом, равно как и остальной ACID.
Что же касается MySQL, то с рождения там был MyISAM, и он оставался дефолтным до совсем недавнего времени. И естественно, ни о какой ACID-ности там и речь не шла. (Напомню, что в обсуждаемой статье разговор был не о том как дела у MySQL сейчас, а о том, для чего MySQL был придуман. Так вот, учитывая MyISAM, ни о какой Consistency при создании MySQL даже не подозревали).
Относительно InnoDB, тоже, кстати, забавно. Сначала мужик, который его придумал, сунулся в MS продать это как движек транзакций для сиквела, где ему популярно объяснили, что эта конструкция не сильно ушла от MyISAM, и даже текущая реализация сиквела на много удачнее, после чего он и подался в опенсорс, так как никто из взрослых дядек его усилий не оценил. Подозреваю, что он и к другим ходил, но достоверно знаю только про MS.

Gt_>достаточно известный факт, до IL snapshot лишь в mssql2005 появился и до сих пор прикручен сбоку, через tempdb.
Не знаю к чему вы тут упомянули snapshot, надеюсь, вам не надо объяснять, что чистый snapshot как раз не гарантирует Isolation и, как следствие, Consistency?
О том, что качество реализации этого режима в MSSQL намного лучше, чем у большинства движков где он был изначально, не смотря на упоминание tempdb в документации, я даже рассказывать не буду, это уж совсем далеко от темы топика.

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

Gt_>>innodb был у mysql еще 16 лет назад, т.е. за много, много лет до того как в mssql появилось нормальное consistency.
IB>Ох.. Вы, наверное, под Consistency понимаете что-то свое, но в MSSQL она была еще пока он был Sybase-ом, равно как и остальной ACID.

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

IB>Что же касается MySQL, то с рождения там был MyISAM, и он оставался дефолтным до совсем недавнего времени. И естественно, ни о какой ACID-ности там и речь не шла. (Напомню, что в обсуждаемой статье разговор был не о том как дела у MySQL сейчас, а о том, для чего MySQL был придуман. Так вот, учитывая MyISAM, ни о какой Consistency при создании MySQL даже не подозревали).

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

IB>Относительно InnoDB, тоже, кстати, забавно. Сначала мужик, который его придумал, сунулся в MS продать это как движек транзакций для сиквела, где ему популярно объяснили, что эта конструкция не сильно ушла от MyISAM, и даже текущая реализация сиквела на много удачнее, после чего он и подался в опенсорс, так как никто из взрослых дядек его усилий не оценил. Подозреваю, что он и к другим ходил, но достоверно знаю только про MS.

учитывая что у innodb полноценный UNDO, а в сиквеле порно в tempdb со сборкой мусора, твоя байка далека от истины.

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

в цитате речь об источниках данных, а не субд что заменили. там же в цитате ссылка на кейс с подробностями
Before Cloudera, it could take two days to prepare data, but with Cloudera, within 60 minutes it can be ready for our management,” said Muhamad Guntur, SVP of enterprise data management at Bank Mandiri. “And the cost, compared to using a relational database, is about 1 to 100; that’s 99 percent cost savings versus other systems.”

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

Gt_>до mssql2005 все было очень печально, блокировочный RC выдает неконсистентную кашу, а все что выше RC бесполезно в реальной жизни т.к. утопает в блокировках и дэдлокоах.
В блокировках, дедлоках и неконсистентной каше утопяют только базы в чьих-то неудовлетворенных фантазиях. У MSSQL проблем с консистентностью не было ни до 2005-го ни после, равно как и у DB2, Sybase-а и других блокировочников, у которых версионного режима нет до сих пор. В прочем, это опять-таки сильно выходит за границы топика и не имеет никакого отношения к консистентности и поддержке ACID в базах.

Gt_> в реальной жизни на mssql все так и сидят с неконсистетной кашей на дефолтном RC.
В реальной жизни все сидят на RC и блокировочники и версионники, что не мешает ни тем ни другим быть консистентными при прямых руках разработчика. В отличии от MyISAM, где что бы ты не делал, в любой момент сервер может сказать что устал, и бросить транзакцию на половине.

Gt_>mysql изначально был придуман как база с разными энжинами, с различными свойствавами.
Разработчики MySQL сильно удивились бы узнав об этом =) FYI изначально MySQL создавался как SQL обертка над ISAM API. Целью создателей было сделать более быстрый и универсальный API для работы с ISAM базами, коим и явился SQL. И вот это как раз имеет прямое отношение к топику )

Gt_>учитывая что у innodb полноценный UNDO, а в сиквеле порно в tempdb со сборкой мусора, твоя байка далека от истины.
Далеки от истины ваши претензии к tempdb, а это реальная история — я в то время как раз общался с разработчиками сиквела и знаю из первых рук.
Ну и в любом случае, это не имеет отношения к поддержке ACID (если не считать, что версионники не гарантируют 100% изоляции) и точно выходит за границы обсуждаемой темы.

Gt_>в цитате речь об источниках данных
Так и я писал об источниках данных.

Gt_> “And the cost, compared to using a relational database, is about 1 to 100; that’s 99 percent cost savings versus other systems.”
Имея представление о том как ведется бизнес в индонезии, я понимаю на чем они на самом деле с экономили =)

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

_>>Так а где там область видимости этого самого "структурного типа"? В случае await оно вообще в куче создаётся и потом вызывается из цикла обработки сообщений или вообще другого потока. В случае yield я сам не проверял — у тебя есть точные данные, что оно размещается на стеке и при этом в области видимости вызывающего цикла? )
S>Сейчас — нет. Там генерируется reference type, и размещается в куче.

Ужас какой. Хотя я именно такое и предполагал, из знаний работы await.

S>Поэтому для агрессивной оптимизации нужен ещё и escape analysis. Всё опять упирается в инлайнинг, т.к. без него даже и со структурным типом не удалось бы сделать ничего полезного.

Лучше уж тогда не escape analysis, а нормальное статическое размещение переменных на стеке компилятором.

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

_>>Да простейшее дерево, типа такого:
_>>

_>>struct node_t{
_>>    value_t value;
_>>    list<node_t> childs;
_>>};
_>>

S>И как выглядит сигнатура метода, который нужно написать?
S>Интуитивно ожидаемая int Distance(node_t &node1, node_1 &node2) нереализуема в такой архитектуре.

Ты забываешь, что задаётся ещё собственно сама коллекция. В случае дерева это обычно реализуется через задание root node.

_>>Ээээ что? Какое ещё SortedList? Зачем нам этот жирный тормоз? Смотри, вот буквально детская задачка из самых основ работы с коллекциями: имеем простейший int[], заполненный отсортированными значениями. Надо получить его подмассив, находящийся в пределах значений от 0 и до 1000. Я могу это сделать на linq за логарифмическое, а не линейное время?
S>Да, конечно. Но всё равно как-то придётся объяснить инфраструктуре, что массив отсортирован. Телепатия ведь не работает.
S>Если вы хотите иметь возможность стрелять себе в ногу в обычной "эгей!эгей!" манере нативных программистов, то достаточно сделать тонкую обёртку типа
S>

S>public static SortedArray<t> AsSorted(this T[] alreadySortedArray)
S>  where T:IComparable<T>
S>{
S>   // skip sorting, just store the reference to the original array
S>  _array = alreadySortedArray;
S>}
S>

S>Далее — по тексту:
S>

S>var test = new int[]{1, 6, 10, -150};
S>var splice = from a in test.AsSorted() where a >= 0 && a <1000 select a;
S>

Некорректный код, т.к. у тебя массив не отсортирован. ))) Ну да ладно. )))

Я правильно понимаю, что здесь ещё не хватает кода самого SortedArray и плюс кода для where по SortedArray (представляющего собой как раз тот самый императивный код, только намного неудобнее)?

И если я правильно всё понял, то тогда сразу же возникает вопрос: а зачем тут собственно Linq, для лишнего усложнения? )))

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

_>>В таком случае тебе конечно же будет совсем не трудно дать ссылку на соответствующую цитату... )
IB>В соседнем же сообщении. )

Так ссылочка то будет, на моё предложение заменить SQL на язык из MongoDB? )

_>>Пока что в данной дискуссии пытаешься съезжать в основном ты. Достаточно вспомнить тот твой нелепый тезис о том, что работа с коллекциями через Linq может быть быстрее аналогичного императивного кода.
IB>Не любого, а for, выяснили же. И опять съезд на тот же for, вместо ответа на текущее замечание )

А какой ещё может быть императивный код для обработки коллекции, если не for? Что за жалкие увиливания?

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

Он описал крайне забавную ситуацию, в которой при изменение условий задачи Linq код успели оптимизировать под новые условия, а императивный код не успели. И поэтому неисправленный императивный код естественно оказался медленнее исправленного Linq. Выдавать подобный сценарий в качестве аргументации — это конечно очень смешно и наивно.

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

_>>Не улавливаешь: Linq просто не имеет прямого отношения к обсуждаемому вопросу. Для общения с СУБД в любом случае необходимо нечто (язык, протокол, api — называй как хочешь), что будет отсылаться клиентом на сервер для описания запросов. И даже если для Linq появится новый бэкенд, работающий на этом новом нечто, Linq не будет иметь никакого отношения к обсуждаемому в данной дискуссии вопросу. Потому что заменой SQL будет именно это нечто, а не Linq.
IB>Я кажется понимаю кто тут чего не улавливает... Не имеет никакого значения что именно ползает между клиентом и сервером. Важно на чем разработчик пишет свой запрос и какой результат он при этом получает.

Это ты всего лишь высказал очередной свой сомнительный (к нему элементарно подобрать контрпример в виде отбирания у SQL какой-нибудь функциональности и потом наблюдения за работой linq в таких условиях) тезис. Без аргументации (почему одно имеет значение, а другое нет) он ничего не стоит.

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

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

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

Что-то незаметно. Тот же Sinclair, хотя и спорит со мной или вдимасом по разным вопросам, но некоторые его претензии к SQL тоже можно легко увидеть в данной теме. А от тебя тут пока что была видна исключительно яростная защита SQL по всем вопросам.

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

_>>Очень аргументированно. )))
IB>Ну блин. В MySQL не было ни consistency, ни durability и вообще хоть какого-либо ACID и поддержки транзакций до встраивания InnoDB. Мне казалось, что это достаточно известный факт, чтобы его нужно было здесь упоминать.

О, я смотрю от изначального тезиса, что "у MySQL проблемы с consistency и availability" мы незаметно попытались перейти к новому тезису, что "у MySQL были проблемы с consistency и availability до определённой версии". А можно теперь озвучить в какому году появилась та версия (в которой добавили InnoDB), начиная с которой проблем нет?

_>>Как раз на днях встретилась в рассылке статья: https://habrahabr.ru/post/353008/. Кстати, в случае с крупнейшем банком Индонезии там указано не просто масштабное внедрение, но и как раз замена РСУБД с огромной выгодой... )))
IB>Пффф, опять BigData, да еще вот:
IB>

IB>Источниками данных для технологического решения по прежнему остаются 27 реляционных БД, профайлы клиентов, данные о транзакциях по пластиковым картам и (как ожидаемо) данные социальных сетей

IB>Какая же это замена?

Так заменили на Cloudera(разновидность Hadoop) не все РСУБД, а только часть (и в данной цитате отмечено, какие БД не стали заменять). И это логично, т.к. далеко не для всех БД это полезно. Однако ты тут утверждал, что подобных переходов никто не делает в принципе.

по факту даже у myisam все многократно лучше c консистентностью, хотя бы потому что mysisam никогда не выдаст набор, где фигурирует одна и та же запись несколько раз, а блокировочный RC от mssql запросто может по мере чтения выдать порно с одной и той же записью, если запись во время чтения проапдейтили. и read uncommitted в блокировочниках не от хорошей жизни, а именно из-за утопания в блокировках и дедлоках. mysql читать uncommitted записи в голову не приходит, там такого режима в принципе нет.
байки про разработчиков веселые, но я то помню что именно в тот период мы ржали с ваших перлов в oracle bloking problem. помню и того товарища, с "привета"/майкрософт с росказнями о IL snapshot. жаль что он позабыл поведать о перфоменсе tempdb и сборе из него мусора на IL snapshot. но собственно история уже все расставила по местам и вопрос был "А что у MySQL с этим не так?" не в далеком прошлом, и не про myisam.

Gt_>>в цитате речь об источниках данных
IB>Так и я писал об источниках данных.

здорово, но тебе указывали на кейс замены реляционного DWH, а не его источников

Gt_

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

_>Ужас какой. Хотя я именно такое и предполагал, из знаний работы await.
Если честно, я не понял, зачем там генерируется референс-тип. Вполне хватило бы структурного типа.
Тогда инлайнинг бы автоматически получал то, что нужно.

_>Лучше уж тогда не escape analysis, а нормальное статическое размещение переменных на стеке компилятором.
Вы имеете в виду порождение структурного типа? Потому что "нормальное статическое размещение" для переменных референс-типа — это и есть escape-analysis.

_>И да, при условие правильного размещения локальной переменной, представляющей собой экземпляр структуры бесстековой сопрограммы, на C++ подобный коде действительно мог бы оптимизироваться до своего императивного аналога (если забыть, что что автоматической генерации компилятором бесстековых сопрограмм в стандарте C++ пока нет). Только непонятно какое это имеет отношение к дискуссии, т.к. Linq в C++ не нужен (есть более удобная замена под названием Ranges).
Ну, если ranges умеют аналогичный синтаксический сахар — то отлично.

_>Ты забываешь, что задаётся ещё собственно сама коллекция. В случае дерева это обычно реализуется через задание root node.
Тогда всё ещё проще. Завтра напишу.

_>Некорректный код, т.к. у тебя массив не отсортирован. ))) Ну да ладно. )))
Вот и я об этом. Именно для этого нам нужен SortedList, а не просто "массив, который наверное уже отортирован.
_>И если я правильно всё понял, то тогда сразу же возникает вопрос: а зачем тут собственно Linq, для лишнего усложнения? )))
В основном для того, чтобы отделить намерения от реализации.
Вам просто кажется, что главное — реализация, поэтому хочется видеть в программе "произвольный императивный код".
А я считаю, что главное — намерения. А реализацию я хочу менять по мере уточнения нефункциональных требований.

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

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

V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.

Джаваскрипт тоже был "сущностью второго рода" лет 15 назад и безбожно генерировался, а сейчас он — король.
SQL уже существует лет 40 и только развивается. Почти всё, что, как вам кажется "в SQL делать очень сложно", сейчас делается очень просто.
Ах да, SQL простудится на похоронах почти всего новомодного говнища, ибо скилы в SQL растут в цене со временем, чего не скажешь о других платформах.

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

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

_>Я же тебе уже говорил, что это только если исходить из предположения убогого процесса разработки в котором требования определяются сроками. В реальности в нормальном процессе разработки всё наоборот: в начале определяются нужные требования, а потом под них определяются нужные сроки.

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

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

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

_>>Ужас какой. Хотя я именно такое и предполагал, из знаний работы await.
S>Если честно, я не понял, зачем там генерируется референс-тип. Вполне хватило бы структурного типа.
S>Тогда инлайнинг бы автоматически получал то, что нужно.

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

_>>Лучше уж тогда не escape analysis, а нормальное статическое размещение переменных на стеке компилятором.
S>Вы имеете в виду порождение структурного типа? Потому что "нормальное статическое размещение" для переменных референс-типа — это и есть escape-analysis.

Ммм, при слове escape-analysis у меня появляется ассоциация исключительно с соответствующим механизмом в Java, который работает как раз не на уровне компилятора, а на уровне виртуальной машины (причём ещё и на вероятностных принципах, анализируя рантаймовые параметры). Если ты имел в виду что-то другое (статическое, на этапе компиляции), то значит у нас тут просто небольшое рассогласование в терминологии.

_>>И да, при условие правильного размещения локальной переменной, представляющей собой экземпляр структуры бесстековой сопрограммы, на C++ подобный коде действительно мог бы оптимизироваться до своего императивного аналога (если забыть, что что автоматической генерации компилятором бесстековых сопрограмм в стандарте C++ пока нет). Только непонятно какое это имеет отношение к дискуссии, т.к. Linq в C++ не нужен (есть более удобная замена под названием Ranges).
S>Ну, если ranges умеют аналогичный синтаксический сахар — то отлично.

Ну это же C++, тут главное функциональность (например туда отлично легли даже вычисления на GPU) и нулевой оверхед, а всяческие красивости ценятся на последнем месте. Хотя лично мне интерфейс в стиле конвейера (давно привычный каждому, кто работал в консоли) вполне нравится. Но это всё оффтопик в данной теме, т.к. хотя ranges применяют не только для контейнеров (например можно реактивно фильтровать данные приходящие асинхронно по сети и т.п.), но для передачи запросов к СУБД они точно не предназначены. )))

_>>Некорректный код, т.к. у тебя массив не отсортирован. ))) Ну да ладно. )))
S>Вот и я об этом. Именно для этого нам нужен SortedList, а не просто "массив, который наверное уже отортирован.

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

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

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

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

Не вижу никакой принципиальной разницы между случаем отсортированного int[] и myfields[], отсортированного по какому-то из полей структуры myfields. И в том и в другом случае тебе всё равно приходится руками писать тот же самый императивный код в своей реализации where для данного типа.

S>Линк мне даст возможность менять это одной строчкой, а произвольный императивный код придётся переписывать полностью каждый раз.

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

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

_>Так ссылочка то будет, на моё предложение заменить SQL на язык из MongoDB? )
http://rsdn.org/forum/flame.comp/7114380.1

Автор: IB
Дата: 16.04.18

_>А какой ещё может быть императивный код для обработки коллекции, если не for? Что за жалкие увиливания?
Это у вас жалкие увиливания и попытка домотаться до for, "я вовсе не это имел ввиду" (С). Только почему-то и Антон и я поняли это одинаково. Значит надо либо учиться выражаться точнее, либо не обижатья что не так поняли.

_>Он описал крайне забавную ситуацию, в которой при изменение условий задачи Linq код успели оптимизировать под новые условия, а императивный код не успели.
Там никто никуда не успевал. в случае linq вообще ничего делать не надо, один и тот же прикладной код одинаково эффективно работает с разными типами коллекций. В случае же императивного кода под каждую коллекцию код работы с ней приходится переписывать заново. Именно это я и имел ввиду, когда писал, что for не достаточно универсален, чтобы быть везде эффективным.

_> Выдавать подобный сценарий в качестве аргументации — это конечно очень смешно и наивно.
Ну да, именно этим вы постоянно тут и занимаетесь.

_>Да, но при всей нелепости подобной аргументации, это была хоть какая-то попытка. В то время как от тебя (как изначального автора данного неверного тезиса), в данной теме не было даже попытки защитить его.
Как я уже сказал, Антон отлично сделал это за меня и я не видел смысла повторять тоже самое.

_>Это ты всего лишь высказал очередной свой сомнительный (к нему элементарно подобрать контрпример в виде отбирания у SQL какой-нибудь функциональности и потом наблюдения за работой linq в таких условиях) тезис. Без аргументации (почему одно имеет значение, а другое нет) он ничего не стоит.
Отбирая функциональность у SQL надо предоствить аналогичную функциональность в виде другого API к базе, тогда такой пример будет корректным.
Даже ладно, фиг с ним, пусть мы просто отрежем кусок возможностей сиквела и linq-у придется поддерживать это уже на клиенте, на выразительности и удобстве линка как языка это все равно не скажется. Мы же обсуждаем язык, а не то как его конкретная имплементация поддержана в конкретной базе. Скажу больше, мы ищем вдохновение(!) для понимания на что мог бы быть похож такой язык.

_>Ну вот подобное ещё можно было бы обсудить. Не скажу, что мне это кажется идеальным решением, но оно хотя бы полностью отвечает нашей дискуссии.
Ну наконец-то.

_>Что-то незаметно. Тот же Sinclair, хотя и спорит со мной или вдимасом по разным вопросам, но некоторые его претензии к SQL тоже можно легко увидеть в данной теме. А от тебя тут пока что была видна исключительно яростная защита SQL по всем вопросам.
Не по всем, а только по тем, где к сиквелу доматываются не по делу.

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

_>Ещё раз: хранимые процедуры — это не SQL. Это процедурный (императивный) язык, в то время как SQL является полностью декларативным языком.

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

Плюрализм, однако.

Как тебя понимать, императивные расширения SQL это SQL или нет ? В одном месте ты пишешь, что да, в другом — что нет.

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

_>О, я смотрю от изначального тезиса, что "у MySQL проблемы с consistency и availability" мы незаметно попытались перейти к новому тезису, что "у MySQL были проблемы с consistency и availability до определённой версии".
О, я смотрю проблемы не только с написанием, но еще и с чтением? =)
С процитирую еще раз, мне не сложно:
such as MySQL – were originally designed with only consistency and availability in mind
Как видно по исходной цитате, речь изначально шла о том, для чего именно был задизайнен MySQL, а не о том, что он умеет сейчас. Так вот уж точно не для Consistency и availability, так как их там даже близко не было.
Правильный ответ (уловите иронию) для создания более эффективного и удобного API к ISAM базам, и таким API явился SQL.

_> А можно теперь озвучить в какому году появилась та версия (в которой добавили InnoDB), начиная с которой проблем нет?
По дефолту? Кажется, середина 16-го года.

_> И это логично, т.к. далеко не для всех БД это полезно.
Ну так и я о том же, есть ОЛАП, есть BigData, где традиционная реляционка работает только до определенных пределов. Собственно об этом я и написал еще три сообщения назад.

_>Однако ты тут утверждал, что подобных переходов никто не делает в принципе.
Цитату можно? Где прям в принципе?

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

_>>Ужас какой. Хотя я именно такое и предполагал, из знаний работы await.
S>Если честно, я не понял, зачем там генерируется референс-тип. Вполне хватило бы структурного типа.

Работы в этом направлении ведутся. ValueTask уже добавили.

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


_>Ммм, при слове escape-analysis у меня появляется ассоциация исключительно с соответствующим механизмом в Java, который работает как раз не на уровне компилятора, а на уровне виртуальной машины (причём ещё и на вероятностных принципах, анализируя рантаймовые параметры). Если ты имел в виду что-то другое (статическое, на этапе компиляции), то значит у нас тут просто небольшое рассогласование в терминологии.
Ок, поясню: размещение в куче позволяет объекту пережить тот стек-фрейм, в котором он был создан.
Это необходимо, если ссылка на этот объект покидает этот стек-фрейм. Если же время жизни всех ссылок на этот объект ограничено временем жизни стек-фрейма, то можно разместить этот объект на стеке прозрачно для всего остального кода.
Проверка этой гипотезы и называется escape analysis: мы смотрим, не "сбегает" ли ссылка. Кто это делает — компилятор или среда — неважно. Механизм — один и тот же.
В управляемой среде компилятор может отловить только самые очевидные случаи. Инлайнинг и прочий хардкор, который может позволить уточнить результаты escape-analysis, производится на уровне JIT.
Насколько я знаю, никаких вероятностей в Java нету — ведь если мы с вероятностью 1% ошибаемся, то один раз из ста у нас наружу уходит ссылка на разрушенный объект.

_>Ты действительно хочешь сказать, что в программирование не встречается задач, где входные данные уже гарантированно отсортированы? )
Гарантии может дать только статически верифицируемый код. Поэтому наиболее эффективный способ — это ввести тип SortedList, который будет гарантировать наличие сортировки независимо от количества коммитов в репозиторий, прошедших со дня первоначальной сборки.
Это — ровно то же самое, что и строка, оборудованная предвычисленной длиной.
Лет десять назад я тут вёл споры с одним фанатом императивного программирования, который уверял меня, что в программировании прямо-таки постоянно встречаются строки, про длину которых заранее ничего неизвестно.
Примеры он, правда, привести затруднился — пришлось придумать воображаемый сетевой протокол.
И тут у нас всё точно так же: важно предотвратить нарушение инвариантов. По-хорошему, конструктор обязан удостовериться за O(N) что массив и правда отсортирован.

_>Ну так если бы возможность задавать намерения, позволяла это эффективно делать для произвольных задач и с нулевым оверхедом, то я бы тоже не отказался от такого. Но к сожалению волшебных палочек не существует. Даже упоминаемые выше ranges из C++ годятся не для всех задач (хотя с обсуждаемым случаем работы по отсортированному массиву естественно справляются)...
Если начинать с задачи "минимизировать оверхед", то мы никогда не построим удобного языка. Надо начинать с задачи "обеспечить выразительность", а уже потом заниматься устранением abstraction penalty.
Тем более, что методик по борьбе с abstraction penalty придумано вагон и маленькая тележка — начиная ещё со Smalltalk с его хотспоттингом и работ Ершова по частичным вычислениям.

_>Не вижу никакой принципиальной разницы между случаем отсортированного int[] и myfields[], отсортированного по какому-то из полей структуры myfields. И в том и в другом случае тебе всё равно приходится руками писать тот же самый императивный код в своей реализации where для данного типа.
Нет. Where пишется один раз для SortedList<T>, также, как и i4o, который уже написан. Там внутри — анализ предиката в поисках сравнений ключевого атрибута с параметром, перестроение предиката на "индексную" и "остаточную" части, и потом выполнение кода. Никакой специфики для пользовательского типа там нет.


_>С чего это переписывать полностью императивный код при правке предиката? Или ты думаешь он там какой-то ассемблерной магией задаётся, а не той же самой банальной строчкой с условием? )
Может, я и правда чего-то не понимаю?
Давайте в студию пример императивного кода, который заменяет вот такой вот примитивный query comprehension:

var t = from p in persons where p.Age >= 18 && p.Age <= 65 && p.Name.StartsWith("K") select p

Предположим, что persons — массив, который уже отсортирован по Age.
Как изменится код, если отсортировать массив по Name?
Как изменится код, если отсортировать массив сначала по Name, потом по Age?
Как изменится код, если отсортировать массив сначала по Age, потом по Name?

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

_>>Так ссылочка то будет, на моё предложение заменить SQL на язык из MongoDB? )
IB>http://rsdn.org/forum/flame.comp/7114380.1

Автор: IB
Дата: 16.04.18

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

_>>А какой ещё может быть императивный код для обработки коллекции, если не for? Что за жалкие увиливания?
IB>Это у вас жалкие увиливания и попытка домотаться до for, "я вовсе не это имел ввиду" (С). Только почему-то и Антон и я поняли это одинаково. Значит надо либо учиться выражаться точнее, либо не обижатья что не так поняли.

И где это я сказал "вовсе не это имел ввиду" (я уже молчу про то, что подобную ошибку в русском языке никогда не сделал бы) в контекте for? И что же именно правильно понял Антон? Я что-то не увидел каких-то естандартных пониманий у него.

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

Это ты сейчас полную ерунду написал. В обоих случаях при изменение способа обхода коллекции в соответствие с новым типом коллекции (в данном случае обсуждалось добавление индекса по какому-то полю) будет исполняться новый код. Единственная разница заключается в том, что в случае linq этот код можно скачать готовым в виде некой библиотеки (правда скорее всего пожертвовав при этом производительностью), а в случае без Linq придётся написать самому (и то не факт — вполне возможно что есть готовые аналогичные библиотеки и без Linq).

IB>Именно это я и имел ввиду, когда писал, что for не достаточно универсален, чтобы быть везде эффективным.

А что это ещё за эфемерная "эффективность" появилась у нас в обсуждение, если здесь мы говорили о вполне конкретной производительности?

Ну и если уж речь зашла об универсальности... Вот тут рядом рассматриваем ещё один пример похожего изменения начальных условий, приводящий при оптимизации к аналогичному ускорению (O(n)->O(ln(n)): вместо добавления индекса в коллекцию, рассматриваем отсортированные коллекции. Судя по ответам Sinclair'а соответствующей готовой библиотеки для linq не оказалось и "неожиданно" для написания linq варианта кода в этих условиях требуется намного больше усилий, чем при простом for'е. Как же так то, а? )))

_>>Это ты всего лишь высказал очередной свой сомнительный (к нему элементарно подобрать контрпример в виде отбирания у SQL какой-нибудь функциональности и потом наблюдения за работой linq в таких условиях) тезис. Без аргументации (почему одно имеет значение, а другое нет) он ничего не стоит.
IB>Отбирая функциональность у SQL надо предоствить аналогичную функциональность в виде другого API к базе, тогда такой пример будет корректным.
IB>Даже ладно, фиг с ним, пусть мы просто отрежем кусок возможностей сиквела и linq-у придется поддерживать это уже на клиенте, на выразительности и удобстве линка как языка это все равно не скажется. Мы же обсуждаем язык, а не то как его конкретная имплементация поддержана в конкретной базе. Скажу больше, мы ищем вдохновение(!) для понимания на что мог бы быть похож такой язык.

Ещё раз: у Linq нет никакой имплементации ни в какой СУБД, поэтому обсуждение его в том виде, в каком сего используют сейчас (в качестве надстройки над SQL), абсолютно не интересно в данной дискуссии.

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

Так а почему до сих пор тут никто не выдвигал этого предложения (исполнения непосредственно Linq запросов на сервере) и не было его подробного обсуждения?

_>>Что-то незаметно. Тот же Sinclair, хотя и спорит со мной или вдимасом по разным вопросам, но некоторые его претензии к SQL тоже можно легко увидеть в данной теме. А от тебя тут пока что была видна исключительно яростная защита SQL по всем вопросам.
IB>Не по всем, а только по тем, где к сиквелу доматываются не по делу.

Ну так может тогда поделишься, какие на твой взгляд главные недостатки у SQL? )