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

V>>Машинка — HP ProLiant DL370 G6
V>>Oracle Database 11g — 631766,00
V>>Microsoft SQL Server 2005 — 661475,00
S>Ну и что? Мы говорим о максимальных мощностях

Мы говорим о ситуации в современом IT.


S>а не об "обычных серваках на ксеонах"

А в современном IT 99% всех серваков — они "обычные", на ксеонах.


S>Если ограничиться 80286, то вообще всех порвёт FoxPro.

Это не современное IT.

V>>Возьми свой ноут, который на батарейках, поставь Оракл, MySQL и сравни.
S>Предположение о том, что результаты замеров на ноуте можно масштабировать на "дичайшие sun-кластеры" — это и есть нубство.

Я это не предполагал.
Я предлагал посмотреть на ходовые сценарии и что в них не так.


S>На ноуте и SQLite будет показывать отличные результаты.

Не будет.


V>>За пол-ляма в сек "просто запросов" MySQL перешагнул уже относительно давно на относительно скромном оборудовании.
S>Меня не интересуют "просто запросы". Интересуют результаты нормальных бенчмарков.

Зависит от сценариев.
Когда надо в основном только отдавать данные, то MySQL на современной технике практически вне конкуренции.


S>А пока что речь идёт о том, как бы он круто выиграл забег, если бы ему дали.

Дык, он и выиграл давным давно.
Чуть менее чем весь современный веб опирается на MySql в бэкенде.


V>>А твоими цифрами, как обычно, только детей пугать. ))
S>Ну, мы же сравниваем биржевую торговлю с учётными системами, нет? Или там весь NASDAQ бегает на "обычном серваке на ксеонах"?

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


S>Если нет, то нехрен и RDBMS ограничивать.

Но ведь нет. ))
На этом кластере при его чудовищной througput показана одна из самых плохих latency — порядка 0.1 сек.
Это только в мусорку по современным реалиям.


V>>Просто ты пытаешься рядом рассуждать о "недостатке декомпозиции в SQL" (С) не понимая принципов построения языков этого поколения.
V>>И тем более не понимая оксюморона ситуации с генерацией предложений этого языка из более низкоуровневых языков.
S>Продолжается беспредметное умничание. Кого интересует моё непонимание? Тут мы видим твою неспособность объяснить, не более того.

Так я ХЗ с какого уровня начинать давать, ты же не определил себя никак.
Можно начать с базы — языки 3-го поколения построены на простой базе, но мощных ср-вах комбинирования этой базы.
Языки 4-го — наоборот. Имеют мощную базу при слабой возможности комбинирования.
Считается, что одно выражение языка 4-го поколения и так уже достаточно высокоуровневое, т.е. покрывает собой тысячи и/или десятки тысяч строк кода на языках третьего поколения.

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

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

Но должны были пройти те самые 30 лет, чтобы сформировалось понимание, как будет лучше — т.е. удобней для человека и эффективней для машины.
А так-то на момент разработки SQL классикой 3-го поколения были C/Pascal/Lisp, классикой 4-го поколения Prolog/REXX/sh.

Ну понятно, что от плохого понимания перспектив развития IT язык SQL получился чем-то вроде Пролога, ы-ы-ы. Собсно, внутренняя механика обеих языков имеет много общего. В этом месте стоит включить честность и заметить, что при наличии альтернатив Прологу от него легко отказываются.


S>А если нагрузка в полмиллиона транзакций в секунду не планируется — то можно обойтись и значительно более скромной аппаратурой, и выжимать такты на "статика против динамики" не потребуется.

Выжимать такты требуется всегда.
Такова наша реальность примерно с 2004-го года, когда кривая развития процов вошла в хорошо различимое насыщение.
А последние 4-5 лет так и вовсе на месте замерло.
Усё, приплызд.
Теперь надо повернуться лицом к софту и научить его выжимать максимум из железок.


V>>Аналог. В некоторых языках пошли на хитрость, сумев при почти таком же синтаксисе превратить SQL-запросы в полноценные выражения ФП-подобного языка. Но далее уже идёт строгая типизация и прочие плюшки развитого языка.
S>Это мы мне рассказываем про Linq?

Нет, это было до Linq.
Я же говорил много раз — Linq интересен, жаль что опоздал лет на 10.
И это множит его на ноль.
Вся инстраструктура донета развивалась без Linq.
А если бы его выкатили сразу, то C# не рассматривался бы как "еще одна джава" или как "Паскаль с сишным синтаксисом". Этот язык тогда рассматривали как "другой язык". Вон Пролог — это же "другой" язык, верно? )) Не как безликие-однотипные С/Паскаль/Джава.


V>>Современные оптимизаторы отслеживают не только типы, они отслеживают жизненный цикл данных, принимают решения по трансформации графа операций с данными и т.д.
S>А статистику они откуда берут?

Статистику берут оттуда же.


S>Откуда они знают, что при одном значении параметра надо сканировать один индекс, а при другом — другой?

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

Сейчас оценка происходит крайне медленно, поэтому иногда принимается решение взять "достаточно хороший" план, а не лучший.

Ну и, не знаю, стоит ли расписывать всевозможные ситуации.

Допустим, есть два варианта плана по запросу из 3-х таблиц. По одному плану идёт скан таблиц 1, 2, 3, по другому — 1, 3, 2. Нетрудно заметить, что уже в статике становится понятно, что одновременно с оценкой каждого плана уже можно сканировать таблицу 1.

Далее. Само сканирование (маппинг полей — проекции, вычисляемые поля и выражения при join т.д.) — сегодня это сильно тормозная штука в общих затратах (ведь это классика интерпретирования), бо скорость чтения с современных SSD-массивов приблизилась к скорости чтения обычной RAM. Это раньше можно было спекулировать на "этих затрат не видно и под микроскопом в сравнении со стоимостью чтения с диска", а сегодня забудь об этом аргументе навсегда. ))


V>>Там же сразу появляются мощные библиотеки, т.е. всё по-взрослому.
V>>А писанных тобой лично процедур — резко сократилось бы.
V>>Так у меня в любой базе жил еще заметный утилитно-библиотечный слой.
S>Ну да, примерно так и есть. Хотя чётко отделить кто пишет какой слой скорее всего не получится.

Фантазировать прямо отсюда — это как разрабатывать SQL в 70-х годах. ))
Тут надо просто дать инструмент и посмотреть куда кривая выведет.
Заметь, что бурное в последние годы развитие самих языков (C++/Java/C#) диктуется исключительно прикладным кодом на этих языках.
Т.е. вот она обратная связь.


V>>У меня сие "осознание" произошло еще до 97-го года.
S>А выглядит так, что оно появляется ровно в процессе этого разговора.

Брехня. Мы с тобой по этой теме цеплялись еще в 2004/2005-хх, но ты был совсем невменяем. ))
Собсно, на тот момент альтернатив не было ваапще никаких и попытки критиковать текущее положение вещей смотрелись дико, согласен.
Я и огребал.
Но так-то с 97-98-го года своё мнение не поменял — принципы работы с реляциоными СУБД весьма убоги.
Собсно, достаточно написать парочку больших приложений на БД чтобы увидеть, что даже 3-я нормальная форма — это миф, в живой природе не встречается, не говоря уже о форме Бойса-Кодда. Про 4-ю и выше вообще забудьте — ничего сложнее записной книжки в нормальные формы не воткнёшь.


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

Я рядом достаточно подробно писал, например в этой подветке:
http://www.rsdn.org/forum/flame.comp/7059865.1
И выше.

Просто мне сложно отвечать конкетно на абстрактные вопросы.
Там чел стал спрашивать конкретней — я иотвечал конкретней.

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


S>пишется "есть некоторые языки, которые менее ограничены кое-в-чём, по сравнению с кое-какими другими языками". Понятно, что на вот таких полунамёках построить полноценную дискуссию затруднительно.

Дисскуссию сложно строить на "ату его, ату!"
Но абсолютно каждый оппонент начинает именно с этого. ))

Это слава богу, что уже есть и неплохие компиллируемые NoSQL и прочие альтернативы, которые показывают какие-то совершенно дикие результаты в сравнении с "обычными" СУБД. Мне сейчас психологически банально легче, бо когда совсем уж против ветра было — то удовольствие не из изысканных.


V>>В общем, тут декомпозицией не отделаешься, тут дизайн языка с 0-ля менять надо.
S>Вот тут всегда возникает дилемма: слишком далёкий от привычного язык даст нулевую заинтересованность. Слишком близкий — даёт мало толку. Языки изобретать тяжело (по крайней мере, хорошие).

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


S>Опять же — как делать: по языку для каждого слоя, или один на всех?

Один с достаточной выразительностью.


S>Основной язык слишком императивный.

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

Ну и, говорил уже, нужна и РА и РИ.
Собсно, в современном Linq именно так и есть.
Просто РА сугубо императивна и практически не оптимизируется.



S>В современном мейнстриме мы имеем либо вавилон из JS+Java+SQL, когда каждую фичу должно делать три разработчика плюс два тестера плюс отдельный менеджер, чтобы следить, чтобы все края совпали, либо JS everywhere с феерически неэффектиывым бэкендом и базой данных.

Про JS я даже говорить не хочу, если честно.
В сравнении с JS обсуждаемый SQL — просто верх человеческой мысли. ))


V>>Просто лично я за такой язык, который допускал бы и статическую компиляцию с максимумом проверок/ограничений/оптимизаций.
V>>Но, если потянуть за эту ниточку — там вытягивается слишком много кардинальный отличий от нынешних мейнстримовых практик.
S>Чтобы штука заработала, надо, чтобы она окучивала целую вертикаль — вот прямо от клиента и до сервера.

От сервера до готовой к линковке транспортной либы для клиента. Причём, типа как из CORBA — бинд на кучу языков.

Блин, да я готов довольно много поставить на то, что в конце всех концов "оно" именно так и будет.
Там и выхода-то другого нет.


S>Иначе — будь любезен, соответствуй общепринятым стандартам.

Стандарты — штука капризная.
Protobuf появился вопреки всем стандартам и стал бешенно популярным, помножив весь IDL на ноль и почти на ноль XML-сообщения.
Это тупая инженерная хрень.
Тупейшая.
Бо отвечает прямо на прямо поставленные инженерные вопросы.
Но так и должно.


S>Я об таком в свободное время фоном думаю, но во-первых, уделяю мало времени, во-вторых, не уверен, что это всё ещё актуально.

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


S>Грубо говоря, непонятно, нужны ли ещё людям те приложения, которые я себе воображаю.

Нужны.


S>TPC-C вышел из моды потому, что уже лет 15 никто не пишет учётные системы.

Пишут конструкторы учётных систем. ))
А еще никто не разворачивает выч. мощности "сам", их теперь арендуют и почти всегда есть доступ к "достаточной" мощности.
Но так-то всё в силе, в любом случае.


S>Нет хороших фреймворков и вообще понимания, что и как должно делаться. Глобально — потому, что люди, выделяющие финансирование, катастрофически некомпетентны. Им показывают прототипы из одной странички, за которыми стоит база из 5 строчек. Когда начинается нормальная нагрузка — то либо проект дохнет (если не успевает принести денег), либо под него нанимаются мега спецы, которые способны собрать кастом билд MySQL и прикрутить статическую оптимизацию к PHP. Людям такого уровня "библиотеки" и "фреймворки" вообще не нужны — они сами могут компилятор сварганить.

Сварганить компилятор не сложно, можно за несколько вечеров на коленке.
А вот оптимизатор — это на той самой грани прогресса современного IT.


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

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

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

Ну и, один из самых популярных способов оптимизации в С++ сегодня — это оптимизация по показаниям профайлера.
Т.е. собрали, запустили профайлер. А затем пересобрали уже с показаниями профайлера.
Для БД это вообще идеальный сценарий, тогда и хинты ручками указыать не надо, они будут расставляться профайлером по-факту.


V>>Почему rsdn тормозит? ))
S>RSDN для своего объёма и железа просто летает. При этом у него внутри как раз MS SQL + linq2db.

ЧТД, "своего железа".
А не дикого кластера.
Отсюда и пляшем.

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

V>>Машинка — HP ProLiant DL370 G6
V>>Oracle Database 11g — 631766,00
V>>Microsoft SQL Server 2005 — 661475,00
S>Ну и что? Мы говорим о максимальных мощностях

Мы говорим о ситуации в современом IT.


S>а не об "обычных серваках на ксеонах"

А в современном IT 99% всех серваков — они "обычные", на ксеонах.


S>Если ограничиться 80286, то вообще всех порвёт FoxPro.

Это не современное IT.

V>>Возьми свой ноут, который на батарейках, поставь Оракл, MySQL и сравни.
S>Предположение о том, что результаты замеров на ноуте можно масштабировать на "дичайшие sun-кластеры" — это и есть нубство.

Я это не предполагал.
Я предлагал посмотреть на ходовые сценарии и что в них не так.


S>На ноуте и SQLite будет показывать отличные результаты.

Не будет.


V>>За пол-ляма в сек "просто запросов" MySQL перешагнул уже относительно давно на относительно скромном оборудовании.
S>Меня не интересуют "просто запросы". Интересуют результаты нормальных бенчмарков.

Зависит от сценариев.
Когда надо в основном только отдавать данные, то MySQL на современной технике практически вне конкуренции.


S>А пока что речь идёт о том, как бы он круто выиграл забег, если бы ему дали.

Дык, он и выиграл давным давно.
Чуть менее чем весь современный веб опирается на MySql в бэкенде.


V>>А твоими цифрами, как обычно, только детей пугать. ))
S>Ну, мы же сравниваем биржевую торговлю с учётными системами, нет? Или там весь NASDAQ бегает на "обычном серваке на ксеонах"?

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


S>Если нет, то нехрен и RDBMS ограничивать.

Но ведь нет. ))
На этом кластере при его чудовищной througput показана одна из самых плохих latency — порядка 0.1 сек.
Это только в мусорку по современным реалиям.


V>>Просто ты пытаешься рядом рассуждать о "недостатке декомпозиции в SQL" (С) не понимая принципов построения языков этого поколения.
V>>И тем более не понимая оксюморона ситуации с генерацией предложений этого языка из более низкоуровневых языков.
S>Продолжается беспредметное умничание. Кого интересует моё непонимание? Тут мы видим твою неспособность объяснить, не более того.

Так я ХЗ с какого уровня начинать давать, ты же не определил себя никак.
Можно начать с базы — языки 3-го поколения построены на простой базе, но мощных ср-вах комбинирования этой базы.
Языки 4-го — наоборот. Имеют мощную базу при слабой возможности комбинирования.
Считается, что одно выражение языка 4-го поколения и так уже достаточно высокоуровневое, т.е. покрывает собой тысячи и/или десятки тысяч строк кода на языках третьего поколения.

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

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

Но должны были пройти те самые 30 лет, чтобы сформировалось понимание, как будет лучше — т.е. удобней для человека и эффективней для машины.
А так-то на момент разработки SQL классикой 3-го поколения были C/Pascal/Lisp, классикой 4-го поколения Prolog/REXX/sh.

Ну понятно, что от плохого понимания перспектив развития IT язык SQL получился чем-то вроде Пролога, ы-ы-ы. Собсно, внутренняя механика обеих языков имеет много общего. В этом месте стоит включить честность и заметить, что при наличии альтернатив Прологу от него легко отказываются.


S>А если нагрузка в полмиллиона транзакций в секунду не планируется — то можно обойтись и значительно более скромной аппаратурой, и выжимать такты на "статика против динамики" не потребуется.

Выжимать такты требуется всегда.
Такова наша реальность примерно с 2004-го года, когда кривая развития процов вошла в хорошо различимое насыщение.
А последние 4-5 лет так и вовсе на месте замерло.
Усё, приплызд.
Теперь надо повернуться лицом к софту и научить его выжимать максимум из железок.


V>>Аналог. В некоторых языках пошли на хитрость, сумев при почти таком же синтаксисе превратить SQL-запросы в полноценные выражения ФП-подобного языка. Но далее уже идёт строгая типизация и прочие плюшки развитого языка.
S>Это мы мне рассказываем про Linq?

Нет, это было до Linq.
Я же говорил много раз — Linq интересен, жаль что опоздал лет на 10.
И это множит его на ноль.
Вся инстраструктура донета развивалась без Linq.
А если бы его выкатили сразу, то C# не рассматривался бы как "еще одна джава" или как "Паскаль с сишным синтаксисом". Этот язык тогда бы рассматривали как "другой язык". Вон Пролог — это же "другой" язык, верно? )) Не как безликие-однотипные С/Паскаль/Джава.


V>>Современные оптимизаторы отслеживают не только типы, они отслеживают жизненный цикл данных, принимают решения по трансформации графа операций с данными и т.д.
S>А статистику они откуда берут?

Статистику берут оттуда же.


S>Откуда они знают, что при одном значении параметра надо сканировать один индекс, а при другом — другой?

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

Сейчас оценка происходит крайне медленно, поэтому иногда принимается решение взять "достаточно хороший" план, а не лучший.

Ну и, не знаю, стоит ли расписывать всевозможные ситуации.

Допустим, есть два варианта плана по запросу из 3-х таблиц. По одному плану идёт скан таблиц 1, 2, 3, по другому — 1, 3, 2. Нетрудно заметить, что уже в статике становится понятно, что одновременно с оценкой каждого плана уже можно сканировать таблицу 1.

Далее. Само сканирование (маппинг полей — проекции, вычисляемые поля и выражения при join т.д.) — сегодня это сильно тормозная штука в общих затратах (ведь это классика интерпретирования), бо скорость чтения с современных SSD-массивов приблизилась к скорости чтения обычной RAM. Это раньше можно было спекулировать на "этих затрат не видно и под микроскопом в сравнении со стоимостью чтения с диска", а сегодня забудь об этом аргументе навсегда. ))


V>>Там же сразу появляются мощные библиотеки, т.е. всё по-взрослому.
V>>А писанных тобой лично процедур — резко сократилось бы.
V>>Так у меня в любой базе жил еще заметный утилитно-библиотечный слой.
S>Ну да, примерно так и есть. Хотя чётко отделить кто пишет какой слой скорее всего не получится.

Фантазировать прямо отсюда — это как разрабатывать SQL в 70-х годах. ))
Тут надо просто дать инструмент и посмотреть куда кривая выведет.
Заметь, что бурное в последние годы развитие самих языков (C++/Java/C#) диктуется исключительно прикладным кодом на этих языках.
Т.е. вот она обратная связь.


V>>У меня сие "осознание" произошло еще до 97-го года.
S>А выглядит так, что оно появляется ровно в процессе этого разговора.

Брехня. Мы с тобой по этой теме цеплялись еще в 2004/2005-хх, но ты был совсем невменяем. ))
Собсно, на тот момент альтернатив не было ваапще никаких и попытки критиковать текущее положение вещей смотрелись дико, согласен.
Я и огребал.
Но так-то с 97-98-го года своё мнение не поменял — принципы работы с реляциоными СУБД весьма убоги.
Собсно, достаточно написать парочку больших приложений на БД чтобы увидеть, что даже 3-я нормальная форма — это миф, в живой природе не встречается, не говоря уже о форме Бойса-Кодда. Про 4-ю и выше вообще забудьте — ничего сложнее записной книжки в нормальные формы не воткнёшь.


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

Я рядом достаточно подробно писал, например в этой подветке:
http://www.rsdn.org/forum/flame.comp/7059865.1
И выше.

Просто мне сложно отвечать конкетно на абстрактные вопросы.
Там чел стал спрашивать конкретней — я иотвечал конкретней.

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


S>пишется "есть некоторые языки, которые менее ограничены кое-в-чём, по сравнению с кое-какими другими языками". Понятно, что на вот таких полунамёках построить полноценную дискуссию затруднительно.

Дисскуссию сложно строить на "ату его, ату!"
Но абсолютно каждый оппонент начинает именно с этого. ))

Это слава богу, что уже есть и неплохие компиллируемые NoSQL и прочие альтернативы, которые показывают какие-то совершенно дикие результаты в сравнении с "обычными" СУБД. Мне сейчас психологически банально легче, бо когда совсем уж против ветра было — то удовольствие не из изысканных.


V>>В общем, тут декомпозицией не отделаешься, тут дизайн языка с 0-ля менять надо.
S>Вот тут всегда возникает дилемма: слишком далёкий от привычного язык даст нулевую заинтересованность. Слишком близкий — даёт мало толку. Языки изобретать тяжело (по крайней мере, хорошие).

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


S>Опять же — как делать: по языку для каждого слоя, или один на всех?

Один с достаточной выразительностью.


S>Основной язык слишком императивный.

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

Ну и, говорил уже, нужна и РА и РИ.
Собсно, в современном Linq именно так и есть.
Просто РА сугубо императивна и практически не оптимизируется.



S>В современном мейнстриме мы имеем либо вавилон из JS+Java+SQL, когда каждую фичу должно делать три разработчика плюс два тестера плюс отдельный менеджер, чтобы следить, чтобы все края совпали, либо JS everywhere с феерически неэффектиывым бэкендом и базой данных.

Про JS я даже говорить не хочу, если честно.
В сравнении с JS обсуждаемый SQL — просто верх человеческой мысли. ))


V>>Просто лично я за такой язык, который допускал бы и статическую компиляцию с максимумом проверок/ограничений/оптимизаций.
V>>Но, если потянуть за эту ниточку — там вытягивается слишком много кардинальный отличий от нынешних мейнстримовых практик.
S>Чтобы штука заработала, надо, чтобы она окучивала целую вертикаль — вот прямо от клиента и до сервера.

От сервера до готовой к линковке транспортной либы для клиента. Причём, типа как из CORBA — бинд на кучу языков.

Блин, да я готов довольно много поставить на то, что в конце всех концов "оно" именно так и будет.
Там и выхода-то другого нет.


S>Иначе — будь любезен, соответствуй общепринятым стандартам.

Стандарты — штука капризная.
Protobuf появился вопреки всем стандартам и стал бешенно популярным, помножив весь IDL на ноль и почти на ноль XML-сообщения.
Это тупая инженерная хрень.
Тупейшая.
Бо отвечает прямо на прямо поставленные инженерные вопросы.
Но так и должно.


S>Я об таком в свободное время фоном думаю, но во-первых, уделяю мало времени, во-вторых, не уверен, что это всё ещё актуально.

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


S>Грубо говоря, непонятно, нужны ли ещё людям те приложения, которые я себе воображаю.

Нужны.


S>TPC-C вышел из моды потому, что уже лет 15 никто не пишет учётные системы.

Пишут конструкторы учётных систем. ))
А еще никто не разворачивает выч. мощности "сам", их теперь арендуют и почти всегда есть доступ к "достаточной" мощности.
Но так-то всё в силе, в любом случае.


S>Нет хороших фреймворков и вообще понимания, что и как должно делаться. Глобально — потому, что люди, выделяющие финансирование, катастрофически некомпетентны. Им показывают прототипы из одной странички, за которыми стоит база из 5 строчек. Когда начинается нормальная нагрузка — то либо проект дохнет (если не успевает принести денег), либо под него нанимаются мега спецы, которые способны собрать кастом билд MySQL и прикрутить статическую оптимизацию к PHP. Людям такого уровня "библиотеки" и "фреймворки" вообще не нужны — они сами могут компилятор сварганить.

Сварганить компилятор не сложно, можно за несколько вечеров на коленке.
А вот оптимизатор — это на той самой грани прогресса современного IT.


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

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

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

Ну и, один из самых популярных способов оптимизации в С++ сегодня — это оптимизация по показаниям профайлера.
Т.е. собрали, запустили профайлер. А затем пересобрали уже с показаниями профайлера.
Для БД это вообще идеальный сценарий, тогда и хинты ручками указыать не надо, они будут расставляться профайлером по-факту.


V>>Почему rsdn тормозит? ))
S>RSDN для своего объёма и железа просто летает. При этом у него внутри как раз MS SQL + linq2db.

ЧТД, "своего железа".
А не дикого кластера.
Отсюда и пляшем.