Лямбды и Firebird, ад продолжается

[metaclass]

А теперь, внимание, бородатая женщина будет есть червей мнение разработчика Firebird о лямбда-функциях:

Отвратительная возможность, провоцирующая написание нечитаемого
и несопровождаемого спагетти-кода, созданная на пустом месте чисто в
маркетинговых целях.
Вот такое моё частное мнение о лямбда-функциях.

Comments

[nivanych.livejournal.com]

Какой именно проблемы?
Язык высокого уровня с удобной работой с низкоуровневым?
Ну, теоретически, решили. Практически, пока не очень.
Запихивать элементы функциональных языков в низкоуровневые?
Ну, если говорить о "проблеме", то решили.
Но вот, имплементаций нормальных нет.

[permea-kra.livejournal.com]

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

[blackyblack.livejournal.com]

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

[fraks-nsk.livejournal.com]

Вы клинический идиот если считаете что метакласс, вдруг бросится переписывать уже написанные и внедренные программы на сервер "X" из-за того что какому-то идиоту не понравился разработчик сервера "Y".

[metaclass.livejournal.com]

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

[osdm.livejournal.com]

Эх, а ведь именно в SQL лямбды были бы наиболее полезны как средство передачи дополнительных условий фильтрации в функции/SQL-запросы. Потому что динамический SQL - это конечно круто, но статика с лямбдами была бы намного удобнее.

[metaclass.livejournal.com]

Вот именно.

[volodymir-k.livejournal.com]

Настоящие индейцы передают строки с условиями, их сервер конкатенирует и execute immediate. Медленно? Если вы думаете, что в чём-то можно сильно сэкономить на парсинге AST и анализе планов, то сильно ошибаетесь -- дисковая операция в 1000 раз медленнее самого навороченного парсинга с планированием.

[osdm.livejournal.com]

Дело столько не в том, что медленно, сколько в том, что неудобно. Конструкции получаются громоздкими (удвоение кавычек, переносы строк и прочая фигня). Переменные не в фильтре приходится явно биндить, а переменные в фильтре переводить в строку, рискуя получить injection vulnerability. Ошибки выявляются в runtime, а не в процессе компиляции и т.п.

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

[volodymir-k.livejournal.com]

> Переменные не в фильтре приходится явно биндить, а переменные в фильтре переводить в строку, рискуя получить injection vulnerability.

По-моему это невалидный аргумент, уже лет 20 как передаётся строка и массив объектов в любое API.

> Конструкции получаются громоздкими (удвоение кавычек, переносы строк и прочая фигня).

Да, во многих языках нету литералов, и некрасивенько.

> когда его приходится вызывать сотню тысяч раз за расчет... и на парсинге тоже стоит поэкономить

Как правило такое вычисление экономят на клиенте и не пересекают 10 слоев, а БД обычно делается сетевое с 50 мс задержкой.

А кто делает расчёты на T/PL-SQL на сервере...тот ценитель извращений.


А знаете, какая самая проблема передать лямбду? потому что будет хотеться передать с контекстом, и непредсказуемой сложности вычисление. А ведь одно дело -- условие where a < b и другое where factorial(x) < 12345678. То есть лямбду в общем случае не оптимизируешь, как условие.