Читаем Журнал «Компьютерра» № 24 от 26 июня 2007 года полностью

Журнал «Компьютерра» № 24 от 26 июня 2007 года

Полагаю разумным сделать паузу и предоставить читателям возможность сходить по незнакомым ссылкам и подробнее ознакомиться с упомянутыми материалами. Разумеется, все упомянутые продукты непросты в освоении, но усилия, потраченные на овладение ими, того стоят. Воспользовавшись возникшим вакуумом, можно не пытаться воссоздавать ранее бывшее окружение путем поиска эрзацев, а попытаться сменить видение. Решать эту задачу в одиночку сложни тяжело, но, с другой стороны, существует огромное количество технологий и продуктов, позволяющих объединять усилия различных людей в одном направлении. И эти технологии очень хорошо вписываются в структуру научного сообщества, дополняя и расширяя существующие связи между научными группами. Наличие инициативной группы, являющейся неформальным ядром такого сообщества, позволит сменить парадигму достаточно безболезненным образом. Болеетого, такая система является системой с положительной обратной связью, и, будучи запущена, может поддерживать себя сама. В качестве результатов работы такой группы можно продемонстрировать ресурс «TeX в Институте математики и механики УрО РАН». Ему уже около четырнадцати лет (восемь из них посвящены работе с MiKTeX), и история его развития может служить показательным примером того, как можно успешно внедрять новые технологии в научных учреждениях.

Почему так

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

1. Почему начато с LaTeX?

Потому, что текстовый редактор – самый частый инструмент в обиходе научного работника. Это раньше можно было получать зар– плату и заниматься измерениями. А теперь – непрерывные заявки на гранты/отчеты/статьи/презентации и прочие оргвещи, позволяющие другим членам группы проводить научные изыскания. LaTeX выбран как единое средство для написания статей, подготовки презентаций. Более того, поскольку входные файлы имеют понятный ASCII-формат, автоматизированные системы наполнения документов пишутся очень легко. И делается это при помощи скриптовых языков.

2. Почему речь идет о Python, а не о С++. Все просто. Имея опыт промышленной разработки C++, я хорошо представляю, каковы накладные расходы, связанные с его использованием.

Какие же требования следует предъявить к языку программирования для научных работников?

Опыт показывает, что следующий список близок к оптимальному:

• однозначность конструкций языка, прозрачный синтаксис;

• легкость понимания, приемлемая кривая обучения;

• кроссплатформность;

• гибкость;

• компактность программ;

• поддержка в научном

• сообществе;

• широкий набор библиотек;

• сокрытие технологических сложностей (COM, работа с XML, списки, хеши, таблицы, работа со строками, итераторы);

• возможность с равной легкостью разрабатывать как CLI-склейки, так и GUI;

• удобство отладки;

• поддержка ООП-концепций;

• быстрота выдачи готового кода (желательно с автотестами);

• возможность интроспекции.

• Имея опыт работы с C++, Java, Perl, Python, я остановился на последнем. И на нем много чего было сделано. Изумительно просто можно организовать генерацию Excel-отчетов (с раскраской и форматированием), не зная глубинно о OM. С XML очень удобно работать… и масса дру-гих вещей.

3. На Matplotlib свет клином не сошелся. Пакетов много, но я говорю о конкретном решении, которое я собрал (оценивая по многим параметрам). Перечислять все пакеты в популярной статье, наверное, ни к чему. Я хотел рассказать об общем подходе в создании АРМ научного работника.

Смысл не в том, чтобы метаться от пакета к пакету, а в том, что можно собрать под себя инструмент и далее оттачивать свое мастерство в решении конкретных задач. Я вовсе не настаиваю на конкретном пакете, я говорю о концепции. Люди, которые решат использовать open source, так или иначе должны будут включиться в community и оглядеться вокруг повнимательнее.