США, Техас, Остин, клуб Continental
Воскресенье, 5 января 1987 г.

— Спасибо за приглашение, мистер Ломуто. Скоро я возвращаюсь в Англию, так что это было очень вовремя.

— Спасибо, что согласились со мной встретиться, мистер… сэр… Чарльз… Энтони Ричард… Хоар. Это большая честь для меня. Я даже не знаю, как к вам обращаться. У вас есть рыцарский титул?

— Зовите меня Тони, и, если вы позволите, я буду называть вас Нико.

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

Одетый в безупречно подогнанный костюм-тройку с нарочитой небрежностью, на какую способен только англичанин, Тони Хоар был таким же воплощением Британии, как и чашка чая. Смиренное выражение лица, с которым он попивал из своего стакана, без всяких слов выражало его мнение в споре между бурбоном и скотчем. Сидевший напротив Нико Ломуто представлял полную ему противоположность: одетый в джинсы программист, мешавший виски с колой (что для Тони было настолько возмутительно, что он сразу решил подчёркнуто это игнорировать — как резкий запах пота или оскорбительную татуировку), в состоянии некого расслабленного трепета перед гигантом информатики, с которым он только что познакомился лично.

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

— Что? Ах да, алгоритм разбиения, — Тони поднял брови в притворном изумлении, словно забыв, что каждая статья или книга о быстрой сортировке за последние пять лет упоминала их имена вместе. Очевидно, что именно это связывало этих двух людей и было причиной этой встречи, но Тони, как безупречный джентльмен, мог бы часами говорить о погоде, если бы собеседник не упомянул о стоящем в комнате розовом слоне.

Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.

Better C — это способ перенести существующие проекты на языке C на язык D в последовательной манере. Эта статья показывает пошаговый процесс конвертации нетривиального проекта из C в D и частые проблемы, которые при этом возникают.

Хотя фронтенд компилятора D dmd уже сконвертирован в D, это настолько большой проект, что его трудно целиком охватить. Мне был нужен более мелкий и скромный проект, который можно было бы целиком держать в голове, но чтобы он не был умозрительным примером.

Мне пришла на ум старая make-программа, которую я написал для компилятора C Datalight в начале 1980-х. Это реальная имплементация классической программы make, которая постоянно использовалась с начала 80-х. Она была написана на C ещё до его стандартизации, портировалась из одной системы в другую и укладывается всего в 1961 строчку кода, включая комментарии. Она до сих пор регулярно используется.

Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.

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

А может, дело не в вас? Я покажу вам, что эти ошибки не ваша вина: это вина инструментов, и если только улучшить инструменты, то ваш замок будет в безопасности.

И вам даже не придётся идти ни на какие компромиссы.

Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.

Язык D был с самого начала спроектирован так, чтобы легко и напрямую обращаться к C и, в меньшей степени, C++. Благодаря этому в нём доступны бесчисленные C-библиотеки, стандартная библиотека C и конечно же системные API, которые как правило построены на API языка C.

Но C — это не только библиотеки. На C написаны многие большие и неоценимо полезные программы, такие как операционная система Linux и значительная часть программ для неё. И хотя программы на D могут обращаться к библиотекам на C, обратное неверно. Программы на C не могут обращаться к коду на D. Невозможно (или по крайней мере очень сложно) скомпилировать несколько файлов на D и слинковать их в программу на C. Проблема в том, что скомпилированные файлы на D могут обращаться к чему-то, что существует только в рантайме D, а добавлять его в линковку обычно оказывается непрактично (рантайм довольно объёмный).

Также код на языке D не может существовать в программе, если D не контролирует функцию main(), потому что именно так происходит запуск рантайма D. Поэтому библиотеки на D оказываются недоступны для программ на C, а программы-химеры (смесь C и D) становятся непрактичными. Нельзя взять и «просто попробовать» язык D, добавляя модули на D в существующие модули программы на C.

Так было до тех пор, пока не появился Better C.

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

Хотя это только четвёртая публикация в этой серии, это уже третья, в которой я рассказываю о способах избежать использования GC. Не обманитесь: я не пытаюсь отпугнуть программистов от сборщика мусора в языке D. Как раз наоборот. Понимание того, когда и как обходиться без GC, необходимо для эффективного его использования.

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

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

Когда сборщик мусора отключён через GC.disable или запрещён к использованию атрибутом функции @nogc, память всё ещё надо откуда-то выделять. И даже если вы используете GC на всю катушку, всё равно желательно минимизировать объём и количество выделений памяти через GC. Это означает выделение памяти или на стеке, или в обычной куче. Эта статья будет посвящена первому. Выделение памяти в куче будет предметом следующей статьи.

В первой из серии статей о GC я представил сборщик мусора в языке D и возможности языка, которые его используют. Два ключевых момента, которые я пытался донести:

1. GC запускается только тогда, когда вы запрашиваете выделение памяти. Вопреки расхожему заблуждению, GC языка D не может просто взять и поставить на паузу ваш клон Майнкрафта посреди игрового цикла. Он запускается только когда вы запрашиваете память через него и только тогда, когда это необходимо.

   
   

2. Простые стратегии выделения памяти в стиле C и C++ позволяют уменьшить нагрузку на GC. Не выделяйте память внутри циклов — вместо этого как можно больше ресурсов выделяйте заранее или используйте стек. Сведите к минимуму общее число выделений памяти через GC. Эти стратегии работают благодаря пункту № 1. Разработчик может диктовать, когда допустимо запустить сборку мусора, грамотно используя выделение памяти из кучи, управляемой GC.

   
   

D, как и многие активно используемые сегодня языки, поставляется со сборщиком мусора (Garbage Collector, GC). Многие виды ПО можно разрабатывать, вообще не задумываясь о GC, в полной мере пользуясь его преимуществами. Однако у GC есть свои изъяны, и в некоторых сценариях сборка мусора нежелательна. Для таких случаев язык позволяет временно отключить сборщик мусора или даже совсем обойтись без него.

Чтобы извлечь максимум пользы от сборщика мусора и свести его недостатки к минимуму, необходимо хорошо понимать, как работает GC в языке D. Хорошей отправной точкой будет страничка «Garbage Collection» на dlang.org, которая подводит обоснование под GC в языке D и даёт несколько советов о том, как с ним работать. Это — первая из серии статей, которая призвана более подробно осветить тему.

Мы установили десять самых популярных программ с Download.com, и вы не поверите, что произошло! Впрочем, наверное, вы и сами можете догадаться: что-то ужасное. Что-то ужасное — вот что произошло. Присоединяйтесь к нашему веселью!

Уже не первый год мы сетуем на то, что нельзя спокойно порекомендовать скачать бесплатную программу, а недавно мы рассказали, как можно безопасно испытывать любое ПО при помощи виртуальной машины. И мы подумали: а почему бы не повеселиться и не посмотреть, что же, в самом деле, произойдёт, если скачивать программы как обычный ничего не подозревающий пользователь?

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

Когда я начал делать Super Meat Boy, я знал, что хорошее или плохое управление может решить судьбу игры. Я очень придирчив к управлению в играх, до такой степени, что если игра управляется плохо, я брошу её, неважно, что это за игра, и кто её сделал. Меня часто спрашивают, какие формулы я использовал, чтобы сделать передвижение, трение, сопротивление воздуха и т.п. в Super Meat Boy. На самом деле никаких формул не было… а просто большой хак. Я потратил два месяца на то, чтобы управление в SMB стало идеальным. Всё, от странного «трения», которое вы испытываете, меняя направление в воздухе, до задержки в 200 мс, которая происходит, когда вы отрываетесь от стены, — всё это основано на том, что я ощущаю во время игры. Ни одна из этих формул не базируется на физических законах, они на все сто процентов построены на ощущениях.

Когда дело доходит до устройств, я, опять же, очень разборчив. Недавно Шеннон купил контроллер Razer с непонятными кнопками, которые странно нажимаются. Я отказываюсь на нём играть. Мне не нравилось играть на PS3, когда она только вышла, потому что геймпад Sixaxis из-за отсутствия вибрации слишком лёгкий. Я толком не играл ни в одну игру на PS3, пока не купил DualShock 3. В сторону геймпада Ouya я даже не смотрю, потому что другие люди жаловались на проблемы с откликом, и я точно знаю, что тоже с ними столкнусь.

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

Сегодняшний «Бизнес-линч» напомнил о том, что я давно хочу высказать свои мысли о современном состоянии веб-дизайна, в частности, о кнопке «Наверх».

Веб-дизайн болен. Разработчики превращают сайты в веб-приложения, которые работают нормально только в правильных с их точки зрения браузерах. Повсюду плавающие элементы, которые на мобильном устройстве обязательно куда-нибудь уедут и что-нибудь загородят. Бесконечная прокрутка порою прикручена к сайту так бездумно, что чтобы добраться до ссылок в подвале, приходится судорожно долбить кнопку End (прямо как quick time event в играх). На мобильном устройстве пользоваться полной версией сайта со всеми этими «удобствами» невозможно, и разработчики делают урезанную версию сайта, называя это «адаптив-дизайн», «респонсив-дизайн» и «йет–эназер–маркетинг–буллшит–инглиш–ворд-дизайн» — по сути своей это WAP-сайты в новой личине. Мало того, эту урезанную версию пользователю ещё и навязывают. И не дай бог у сайта есть мобильное приложение: в лучшем случае вы увидите радостное сообщение об этом на весь экран, а в худшем вас, ни о чём не спрашивая, перенаправят в App Store или Google Play, и никого не интересует, что вы зашли на сайт по поисковой выдаче и не собираетесь постоянно его посещать.


За примером далеко ходить не надо

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