На Хабре появился проект True — экспериментальный язык программирования, в котором программа представляет собой цикл, а её код — ленту строк, которую этот цикл читает и меняет. Автор описывает интерпретатор Simple: кроссплатформенный, на Python 3 и Tkinter, без внешних зависимостей. Формально это не статья о трудоустройстве и не гайд по профессии, но для редакции ProCareer Hub такие проекты интересны по другой причине: они показывают, как разработчики учатся думать о коде, состоянии и побочных эффектах. А это ровно те навыки, которые спрашивают на собеседованиях и которыми проверяют зрелость инженера.

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

Что на самом деле означает «программа меняет саму себя»

В обычной модели программа — это инструкции, а данные — то, с чем инструкции работают. В модели True граница размыта: код хранится как последовательность строк, а цикл исполнения читает очередную строку и может её изменить. По сути это разновидность самомодифицирующегося кода, известного ещё с первых ассемблерных программ. В современной практике к нему близки JIT-компиляторы, метапрограммирование, макросы и системы, которые генерируют код на лету.

Важно понимать: «самоизменяемость» — не магия и не признак «продвинутости». Это инструмент с конкретными издержками. Чем больше программа меняет себя, тем сложнее её отлаживать, тестировать и объяснять коллегам. Поэтому такие языки почти всегда остаются нишевыми: учебными, исследовательскими или художественными. И это нормально — у них другая задача.

Кому и зачем это может быть полезно

Если вы учитесь программировать, проект вроде True даёт редкий опыт: увидеть, как из минимального набора примитивов — цикла, строки, операции замены — вырастает вычислительная модель. Это тренирует понимание интерпретаторов, состояний и порядка выполнения. Если вы уже работаете, такой проект полезен как упражнение в чтении чужого кода и оценке архитектурных решений.

  • Студентам и джунам — чтобы на практике увидеть разницу между кодом и данными, разобраться, как устроен интерпретатор.
  • Опытным разработчикам — как повод освежить тему метапрограммирования и побочных эффектов.
  • Преподавателям — как пример для занятий по теории вычислений или устройству языков.
  • Тем, кто собирает портфолио — как проект, о котором можно содержательно рассказать на собеседовании.

Чего здесь точно не стоит искать — прямой связи с вакансиями. Язык True не входит в требования работодателей, и в резюме он сам по себе не добавит очков. Ценность — в навыках, которые вы прокачаете, пока будете в нём разбираться.

Как оценивать экспериментальный язык или нестандартный проект

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

  • Понятность модели. Можно ли в двух-трёх предложениях объяснить, как исполняется программа? Если нет — скорее всего, проблема в дизайне, а не в вашем понимании.
  • Предсказуемость. Понятно ли, что произойдёт при изменении строки кода во время выполнения? Есть ли правила, а не сюрпризы?
  • Отлаживаемость. Можно ли пошагово посмотреть, как меняется состояние? Есть ли трассировка?
  • Тестируемость. Можно ли написать тесты на поведение программы, а не только на её вывод?
  • Зависимости и запуск. Проект на Python 3 и Tkinter без внешних зависимостей — это плюс: меньше барьеров для первого запуска.
  • Документация. Хватает ли примеров, чтобы повторить базовый сценарий без чтения всего исходника?

Если по большинству пунктов ответ «скорее нет», проект стоит воспринимать как эксперимент, а не как инструмент для реальной задачи. Это не приговор — просто честная оценка.

Типичные ошибки при знакомстве с такими языками

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

Третья ошибка — начинать с интерфейса. Tkinter-обёртка выглядит дружелюбно, но если вы не поняли модель исполнения, GUI только запутает. Четвёртая — не фиксировать наблюдения. Если вы разбираете проект для портфолио или обучения, ведите короткие заметки: что попробовали, что получилось, где споткнулись. Это потом превращается в осмысленный рассказ на интервью.

И пятая, самая частая — молчание. Автор проекта прямо просит обратную связь. Конструктивный отзыв — это отдельный навык: указать, что было непонятно, в каком месте, что вы ожидали увидеть. Такой отзыв полезен и автору, и вам: вы учитесь формулировать претензии к коду по делу, а не «мне не зашло».

Что сделать прямо сейчас

Если тема зацепила, вот практический план на пару вечеров. Сначала прочитайте описание модели и попробуйте пересказать её своими словами — без подглядывания. Затем запустите интерпретатор и выполните простейший пример: одна строка, один цикл, одно изменение. После этого усложните: сделайте так, чтобы программа меняла своё поведение в зависимости от состояния.

  • Запишите три вопроса, на которые описание не ответило.
  • Сформулируйте один конкретный сценарий, где такой подход был бы уместен, и один — где он явно во вред.
  • Напишите короткий отзыв автору: что понятно, что нет, чего не хватает в примерах.
  • Добавьте проект в список «разобрать подробнее», если хотите использовать его в портфолио.

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