[Перевод] Ouroboros — язык программирования почти без синтаксиса

От переводчика: статья немного сокращена по сравнению с оригиналом, исключён раздел об этимологии слова "Ouroboros", а также полные каламбуров отсылки автора к латинским, прочим романским и английским корням. Далее - от автора. Можно ли создать язык программирования, в котором нет синтаксиса? Кажется, что это чистое противоречие. Вся суть языков программирования заключается в синтаксисе, плюс немного в генерации и оптимизации кода, настройке сред выполнения и т.д. Но с точки зрения программиста — именно синтаксис самая важная часть языка. Когда вы приступаете к изучению нового языка программирования, вам обязательно придётся уделить время освоению синтаксиса. Можно ли просто избавиться от синтаксиса или, как минимум, предельно его упростить? Другой вариант — можно ли сделать синтаксис произвольным, чтобы программист, пишущий код, мог сам для себя его определять? Именно этих целей мы попытались достичь, создав язык Ouroboros. Его синтаксис максимально прост. Настолько, что в этом языке даже не предусмотрен синтаксический анализатор. В нём есть только лексический анализатор, код которого составляет 20 строк.

https://habr.com/ru/articles/974074/

#Java #интерпретатор #эксперимент #синтаксис

Кто угодно может пнуть мёртвого льва

Кто угодно может пнуть мёртвого льва. Мёртвый лев не рыкнет на наглеца. Мёртвый лев не откусит ему ногу «по самое не хочу», хотя стоило бы. Лев мёртв, и теперь его может пнуть каждый ишак, что конечно же не показывает превосходство ишака над львом. Эта статья будет полна негодования и ненависти. Кровь ещё закончила кипеть от негодования. Но, разумеется, помимо эмоций будут и сухие объективные факты, немножко исследования и расстановка точек над i. В интернете кто-то не прав... опять... Существует целый ряд инструментов, технологий и вообще вещей, которым по какой-то непонятной вселенской несправедливости не повезло : нашлась масса непонятных людей, которые по какой-то необъяснимой причине начали распускать про эти инструменты/технологии/вещи разные небылицы, идиотские фейки, слухи и прочий порочащий репутацию «компромат». Можно не переживать, если речь идёт о технологии, которая находится «на пике» — у неё будет большое community и правда восторжествует. Совсем другое дело, когда речь идёт о чём-то, что далеко не на пике, чья минута славы в прошлом (возможно даже давно в прошлом) — здесь мёртвый «лев» не может дать сдачи, и что самое обидное, что в какой-то степени «лев» сейчас мёртв отчасти и потому, что ещё при его жизни началось необоснованное распространение всяких бредовых поверий и мифов про него. И сегодня речь пойдёт об одном из таких случаев.

https://habr.com/ru/articles/973594/

#Basic #QuickBasic #Visual_Basic #интерпретатор #трансляция #x86 #фейки

ESPB — брат WASM для ESP32

Привет, Хабр! Меня зовут Андрей. По основной профессии я инженер-проектировщик, а программирование для меня — это хобби и инструмент, помогающий в работе. Это моя первая публикация, и я хочу представить проект, идея которого родилась после долгих поисков способа динамически подгружать код в работающее устройство на ESP32. Думаю многие проводили изыскания в данном направлении. Всё началось с прикладной задачи, опять же в качестве - а смогу ли? Было разработано и собрано устройство для переключения насосов и управления системой подпитки для индивидуального теплового пункта. Оно подключается к телефону для мониторинга и настройки. В какой-то момент захотелось иметь возможность дополнять его логику новыми схемами управления прямо с телефона, не перекомпилируя и не перепрошивая основное ядро. И понеслась...

https://habr.com/ru/articles/969400/

#ESPB #esp32 #vm #интерпретатор #wasm

Добавляем MapReduce в этот наш SQL: генераторы на основе курсоров

Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath. Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно. Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно! Давайте узнаем, как именно

https://habr.com/ru/articles/958362/

#sql #etl #apache_spark #java #hadoop #big_data #big_data_solutions #big_data_tools #интерпретатор

[Перевод] Мифы и легенды о производительности Python

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy . Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy , который, возможно, станет способом реализации сверхбыстрого Python. Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

https://habr.com/ru/companies/ruvds/articles/935046/

#интерпретатор #оптимизация_кода #jitкомпилятор #ruvds_перевод

[Перевод] Мифы и легенды о производительности Python

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy . Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy , который, возможно, станет способом реализации сверхбыстрого Python. Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

https://habr.com/ru/companies/ruvds/articles/935046/

#интерпретатор #оптимизация_кода #jitкомпилятор #ruvds_перевод

Обратная сторона Babel: как микроскопические языки помогают в изучении больших

В этой статье рассказывается, как крошечные, экспериментальные языки программирования, размером порой меньше 100 строк, могут неожиданным образом углубить понимание сложных промышленных языков. Будет показано, как микроязыки раскрывают суть концепций, скрытых в слоистых абстракциях Java, Rust или C++. Много примеров, кода и немного лирики.

https://habr.com/ru/articles/910864/

#микроязыки #миниязыки #ast #компилятор #парсинг #интерпретатор #обучение #языковая_архитектура

DSL для интерактивных рассказов: как я написал язык, чтобы придумывать истории, а не кодить

Многие разработчики мечтают о проектах, в которых можно совместить любовь к программированию и нарративу. В этой статье рассказывается о создании собственного DSL (domain-specific language) для интерактивных историй — от формализации сценарных структур до реализации интерпретатора на Python. Много кода, много боли, немного магии.

https://habr.com/ru/articles/907798/

#dsl #интерактивный_рассказ #парсинг #интерпретатор #генерация_кода #python

Почему мы отказались от выражения «assert» в Python

В текущем проекте на Python мы практически полностью отказались от использования выражений с ключевым словом assert , и в этой статье я расскажу почему. Рассмотрим кейсы где использование выражений assert уместно, а где оно может выстрелить в ногу, и как этого избежать.

https://habr.com/ru/articles/876170/

#python #assert #exception #исключения #pytest #pydantic #линтер #интерпретатор #баги #ошибки

Как я собственный язык на КуМире писал

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

https://habr.com/ru/articles/872680/

#кумир #русский_алгоритмический_язык #интерпретатор #разработка_языков_программирования