Ненормальное программирование *

Тут вот человек написал навороченную статью про установку под Докер этой штуки
https://habr.com/ru/articles/948894/
но так как я программист не настоящий ( а всё через нейросети), и Linux-ом баловался только лет 20 назад, то решил всё же под Windows всё это сделать, ибо полезно:
1) телефонные звонки можно иногда расшифровать
2) делать интервью для написания книги ( в ролях)
3) как там уже писали про всякие деловые разговоры..
4) ну и так далее и так далее..потом этот текст засунуть в нейросеть и сделать выводы.

Короче говоря, помучал нейросеть полдня с перерывами, и вот такая картинка ниже, вполне очевидная. Отдельно окно для настроек диаризации, так как вначале принимало за одного и того же человека, совершенно разных людей с сильно разными голосами ( это расшифровка телефонного разговора)
При других настройках все гораздо лучше- как на скрине.
Кода исходного не будет, Гитом не умею пользоваться. Да и код как раз был скормплен нейросети из поста по ссылке, а также еще с другого деятеля, у которого была чуть более старая версия на gitnub
Потом борьба с ошибками и пожалуйста..

Это я к тому, что на Reddit-е пока все это делал наткнулся на жалобы, вот мол, а почему под Windows нет сборки? Типа всё на линуксе да на линуксе, а сделать такое оказывается делов на пол-дня не программисту.

/

Все вокруг стараются сделать мир лучше, пишут редакторы, используют нейросети. Скука! Я решил пойти другим путём и создал "Лабораторию Абсурда" — которая намеренно и с особым цинизмом превращает любой осмысленный текст в лингвистический бред.

Не спорю, существуют и другие генераторы бреда, но я дарю вам 50 (или что-то около того) разных способов издевательства над текстом и здравым смыслом! Никаких рекламных баннеров, только ванильный JS и словари на тысячи слов, только хардкор!

Недавно сообщество фанатов классической RPG Arcanum: Of Steamworks and Magick Obscura потрясла новость: разработчик по имени Alex завершил титанический труд по реверс-инжинирингу оригинального движка игры. Теперь у нас есть его полнофункциональные исходные коды, которые можно компилировать под Windows, Linux и macOS с использованием современной библиотеки SDL3.

Это осуществление мечты. Теперь игру можно улучшать, исправлять многолетние баги, добавлять новый контент. И я, как и многие, планирую поучаствовать в этом процессе. Но этот прорыв заставил меня задуматься: а как создавалась такая магия тогда, в середине 90-х? Каково это — строить подобный движок внутри той самой эпохи, с её железом, софтом и мировоззрением?

Так родился этот личный эксперимент. Я не буду переделывать готовый движок. Я попытаюсь с нуля написать свой движок для Arcanum так, как если бы на дворе был 1995 год.

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

В 90-х и 2000-х студия Impressions Games выпускала отличные исторические градостроительные симуляторы. Я играл во все игры этой серии от незабываемого Caesar 3, который вообще был первой моей компьютерной игрой на отцовском компуктере, до Императора про древний Китай. Но египетский Pharaoh и греческий Zeus запомнились намного четче, но вот почему я сказать не берусь.

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

Формат "Новых исполняемых" файлов называют сегментным. Даже в официальной документации Microsoft её заголовок это "Сегментный Новый Исполняемый формат" (ориг. "Segmented NEW Executable Format").

Этот сегментный формат программ поддерживал

Сегментную модель памяти;

Защищенный режим Intel 286+

Динамичкую компановку (Dynamic Linking);

Управление ресурсами;

Возможность экспорта и импорта определенных процедур.

Формат "Новых исполняемых" файлов называют сегментным. Даже в официальной документации Microsoft её заголовок это "Сегментный Новый Исполняемый формат" (ориг. "Segmented NEW Executable Format").

Этот сегментный формат программ поддерживал

Сегментную модель памяти;

Защищенный режим Intel 286+

Динамичкую компановку (Dynamic Linking);

Управление ресурсами;

Возможность экспорта и импорта определенных процедур.

В 1980х в США активно развивалось увлечение садовыми железными дорогами. Поезда работали на электричестве вместо пара, были доступны аккумуляторы, появилась компактная электроника, чтобы можно было «прикрутить» радиоуправление. И многие любители делали не только модели настоящего подвижного состава, но и ставили на рельсы игрушки марки Stomper.

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

Как следует отображать на экране результат деления 3.0 на 10.0 ? Сколько цифр следует вывести, если пользователь не указал точность?

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

Давайте продолжим разговор о самой неоптимизированной в мире библиотеке эмуляции плавающей точки при помощи целочисленной арифметики.

Это вторая статья из цикла «Санпросвет о плавающей точке»:

1. Компьютеры и числа

2. Вывод чисел с плавающей точкой на экран <- вы тут

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

Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.

Таким образом, я решил засучить рукава, и изобрести велосипед. То есть, написать самую неоптимизированную C++ библиотеку для эмуляции IEEE754 32-битных чисел с плавающей точкой при помощи исключительно 32-битной целочисленной арифметики. Библиотека уложится в несколько сотен строк кода, и в ней не будет никакого битхакинга. Задача написать понятный код, а не быстрый. А заодно хорошенько его документировать серией статей.

Итак, этим полукреслом мастер Гамбс начинает новую партию мебели, или статья первая: поговорим о числах и компьютерах.

Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За годы работы над движками и играми я понял, что подход к управлению памятью очень сильно влияет на весь проект. В отличие от многих приложений - игры, особенно большие, часто работают часами без прерываний и должны поддерживать стабильный фреймрейт и отзывчивость. Когда проседание fps или фриз происходит на глазах у сотен тысяч игроков, вам уже никто не поможет — ущерб уже нанесен, а в steam полетели отзывы о кривизне рук разработчиков.

Однажды моя команда закончила работу над довольно интересным проектом, который портировали больше двух лет на плойку. Движок старый, большой и мощный, но работа с памятью была ориентирована на ПК времен конца 2000-х, и что меня поразило, так это насколько сильно большая часть кодовой базы зависела от динамической памяти во время выполнения. На ограниченном железе (далеко не у всех есть PS5 pro) и в условиях жёстких требований к сертификации на консолях такие решения быстро превращаются в проблему.

В разработке для консолей (про мобильные устройства я молчу, потому что игра не влезает по памяти даже в восемь гигов) с ограниченными ресурсами, архитектура с частыми аллокациями не просто неэффективна — она становится реальной угрозой для стабильности проекта. Каждое выделение памяти в куче влечёт за собой накладные расходы: это дополнительные !миллисекунды! (в целом на кадре) задержки, риск большой фрагментации памяти, и непредсказуемое поведение в долгой игровой сессии. После двух часов игры постоянные операции с кучей буквально «сжигают» половину бюджета кадра.

Хотел написать классическую статью, ни разу не писал, ради интереса попросил ChatGPT и она все написала, стало скучно до жути, эта «классическая » статья будет под спойлером, она реально по теме, написана с двух запросов, а далее будет кратенько и технически что и зачем, со ссылками на примеры. Для технической части нужны знания python, llm, cuda и что такое OpenAI API.

Что действительно делает программу великой? Скорость работы, поражающая воображение? Лаконичность и изящество кода, восхищающие коллег? Или, быть может, Архитектура, обещающая вечную гибкость? Тысячи лет все эти империи рушились перед лицом коварной Ошибки. Пришло время провозгласить манифест иной истины: высшая ценность программы — её Достоверность, и цель разработки — доказать, что программа безупречно воплощает замысел своего создателя. В данной статье мы рассмотрим инструменты и методы, которые превращают намерение программиста в неопровержимую теорему. Через формальную верификацию тривиального, но коварного ФиззБазза средствами Idris 2 мы покажем, как строить программы, чья правильность не вера, но математический факт. Зависимые типы — наш меч. Добро пожаловать в мир, где код не просто работает — он доказан.

Надоело каждый раз подставлять TOTP на сайтах и у вас есть yubikey? Тогда добро пожаловать под кат. Поделюсь самописным расширением, которое позволяет автоматизировать эту рутину.

Недавно я набрёл на шедевр Патрика — клон DOOM, основанный на DuckDB-WASM и работающий в браузере. Прочитав о нём, я решил  довести  эту великолепную идею до логического завершения: написать многопользовательский DOOM-подобный шутер целиком на SQL. При этом всю тяжёлую работу хотел сделать через базу данных CedarDB. Отлучившись с работы в месячный отпуск по уходу за ребёнком (бессонных ночей хватало), я попытался сделать именно это.

Вот вам тизер DOOMQL:

В процессе разработки программного обеспечения часто возникает вопрос: нужно ли заранее проектировать структуру кода и устанавливать строгие правила, чтобы облегчить работу команды? Недавний диалог между разработчиками Азазелем и Сашей проливает свет на этот вопрос и предлагает интересный взгляд на организацию процесса разработки.

Азазель предложил идею, которая кажется логичной и полезной:

Привет, меня зовут Саша и я Android-разработчик :)

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

Часто источниками данных являются: человек, сервер и устройство (User, Server, Platform).

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

Подобно тому как вызовы функций вкладываются друг в друга:

Снова показываю как можно вести разработку «голыми руками» — без IDE, документации и даже интернета. На этот раз с помощью «пользовательской» Ubuntu Linux и OpenJDK.

В процессе разработки некоторого количества достаточно сложных текстовых квестов, пришло понимание связанных с этим сложностей. Работа в графическом редакторе увлекательна, но крайне неудобна, по целому ряду причин. В ответ на эти проблемы, родилась идея текстового языка разметки, а уже в процессе его разработки появилась возможность сделать кое что неожиданное. Мне требовался вычислительный блок, для выполнения нетривиальных вычислений и система команд МК-61 показалась неплохим выбором. Ну а чтобы убедиться что всё работает, пришлось воссоздать “Лунолёт”. Внутри текстового квеста…

Язык программирования, даже общего назначения, - это инструмент. Каждый язык хорош в решении задач своей сферы: C++ позволяет писать эффективные программы, Haskell - писать элегантный параллельный и математический код, C# - создавать программы на гибкой масштабируемой архитектуре. Современные языки заставляют нас мириться с их недостатками: отсутствие нужной системы типов, нехватка синтаксического сахара, отсутствие парадигмы X. Все хоть раз мечтали о языке, который удобен для решения любой задачи.

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