to post messages and comments.

А ведь SQL достаточно продуман по сравнению со всякими поделками. Ну например, в нем join-клозы — это не список, а дерево. Что вполне логично, но не сразу очевидно.

Решился-таки потратить время и залезть в NHibernate, чтобы добавить туда некоторые нужные вещи.

Интересная особенность - в NHibernate используется AntLRv3, и создание SQL-запросов проходит через 2 промежуточных представления и 3 парсера/преобразователя деревьев (все 3 написаны на ANTLR).
Деревья:
1) Дерево для HQL. Здесь у нас запросы в терминах классов и их свойств.
2) Дерево для SQL. Здесь у нас запросы в терминах таблиц и колонок.
Парсеры:
1) Парсер из текстового представления HQL-запросов. Здесь нет ничего особенно интересного.
2) Набор правил переписывания для преобразования HQL-дерева в SQL-дерево. Вот здесь скрыта вся соль NHibernate'а.
3) Генератор текстового представления SQL-запросов. Здесь тоже нет ничего интересного.
Парсер/переписыватель дерева в п.2 достаточно грязен - мутирует отдаленные узлы, написан достаточно императивно, содержит эвристики, не всегда работающие. Но ANTLR на такой задаче, конечно, рулит.

Все другие API NHibernate'а работают через генерацию HQL-дерева.

Как мне кажется, использовать HQL AST в качестве внутренного представления (IR, Internal Representation) запросов - не очень хорошая идея. Более хорошим было бы сделать внутренне представление, основанное на реляционной алгебре, в которой узлами были бы классы, таблицы, подзапросы и реляционные операции. В таком виде несложно делать преобразование HQL -> IR, ICriterion -> IR, IQueryable -> IR и IR' -> SQL, где IR' содержит только таблицы и колонки, а не классы и свойства. А преобразование IR -> IR' можно сделать в несколько проходов:
1) Устранить цепочки навигационных свойств
2) Добавить необходимые joined-таблицы и фильтры в качестве подзапросов
3) Преобразовать свойства в колонки
4) Соптимизировать дерево.

Хм, почему так не было сделано?

А есть ли в Казани ИТ-компании, которые занимаются СУБД/компиляторами/ОС, ИИ/машинным обучением, хайлоадом и прочим вебдваноль?

В thinkpad можно ограничить заряд аккумулятора — это продлевает срок его службы.
Рекомендуют ограничить заряд до 50% для максимального срока службы при постоянной работе от сети.
Я вот подумал об этом и теперь хочется, чтобы во всех девайсах с аккумуляторами была такая возможность.

Потратил очень много времени на отладку простейшей задачки из-за неверного распределения для инициализации нейросети. Пока непонятно, как в принципе отлаживать такие вещи, кроме как метода «пристального взгляда».

Попробовал воспользоваться cgroups в линуксе — результат порадовал.
Во-первых, это оказалось совсем несложно — всего в 4 строчки запускаем группу процессов с ограничением по памяти и процессору (чтобы всякие java-монстры не пожирали ресурсы, например):
$ sudo cgcreate -a username -g cpu,memory:groupname
$ cgset -r cpu.shares=512 groupname
$ cgset -r memory.limit_in_bytes=1024M groupname
$ cgexec -g cpu,memory:groupname programname

Во всех описаниях map-reduce меня больше всего возмущает одна простая вещь: названия «map function» и «reduce function» (хотя бы в той же википедии: en.wikipedia.org когда под «map function» имеют в виду функцию, которая применяется с помощью map, а под «reduce function» — функцию, которая применяется с помощью reduce.

Или в очень многих местах путают и смешиавют авторизацию и аутентификацию. Птичий язык просто какой-то.