Так часто приходится писать такой код:

x = (y + 1) % 10;
x = (y + 1) * (z - 1);
x = (double)(f(y) + 1);

Так как у операторов + и — такой низкий приоритет, то приходится постоянно заключать их в скобки, а это приводит к глубокому вложенному коду, который сложно понять.
В Visual Studio 2015 RC добавлена пара экспериментальных операторов, названных операторы–головастики. Они позволяют добавлять и вычитать единицу без необходимости прибегать к скобкам.

x = -~y % 10;
x = -~y * ~-z;
x = (double)-~f(y);

Некоторое время назад я натолкнулся на упражнение, которое выглядит не так уж и сложно:

Пусть последовательность x_n определена так:

посчитайте x₃₀.

Это не так уж и трудно закодировать, возможно реализовав x_i как рекурсивную функцию. С обычными числами с плавающей запятой двойной точности, по мере увеличения i, результат красиво сходится к 100. Супер!

К сожалению, 100 даже близко не является правильным ответом. На самом деле последовательность сходится к 5.

Обнаружил на просторах интернета забавный плагин для VIM — Homura.
Он позволяет записывать историю редактирования и преобразовывать её в
интерактивный HTML, с возможностью перемотки и управлением скоростью
проигрывания.

В языке Go используются обычные способы управления потоком выполнения: if, for, switch, goto. Есть ещё оператор go, чтобы запустить код в отдельной го-процедуре. А сейчас я бы хотел обсудить менее обычные способы: defer, panic и recover.

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

Например, посмотрим на функцию, которая открывает два файла и копирует содержимое из одного файла в другой:

В игре Pac-Man (и во многих клонах и продолжениях), было установлено, что привидения Pinky и Inky преследуют Pac-Man´а, определяя точку в которую следовать с учётом направления, в котором он движется. Например, Pinky обычно следует к точке, которая расположена в четырёх единицах от Pac-Man´а по направлению его движения. Однако, если Pac-Man двигается вверх, этой точкой назначения становится точка, расположенная на четыре единицы вверх и четыре единицы влево относительно Pac-Man´а. Привидение Inky имеет похожее поведение, когда Pac-Man двигается вверх. Почему же Pinky и Inky имеют различное поведение, когда Pac-Man двигается вверх?

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

Техника, известная как «Чтение по спирали/по часовой стрелке» (“Clockwise/Spiral Rule”) позволяет любому программисту разобрать любое объявление языка Си.

Следуйте этим простым шагам:

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

Был у меня простой, рабочий код (я убрал лишнее оставил только суть):

typedef enum
  {
    enNone,
    enOne,
    enTwo,
    enThree
  }TEnum;

    switch(Enum)
      {
        case enNone:
             /*Ничего не делаем*/
             break;/*enNone*/
        case enOne:
             Value=f1(Value);
             Value=A*Value+B;
             break;/*enOne*/
        case enTwo:
             Value=f2(Value);
             Value=A*Value+B;
             break;/*enTwo*/
        case enThree:
             Value=f3(Value);
             Value=A*Value+B;
             break;/*enThree*/
      }/*SWITCH*/

Больших претензий к нему у меня не было, но решил его микрооптимизировать:

Предыстория

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

Естественно, что одной из первых задач возникла проблема преобразования в этот формат. Из всех существующих средств ни одно меня не устроило, и для обычных художественных произведений мне было проще и быстрее сделать в своём привычном текстовом редакторе (jEdit или VIM).

Небольшими затруднениями для меня были: а) описание документа — это решалось с помощью использования шаблона; б) изображения — обычно это была обложка и её можно было добавить с помощью FB Editor'а (первого); в) сноски — они встречались не часто, понемногу, и, в принципе, зная формат, добавлялись без особых затруднений.

Некоторое время назад, появился конвертер из FB2 в PDF от KiR'а, помимо того, что это замечательный инструмент для получения pdf хорошего, почти издательского качества, это был пример использования формата DocBook, о котором я много слышал, но никак не мог начать и собрать все необходимые инструменты воедино.

DocBook, как и FictionBook — формат, основанный на технологии XML. И как для FictionBook'а его не очень удобно редактировать в своём природном формате, но, к счастью, существует такая утилита, как asciidoc, которая позволяет создать из текстового файла с довольно простой разметкой соответствующий документ в формате DocBook, html или других.

Создание fb2-backend'а

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

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

Методов разбора существует множество (рекомендую следующий обзор Dick Grune, Ceriel J. H. Jacobs — Parsing Techniques: A Practical Guide, ISBN 0-13-651431-6). Причём реализации методов варьируются от полностью ручных до использования автоматизированных генераторов, таких как bison, antlr, lemon и других.
В то время, как ручное написание лексических и синтаксических (далее я буду называть из лексер и парсер) разборов позволяет достичь максимальной скорости и контроля (особенно над ошибками и способами их преодоления), использование генераторов позволяет сосредоточиться непосредственно на задаче, облегчает модификацию грамматики и бережёт время. Умение владеть такими инструментами позволяет чаще прибегать к DSL (Domain Specific Language) и вообще видеть возможность их применения.

Я хочу привести пример использования bison (парсер) и flex (лексер) в реальной жизни: от возникновения задачи, до её решения.

Поводом для написания этой статьи стало желание разобраться с тем, как работает Y-комбинатор.

Чтобы мозги не ржавели и работали как часы, я стараюсь пробовать новые и необычные вещи.
Интереса ради, я скомпилировал Lua 5.x под DOS, с этим никаких проблем не было, но при проверке Lua на её стандартных тестах, я обнаружил код вычисления факториала, работу которого я не понял.
Но ясно осознал, что это нечто относится к функциональному программированию.