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