Простой код — изящный и понятный код. Он работает предсказуемым образом, в нём легко выявить ошибки ещё на стадии написания. Наконец, он просто красив! Какой программист не стремится к простому коду? Когда мы представляем себе идеальный код — мы обычно имеем в виду именно простой, красивый исходный код! Но почему мы пишем нечто совсем другое?

Уравнение прямой — что может быть проще?

Ах + Ву + С = 0

Формула существует в мире идеальном. Но попробуем нарисовать отрезок прямой в грубой действительности — на растровом мониторе. Мы можем, конечно, выразить y через x и, увеличивая на 1 x, рассчитывать y. (Или x от y, для вертикальных отрезков). Потом ставить пиксель в координаты (x, y). Простой алгоритм. Только, никто так не делает. Медленно, неэффективно. Вы наверняка слышали об алгоритме Брезенхэма, который используется в таких случаях. К примеру, реализация рисования отрезка в INSTEAD (на C), выглядит так:

static __inline void line0(struct lua_pixels *hdr, int x1, int y1, int dx, int dy, int xd, unsigned char *col)
{
    int dy2 = dy * 2;
    int dyx2 = dy2 - dx * 2;
    int err = dy2 - dx;
    unsigned char *ptr = NULL;
    int w = hdr->w; int h = hdr->h;    int ly = w * 4;
    int lx = xd * 4;    while ((x1 < 0 || y1 < 0 || x1 >= w) && dx --) {
        if (err >= 0) {
            y1 ++;
            err += dyx2;
        } else {
            err += dy2;
        }
        x1 += xd;
    }
    if (dx < 0)
        return;
    ptr = (unsigned char*)(hdr + 1);
    ptr += (y1 * w + x1) << 2;    pixel(col, ptr);
    while (dx --) {
        if (err >= 0) {
            y1 ++;
            if (y1 >= h)
                break;
            ptr += ly;
            err += dyx2;
        } else {
            err += dy2;
        }
        x1 += xd;
        if (x1 >= w || x1 < 0)
            break;
        ptr += lx;
        pixel(col, ptr);
    }
    return;
}

static __inline void line1(struct lua_pixels *hdr, int x1, int y1, int dx, int dy, int xd, unsigned char *col)
{
    int dx2 = dx * 2;
    int dxy2 = dx2 - dy * 2;
    int err = dx2 - dy;
    int w = hdr->w; int h = hdr->h;
    unsigned char *ptr = NULL;
    int ly = w * 4;
    int lx = xd * 4;    while ((x1 < 0 || y1 < 0 || x1 >= w) && dy --) {
        if (err >= 0) {
                x1 += xd;
            err += dxy2;
        } else {
            err += dx2;
        }
        y1 ++;
    }
    if (dy < 0)
        return;    ptr = (unsigned char*)(hdr + 1);
    ptr += (y1 * w + x1) << 2;    pixel(col, ptr);    while (dy --) {
        if (err >= 0) {
            x1 += xd;
            if (x1 < 0 || x1 >= w)
                break;
            ptr += lx;
            err += dxy2;
        } else {
            err += dx2;
        }
        y1 ++;
        if (y1 >= h)
            break;
        ptr += ly;
        pixel(col, ptr);
    }
    return;
}

static void line(struct lua_pixels *src, 
int x1, int y1, int x2, int y2, 
int r, int g, int b, int a)
{
    int dx, dy, tmp;
    unsigned char col[4];
    if (y1 > y2) {
        tmp = y1; y1 = y2; y2 = tmp;
        tmp = x1; x1 = x2; x2 = tmp;
    }
    col[0] = r; col[1] = g; col[2] = b; col[3] = a;
    if (y1 >= src->h)
        return;
    if (y2 < 0)
        return;
    if (x1 < x2) {
        if (x2 < 0)
            return;
        if (x1 >= src->w)
            return;
    } else {
        if (x1 < 0)
            return;
        if (x2 >= src->w)
            return;
    }
    dx = x2 - x1;
    dy = y2 - y1;
    if (dx > 0) {
        if (dx > dy) {
            line0(src, x1, y1, dx, dy, 1, col);
        } else {
            line1(src, x1, y1, dx, dy, 1, col);
        }
    } else {
        dx = -dx;
        if (dx > dy) {
            line0(src, x1, y1, dx, dy, -1, col);
        } else {
            line1(src, x1, y1, dx, dy, -1, col);
        }
    }
    src->dirty = 1;
}

И это — весрия без анти-альясинга… Согласитесь, понять из алгоритма, что именно он делает, не так-то просто…

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

Я очень люблю OpenBSD за её простоту. Если сравнивать с современным Linux — это небо и земля! Но я понимаю, что за простоту пришлось заплатить… эффективностью. Ядро Linux очень сложное! Очень хитрые способы синхронизации (взять хотя бы rcu) разросшийся код системных вызовов… Даже если сравнивать один и тот же код разных версий — разница будет видна невооружённым глазом. Например, код из версии ядра 3.16:

void __napi_complete(struct napi_struct *n)
{
    BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
    BUG_ON(n->gro_list);
    list_del(&n->poll_list);
    smp_mb__before_atomic();
    clear_bit(NAPI_STATE_SCHED, &n->state);
}
void napi_complete(struct napi_struct *n)
{
    unsigned long flags;`    /*
     * don't let napi dequeue from the cpu poll list
     * just in case its running on a different cpu
     */
    if (unlikely(test_bit(NAPI_STATE_NPSVC, &n->state)))
        return;`    napi_gro_flush(n, false);
    local_irq_save(flags);
    __napi_complete(n);
    local_irq_restore(flags);
}

А вот аналогичный код, но уже из 4.18

bool napi_complete_done(struct napi_struct *n, int work_done)
{
    unsigned long flags, val, new;    /*
     * 1) Don't let napi dequeue from the cpu poll list
     *    just in case its running on a different cpu.
     * 2) If we are busy polling, do nothing here, we have
     *    the guarantee we will be called later.
     */
    if (unlikely(n->state & (NAPIF_STATE_NPSVC |
                 NAPIF_STATE_IN_BUSY_POLL)))
        return false;    if (n->gro_list) {
        unsigned long timeout = 0;        if (work_done)
            timeout = n->dev->gro_flush_timeout;        if (timeout)
            hrtimer_start(&n->timer, ns_to_ktime(timeout),
                      HRTIMER_MODE_REL_PINNED);
        else
            napi_gro_flush(n, false);
    }
    if (unlikely(!list_empty(&n->poll_list))) {
        /* If n->poll_list is not empty, we need to mask irqs */
        local_irq_save(flags);
        list_del_init(&n->poll_list);
        local_irq_restore(flags);
    }    do {
        val = READ_ONCE(n->state);        WARN_ON_ONCE(!(val & NAPIF_STATE_SCHED));        new = val & ~(NAPIF_STATE_MISSED | NAPIF_STATE_SCHED);        /* If STATE_MISSED was set, leave STATE_SCHED set,
         * because we will call napi->poll() one more time.
         * This C code was suggested by Alexander Duyck to help gcc.
         */
        new |= (val & NAPIF_STATE_MISSED) / NAPIF_STATE_MISSED *
                            NAPIF_STATE_SCHED;
    } while (cmpxchg(&n->state, val, new) != val);    if (unlikely(val & NAPIF_STATE_MISSED)) {
        __napi_schedule(n);
        return false;
    }    return true;
}
EXPORT_SYMBOL(napi_complete_done);

Кроме очевидного увеличения объёма кода тут присутствует любопытный фрагмент. Обратите внимание на конструкцию:

new |= (val & NAPIF_STATE_MISSED) / NAPIF_STATE_MISSED * NAPIF_STATE_SCHED;

Попробуйте самостоятельно понять, что она значит. Это яркий пример встречи мира идеального и мира материального. К счастью, над этой строчкой присутствует комментарий, который описывает назначение кода.

Сложность кода растёт, простота теряется… Нельзя назвать ядро Linux примером плохого кода, но и красивым этот код можно назвать лишь с натяжкой.

К сожалению, мир в котором мы живём — это мир компромиссов.

Мы можем следовать одному из принципов:

- Linux — стихийная хакерская разработка;
- OpenBSD — принцип простоты в абсолюте;
- Проект https://suckless.org/ — принцип простоты до абсурда.

А можем пытаться выбрать что-то среднее. Но только ведь мы мечтаем об идеальном коде! А идеалы не терпят компромиссов. Так что в качестве отдушины, я пользуюсь на ноутбуке OpenBSD. А в INSTEAD я стараюсь придерживаться серединного пути. Но все-таки, все-таки все идеи приходят из мира идеального. Так что, даже в ядре Linux мы можем увидеть отголоски кода нашей мечты. :)

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

Это не чтобы вызвать флейм, а чтобы поделиться разными мнениями.

vvs> Кстати, вот вопрос ко всем и к Петру в первую очередь. А как вы определяете простоту? Почему если все надо писать на низком уровне, то это обязательно просто? Прост ли ассемблер? А может если система все за вас решает, то это проще? Например Пролог?

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

Мне лично больше нравится первое. Потому что простым вещам сложнее ломаться и их проще починить. А ещё я не плачу за блестящие хреновины, которые больше мешают, чем помогают. Что не мешает, впрочем, мне любить пайтон и лисп, например :)

Сложное, это не просто сумма простых частей. А простое, это не значит низкоуровневое.

Понятно, что сама мера, зависит от ситуации и личности. Например, INSTEAD не так прост, как мне хотелось бы, потому что я писал его для других людей в том числе. Но в то же самое время, я сейчас пишу игру в Plan9 на консольной версии метапарсера, прямо в редакторе ACME запуская его. И мне это по душе.

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

Например, я не готов набирать тексты в редакторе ed, хотя он ещё проще. :) Но я спокойно могу пожертвовать подсветкой синтаксиса. Или современным вебом.

Ещё пример. Средство синхронизации rcu в ядре. Какой прирост они обеспечивают? Стоит ли жертвовать скоростью ради более простого кода? Это выбор, который определяется задачей.

А ещё, кроме простоты есть эффективность решений. Красивое решение, это максимум простоты при максимуме эффективности.

Формула: красота = эффективность/сложность.

Например, ACME редактор прост, но для своей простоты он удивительно эффективен. emacs - может больше. Но сложность emacs несоизмеримо больше.

Ещё пример. latex vs troff. Разница - огромна. Функции -- близки.

Так что, на мой взгляд, простота и аскетика, способность отказаться от "блажи", поиск красивых решений -- всегда идут рядом с приципом KISS.

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

А есть еще другой тип программистов, которые любят что-нибудь вычурное, например Brainfuck. Он еще проще ассемблера, но понять программы на нем без поллитра не получается.

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

vvs> Тут чувствуется одно противоречие. Программист - он еще и пользователь, зачастую очень ленивый.

А в чём противоречие? Во первых, не все эти программисты пробовали разные подходы. Почему не пробовали, это отдельный вопрос. Во-вторых, очень многое решает привычка. Мне лично очень нравится ломать свои привычки. Изучать новое. Поэтому я перепробовал много ОС и много разных подходов. Лично мой опыт -- большинство прибамбасов это просто свистелки, навязанные маркетингом. Я совершенно спокойно программирую без автодополнения кода. Если оно есть - могу с ним. Я не вижу вообще, что это как то критично.

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

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

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

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

Я тут подумал, что есть ещё одна аналогия.

Учась в школе/институте, я часто встречался с ситуацией, когда проще не заучивать формулу, а выводить её, если она понадобится. Это не значит, что ты всегда её выводишь, ведь если она тебе нужна часто, то ты естественным образом запомнишь её. Но тут важен подход -- если ты понимаешь базовые принципы и систему вообще -- остальное есть следствие. Конечно, бывают такие вещи, которые нереально сложно и долго выводить самому.

В KISS, грубо говоря, зная как работают кирпичики, ты строишь свои знания/навыки естественным способом. В сложном графическом приложении - ты должен запомнить все элементы и способы работы с ними. Но вот, меняется приложение -- и всё начинается заново...

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

vvs>> Тут чувствуется одно противоречие. Программист - он еще и пользователь, зачастую очень ленивый.

hugeping> А в чём противоречие?

Это конкретно было адресовано Андрею на черно-белую дихотомию инженеров и пользователей.

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

hugeping> Сейчас идёт сравнение с ассемблером? Я лично тоже доверяю компилятору. На ассемблере я давно не пишу (хотя сталкиваюсь с ним при отладке). Си -- один из примеров, когда коэффициент красоты (эффективность/сложность) -- очень хороший. Он и создавался как переносимый ассемблер.

Нет. Вот конкретный пример:

def fact x :=
  match x with
  | 0   => 1
  | n+1 => (n+1) * fact n

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

Я хотел сказать, что тот код, что мы видим - это вовсе не тот код, который видит компьютер, а посредником выступает компилятор.
P.S. Edited: 2020-12-05 18:06:18

vvs> Это просто? Вроде да. Но это только синтаксический сахар.

Ну, ФП это кмк не только синтаксический сахар. Думаю, это тоже простота. Я, кстати, пытался читать книжку по Haskell несколько раз и кажется, начал что-то понимать. :) В каком-то смысле там тоже простота - все эти ленивые вычисления и чистые функции. :) Но применить мне это не где, потому что проще всё-таки писать императивно. Тоже привычка.

hugeping> То-есть в простом подходе, не плодятся сложные уникальные сущности, но по разному комбинируются простые. Это и есть Unix подход. Только Linux уходит от него всё дальше... Понятно, что когда мы говорим о такой задаче, как обработка/редактирование видео, например, Unix подход может превратиться в ту самую "сложную" формулу. Так что, очевидно, простота работает не везде. Но можно к ней хотя бы стремиться.

Тут фишка в том, что это зависит не от линукса, а от нашего собственного ограниченного понимания проблемы. Что такое топологическое пространство? Специалисту это просто, а остальным - это новая непонятная сущность :)

hugeping> Уравнение прямой — что может быть проще?

hugeping> Ах + Ву + С = 0

Кстати, это хорошая аналогия. Здесь записана формулировка задачи, а не ее решение. Если записать здесь какое-нибудь другое уравнение, например ОТО, то оно будет выглядеть обманчиво просто. А вот его решение может оказаться никому не по зубам. Вот поэтому я и предпочитаю полагаться на компилятор.

vvs>>> Тут чувствуется одно противоречие. Программист - он еще и пользователь, зачастую очень ленивый.
hugeping>> А в чём противоречие?
vvs> Это конкретно было адресовано Андрею на черно-белую дихотомию инженеров и пользователей.

Я взял полярные случаи для наглядности. И делил вещи, а не людей. Ты что-то понял не так.

vvs>>> Лично мне больше нравится, когда решение моей задачи я доверяю компилятору.
hugeping>> Сейчас идёт сравнение с ассемблером? Я лично тоже доверяю компилятору. На ассемблере я давно не пишу (хотя сталкиваюсь с ним при отладке). Си -- один из примеров, когда коэффициент красоты (эффективность/сложность) -- очень хороший. Он и создавался как переносимый ассемблер.
vvs> Нет. Вот конкретный пример:
vvs>
vvs> ```
vvs> def fact x :=
vvs> match x with
vvs> | 0 => 1
vvs> | n+1 => (n+1) * fact n
vvs> ```

Код здесь обрамляется ====.

vvs> Это просто? Вроде да. Но это только синтаксический сахар. После развертывания в абстрактный синтаксис это выглядит далеко не просто. Кроме того компилятор генерирует вспомогательный код, который нужен ему, но мне не обязательно понятен. Разве что если я увлекаюсь теорией формальных языков.

Это нифига не просто. Но для пользователя синтаксический сахар как раз и проще.

AL> Я взял полярные случаи для наглядности. И делил вещи, а не людей. Ты что-то понял не так.

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

P.S. Кстати, подобная идеализация свойственна последователям Платона. Я к ним не отношусь, если что.
P.S. Edited: 2020-12-06 12:34:03

AL>> Я взял полярные случаи для наглядности. И делил вещи, а не людей. Ты что-то понял не так.
vvs> Я с большим недоверием отношусь к искусственным идеализациям. В жизни они часто не имеют смысла. Мы тут на эту тему уже не раз копья сломали. Оторвать инженерные критерии от инженеров вряд ли получится, поскольку они не существуют сами по себе в вакууме. Конечно, имеет смысл думать что инженеры стремятся к какому-то идеалу, но как показывает эта же самая дискуссия - он у всех разный.
vvs> P.S. Кстати, подобная идеализация свойственна последователям Платона. Я к ним не отношусь, если что.

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

Хм. На этот раз я вынужден сказать, что ты меня как-то не так понял. А где именно я сказал, что твоя точка зрения - это плохо? Я лишь просто уточнил, что мне такое деление кажется искусственным. Твою точку зрения я прекрасно понял, просто для того, чтобы лично мне узнать, что есть технически простое решение, придется идти к тебе за ответом. Я сам не могу с уверенностью это определить. Вот даже на приведенный мной раньше фрагмент кода вы с Петром дали противоположные ответы. Так кто будет в этом конкретном случае арбитром? Я не против если это будешь именно ты, но это как-то слишком произвольно на мой взгляд, разве нет? :)
P.S. Edited: 2020-12-06 14:21:51

vvs> Хм. На этот раз я вынужден сказать, что ты меня как-то не так понял. А где именно я сказал, что твоя точка зрения - это плохо? Я лишь просто уточнил, что мне такое деление кажется искусственным. Твою точку зрения я прекрасно понял, просто для того, чтобы лично мне узнать, что есть технически простое решение, придется идти к тебе за ответом. Я сам не могу с уверенностью это определить. Вот даже на приведенный мной раньше фрагмент кода вы с Петром дали противоположные ответы. Так кто будет в этом конкретном случае арбитром? Я не против если это будешь именно ты, но это как-то слишком произвольно на мой взгляд, разве нет? :)

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

Хорошо. Чтобы еще больше всех тут запутать я скажу, что для формального описания поведения вышеупомянутого кода годится лямбда-исчисление, а для императивного кода, даже на языке ассемблера (или C), нужна уже логика разделения, которая ну никак не кажется проще. Следствием является то, что доказать правильность работы ФП в целом проще, чем императивного кода. Что означает, что добиться надежности в первом случае тоже легче.

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

Я уже сказал в самом начале, что не собираюсь поднимать флейм. Моя личная точка зрения по этому поводу, что говоря о "простоте" люди обычно сравнивают теплое с мягким и большого смысла такое сравнение не имеет.

Я тоже немного запутаю.

Когда говорили про Plan9, true-grue прислал мне один свой комментарий, который, на мой взгляд, в тему разговора. Особенно там, где про чувства к инструменту.

http://fforum.winglion.ru/viewtopic.php?p=40887&sid=b952e062260f48b8f6b6b45f8e76b3d0#p40887


Далее цитата.

Форт-метод -- метод создания инструментария для решения задач. Каковы же его отличительные стороны? Ориентированность на личность, на кустаря-одиночку, независимого от чужого инструментария. Использующему форт-метод разработчику требуются большие опыт и знания. Ведь он, подобно Родену, изучив "глыбу мрамора" знаний и технологий, отсекает от нее все лишнее для себя, путем тщательного отбора из большого числа возможностей. Аналогия с искусством тут неслучайна, ведь автор не просто создает полезный инструмент, а такой, которому он будет испытывать чувства. Отсюда стремление к элегантности, красоте конструкций, миниатюризации. Его инструмент -- средство индивидуального пользования для решения собственных задач. Поддержка в рабочем состоянии, независимость от чужих технологий -- все это накладывает отпечаток на структуру инструмента. Отсюда требования к простоте и регулярности конструкции. Минимализм и единообразие часто приводят к тому, что одни и те же элементы такого инструментария используются нетривиальным образом для различных целей. Это требует определенного мастерства в освоении, в духе процесса бритья топором или использования надфиля в качестве пилки для ногтей. В целом, форт-метод добавляет к результату яркий отпечаток индивидуальности создателя.

Что ж, это интересный пассаж, добавляющий еще одно измерение. Действительно, речь идет об искусстве или о производстве? Искусство дает уникальное творение, а производство массовые копии. Простота производства, безусловно, должна отличаться от простоты искусства. С моим мнением это тоже вполне согласуется.

Кстати, я сообразил, что мы еще не доказали, что простота - это свойство. А по-моему - это отношение. Каждый относится к предмету по-разному и видит в нем свою простоту или сложность.

Тут хорошо подойдет известная аналогия: когда именно несколько песчинок превратятся в кучу песка? Где именно граница между простым и сложным? Разве это не указывает на наше индивидуальное отношение?

AL> Код, который ты приводил, как раз ярко иллюстрирует мою идею. Компилятор сложная технически штука. Очень сложная. Зато она позволяет вот так просто для пользователя писать код.

Просто для поддержания светской беседы, не относитесь к этому вопросу слишком серьезно. Компилятор с языка, на котором написан этот код, имеет меньше ста тысяч строк кода вместе с комментариями. Напомните мне, пожалуйста, какой размер кода имеют gcc или go? Последний раз когда я смотрел, число строк кода go приближалось уже к миллиону. Да, я знаю, что это сравнение не вполне корректное, но все же. :)

vvs> Хорошо. Чтобы еще больше всех тут запутать я скажу, что для формального описания поведения вышеупомянутого кода годится лямбда-исчисление, а для императивного кода, даже на языке ассемблера (или C), нужна уже логика разделения, которая ну никак не кажется проще. Следствием является то, что доказать правильность работы ФП в целом проще, чем императивного кода. Что означает, что добиться надежности в первом случае тоже легче.

Всё так.

vvs> Другим следствием будет то, что понять логику работы компилятора неспециалисту, конечно, сложнее, чем программы на языке ассемблера. При том, что существуют формально проверенные компиляторы, где корректность их реализации формально гарантирована. Весь вопрос в том, какая же именно простота тут "истинная"?

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

vvs> Я уже сказал в самом начале, что не собираюсь поднимать флейм. Моя личная точка зрения по этому поводу, что говоря о "простоте" люди обычно сравнивают теплое с мягким и большого смысла такое сравнение не имеет.

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

vvs> Что ж, это интересный пассаж, добавляющий еще одно измерение. Действительно, речь идет об искусстве или о производстве? Искусство дает уникальное творение, а производство массовые копии. Простота производства, безусловно, должна отличаться от простоты искусства. С моим мнением это тоже вполне согласуется.

Если говорить о продукте, то надо делать быстро и чтобы пользователю было как можно проще. Для пользователя действие должно быть операцией одной кнопки.

vvs> Кстати, я сообразил, что мы еще не доказали, что простота - это свойство. А по-моему - это отношение. Каждый относится к предмету по-разному и видит в нем свою простоту или сложность.

О чём я и говорил изначально :)

vvs> Тут хорошо подойдет известная аналогия: когда именно несколько песчинок превратятся в кучу песка? Где именно граница между простым и сложным? Разве это не указывает на наше индивидуальное отношение?

Сумма простых вещей может быть и сложной. Но сумма сложных вещей сложнее :)

AL>> Код, который ты приводил, как раз ярко иллюстрирует мою идею. Компилятор сложная технически штука. Очень сложная. Зато она позволяет вот так просто для пользователя писать код.
vvs> Просто для поддержания светской беседы, не относитесь к этому вопросу слишком серьезно. Компилятор с языка, на котором написан этот код, имеет меньше ста тысяч строк кода вместе с комментариями. Напомните мне, пожалуйста, какой размер кода имеют gcc или go? Последний раз когда я смотрел, число строк кода go приближалось уже к миллиону. Да, я знаю, что это сравнение не вполне корректное, но все же. :)

Да. Эти компиляторы очень сложные с инженерной точки зрения. И как и везде это имеет две стороны: они позволяют достаточно простые вещи, но они достаточно сложны.

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

hugeping> Сложность это не просто размер кода, это _комплексность_. Например, сложность ядра Linux высока не столько из-за размера, сколько из-за сложного взаимодействия компонентов. Так что компилятор компилятору -- рознь.

Комплексность сложно оценить, в отличие от размера. Я вот понятия не имею, что сложнее устроено: солнечная система или электрон?

hugeping> Я не специалист в ФП, но мне кажется идеи, которые реализует тот же Haskell сами по себе просты. Но, не буду лезть в область, в которой я нуб.

hugeping> В качестве элегантных (и при этом мощных) вещей можно привести: Форт, Лисп.

Я там вижу две составляющие: логика и эстетика. Опять же, первую оценить относительно просто, в отличие от второй.

P.S. Да, там еще есть изощренность практических алгоритмов, которую тоже оценить трудно.

P.S. Edited: 2020-12-07 12:46:25

hugeping> В качестве элегантных (и при этом мощных) вещей можно привести: Форт, Лисп.

К Лиспу у меня двойственное отношение. С одной стороны синтаксис и примитивы языка экстремально просты. С другой стороны это привело к тому, что многие конструкции языка превратились во внешние функции, а языка, как единого целого не существует вовсе. Есть бесчисленное множество диалектов для конкретных приложений и когда упоминают Лисп, то, зачастую, имеют в виду какую-то абстрактную идею. Для меня основным здесь кажется то, что влияние Лиспа можно найти всюду, в самых неожиданных местах, но мне самому писать на нем не хочется. В его коде я не ощущаю индивидуальности, хотя он и очень узнаваем. Кстати, в свое время мне пришлось изучать PL/I и там было такое же ощущение какой-то безликости.

vvs> Комплексность сложно оценить, в отличие от размера. Я вот понятия не имею, что сложнее устроено: солнечная система или электрон?

Ну мы же говорили о том, что человек создал. Скажем, сравнительно оценить сложность: ядра Linux, OpenBSD, FreeBSD, HaikuOS и Plan9 вполне себе сравнивается. :)

vvs> Я там вижу две составляющие: логика и эстетика. Опять же, первую оценить относительно просто, в отличие от второй.

Оценить - несложно. Формально доказать - сложно. Но у кого стоит такая цель? У меня - нет такой. :)

vvs>> Комплексность сложно оценить, в отличие от размера. Я вот понятия не имею, что сложнее устроено: солнечная система или электрон?

hugeping> Ну мы же говорили о том, что человек создал. Скажем, сравнительно оценить сложность: ядра Linux, OpenBSD, FreeBSD, HaikuOS и Plan9 вполне себе сравнивается. :)

Не думаю. Как сравнивать, например, маленький, но очень хитроумный алгоритм, использующий глубокие теоретические результаты и огромный, запутанный алгоритм, с большим числом вариантов? Если я понимаю теорию, то я могу сказать, что первый прост, но совсем не тривиален, а второй сложен для понимания, но тривиален по сути. Сразу начнется спор: а что здесь есть комплексность? Честно говоря, мне неохота начинать все по новой.

Другой пример. Одна ОС реализует аппаратную защиту памяти, а другая полагается для этого на компилятор, как Singularity.

Да нет, видно там всё по коду.

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

P.S. Я не спорю. Просто делюсь своими наблюдениями. Ты можешь считать их ошибочными, я не против.

vvs> Другой пример. Одна ОС реализует аппаратную защиту памяти, а другая полагается для этого на компилятор, как Singularity.

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

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

Так же, есть вещи, которые изменить нельзя. Например, сложная система команд целевого процессора. Ну, взять тот же vliw.

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

hugeping> Это уже не сложность, по-моему, а разный подход к решению проблемы. То-есть, сказать только по вот этой-вот части - нельзя ничего.

А как отделить очень разное концептуальное устройство от оценки сложности. Все равно, что оценивать костюм по пуговицам, как у Райкина.

hugeping> Про Singularity я, к сожалению, ничего не знаю. Очевидно, в этой ОС проблема выполнения недоверенного (нативного) кода как-то решается. Или там вообще нет такого понятия и всё проходит через их язык. Но, тоже решение. Может быть, и нормально. Хоть и не традиционно.

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

hugeping> Так же, есть вещи, которые изменить нельзя. Например, сложная система команд целевого процессора. Ну, взять тот же vliw.

Все еще сложнее. Как сравнивать арифметику натуральных чисел и анализ комплексных функций? Они связаны, но слишком разные. Если процессор не реализует вычисления с плавающей точкой, то это неизбежно сказывается на всем ПО. И как сравнивать ОС для разных архитектур? Можно только специально подобрать для сравнения очень похожие примеры, но это очень частный случай и поэтому не интересно.

hugeping> Но всё-равно, сложные решения чаще становятся непредсказуемыми. Уязвимости в интел процессорах сейчас все бросились искать. Ну, в том числе, потому что срезали углы. Старались оптимизировать всё. Вопрос цены. Но мне часто кажется, что задача выжать скорость любой ценой, в том числе и за счёт сильных ухищрений, это скорее следствие конкуренции... :)

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

vvs> Инженерное решение - это всегда компромисс между желанием и имеющимися ресурсами. Наука и искусство этим напрямую не связаны, хотя, например, физика косвенно зависит от инженерных решений.

Можно ли сказать, что какие-то числа объективно большие, а какие-то -- не очень большие?

На первый взгляд, нельзя. Ведь всегда можно выбрать число больше. И вообще, 10 это много или мало? Относительно 1 -- много! Но мне кажется, что есть всё-таки какая-то мера сложности, которая должна оцениваться относительно меры сложности человека и мира, в котором он живёт.

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

Были 8битные процессоры. Объективно -- не хватало. Потом 16, лучше, но не всегда хватало. 32 бита! Вообще отлично! На самом деле 32 бит для большинства задач хватало, а то что больше - ну писали библиотеки. Но вот адресное пространство 32 бит, как-то не очень... 64 бита. Нужно ли 128бит? 256? 512? (Я не про векторные инструкции и не про специализированные аккселераторы крипты, к примеру, а именно про регистры общего назначения).

Возможно, будет новый виток развития, где уже никто не будет писать на Си и на ассемблере, и адресные пространства будут такими, что понадобится 256-битные адреса.... Не знаю. Мне сейчас кажется, что всё-таки будет некий предел, который ограничит дальнейший рост.

Ну это как с размерами мозга. Каким может быть максимальный объём мозга, чтобы он работал? Так вот, где-то читал статью, что он не может быть слишком большим. Возникают большие задержки итд итп. То-есть, размер мозга оптимален.

Та же скорость света - как предел распространения сигнала.

Так что мне кажется, что тут можно говорить об антропном принципе в оценке сложности. :)

Насчёт Singularity возникли мысли, но уже не буду писать, а то много текста. :)

hugeping> Не знаю. Мне сейчас кажется, что всё-таки будет некий предел, который ограничит дальнейший рост.

Ха-ха. "Есть две бесконечные вещи — Вселенная и человеческая глупость. Впрочем, насчёт Вселенной я не уверен" А.Эйнштейн

Я бы еще сюда добавил и жадность.

hugeping> Насчёт Singularity возникли мысли, но уже не буду писать, а то много текста. :)

Сам туда очень давно не заглядывал, а там есть ссылки на аналогичные проекты. И среди них Inferno. Впрочем, туда я тоже давно не заглядывал :)

А вообще, действительно, основное отличие Inferno от Plan 9 - это исполнение пользовательского кода на языковой виртуальной машине. Кроме того, меня подкупила там возможность использования совместно с обычной ОС.

Времени на все, к сожалению, не хватает - это самый ограниченный во вселенной ресурс :(

hugeping> Так что мне кажется, что тут можно говорить об антропном принципе в оценке сложности. :)

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

P.S. Тут точнее было бы говорить об избавлении от субъектоцентризма.

P.S. Edited: 2020-12-07 18:34:44

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

Это в некотором роде идиллическая сказка. Старые машины далеко не всегда были похожи на это описание. И даже наоборот, бытовала точка зрения, что архитектура процессора должна быть очень высокого уровня.

Была такая линейка компьютеров IBM System i, которая начиналась, как IBM System/38 еще в 1978 (ее идейная предшественница System/3 еще в 1969), а потом AS/400. Отличительной особенностью было то, что программисты не имели доступа к аппаратуре, а работали только с виртуальной архитектурой, которую обеспечивала прошивка. Архитектура эта была реализована только для языков высокого уровня с компиляцией в промежуточное представление. Трансляция в машинный код осуществлялась прошивкой статически при установке этого ПО. При замене аппаратной части на несовместимую микроархитектуру ничего не надо было менять, только обновить кэш, где и хранился машинный код.

Я лично их не видел, но сам начинал работу на ЕС ЭВМ (аналог IBM S/370 модель 138), которая на простые машины тоже была не слишком похожа. Хотя с паяльником туда действительно лазили, предварительно с помощью осциллографа найдя неисправный ТЭЗ. Я до сих пор жалею, что не утащил альбомы с принципиальными схемами, которые потом все погибли во времена перестройки. Сейчас наверное уже ничего не сохранилось. Все там было большое, например пакет дисков объемом 29 МБ весил несколько кг, а переключатели и кнопки были, наверное, не меньше пяти см. Рама там была из литого металла и весила наверняка центнеры и могла выдержать последствия ядерного взрыва если не в самом эпицентре, конечно. Одна документация занимала целые шкафы. Зато там были и принципиальные схемы, и распечатки микропрограмм и кода ОС. Терминалы были действительно векторные, поскольку ЭЛТ не имела строчной развертки и луч действительно рисовал изображение на люминофоре, а контроллеры выглядели, как железные шкафы. В машинном зале все гудело и стрекотало, и ощущения были совсем не похожи на те, которые испытываешь рядом с ПК. :) Машинный код можно было увидеть и пощупать руками, когда держишь в руках перфокарту с отверстиями пробитыми в разных местах. А потом вставить ее в устройство чтения, выставить его адрес на панели ЦП и нажать на кнопку загрузки.
P.S. Edited: 2020-12-07 23:41:00

AL>> А где-то глубоко внутри я просто тоскую по старым машинам, которые и не могли адекватно предоставить простой для пользователя софт и сами были достаточно простыми, чтобы можно было в них лазить паяльником чтобы улучшать.
vvs> Это в некотором роде идиллическая сказка. Старые машины далеко не всегда были похожи на это описание. И даже наоборот, бытовала точка зрения, что архитектура процессора должна быть очень высокого уровня.

Скажем так, что проще, какой-нить PDP-6 или PDP-11 или мой ноут? :)

vvs> Была такая линейка компьютеров IBM System i, которая начиналась, как IBM System/38 еще в 1978 (ее идейная предшественница System/3 еще в 1969), а потом AS/400. Отличительной особенностью было то, что программисты не имели доступа к аппаратуре, а работали только с виртуальной архитектурой, которую обеспечивала прошивка. Архитектура эта была реализована только для языков высокого уровня с компиляцией в промежуточное представление. Трансляция в машинный код осуществлялась прошивкой статически при установке этого ПО. При замене аппаратной части на несовместимую микроархитектуру ничего не надо было менять, только обновить кэш, где и хранился машинный код.

Были очень разные машины и разные идеи. Про System i, кстати, не слышал раньше. Вообще машины от IBM не попадали в поле зрения пока. Надо будет восполнить пробел.

vvs> Я лично их не видел, но сам начинал работу на ЕС ЭВМ (аналог IBM S/370 модель 138), которая на простые машины тоже была не слишком похожа. Хотя с паяльником туда действительно лазили, предварительно с помощью осциллографа найдя неисправный ТЭЗ. Я до сих пор жалею, что не утащил альбомы с принципиальными схемами, которые потом все погибли во времена перестройки. Сейчас наверное уже ничего не сохранилось. Все там было большое, например пакет дисков объемом 29 МБ весил несколько кг, а переключатели и кнопки были, наверное, не меньше пяти см. Рама там была из литого металла и весила наверняка центнеры и могла выдержать последствия ядерного взрыва если не в самом эпицентре, конечно. Одна документация занимала целые шкафы. Зато там были и принципиальные схемы, и распечатки микропрограмм и кода ОС. Терминалы были действительно векторные, поскольку ЭЛТ не имела строчной развертки и луч действительно рисовал изображение на люминофоре, а контроллеры выглядели, как железные шкафы. В машинном зале все гудело и стрекотало, и ощущения были совсем не похожи на те, которые испытываешь рядом с ПК. :)

Для адекватной оценки я предлагаю представить себе объём документации такого уровня на какой-нибудь современный сервер. С принципиальными схемами, документацией на чипы, распечатки микропрограмм и кода ОС :)

Больших машин я, к сожалению, не видел, но читал про них. Конечно, тоже неоднозначно всё. Например, пакетный режим работы это одно, а интерактивный уже совсем другое. И вряд ли меня бы увлекла работа в пакетном режиме :)

AL> Скажем так, что проще, какой-нить PDP-6 или PDP-11 или мой ноут? :)

Да, туда еще был смысл лазить с паяльником и пользоваться принципиальной схемой. И ее даже можно было понять, поскольку делали люди, а не автоматический синтез из какого-нибудь Verilog. А в каком-нибудь смартфоне уже, наверное, нет.

AL> Для адекватной оценки я предлагаю представить себе объём документации такого уровня на какой-нибудь современный сервер. С принципиальными схемами, документацией на чипы, распечатки микропрограмм и кода ОС :)

Нынешний производитель нас явно жалеет и потому не перегружает такими деталями. А в СССР каждый телевизор продавался с принципиальной схемой.

AL> Больших машин я, к сожалению, не видел, но читал про них. Конечно, тоже неоднозначно всё. Например, пакетный режим работы это одно, а интерактивный уже совсем другое. И вряд ли меня бы увлекла работа в пакетном режиме :)

Для интерактивной работы были разные системы разделения времени. И Unix появился именно тогда. А какие игры были! Colossal Cave Adventure! У нас на PRIMUS были калах и какая-то стратегия с чистым текстом. И писали все на каком-нибудь ассемблере или на, худой конец, FORTRAN IV. Конечно были и Симула-67 и Алгол-68 и Лисп, но это уже не то. :) OS/360 и VM/370 были целиком написаны на макроассемблере и настоящий системщик обязан был его знать на зубок.

AL> Код, который ты приводил, как раз ярко иллюстрирует мою идею. Компилятор сложная технически штука. Очень сложная. Зато она позволяет вот так просто для пользователя писать код.

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

В прошлом не раз предпринимались попытки устранить этот разрыв за счет более высокого уровня архитектуры процессора, например Intel iAPX 432. Такие попытки проиграли из-за низкого уровня технологий, приведшего к низкой производительности. Я бы напомнил, что были и попытки, наоборот, еще понизить уровень микроархитектуры для увеличения производительности, например IA-64 (Itanium). Проиграла из-за цены.

То есть я не вижу и здесь объективной сложности, а только рыночные факторы.

А вот это интересный пример "простого" кода: https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine/

Не уверен, к какому типу языка программирования его можно отнести. Пожалуй ближе к аппаратным языкам, наподобие Verilog/VHDL.

Мне лично код отрисовки линии из твоего примера кажется куда понятнее кода относящегося к ядру. Но это потому, что первое я изучал, а второе вижу впервые.
Но в последнее время претит писать сложные куски кода. Иногда часами сижу и раздумываю как написать попроще и понятнее. Инвертирую условия, смотрю какие ветки выполняются с большей вероятностью. Разбиваю задачки на мелкие фрагменты. Хотя работы минут на десять от силы.
Коллеги теперь иногда жалуются, что мой код излишне декомпозирован и разбит на мелкие фрагменты. Иногда эти компоненты излишне простые и даже примитивные.
Теперь борюсь с собой, чтобы излишне долго с кодом не ковыряться.