Парадокс Блаба.

[valexey]

Ну, таки да, сишные макросы они с одной стороны ужасны, с другой стороны до смешного мало могут. Там AST'ом и не пахнет.

На самом деле я склонен рассматривать как аналог лисповых макросов шаблоны в С++. Впрочем, относительно лиспа они также убоги. А в ghc есть расширение под названием TH (Template Haskell) иногда весьма полезно бывает. Ну и в D2 есть механизм позволяющий писать программы работающие на этапе компиляции. Прямо на подмножестве D2 писать. Опять же очень удобно для всяких EDSL, в частности для тех же конечных автоматов.

[Peter Almazov]

А Грейхем про него вообще что-то знает? :-)

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

[valexey]

Ну-у. Хм... Ничто не мешает иметь список состоящий из элементов типа Data.Dynamic, в которых будет уже содержаться все что угодно. Динамическая типизация реализуется посредством статической, но вот обратное не верно.

[igor]

Программы пишут не только программисты. И даже не столько. На своём примере, я - химик.

Не программист, который пишет программы, - таки, программист. (С) 

[Geniepro]

Но Хаскелл -- ленивый язык, в нём такие фокусы проходят.

А кстати, как тут помогает ленивость? Я не вижу проблем сделать то же самое на энергичном языке с замыканиями.

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

[Geniepro]

А Грейхем про него вообще что-то знает? :-)

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

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

Единственно, что для того, что бы поместить в гомогенный список значения разных типов, придётся объявлять дополнительный алгебраический тип данных, объединяющий в себе эти типы. Получается некоторый синтаксический оверхед, который, с другой стороны, можно объявить повышающим наглядность программы, а стало быть, дополнительно повышающий её правильность.

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

В таком случае может быть удобнее объявить класс типов с требуемыми операциями, которые будут проделываться с элементами в этом списке, и объявлять, что в этом списке могут быть значения любых типов данных, входящих в этот класс (экзистенциальные типы в терминах хаскелла).

[Geniepro]

Вообще, Пол Грэм (автор этой статьи) рекомендовал использовать макросы только в том случае, если они сокращают код раз в двадцать. Он признавал, что обильное и неуместное использование макросов способно только запутать и усложнить понимание программы.
Да даже если код благодаря макросам может быть уменьшен всего лишь в 10 раз -- разве это не повод для их использования.
К сожалению, не могу придумать такого примера, где было бы уменьшение кода на порядок. Однако иногда жалею, что в том же C# нет даже простых сишных макросов -- иногда они позволили бы не делать тупой копи-паст.

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

[Peter Almazov]

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

Ну так и приведите пример. Мне, например, не приходилось жалеть.
И, кстати, где эти примеры на Лиспе с уменьшением размера кода в 20 раз?

[valexey]

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

[Geniepro]

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

Ну так и приведите пример. Мне, например, не приходилось жалеть.
И, кстати, где эти примеры на Лиспе с уменьшением размера кода в 20 раз?

Ну вот мой пример:

Код: [Выделить]

if (obj1[i].abracadabra1 != obj2[i].other_abracadabra1)
{
    какие-то действия с obj1[i].abracadabra1:
   
    obj1[i].abracadabra1 = obj2[i].other_abracadabra1;

    какие-то другие действия с obj1[i].abracadabra1:
}

if (obj1[i].abracadabra2 != obj2[i].other_abracadabra2)
{
    какие-то действия с obj1[i].abracadabra2:
   
    obj1[i].abracadabra2 = obj2[i].other_abracadabra2;

    какие-то другие действия с obj1[i].abracadabra2:
}

if (obj1[i].abracadabra3 != obj2[i].other_abracadabra3)
{
    какие-то действия с obj1[i].abracadabra3:
   
    obj1[i].abracadabra3 = obj2[i].other_abracadabra3;

    какие-то другие действия с obj1[i].abracadabra3:
}

if (obj1[i].abracadabra4 != obj2[i].other_abracadabra4)
{
    какие-то действия с obj1[i].abracadabra4:
   
    obj1[i].abracadabra4 = obj2[i].other_abracadabra4;

    какие-то другие действия с obj1[i].abracadabra4:
}

if (obj1[i].abracadabra5 != obj2[i].other_abracadabra5)
{
    какие-то действия с obj1[i].abracadabra5:
   
    obj1[i].abracadabra5 = obj2[i].other_abracadabra5;

    какие-то другие действия с obj1[i].abracadabra5:
}Типы у этих abracadabra1..abracadabra5 -- разные, не совместимые (в смысле нет там наследований всяких).

Были бы макросы (хоть сишные), можно было бы сделать так:

Код: [Выделить]

#define do_what_we_need(obj1,obj2)          \\
    if (obj1 != obj2)                       \\
    {                                       \\
        какие-то действия с obj1:           \\
                                            \\
        obj1 = obj2;                        \\
                                            \\
        какие-то другие действия с obj1;    \\
    }

do_what_we_need(obj1[i].abracadabra1, obj2[i].other_abracadabra1);
do_what_we_need(obj1[i].abracadabra2, obj2[i].other_abracadabra2);
do_what_we_need(obj1[i].abracadabra3, obj2[i].other_abracadabra3);
do_what_we_need(obj1[i].abracadabra4, obj2[i].other_abracadabra4);
do_what_we_need(obj1[i].abracadabra5, obj2[i].other_abracadabra5);
А по поводу 20-кратного уменьшения кода, да ещё и на Лиспе -- это Вы лучше у Пола Грэма спросите, у него наверняка есть таких примеров...

[Peter Almazov]

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

Дженерики в шарпе - это хорошо. Макросы - это гов плохо. Зачем мешать такие вещи?

[valexey]

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

Кстати, а что это мы на макросах зациклились? Они тут вторичны абсолютно. Первичен парадокс Блаба. Впрочем, такое горячее обсуждение макросов является как бы живой иллюстрацией оного парадокса.

[Peter Almazov]

1. - В чем заключается парадокс Блаба?
2. - В парадоксе Блаба.
далее см. пункт 1.

[valexey]

Ну как же? Вполне четкое определение дадено:

Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык.
И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol'а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol'е даже нет некой возможности X, присутствующей в Блабе.

Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе.

Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. "Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!"

Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками

[Peter Almazov]

Это описание "когнитивной слепоты". А парадокс вообще отсутствует.
Мне в статье интересны 2 тезиса:
1. Лисп - самый мощный язык всех времен и народов.
2. Значительная часть его мощности обеспечивается за счет макросов.