На C++ я программирую уже очень давно. Наверное, года с 1992-го, а может и с 1991-го. Блин, столько не живут :)
Так вот на C++ я программирую уже настолько долго, что периодически хочу сменить его на что-нибудь другое. Более лаконичное и безопасное. В первую очередь – безопасное. Со сборкой мусора. С проверками выхода за пределы буфера. Со stacktrace-ми в исключениях (да, я знаю, что в C++ с помощью дополнительных велосипедов и отладочной информации это можно получить). Пока ничего такого же быстрого и, как бы сказать, дающего возможность поизвращаться (трех-этажные шаблоны – это же увлекательное извращение) не нашел.
Через два месяца SObjectizer-4 будет семь (блин, вдуматься – СЕМЬ!) лет. Это достаточно долго. Хотя бы для того, чтобы всерьез заниматься проектированием SObjectizer-5.
Временами желания выбросить C++ и написать SObjectizer-5 “с нуля” совпадают во времени и пространстве. И я начинаю обдумывать, как мог бы выглядеть SObjectizer-5 на другом языке. На D. Или на Eiffel. Или на Scala. Ada. OCaml. C#. Вот в минувшие выходные опять смотрел в сторону Scala…
Но, практически всегда я останавливаюсь на одном вопросе: “А нужен ли будет SObjectizer на этом языке вообще?”
Для JVM-языков (Java и Scala в первую очередь) он вообще не нужен. Во-первых, потому, что для JVM сейчас и так только не ленивый клепает свои actor framework-и. Во-вторых, потому, что в мире JVM почему-то очень силен пиетет перед “правильными” решениями и технологиями. Вот J2EE и EJB – это правильные веши. Остальное – велосипедостроение.
Платформа .NET пока для меня загадка. В каких задачах она широко используется? Будет ли там востребован? Пока не понятно.
Eiffel и Ada сами по себе достаточно маргинальные языки (по крайней мере в нашей стране). Так что даже если SObjectizer-5 окажется восстребованным на Eiffel или Ada, то речь будет идти разве что об единичных применениях. Поскольку вряд ли Eiffel/Ada сами по себе применяются чаще :)
Очень хорошо могло бы быть с D. Поскольку для D сейчас вообще мало чего есть, а интерес он к себе привлекает изрядный. А тут бы мы с SObjectizer-5 подсуетились. Здорово могло бы быть, тем более, что на D приятно программировать. Одна сверхзвуковая скорость компиляции чего стоит! Но… Но пока сам D все еще в стадии формирования. И лично у меня уже нет больших надежд на то, что он когда-нибудь из этой стадии вырастет во что-то стабильное и надежное.
Так что остается C++. Со всеми его прелестями.
Положительным моментом в выборе C++ является то, что для C++ не так уж много проектов, подобных SObjectizer-у. Подтверждение чему я получил буквально вчера.
Вчера я получил письмо от француза (судя по имени и фамилии), который просил помочь в компиляции SObjectizer под Linux-ом. Я офигел. Поскольку мало того, что я не давал каких-либо анонсов в англоязычных изданиях, так еще нигде нет никакой документации по SObjectizer на английском. А тут человек нашел SObjectizer, скачал его, разобрался, что нужны еще ACE, Ruby, RubyGems и Mxx_ru. Установил все это и даже наполовину скомпилировал! Офигеть!!! (Оказалось, что он переводил документацию по SObjectizer с помощью Google Translate).
Когда же я у него спросил, откуда он узнал о SObjectizer, он ответил:
Since a long time, I search C++ toolbox make to create agents (and MAS). The majority of development made under java, but I want to use C++ for the speed execution. It seems that the majority of laboratory teams prefer java. So I try to search also under sourceforge, and I found sobjectizer existence.
Вот оно как. Дела с агентными фрейворками для C++ настолько плохи, что приходится брать инструмент с русскоязычной документацией и изучать его с помощью автоматических переводчиков. Лично я бы никогда не взялся смотреть на инструмент с французкой или португальской документацией.
А посему можно смело ориентировать SObjectizer на C++. Ведь не смотря на все свои недостатки, C++ уже давно достиг состояния immortality. Поэтому на нем пишут сейчас и еще долго будут писать. В том числе и SObjectizer ;)
Комментариев нет:
Отправить комментарий