Злые языки утверждают, что функциональные языки программирования — «языки для написания факториалов». Чаще всего так определяют язык Haskell, мы же начнем с того функционального языка, который сильно повлиял и на Haskell, и на подмножество средств для функционального программирования многих других языков — язык Scheme. По-крайней мере, map и for-each, filter и reduce, а так же apply и eval пришли в наши любимые языки программирования если не именно из Scheme, то в том числе и оттуда.

Рассмотрим некоторые возможные способы записи вычисления факториала. Заодно получится своеобразная ода языку программирования Scheme. Думаю, этот замечательный язык того вполне заслуживает.

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

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

YOLO

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

Вообразите наше восхищение, когда манифест этой новаторской новой методологии попал в наши новостные ленты. Пророк YDD, она же YOLO Driven Development Todor Grudev высек в камне (на GitHub) 17 заповедей YDD. YOLO буквально означает — You Only Live Once, или по-русски: ВЖОР — Вы Живете Один Раз.

В Windows стек растет от больших адресов к меньшим. Иногда это определяется архитектурно, а иногда это просто принятое соглашение. Значение указателя стека (регистр процессора), является указателем на значение в верхней части стека. А значения, расположенные глубже по стеку, соответственно, находятся по большим адресам. Но что происходит с данными, которые расположены по адресам, меньшим, чем указатель стека?

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

TL;DR: GitHub://PastorGL/AQLSelectEx.

Однажды, ещё не в студёную, но уже зимнюю пору, а конкретно пару месяцев назад, для проекта, над которым я работаю (нечто Geospatial на основе Big Data), потребовалось быстрое NoSQL / Key-Value хранилище.

Терабайты исходников мы вполне успешно прожёвываем при помощи Apache Spark, но схлопнутый до смешного объёма (всего лишь миллионы записей) конечный результат расчётов надо где-то хранить. И очень желательно хранить таким образом, чтобы его можно было по ассоциированным с каждой строкой результата (это одна цифра) метаданным (а вот их довольно много) быстро найти и отдать наружу.

Приветствую всех в своей традиционной рубрике, полной лавкрафтианского безумия.

В процессе написания одной из прошлых статей (не ищите, она была не особенно хороша) я задумался над тем, что квайн… Да, на всякий случай напомню: квайн — это программа, которая выводит свой собственный текст, причём делает это «честно» (не подсмотрев, допустим, этот текст в файле на жёстком диске). В общем, традиционная бессмысленная пузомерка программистов.

Так вот, я задумался над тем, что квайн, в принципе, может нести произвольную полезную нагрузку. То есть — делать ещё что угодно помимо своей основной функции. И в качестве proof-of-concept я решил написать квайн, который играет в крестики-нолики. И написал. Грязные подробности под катом.

Несколько лет назад на форуме SQL.ru решили провести сравнение реализаций трассировщиков лучей на разных языках программирования. К сожалению, моя заявка не может участвовать т.к. она не выводит надпись «PIXAR», поэтому публикую ее здесь.

Для чистоты эксперимента я использовал SQLite без расширений. Оказалось, что там нет даже функции SQRT.

WITH RECURSIVE numbers AS (SELECT 0 AS n UNION ALL SELECT n+1 FROM numbers WHERE n<89),
pixels AS (SELECT rows.n as row, cols.n as col FROM numbers as rows CROSS JOIN
numbers as cols WHERE rows.n > 4 AND rows.n < 38 AND cols.n > 9 AND cols.n < 89),
rawRays AS (SELECT row, col, -0.9049 + col * 0.0065 + row * 0.0057 as x,
-0.1487 + row * -0.0171 as y, 0.6713 + col * 0.0045 + row * -0.0081 as z FROM pixels),
norms AS (SELECT row, col, x, y, z, (1 + x * x + y * y + z * z) / 2 as n FROM rawRays),
rays AS (SELECT row, col, x / n AS x, y / n AS y, z / n AS z FROM norms),
iters AS (SELECT row, col, 0 as it, 0 as v FROM rays UNION ALL
SELECT rays.row, rays.col, it + 1 AS it, v + MAX(ABS(0.7+v*x) - 0.3,
ABS(0.7+v*y) - 0.3, ABS(-1.1+v*z) - 0.3, -((0.7+v*x) * (0.7+v*x) +
(0.7+v*y) * (0.7+v*y) + (-1.1+v*z) * (-1.1+v*z)) * 1.78 + 0.28) AS v
FROM iters JOIN rays ON rays.row = iters.row AND rays.col = iters.col WHERE it < 15),
lastIters AS (SELECT it0.row, it0.col, it0.v AS v0, it1.v AS v1, it2.v AS v2
FROM iters as it0 JOIN iters AS it1 ON it0.col = it1.col AND it0.row = it1.row
JOIN iters AS it2 ON it0.col = it2.col AND it0.row = it2.row
WHERE it0.it = 15 AND it1.it = 14 AND it2.it = 13),
res AS (SELECT col, (v0 - v1) / (v1 - v2) as v FROM lastIters)
SELECT group_concat(
substr('$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/|()1{}[]?-_+~<>i!lI;:,"^. ',
round(1 + max(0, min(66, v * 67))), 1) || CASE WHEN col=88 THEN X'0A' ELSE '' END, '')
FROM res;

Здесь можно покрутить кубик

Под катом построчный разбор запроса. Как обычно, достаточно знания основ SQL и школьной математики.

Zircon? Что это?

В августе 2016 года, без каких-либо официальных объявлений со стороны Google, были обнаружены исходники новой операционной системы Fuchsia. Эта ОС основана на микроядре под названием Zircon, которое в свою очередь основано на LK (Little Kernel).

Fuchsia is not Linux

О чем пойдет речь в статье?

vDSO в Zircon является единственным средством доступа к системным вызовам (syscalls).

А разве нельзя из нашего кода напрямую вызвать инструкции процессора SYSENTER/SYSCALL? Нет, эти инструкции процессора не являются частью системного ABI. Пользовательскому коду запрещено напрямую выполнять такие инструкции.

Желающих узнать больше деталей о таком архитектурном шаге приглашаю под кат.

Дальнейший текст — моя точка зрения. Возможно, она позволит кому-то по-новому взглянуть на дизайн языков программирования или увидеть какие-то преимущества и недостатки конкретных фич. Я не буду лезть в частные подробности типа "в языке должна быть конструкция while", а просто опишу общие подходы. P.S. У меня когда-то была идея создать свой язык программирования, но это оказалось довольно сложным процессом, который я пока не осилил.

Влияние предыдущего опыта

На написание статьи меня вдохновила вот эта статья. Автор придумал свой язык программирования, и этот язык своим синтаксисом и особенностями оказался подозрительно похожим на Free Pascal, на котором и была написана реализация ВМ для языка. И это не совпадение. Языки программирования, на которых мы раньше писали, загоняют мышление в рамки языка. Мы сами можем не замечать этого, но сторонний наблюдатель с иным опытом может посоветовать что-то неожиданное или сам научиться чему-то новому.

Рамки мышления немного раздвигаются после освоения нескольких языков. Тогда в языке А вам может захотеться иметь фичу из Б и наоборот, а ещё появится осознание сильных и слабых стороны каждого языка.

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

Мой опыт: когда-то я начинал с паскаля, впоследствии познакомился с Java, Kotlin, C++, Python, Scheme, а основными языком считаю Scala. Как и в вышеописанном случае, мой "идеальный" язык имеет много общего со Scala. По крайней мере, я отдаю себе отчёт в этом сходстве)

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

В данной статье я расскажу немного про протокол DHCP и некоторые тонкости из bash'а.