`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Опять язык программирования? И опять – новый?

Статья опубликована в №38 (704) от 27 октября

+33
голоса

Есть разработки, интересные не столько результатом (и даже такие, результат которых вообще не интересен) или проектным процессом, сколько логикой принимаемых в нем решений. К сожалению, возможность «подсмотреть за логикой проектировщика» – редкость.

Увы, да. Еще одним новым языком программирования, похоже, становится больше. И это в то время, когда даже Гвидо ван Россум, автор знаменитого языка Python, призвал к замораживанию на несколько лет синтаксиса и семантики своего детища – в том числе и потому, что высокая динамика изменений языков программирования (и появления новых) утомляет опытных системных программистов, занятых разработкой реализаций этих языков. (Тут следует заметить, что и начинающих, и прикладных программистов часто меняющиеся инструменты тоже не особо радуют.) В реальности, естественно, не получается ни первого, ни второго. И на «очень еще один» язык Zimbu можно было бы вообще не обращать внимания, разве что упомянуть, что автор его, Брем Муленар, – создатель культовой расширенной реализации Vim культового же текстового редактора vi. Если бы не одно очень важное «но» – проект Zimbu настолько Open Source, что предоставляет возможность не просто увидеть и понять логику главного архитектора нового инструментального средства, но и даже попробовать в какой-то мере на нее повлиять.

Итак, самое главное, с чего начинается любой проект – мотивация разработчика. Давайте проследим за логикой Брема Муленара и попробуем с ним не согласиться (просто из вредности, речь ведь идет о «еще одном языке программирования»). Предположим, что вы – рядовой программист, – говорит Муленар, – и хотите достаточно быстро и относительно недорого написать какую-то очень хорошую нетривиальную программу: быструю, легковесную, корректную, функционально насыщенную. Какой языковый инструмент вы выберете? Раз программа должна быть быстрой и легковесной, забудьте об интерпретируемых языках. Корректность в сочетании с высокой скоростью разработки означает одно – сверхассемблеры типа популярного С для решения задачи не годятся. Если вы рядовой программист, а не гуру с PhD лучшего университета, – и С++ с прочими языковыми монстрами, и изящный, но вычурный Haskell тоже не для вас. Если вас не устраивают большая среда времени исполнения и тяжеловесный старт приложения – Java тоже не ваш выбор. Ну и наконец, если вы хотите запускать свою программу на всех платформах, где из доступного инструментального ПО есть только С-компилятор, то что же выбрать? При подобном перечне требований, – утверждает Муленар, – выбирать не из чего, поэтому надо создавать новый язык. Из-за всех этих утверждений можно, конечно, устроить большой крикливый спор, но давайте мысленно добавим к каждому из них очевидное, в общем, уточнение «в среднем». И все станет на свои места. Да, возможно, есть какие-то экстремальные отклонения, но в среднем Брем Муленар прав – язык одновременно выразительный, мощный, современный, простой в освоении и облегчающий написание корректных программ действительно нужен и сейчас. Его отсутствие остро ощущают программисты в таких критичных к качеству языковых инструментов областях, как, например, во встраиваемых (embedded) системах, где язык C по сей день остается незаменимым, в том числе и просто потому, что замены не существует. Впрочем, удачное сочетание низкоуровневых средств (например, непосредственного доступа к памяти и адресной арифметики) и эффективных высокоуровневых механизмов – предмет, заслуживающий отдельного обсуждения. Что же касается мотивации Брема Муленара, то она станет тем более понятна, если вспомнить немаленький размер реализации и популярность программы Vim на совершенно разных платформах.

Теперь ознакомимся с целями проекта. Исторически языки программирования возникали в результате или потребности хоть в каком-нибудь инструменте для платформы (почти так и было с C), или попыток улучшения и адаптации к новым парадигмам ранее созданных разработок (в какой-то мере этому соответствуют цепочки алголо- и С-подобных языков), или для некоторых нишевых применений (Pascal – обучения, Ada – встраиваемых систем управления оборонного назначения), или, наконец, просто для инструментальной поддержки различных парадигм программирования (например, функциональные языки). Особая история – языки-платформы, созданные для расширения и адаптации собственными средствами (Forth и Scala). У всех них, как продуктов некоего проектного процесса, есть нечто общее. А именно, некоторая «суперцель». В случае с Zimbu все много проще. Главная цель более чем скромна – создать еще один язык, пригодный для практических применений. А вот второстепенные цели, определяющие пригодность для практических применений, весьма интересны. Во-первых, это пригодность к чтению и пониманию исходных текстов программ. Брем Муленар неслучайно заявил эту цель первой. И неслучайно указал сочетание читабельности и понятности. Например, многие функциональные языки, характеризующиеся изысканно изящным синтаксисом, вынуждают «читателя» программы производить в уме довольное вычурное моделирование процесса исполнения, учитывающее различные скрытые механизмы (то же самое можно сказать, например, и о рекурсивных императивных программах, которые начиная с определенной степени сложности превращаются в настоящую головоломку). Что касается читабельности, то для нее Муленар находит весьма толковое определение – это баланс между количеством «слов» и «символов», избыток «слов» порождает необходимость много читать о том, что можно было бы сказать короче (классический пример многословности – Cobol), избыток символов превращает программу в шифровку (за это много и часто обоснованно критикуют Perl). К слову, весьма примечательно и соображение Муленара о необходимости понятности ключевых слов без дополнительных знаний – например, зачем использовать термин «виртуальная функция», требующий изучения терминологии объектно-ориентированного программирования, если можно сказать понятнее – «установленная по умолчанию функция»?

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

Кроме стратегии – мотивации и целей, проект Zimbu открывает и тактику рассуждений «языкостроения». И она не менее интересна. Очевидно, что каких-либо формальных требований (кроме разве что определенных ограничениями механизмов синтаксического и грамматического разбора), скажем к синтаксису отдельных конструкций языка программирования, быть не может. Поэтому проследить ход мысли разработчика, приводящий к появлению тех или иных весьма специфических структур, отличающих, например, один императивный язык от другого, – весьма привлекательная возможность. В своих рассуждениях о языковых конструкциях Брем Муленар использует прием анализа-синтеза – он «разбирает» реализации самых популярных аналогов, выносит иногда небесспорные вердикты и на их основании уже строит нечто новое. Базу для тактических решений «языкостроителя» составляют результаты укрупненного анализа «источников вдохновения» – востребованных практикой программирования языков. К таким Брем Муленар отнес Java, Python, C, C++, Ruby (и, очевидно, из персональных симпатий – D и «редкую птицу» Boo). Короткие доводы против каждой из этих «муз» весьма познавательны, как это ни странно, даже для тех, кто только собирается изучать какой-либо язык программирования. Java, поставленный Муленаром на первое место, оказался действительно весьма совершенным языком, в списке недостатков которого или нехватка синтаксического сахарка (излишняя многословность конструкций типа

модуль.класс переменная = new модуль.класс()

несколько раздражает, особенно при длинных именах модулей и классов), или всякие мелкие унаследованные крошки (невнятное ключевое слово static из С, вводящее невнятную семантику static-методов), или особенности реализации Java как платформы. Список недостатков С лаконичен – препроцессор и указатели. Здесь, увы, автор статьи вынужден с автором Zimbu поспорить. Нет, препроцессор C – безусловно, атавистическая весьма убогая конструкция, с кучей потенциальных опасностей для неумелых или очумелых программистских ручек. Но вот указатели... В действительно хорошем универсальном языке программирования они должны быть. Как и адресная арифметика. Пусть выделенные в особые классы небезопасных операций (как в упомянутом Boo, весьма интересном почему-то непопулярном языке), но они обязаны быть. Популярность С и богатство инструментальных средств убедительно доказывают – адресная арифметика и указатели программистам нужны. Другое дело, что нужны не только они, и потому хороший язык должен предлагать и безопасные механизмы.

Вдаваться в детали процесса анализа-синтеза конкретных языковых конструкций, которые приведены на сайте проекта, в журнальной статье совершенно нет нужды. Впрочем, речь даже не о них. Как уже было сказано ранее, проект Zimbu куда более интересен эталонной Open Source открытостью. Станет ли язык Zimbu чем-то значимым, получится ли он действительно удачным (в его текущем состоянии он кажется весьма симпатичным) – дело на самом деле десятое. Урок проекта не должен пропасть зря – Брем Муленар очень опытный Open Source разработчик, и потому, возможно, просто подсознательно воплотил в логике самого проектного процесса то, чего большинству Open Source проектов категорически не хватает. А именно – полностью открытый на самых ранних этапах проектный процесс. Во времена исторического материализма о таких говорили «с них надо брать пример».

+33
голоса

Напечатать Отправить другу

Читайте также

А вот и еще один новый язык – Go от Google: http://golang.org/ Это к вопросу о "высокой динамике изменений языков программирования (и появления новых)"... :))

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT