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

_>У Linq и с описанием многих задач большие проблемы. Один вопрос рекурсии чего стоит. )))
Ну, он не идеален, но сильно лучше for. Но рекурсия — это не проблема линка, а проблема языка, тем не менее рекурсию описать тоже можно.

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

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

_>SQL тут не подходит.
Чем?

_>Уже сто раз обсуждали, что не будет так работать.
Почему?

_>В том то и дело, что никому не надо писать свой hadoop — он как раз низкоуровневый и поэтому подходит всем (он и есть аналог тех низкоуровневых потрохов СУБД, которые не надо переписывать). А писать надо свои аналоги такого https://en.wikipedia.org/wiki/Apache_Hive.
Зачем писать еще один точно такой же SQL, но другой? у разработчика БД это все равно получится заведомо лучше.

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

Gt_>указывает.
Каким образом?

Gt_>настоящие мужики выбирают лидирующие технологии: oracle rdbms, oracle java, а слабаки да, на технологиях второго эшелона mssql, .net созданные по мотивам оракла
Терпите.

Gt_>то что декларативным sql такие вещи не решить, но есть костыль на императивном C#, который убьет оптимизатор и все равно ничего не даст.
Чего это не даст? В вашем любимом хадупе, точно такой же код, точно так же не известный оптимизатору и движку.

Gt_>нет. хранимка это то, что заранее задефайнено в субд, а тут либы используемые твоим кодом. соответственно можно выполнять код с разными версиями либ одновременно.
можно, но нужно ли? К тому же хранимки тоже можно на лету делать.

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

_>Ох, как утомляют эти любители спорить с голосами в своей голове...

Угу. Особенно, когда они потеряли исходный контекст.

_>Ну покажи моё утверждение об "отказе Яндекса от SQL в пользу Питона". )))

Причем тут ты и твои утверждения? Начало этого спора было положено Gt_ вот тут:

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

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

_>Может ты тогда ещё и PL/SQL считаешь как часть SQL? )

Я его считаю развитием SQL и одной из его реализаций.

_>Ещё раз: в современных условиях использование запроса сложнее чем "select * from my_table" имеет смысл только в том случае, если там терабайты данных. Во всех остальных случаях проще загрузить в Питон таблицу целиком, как сырые данные, и уже там обрабатывать удобными инструментами.

В современных условиях терабайтами уже никого не удивишь. У нас тут только тестовые данные под один из интеграционных тестов около терабайта весят. А размеры production баз в петабайтах измеряются.

Gt_>>указывает.
IB>Каким образом?

возьми любую книжку по F# и почитай вводную, там везде будет разжевано почему C# imperative language

Gt_>>то что декларативным sql такие вещи не решить, но есть костыль на императивном C#, который убьет оптимизатор и все равно ничего не даст.
IB>Чего это не даст? В вашем любимом хадупе, точно такой же код, точно так же не известный оптимизатору и движку.

в мап-редюсе в принципе нет оптимизатора, там по сути голый жава код с парой вызовов из наследумых от хадупа классов.
у spark оптимизатор есть, но там и управлять потоком данных можно совершенно на ином уровне и код совершенно иначе выглядит. что в вашем мсскл ? тут декларативный sql, тут с# между ними пропасть и тучи сугубо технического геморроя подружить энжины из разных миров, нихера толком не интегрированных. зачастую это вообще три мира — процедурный t-sql бежит в цикле по курсору из декларативного мира, дергая C# процедуру из мира .net. и в каждом из миров свой синтаксис, свои типы, свои процессы и память.

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

        Dataset<Row> shit = vars.mapGroups(
                (MapGroupsFunction<Integer, String, String>) (key, values) -> {
                    MyMegaClass mc = new MyMegaClass(key);
                    while (values.hasNext()) {
                        mc.process(values.next());
                    }
                    return mc.toString();
                }, Encoders.STRING()) ;

        datasetCache.cache("shit", shit);

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

Gt_>>нет. хранимка это то, что заранее задефайнено в субд, а тут либы используемые твоим кодом. соответственно можно выполнять код с разными версиями либ одновременно.
IB>можно, но нужно ли? К тому же хранимки тоже можно на лету делать.

с дуру можно и ... сломать. но первое код ревью за "хранимки на лету" с волчьим билетом

Gt_

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

Gt_>возьми любую книжку по F# и почитай вводную, там везде будет разжевано почему C# imperative language
Не надо путать теплое с мягким. Из того, что C# скорее императивный, хотя и функицональных возможностей более чем достаточно, никак не следует, что фунцкия StartsWith что-то кому-то указывает. Уж точно не больше чем сиквельный like.

Gt_>в мап-редюсе в принципе нет оптимизатора, там по сути голый жава код с парой вызовов из наследумых от хадупа классов.
Тем хуже для него ))

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

Gt_>что в вашем мсскл ? тут декларативный sql, тут с# между ними пропасть и тучи сугубо технического геморроя подружить энжины из разных миров, нихера толком не интегрированных.
А их и не надо интегрировать, каждому свое.

Gt_>той пропасти в синтаксисе нет, все в одном енжине, где вмешаться можно хоть в кеширование.
А толку-то, сервер все равно ничего не знает про MyMegaCalss и может его только выполнить, передав результат запроса. Технически это ровно тоже самое, только что синтаксис другой.

я бы постебался, да ты же все равно затрешь всю переписку, как с тем oracle problem (tm)
MyMegaClass, spark, hadoop классы это все единая аппликация, которая стартанет в единой jvm и которая будет читать локальный файлик. на каждом узле кластера. в этом вся суть.

Gt_

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

_>>Ну так можешь показать как будет выглядеть самый простейший вариант реализации? А то у меня есть подозрения, что тебе тут снова придётся заниматься всяческими рантаймовыми анализами AST. Что очевидно совершенно дико и с точки зрения времени разработки и с точки зрения эффективности итогового кода.
S>Тупой влобный вариант — вот:
S>

S>        public static T[,] GroupBy<T>(this T[,] source, Func<IRelativeAccess2d<T>, T> kernel)
S>        {
S>            var km = new KernelMeasure<T>(kernel);
S>            var result = new T[source.GetLength(0), source.GetLength(1)];
S>            var ra = new RelativeArrayAccess2d<T>(source);

S>            for (int i = source.GetLowerBound(0) - km.xmin; i < source.GetUpperBound(0) - km.xmax; i++)
S>                for (int j = source.GetLowerBound(1) - km.ymin; j < source.GetUpperBound(1) - km.ymax; j++)
S>                {
S>                    ra.x = i;ra.y = j;
S>                    result[i, j] = kernel(ra);
S>                }
S>            return result;
S>        }
S>

S>Это, в общем-то, ровно то же самое, что под капотом у С++-библиотеки.
S>Минус возможности инлайнинга kernel, из-за которых внутри цикла — косвенный вызов, внутри которого — косвенные вызовы.
S>Не очень сложным способом мы можем проинлайнить kernel вручную, и получить на выходе MSIL, эквивалентный "идеальному" для CLR императивному коду.

Так а откуда тут появляется некая функция kernel от одного параметра (специфического типа RelativeArrayAccess2d), в то время как в твоём оригинальном Linq выражение ("from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;") нет никаких намёков на какие-либо параметры?

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

_>>Это всё понятно. Но "бороться" с низкоуровневым кодом можно разными способами. Единственно правильный на мой взгляд способ — это оборачивать его в высокоуровневые абстракции (готовые библиотеки, фреймворки и т.п.). А вот самый простейший способ, под названием "запрет" на мой взгляд не верен.
S>Пока вы контролируете 100% codebase — да, всё ок.
S>Что ограничивает нас любительскими проектами на 1-3 человек.
S>Как только у нас возникает совместная деятельность — упс, лишние разрешения только мешают.
S>А когда у нас есть совместная деятельность без общей цепочки подчинения — то надо разрешать как можно меньше.
S>Вот, к примеру, есть какой-нибудь booking.com.
S>Он позволяет делать поиски по всяким критериям. Но я не могу запихать в него произвольный императивный код для поиска — ибо нефиг. Даже если "опесочить" этот код так,чтобы он не разломал полбазы, я всегда могу скормить туда пожиратель ресурсов и спровоцировать DoS. Проверить, можно ли исполнять произвольный запрос, или он положит всю систему, эквивалентно решению проблемы останова.

Ну зачем так передёргивать то? ) Я думаю тут каждому очевидна разница между предоставлением низкоуровневого доступа программисту системы и пользователям.

Ну и кстати говоря тот же booking.com вроде как и возможность sql запросов тоже не предоставляет пользователям...

S>>>В SQL нет никаких алгоритмов. Именно в этом его преимущество: он описывает то, какие данные надо получить, а не алгоритм обхода.
_>>В текущих РСУБД у SQL вполне конкретный набор алгоритмов. )))
S>И он, что характерно, менялся с годами. Если есть мнение, что какие-то реляционные данные эффективнее "обходить" по-другому, то лучше инвестировать в улучшение исполнителя SQL, который поможет всем, чем в ручное итерирование по курсорам.

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

_>>Угу, отличный подход. И главное, что если вдруг в numpy не будет нужного кода, то у тебя нет никаких проблем (если конечно ты знаком с C/C++) написать свой низкоуровневый кусочек...
S>Угу. И зачем мне Питон, если я умею в С++? Если чо, там пол-языка было изобретено исключительно для того, чтобы побить фортран в математике.

Питон нужен чтобы быстро (в смысле времени написания кода) и удобно решать задачи. C/C++ модули нужны чтобы этот код на Питоне быстро (в смысле машинного времени) получал требуемый результат. Это одна из оптимальнейших архитектур, применяемая очень много где (от игр и cad'ов, до суперкомпьютеров).

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

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

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

_>>А причём тут внутренний API? Я тут отвечал на вполне конкретный вопрос "Кому надо исполнять произвольный императивный код на сервере?". Судя по распространённости множества разных диалектов PL/SQL и даже применения более серьёзных языков — это очень много кому надо... )))
IB>А, в этом смысле. Ну так PL/SQL, равно как и другие императивные расширения для написания процедур на сервере, были придуманы в те времена, когда считалось, что СУБД должна еще и логику выполнять. Но практика показала, что это самый неудачный подход из всех возможных. И хотя еще до сих пор есть любители выписывать логику на сервере, лучшим доказательством, что языки типа PL/SQL не востребованы — это то, что они не развиваются. Если бы была потребность в нормальном языке на серврере, то их давно бы уже привели в порядок, но так как нет такой нужды, то никто в эти языки не в кладывается и они как были убожеством, так и остались.
IB>Так что да, произвольный императивный код на сервере непонятно зачем нужен, всегда можно достать результат запроса на клиент и сделать с ним все что хочется.

Не развивается значит? ) А кто тут совсем недавно хвастался появление возможности выполнения функций на Питоне в СУБД? )))

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

_>>Далее, возьмём классическую задачку: у нас есть табличка с некими числами в одном из столбцов, надо создать новую табличку, в которой количество строк определённого вида будет равно этому самому числу. Несколько сумбурно сформулировал, но думаю ты понял о чём я. Так как ты опишешь такое на SQL или Linq? )
IB>Не, не понял задачу... Если эти строки определенного вида есть в другой таблице, то нет проблем сделать select top(select столбец_с_числами from таблица_с_числами) строка from таблица_со_строками. Если же таблицы нет, то это не задача sql — данные генерить, хотя иногда можно извернуться с псевдотаблицами или какими-нибудь служебными.

Давай покажу на примере. И так у нас есть табличка:

name | count
===========
вася | 2
петя | 3

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

id | name
===========
1 | вася
2 | вася
3 | петя
4 | петя
5 | петя

Как будет выглядеть решение на SQL или Linq? )

_>>Интересно, и почему Гугл с Яндексом не пошли по такому пути? ))) Всего то допилить MySQL или PostgreSQL до нужного состояния...
IB>Почеу не пошли? Пошли, гугл довольно долго пилил MySQL и всячески его использовал, думаю и до сих пор продолжают.

Гугл использует BigTable, от которой собственно и зародилось "движение" NoSQL. А что касается использования MySQL в кое-каких побочных местах, то они его уже давно заменили на эту https://en.wikipedia.org/wiki/Spanner_(database) игрушку.

_>>Ну ОК, возможно точные даты я забыл, но суть всё равно осталась верной: разрабатывался sql не на базе той теории. )
IB>Ну как же не на базе то, алгебра -> SQUARE -> SQL я прямо цитату привел: The researchers query language — initially called SQUARE — or Specifying Queries As Relational Expressions. Even SQUARE had some mathematical notations. Its successor, Structured English Query Language, was based exclusively on English words

Что-то ты сам себе противоречишь. Твоя же цитата: " В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS".

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

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

_>>У Linq и с описанием многих задач большие проблемы. Один вопрос рекурсии чего стоит. )))
IB>Ну, он не идеален, но сильно лучше for. Но рекурсия — это не проблема линка, а проблема языка, тем не менее рекурсию описать тоже можно.

Под языком ты C# имеешь в виду? Что-то не слышал про проблемы с рекурсией у C#...

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

_>>SQL тут не подходит.
IB>Чем?
_>>Уже сто раз обсуждали, что не будет так работать.
IB>Почему?

Уже 10 раз (причём включая конкретные примеры) было показано, что множество задач решаемых с помощью SQL является подмножеством задач, решение которых задаётся произвольным императивным кодом.

_>>В том то и дело, что никому не надо писать свой hadoop — он как раз низкоуровневый и поэтому подходит всем (он и есть аналог тех низкоуровневых потрохов СУБД, которые не надо переписывать). А писать надо свои аналоги такого https://en.wikipedia.org/wiki/Apache_Hive.
IB>Зачем писать еще один точно такой же SQL, но другой? у разработчика БД это все равно получится заведомо лучше.

Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных) и такое https://en.wikipedia.org/wiki/Apache_Trafodion (что там говорили про транзакции?) и даже такое https://www.opencypher.org. Причём всё это заводится поверх одного и того же hadoop кластера.

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

_>>Ну покажи моё утверждение об "отказе Яндекса от SQL в пользу Питона". )))
L>Причем тут ты и твои утверждения? Начало этого спора было положено Gt_ вот тут:
L>

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

L>Ты всего лишь продолжил эту линию. И пример мой был именно против этой основы, а не против того, что ты там себе придумал.

"дата сайенс уходит от высокоуровневого SQL к гораздо более низкоуровневым R и python скриптам" — подтверждаю верность этого утверждения.

Но справедливо и то, что в отношение Яндекса это утверждение не верно. Только не потому, что им продолжает нравиться SQL, а потому что у них его никогда и не было (в этой роли) — у них изначально было низкоуровневое решение (причём даже ниже любых Питонов). Но Гугл и Яндекса — это скорее исключения из правил, понятно почему. А у большинства в прошлом использовался как раз SQL, пока не появилось более удобные решения, в том числе и на базе Питона.

_>>Может ты тогда ещё и PL/SQL считаешь как часть SQL? )
L>Я его считаю развитием SQL и одной из его реализаций.

Т.е. императивный PL/SQL — это развитие декларативного SQL? Хм, хм, что-то в этом утверждение конечно есть. А то тут многие всё пытаются говорить о ненужности императивного подхода...

_>>Ещё раз: в современных условиях использование запроса сложнее чем "select * from my_table" имеет смысл только в том случае, если там терабайты данных. Во всех остальных случаях проще загрузить в Питон таблицу целиком, как сырые данные, и уже там обрабатывать удобными инструментами.
L>В современных условиях терабайтами уже никого не удивишь. У нас тут только тестовые данные под один из интеграционных тестов около терабайта весят. А размеры production баз в петабайтах измеряются.

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

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

_>Под языком ты C# имеешь в виду? Что-то не слышал про проблемы с рекурсией у C#...

И как в выражении на C# записать рекурсию?

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

_>Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных)

Это как с Линуксом. Он все время уже наконец вот вот отвоюет десктоп у винды. И уже совсем почти отвоевал, жаль только десктоп сдох, а у Линукса там так и остались его 2-3%.

_>>Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных)

НС>Это как с Линуксом. Он все время уже наконец вот вот отвоюет десктоп у винды. И уже совсем почти отвоевал, жаль только десктоп сдох, а у Линукса там так и остались его 2-3%.

дык, андройд разгромил всех конкурентов на мобильном "десктопе"

Gt_

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

НС>>Это как с Линуксом. Он все время уже наконец вот вот отвоюет десктоп у винды. И уже совсем почти отвоевал, жаль только десктоп сдох, а у Линукса там так и остались его 2-3%.
Gt_>дык, андройд разгромил всех конкурентов на мобильном "десктопе"

А в Киеве дядька.

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

_>Так а откуда тут появляется некая функция kernel от одного параметра (специфического типа RelativeArrayAccess2d), в то время как в твоём оригинальном Linq выражение ("from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;") нет никаких намёков на какие-либо параметры?
Ну как же нету? В этом выражении d как раз имеет тип IRelativeAccess2d<int>, он и является параметром функции (IRelativeAccess2d<int> d)=>(d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4).
Благодаря чему я имею возможность записать ядро с более человеческим синтаксисом, чем в С++.

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

_>Ну и кстати говоря тот же booking.com вроде как и возможность sql запросов тоже не предоставляет пользователям...
Ага. Зато можно недорого реализовать провайдер linq to booking, который будет превращать запросы на статически верифицируемом "суб-языке" в URLы букинга.

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