понедельник, 17 марта 2008 г.

Визуализация данных при помощи PyNGL

Попалась на глаза статья, посвященная визуализации научных данных с помощью питоновских библиотек. Не то чтобы я сторонник питона, но отход от использования явы в ГИС-приложениях и смежных областях очень радует, ибо мое отношение к яве "ни за что и никогда". К питону претензия только одна - язык объектный, что чревато всякими нехорошими эффектами (наподобии проблемы с параллельным выполнением кода, отсутствия средств для генерации кода и его последующего выполнения и проч.). Зато вызывает уважение, что питон сумел потеснить перл и яву, на фоне этих артефактов объектная модель питона смотрится привлекательно. Как раз вот сегодня пользовался утилитами из комплекта FWTools, а если быть точным, то питоновской оберткой к gdal, в очередной раз ругался на странную с моей точки зрения идеологию разбора параметров командной строки :-)

А вот и сама статья статья

4 комментария:

lispnik комментирует...

Что-то я не совсем понял ваши притензии к объектности :)

Проблемы с параллельным выполнением кода возникают не из-за объектности, а из-за изменяемого стостояния. Средства генерации и выполнения кода -- имеется в виду eval? Так он в питоне есть.

Я просто хочу понять вашу точку зрения и в чём вы видите выход.

Печников Алексей комментирует...

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

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

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

lispnik комментирует...

Замечательно, рад встретить ещё одного сторонника функционального программирования :)

Magik комментирует...

http://koldunov.net/?p=168
Еще одна статья про PyNGL, если интересно.


(C) Alexey Pechnikov aka MBG, mobigroup.ru