tower of weaking (tribute)

[amarao]

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

Хорошее ПО прячет сложность от пользователя. Это означает, что исходный код ПО содержит в себе сложность, о которой потребитель ПО не знает. Наоборот, если потребитель очень хорошо знает эту сложность, ПО плохо её прячет.

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

Comments

[juan_gandhi]

Забавная мысль. А ведь возможно, что сложность просто не очевидна.

[amarao]

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

[juan_gandhi]

Hу вас послушать, так получается, что качество продукта оценивается по неспособности пользователя понять суть вещей. Это странно. С другой стороны, насчет простого интерфейса - тут я двумя руками за.

[amarao]

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

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

[juan_gandhi]

Я все больше перестаю понимать. Можно на примерах, для простого народу? Вот xargs, или grep, или curl, или ncdu - они входят в этот узкий круг загадочных утилит?

[amarao]

xargs - хороший пример. Все умеют пользоваться xargs, и он работает волшебно просто.

Открываем сырцы:

  /* All POSIX systems are required to support ARG_MAX of at least
   * 4096.  For everything to work the total of (command line +
   * headroom + environment) must fit into this.  POSIX requires
   * that we use a headroom of 2048 bytes.  The user is in control
   * of the size of the environment.
   *
   * In general if bc_init_controlinfo () returns
   * BC_INIT_CANNOT_ACCOMODATE_HEADROOM, its caller can try again
   * with a smaller headroom.  However, in the case of xargs, this
   * would not be POSIX-compliant.

...

      /* Allow only up to MAX_PROC_MAX child processes. */
      proc_max = parse_num (optarg, 'P', 0L, MAX_PROC_MAX, 1);
      break;

...

      if (0 != unsetenv (slot_var_name))
        {
          /* This is a fatal error, otherwise some child process
             may not be able to guarantee that no two children
             have the same value for this variable; see
             set_slot_var.
          */

...

ifdef SIGUSR1

ifdef SIGUSR2

/* Accept signals to increase or decrease the number of running child processes. Do this as early as possible after setting proc_max. */ sigact.sa_handler = increment_proc_max; sigemptyset(&sigact.sa_mask); sigact.sa_flags = 0; if (0 != sigaction (SIGUSR1, &sigact, (struct sigaction *)NULL)) error (0, errno, _("Cannot set SIGUSR1 signal handler"));

sigact.sa_handler = decrement_proc_max; sigemptyset(&sigact.sa_mask); sigact.sa_flags = 0; if (0 != sigaction (SIGUSR2, &sigact, (struct sigaction *)NULL)) error (0, errno, _("Cannot set SIGUSR2 signal handler"));

endif /* SIGUSR2 */

endif /* SIGUSR1 */

...

/* Failures here are undesirable but not fatal, since we can still guarantee that this child does not have a duplicate value of the indicated environment variable set (since the parent unset it on startup). If the user doesn't want us to set the variable, there is nothing to do. However, we defer the bail-out until this point in order to get better test coverage. */ ...

        if (errno)
          {
            /* Write errno value to parent.  We do this even if
             * the error was not E2BIG, because we need to
             * distinguish successful execs from unsuccessful
             * ones.  The reason we need to do this is to know
             * whether to reap the child here (preventing the
             * exit status processing in wait_for_proc () from
             * changing the value of child_error) or leave it
             * for wait_for_proc () to handle.  We need to have
             * wait_for_proc () handle the exit values from the
             * utility if we run it, for POSIX compliance on the
             * handling of exit values.
             */

... /* we know the child is about to exit, so wait for that. * We have to do this so that wait_for_proc () does not * change the value of child_error on the basis of the * return value -- since in this case we did not launch * the utility. * * We do the wait before deciding if we failed in order to * avoid creating a zombie, even briefly. */ ...

      {
        /* Failed to read data from pipe; the exec must have
         * succeeded.  We call add_proc only in this case,
         * because it increments procs_executing, and we only
         * want to do that if we didn't already wait for the
         * child.
         */

И это только малое подмножество нюансов внутри. Там ещё отдельно работа с системами с локалью и без, правильное поведение в нескольких edge-case'ах.

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

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

[juan_gandhi]

О да; но разве кто-то считает xargs простой штучкой? Да и много ли народу ее знает? Я каждый раз, когда меня спрашивают, что подучить, советую изучать xargs. И да, заглянув в эту бездну, начинаешь ещё больше ужасаться, конечно.

[amarao]

xargs умеет много дополнительного, но базовый cat foo | xargs bar крайне прост.

[anonim_legion]

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

[amarao]

ты хочешь поругать плохое. Это всегда приятно.

А как насчёт того, чтобы похвалить хорошее?

[anonim_legion]

Хорошее я видел больше 20 лет назад.

И об интересе к плохому: https://telegra.ph/Pochemu-vezde-tolko-plohie-novosti-10-05

[amarao]

Ты прав, ты видел хорошее больше 20 лет назад. С тех пор ты не смотришь на хорошее.

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