Hacker News Digest

Медицинская компания недвижимости Medical Properties Trust (MPT) организовала секретную кампанию по подавлению критиков, включая расследование Wall Street Journal. CEO компании Эд Алдаг, влиятельный бизнесмен из Бирмингема, Алабама, был недоволен растущим вниманием к деятельности MPT. Компания, пожертвовавшая миллионы местным некоммерческим организациям, столкнулась с жесткими вопросами со стороны федерального правительства, инвесторов и СМИ.

MPT зарабатывает путем покупки больничных зданий и сдачи их в аренду операторам здравоохранения, включая Steward Health Care. Когда критики начали задавать неудобные вопросы о финансовых операциях компании, они столкнулись с давлением и наблюдением. Алдаг, регулярно фигурирующий в списках самых влиятельных бизнесменов города, лично руководил кампанией по дискредитации критиков, наняв частных детективов для сбора компромата.

• Роб разоблачил компанию без реальной ценности через анализ несоответствующих цифр и предсказуемый вывод.
• Ситуация параллельна LBO (выкупам с плечом) частного капитала, где скупают активы для их распродажи.
• Критикуется практика скупки больниц и клиник с последующим закрытием специализированных услуг.
• Частный капитал и коммерческие похоронные услуги названы "злом" из-за такой деятельности.

Раф Костер утверждает, что геймдизайн на самом деле прост, если понимать суть удовольствия от игр. Он критикует поверхностное толкование "fun", отмечая, что радость от конфетти и адреналин от свободного скалолазания — принципиально разные вещи, хотя оба могут приносить удовольствие. Ключевая идея из его книги "Theory of Fun" заключается в том, что полезным для дизайнера является лишь "мастерство решения проблем". Это означает, что даже болезненные или пугающие активности, как покорение скалы, попадают в категорию игровых, если они развивают навыки. Важно, что удовольствие часто приходит ПОСЛЕ преодоления, а не во время процесса.

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

• Дискуссия вращается вокруг статьи Рафа Костера о дизайне игр, но участники быстро уходят в сторону: от обсуждения "фан" как прогресс в предсказании, до споров о том, что такое "фан", до обсуждения того, что такое "простой" и "легкий" в контексте дизайна игр, и до обсуждения того, что такое "игра" и "игровой дизайн".

Фраза "предпочитай композицию наследованию" стала клише, но её происхождение точно известно — это второй принцип объектно-ориентированного дизайна из книги "Design Patterns" "банды четырёх" (Gamma, Helm, Johnson, Vlissides). Оригинальная формулировка гласила: "Favor object composition over class inheritance". Авторы противопоставляли наследование ("белая коробка", где подкласс видит детали реализации) и композицию ("чёрная коробка", где объект взаимодействует только через интерфейс). Однако этот аргумент зависит от языка: в Java можно ограничить видимость для подклассов, а в Smalltalk и Python доступ к внутренностям возможен через рефлексию.

Более весомый аргумент касается гибкости: наследование статично и определяется на этапе компиляции, что затрудняет изменение, тогда как композиция динамична и позволяет заменять компоненты во время выполнения. Это меняет архитектурные зависимости — система опирается на отношения объектов в рантайме, а не на иерархию наследования. В контексте современного тренда к статической типизации и проверке компилятором, этот подход требует баланса. Интересно, что Barbara Liskov ещё в 1987 предлагала альтернативу: вместо жёсткой иерархии позволять полиморфным модулям использовать любые типы с нужными операциями, без формального отношения подтипа.

• Inheritance can lead to complex, fragile hierarchies and "co-recursion" issues where subclass methods override parent methods in unpredictable ways.
• Composition is generally preferred for flexibility and maintainability, as it avoids tight coupling and allows "black box" reuse without exposing implementation details.
• Both approaches have valid use cases: inheritance suits "is-a" relationships with clear invariants, while composition excels at combining independent behaviors ("has-a").
• Modern best practices favor interfaces + composition to decouple polymorphism from behavior sharing, reducing brittleness compared to deep inheritance chains.
• Over-reliance on inheritance often stems from cargo-culting; it should be reserved for cases where it genuinely simplifies the design rather than complicating it.

Разработка ПО не может быть конвейерным производством, поскольку дизайн возникает через реализацию, а не наоборот. LLM снова подталкивают нас к этой ошибочной аналогии, игнорируя фундаментальную природу программирования, где экспериментирование и обратная связь от кода являются главным проводником. Как отмечает автор, "люди, пишущие код, не просто 'исполнители'; они играют центральную роль в обнаружении правильного дизайна".

LLM полезны как партнеры для генерации идей и начальной настройки, но часто создают код с ошибками, не соответствующими глубинным намерениям. Они особенно эффективны на этапе bootstrap-проекта: настройке окружения, создании начальных файлов и зависимостей, снижая порог для экспериментов. Однако после "Hello World" начинается настоящая работа, требующая глубокого понимания.

Существует фундаментальный цикл обучения: наблюдение и понимание, формулировка гипотез, экспериментирование и рефлексия. Этот цикл остается неизменным независимо от инструментов - от простого текстового редактора до продвинутого ИИ. LLM могут ускорить отдельные этапы, но не могут заменить необходимость непрерывного обучения через практику.

• Ценность разработчика заключается в понимании предметной области, архитектуры и умении принимать решения, а не в самом коде как артефакте решения.
• Разработка ПО разделяется на творческие задачи (требующие опыта и глубокого понимания) и рутинные (которые хорошо автоматизируются, включая boilerplate).
• LLMs полезны для генерации кода, но могут создавать ошибки и не всегда соответствовать глубинному замыслу, требуя тщательной проверки.
• Автоматизация через LLMs вызывает опасения, что разработчики могут потерять понимание "существенной сложности" (бизнес-логика) в ущерб "случайной сложности" (технические детали).
• Альтернативные подходы, такие как визуальное программирование (drag-and-drop) и метапрограммирование, рассматриваются как потенциальные решения для повышения абстракции.

К сожалению, я не вижу полного текста статьи для создания пересказа. В предоставленном фрагменте только заголовок "Rob Ricci: 'While cleaning a storage room, our staff found th…'" и ссылка на discuss.systems, но отсутствует основное содержание.

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

• Восстановление ленты Unix V4 (1973 г.) — первой версии, написанной на C, — может дать нам единственный сохранившийся образец кода той эпохи.
• Проект, в котором участвуют исследователи из университета Юты, подразумевает извлечение битовой копии с ленты и последующее распространение ее через GitHub под лицензией BSD-2-Clause.
• Поскольку лента хранилась в сухом климате, шансы на то, что данные уцелели, высоки; однако никто не может гарантировать, что 50-летняя лента 9-дорожечной записи не содержит ошибок.
• Даже если в итоге окажется, что часть данных утрачена, сообщество может в конце концов получить хоть какие-то фрагменты кода на C, что само по себе уже является сенсацией.
• Вопрос о том, какие именно части кода первоначально были потеряны, остается открытым — возможно, они были утеряны еще в 1970-х.

Мне не удалось найти основное содержание статьи в предоставленном HTML-коде. Страница содержит только навигационное меню и структуру сайта Королевского астрономического общества, но не текст самой новости о замедлении расширения Вселенной. Для создания точного пересказа мне нужен фактический контент статьи, включая основные выводы исследования, данные и интерпретации ученых. Если вы предоставите текст статьи, я смогу создать краткий пересказ в соответствии с вашими требованиями.

• Предположение, что сверхновые Ia типа не зависят от возраста их предшественников, оказалось неверным: яркость корректируется на 0.8 магнитуды, что эквивалентно 0.2 звёздных масс.
• Это означает, что космологические измерения, основанные на SN Ia, могут быть систематически смещены на 0.2 звёздных масс.
• Возможно, что это смещение может быть скомпенсировано, но это требует дополнительных параметров, что может привести к переоценке темной энергии.
• Все остальные космологические наблюдения (CMB, BAO и т.д.) согласуются с моделью, в которой темная энергия не исчезает, но не с моделью, в которой она исчезает.

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

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

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

Whenever someone argues the uselessness or redundancy of a particular word, a helpful framework to understand their perspective is "Lumpers vs Splitters" : https://en.wikipedia.org/wiki/Lumpers_and_splittersAn extreme caricature example of a "lumper" would just use the word "comp

Troy Hunt объявил о добавлении в Have I Been Pwned 2 миллиардов уникальных email-адресов (точнее 1,957,476,021) и 1,3 миллиарда паролей, из которых 625 миллионов ранее нигде не встречались. Это крупнейшая база данных утечек, которую когда-либо обрабатывали. Данные поступили из двух источников: логов вредоносного ПО, собирающего данные с зараженных устройств, и списков для подбора паролей, полученных из других утечек. Hunt отмечает, что такие списки становятся "ключами от замка" из-за привычки пользователей использовать один и тот же пароль на разных ресурсах.

Для проверки данных Hunt проанализировал собственные старые email-адреса и обратился к подписчикам. Один пользователь подтвердил, что в базе находились как его старые, так и текущие пароли. Особенно показателен случай, когда человек использовал простой пароль, состоящий из другого пароля с добавлением в конце "!!". Это подтверждает распространенную практику создания слабых вариаций паролей, что делает пользователей уязвимыми при утечках данных.

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

Nice work, thanks for sharing!Here's my feedback..1. Please, consider to always include the latest What Are You Working On posts. For instance, this latest one posted 16 hours ago is not included yet (https://news.ycombinator.com/item?id=45869146).2. Also, it may be better to inc