Ага, так и хотелось сказать что это type class на минималках.
Я тоже пробовал свой язык дизайнить и кажется, что если есть типы-суммы с тегами и тайпклассы, то как будто можно построить адекватный язык без наследования. Отличия конечно будут, но мне понравилось что получилось, и штуки типа vtable и прочего если очень надо - можно эмулировать.
У вас в итоге получилась сортировка подсчётом по номеру локации (чтобы было за O(N) вместо О(NlogN) у обычной сортировки) и вспомогательная структура для быстрого поиска. Возможно это очевидно, но в статье ни слова про сортировку и хранение по порядку в финальном варианте. (По крайней мере мне такое описание кажется более интуитивно понятным)
В краткосроке да, в долгосроке читателей всё меньше становится и хабр окончательно умрёт. Туда ему и дорога.
Реальная проблема не в ИИ и не а нейросоопе, а в накрутках рейтинга статей и отсутствии системы рекомендаций. На платформах типа Ютуба можно выкладывать любой шлак, но если его не смотрят и не лайкают - особо никто его и не увидит. А на Хабре единственный критерий для ленты рейтинг (Окей, ещё хабы), и у любой копростатьи он легко шагает за +30.
И хабр не особо поощряет минусование статей (требуют указать причину, есть лимиты на минусование, для старых пользователей плюс даёт. +² или +3, а минус - только -1) - этот механизм усилиям администрации тоже скорее мёртв чем жив, даже нейрослоп особо не минусуют, а для корпоративных статей с админ ресурсом это вообще почти нереально - они в любой момент могут ещё плюсов досыпать.
А, про такое я знаю, но в идеале не надо на сотню километров от центра уходить. Тогда да, любая погрешность с углом умножается на расстояние и точность падает на пять порядков (если 1 это один метр, а если один сантиметр или миллиметр то ещё хуже). А вам даже точности double не хватало? Там точность 15 знаков и как будто их достаточно.
Для матрицы вращения 3х3 экспоненту можно вычислить в замкнутой формуле (и для кватернионов и моторов аналогично). Из минусов - там вылазят вычисления sin, cos и atan2, но для малых углов можно разложить формулы в ряд Тейлора и получить и точность и скорость вычислений. Вдобавок у чисел с плавающей запятой есть замечательное свойство - они умеют хранить очень маленькие или очень большие числа типа 1е-50 или 1е50, и точность не страдает. Я в остальном согласен, но именно интерполяция не самая проблемная часть.
Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
Исходная точка: физические ограничения против теории типов Мой подход исходит из физических ограничений целевого железа (8-битный МК и 2 КБ ОЗУ). Это не абстракция, а жесткая реальность. Каждая фича языка в vm5277 должна платить за свое существование байтами Flash/RAM и тактами процессора. Ваш подход, как я понял, идет от выразительности и корректности на уровне типов. Это прекрасно там, где есть гигабайты ОЗУ и JIT-компилятор, но избыточно для микроконтроллеров.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
не перепутали ли мы эстетическую проблему с гораздо более серьёзной — исчезновением редакционной ответственности?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.
Ага, так и хотелось сказать что это type class на минималках.
Я тоже пробовал свой язык дизайнить и кажется, что если есть типы-суммы с тегами и тайпклассы, то как будто можно построить адекватный язык без наследования. Отличия конечно будут, но мне понравилось что получилось, и штуки типа vtable и прочего если очень надо - можно эмулировать.
У вас в итоге получилась сортировка подсчётом по номеру локации (чтобы было за O(N) вместо О(NlogN) у обычной сортировки) и вспомогательная структура для быстрого поиска. Возможно это очевидно, но в статье ни слова про сортировку и хранение по порядку в финальном варианте. (По крайней мере мне такое описание кажется более интуитивно понятным)
В краткосроке да, в долгосроке читателей всё меньше становится и хабр окончательно умрёт. Туда ему и дорога.
Реальная проблема не в ИИ и не а нейросоопе, а в накрутках рейтинга статей и отсутствии системы рекомендаций. На платформах типа Ютуба можно выкладывать любой шлак, но если его не смотрят и не лайкают - особо никто его и не увидит. А на Хабре единственный критерий для ленты рейтинг (Окей, ещё хабы), и у любой копростатьи он легко шагает за +30.
И хабр не особо поощряет минусование статей (требуют указать причину, есть лимиты на минусование, для старых пользователей плюс даёт. +² или +3, а минус - только -1) - этот механизм усилиям администрации тоже скорее мёртв чем жив, даже нейрослоп особо не минусуют, а для корпоративных статей с админ ресурсом это вообще почти нереально - они в любой момент могут ещё плюсов досыпать.
А, про такое я знаю, но в идеале не надо на сотню километров от центра уходить. Тогда да, любая погрешность с углом умножается на расстояние и точность падает на пять порядков (если 1 это один метр, а если один сантиметр или миллиметр то ещё хуже). А вам даже точности double не хватало? Там точность 15 знаков и как будто их достаточно.
Для матрицы вращения 3х3 экспоненту можно вычислить в замкнутой формуле (и для кватернионов и моторов аналогично). Из минусов - там вылазят вычисления sin, cos и atan2, но для малых углов можно разложить формулы в ряд Тейлора и получить и точность и скорость вычислений. Вдобавок у чисел с плавающей запятой есть замечательное свойство - они умеют хранить очень маленькие или очень большие числа типа 1е-50 или 1е50, и точность не страдает. Я в остальном согласен, но именно интерполяция не самая проблемная часть.
Есть такое видео, но его сложновато слушать: https://www.youtube.com/watch?v=1iPWt1gvT_w
И ссылки на почитать. https://habr.com/ru/articles/1033328/ https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/135011
Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
P.p.s. какие-то мысли про язык и процесс разработки (сам язык сильно отличается, но надеюсь какие-то вещи могут пригодиться) : https://kright.me/2026/07/06/delaiu-svoi-iazyk-programmirovaniia/
Лол, а остальные статьи на Хабре вас не смущают, включая статьи самих редакторов?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Ага, и на мой взгляд будет круто, если у них всё получится. Выглядит очень смело и амбициозно.
Они и хотят и пытаются. К текстовому редактору намного проще делать плагины и изменения, чем к IDE с кучей внутренних взаимосвязей и ограничений.
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
То же самое хотелось сказать. Отвратительно написанная новость, только в заблуждение вводит, хотя по-факту ничего не изменилось.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.