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

_>Так foreign key constraints задаются в коде или же берутся с сервера в рантайме?
С сервера в рантайме.
_>Получится, если делать это во время компиляции (в идеале) или при инициализации приложения (вариант похуже, но всё равно лучше текущей реализации linq для СУБД).
Для приложений 24x7 никакой "инициализации" нет. Но да, возможность кэшировать результаты — нужна.

_>Низкоуровневостью и следующей из неё универсальностью и эффективностью. Можно без проблем взять любой существующий C/C++ код (например ту же самую реализацию .net из mono, как сделали в проекте blazor) и просто скомпилировать его под WASM. Причём быстродействие будет всего раза в 2 хуже нативного кода (что гораздо лучше любых других безопасных решений, типа CLR и JVM).
Интересно. Будем думать.

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

_>Хы, да есть решения даже покруче (типа нецелевого использования VMT), причём в базовых библиотеках от MS. А к примеру библиотека сопрограмм (stackful) из Буста опирается об ассемблерный код (написанный отдельно под каждую архитектуру процессоров) сохранения/восстановления регистров. И ничего страшного.

_>Ну можешь посмотреть на него, как на вложенные коллекции — это сильно изменит ситуацию? )))
Только в худшую сторону. Как правильно смотреть — я ответил в параллельной ветке, там где с Иваном спор.

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



IT>Linq провайдер именно этим и занимается. Первый метод выделяется в отдельное выражение, компилируется и когда надо вызывается для того, чтобы получить значение, которое поедет в запрос как параметр. Второй метод становится частью финальной проекции из которой выделяется всё, что можно сконвертировать в SQL, остальное так же компилируется и вызывается для материализации возвращаемого объекта. Только всё это делается в рантайме, по построенному компилятором дереву вышеприведённого кода.

IT>Может ли такое же сделать компилятор? Конечно, может. В теории. Хотя нет. На практике тоже может, но, как я уже говорил, с большими ограничениями.
..... поскипано.....

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

мой основной вопрос был:

зачем вообще это — select new WpfCustomerViewModel(t.Field2, t.Field3); пытаться выполнять на сервере?

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

MH>Уважаемый IT , вы видимо или меня с кем-то перепутали или не на то сообщение ответили )

Я отвечал в топик, так что не надо принимать это так близко к сердцу.

MH>В целом, с высказанными вами аргументами согласен, но я и не высказывал предложения, что именно компилятор на этапе компиляции должен проверять все эти нюансы

MH>мой основной вопрос был:
MH>

MH>зачем вообще это — select new WpfCustomerViewModel(t.Field2, t.Field3); пытаться выполнять на сервере?

Второй вариант.

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

MH>линк-провайдер же уже умеет понимать — поддерживает ли скл-сервер конкретную функцию. нет с этим проблемы. есть проблема, что если скл не поддерживает придётся тащить, ну тут либо поддержать функцию на скл-сервере либо тащить данные и локально фильтровать.
Вот об этом IT и говорит: "либо научить компилятор вместе с клиентским кодом заглядывать в код сервера".

Здравствуйте, alex_public, Вы писали:
_>Ну если смотреть по быстродействию, то не просто хорошо, а лучше всех. )))
Да ну? А если померить?

_>Ты его сам же ниже написал, причём аж в одну строчку. )))
Ну а почему его я-то должен писать?

_>Вообще то как раз современные распределённые решения (они же все nosql) берут совершенно другим принципом. Там выполняется множество "ненужной" работы, но за счёт того, что это происходит на сотнях узлов, итоговый результат выдаётся всё равно быстрее чем у "умного" решения на одном сервере.
Это называется "ложная альтернатива". Когда мы снижаем эффективность в 100 раз, а потом заливаем это 1000кратным удорожанием системы. Хочется того же — только без такого просада эффективности.


_>For нигде не противопоказан. Мы или используем его сами или используем его внутри неких абстракций, представляющих собой уже готовые алгоритмы.
Ну вот внезапно оказывается, что эффективный способ записывать 2d-фильтрацию исключает использование for.

Здравствуйте, alex_public, Вы писали:
_>И ты только сейчас это понял???
Бывает — туплю иногда.

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

_> Основной инструмент Питона для работы с табличными данными называется pandаs, и именно он используется большинством аналитиков, учёных, инженеров и т.п. Так вот linq не идёт ни в какое сравнение с этим инструментом по удобству и эффективности работы.
linq и sql — инструменты общего назначения. pandas — инструмент нарошно сделанный для аналитиков под их задачи. Который, к слову, на вход понимает и sql помимо всяких csv, json и прочей фигни. Очевидно специально заточеный инструмент будет эффективнее и удобнее общего, и именно это причина что используют его, а не голый sql, да и то поверх pandas приделали pandasql для некоторых сценариев. Наверно pandas слишком крут для простых задачь? ))

_>Действительно, импортировать сырые данные в Питон из своего nosql хранилища гораздо удобнее напрямую, а не через промежуточный csv файл. Но анализ данных то всё равно выполняется в Питоне, вне зависимости от способа импорта сырых данных.
Собственно с этого и начался этот бестолковый спор, где место SQL, а где место питона в технологическом стеке.

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

_>>Да всё что угодно. Сравнивать API hadoop и SQL — это тоже самое, что сравнивать C++ и 1C...
IB>Не, что угодно — не ответ ) В каких конкретно сценариях не хватает возможностей sql и нужен доступ к потрохам СУБД?

Как минимум для всех тех случаев, для которых сейчас применqется PL/SQL.

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

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

И всё это легко реализуется поверх низкоуровневого API типа Hadoop.

_>> А вот обратное не верное — мы не можем выразить все возможные nosql решения через sql.
IB>Я кажется понял в чем у вас проблема, вы там выше писали, что "sql не имеет средств для решения задач". Так вот sql — не средство решения задач, это средство описания результата.
IB>Если требовать от sql-я то же что и от императивного языка, то естественно будет куча претензий, но он вообще-то про другое )
IB>Коль скоро мы можем описать желаемый результат, то совершенно пофиг через какое решение он там выражается, это уже задача сервера выбрать оптимальный алгоритм.

Только при таком подходе, тебе для решения задачи придётся каждый раз писать свою СУБД.

_>>Совершенно верно. И пока мы не будем убирать фундамент из полученной пирамиды абстракций, у нас всё будет отлично. А вот если мы выкинем возможность доступа на самом фундаментальном уровне (как сейчас в мире РСУБД), то сразу получим не эволюцию, а деградацию.
IB>Как раз наоборот, наличие низкоуровневого API ограничивает возможности оптимизации и эволюцию самих серверов.
IB>В РСУБД, наличие теории и строгой мат-модели позволило формально доказать, что императивное API не нужно для достижения результата, поэтому его и не было изначально. nosql идут от практики, но закончится все тем же, скорее всего.

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

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

_>>Наоборот, это ускорит прогресс, т.к. наконец то появится реальная конкуренция.
IB>Ну да, а сейчас чем конкуренция не реальная? ) С чем с чем, а с конкуренцией все хорошо.

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

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

Вообще то низкоуровневые потроха СУБД как раз не надо будет переписывать — в этом и есть главное преимущество по сравнению с твоим подходом (писать запрос на SQL, а тюнинг под конкретную специфику осуществлять с помощью написания новой СУБД с нуля). Потребуется написать только конвертер из некого внутреннего DSL (уже есть в большинстве ORM) в алгоритмы исполнения запросов (шаблоны алгоритмов можно взять например из исходников postgresql).

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

_>> Вот на русском языке это звучит так: хотим получить массив, каждый элемент которого является усреднением соседей этого элемента в исходном двухмерном массиве. Вроде бы как раз описание желаемого результата, без каких-либо указаний о механизме реализации. Покажешь как это сформулировать на linq?
IB>from Filter(data, filterType, parameters) select x,
IB>пойдет? )

А что мешает написать написать просто res=Filter(data, filterType, parameters) ?

_>>И в чём разница?
IB>в том, что он и не должен мочь.

Ну т.е. Linq не может (ок, потому что и не должен мочь) многие операции с коллекциями. В отличие от того же тупого императивного for. Теперь надеюсь мы это уже однозначно выяснили, правильно?

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

_>>Так это у тебя только пример "объявления AST", который может быть и вполне корректным для определённых задач (скажем при исполнение на клиенте). А где у тебя собственно код отправления этого запроса на сервер? Ведь именно там система должна послать тебя очень далеко (в идеале на стадии компиляции, но в текущей убогой реализации linq это видимо только в рантайме возможно)...
IT>Про код отправки запроса на сервер компилятором я не всё понял, поэтому предположу, что ты имеешь ввиду генерацию компилятором некоего кода, который потом в рантайме будет отправлятся на сервер. Здесь я тебя должен огорчить, мой компиляторолюбивый друг, запросы вида
IT>

IT>from t in Table where t.id == 1 select t
IT>

IT>встречаются в демонстрационных примерах примерно на несколько порядков чаще, чем в реальном коде. В реальном коде мы наблюдаем чаще всего что-нибудь типа этого:
IT>

IT>var q = from t in Table select t;
IT>if (name.IsNotEmpty())
IT>    q = q.Where(t => t.Name == name);
IT>if (idList.IsNotEmpty())
IT>    q =
IT>        from t in q
IT>        join id in IdTable on t.ID equals id.ID
IT>        where id.ID.In(idList)
IT>        select t;
IT>var list q.ToList();
IT>

И в чём разница? С точки зрения обсуждаемого нами вопроса вообще ничего не изменилось. Всё равно должна быть одна точка отправки запроса на сервер, в которой тривиально принимается решение (в идеале на стадии компиляции) о валидности переданного кода.

IT>И это является одной из самых сильных сторон linq. Это позволяет строить более оптимальные запросы, которые при всей якобы медлительности linq, рвут по производительности всякие сохранённые процедуры и прямой SQL как тузик грелку.



С учётом того, что Linq всего лишь генерирует SQL, то разговоры о том, что он "рвёт по производительности прямой SQL как тузик грелку" крайне забавны. Это вот буквально так же смешно, как утверждение IB (уже благополучно замятое) о том, что linq для коллекций рвёт по быстродействию тупой for.

IT>Но при этом, всё, что может сделать компилятор — это сгенерировать промежуточное AST. Не готовый API для SQL, а AST этого кода, который ты уже в рантайм соберёшь в нечто более менее целое и сгенерируешь свой API для SQL. И если пойдёшь таким путём, то всё будет хорошо. Только есть одно но — ты только что изобрёл LINQ over WCF. Там всё именно так и работает.

Ну это текущий компилятор C# и текущая реализация Linq только так умеют (и то в теории). А есть ещё и другие варианты, в более мощных языках.

_>>Да, я не вижу абсолютно никакой проблемы в том, что система не будет позволять выполнять априори некорректный код. Так же как и на GPU тебе никто не позволит отослать неподходящий для этого код.
IT>Никто — это для меня слишком абстракто. Кто именно никто?

Так смотря какую конкретную технологию мы используем. Ну давай возьмём для определённости OpenACC.

Допустим у тебя есть такой самый обычный код (взял из примера отсюда https://devblogs.nvidia.com/getting-started-openacc/), исполняющийся в твоём приложение:

for( int j = 1; j < n-1; j++) {
    for( int i = 1; i < m-1; i++ ) {
      Anew[j][i] = 0.25 * ( A[j][i+1] + A[j][i-1] +
                            A[j-1][i] + A[j+1][i]);
      error = fmax( error, fabs(Anew[j][i] - A[j][i]));
    }
  }

Так вот с помощью OpenACC тебе достаточно всего лишь написать перед этим циклом директиву "#pragma acc kernels", как данный код будет скомпилирован не в x86 инструкции, а в специальный язык nvidia и вставлен как данные в программу, а на месте цикла будет размещён код запуска этого фрагмента на GPU.

Однако стоит тебе вставить внутри этого цикла какую-нибудь ересь (неподходящий для GPU код, например тоже самое обращение к СУБД), как компилятор сразу же пошлёт тебя очень далеко.

IT>>>Почему SQL недостаточно? И почему более низкоуровневый (это какой) API достаточно?
_>>Ну у SQL то вообще всё тяжело, т.к. он не позволяет задавать даже не использующий внутренний API (грубо говоря чистую функцию), произвольный императивный код.
IT>Зачем? Кому это надо?

Если это никому не надо, то зачем по-твоему появились на свет различные вариации PL/SQL? )))

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

_>>Ну так если проблем нет, то почему я не вижу кода обсуждаемых примеров? В чём проблема "описать на linq желаемый результат"? Вот на русском языке это звучит так: хотим получить массив, каждый элемент которого является усреднением соседей этого элемента в исходном двухмерном массиве. Вроде бы как раз описание желаемого результата, без каких-либо указаний о механизме реализации. Покажешь как это сформулировать на linq?
S>Ну ладно, уговорил.
S>Вот как это выглядит на linq:
S>

S>var data = new int[10, 10];
S>var t1 = from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;
S>

error CS1935: Не удалось найти реализацию шаблона запроса для типа источника "int[*,*]". "GroupBy" не найден. Возможно, отсутствует ссылка или используется директива для "System.Linq".

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

_>>И? Прямо по твоим ссылкам написано, что журнал работает как раз по умолчанию.
S>И при этом без явного указанbя j:true "коммит" происходит в памяти. Это — ровно то, о чём я говорил.

Кстати, я вспомнил тот тест. Да, там код на монге был без j:true, но и sql код был без транзакций. Так что всё было по честному.

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

_>>У Яндекса не может быть отказов от SQL в сторону Питона или наоборот, потому как в основе у них лежит вообще другой инструмент. Их базис — это собственноручно написанное nosql решение по схеме MapReduce, работающее с C++ (в смысле не только само на нём написанное, но и выполняющее произвольный код в запросах). Т.е. это что-то вроде своего аналога Hadoop, только не с Java, а с C++. В какой-то момент им видимо надоело писать однотипный императивный код для шаблонных случаев и они захотели написать свой высокоуровневный язык запросов. Только не такой убогий, как SQL, а значительно лучше: там есть и исполнение произвольного императивного кода (причём аж на C++! Ну и на Питоне ещё, но это там реализовано как просто C++ функция с интерпретатором Питона) и MapReduce и декомпозиция запросов и ещё много чего интересного.
L>О, ты, похоже, слышал про YT. А слышал ли ты, что кроме него есть еще минимум 2 другие MR-системы. Это не считая реляционных баз и всяких key-value хранилищ.

Ну так в любом случае это был и не sql и не питон, а нечто низкоуровневое. Так что ни о каких перехода в одну или другую сторону априори речи нет.

L>Любая приличная реализация SQL умеет UDF, которые, внезапно, можно писать на плюсах (Яве, Шарпе, etc). В YQL оно работает ровно так же. Хочешь исполнять код на плюсах или питоне — пиши UDF с довольно жестким интерфейсом.

О, интересненько... С удовольствием послушаю как в языке SQL описывается загрузка UDF функций...

_>>Но это всё касалось грубо говоря доступа к данным (по сути API к БД), а реальной обработкой данных современные аналитики предпочитают заниматься в Питоне и с помощью Jupyter Notebook.
L>Получение и подготовка данных — это, внезапно, часть реальной обработки, без которой ты никуда не уедешь.

SQL/YQL и т.п. теперь касается только получение данных. )

_>>Только раньше им надо было в начале загрузить данные (с помощью низкоуровневой mapreduce команды, написанной на C++) из хранилища Яндекса в csv файлик, а потом импортировать его в Питон. А теперь они могут просто в одну строчку загрузить данные их хранилища данных Яндекса (точно так же как они привыкли это делать для любых SQL баз, Hadoop'a и т.п.).
L>А ничего, что CSV-файлик на десяток терабайт может получиться, например? Долго его питону будешь скармливать?

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

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

_>>Ну вот например я хочу не SQL, а такой https://www.opencypher.org/ язык для своей задачи. Тот же Hadoop/Spark это легко позволяют https://neo4j.com/blog/cypher-for-apache-spark/.
S>Это интересная инициатива. Но, во-первых, это по-прежнему декларативный язык, то есть непринципиально отличающийся от SQL, а во-вторых, я ещё не убедился, что он чем-то сильно лучше.

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

S>В-третьих, если вы хотите гонять его поверх RDBMS, то скорее всего, его не очень трудно просто транслировать в SQL. Без какой-либо потери производительности.

Сомневаюсь. Тут нужны совсем другие алгоритмы обхода данных.

_>>И в чём проблема https://habr.com/post/154007/ ? )
_>>Ну естественно "подтюнивание" будет заключаться в написание своей коллекции, точно так же как написанный на C модуль numpy превращает медленный Питон в один из главных инструментов вычислений у учёных, инженеров, аналитиков, специалистов по машинному обучению и т.п.
S>Нет, так — не сработает. Либо работать будет не быстрее, чем встроенные коллекции, либо сломается интероперабельность. И вам весь-весь код придётся писать самому и с нуля.

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

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

Ну ОК, вот есть у нас PostgreSQL сервер...

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

_>>Ну если смотреть по быстродействию, то не просто хорошо, а лучше всех. )))
S>Да ну? А если померить?

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

_>>Вообще то как раз современные распределённые решения (они же все nosql) берут совершенно другим принципом. Там выполняется множество "ненужной" работы, но за счёт того, что это происходит на сотнях узлов, итоговый результат выдаётся всё равно быстрее чем у "умного" решения на одном сервере.
S>Это называется "ложная альтернатива". Когда мы снижаем эффективность в 100 раз, а потом заливаем это 1000кратным удорожанием системы. Хочется того же — только без такого просада эффективности.

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

_>>For нигде не противопоказан. Мы или используем его сами или используем его внутри неких абстракций, представляющих собой уже готовые алгоритмы.
S>Ну вот внезапно оказывается, что эффективный способ записывать 2d-фильтрацию исключает использование for.

For там сидит внутри. )

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

_>> Основной инструмент Питона для работы с табличными данными называется pandаs, и именно он используется большинством аналитиков, учёных, инженеров и т.п. Так вот linq не идёт ни в какое сравнение с этим инструментом по удобству и эффективности работы.
IB>linq и sql — инструменты общего назначения. pandas — инструмент нарошно сделанный для аналитиков под их задачи. Который, к слову, на вход понимает и sql помимо всяких csv, json и прочей фигни. Очевидно специально заточеный инструмент будет эффективнее и удобнее общего, и именно это причина что используют его, а не голый sql, да и то поверх pandas приделали pandasql для некоторых сценариев. Наверно pandas слишком крут для простых задачь? ))

pandasql работает не поверх pandas, а поверх sqlite. С pandas его связывает только то, что он берёт данные их базового табличного типа pandas и возвращает их в него. Ну и создан он для специфической аудитории людей, не имеющих опыта в Питоне, но хорошо знающих SQL. Потому как если взглянуть на примеры его использования (ну вот например здесь https://habr.com/post/279213/), то можно легко увидеть, что во всех случаях код с pandas заметно лаконичнее и удобнее (автодополнения то у sql строк нет).

_>Кстати, я вспомнил тот тест. Да, там код на монге был без j:true, но и sql код был без транзакций. Так что всё было по честному.
SQL кода без транзакций не бывает. Бывает автокоммит.

S>>Ну ладно, уговорил.
S>>Вот как это выглядит на linq:
S>>

S>>var data = new int[10, 10];
S>>var t1 = from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;
S>>

_>

_>error CS1935: Не удалось найти реализацию шаблона запроса для типа источника "int[*,*]". "GroupBy" не найден. Возможно, отсутствует ссылка или используется директива для "System.Linq".

_>:
Все верно. Это было описание желаемого. Теперь надо к нему прикрутить реализацию.
И вот как раз тут мы можем рулить всем процессом — от тупого императивного for до автоматической трансляции в cuda.

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

_>Да причём тут это. Ты разве не понимаешь, что отсутствие низкоуровневого интерфейса убивает сам принцип разнообразия высокоуровневых абстракций, оставляю только одну (которая сейчас служит API). Т.е. дело не в конкретном языке для графов, а в подходе расширяемости.
Совершенно верно. Просто надо выбирать: шашечки либо ехать. Если хочется шашечки — то да, надо низкий уровень, и пусть программист лично отвечает за всё, что происходит. И за корректность, и за производительность. Примерно так и было в семидесятые годы. Потом оказалось, что подобные проекты тонут: время реализации нелинейно зависит от объёма кода, несмотря на увеличение количества разработчиков.
Поэтому стали развиваться средства декомпозиции и изоляции: идея в том, чтобы вместо позволения писать "любой" код позволять писать "корректный" код. И давать гарантиии сохранения корректности при внесении изменений.
Для меня "принцип разнообразия высокоуровневых абстракций" имеет второстепенное значение. Да, я понимаю привлекательность средств языкостроения типа Немерле, но как продакт менеджер я больше заинтересован в одном "хорошем" языке, чем в дюжине бездарных.

S>>В-третьих, если вы хотите гонять его поверх RDBMS, то скорее всего, его не очень трудно просто транслировать в SQL. Без какой-либо потери производительности.
_>Сомневаюсь. Тут нужны совсем другие алгоритмы обхода данных.
В SQL нет никаких алгоритмов. Именно в этом его преимущество: он описывает то, какие данные надо получить, а не алгоритм обхода.

_>Естественно коллекции numpy имеют специфичные свойства (и именно из-за этого они в разы быстрее встроенных). Так их и применяют не где попало, а в специфическом коде (тяжёлых вычислений). Так что не вижу никаких проблем.
Ну, то есть мы говорим не о подтюнивании, а о полной замене с потерей интероперабельности. Так — неинтересно: невозможно начать проект, изолировать в нём узкие места, и оптимизировать их.
С numpy ситуация другая — там у нас задача известна с самого начала, и питон используется только как высокоуровневый клей для вызова хардкорных алгоритмов, написанных не на нём.
_>Ну ОК, вот есть у нас PostgreSQL сервер...
У постгрес стратегия изоляции транзакций другая — в нём нет локов, как таковых; поэтому нет и смысла ими управлять.