Я довольно давний поклонник IDE от Jetbrains. Тем же IntelliJ IDEA и PyCharm просто нет сопоставимых альтернатив с точки зрения скорости работы и удобства. Собственно говоря у меня у меня даже подписка на них оформлена из соображений “нравится проект – поддержи финансово”, но вот с CLion что-то пошло не так…
На мой взгляд основная проблема в том, что разработчики и менеджеры продукта пришедшие с платформ .NET и JVM просто не понимают что такое разработка на C/C++. В итоге идёт попытка переложить модель разработки с той же Java на C++. В крайне случае у меня сложилось именно такое ощущение как после личного общения с JetBrain-овцами на CppCon, так и после вчерашнего диалога в Twitter.
Собственно, проблема и непонимание состоит в том, что команда CLion упорно хочет видеть “проектную модель”. Я не знаю чем это вызвано, толи наличием libClang под капотом, толи архитектурными проблемами собственного парсера, но без реальной проектной модели CLion превращается в тыкву. Хотя, он даже и с реальной проектной моделью иногда превращается в тыкву, например спотыкаясь на сгенерированном через Protobuf коде.
К сожалению, такой подход не может работать в мире C++ на многих проектах сложнее Hello World. За исключением счастливчиков, которым доступно писать всё в Visual Studio, у разработчиков огромный зоопарк используемых редакторов и причина у этого довольно грустная, в теории CLion и должен был исправить эту ситуацию. Так вот, мои коллеги пишут в Sublime, Emacs, Vim, Eclipce CDT, Studio Code и многих других редакторах по большому счету потому, что все они практически одинаково плохи в роли C++ IDE. Ну может за исключением Emacs/Vim, за счёт его интеграции с Globals/CTags и Eclipse, за счёт наличия грамотно реализованного парсера C++. Но в Emacs/Vim ещё нужно уметь писать – это свой отдельный мир, а Eclipse даже на Xeon-ах с горой памяти на борту умудряется тормозить.
Если же говорить о проектной модели и почему привязка к ней делает редактор не пригодным к промышленному использованию – то её часто просто нет. К примеру на данный момент я периодически переключаюсь между несколькими проектами: один на базе CMake, второй на некой дикой смеси Make, CMake и SCons обвешанной sh/bat скриптами сверху. Так же я иногда заглядываю в проекты которые представляют из себя кучу файлов просто “для консультации”. Таким образом, в теории, я мог бы писать 1 проект из всех над которыми работаю в CLion, но есть ли в этом хоть какой-то смысл если мне нужно писать и другие проекты и иметь пусть приблизительную, но быструю навигацию по коду и хоть какую-то автоподстановку? По мне так никакого, так как привыкать к особенностям 2-х редакторов куда как менее удобно нежели всегда работать в одном. Жаль только надежда на то, что на менеджеров продукта CLion сойдет понимание проблемы угасла.
Проектная модель CLion необходима ни как какая-то “прихоть”. Это способ узнать всю нужную информацию о проекта – файлы, которые входят в проект, флаги компиляции, header search пути, флаги линковки и пр. То есть можно попытаться сделать некий UI и “спросить” все это у пользователя, но это ж будет такая же проектная модель, только еще и своя, то есть ни с чем не совместимая. Поэтому решили начать (дальше ведь будет больше добавлять) с самой популярной модели в мире кросс-платформенной разработки на C++ (чтобы это узнать, мы проводили специальное исследование) – CMake.
Анастасия – это все круто звучит, в теории, так же охотно верю что вы, JetBrains, проводили исследование. Проблема в результате – он не годен для использования и я объяснил почему. C++ проекты очень часто базируются на старых сборочных системах и их никто не будет переписывать в угоду классному редактору.
Необходимость проектной модели прихоть – уровень автоподстановки/навигации обеспечиваемой Global/CDT достаточен в повседневной жизни. Уровень поддержки C++ в Global/CDT не идеален, но он лучше чем “вообще никак” предлагаемое CLion.
Самые простые и распространенные сценарии в мире C++ (еще раз, выйдете за пределы мира JVM/.NET):
1) Развитие проекта 10+ лет отроду. Он будет либо MSVS (но у них и без CLion всё хорошо) либо на некой смеси из Make, Sh, autoconf и чего угодно вплоть до самодельной сборочной системы. Тут вы пролетаете сразу, даже если Make будете парсить.
2) Изучение исходников стороннего проекта в виде просто папки с кодом. Тут очень важна хоть какая-то, но навигация, так как любая приблизительная навигация лучше Grep.
3) Развитие нового проекта. И вот только тут CLion позволяет со скрипом (у меня CLion так и не увидел сгенерированный через FindProtobuf исходники) работать над проектом.
>> То есть можно попытаться сделать некий UI и “спросить” все это у пользователя.
В этом нет никакой необходимости. Где находятся системные include вы знаете и можете всё найти. Вы знаете директорию с кодом пользователя и можете (наверное, зависит от реализации вашего парсера) её разобрать. Будет криво и не точно? Будет, но будет работать, а не говорить что “не нашел ничего”.
Я не буду спорить, что многих разработчикам и простого Vim достаточно. Цель CLion-а именно в предоставлении умных фич, которые требуют знаний о проекте (и хорошего и точного понимания кода, иначе один рефакторинг может испортить все). В C++ довольно легко неправильно понять код. Даже для простейших вещей, типа подсветки keywords, порою требуется глубокое понимание кода (читай, парсинг/резолв).
Директории с кодом пользователя, безусловно, разобрать не достаточно. А от флагов компиляции (особенно для кросс-платформенных проектов, которые собираются на платформах отличных от платформы разработки) сильно зависит, как парсить/резолвить код.
Но опять же, если достаточно “криво и неточно”, то наверное и не нужен никакой умный редактор, а достаточно обычного Vim/Emacs.
И да, мы исследовали именно разработку в C++ мире (да и C++ разработчиков в команде достаточно), и смотрели именно на самые популярные модели там. CMake используется очень многими. На CMake переходят большие и маленькие проекты (вспомните LLVM, для примера), его активно продвигают разработчики другого тулинга (вспомните, Conan и его predefined helpers).
Но я соглашусь, что всяческие зоопарки сборочных систем вплоть до кастомных, тоже очень популярны. И мы планируем в будущем иметь поддержку для таких случаев.
А что вам мешает иметь поддержку папки с исходниками по аналогии с CDT? Там ведь парсер отлично работает, чего нельзя сказать про сам Eclipse.
Всё же позиция продуктовых менеджеров JB загадочна для меня. Вы не можете выпустить универсального редактора имея все инструменты уже в готовом состоянии.
Папку можно открыть, ничего не мешает. Возьмите вот CLion 2018.1 EAP и там уже можно. Но никакой навигации, комплишена там, конечно, нет, потому что не понятно, как это парсить/резолвить. Если CLion ошибется, то велика вероятность, что рефакторинги или еще какие-то умные действия приведут к некорректному коду.
Eclipse кстати тоже же имеет проектную модель, просто свою. И в рамках нее и парсит, не всегда корректно, особенно когда данных не хватает.
Здравствуйте, Александр!
Как-то давно вышел на ваш блог по запросу что-то вроде “С++ для новичков”.
Почитал статьи, понравилось. Я сам являюсь новичком.
Добавил сайт в закладки.
Прочитал статью о тестовом задание в яндекс, еще что-то, и Ваши размышления о том как Вы выбираете язык для нового проекта.
У Вас, насколько я помню, был приоритет:
python -> java -> C++.
У меня отсюда сформировалось понимание, что Ваше отношение к С++ “не-не, древняя тема”.
Или я так подумал, потому что сам так считал.
Сейчас же я погружаюсь в новые стандарты языка, смотрю конференции, вижу как сообщество программистов вокруг С++ только ширится, как язык идет вперед и меня всё это вовлекает, появляется воодушевление.
Затем сайт где-то забылся у меня в закладках, потерялся.
И тут мне понадобилось разобраться в cmake и тестах(запрос “cmake –target test”), снова Выдало Ваш сайт.
Увидел последнюю из новостей про С++(эту). Обрадовался, что она оказалась не древней, а, считай, свежеиспеченной
Это меня наводит на мысль, что Вы С++ не забросили. Или же вы его и не бросали, просто мне так показалось?
Хотелось бы узнать Ваше мнение насчет тезиса “C++ живее всех живых”.
С уважением,
Владимир.
> У меня отсюда сформировалось понимание, что Ваше отношение к С++ “не-не, древняя тема”.
Дело не в древности, а в том, на сколько просто найти людей на поддержку и развитие решения.
> Это меня наводит на мысль, что Вы С++ не забросили. Или же вы его и не бросали, просто мне так показалось?
Конечно, нет! то отличный и перспективный язык. Просто ему иногда есть более подходящие альтернативы.
Спасибо за ответы