Hacker News Digest

Проектирование языка программирования — это итеративный процесс, включающий четыре фазы, которые необходимо повторять многократно. При реализации компилятора часто обнаруживается, что некоторые части языка спроектированы некорректно, что требует возврата к предыдущим этапам. Успех в создании языка зависит от глубоких знаний в трех ключевых областях: программных парадигмах (императивной, декларативной, объектно-ориентированной и др.), концепциях языков (последовательность выполнения, типизация, параллелизм и др.) и знакомстве с существующими языками. Автор рекомендует изучить десятки языков — от Python и Smalltalk до Haskell и Rust, а также ознакомиться с классическими работами по проектированию языков.

• Предложение включить Raku в список языков из-за встроенных грамматик для парсинга и объектно-ориентированной природы.
• Вопросы о компиляции целевых языков, их пайплайне сборки и контексте выполнения.
• Размышления о создании нового языка: необходимость, наличие ресурсов/команды, сроки выпуска MVP.
• Критика исходного материала как "AI slop", рекомендация использовать "programming language checklist".
• Споры об AI-происхождении текста (находки 2017 года) и упоминание забавного элемента (SnekQL).

Архив Эдсгера Дейкстры содержит более тысячи его неопубликованных рукописей, известных как "EWDs", которые он рассылал десяткам получателей на протяжении более 40 лет. Дейкстра, один из основоположников компьютерных наук (1930-2002), внёс фундаментальный вклад в алгоритмы, языки программирования, операционные системы и формальную верификацию, за что получил высшую награду ACM - премию Тьюринга. Большинство его работ остались недоступными для широкой публики, пока не были оцифрованы и представлены на этом сайте в виде PDF-документов.

Исходные материалы, включая дневники и переписку, хранятся в Техасском университете. Архив включает несколько индексов для поиска, а также растущее количество транскрибированных текстов и переводов на разные языки. Дейкстра часто возвращался к уже обсуждавшимся темам, предлагая новые взгляды или более точные формулировки, что отражено в системе перекрёстных ссылок между документами.

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

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Мне не хватает содержимого статьи, которую нужно пересказать. Вы предоставили только фразу "What the hell have you built", но не сам текст Hacker News.

Чтобы я мог создать точный и ёмкий пересказ на русском языке в формате Markdown (~170 слов в двух абзацах), пожалуйста, предоставьте содержимое статьи, которую вы хотите, чтобы я обработал.

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

Radiant Computer представляет собой проект по созданию персонального компьютера с нуля, свободного от исторического багажа и влияния Big Tech. Авторы считают, что современная вычислительная индустрия движется к менее свободному миру, где системы проектируются вокруг моделей вовлеченности и слежки, а не потребностей пользователей. Их система предлагает альтернативу: без браузера, с собственной сетью, напоминающей ранний интернет, без соцсетей, скриптов и трекеров.

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

• Проект Radiant Computer представляет собой попытку создать новую вычислительную платформу с нуля, включая ОС, язык программирования и даже аппаратное обеспечение, но пока не представлено никаких конкретных результатов.
• Критики указывают на то, что проект выглядит как вейпор, не предлагает никаких конкретных технических деталей и не демонстрирует прогресса.
• Некоторые комментаторы выражают сомнение в способности команды реализовать заявленные амбиции, учитывая, что они не предоставляют никакой конкретной информации о текущем состоянии дел.
• Некоторые комментаторы также отмечают, что проект не предлагает никаких конкретных технических деталей, что делает его похожим на вейпор.
• Некоторые комментаторы также отмечают, что проект не предлагает никаких конкретных технических деталей, что делает его похожим на вейпор.

Rust-разработчик взглянул на Vec<T> и обнаружил, что вместо ожидаемых трёх полей ptr, len, capacity внутри структура скрыта целая иерархия обёрток: RawVec, RawVecInner, Unique, NonNull и NonNull<T> — всё ради безопасности и гибкости. Это вызвало вопрос: зачем такая сложность, если можно было обойтись тремя полями? Ответ оказался в том, что каждый слой добавляет безопасность и абстракцию, защищая от ошибок с указателями.

• Обсуждение развивалось вокруг того, что стандартная библиотека Rust предоставляет безопасные абстракции над низкоуровневыми деталями, но при этом не скрывает их полностью, и что это влияет на то, как код на Rust выглядит и ощущается.
• Участники обсуждали, что сложность реализации Vec в стандартной библиотеке Rust отражает компромисс между безопасностью и производительностью, и что это влияет на то, как разработчики думают о системе типов и управлении памятью в Rust.
• Также обсуждались вопросы о том, как документация и обсуждение в сообществе Rust может быть улучшена, включая сравнение с C++ и обсуждение того, как язык программирования влияет на то, как мы думаем о коде.
• Участники также затронули тему того, что сложность реализации может отпугнуть новичков, но что это может быть уменьшено путем улучшения документации и обучающих материалов.
• В конце концов, обсуждение завершилось тем, что участники сошлись на том, что хотя Rust и предоставляет мощные и безопасные абстракции, это не делает его легким для новичков без качественного обучения и документации, и что это может быть улучшено.

Forth — это уникальный язык программирования 1970-х годов, который до сих пор используется в некоторых нишевых приложениях. Его ключевая особенность — работа со стеком: числа помещаются на стек, а операции (например, +) забирают верхние элементы и возвращают результат. Например, последовательность 5 2 + 10 * вычисляет выражение 10 * (5 + 2) без скобок благодаря обратной польской записи.

Определения новых слов создаются через : и ;. Например, : foo 100 + ; добавляет 100 к верхнему элементу стека. Forth требует точного соблюдения пробелов: +; будет воспринято как одно слово, а не два. Это минималистичный язык, который учит мыслить иначе, расширяя программистский кругозор.

• Участники делятся ресурсами для изучения Forth (Jones Forth, видео, книга) и отмечают его ценность для расширения кругозора и создания собственных языков.
• Обсуждаются технические ограничения и нишевое применение Forth (встраиваемые системы с малыми ресурсами), а также его уникальные особенности, такие как использование двух стеков.
• Критикуется автоматическая прокрутка на странице проекта, делающая его неудобным в Safari и Firefox, но отмечается работоспособность с отключенным JS.
• Пользователи делятся впечатлениями от экспериментального проекта FXYT, предлагают улучшения (демо-программы в интерфейсе) и задают вопросы по реализации (например, рисование круга).
• Высказывается мнение о непрактичности Forth для создания крупных приложений и сложности решения базовых задач (например, чтения строк из файла).

AI-кодинг: компилятор, а не магия

LLM — это компилятор: английский вместо C, выхлоп — код.
Работает лишь для тривиальных задач; чуть сложнее — приходится писать спецификации длиннее самого кода.
Английский не имеет спецификации, выхлоп недетерминирован, изменение в одном месте ломает всё.
Казаться быстрее на 20 %, реально медленнее на 19 % (arxiv.org/abs/2507.09089).

«ИИ заменит программистов» так же, как компиляторы заменили ассемблер и Excel — бухгалтеров: инструмент, а не чудо.
Миллиардные инвестиции в «vibe coding» — повторение провала self-driving.
Вместо хайпа стоит делать лучшие языки, компиляторы и библиотеки.

• Опытные разработчики спорят: кто-то экономит часы на рутине, кто-то теряет скорость из-за «зайцев» и недопонимания кода.
• AI-инструменты (автодополнение, Claude Code, Cursor) дают +20–50 % к старту, но требуют навыка «prompt-инженерии» и постоянного контроля.
• «Вайб-кодинг» без понимания архитектуры быстро даёт MVP, но приводит к техдолгу и невозможности поддержки.
• Независимые исследования пока не подтверждают значительного ускорения для сеньоров в сложных кодовых базах; выгода заметнее в шаблонных CRUD-задачах.
• Рынок и инвесторы толкают AI-хайп из-за страха пропустить «новое интернет», а не из-диоказанной эффективности.