Hacker News Digest

Автор изучает необычный стиль написания кода Артура Уитни, создателя языков программирования A, K, Q и высокопроизводительных баз данных kdb и Shakti, используемых в финансовой индустрии. Основное внимание уделено компактному интерпретатору языка K размером всего около 50 строк на C, который демонстрирует уникальный подход Уитни к программированию. Код насыщен макросами и использует необычные синтаксические конструкции C, что делает его трудным для понимания, но потенциально эффективным для быстрого восприятия всей логики целиком.

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

• Код стиля Артура Уитни (Arthur Whitney) — это микро-DSL на препроцессоре C, который вдохновлялся APL; читать его лучше всего, если вы знакомы с APL, иначе он может казаться нечитаемым.
• Подход «сначала напиши, потом сделай это читаемым» противоположен современному подходу «сначала сделай это читаемым, потом напиши код».
• Сторонники и противники такого стиля спорят о том, является ли это «искусством» или «самообфускацией»; в то время как другие считают, что это просто вопрос привычки и что читаемость может быть улучшена с помощью современных инструментов.
• Некоторые комментаторы отмечают, что стиль кода Уитни может быть трудным для чтения, но он также может быть более выразительным и эффективным для тех, кто привык к APL.
• В конце концов, обсуждение пришло к выводу, что важно не только то, как стиль кода влияет на читаемость и поддерживаемость, но и то, как команда работает вместе, чтобы поддерживать и развивать код в течение длительного времени.

Helion — это высокоуровневый язык для создания производительных и переносимых ML-ядер, разработанный командой PyTorch в Meta. Он разрешает конфликт между производительностью и удобством, компилируя Python-встроенный DSL в автоматически настраиваемый код Triton. Helion создает новый уровень абстракции, сочетающий простоту PyTorch с производительностью низкоуровневых языков, автоматизируя рутинные задачи вроде индексации тензоров и управления памятью. Это позволяет разработчикам сосредоточиться на алгоритмической логике, а не на аппаратно-специфичных деталях.

Текущие языки вынуждают выбирать между контролем и производительностью: CUDA дает максимум контроля, но требует значительных усилий; Triton — шаг вперед, но все еще требует ручной настройки; PyTorch прост, но ограничен в детальном контроле. Программная модель Helion, описываемая как "PyTorch с тайлами", минимизирует шаблонный код и использует знания разработчиков в PyTorch. Типичное ядро Helion состоит из двух взаимодополняющих частей, что упрощает создание правильных и эффективных ядер.

• Helion позиционируется как более высокоуровневая альтернатива Triton, упрощая написание кода за счет автоматического автотюнинга, в отличие от других DSL (Gluon, CuTe), которые предлагают больше контроля на низком уровне.
• Основные проблемы включают длительный автотюнинг (до 10+ минут), отсутствие полноценной поддержки Python-отладки (автодополнение, точки останова) и сложность выбора между множеством технологий (Triton, Gluon, JAX Pallas и др.).
• Несмотря на рост высокоуровневых фреймворков, низкоуровневые оптимизации остаются критичными для новых архитектур моделей (например, FlashAttention, MXFP4) и аппаратных платформ (NVIDIA, AMD).
• Споры о релевантности CUDA: мнения расходятся от его "устаревания" до сохранения доминирующей роли в экосистеме на годы вперед из-за зрелости инструментов и сообщества.
• Пользователи отмечают, что Helion может расширить круг разработчиков, способных писать эффективные ядра, но сомневаются в его преимуществах перед Triton/Gluon без явного выигрыша в производительности или простоте.

Представлен Pipelex - новый open-source язык, созданный специально для AI агентов с целью разработки и выполнения повторяющихся AI рабочих процессов. Проект призван упростить создание сложных автоматизированных систем с использованием искусственного интеллекта, предоставляя разработчикам специализированный инструмент для реализации своих идей.

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

• Declarative workflow DSL (Pipelex) позволяет описывать пайплайны на высоком уровне, что делает его более читаемым и удобным для совместной работы между техническими и нетехническими участниками.
• В отличие от BAML, Pipelex фокусируется на том, чтобы предоставить DSL для описания логики, а не только для LLM вызовов.
• Пользователи могут запускать пайплайны как локально через CLI, так и удалённо через API сервер, который также доступен как Docker образ.
• Поддержка MCP серверов в разработке, но уже сейчас можно использовать PipeFunc для вызова любых Python функций и инструментов.
• Сообщество приветствует вклад в развитии и интеграцию с другими инструментами и сервисами.

Ruby блока — это фундаментальная концепция, делающая язык выразительным и читаемым. Автор подчеркивает, что даже конструкции вроде it в RSpec являются методами с блоками, что открывает новые горизонты понимания языка. Блоки позволяют создавать мини-языки, расширяя встроенные типы — например, добавляя методы к Integer для создания цепочек вроде 30.minutes.from_now.

Применение блоков разнообразно: от управления ресурсами (как в File.open) до создания DSL. В отличие от Python, где управление ресурсами требует специального ключевого слова with, в Ruby это делается через методы, принимающие блоки. Автор демонстрирует, как можно создать систему управления задачами с помощью блоков, показывая их гибкость и мощь. Понимание этой концепции, по мнению автора, ключ к по-настоящему глубокому пониманию Ruby.

• Автор написал статью, чтобы подчеркнуть повсеместное использование блоков в Ruby.
• Он выражает большой интерес и восхищение тем, как Ruby интегрирует блоки в язык.
• Статья служит акцентом на важности и удобстве блоков в Ruby.

Проект предлагает необычный взгляд на C++ как на интерпретируемый язык, оспаривая традиционное представление о нём исключительно как о компилируемом. Автор демонстрирует, что с помощью современных инструментов и техник C++ можно использовать в интерактивном режиме, подобно Python или JavaScript. Это открывает возможности для быстрого прототипирования и экспериментальной разработки без необходимости полной перекомпиляции.

Ключевая идея заключается в использовании JIT-компиляции и REPL-окружений, что делает C++ более гибким и доступным для исследовательских задач. Такой подход может сократить время разработки и упростить тестирование идей, сохраняя при этом все преимущества производительности и низкоуровневого контроля, характерные для C++.

• Участники обсуждают техническую реализацию проекта, предполагая использование метапрограммирования шаблонов, DSL и специальных флагов компилятора (GCC/Clang).
• Высказывается недоумение и замешательство по поводу принципов работы проекта, а также желание получить более подробное текстовое объяснение.
• Предлагаются альтернативные инструменты для интерпретации C++ (Clang-Repl, Xeus cling, AngelScript).
• Несколько пользователей делятся положительными впечатлениями от видео и творческого подхода автора.
• Один из комментариев содержит ироничное замечание о значении слова "based" в данном контексте.

Навигационное меню GitHub с разделами:

- Платформа: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
- Решения: для предприятий, малых команд, стартапов, некоммерческих организаций
- Ресурсы: статьи по AI, DevOps, безопасности, разработке ПО
- Open Source: спонсоры, проекты, репозитории
- Enterprise: платформа, дополнения
- Цены

Поиск кода, репозиториев, пользователей, issues и pull requests. Возможность сохранения поисковых запросов.

• NVIDIA Tilus представляет собой низкоуровневый инструмент для контроля над регистрами, возможно, как ответ на Triton, который поддерживает AMD и другие ускорители, угрожая экосистеме CUDA.
• Название Gluon уже используется несколькими проектами, включая язык для ML от Amazon/Microsoft, UI-тулкит для Java и встраиваемый язык для Rust, что создает путаницу.
• Gluon от NVIDIA рассматривается как сходный с их же CUTE DSL, что указывает на convergence к оптимальному дизайну Python-based DSL для программирования ядер.
• Мнения разделились: одних смущает, что «язык» остается кодом на Python, требующим трассировки, другие считают такой подход на основе AST-walker эффективным.
• Появление Gluon связано со сложностями Triton в достижении высокой эффективности на новых архитектурах NVIDIA, таких как Blackwell.
• NVIDIA разрабатывает множество DSL, что свидетельствует о их беспокойстве из-за открытых и портируемых альтернатив CUDA.
• На экосистему CUDA оказывают давление крупные компании, разрабатывающие собственные чипы для AI, чтобы избежать зависимости от NVIDIA.

ASCIIFlow — онлайн-инструмент для рисования ASCII-диаграмм прямо в браузере.
Быстро создаёт блок-схемы, схемы сетей и другие текстовые чертежи без установки ПО.

• Пользователи обсуждают, что экспорт «ASCII» на деле выдаёт UTF-8, но из-за скрытых преобразований браузера/ОС это трудно проверить.
• Упомянуты похожие инструменты: Monodraw, d2 (новый ASCII-режим), graph-easy и ещё один, где диаграммы задаются собственным DSL.
• Популярный запрос — возможность рисовать без мыши: писать структуру текстом и получать ASCII-арт.
• Есть жалобы, что «Select & Move» работает не для целых фигур, а только для отдельных сегментов линий.
• Приведены ссылки на предыдущие обсуждения проекта на HN (2014–2022).

• Главная
• Чат-демо
• Потоковая передача
• Реализации
• Спецификация
• GitHub

• Пользователи спорят: зачем превращать Markdown в React/Svelte/Vue-компоненты, если можно сразу выдавать HTML.
• Автор отвечает: цель — безопасный runtime-DSL для LLM, чтобы чат-боты могли «рисовать» интерактивные формы без сборки.
• Критика: без сборки не получается оптимизированный код, ломается после нескольких кликов, не масштабируется.
• Некоторые сравнивают проект с MDX и mdwiki, предлагают компилировать на этапе сборки или использовать Web Components.
• Автор признаёт проблемы и анонсирует v2: нативные custom elements + тонкие обёртки под React/Svelte/Vue.

POML — язык разметки Prompt Orchestration Markup от Microsoft.
Проект в открытом доступе на GitHub: microsoft/poml.

• Назначение: структурировать, версионировать и переиспользовать промпты для LLM.
• Формат: YAML-подобный, читаемый человеком и парсером.
• Возможности:
  – параметризованные шаблоны,
  – условные ветвления,
  – импорт фрагментов,
  – метаданные (автор, версия, модель).
• CLI: poml build → компиляция в чистый текст, poml test → прогон с примерами.
• CI/CD: экшены GitHub для валидации и деплоя промптов.
• Интеграции: Python SDK, VS Code-расширение, экспорт в OpenAI, Azure, Bedrock.

• POML — это XML-подобный DSL от Microsoft Research для «view-слоя» промптов, но выглядит как «JSX, только хуже» и заставляет писать код в строках.
• Участники сравнивают его с YAML-промптами GitHub, BAML (TypeScript-подобные схемы), Jinja и обычным XML, споря о необходимости новой библиотеки.
• Критика: один контрибьютор при $3T-спонсоре, нет SDK для .NET/C#, лишний tooling, «IP squatting», циклы в XML выглядят как костыль.
• Ирония: из-за потребности в точности неформальные LLM-промпты всё структурнее, как юридические документы.