Про логические уловки.

Люди довольно часто, осознано, или нет, оставим это на их совести, пользуются логическими уловками.

3 моих любимых:

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D1%81%D1%83%D0%BF%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D1%8F

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D0%BC%D0%B5%D0%BD%D0%B0_%D1%82%D0%B5%D0%B7%D0%B8%D1%81%D0%B0

https://cyclowiki.org/wiki/%D0%9E%D1%86%D0%B5%D0%BD%D0%BE%D1%87%D0%BD%D0%BE%D0%B5_%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5

Я, знаете ли, в разные периоды жизни по разному реагировал, когда собеседник/оппонент начинал использовать подобные приемы.

Горячился, махал руками, пытался что-то объяснять.

Сейчас я придерживаюсь следующей позиции - никогда не садитесь играть в карты с шулером.

Что это значит?

Это значит, что, если вы не обозначите свое отношение к высказанному утверждению, максимально четко и ясно, то вы примете мысленный фреймворк оппонента, а ему только это и нужно.

Например, если ваш оппонент говорит, что "А - хорошо, Б - плохо" (оценочное суждение), то вам не стоит начинать обсуждать, действительно ли A - хорошо, а Б - плохо. Если вы начали это обсуждать, то вы попались - вы приняли право вашего оппонента навязывать вам определения "хорошо" и "плохо". И на этом поле оппонент вас обязательно выиграет, потому что выигрывает тот, кто определяет, что хорошо, а что - плохо.

Поэтому, когда я вижу, что собеседник пользуется одной из таких логических уловок, у меня в диалоге случается "full stop".

Я говорю собеседнику, что он воспользовался подобным приемом (*), и предлагаю ему либо согласиться, и переформулировать мысль, или не согласиться, и доказать мне, что я ошибся, или закончить наш диалог. Потому что не надо садиться играть в карты с шулером! Не надо пытаться договориться с шулером в рамках правил, которые он вам навязывает, потому что вы автоматически проиграли. Сначала договоритесь про устраивающие вас правила.

Ну а дальше либо диалог переходит в более конструктивное русло (в случае оценочного суждения, например, вам стоит на берегу договориться о том, какие объективные критерии вы измеряете, без "хорошо" и "плохо"), либо заканчивается.

(*): да, прямо так и говорю - "это пресуппозиция", или "это оценочное суждение", или "это подмена тезиса".

Забавно.

Если не узнаёте, то на YouTube вернулся Brackeys — некогда один из самых известных авторов туториалов по Unity. Свой путь он начал уже более десяти лет назад. Настоящий ветеран.

Теперь же он решил сфокусироваться на Godot, объяснив это тем, что движок опенсорсный и очень простой в освоении.

Гемдев мир настолько очистился, что хорошие тутористы возвращаются с переходом на Godot!

И на этом самом годоте на недавнем геймджеме Ludum Dare я в компании хороших людей запилил небольшую игру.
В комментах все хвалят музыку и графоний (это не я делал!) и ругаются, что сложно играть (а это уже я! но делал сложнее, а получилось попроще, но всё равно ругаются)

Если кто хочет попробовать или ещё и проголосовать: https://ldjam.com/events/ludum-dare/55/last-minute-awakening

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

По мотивам этого прикола и других недавних обсуждений всплыла одна интересная, на мой взгляд, моделька.
Хочется сказать пару слов про неё, почему и где она мне кажется полезной, на примере геймдева и другого около-IT опыта.

Про саму модельку design-time vs. run-time

Простыми словами, что это:
- design-time - это когда что-то продумывают (зачем как и где это будет работать) и создают
- run-time - это когда это же что-то работает

Почему это полезно выделять как разные штуки:
- для design-time и run-time нужны отличные друг от друга силы и ресурсы, роли и много чего ещё
- design-time сильно влияет на run-time - чем лучше продумать и реализовать, тем лучше это будет работать
- на переключение между продумыванием и исполнением может уходить много сил и ресурсов, или качество одного или другого может сильно страдать, потому как ресурсов не нашлось и что-то сделано хреново. Особенно если хреново сделан design
- всё это происходит не один раз, потому как результаты работы (run-time) оцениваются и снова происходит дизайн, реализация, исполнение - можно тут вспомнить цикл Дёминга-Шухарта aka цикл PDCA: plan, do, study, act

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

А если разделить, то можно:
- отслеживать отдельно - пусть не 4 стадии по PDCA, а хотя бы две
- улучшать их отдельно
- меньше тратить время на переключение и многозадачность

В результате - меньше тратить сил и иметь возможность улучшать результат.

Примеры натягивания совы модельки на глобус реальности приведу в следующем посте.

#systemyass

Перед описанием примеров применения хочу сделать пару дополнений:

- вся мощь модельки с разделением design time и run time для меня открывается при рекурсивном её применении - то есть run time для одной штуки может быть в то же время design time для другой. И тут важно эти штуки не путать и фиксировать в реальном мире, об чём, собственно, речь (привет, определение системы из Левенчука)
- это всего лишь моделька, использовать её лучше как линзу (привет, gamedev и Джесси Шелл с его линзами) - вот берём ситуацию и можно на неё вот так посмотреть, если получается фигня - бросаем линзу и дём дальше

#systemyass

Пример первый: недавно я впервые сыграл на барабанах на джем-концерте две песни

Design time для самого выступления:
- разбор песен дома
- тренировки игры на барабанах - отработка какой-никакой техники игры с нуля, до этого я только иногда держал палочки в руках
- общая репетиция с другими
- понять где это всё будет, не проебаться и дойти вовремя до места
- выяснение что там будет на сцене в плане установки, куда как врубать метроном

Run time:
- исполнение на сцене двух песен

В чём тут пригодилась моделька
- сформулировать run time для себя и что надо для подготовки - то есть для исполнения design time
- не путать само выступление и обучение мастерству играть на барабанах. Моя цель - выступить, а не идеально сыгать или освоить какую-то конкретную технику исполнения
- пока я играл первую песню - вылетели все техники и приёмы, руки стали деревянные, в голову полезли мысли, как я вторую песню то буду играть и прочая фигня, но это run time, это не про улучшение техники или игры - потому я в перерыве между песнями сбросил напряжение с рук и выбросил из головы мысли про фристроки, свободное движение палочки
- в итоге получить кучу удовольствия вместо переключения на то, где я как сыграл не так и что с этим делать - для этого можно потом выделить время
- вынести из концерта не только удовольствие, но и идеи, что над чем и как я хочу поработать, мотивацию записаться на урок к препроду, мысли, что я хотел бы сыграть в следующий раз или через N времени
- хорошо подготовиться, применяя модельку рекурсивно - run time репетиции это кусок design time выступления

Надеюсь, сова в этом примере хорошо облегает глобус, а если есть мысли, идеи, вопросы - то добро пожаловать в комментарии

Дальше в списке примеров - психотерапия, встреча по планированию в стартапе и недавний LD геймджем.

#systemyass

Прошёл Indika (https://indikathegame.com)

Коротко: хорошая короткая история с погружающим визуалом.
Там мало игры - это видео-новелла с 2-3 хорошо вписывающимися игровыми механиками (и с остальными не очень хорошо вписывающимися).

Самое впечатляющее - окружение/мир и подача истории через хорошо поставленные ролики. По ходу прохождения вспоминались произведения Сорокина, Балабанова, Шаламова, Германа-старшего, Мамлеева, Глуховского - мир показался загадочным и завораживающим. И очень родным, местами даже отечественным.

Стоит того, купить, пройти и перетерпеть некоторые игровые моменты.

#mesa #opengl #valve #zink

https://www.phoronix.com/news/NVK-Explicit-Sync-Valve

Надо сказать, что Valve системно поднимает графический стек Linux из руин, в которых он пребывал последние лет 20.

Надо сказать, что однажды в Linux было очень неплохое 2D ускорение, но, по мере усложнения аппаратной начинки, все это катилось в глюкавое и ненадежное говно, в которое вендоры иногда щедро подливали своих бинарных блобов, которые нормально работали примерно только на машинках их разработчиков, то есть, почти нигде.

Вроде, есть Intel, есть AMD, которые выкатили oss драйвера, а теперь вот и Nvidia, но починкой всего стека системно занимается именно Valve.

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

Комментарий специалиста:

Есть два закона, первый — шуточный закон Старджона ("90% всего — полное говно"), второй — какой-то закон из социологии, название которого я не помню, но он про то, что выборка людей, взятая по одному параметру, по остальным параметрам начинает повторять популяцию в целом. То есть, если бы берем всех "ученых", то внезапно оказывается, что процент идиотов там такой же, как везде, если берем всех "медиков", то процент курящих или верящих в гомеопатию или плоскую землю там такой же.

Знание этих законов освобождает от удивления, возмущения и разных прочих чувств, когда вы сталкиваетесь с чем-то подобным.

Ну и потом, это же гештальт.

межтем

Левенчук очень хорошо про ейай ейлаймент

В связи с чем вспоминается много хороших анекдотов с моей терапевтической группы
Например - Изечка, мама прожила свою жизнь, проживет и твою

Отдельно вдохновляет попытка Анатолия что-то в этой ситуации всё же предложить, хотя в комментариях баба яга всё равно против

Свобода сильна и до справления с ней долгий пусть

А разгадка, как всегда, одна

Вокруг меня довольно много разговоров про alignment (в связи с уходом кучи "безопасников" из OpenAI, скатертью им дорожка), я даю несколько заметок на эту тему. Возможно, кто-то умерит свой пыл в обсуждениях этой проблемы и освободившееся время уделит чему-то более полезному, 24Кзнака, получилось длинно.
— Предметная область alignment: техническое регулирование и нераспространение, а также рабовладение
— От кого/чего надо спасать человечество: alignment как идея
— А делать что? Кто расскажет, как мировое правительство должно отрегулировать мировых разработчиков AI?

Картинка, конечно, классическая — "Гулливер в стране лилипутов".

https://ailev.livejournal.com/1723118.html

В блоге JetBrains вчера вышло прощание с создателем Флибусты – Стивером, но с малоизвестной стороны: в очень техническом посте подробно расписано как много Стивер сделал для языка программирования Java, если коротко – он был автором популярного инструмента для программистов на языке Java и сильно облегчил жизнь программистам, и я честно этого не знал

JetBrains теперь организует мемориал в память Стиверу, продолжит развитие этого инструмента (декомпилятора Fernflower) с открытой лицензией, и рассматривает гранты и стипендии людям в смежных сферах

JetBrains – молодцы