Статьи

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

Если Состояние='...' тогда
…
ИначеЕсли Состояние=’…’ тогда
…
КонецЕсли;


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

Те, кто сталкивался или сталкивается с ДКА удивлены не будут. Для остальных сделаю маленькое пояснение. Фокус в том, что параллельно исполняемые процессы можно описать с помощью НКА. В свою очередь, если есть НКА, то можно построить ДКА, который будет ему эквивалентен. Структура, которую я указал, как раз и служит для того, чтобы описать функционирование ДКА.

Конечно, на практике вряд ли кто-то будет использовать ДКА вместо НКА. Детерминированный автомат обладает кое-какими особенностями функционирования, что делает его применение на практике не слишком удобным. Другое дело - НКА. Но его можно запрограммировать с помощью последовательно исполняемого кода. Конечно, и здесь есть свои тонкости, но все они преодолимы в рамках любого языка программирования.

Я думаю, что не стоит расписывать, почему так получается, что последовательный код описывает параллельные вычисления. Собственно, тот же фокус применяется и в ОС, насколько я понимаю. Мне представляется куда более важным, что код является относительно простым и достаточно прозрачным; что НКА - это достаточно хорошо исследованный математический формализм; что решение не зависит от ОС и ЯП; что можно построить универсальный процессор, который будет исполнять автоматы. (Кстати, такой процессор у меня есть - презабавнейшая штука! Но об этом как-нибудь в другой раз.) Иными словами - вместо навороченного кода, невнятного спагетти, в котором и черт ногу сломит и солдат с ранцем завалится имеем простую и ясную как правда программу.

Иногда так случается, что нужно синхронизировать исполнение 2-х и более потоков. НКА с этим плохо справляется, для этих целей лучше использовать сети Петри (СП). Это более сложный формализм, который, к тому же, в классическом виде не реализуется. Для целей практики следует выбрать какой - либо из видов СП. Не буду их перечислять, если очень интересно - загляните в учебник. Скажу только, что здесь UML и BPML вам в помощь. Потому что и тот и другой ML является потомком СП.

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

Другая ситуация. Представим, что в вашем коде присутствует некоторая коллекция. И, время от времени, вы обращаетесь к ней, чтобы найти элемент по какому-либо условию. Уже поняли, куда я клоню? Прекрасно, но я все - же закончу. Сколько времени будет искаться элемент? При обычной линейной организации - от 1 до N итераций. Хорошо, если в коллекции не больше 1000 элементов - задержка не особо видна. А если 100 000? А если еще больше? Придется использовать деревья, иначе тормозов не избежать. Видов деревьев много, можно выбрать и на вкус и на цвет. Тем более, что сейчас, в рамках инициативы по борьбе с “велосипедами”, выходит много публикаций на эту тему.

Что же из этого следует? Чтобы быть эффективным программистом гораздо важнее знать структуры данных и способы их обработки, чем технологические навороты конкретных языков программирования. Конечно, это хорошо, когда кодер стремиться лучше изучить инструмент, который использует каждый день; когда он использует лучшие, проверенные практики; когда он соблюдает правила хорошего тона при написании кода; когда он белый, пушистый и мурлычет - но это не самое главное в нашей профессии. Без знания технологических наворотов языка можно написать очень хорошую программу. Без знания машины Тьюринга - вряд ли. Для того, чтобы писать на ЯП нужно знать 10-20 операторов, принцип структурирования программы и место, где есть приличная документация по языку и его библиотекам. К примеру, объекты можно использовать достаточно эффективно, если всего лишь знать 3 аксиомы ООП. Можно даже путать объектно-ориентированный полиморфизм с полиморфизмом в операторном программировании. А как объявляется класс - можно и в документации прочитать. Иными словами, прежде чем создать хотя бы одну табличку, учим теорию реляционных БД, а перед этим - теорию множеств и только потом читаем MSDN, форумы и прочие актуальные источники. Именно в такой последовательности, иначе каши в голове не избежать.