Friday, April 20, 2018

Роберту Иерузалимски "Программирование на языке Lua. Третье издание"

Lua - это легковесный динамически типизированный язык программирования, созданный для работы поверх языка С. Задумка хорошая - тяжелому и низкоуровнему С очень не хватает скриптового дополнения. Сам автор пишет, что Lua задумывался как клей между модулями написанными на С. Задача Lua не оптимизировать выполнение программы, а соединить различные блоки кода с минимальными усилиями. Именно поэтому Lua рантайм весит в развернутом состоянии в районе одного мегабайта, а также при загрузке можно определить набор стандартных библиотек (которые можно и совсем не подключать) сократив размер Lua до минимума. Все это сделало Lua широко используемым в программировании микроконтроллеров и игровых движках (которые, собственно, и послужили моей мотивацией к прочтению данной книги). 

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

У Lua и Javascript есть много общих моментов и, в принципе, понимая как работает Javascript, проблем с Lua возникнуть не должно. Представления объектов как ассоциативных массивов, области видимости переменных (по умолчанию в Lua все переменные глобальные), замыкания - все это работает очень похожим образом. Чисто теоретически, Lua можно использовать как формат описания данных, заменяя тем самым JSON, и выигрывая по скорости чтения и интерпретации данных (естественно, с запущенным интерпретатором).

Lua довольно гибкий язык и с этой гибкостью следует быть очень осторожным. Например, все функции в Lua анонимные, а если у функции есть название, то это всего лишь переменная, ссылающаяся на анонимную функцию. Что это значит? Что стоит вам переприсвоить переменную, как вы тут же навсегда потеряете свою функцию. И, несмотря на то, что в своем коде ты сам себе злобный буратино, полная мутабельность данных превращает всю ситуацию в поле из граблей. Полная мутабельность данных означает что даже библиотеку, написанную на Lua можно изменить (если программист не предпринял дополнительных мер для запрета мутабельности) и переприсвоить функции из библиотеки любое значение которое захочет пользователь. То есть ваша библиотека вместо функции может попытаться вызвать численное значение, потому что пользователь решил переприсвоить переменную, содержащую функцию. Взрыв мозга.

В Lua есть корутины (или сопрограммы) однако настоящей многопоточности нет. Добиться эмуляции многопоточности можно ручным переключением контекста, выполняя каждый шаг разных корутин. Также можно реализовать многопоточный код на С, однако стоит заметить, что тогда он будет платформо-зависимым и придется делать разную реализацию для разных платформ. Уверен в свободном доступе есть библиотеки дающие реальную многопоточность Lua корутинам.

Память в Lua контроллируется сборщиком мусора. До Lua 5.0 сборщик мусора был stop-the-world, в следующих версиях при каждом выделении памяти интерпретатор выполняет какое-то количество шагов сборщика мусора, таким образом достигается псевдо параллельность и ускоряется работа программы. Есть возможность контроллировать количество шагов сборщика мусора, отключать его и включать снова как из С так и из Lua. Любые объекты для которых память выделялась в ручную из С также должны быть собраны вручную, так как сборщик мусора о них ничего не знает.

API совместимости с С с одной стороны очень низкоуровневое, с другой максимально легковесное. Работа осуществляется через стек, на стек кладутся значения аргументов функций, со стека также забирается результат. Существуют функции позволяющие менять стек, манипулировать значениями не снимая их со стека (например конкатенировать строки). Между различными модулями используется общий реестр, хранящий глобальные значения, а также можно использовать значения upvalue, которые представляют собой замыкания, но для С функций.

"Программирование на языке Lua" считается библией языка - той книгой, которую стоит давать каждому, кто собирается использовать Lua. Тот факт что она состоит всего из 300 с лишним страниц, говорит о его размерах и о количестве знаний требующихся для его понимания. Однако компактность и легкость языка делает его сложным для разработки, в том плане, что нужно быть постоянно внимательным и следить за всем, что ты пишешь, так как ни одна IDE не может понять в динамических языках что на самом деле имел в виду программист.

Со своими целями Lua справляется очень хорошо. Писать небольшой скрипт для склейки блоков написанных на С должно быть быстро и эффективно, но писать на нем какой-то более масштабный проект кажется не лучшей затеей.

Friday, March 16, 2018

Дэниэл Киз "Множественные умы Билли Миллигана"

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

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

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

Не понравилось то, что история выглядит довольно однобоко. Тяжелая судьба, многочисленные нападки, множественные личности, описанные как защитные механизмы - все это заставляет сопереживать Билли Миллигану. Все суды также описаны с акцентом на их несправедливость. При прочтении совершенно не остается осадка спорности ситуации, кажется что с Миллиганом поступают нечестно и несправедливо. Проблема в том, что в книге представлены аргменты только защищающей стороны. Отчасти, я понимаю, что обвинительная сторона не давала интервью писателю, а может быть писатель и сам не посторался поинтересоваться аргументацией судьи при переводе Миллигана на более строгий режим, или может быть специально выдал суд, СМИ и чиновников в негативном свете. В любом случае, ощущения объективной картины нет, есть ощущение субъективной точки зрения, и это немного портит впечатление.

Я подозревал, что в государственных психиатрических клиниках США, также как и в моей родной стране не происходит ничего хорошего. Насколько мне известно, Киз выпустил еще одну книгу, конкретно про то как Миллигану жилось в клиниках строгого режима. Книга была запрещена в США за критику медицины, однако была выпущена во многих других странах. Думаю стоит почитать и ее, но с доброй долей скептицизма, с которой стоит читать и "Множественные умы Билли Миллигана".

Saturday, March 3, 2018

Jesse Schell "The Art of Game Design: A Book of Lenses"

This book is a collection of useful questions that help you to understand how to make a game better on each step of the development process from idea generation to final release. Something like Bible for a game designer.

The main idea of the book is that game designers don't create games - they create experiences. A good game should generate right emotions in a player and help the player to feel himself in the skin of someone else (like the king or military general, or coffee shop owner etc). People like games when they feel immersion and this is the main goal of a designer to create this feeling. The game is a mere instrument to achieve the main goal - create an experience. You can create an experience in different ways, not only by the game but with book or movie and even within a game genre experience can be created by sports game or board game or video game. The game designer should understand what will serve him best to deliver right feeling to the player and chose the right genre to work in.

One of the most useful skills of the game designer is listening. It is helpful on every step - from idea generation to understand the team. For me, the most insightful thing was that listening to yourself during different experiences is the key point for idea generation. Many genres of art have their own ways to deliver an experience and something you like and something you don't. If you understand what do you particularly like in one thing and don't like in another it will help you to understand more about how to deliver an experience you want to a player. Or even more: what experience you want to deliver to a player.

"The Art of game design" is the book about games, and more specifically video games (however many advice are applicable in other arts as well), so it covers all aspects of game development. It destructures the games to four main parts - Mechanics, Aesthetics, Story, and Technology. Usually, by making decisions on each of these four parts you form a game that delivers an experience you want. 

Another good advice from the book is that process of development should be iterative. You always have to start with the simplest thing, then ask yourself questions about problems you see and then constantly improve your game by answering these questions and always checking - does the game deliver an experience you want, or not.

Other advice in the book is about very concrete things that I think it doesn't make sense to retell it here. I will definitely reread certain chapters of the book if I'll finally decide to build my game.