declarative

[thedeemon]

Периодически встречаю словосочетание "декларативное программирование", которое противопоставляют императивному, сопровождая формулой "описывается, что должно быть получено, а не как оно должно быть получено". Известный пример декларативного языка - SQL. Еще к декларативщине частенько относят хаскель и другие ФЯ, но вот с ними проблема: сколько кода я на них видел, (практически) везде было явное описание процесса вычисления, т.е. код был все же императивным по сути (создать список такой-то, свернуть его так-то, построить дерево такое-то и т.д. - это все про "как"). Вопрос к залу: покажите максимально декларативное решение (на любом языке, в том числе еще не существующем и чисто гипотетическом) следующей задачи.

Есть последовательность байтов (фиксированный массив/список или потенциально бесконечный поток - на ваш выбор), нужно их сжать RLE методом по мотивам формата PCX: в выходном потоке байт Х <= 192 обозначает сам себя, а байт Х > 192 означает Х-192 повторений следующего за ним байта. Т.е. последовательность
1, 1, 2, 3, 2, 2, 2, 200, 0, 200, 200, 200, 200
должна превращаться в
194, 1, 2, 3, 195, 2, 193, 200, 0, 196, 200

Comments

[thedeemon.livejournal.com]

Ну, всякие курсоры, триггеры и хранимки - это уже императивщина, да. Но база SQL, реляционная алгебра, все же декларативна, имхо.

[alll]

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

[109.livejournal.com]

+1
law of leaking abstractions