x86128 | Reading

Есть такой симулятор ZX Спектрума, глюкалка называется. Я переложил исходники на Гитхаб для сохранности. Подрихтовал маленько: вдруг кому пригодится.

github.com/sergev/glukalka3

vak

Целиком интервью можно посмотреть на Ютубе. Вот текст первой части. Остальные семь частей добавлю в комменты.

Part 1: Why Build Zig & Overcoming Technical Friction

[00:00]

What made you build Zig? I can do better. I can do better than C++, I can do better than Rust, I can do better than Go, I can do better than JavaScript. Strict no LLM, no AI policy, why? Invariably garbage. $100 million, would you take it? I'm sorry, but we will not do what you say, and if you take your money away, we will survive. You moved Zig's main repository from GitHub to Codeberg. GitHub simply stopped working for us. We moved to Codeberg and now our continuous integration server works again. When we tag 1.0, it will be like a true uncompromising labor of love. We will not have to be stuck with any like bad decisions. What's blocking it? Um, well, ultimately...

Andrew Kelley, we already have C, C++, Rust, Go. What made you build Zig anyway? Well, it's funny that you listed those languages specifically because that is exactly the set of programming languages that I first tried to use to build a digital audio workstation just before I pivoted to working on Zig. And when I tried to work on this project with each different language, I ran into a different set of problems that I found insurmountable. And at the end of this process, I concluded that no, it's not me that is having a skill issue, it's the programming language that's the problem. And so from there, that's where I developed the hubris of making a new programming language.

Comment: Andrew Kelley, creator of the Zig programming language, quit his tech job in 2018 to build Zig full-time. He runs the Zig Software Foundation on $670,000 a year and enforces a strict ban on AI contributions.

What problems exactly? The first thing that I tried to do was make the digital audio workstation in the browser using JavaScript, and what I quickly realized is that this is too high level. I don't have access to the computer's capabilities that will allow me to make a compelling user experience in this digital audio workstation. So I threw that out the window and I went to native programming language compilation.

The next thing I tried to do is Go. What I ran into with Go is, number one, trying to interact with libraries like for creating a window or making buttons or something like this using existing C code does not work very well with Go. And then I also ran into the garbage collector problem. So, of course, if you're trying to do audio, you have a real-time deadline. If you can't process the audio in exactly this amount of time, you get a glitch or a skip, and it's completely unacceptable for live performance software like a digital audio workstation.

So then I got rid of Go. Now I tried to use Rust, and this was before Rust 1.0. But what happened is that I really struggled to write code that would satisfy Rust's rules. Once I did satisfy them, I found that even trying to make little changes would cause a cascade of compile errors that would prevent me from making more progress. I remember just feeling very frustrated that I spent a whole month trying to get font rendering to work, and then felt stuck like I couldn't even make more progress after that point. So I gave up on Rust and I switched to C++.

Then I felt more productive at first. But what happened very quickly is that just a little typo here, a little mistake there, would result in a memory corruption bug that would cost me weeks in order to debug. This is just too slow. I can't create a project with this magnitude of difficulty when these little mistakes are costing me weeks and weeks over and over again. After that, I tried C++ but C-style. I would compile with the C++ compiler, but I would link with the C linker, and that would give me an error if I tried to use fancy C++ features. That limited me to only templates and a few other things, but even then, it was the same problem. It's just too easy to shoot yourself in the foot with C++. For me, that was when I said: "I can do better. I can do better than C++, I can do better than Rust, I can do better than Go, I can do better than JavaScript, I can do better than D." That was my hubris.

vak

Мне тут ценный промпт подкинули.

You are my personal teacher. Your job is to make me smarter after every single task we do together. After completing any task or project, write a detailed FOR[yourname].md file that breaks down the entire thing in plain language.

Here's exactly what I want you to cover.

Step 1: What approach did you take, and why? Walk me through your reasoning. What was your starting point? What did you consider first?

Step 2: What other approaches did you consider but abandon? Why did you reject them? What was wrong with them? This is where I learn the most — I want to understand the roads not taken.

Step 3: How do the different parts of your work connect to each other? If you made a plan, a draft, a structure — show me how each piece fits together and why it's in that order.

Step 4: What tools, methods, or frameworks did you use? Why those specifically and not others? What would have changed if you picked differently?

Step 5: What tradeoffs did you make? What did you prioritize and what did you sacrifice? Every decision has a cost — show me both sides.

Step 6: What mistakes, dead ends, or wrong turns did we hit? How did we fix them? Don't hide the mess — the mess is where the learning lives.

Step 7: What pitfalls should I watch out for if I do something similar in the future? Give me the "I wish someone told me this earlier" advice.

Step 8: What would an expert notice about this work that a beginner would miss? Show me what separates good thinking from average thinking.

Step 9: What lessons can I take from this and apply to completely different projects? Connect the dots for me.

Make it engaging. Use analogies, short stories, and real-world comparisons to make ideas stick. If a concept is abstract, ground it in something I can picture.

I want to finish reading and feel like I actually understand what happened.

Чтобы заценить, открыл я проект своего Си компилятора и дал этот промпт Клод Коду. Вот что получилось:

Learn_From_This_Project.md

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

Там есть пара мест, где надо бы уточнить, но в целом отлично.

denise posting in

dw_maintenance

Quick note that post-by-email and comment-by-email is (sometimes?) failing silently without actually posting right now! I'm pretty sure this is related to last night's shenanigans and will be fixed once Mark can finish the full fix for it, which he's working on, but if you've posted or replied by email in the last 24 hours, fish it out of your sent folder to check if it posted!

EDIT: This should be fixed as of around 7AM EDT! We *believe* everything that was stuck in the plumbing has been sent along to your journal or the comment thread it was meant for; it's definitely not where it was stuck anymore, at least.

vak

Мои земляки решили положить конец 300-летней истории языкового угнетения.

(facebook)

Депутати Полтавської міської ради ухвалили рішення щодо заборони російськомовного культурного продукту.

Як зазначено в документі, рішення розроблено у зв’язку з потребою в захисті українського інформаційного простору від гібридних впливів держави-агресора, що намагається завадити зміцненню національної ідентичності, збереженню національної культури, традицій, звичаїв, історичної пам’яті.

Обмеження діятимуть у транспорті, закладах громадського харчування та культури, торговельних майданчиках та інших публічних просторах. Зокрема, йдеться про заборону публічного використання російськомовних книг, музичних творів, фільмів, театральних постановок, концертних програм, культурно-освітніх заходів тощо.

Их там баллистикой бомбят в последнее время не по детски.

https://youtu.be/5xvKeUbwQqg

vak

Хотите, чтобы крыша конкретно поехала? Вот вам.

Сам я не пытался смотреть сей опус от начала до конца на нормальной скорости. Только пролистал швыдэнько.

Watch on YouTube

denise posting in

dw_maintenance

Robby has managed to put in a temporary fix for the site errors and things failing to refresh or not showing up where they should! The permanent fix is going to need Mark's experience, and unfortunately -- seriously, this literally never fails -- Mark has been on an international flight all day, because of course he has. (Never. Fails. He and I are not allowed to both take vacation at once.)

The site will work just fine with the temporary fix in place, things just might be a little slow here and there. We'll keep you updated.

vak

От фирмы Unicomp приехала клавиатура Model M. Абсолютно те же ощущения, что и 40 лет назад от первых IBM PC. Я попробовал пользоваться этой клавиатурой на работе. Вполне комфортно, кроме одной проблемы: она довольно шумная. Кнопки щёлкают при нажатии, пружинки поскрипывают. Первые пару минут прикольно, а потом начинаешь понимать, что в современном open office оно несколько неуместно. Соседи может ничего и не скажут из вежливости, но вообще-то принято вести себя негромко.

Дома проще, если не работать по ночам, когда все спят.

К клавиатуре был приложен листик со ссылками на полезные инструкции:

denise posting in

dw_maintenance

We're aware of site traffic issues and are working to fix them for the people who are having problems! (The tactics the damn bot traffic uses are endlessly shifting, and they're really good at looking like real traffic, sigh.)

vak

Старая детская хохма.

"Why can't you send a duck into space?"
"Because the bill would be astronomical!"

В английском языке здесь двойная игра слов: bill как клюв утки, и bill как счёт, выставленный к оплате. Также astronomical как относящийся к космосу и одновременно "очень большой".

К недавнему облёту Луны народ выпустил памятную уточку:

vak

Законспектирую опыт программирования с Курсором и Claude Code. Вдруг кому пригодится. Я провёл несколько дней, активно кодируя симулятор i386 на микрокоде. Чисто из любопытства: если получится, его можно будет встроить в tiltti.

Но главная цель - сравнить умность двух разных моделей: от Курсора (Composer) и от Claude Code (Opus). Недавно как раз появились новые версии: Composer 2.5 и Opus 4.8.

Начал я с того, что дал Клод Коду (модель Sonnet 4.6) исходники микрокода i386 и исходники реализации z386 для FPGA. Попросил проанализировать их на предмет построения софтверного симулятора. Получил подробный план разработки из 19 шагов. По этому плану и действовал.

Создал два пустых Git-репозитория: в одном будет трудиться модель Composer 2.5 от Курсора, в другом - модель Opus 4.8 (тоже через Курсор, но сначала Sonnet 4.6 через Claude Code).

Из tiltti убрал всю суть и оставил голый скелет приложения - main() и мелочёвку. Положил в оба репозитория и скомандовал агентам: вперёд и с песней. Делаем шаг №1 по плану, покрываем тестами. Потом шаг №2, и так далее.

Композер быстро вырвался вперёд. За два дня усердной работы (с утра до вечера) все 19 шагов были выполнены. Ещё через два дня допиливания удалось пройти первые пять тысяч MOO тестов.

Соннет (под Claude Code) быстро осилил первые девять шагов, и на десятом застрял на два дня. Когда он таки добил десятый шаг, я решил, что так мы далеко не уйдём. Что-то фигово там в планировщике. Вместо Claude Code запустил тот же Курсор, но уже с моделью Opus 4.8. Тоже от Anthropic, как и Соннет, но поумнее. И дело наладилось. Через пару дней все шаги были выполнены, и отлажены первые пятьсот MOO тестов.

Какой вывод? Казалось бы, Композер однозначно победил: 5000 тестов супротив 500, и намного шустрее. Однако всё ровно наоборот. Смотрим исходники. В классе, представляющем собственно процессор, Композер нагенерил множество малопонятных переменных состояния. У Опуса же все переменные состояния однозначно связаны с потребностями микрокода. Общий размер исходников: 11205 строк против 6193. То есть почти в 2 раза больше. Много лишней логики - явный признак некачественного дизайна.

С отладкой каждого следующего MOO теста Композер имеет тенденцию добавлять новые переменные состояния. То есть он не врубается в работу процессора и ищет обходные пути. Опус же ничего такого себе не позволяет. Для каждого теста он глядит в суть и вносит мелкие изменения в существующий код.

Я пришёл к выводу, что продолжать с Композером бессмысленно. А вот с Опусом вполне можно бы довести симулятор i386 до ума. Если бы только он не жрал столько денег. Для хобби выходит недешёвое удовольствие.

vak

Я как-то показывал игру в стрелочки, что мне Курсор состряпал на скорую руку. Там было несколько глюков в анимации, которые тогдашний ИИ в упор не видел. Мне самому тоже не удавалось найти ошибку. Но вот на днях вышла новая модель Opus 4.8, и о чудо! Она смогла отыскать и шустро исправить все проблемы. Теперь можно играть в своё удовольствие.

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

Исходники: github.com/sergev/goarrows

vak

Вы вот хихикаете над списком вкусов, а между тем учоные собрали огромную базу FlavorDB - 25595 молекул вкуса и аромата. Вот группы, чаще всего встречающиеся среди пищевых ароматических молекул:

Категория          | Примеры дескрипторов                    
------------------ | ---------------------------------------  
Фруктовые          | fruity, citrus, berry, apple, pineapple 
Цветочные          | floral, rose, jasmine, violet           
Сладкие            | sweet, vanilla, caramel, honey          
Зелёные            | green, grassy, leafy, herbal            
Пряные             | spicy, clove, cinnamon, pepper          
Древесные          | woody, resinous, cedar                  
Землистые          | earthy, mushroom, musty                 
Ореховые и жареные | nutty, roasted, toasted                 
Мясные / умами     | meaty, savory, brothy                   
Сернистые          | sulfurous, onion, garlic                
Молочные           | creamy, buttery, cheese                 
Кислые / уксусные  | sour, acetic, vinegar

spamsink

Знаете, что бесит?

Что разные идиотские мессенджеры превращают каждое упоминание в сообщениях имён Markdown-файлов в линки на (несуществующие в 99.999...% случаев, разумеется) домены .md.

vak

Народ натренировал ИИ на миллионах рецептов всяческой еды. Статья: "Epicure: Navigating the Emergent Geometry of Food Ingredient Embeddings".

Вероятно, вся статья написана неестественным интеллектом. Читать невозможно. Но меня там заинтересовали 27 кулинарных измерений.

Группа 1: вкусо-ароматические признаки.

бальзамический
цитрусовый
землистый
жирный
цветочный
фруктовый
зелёный
мясной
мятный
ореховый
пряный
овощной
винный
древесный

Группа 2: базовые вкусы.

сладкий
горький
бульонный (умами)
жгучий
кислый

Группа 3: питательные вещества.

белок
общий жир
углеводы
энергия (ккал)
вода
клетчатка
натрий
сахара

Странно, что солёный вкус отсутствует.

vak

Человеческие языки можно разделить на "родные" и "имперские". Родной язык — на котором мы говорим с родными. Обычно они относятся к местным этносам. Имперские языки связаны с крупными государствами. Часто имперский язык становится вторым после родного. Почему Иисус говорил на арамейском? Время такое было. Все говорили на арамейском. 😀

Какие существовали имперские языки в истории человечества?

vak

В школе нас учили: суть языка в том, что каждое слово имеет отдельное значение. Обманули однако. К примеру, рассмотрим простое английское слово "keen". Значений столько, что смысл теряется. 😀

denise posting in

dw_maintenance

It's been a while since we've done a full code push rather than just hotfixes for bugs, so we are well overdue! Depending on availability, we're aiming to do one sometime soon; we'll let you know specifics once we've worked out good timing for everyone who needs to be available.

However! The reason it's been so long is we kept trying to get some of the stuff that's pending to "really finished" instead of just "mostly finished", and then we once again looked around and went "oh no, this is a really big code push with a lot of changes". Those make us nervous, because while we do a lot of testing ourselves, y'all are really creative in how you use the site and we inevitably find a bunch of edge cases when we let you loose on new code with your real-world data!

So, if folks have some spare time in the next few days, it would be a huge help if you could spend half an hour or so using the site the same way you normally do but with the "Site-Wide Canary" beta features flag turned on. Canary mode is a sort of "live testing" mode: it's your real data, but running the most up-to-date code.

Canary mode always does have a few glitches -- there may be missing text strings or errors about missing database properties, which is a limitation of how we run it. We don't need to know about those, but anything else weird that you run into, leave a comment with what you were trying to do and the error message you got.

I'll repeat that the "here be dragons" caution that's on the beta features page: some things may be broken, so don't use it for when you're doing something important. But a few more eyeballs on it before the push will help the push go more smoothly for everyone.

For folks who want to concentrate on what's changing, we haven't finished the second code tour of what's going to be in this push, but the ffirst one has a good chunk of what's going to be going live. (We'll get the second half done ASAP!)

vak

Я подумал: раз уж у нас имеется аутентичный микрокод процессора i386, и даже построенные на нём Верилоговские исходники для FPGA, не соорудить ли из этого богатства качественный симулятор?

Сделал детальный план разработки, разбитый на 14 последовательных шагов. Дал задание двум разным ИИ (Claude Code и Cursor) создать по этому плану симулятор i386. Независимо друг от друга, в разных бранчах. Поглядим, у кого лучше выйдет.

vak

Набрёл на фрагмент книги Алистера Кокбурна про разработку софта (1985-naur.pdf).

В книге "Work-Oriented Development of Software Artifacts" (1988) Pelle Ehn описывает серию проектов, исследовавших способы сделать программное обеспечение более соответствующим своему конечному применению, более удобным в использовании и создаваемым совместно программистами и конечными пользователями.

Для меня высшей точкой этой книги является то, как он рассматривает разработку программного обеспечения в контексте четырёх философов: René Descartes, Karl Marx, Martin Heidegger и Ludwig Wittgenstein.

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

Человек, работающий в стиле Маркса, прежде всего спрашивает: «Кому выгодна эта новая система? Как её внедрение изменяет структуру социальной власти?» Это осмысленный вопрос, независимо от того, нравятся вам политические теории Маркса или нет.

Человек, работающий в стиле Хайдеггера, рассматривает систему с точки зрения её эффективности как инструмента. В идеале пользователь вообще не должен «видеть» систему. Он должен видеть сквозь систему саму выполняемую задачу. Например, когда я печатаю документ, я вижу страницу, заполняющуюся текстом; я не «вижу» текстовый процессор. Опытный пианист видит создаваемую музыку, а не фортепиано; хороший плотник видит гвоздь, входящий в дерево, а не молоток. Подход Хайдеггера к оценке помогает нам создавать системы, более пригодные к использованию.

И только стиль Витгенштейна противопоставляется стилю Декарта. Человек, работающий в этом стиле, рассматривает развитие программного дизайна как разворачивание языковой игры, в которой со временем в язык добавляются новые слова.

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

Эна интересует построение общего опыта через совместную практику, использование самой практики как непосредственной основы для выявления потребностей. Иными словами, он работает с неявным знанием. Более того, он подчёркивает роль мастерства в осуществлении практик (интересно читать слова Miyamoto Musashi, указывающие почти на то же самое). Хотя я и упоминал тему мастерства, Эн развивает её гораздо более глубоко и полно.

Там ещё есть от Питера Наура, про программирование как строительство теории. И от Миямото Мусаши, самурая 17-го века, не знавшего поражений.