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

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

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

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

S>Нам же потребуется какой-то фреймворк для 2d-фильтров.
S>Что-то типа ApplyFilter(data, filter, edgeHandlingRules), где data — наш массив чисел, filter — матрица коэффициентов, edgeHandlingRules — набор параметров, описывающих, как обрабатывать границу (считать ли точки, выходящие за границы массива, нулевыми, единичными, или аппроксимировать средними).
S>В зависимости от задачи, мы, возможно, захотим уметь записывать цепочки фильтров — чтобы минимизировать количество проходов.
S>Нам потребуется фреймворк, умеющий превращать data.Filter(filter1).Filter(filter2) в data.Filter(filter1_filter2).
S>При этом мы, естественно, понимаем, что data запросто может оказаться больше размера доступной RAM, и что обрабатывать мы это всё, возможно, захотим в несколько потоков одновременно.
S>Поэтому наивная реализация через четыре вложенных цикла нас не интересует. Через два вложенных цикла — тем более, т.к. мы хотим иметь возможность быстро менять фильтр, подбирая его по качеству результата. Ручное переписывание 4х точек на 8 точек, а потом на 12 в этом смысле нас не устраивает.

Ну это всё делается не совсем так. Не плохой вариант ты можешь глянуть например здесь https://github.com/matt-42/vpp.

S>Не говоря уже о том, что порядок чтения и записи результатов нам надо будет подбирать с учётом особенностей кэширования, и наличия векторных операций в процессоре, на котором мы исполняемся (ну, это в зависимости от типа данных, которые мы обрабатываем — для 16-разрядных целых детали оптимального ассемблерного кода будут существенно отличаться от случая 80-битных плавающих)

Для этого есть библиотеки типа Eigen. Только они работают на более низком уровне (векторы, матрицы и т.п.).

S>Итого, сам Linq тут ни при чём. Но подход к решению должен быть именно таким — мы пишем максимально декларативный код, и пишем механизм конверсии этого кода в оптимальный низкоуровневый код.

Ну так никто не против таких подходов, только при правильной модели и реализации...

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

S>Язык, который навязывает нам использование вложенных циклов, неинтересен.

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

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

_>>На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД).
S>Во-первых, это опциональный режим. То есть они всё ещё умеют обходиться без write-through коммита.

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

S>Во-вторых, вот именно эта штука, которая называется write-ahead log, взята 1-в-1 из RDBMS, потому что их тоже не дураки писали. И именно поэтому я и "намекал", а, точнее, писал открыто: в таком режиме commit в Монгу занимает ровно столько же времени, как и в RDBMS. Потому что делается ровно то же: флашится буфер журнала, а это как минимум 1 IO операция, которая, внезапно, упирается в HDD, а не в алгоритмы СУБД или язык реализации.
S>Все легендарные скорости записи достигаются исключительно при отключении write-through коммитов, потому что чудес не бывает. Некоторые особо резвые RDMBS тоже оборудованы аналогичными режимами, но их использование малоинтересно, т.к. нас интересуют предсказуемые поведения, а не "авось проконает". Если вы готовы пожертвовать данными, то математик внутри меня подталкивает сразу смонтировать базу на dev/null и обеспечить непревзойдённую скорость записи

Хы, помнится мы тут на форуме тестировали некий пример несколько лет назад и в нём Монга обходила MS SQL. При этом я запускал Монгу как раз в дефолтном режиме, без каких-то спец. опций.

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

_>Аааа, ну если у нас теперь код — это не реальный аргумент, а попытка увести дискуссию в сторону, то тогда тогда мне действительно всё понятно...

Конечно, все от контекста зависит )))

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

_>Задачи такие давным давно были, только подходящих инструментов не было.
Да ладно, инструменты появились моментально, как материализовалась потребность. Какое-то время они были для внутреннего потребления, потом вышли наружу.

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

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

_>Так что это не недостаток, а суровая реальность, с которой надо как-то жить...
Отож

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

_>>А ты вообще в курсе что такое Jupyter Notebook, как он работает и какое место занимает в современном мире DS? )))
L>Как ты думаешь, а зачем Яндекс пилит собственный движок запросов с SQL-подобным синтаксисом, если Python так прекрасен?
L>https://habr.com/company/yandex/blog/312430/

Эм, а ты сам то свою ссылку открывал, читал?

А то там на первой же картинке под названием "Архитектура YQL" красуются и Python и Jupyter...

И потом ещё идёт целая отдельная секция статьи просвещенна интеграции с Питоном, даже со скринами того самого Jupyter Notebook.

В общем фееричное возражение у тебя получилось...

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

_>>Ну так и SQL решения (да и любого другого — думаю тут все в курсе некой теоремы) с ACID на тысячи узлов тоже нет.
IB>О чем и речь. Либо SQL и ACID, но не тысяча узлов (хотя там тоже есть на самом деле), либо приседай вокруг хадупа, но зато масштабируйся как влезет.

Ну так САР-теорему никто не отменял.

Здравствуйте, alex_public, Вы писали:
S>>Но тут пришёл программист, и говорит "А напишу-ка я ассемблерную вставку", хреначит mov &i, eax, и вот компилятор уже вынужден резервировать место на стеке и складывать туда значение.
_>Давай всё же определимся. Если программист вставляет что-то подобное, то значит он знает что делает и это действительно лучшее решение. Иначе зачем ему это делать?
а) о думает, что знает лучше, но на самом деле не понимает подробности работы конвеера и кэша.
б) он в самом деле знал лучше, но это было актуально в далёком мае 2018; сейчас, в 2024, архитектура существенно изменилась, а статистика реального использования отличается от того, что ожидал программист.
Я работаю в коммерческой разработке софта с 1991 года. Представления о том, чего могут и чего не могут программисты — имею вполне статистически значимые.
_>Вот тебе хорошо, т.к. тебе надо только "вверх" относительно SQL. А что предложишь делать тем, кому надо "вбок"? )
Для начала надо определить, что это за "вбок" такой. Невозможно решить несформулированную задачу.

_>Это не тупик, а это фундамент, на котором лежит весь мир IT. И да, чем больше мы создаём новых абстракций (а потом и абстракций поверх этих абстракций), тем меньше потребности к ручной правке этого фундамента. Но при этом он всегда в действие (исполняется именно такой код в итоге) и всегда под рукой для правки, если существующие абстракции не справляются.
Ну вот нет же. "всегда под рукой". Вот вам Node.js — пойдите, подтюньте поведение коллекций в нём, если вас не устраивает стандартный джаваскриптовый ассоциативный массив.

_>И как тебе roslyn поможет управлять локами в транзакции?
рослин — никак. А вот если бы у меня был под рукой готовый парсер SQL, то я бы мог писать несложные правила анализа, позволяющие мне автоматически расставлять хинты.
Там же объёмы кода несопоставимые — можно просто взглянуть на то, что люди прикручивают поверх того же рослина, чтобы понять, почему они не делали того же самого до рослина.

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

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

_>>>Эм, какое ещё O(...), когда мы говорим о работе с нынешними СУБД (т.е. вся работа нашего кода заключается в генерации sql строк)?
S>>Очень удобная позиция. "Мой код справился за 1мкс, а то, что СУБД была вынуждена лопатить 15 минут — это не ко мне вопрос".

_>А какая связь между временем генерации SQL строки (одной и той же) и тем сколько времени будет её исполнять сервер?
Очень простая. Вот-простой пример:

select * from order_items where order_id not in (select id from orders)

Я могу отправить эту строку, и наслаждаться тем, как шустро сервер сканирует два индекса.
А могу проанализировать foreign key constraints, провести упрощение предиката, и никакой запрос на сервер вообще не отправлять. То есть имеем 100мс на анализ против 0мс на анализ и O(N) на исполнение запроса.
_>Возможно и не плохая. Если конечно нельзя сэкономить это лишнее обращение, не потратив 200мс.
Совсем ничего не потратить не получится.

_>Ну почему же. Это по сути нативный код, но при этом независящий от конкретного процессора и безопасный для процесса (запертый в песочнице). Очень нужная концепция сама по себе. Не факт что именно она нужна для СУБД (т.к. возможно лучше что-то повыше уровнем, чтобы сохранять типизацию), но она явно смогла бы тут работать.
А можно вкратце пояснить, чем, по-вашему, WASM лучше CLR или JVM?

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

_>Ну во-первых не по C# коду, а по некому специальному AST. А во-вторых называть генерацию SQL строки для сервера метапрограммированием — это уже несколько перебор... Тогда уж все серверные веб-решения (выдающие в браузеры js код) тоже являются чисто метапрограммными инструментами. )))
Естественно.

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

_>Посмотри повнимательнее http://rsdn.org/forum/flame.comp/7127041.1. Передаётся именно два итератора (один указывает на начало и один на конец).
А, действительно, просмотрел.

_>Да, но при этом спектр охватываемых им задач меньше не только чем у тупого for, но даже меньше чем у цепочки range (тоже довольно абстрактной конструкции).
И даже меньше чем у набора из "0, инкремент, выбор N-го аргумента". Понятно, что чем "тупее" инструкция, тем "полнее" спектр охватываемых ею задач. Точнее, наоборот — не "охватываемых", а тех, куда её можно применить.
Тот же самый for "охватывает" очень мало чего — кроме копирования С-style string. То, что его можно применить в большом количестве сценариев — ну так и if() можно применить очень много где. От этого его "охват" больше не становится.

_>И выдавать будет нормальные данные, если соблюдать условия игры.
Конечно. Вот, к примеру, код функции умножения:

int mul(int a, int b) {return 42;}

Она прекрасно работает, если ей передать 6 и 7. Ну, или 7 и 6. Всё остальное — не моя проблема.

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

_>Да, linq тут не у дел, а при этом тупой императивный for легко справляется и тут. Собственно именно об этом я писал изначально, но потребовалось как-то многовато времени и конкретных примеров, чтобы собеседники смогли ощутить это сами...
Легко — не значит хорошо.
Конкретного примера, кстати, так и нету.

_>Ну это всё делается не совсем так. Не плохой вариант ты можешь глянуть например здесь https://github.com/matt-42/vpp.
Вот именно так и делается, как я написал. Вместо тупого императивного for в стиле

for(int j=0; i<height; i++) for(int i=0; j<width; j++) res[i, j] = (src[i-1,j] + src[i, j-1] +  src[i+1,j] + src[i,j+1]) / 4;

мы пишем декларативный

pixel_wise(relative_access(A), B) | [] (auto a, int& b) {
  b = (a(-1, 0) + a(1, 0) + a(0, 1) + a(0, -1)) / 4;
};

А если нам захочется написать что-то вроде фотошопа, где фильтр задаётся коэффициентами, а не императивной кернел-функцией, то эффективнее будет тот подход, который я написал.
_>Для этого есть библиотеки типа Eigen. Только они работают на более низком уровне (векторы, матрицы и т.п.).
Ну то есть это примерно 15% того пути, который надо пройти.
_>Ну так никто не против таких подходов, только при правильной модели и реализации...
А с чем же тогда вы спорите?
_>Или ты думаешь, что я агитирую за написание множества своих велосипедов? Как раз наоборот, в моих текущих проектах используются десятки чужих сложнейших библиотек, фреймворков и т.п. Но они там все по делу, и по эффективности они ничуть не хуже написанного мною в лоб кода (гипотетического).
Пока что видно, что вы неверно понимаете слово "эффективность". Вы занимаетесь микрооптимизациями — это крайне интересная область, но в распределённой среде важно не умение быстро выполнить миллион операций, а суметь выполнить только 10000 операций из них.

S>>Язык, который навязывает нам использование вложенных циклов, неинтересен.
_>Язык ничего не навязывает. Императивный for — это универсальный базовый кирпичик, с помощью которого можно эффективно решить любую задачу. Причём это может быть как конкретный частный случай (который возможно и имеет смысл решать в лоб), так и какой-то обобщённый фреймворк для всего класса подобных задач с неким DSL.
Ну вот вы же сами привели пример задачи, в которой for противопоказан.

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

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

_>>>На самом деле у Монго немного другая схема. Sinclair тут намекал на то, что в Mongo данные пишутся на диск не перед завершением транзакции, а с какой-то переодичностью (раз в сколько-то секунд, как раз для оптимизации быстродействия) и что типа только из-за этого она такая быстрая, но зато при сбое теряются данные, которые не успели быть записаны. Так вот на самом деле данные там пишутся как раз мгновенно (ну т.е. перед завершением транзакции), только не в саму БД, а в некий специальный журнал изменений (очищаемый как раз при записи в саму БД).
S>>Во-первых, это опциональный режим. То есть они всё ещё умеют обходиться без write-through коммита.

_>Ты что-то путаешь. Я помню, что ставил Монгу с самыми дефолтными опциями и она громко ругалась при восстановление данных из журнала (при следующем старте), после убийства процесса в диспетчере задач. Так что это точно не какой-то особый режим.
https://docs.mongodb.com/manual/core/journaling/, https://docs.mongodb.com/manual/tutorial/manage-journaling/

_>Хы, помнится мы тут на форуме тестировали некий пример несколько лет назад и в нём Монга обходила MS SQL. При этом я запускал Монгу как раз в дефолтном режиме, без каких-то спец. опций.
Вот по умолчанию, если вручную при записи не требовать j:true, то монга выполняет коммит в памяти. Но,

In between write operations, while the journal records remain in the WiredTiger buffers, updates can be lost following a hard shutdown of mongod.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну так САР-теорему никто не отменял.
Это само-собой. Я к тому, что тысяча узлов все равно можно, просто не факт, что они будут доступны в случае сетевого сбоя, потому как согласованность.

Здравствуйте, vdimas, Вы писали:
V>Что может помешать когда-нить в будущем добавить в LINQ операторы рекурсивных ссылок, на манер современных диалектов SQL?
Вот прямо сейчас — мешает семантика С#. В отличие от SQL, в котором CTE считается определённым сразу после того, как его упомянули в with, в C# переменная считается определённой только после окончания стейтмента.
Поэтому вот так — можно:

WITH DirectReports(ManagerID, EmployeeID, Title, EmployeeLevel) AS   
(  
    SELECT ManagerID, EmployeeID, Title, 0 AS EmployeeLevel  
    FROM dbo.MyEmployees   
    WHERE ManagerID IS NULL  
    UNION ALL  
    SELECT e.ManagerID, e.EmployeeID, e.Title, EmployeeLevel + 1  
    FROM dbo.MyEmployees AS e  
        INNER JOIN DirectReports AS d  
        ON e.ManagerID = d.EmployeeID   
)  

SELECT ManagerID, EmployeeID, Title, EmployeeLevel   
FROM DirectReports

А вот так — нет:

            var directReports =
              (from m in Employees where !m.ManagerID.HasValue
               select new { m.EmployeeID, m.FirstName, m.LastName, m.ManagerID, EmpLevel=0 })
              .Union
              (from e in Employees
               join r in directReports on e.ManagerID equals r.EmployeeID // use of undefined variable directReports
               select new { e.EmployeeID, e.FirstName, e.LastName, e.ManagerID, EmpLevel = r.EmpLevel + 1 }
              );

Gt_>>серьезно. и опыт реальный имеется. раньше было модно подготавливать данные чем-то высокоуровневым типа sas data miner, который транслировал свои flow в sql. теперь мода на гораздо более низкоуровневые R/Phyton
IB>То есть из-за того, что вы перешли с одного стека технологий на другой, теперь делаем далеко идущие выводы о том что в место sql-я теперь везде используют R/Python? Ну, то есть, ничего бы нам с той водки не было, еслиб не ириска?

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

IB>Еще раз, если данные хранить не надо, значит sql там и не нужен был. Если кто-то готовил модели в sql-е, а потом стал готовить их в питоне, это не значит, что sql плохой, это значит, что для работы с моделями в питоне больше библиотек, фреймворков и других инструментов. sql, как уже было сказано, в другом месте стека находится.

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

Gt_>>вообше не понял о чем тут речь.
IB>Это видно ) Пример с DS тут вообще не в тему, но видимо билет был выучен только про блох ))
эх Ваня, я тебя серого еще лет 15 назад просвещал по базовым вопросам рсубд

Gt_>>ML фреймворк это уже следующий этап, но и там я уже не вижу ничего декларативного.
IB>Там декларативного, чуть менее чем все, на то он и фреймворк.
подучиться бы тебе, Ваня

Gt_

S>Во-вторых, вот именно эта штука, которая называется write-ahead log, взята 1-в-1 из RDBMS, потому что их тоже не дураки писали. И именно поэтому я и "намекал", а, точнее, писал открыто: в таком режиме commit в Монгу занимает ровно столько же времени, как и в RDBMS. Потому что делается ровно то же: флашится буфер журнала, а это как минимум 1 IO операция, которая, внезапно, упирается в HDD, а не в алгоритмы СУБД или язык реализации.
S>Все легендарные скорости записи достигаются исключительно при отключении write-through коммитов, потому что чудес не бывает. Некоторые особо резвые RDMBS тоже оборудованы аналогичными режимами, но их использование малоинтересно, т.к. нас интересуют предсказуемые поведения, а не "авось проконает". Если вы готовы пожертвовать данными, то математик внутри меня подталкивает сразу смонтировать базу на dev/null и обеспечить непревзойдённую скорость записи

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

Gt_

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

Gt_>не, мы делаем вывод, что ты не понимаешь даже когда тебе 2 раза пережовывают.
Надо бы пережовывалку подправить, а то она у вас что-то не то выдает ))

Gt_> целые индустрии, и не только фейсбуки с лайками, но и бигдата, датасаенс, iot постепенно откзываются от sql в пользу нечто более низкоуровневого.
Смелое утверждение, но мимо фактов. Мы же уже в этом топике выяснили, что к бигдате, наоборот SQL прикручивают, яндекс для датасайнса свой SQL пилит. Так что по прежнему непонятно кто от чего отказывается, и главное, почему.

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

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

Gt_>эх Ваня, я тебя серого еще лет 15 назад просвещал по базовым вопросам рсубд
Да, тогда это было даже смешнее, чем сейчас )

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

S>А вот так — нет:
Ну, прям так нет... Но через Y-комбинатор рекурсию можно.
Помнишь Мэдс писал у себя гиковский пост, как такое делается?

Gt_>>эх Ваня, я тебя серого еще лет 15 назад просвещал по базовым вопросам рсубд
IB>Да, тогда это было даже смешнее, чем сейчас )

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

Gt_>> целые индустрии, и не только фейсбуки с лайками, но и бигдата, датасаенс, iot постепенно откзываются от sql в пользу нечто более низкоуровневого.
IB>Смелое утверждение, но мимо фактов. Мы же уже в этом топике выяснили, что к бигдате, наоборот SQL прикручивают, яндекс для датасайнса свой SQL пилит. Так что по прежнему непонятно кто от чего отказывается, и главное, почему.

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

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

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

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

в ынтрпрайзе обычно из даталейка, а даталейк это просто parquet, csv, json файлики на hdfs. если объем не велик, просто могут к себе в винду скопировать файлики и играть с ними локально.

Gt_

	От:	alex_public
	Дата:	14.05.18 17:35
	Оценка:

	От:	alex_public
	Дата:	14.05.18 17:37
	Оценка:

От:	IB	http://rsdn.ru
Дата:	14.05.18 17:39
Оценка:

	От:	alex_public
	Дата:	14.05.18 17:47
	Оценка:	+1

	От:	Ночной Смотрящий
	Дата:	14.05.18 20:58
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	15.05.18 03:24
Оценка: