Ненормальное программирование *

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

Механизм макросов используется в Julia довольно часто. Макрос при использовании начинается с символа @ и имеет вид @show, @benchmark… А также, в неявной форме, макросами являются регулярные выражения r"[a..z]" (это макрос с полным именем r_str), а также многочисленные другие способы применения, включая примеры Modia.jl / Unitful.jl с макросом u_str, где физическая величина «вшита» в число:

L = 0.8u"m",
m = 1.0u"kg",
d = 0.5u"Nms/rad",
g = 9.81u"m/s^2",


Придумывать имена сложно. Давайте посмотрим, как далеко мы можем зайти без них.

Что это?

Это язык программирования, основанный на трёх парадигмах:

Бесточечном программировании

Стековом программировании

Массиво-ориентированном программировании

Основная «фишка» языка — избегание любых наименований. Оставаясь верным этой максиме, сам язык тоже не имеет названия. «Язык программирования без имён» (namingless programming language) — это его определение.

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

Для чего это нужно?

В основном ради развлечения. Это язык для хобби-программирования.

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

Как выглядит код на таком языке?

Вот так:

i_^_b_H_i_cpp^_)_V_b_v_J_^_E_H_leafL_==^_)_V_H_Z_Z_^_)_V_H_I_^_E_1^_2^_#_G_Z_Z_^_E_1^_2^_#_H_$_L_-^_G_m_G_&_&_

Чёрт возьми!

Ага.

Простите.

Реализация простого HTTP CONNECT прокси-сервера на Go, квест с маркировкой сетевых пакетов и запуск программы в Android.

Когда-то давно, году в 2013-м, на глаза мне попался следующий код:

>>>+[[-]>>[-]++>+>+++++++[<++++>>++<-]++>>+>+>+++++[>++>++++
++<<-]+>>>,<++[[>[->>]<[>>]<<-]<[<]<+>>[>]>[<+>-[[<+>-]>]<[[
[-]<]++<-[<+++++++++>[<->-]>>]>>]]<<]<]<[[<]>[[>]>>[>>]+[<<]
<[<]<+>>-]>[>]+[->>]<<<<[[<<]<[<]+<<[+>+<<-[>-->+<<-[>+<[>>+
<<-]]]>[<+>-]<]++>>-->[>]>>[>>]]<<[>>+<[[<]<]>[[<<]<[<]+[-<+
>>-[<<+>++>-[<->[<<+>>-]]]<[>+<-]>]>[>]>]>[>>]>>]<<[>>+>>+>>
]<<[->>>>>>>>]<<[>.>>>>>>>]<<[>->>>>>]<<[>,>>>]<<[>+>]<<[+<<
]<]

Это интерпретатор языка Brainfuck, написанный на самом Brainfuck. Ссылки на оригинал у меня не осталось, только код, так что автора я назвать не смогу.

Мне всегда было безумно интересно узнать, как он работает. И теперь я решил наконец-то это сделать!

283 ГБ/с на AMD Ryzen 9 7700X.

Сборка (протестирована с GCC 13):

g++ fizzbuzz.cc -march=native -o fizzbuzz -O3 -Wall -std=c++20 -fno-tree-vectorize -fno-exceptions

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

Вопрос из области ненормального программирования: насколько сложные программы вы сможете написать на питоне, не пользуясь в принципе переменными (а также агрументами функций), за исключением пары глобальных массивов? Правильный ответ: да любой сложности. Если что-то можно сделать на ассемблере, то уж на питоне и подавно! Правда, пусть лучше код вместо меня сгенерирует машина :)

Продолжаем разговор о минималистичном компиляторе, который вполне реально написать за выходные. Задачей стоит транслировать код из придуманного мной языка в x86 ассемблер. Мой компилятор состоит из 611 строк кода, при этом не имеет ни единой зависимости:

ssloy@khronos:~/tinycompiler$ cat *.py|wc -l

611

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

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

Большинство современных программистов привыкли использовать инструменты автодополнения кода и новомодные ИИ-штучки а-ля Copilot. Они стали нормой.

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

Классические компьютеры Macintosh становятся все популярнее среди коллекционеров. В моей личной коллекции имеются и iMac G3, и горячо любимый мной Macintosh SE 30, и Apple Newton. Я собираю их не ради развлечения — я чувствую, как стремительно мир утрачивает знания об истории вычислительной техники. Особенно это касается программирования. Уму непостижимо, сколько сил приходится приложить, чтобы найти все необходимые средства разработки и документацию тех лет.

Я люблю трассировщики лучей и даже посвятил им половину своей книги. Менее известна моя любовь к ZX Spectrum — домашнему компьютеру 1982 года, с которым я вырос и с которого начался мой интерес к графике и программированию. По современным стандартам эта машина столь смехотворно слаба (и даже по стандартам 1980-х), поэтому возникает неизбежный вопрос: в какой степени удастся портировать трассировщик лучей из книги Computer Graphics from Scratch на ZX Spectrum?

В ZX Spectrum установлен процессор Z80 на 3,5 МГц (в тысячу раз медленнее, чем современные компьютеры), который не может умножать числа (!!!), и 48 КБ ОЗУ (в миллион раз меньше); он имеет графический режим 256x176 (примерно в двести раз меньше современного разрешения), способный отображать 15 цветов (в миллион раз меньше, к тому же с довольно необычными особенностями). Интересная машина для графического приложения, активно задействующего CPU!

Я планирую реализовать его на Sinclair BASIC — встроенном языке программирования Spectrum. Это не просто BASIC, а древний, очень ограниченный диалект BASIC. Например, единственные структуры управления в нём — это FOR и IF (а у IF нет ELSE и даже ENDIF); все переменные глобальны; не существует вызовов функций, только GO TO и GO SUB; и так далее. Кроме того, он интерпретируемый, то есть сверхмедленный. Но, по крайней мере, он реализует программное умножение! Если мне нужна будет производительность, то я всегда могу переписать трассировщик на ассемблере.

Я настроил минимально необходимую среду: код на BASIC я пишу в VS Code, компилирую его с помощью BAS2TAP и запускаю в эмуляторе FUSE. Благодаря этому скорость итераций оказалась достаточно высокой.

Это тематическое продолжение моей предыдущей статьи, которая описывала реализацию связанного списка на Wolfram Language. На этот раз мы будем делать динамический список. Где-то его называют просто список либо динамический массив. В C# эта структура представлена типом List<T>, а в Java наиболее похожим классом является ArrayList, хотя насколько я помню называют его динамический массив.

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

Ниже реализация динамического массива/списка на Wolfram Language.

Возможно 11 подписчиков моего блога обратили внимание на тот факт, что все мои статьи касаются языка Wolfram, а несколько последних статей вышли довольно громоздкими. Одна из последних статей была помечена Хабром как требующая в среднем 32 минуты на прочтение. Я посчитал, что это может отпугнуть пользователей (все 11 человек и не факт, что все они до сих пор читают Хабр) и решил попробовать писать более короткие статьи. Плюс я сам перестану теряться в большом количестве текста.

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

Ниже реализация структуры данных LinkedList на Wolfram Language.

Задавались ли вы когда-нибудь вопросом, можно ли полноценно программировать при помощи директивы #define в языке C? Полнота по Тьюрингу шаблонов C++ известна весьма широко, например, люди пишут трассировщики лучей, делающие все вычисления во время компиляции (вместо времени исполнения). А как обстоят дела с препроцессором C? Вопрос оказался сильно нетривиальнее, и эта история является, на мой вкус, отличным анекдотом для курса лекций по теории компиляторов, что я готовлю в данный момент. В частности, для лучшего понимания происходящего здесь, рекомендую ознакомиться со второй статьёй, которую я опубликовал параллельно этой: лексер и парсер.

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

На уходящей неделе мне попалась симпатичная, хоть и не новая мини‑серия статей на Дзен‑канале @zdgzdgzdg про процедурную генерацию лабиринта методом «коллапса волновой функции». Пока я читал эти статьи и знакомился с кодом, меня осенило: ведь это же вычисления в комонаде, погружённые в монаду! Я не издеваюсь, действительно, речь идёт о композиции двух паттернов функционального программирования: комонады Zipper, превращающей локальные правила в глобальное состояние, и монады Random, позволяющей генерировать случайные объекты.

И вот, в качестве баловства на выходных, я решил реализовать этот «квантовый» алгоритм генерации лабиринтов на Haskell, используя и комонады и монады, и вообще, ни в чëм себе не отказывая. И хотя язык программирования Haskell нужен не только для извращений, но именно для них он подходит идеально!

С++ видится мне огромным франкенштейном: очень уж много разнообразных способов описать свои намерения. В добавок к этому язык пропагандирует политику zero-cost abstractions, из которой следует (помимо прочего), что программист в ответе за все свои действия. Однако, работая с большими кодовыми базами, становится крайне тяжело держать в уме различные тонкости языка, которые держать в уме нужно — иначе Undefined Behavior.

В данной статье хочу рассказать о трех интересных случаях UB, с которыми столкнулся при разработке на С++. Не думаю, что опытным разработчикам примеры из статьи будут полезны, но, полагаю, что начинающим разработчикам смогу показать на своем примере, как не стоит писать код на C++.

Я как большой фанат Wolfram Language (WL) очень часто изучаю открытые репозитории с кодом на этом языке. Изучив достаточно много кода я заметил, что стиль написания этого кода очень сильно разнится от проекта к проекту. Но так же я изучил много встроенных пакетов в Mathematica/Wolfram Language, которые были написаны разработчиками из Wolfram Research. В большинстве случаев они были написаны еще хуже (т.е. более неструктурированно и без единого стиля) чем пакеты такого же объема и сложности в открытом доступе. Но и среди проектов на GitHub и среди пакетов в языке мне попадались те, которые действительно хорошо написаны. Постепенно у меня сформировалось понимание того стиля, который будет наиболее прост и понятен большинству пользователей WL. В этой статье я хочу поделиться своим мнением и задокументировать тот стиль и ту конвенцию, которую я постепенно выработал для себя. Возможно, это станет еще кому-то полезно и изучив от корки до корки эту статью, а лучше вызубрив, чтобы от зубов отскакивало, вы станете так быстро решать уравнения и строить графики, что...

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

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

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