Hacker News Digest

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

Accessors.jl построен вокруг концепции линз, позволяющих получать доступ или заменять глубоко вложенные части сложных объектов. Линзы создаются с помощью макроса @optic или напрямую, а затем комбинируются операторами opcompose, ⨟ или ∘. Важная особенность — неизменяемость: при изменении создается новая копия объекта, а не мутируется оригинал.

Для реализации линз требуется определить всего две функции: set(obj, lens, val) и вызов lens(obj), которые должны удовлетворять трем законам линз. Первый закон гарантирует, что полученное значение совпадает с установленным; второй — что установка существующего значения не изменяет объект; третий — что последнее изменение имеет приоритет. Для сравнения значений вместо == могут использоваться isequal или ≈, особенно для типов с особыми правилами сравнения, таких как Float64.

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

Компиляция Zig становится значительно быстрее благодаря многолетней работе над оптимизацией компилятора. Например, сборка скрипта build.zig в версии 0.15 заняла всего 1,7 секунды против 7,2 секунд в версии 0.14. Полная сборка проекта Ghostty без кеша сократилась с 41 до 32 секунд, даже с использованием LLVM.

Особенно впечатляет скорость инкрементных сборок: пересборка библиотеки libghostty-vt после изменения одной строки теперь занимает менее секунды (975 мс против 2,9 секунд ранее). Это уже ощутимо ускоряет рабочий процесс, а в будущем, с отказом от LLVM и внедрением инкрементной компиляции, результаты станут ещё лучше — ожидаются миллисекундные задержки.

• LLVM рассматривается как ловушка из-за сложности тонкой настройки финальных оптимизаций и линковки, несмотря на преимущества в скорости начальной разработки и поддержке платформ. Cranelift и другие бэкенды могут стать альтернативой.
• Zig фокусируется на скорости компиляции для разработки, используя собственный бэкенд для debug-сборок (x86_64) и LLVM для релизов. Есть баги, но инструментарий ценится за простую кросс-компиляцию и статическую линковку.
• Быстрая компиляция (TCC, Go, Vlang) важна для итеративной разработки, но trade-off с оптимизацией кода неизбежен. Интерпретаторы или JIT-компиляция (Julia) предлагают альтернативы для интерактивности.
• Интеграция Zig с системами сборки (Bazel) возможна через правила, но Turing-полные скрипты сборки могут усложнить кеширование. Библиотеки часто обходятся без кастомных скриптов.
• Поддержка платформ (OpenBSD) требует доработки низкоуровневого IO (kqueue). Статическая линковка зависимостей в Zig упрощает деплой, но динамические библиотеки (libc, GUI) остаются.

После многолетнего активного использования Julia для анализа данных и разработки пакетов автор перестал рекомендовать язык из-за серьёзных проблем с корректностью и композируемостью. В экосистеме Julia наблюдается высокая частота критических ошибок, которые проявляются даже в базовых операциях: например, функции sum! и prod! иногда молча возвращают неверные результаты, а выборка из распределений может давать смещённые или некорректные значения.

Особенно уязвимы комбинации пакетов или нестандартные типы данных — Euclidean Distance не работает с векторами Unitful, а макрос @distributed ломается при использовании OffsetArrays. Многие ошибки приводят к выходу за границы памяти или тихим неверным вычислениям, что ставит под сомнение надёжность любых сложных расчётов. Практический вывод: в проектах, где важна точность, Julia может представлять неприемлемый риск.

• Участники обсуждают проблемы с корректностью и стабильностью экосистемы Julia, включая критические баги в базовых пакетах и проблемы совместимости.
• Высказываются опасения, что эти проблемы делают язык неподходящим для проектов, где важна точность, несмотря на его элегантность и производительность.
• В качестве альтернатив для научных вычислений упоминаются Python с библиотеками (PyTorch, Jax, TensorFlow), R (и tidyverse), а также Rust и Go.
• Некоторые пользователи делятся негативным опытом из-за невыполненных обещаний (например, быстрая компиляция) и переходят на другие языки.
• Обсуждается актуальность критики, поскольку некоторые примеры проблем датируются 2024 годом, несмотря на то, что исходный пост мог быть написан ранее.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

Современный Fortran может быть предпочтительнее Python для обучения основам численной линейной алгебры из-за строгой типизации и явного управления памятью, что помогает студентам лучше понять внутреннюю работу алгоритмов. В Python студенты часто полагаются на готовые функции вроде np.linalg.solve, что скрывает детали реализации и приводит к ошибкам, связанным с динамической типизацией и неправильной индексацией массивов. Например, путаница между списками и массивами NumPy или неявное приведение типов могут затруднить отладку.

Fortran, напротив, требует чёткого объявления переменных и размеров массивов, что снижает риски ошибок и заставляет студентов продумывать структуру данных. Это особенно важно для таких задач, как метод Гаусса-Зейделя или метод наименьших квадратов, где понимание циклов и операций с матрицами критично. Хотя Python с его экосистемой удобен для сложных проектов, Fortran обеспечивает более прозрачный переход от математических формул к коду, укрепляя фундаментальные навыки.

• Обсуждается выбор языка для преподавания численных методов и линейной алгебры (Python, Fortran, Julia, C++ и др.), где Fortran хвалят за производительность и удобство для математики, а Python — за распространённость и простоту.
• Критикуется чрезмерно объектно-ориентированный подход в C++ для научных вычислений, а также сложности и "бородатость" некоторых языков (например, Fortran) для новичков.
• Поднимается вопрос о важности баланса между теоретической "чистотой" языка и его практической полезностью для будущей работы студентов.
• Отмечаются преимущества Julia и MATLAB/Octave для обучения благодаря близости их синтаксиса к математической нотации и удобным инструментам.
• Упоминаются проблемы с ошибками в Python (например, типизация и сообщения об ошибках), а также сложности отладки в сравнении с другими языками.

Новый эмулятор Effort.jl позволяет проводить сложнейшие космологические симуляции на обычном ноутбуке, тогда как раньше для этого требовались суперкомпьютеры. Он имитирует поведение модели EFTofLSS, которая статистически описывает крупномасштабную структуру Вселенной, и выдаёт результаты с той же точностью — иногда даже с большей детализацией — всего за несколько минут.

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

• Критика вводящего в заблуждение заголовка: инструмент является не симуляцией, а эмулятором на основе нейросетей, созданным для аппроксимации результатов дорогих вычислений.
• Обсуждение потенциальных ограничений метода: возможность накопления ошибок при последовательном прогнозировании и сомнения в заявлениях о превосходстве над оригинальной моделью.
• Подчеркивание практической ценности эмуляторов для астрофизики и других областей как быстрых и дешевых инструментов для исследования параметров.
• Проведение параллелей с аналогичными гибридными подходами в других областях (прогноз погоды, предсказание структуры белка, DLSS).
• Упоминание реализации проекта на языке Julia и обсуждение его потенциала в ML/AI на фоне доминирования Python.

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

Именно этим объясняется «алгебраичность» Algebraic Effects: набор эффектов и обработчиков строится как свободная алгебра с заданной сигнатурой операций, а значит любая программа сводится к выражению, подчиняющемуся строгим законам переписывания. Практический выигрыш — возможность комбинировать и вложенно перехватывать эффекты без «callback-ада», потому что поведение заранее ограничено алгебраическими законами.

• Обсуждается различие между "алгебраическими" в контексте типов данных и эффектов, подчеркивая, что последние связаны с алгеброй монад, а не просто наличием уравнений.
• Участники предлагают ресурсы для изучения темы (статья "What is algebraic about algebraic effects and handlers?") и проводят аналогии с булевой алгеброй для лучшего понимания.
• Отмечается сложность терминологии и необходимость перевода абстрактных математических концепций (операции над типами/эффектами) в более доступные для программистов термины.
• Поднимается вопрос о синтаксическом представлении алгебраических типов (сумм и произведений) в разных языках программирования (OCaml, Lean).
• Обсуждается практическое применение алгебраических операторов на примере пакета Algebra of Graphics для Julia.

Как 20-летний алгоритм помогает понять эмбеддинги трансформеров

Чтобы понять, о чём думает LLM, когда она слышит «Java», нужно разложить внутренние векторы на понятные человеку концепции. Это формулируется как задача dictionary learning: эмбеддинг представляется как разреженная сумма базовых векторов-концептов. В 2023 г. Bricken и др. предложили учить словарь через sparse autoencoder (SAE), отказавшись от классических методов из-за масштабируемости и опасения «слишком сильного» восстановления признаков.

Мы показали, что 20-летний алгоритм KSVD, с минимальными доработками, справляется с миллионами примеров и тысячами измерений. Наивная реализация требовала бы 30 дней; наша версия DB-KSVD ускорена в 10 000 раз и работает 8 минут. DB-KSVD обобщает k-means, но позволяет приписывать объект сразу нескольким «кластерам» (концептам).

Библиотека KSVD.jl доступна из Python:

import torch, juliacall; jl = juliacall.Main
jl.seval("using KSVD")
Y = torch.rand(128, 5000, dtype=torch.float32)
res = jl.ksvd(Y.numpy(), 256, 3)  # словарь 256, sparsity 3

На бенчмарке SAEBench DB-KSVD и расширение MatryoshkaDB-KSVD показывают результаты, сравнимые с SAE, по шести метрикам: восстановление эмбеддингов, разделение концептов, их интерпретируемость и др.

• В чате поделились скрытым гемом — второй половиной двухчасового видео Леланда Мак-Иннеса (автора UMAP) о построении эмбеддингов через пред-преобразования и SVD.
• Участники отметили отличное время публикации: идея пригодилась для текущих задач.
• Основная претензия — авторы не расшифровали сразу аббревиатуры, особенно KSVD, что замедлило чтение.
• Уточнили: KSVD ≠ обычный SVD, это алгоритм разреженного кодирования с избыточным базисом и разреженными активациями.

LabPlot — бесплатное кроссплатформенное ПО с открытым кодом для визуализации и анализа данных.

Ключевые возможности

• Качественные графики и интерактивные диаграммы в пару кликов
• Статистика, регрессия, аппроксимация и фитинг пиков
• Интерактивные блокноты Python, R, Julia и др.
• Извлечение данных из изображений и поддержка потоковых данных
• Импорт/экспорт множества форматов
• Windows, macOS, Linux, FreeBSD, Haiku

Свежие новости

• 2.12.1 (18 авг 2025) — мелкие улучшения и исправления
• 2.12 (28 апр 2025) — крупное обновление после долгой разработки
• Дек 2024 — обновлённое руководство пользователя

Скачать | Возможности

• Участники обсуждают LabPlot как FOSS-альтернативу Origin/JMP/Tableau для научного графика.
• Сравнивают: гибкость ggplot2, устарелость Excel/SAS, удобство GUI для не-программистов.
• Плюсы: drag-and-drop, встроенный импорт CSV/TSV, лицензия GPLv2+.
• Минусы: пока только SQLite, нет прямого REST/S3/Iceberg, неясно, как быстро копировать стили.
• Целевая аудитория — инженеры и учёные, которым нужен GUI-построитель графиков без кода.

• WebR — R в браузере (v0.5.6-dev).
• Старт: скачать, раздавать страницы, примеры.
• Основы: обмен с воркером, выполнение R-кода, графика, сеть.
• Объекты: управление, конвертация JS ↔ R, создание.
• Пакеты: установка, сборка, монтирование данных.
• API:
  • R API
  • JS API: модули Channel, Message, Proxy, Queue, WebR, …; классы WebR, RObject, RDataFrame, Console, Shelter, …; интерфейсы WebROptions, EvalROptions, InstallPackagesOptions, …

• WebR запускает R прямо в браузере через WASM, позволяя строить ggplot2 и другие вычисления без сервера.
• Пользователи делятся демо-репозиториями, минимальными HTML-примерами и расширениями Quarto/R Markdown.
• Обсуждаются размер WASM-блоба (≈12 МБ), производительность BLAS и возможность офлайн-работы как PWA.
• Упоминаются альтернативы: JupyterLite-xeus, Pluto.jl и попытки «Julia в браузере», но они ещё незрелые.

Производная показывает, как меняется функция.
Для y = x² – 6x + 13 производная y' = 2x – 6.
Знак y' подсказывает, куда идти вниз по графику; ноль означает минимум.
Решив 2x – 6 = 0, сразу получаем x = 3, y = 4.
Итеративный спуск (градиентный) полезен, когда аналитическое решение сложно.

Градиент — вектор частных производных по каждому аргументу.
Для w = f(x, y, z)
∇f = [∂w/∂x, ∂w/∂y, ∂w/∂z].
Каждая компонента показывает, насколько w изменится при приращении соответствующей переменной на 1.

• Градиенты удобно представлять как «карты стрелок», а Якобиан — как набор таких карт для каждой выходной координаты.
• Хесс-матрица — это вторые производные скалярной функции, и её форма (n×n) возникает только при одномерном выходе.
• Визуальные подходы помогают интуитивно понимать устойчивые/неустойчивые точки и алгоритмы оптимизации.
• Современные инструменты (Julia, Enzyme) позволяют эффективно вычислять Якобианы и Хессианы автоматическим дифференцированием.
• Человеческое зрение быстро «находит минимум» лишь в низких размерностях; в высших размерностях без вычислений не обойтись.