Можно было решить обе задачи через дизайн интерфейса, показав уведомление типа "в городе N началось восстание". При нажатии на город - показать большой красный индикатор уровня удовлетворения, а около каждого деления шкалы сноску с тем, какие эффекты даёт достижение каждого уровня.
А при нажатии на конкретную армию - показать какую-нибудь цифру, которая описывает её мощь.
А у каждого термина - ссылку на встроенную энциклопедию.
С тем же успехом можно в MOBA-играх выдавать подсказки типа "против этого героя купи этот предмет, а против вон того-другой предмет" а на миникарте подсвечивать, где в последний раз был враг, таймер до появления бонусов, итд.
Всё это также основано на уже доступной в игре информации.
Базовые механики можно описать через сюжетную кампанию, обучение, или то же уведомление со ссылкой на энциклопедию.
Ждём, когда в новых играх студии перестанут нормально прорабатывать это всё, а игры будут постоянно ходить в интернет ради того чтобы генерить подсказки, либо отжирать память ради локальной llm (потом ещё ввести тариф, чтобы отбить токены)
fuzzy logic можно и классическими методами реализовать (хоть if-else с коэффициентами, хоть через машинное обучение). Не обязательно тащить экскаватор в виде LLM туда, где нужно грядку на балконе совком покопать. Смену логики без переписывания кода также можно реализовать при помощи своего DSL и формул.
Хотя опять же зависит от того, какую логику надо менять.
"поменял промпт за 5 минут" - это очень оптимистично с учётом того что нужно тесты прогонять)
Зато без llm:
Бот быстрее, можно какие-то более мелкие окна принятия решений ловить
Идейно круто, особенно с цепями Маркова. Только на счёт "no external dependencies" немножко обман, так как растовые бинари по-умолчанию от glibc зависят.
Ещё смущает встраивание словаря в код, так как хороший default - это хорошо, а возможность его переопределить - ещё лучше.
Сам код попробую глянуть, может закину какой-нибудь issue или pr.
Даже в 1С есть из коробки синтаксис с английскими ключевыми словами. Так что в идеале можно только предметную область оставить на русском (что будет правильно, имхо)
С дотнетом сразу в комплекте получаем jit-компилятор
Язык 1с by design интерпретируемый, потому без jit будет тяжко
А ещё нужно GC реализовать (а в дотнете он сразу есть готовый)
А ещё на чем-то нужно формочки реализовать (в случае с донетом можно взять уже готовую авалонию)
А ещё в каком-то виде нужно кроссплатформенные плагины делать, которые не придётся перекомпилировать при каждом новом релизе языка. На расте можно было бы wasm прикрутить или изобрести свой формат для плагинов, а в дотнете уже есть свои dll-ки, которые и так нормально работают.
GC и так защищает от утечек памяти, причём лучше чем растовый боров чекер и счетчики ссылок. А утечек памяти раст никогда и не заявлял, что защитит, так как это в понимании разработчиков языка не нарушает memory safety
C# и так показывает достаточно хорошую скорость.
Использование C++ и Rust не сделает рантайм автоматически не зависимым от системы. Всё также останется зависимость от vcruntime на винде и glibc на линуксе. А дотнет можно собрать как self contained
Я хоть и фанат раста и использую его для решения рабочих задач, но я боюсь, что реализовать описанный в новости проект в таком объёме и за такое время было бы невозможно (предлагаю посмотреть на существующие проекты интерпретируемых языков, реализованных на rust и их состояние)
Вообще у онлайн банков тоже в закромах есть очень много интересных кнопок. Вплоть до полуручных процессов для особо редких случаев, когда "дорогой клиент хочет что-то странное".
Например я так когда-то давно в тинькове заказывал карту в лимитированном дизайне, который нельзя было выпустить через приложение (толи только для новых клиентов, толи по времени ограничено было), но который я очень хотел - прямо спросил в поддержке и мне такую выпустили.
Но это естественно только для случаев, когда надо удержать клиента/поднять лояльность, а не закрыть все счета поскорее)
А что же тогда ещё акцизы, транспортный налог, и налоги которыми юридические лица покрыты не считаете, раз уже начали считать косвенные налоги - они все ведь заложены в цене всех товаров?
Можно кстати пример страны, которая хотя-бы декларирует какой-то уровень социалки для всех, у которой поборы будут меньше?
Библиотечный пример я дал не затем, чтобы показать что оно есть, а чтобы показать нормальный код, а не то что чатжпт может выдать => дать нормальную основу для дискуссии.
Можете тыкнуть пальцем в те слова в коде, которые вы считаете лишними?
Так последующее чтение из этой структуры должно будет вызвать assume_init, а этот метод помечен как unsafe, а это значит, что для чтения из MaybeUninit нужно будет объявить unsafe-блок.
Когнитивная нагрузка всё равно будет, если у тебя нет GC. В расте заимствование и владение явное и проверяется компилятором.
А также определённые вещи, которые невозможно на этапе компиляции проверить, можно делать только в unsafe блоках.
В си - нужно самому разработчику смотреть, когда нужно и когда можно память освободить.
Тоесть когнитивная нагрузка не в самой концепции владения и заимствования, а в том что при написании кода нужно свои намерения о потокобезопасности и управлении памятью выражать в типах.
Мне понравилась аналогия про синие воротнички из недавнего поста, но я немного её перефразирую:
Си - это как опасный промышленный станок. Тебе нужно помнить ТБ и внимательно следить за тем, что происходит, чтобы тебя не намотало.
Раст - как какая-то теорема. Если доказал - дальше можешь уверенно пользоваться ей и не думать, так как результат всегда будет правильный.
Ждал упоминание std::mem::ManuallyDrop, но не увидел, хотя штука тоже может больно отстрелить.
https://doc.rust-lang.org/std/mem/struct.ManuallyDrop.html
От парадоксов только в стелларис играл и такой проблемы не заметил, вроде все механики понятные.
(По крайней мере вопрос "почему планета бунтует" или "на сколько сильнее этот флот чем тот что у меня есть" не возникнет)
Сложности только при каких-то не базовых механиках (некоторых евентах, например), взаимодействии нескольких разных механик, поиске меты.
Конкретику не вспомню. Каким-то сильно хорошим игроком я себя не назову.
А вопросы всегда будут, так как не все люди любят/умеют читать.
А ещё обновления меняют старые механики => создают вопросы у тех, кто вроде бы уже умеет играть.
Можно было решить обе задачи через дизайн интерфейса, показав уведомление типа "в городе N началось восстание". При нажатии на город - показать большой красный индикатор уровня удовлетворения, а около каждого деления шкалы сноску с тем, какие эффекты даёт достижение каждого уровня.
А при нажатии на конкретную армию - показать какую-нибудь цифру, которая описывает её мощь.
А у каждого термина - ссылку на встроенную энциклопедию.
С тем же успехом можно в MOBA-играх выдавать подсказки типа "против этого героя купи этот предмет, а против вон того-другой предмет" а на миникарте подсвечивать, где в последний раз был враг, таймер до появления бонусов, итд.
Всё это также основано на уже доступной в игре информации.
Базовые механики можно описать через сюжетную кампанию, обучение, или то же уведомление со ссылкой на энциклопедию.
Ждём, когда в новых играх студии перестанут нормально прорабатывать это всё, а игры будут постоянно ходить в интернет ради того чтобы генерить подсказки, либо отжирать память ради локальной llm (потом ещё ввести тариф, чтобы отбить токены)
На уровне тех самых подписок на гороскопы по клику на не ту кнопку, которую вставил опсос
fuzzy logic можно и классическими методами реализовать (хоть if-else с коэффициентами, хоть через машинное обучение). Не обязательно тащить экскаватор в виде LLM туда, где нужно грядку на балконе совком покопать.
Смену логики без переписывания кода также можно реализовать при помощи своего DSL и формул.
Хотя опять же зависит от того, какую логику надо менять.
"поменял промпт за 5 минут" - это очень оптимистично с учётом того что нужно тесты прогонять)
Зато без llm:
Бот быстрее, можно какие-то более мелкие окна принятия решений ловить
Нет затрат на токены
Идейно круто, особенно с цепями Маркова. Только на счёт "no external dependencies" немножко обман, так как растовые бинари по-умолчанию от glibc зависят.
Ещё смущает встраивание словаря в код, так как хороший default - это хорошо, а возможность его переопределить - ещё лучше.
Сам код попробую глянуть, может закину какой-нибудь issue или pr.
Ну например в keepassxc есть возможность сгенерировать пароль по словарю слов.
bip39 также использует идею кодирования каких-то байтов в виде мнемоники.
Можно взять взять произвольный словарь и генерировать так пароли.
Такое и запомнить не трудно (например у меня используется в качестве мастер-пароля фраза с 200+ бит энтропией)
Даже в 1С есть из коробки синтаксис с английскими ключевыми словами. Так что в идеале можно только предметную область оставить на русском (что будет правильно, имхо)
Ну типа импортозамещение))
А на винде из коробки тоже много всякого есть: C# (но без msbuild), Powershell, какой-то из вариантов Бейсика, JScript, батники
Видимо для тех, кто не знает C#, но знает язык 1С, а упомянутые проблемы не считает значимыми для своей конкретной задачи.
Ну как минимум:
С дотнетом сразу в комплекте получаем jit-компилятор
Язык 1с by design интерпретируемый, потому без jit будет тяжко
А ещё нужно GC реализовать (а в дотнете он сразу есть готовый)
А ещё на чем-то нужно формочки реализовать (в случае с донетом можно взять уже готовую авалонию)
А ещё в каком-то виде нужно кроссплатформенные плагины делать, которые не придётся перекомпилировать при каждом новом релизе языка. На расте можно было бы wasm прикрутить или изобрести свой формат для плагинов, а в дотнете уже есть свои dll-ки, которые и так нормально работают.
GC и так защищает от утечек памяти, причём лучше чем растовый боров чекер и счетчики ссылок. А утечек памяти раст никогда и не заявлял, что защитит, так как это в понимании разработчиков языка не нарушает memory safety
C# и так показывает достаточно хорошую скорость.
Использование C++ и Rust не сделает рантайм автоматически не зависимым от системы. Всё также останется зависимость от vcruntime на винде и glibc на линуксе. А дотнет можно собрать как self contained
Я хоть и фанат раста и использую его для решения рабочих задач, но я боюсь, что реализовать описанный в новости проект в таком объёме и за такое время было бы невозможно (предлагаю посмотреть на существующие проекты интерпретируемых языков, реализованных на rust и их состояние)
Вообще у онлайн банков тоже в закромах есть очень много интересных кнопок. Вплоть до полуручных процессов для особо редких случаев, когда "дорогой клиент хочет что-то странное".
Например я так когда-то давно в тинькове заказывал карту в лимитированном дизайне, который нельзя было выпустить через приложение (толи только для новых клиентов, толи по времени ограничено было), но который я очень хотел - прямо спросил в поддержке и мне такую выпустили.
Но это естественно только для случаев, когда надо удержать клиента/поднять лояльность, а не закрыть все счета поскорее)
as_mut - получить &mut T, например если есть контейнер - чтобы получить ссылку на его содержимое.
Some - чтобы создать Option::Some. (Тут уж либо явно так, либо неявное преобразование + сложный вывод типов как в Haskell или Ocaml, либо null)
А что же тогда ещё акцизы, транспортный налог, и налоги которыми юридические лица покрыты не считаете, раз уже начали считать косвенные налоги - они все ведь заложены в цене всех товаров?
Можно кстати пример страны, которая хотя-бы декларирует какой-то уровень социалки для всех, у которой поборы будут меньше?
С NFC тоже нужен pin.
При использовании QR кода по идее верификация уже произошла на стороне приложения по паролю и номеру телефона
Библиотечный пример я дал не затем, чтобы показать что оно есть, а чтобы показать нормальный код, а не то что чатжпт может выдать => дать нормальную основу для дискуссии.
Можете тыкнуть пальцем в те слова в коде, которые вы считаете лишними?
На моменте "столько лишних слов" нужно дать пример кода, а в текущем виде - это соломенное чучело из палаты мер и весов.
Вообще спрашивать чатжпт для этого не нужно, так как оно уже есть в std:
https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#50-53
А по поводу
В Rust есть ключевое слово unsafe, которое позволит вам разыменовать сырой указатель и вызывать функции, которые этим словом помечены.
Что мешает использовать эту самую самодисциплину совместно с unsafe, если не нравятся "лишние" слова?
Пишут что там 300тб
Так последующее чтение из этой структуры должно будет вызвать assume_init, а этот метод помечен как unsafe, а это значит, что для чтения из MaybeUninit нужно будет объявить unsafe-блок.
ЧТД
Когнитивная нагрузка всё равно будет, если у тебя нет GC. В расте заимствование и владение явное и проверяется компилятором.
А также определённые вещи, которые невозможно на этапе компиляции проверить, можно делать только в unsafe блоках.
В си - нужно самому разработчику смотреть, когда нужно и когда можно память освободить.
Тоесть когнитивная нагрузка не в самой концепции владения и заимствования, а в том что при написании кода нужно свои намерения о потокобезопасности и управлении памятью выражать в типах.
Мне понравилась аналогия про синие воротнички из недавнего поста, но я немного её перефразирую:
Си - это как опасный промышленный станок. Тебе нужно помнить ТБ и внимательно следить за тем, что происходит, чтобы тебя не намотало.
Раст - как какая-то теорема. Если доказал - дальше можешь уверенно пользоваться ей и не думать, так как результат всегда будет правильный.