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

[metaclass]

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

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

Comments

[volodymir-k.livejournal.com]

И Вас с пятницей!
Извините за неразбрчивй пчрк.

[nivanych.livejournal.com]

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

[freiksenet.livejournal.com]

Ну напрямую и я им не пользуюсь, хотя пишу на Common Lisp %)

[metaclass.livejournal.com]

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

[freiksenet.livejournal.com]

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

[mudasobwa.livejournal.com]

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

Грамотный программист еще должен быть грамотным, тогда уж, и уметь написать слово «исчисление» без пары ошибок.

На самом деле, грамотный программист на КОБОЛе (если не ошибаюсь, самая высокооплачиваемая на сегодняшний день профессия в мире IT), должен понимать совсем иное. А когда придет лямбда и всех порешит — грамотный программист должен будет знать другое.

Вы путаете «интересующегося студента» и «специалиста в узкой области». Если разработчики СУБД начнут тратить время на мю- и пи- мезоны — у нас с вами будут не базы данных, а конструкторы ЛЕГО.

[freiksenet.livejournal.com]

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

Грамотный кодер на любом языке вполне может знать этот единственный язык. Грамотный программист будет знать и много языков, и математику, и theoretical computer science. Кодер будет всю жизнь писать опердень. Программист будет писать интересные проекты на любимых языках.

[mudasobwa.livejournal.com]

Я почти 40 лет живу в родной стране, и считаю, что мне непозволительно делать ошибки в тех трех языках, которым я обучился. Ну да ладно. Каждому — свое.

Зачем знать много языков человеку, которому интересна оптимизация БД? Зачем человек, которому не интересна оптимизация БД — владельцу БД?

[mudasobwa.livejournal.com]

Скажите, вы и правда полагаете, что удобство разработчика важнее скорости выполнения?

Или вы просто не понимаете, что означает «узкая специализация»?

[gds.livejournal.com]

если уже есть именованные функции, то не всё ли равно, будут ли ещё вдобавок нормальные анонимные функции, в том числе рекурсивные?

[mudasobwa.livejournal.com]

Вы на ассемблере программировали когда-нибудь?

[metaclass.livejournal.com]

Важнее всего практическое применение, а уж в этом Firebird упрекнуть не в чем :)
А вот после этого важна теоретическая правильность, потому что она позволяет поддерживать софт в живом состоянии и развивать его без особого напряга, особенно софт системного уровня типа СУБД.
Ну и новомодные штучки помогают поддерживать интерес в публике.

[gds.livejournal.com]

к сожалению, слишком много и слишком рано. Если намёк на direct vs indirect call -- не думаю, что субедешечька как-либо считает адреса функций; и наоборот, имея структурку, содержащую тело функции, выполнить функцию легче, чем имея имя, которое ещё надо "отрезолвить" в тело.

Так более того, простые анонимные функции фраербёрд умеет! То есть, вся "машинерия", отвечающая за отделение тела от имени, уже готова.

Впрочем, не понимаю, зачем вообще вопрос поднялся -- fixed point combinator нельзя изобразить, вероятно?

[theiced.livejournal.com]

даже на си можно лямбды сделать... ну почти ;)

[theiced.livejournal.com]

подтверждаю - стэктрейсы в лиспах охуенны.

[theiced.livejournal.com]

традиции юникс программирования последних десятков лет - это - внезапно - гну в основном. емаксы там и прочие гайлы.

[vp.livejournal.com]

Потому что все хорошо в меру :)

[berezovsky.livejournal.com]

пол макккартни

[thedeemon.livejournal.com]

Давайте напишем на нем БД!

[nivanych.livejournal.com]

Это будет темой следующего ICFP ;-)

[migmit.livejournal.com]

Я по работе пишу на плюсах, но отладкой почти не пользуюсь. Честно. Логи пока выручают практически полностью.

[metaclass.livejournal.com]

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

[migmit.livejournal.com]

Я довольно долго писал под приставки, так что уже привык. На приставках а) невозможно собирать всё в дебаг-версии, оно просто не влезет в память, и приходится собирать релиз, снимая оптимизацию с некоторых файлов; б) если пишешь под, например, SPU на PS3, то там вообще с чего бы то ни было снимать оптимизацию – значит нарываться. С логами тоже всё плохо, но это хотя бы можно как-то обходить – писать в переменные, DMA-шить на основной процессор и т.п.

[permea-kra.livejournal.com]

По-моему, этой проблемы до сих пор не решили,

[permea-kra.livejournal.com]

Да, от этого лиспового позора сложно отмыться.