Сборник языков программирования А-я

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

21

Amber — чтобы не тратить нервы на Bash.

Его сделали, чтобы убрать типичные болевые точки Bash: путаницу с типами, странные ошибки из-за пробелов или кавычек, сложность поддержки длинных скриптов. Поэтому в Amber сразу заложили типобезопасность и проверки ещё до запуска — чтобы ловить ошибки раньше, пока они не успели навредить. Плюс модульность: можно делить большие задачи на кусочки, собирать их отдельно, а потом соединять, и язык сам проследит, чтобы они друг другу подходили.

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

Amber может:писать рутину на удобном, безопасном синтаксисе и превращать это в обычный Bash. Делить код на модули, ловить ошибки заранее, делать сообщения понятными.

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

22

Amber JS— это язык-инструмент одного момента.

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

Появился он в эпоху, когда фронтенд стремительно разрастался: каждый день выходили новые библиотеки, и среди этого шума AmberJS пытался быть тихим, аккуратным вариантом — с понятной логикой и без лишней магии. Его сила была в простоте: делай ясно, собирай быстро, не усложняй там, где можно обойтись малым.

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

Чего не умеет: не годится для больших, сложных приложений. У него не было мощной экосистемы и армии разработчиков, которая бы тянула его вперёд. Он не пытался стать стандартом — и потому, когда индустрия выбрала другие пути, он тихо ушёл в тень. Его цель была не «жить вечно в учебниках», а «помочь сделать прямо сейчас».

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

23

Amber Smalltalk:

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

Появился он в 2011 году (сначала под именем Jtalk) как идея: «А давайте запустим Smalltalk прямо в браузере». Его сделал Николас Петтон, опираясь на старые эксперименты с Smalltalk в вебе. Главная фишка была в том, что он компилировался не в какую-то свою виртуальную машину, а напрямую в JavaScript — один к одному. То есть внутри браузера жил настоящий Smalltalk, но для системы он был просто обычным JS.

Что в нём было особенного: у Amber Smalltalk была своя встроенная среда разработки Helios — прямо в браузере. С браузером классов, инспектором объектов, отладчиком: всё как в «большом» Smalltalk. Ты мог открыть класс, поменять метод, нажать «сохранить» — и программа сразу начинала работать по-новому. Это и есть та самая инкрементальная разработка: не «написал — собрал — запустил», а «меняешь — видишь — правишь» в одном непрерывном потоке. Плюс он умел дружить с JavaScript-библиотеками: можно было спокойно тянуть всё богатство npm и использовать его из Smalltalk.

Где применяли: в экспериментах, в обучении, в прототипах — везде, где хотелось почувствовать, как это — программировать в духе старого доброго Smalltalk: очень объектно, очень динамично, очень «в моменте». Это был способ показать, что философия Smalltalk («всё — объекты, всё меняется на лету») может жить и в современном вебе.

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

24

Amiga — специально, персонально.

— это не язык, а целая вселенная: компьютер, который в конце 80 х и в 90 х был не про «посчитать цифры», а про сделать красиво. Представь не просто системный блок, а музыкальный инструмент, холст и кинокамеру в одном корпусе. На нём не столько «работали», сколько творили: рисовали, сочиняли музыку, собирали демо, где каждый кадр — это вызов железу.

Появилась Amiga в 1985 году (первая модель — Amiga 1000), её делала компания Commodore. Её фишка была в том, что она с самого начала проектировалась как мультимедийная машина: у неё были отдельные чипы для графики и звука, которые делали свою работу параллельно с процессором. То есть пока процессор думал, чип графики уже рисовал, а чип звука — играл. Это давало ту самую магию: плавные спрайты, параллакс-скроллинг, сложные звуковые эффекты — и всё это без тормозов, будто магия, а не математика.

Что в ней было особенного:

Чипсет OCS, потом ECS и AGA— это как три разных поколения волшебства. Каждый раз картинка становилась сочнее, цветов больше, эффекты сложнее. Для своего времени это был настоящий прорыв: не просто «квадратики на экране», а почти кино.

Blitter— отдельный чип, который «перекладывал» кусочки картинки. Он умел быстро двигать, копировать и накладывать изображения, и именно благодаря ему на Amiga получались такие красивые переходы и эффекты в демо.

Copper— сопроцессор, который умел синхронизироваться с лучом кинескопа. Представь: экран рисуется строка за строкой, и Copper мог в середине кадра сказать: «А теперь цвет палитры поменяй вот тут». Так рождались эффекты, которых на других компьютерах просто не умели делать.

Звуковой чип Paula— четырёхканальный цифровой звук. На нём собирали музыку, писали трекерные модули: это был такой «синтезатор в коробке», и целая культура музыкантов выросла именно на Amiga.

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

Чего не умеет (и не пыталась): не годится для тяжёлых вычислений, серверных задач или современного веба. Её сила была не в гигагерцах, а в умении делать максимум из того, что есть, — хитро, изящно, по-инженерному красиво. И ещё: она очень привязана к своему времени и к своим мониторам: ЭЛТ-экраны были частью её магии, потому что эффекты строились вокруг того, как луч бегает по стеклу.

25

Amiga E:

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

Появился он в начале 90-х как ответ на очень конкретную боль: на Amiga было море низкоуровневой работы (графика, звук, быстрые эффекты), а классические языки либо слишком тормозили, либо слишком далеко отстраняли от железа. Amiga E придумали так, чтобы ты мог писать в стиле привычного языка (с функциями, типами, циклами), но при этом иметь прямой доступ к аппаратуре — без лишних прослоек. Его автором был Уоррен Бёрч, и язык быстро стал любимцем демо-сцены и авторов утилит: там, где нужна была скорость и точный контроль, Amiga E был как раз тем самым инструментом.

Что в нём было особенного: он совмещал высокоуровневые конструкции с низкоуровневыми вставками. Ты мог спокойно описывать логику программы, а когда требовалось выжать максимум из чипсета OCS/AGA — написать кусок на ассемблере прямо внутри кода и вставить его одной директивой. Плюс у него была мощная система макросов и гибкая работа с памятью — всё ради того, чтобы код был и читаемым, и быстрым. И ещё одна важная деталь: он умел очень аккуратно работать с прерываниями и прямым доступом к видеопамяти — именно это делало его идеальным для демо, где каждый кадр и каждый байт на счету.

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

Чего не умеет: не годится для современных систем и больших проектов. У него нет ни кроссплатформенности, ни привычной экосистемы, ни поддержки новых стандартов. Он жёстко завязан на архитектуру Amiga и её особенности, поэтому вне этого мира почти бесполезен. Ещё одна сложность — порог входа: чтобы раскрыть его силу, нужно хорошо понимать устройство самой Amiga, иначе ты просто не сможешь использовать его главные преимущества.

26

AMPL — архитектор.

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

Появился он в середине 1980-х — его придумали Роберт Фрёрер и Дэвид Гей, чтобы свести вместе математическую модель и мощные алгоритмы поиска решений. Это был ответ на реальную боль: большие задачи оптимизации (расписание поездов, логистика, энергосети) слишком громоздки, чтобы писать их сразу на низкоуровневом коде, но слишком сложны, чтобы держать целиком в голове. AMPL стал тем самым языком, который позволяет сначала чётко сформулировать задачу на человеческом уровне, а потом отдать её решателю.

Что в нём было особенного:

Разделение модели и данных.Ты пишешь модель (цели, ограничения, переменные) отдельно, а данные (цифры, объёмы, расстояния) — отдельно. Это как рецепт и список продуктов: рецепт не меняется, если ты вместо яблок берёшь груши. Так большие проекты становятся понятнее и легче поддерживаются.

Математическая выразительность.В AMPL очень естественно записываются суммы, индексы, множества — всё то, что в обычных языках приходится собирать из циклов и массивов. Ты буквально пишешь формулы почти как в учебнике, и язык их понимает.

Связь с решателями.AMPL — не самостоятельный калькулятор. Он передаёт модель внешним мощным движкам (вроде CPLEX, Gurobi, CBC), которые умеют быстро искать оптимум. То есть AMPL отвечает на вопрос «что мы хотим?», а решатель — «как этого добиться?».

Где применяли: в промышленности и науке, везде, где нужно принимать решения с учётом ограничений. Логистика (как дешевле и быстрее развести грузы), энергетика (как оптимально распределить нагрузку), производство (как составить расписание станков), финансы (как собрать портфель с нужным балансом риска и доходности). Это рабочий инструмент больших компаний и исследовательских групп: там, где «перебрать все варианты» невозможно, а нужно найти лучшее из возможного.

Чего не умеет: не годится для обычных программ, игр, сайтов или скриптов. На AMPL не напишешь интерфейс, не обработаешь картинку, не сделаешь чат бота. У него вообще нет понятия «последовательность шагов» в привычном смысле: это декларативный язык, он описывает чтодолжно быть, а не какэто делать. Ещё он требует отдельного решателя: сам по себе AMPL ничего не считает, он только формулирует задачу.

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

27

Analytical Engine instructions — основано на записках Чарльза Бэббиджа.

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

Можно сказать что Analytical Engine — это не компьютер, а очень строгий, но умный дворецкий в огромном доме. Работал перфокартах— это записки, которые ему кидают на поднос. И он ничего не придумывает сам, он просто выполняет ровно то, что написано, шаг за шагом.

И вот какие записки там были:

«Запиши это число вот в эту шкатулку»— ты даёшь ему число и говоришь, в какой ящик его положить. Шкатулки — это память.

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

«Сложи эти два числа»или «Раздели»— в главном зале он крутит свои шестерёнки и считает. Там даже квадратный корень умел извлекать, долго и старательно.

«Передвинь цифры»— если надо умножить на десять, он просто сдвигает колёсики влево. Как будто запятую двигает, только механически.

«Положи результат обратно в шкатулку номер 7»— посчитал, записал, чтобы не забыть.

«Напиши ответ на бумаге»— была отдельная штука, которая выстукивала цифры на ленте, как старая пишущая машинка.

«Стоп, хватит»— останавливает весь этот грохот шестерёнок.

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

А самое хитрое — записок было два вида, и они работали в паре. Одна записка говорила: «Сейчас будем умножать». Вторая записка рядом шептала: «Умножай то, что лежит в шкатулке 5, на то, что в шкатулке 12, а ответ положи в шкатулку 1». Дворецкий брал обе сразу и делал.

28

APL — A Programming Language(«Язык программирования»).

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

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

Что в нём особенного: у APL свой собственный алфавит — куча необычных значков, которых нет на обычной клавиатуре. Каждый такой значок — это целая мини команда, которая умеет работать сразу со всем массивом данных. Например, вместо того чтобы писать цикл «пройдись по каждому числу в списке и прибавь к нему 5», в APL ты просто ставишь один символ — и он прибавляет 5 ко всем числам сразу. Это как дать одну команду всей толпе, а не шептать каждому по отдельности.

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

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

29

AppleScript — как способ договорится c Mac.

— Это язык помощник: он не столько пишет код, сколько помогает тебе договориться с твоим Mac. Представь, что компьютер — это очень старательный, но дотошный ассистент, который всё делает буква в букву. А AppleScript — это способ сказать ему простыми английскими фразами: «Открой этот файл», «Скопируй туда то», «Спроси у меня подтверждение» — и он честно всё выполнит.

Появился он в начале 90 х (в System 7) как часть идеи Apple: пусть даже не программист сможет автоматизировать рутину, не залезая в сложные внутренности системы. Его специально делали так, чтобы синтаксис был похож на обычный английский: вместо загадочных скобок и точек с запятой — почти разговорные команды.

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

Чего не умеет: не годится для больших сложных проектов, веб сервисов или игр. Он слишком привязан к macOS и к тем приложениям, которые умеют «понимать» скрипты. Если программа не поддерживает Apple Events, язык перед ней бессилен. Плюс из за своей «разговорности» он бывает медленным и не очень удобным для тяжёлых вычислений. А сегодня его потихоньку вытесняют более современные инструменты вроде Shortcuts и Automator, хотя в старых системах и скриптах он до сих пор живёт.

30

ARC: Automatic Reference Counting (автоматический подсчёт ссылок).

Представьте, что вы в очень аккуратной библиотеке, где у каждой книги есть карточка учёта. ARC — это библиотекарь, который сам следит: сколько людей сейчас держат книгу в руках. Если ноль — он тут же ставит её обратно на полку (освобождает память).

Где встречается:в языках Swiftи Objective C(то есть в разработке под iPhone и Mac). Раньше программист должен был сам писать: «освободи эту память», и если забывал — программа текла и падала. ARC взял эту рутину на себя: ты просто пишешь логику, а он тихо считает ссылки и чистит за тобой.

31

Arc: как язык программирования (Lisp семейство) — старая магия.

Есть ещё совсем другой Arc — маленький язык из семейства Лисп, созданный Полом Грэмом. Представь крошечную, но очень умную мастерскую, где все инструменты — это слова. В Лиспе (и в его мини версии ARC) даже код — это данные, а данные — это код. Ты можешь буквально писать программы, которые сами себя переписывают на лету. Это язык не для приложений, а для идей: быстро набросать концепцию, проверить мысль, сделать прототип.

32

AspectJ: чистая архитектура.

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

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

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

Сегодня его идеи живут дальше: в упрощённых механизмах вроде Spring AOP, в аннотациях, которые одной строчкой добавляют сложное поведение, и в общем подходе к разделению «что делает программа» и «как она себя ведёт». AspectJ показал, что можно навести порядок в повторяющихся деталях, не трогая саму суть — и эта мысль до сих пор помогает писать более чистый и понятный код.

33

Aspen для тестирования API (от Treblle)

Это нативное приложение под macOS для тестирования REST API с ИИ ассистентом. Его используют, чтобы быстро прогонять запросы, генерировать модели данных и спецификации OpenAPI, а также создавать код интеграции. ИИ внутри помогает не писать вручную типовые тесты и описания.

Для чего нужен:

ускорять тестирование API и прототипирование;

автоматически создавать модели данных и OpenAPI спецификации;

быстро собирать интеграционный код и коллекции запросов;

импортировать/экспортировать коллекции из Postman и обратно.

Сильные стороны:

локальная работа без отправки данных в облако (подход Zero Trust);

встроенный ИИ заметно сокращает рутину при работе с API;

нативная оптимизация под macOS и быстрый старт без регистрации;

удобная организация коллекций и совместная работа через обмен файлами.

Слабые стороны:

работает только на macOS — на Windows и Linux недоступен;

ИИ генерация не идеальна: код и спецификации часто требуют ручной доработки;

не подходит для сложных сценариев нагрузочного или интеграционного тестирования;

ориентирован на REST API: для GraphQL, gRPC и других протоколов функциональность ограничена.

34

Aspen как язык разметки для графов (для Neo4j)

Это небольшой DSL (язык разметки), который превращает простые текстовые описания в Cypher запросы для Neo4j. Формат выглядит как нарратив: (Liz) [knows] (Jack) превращается в корректный запрос к графовой базе данных.

Для чего нужен:

быстро создавать графы из частично структурированных заметок и описаний;

прототипировать графовые модели без глубокого знания Cypher;

конвертировать текстовые данные в графовую структуру для анализа.

Сильные стороны:

очень простой синтаксис: можно строить графы почти на естественном языке;

ускоряет прототипирование и визуализацию связей;

полезен для аналитиков и разработчиков, которые редко работают с Cypher.

Слабые стороны:

не годится для полноценной ETL обработки и сложных трансформаций данных;

плохо справляется с табличными данными (CSV, Excel): это не его сценарий;

ограниченная гибкость: сложно выразить сложные условия, агрегации и паттерны;

CLI интерфейс и отсутствие полноценного GUI усложняют работу в больших проектах.

35

Assembly: язык, который говорит с процессором напрямую.

Что это такое.Assembly (ассемблер) — это низкоуровневый язык программирования: каждая его команда почти один в один соответствует конкретной инструкции процессора. Вместо абстракций вроде «сложи два массива» тут пишут предельно конкретно: «возьми значение из регистра AX, прибавь к нему значение из ячейки памяти по адресу 0x1000, результат положи в регистр BX». Для перевода этого кода в машинные нули и единицы используют программу ассемблер. Важный нюанс: ассемблер всегда привязан к архитектуре — код для x86 не заработает на ARM, и наоборот.