Системы плагинов и скрипты в современных IDE

О! Буду премного благодарен.

Vim

Рефакторинг, сборка проекта, дебаггинг, настраиваемый интерфейс и там и там есть. В чем няшность студии не ясно. В расположении меню - (в обоих можно потеряться), скорость интерфейса (да еклипс не на с++ написан, но студия монстр еще тот - не дай бог случайно открыть мелкий конфиг студией вместо блокнота), глючат обе. Может быть по сравнению с 2008, которую я последний раз пробовал, они сильно улучшились.

но я допускаю,что для крестов и c# есть какой-то другой эклипс. просто не приходилось сталкиваться.

В том то и дело что на с# раньше альтернатив не было и приходилось есть кактус.

В чем няшность студии не ясно.

продуманный и удобный интерфейс — нативный, отзывчивый, настраиваемый (юзабелен даже в дефолтном виде), самый лучший дебаггер, и все это замечательно работает (косяки есть везде, но в вижуалах их минимум, в сравнении с другими). некоторые релизы бывают лучше или хуже, и гораздо проще рассматривать конкретные версии.

в эклипсе недоумение появляется еще при первом запуске — какого хрена тулбары и вкладки занимают чуть ли не все рабочее пространство? раньше был какой-то аддон, мимикрирующий под вижуалы, но щас я его найти не могу. все эти контролы просто ОГРОМНЫ. интерфейс просто убожество. ненативный, тормозной, отзывчивость никакая, я неоднократно на лоре писал об этом. при вводе текста, он на экране отображается с офигенной задержкой после набора.

сравнивать всякие рефакторинги я не возьмусь, т.к. вижуалы я использую для крестов и шарпа, а эклипс только для жабы. это несколько разные вселенные.

через find + wc посчитал строки, понимаю что это вообще не соответствует реальности т.к. там всякие чужие SDK и пр., и в то же время я посчитал далеко не все наши исходники, но вот что получилось:

cpp/c/h/cs файлов: 43013

количество строк в этих файлах: 10727117

Спасибо. У мну проект поскромнее, хотя я могу замерить чисто исходный код там если убрать из расчета лицензионное соглашение порядка 1000000 строк было когда я мерял, 1.1 мэй би.

Просто интересно было прикинуть когда такие штуки начинают интегрировать, хотелось бы избежать подобных ситуаций :)

Но если подумать такая прикидка практически ничего не даёт, всё сильно зависит от состояния кодовой базы и количества юзекейсов при деплое.

какого хрена тулбары и вкладки занимают чуть ли не все рабочее пространство

VS: https://upload.wikimedia.org/wikipedia/ru/f/fb/Microsoft_Visual_Studio_2008_S... Eclipse: https://upload.wikimedia.org/wikipedia/commons/6/6c/Eclipse_4.2_Juno_screensh... По скриншотам так все явно наоборот.

Нативность интерфейса последнее на что я бы обращал внимание. Вот в IDEA ни разу не нативный интерфейс, но язык не поворачивается упрекнуть ее в этом.

Баг с лагом при вводе текста замечал да, но он проявляется не часто. Вроде бы помогало отключение Window > Preferences > Java > Editor > ContentAssist > Enable auto-activiation. Я к тому, что по-моему, если не считать багов, гуй студии ничем особо няшным не выделяется. Было бы круто иметь возможность подключать движок рефакторинга и т.п. к стороннему более няшному гую. В студии такого, насколько знаю, нет, а eclipse можно запустить как headless.

В QtCreator, увы, нет поддержки скриптовых плагинов.

http://terminus-font.sourceforge.net/

Попробуй его выставить в студии. Она тебе это разрешит, но по факту там не terminus будет, а какой-то другой, дефолтный шрифт. Хотя у того же блокнота проблем с terminus-ом нет никаких.

По скриншотам так все явно наоборот.

у тебя какое-то особое понимание слова «наоборот»?

табы в эклипсе хоть и меньше по размеру (26px), чем они по дефолту (32px), но по прежнему гигантские.

Вот в IDEA ни разу не нативный интерфейс, но язык не поворачивается упрекнуть ее в этом.

как ни парадоксально для тебя это прозвучит, но IDEA (точнее, ее реинкарнация Android Studio) еще хуже эклипсы :) и не только из-за ШГ в линуксе. я убил хз сколько времени, но собрать свой проект в ней так и не смог.

он проявляется не часто

у меня он проявляется абсолютно всегда, на нескольких разных компах, под линухом (несколько разных дистров) и макосью (как 9, так и 10), в разных версиях эклипсы. хз как ты сделал чтобы он у тебя проявлялся «не часто». отключать я пробовал все, до чего руки дотянулись. реакции никакой.

Было бы круто иметь возможность подключать движок рефакторинга и т.п. к стороннему более няшному гую. В студии такого, насколько знаю, нет, а eclipse можно запустить как headless.

в студии все наоборот — к ней подключаются сторонние более няшные движки «рефакторинга и т.п.».

зачем куда-то подключать (отсутствующий) движок рефакторинга вижуалов — это большой вопрос.

Попробуй его выставить в студии. Она тебе это разрешит, но по факту там не terminus будет, а какой-то другой, дефолтный шрифт. Хотя у того же блокнота проблем с terminus-ом нет никаких.

ок, завтра попробую на работе. дома нету венды.

По скриншотам так все явно наоборот.

блин, я даж не поленился измерить. в вижуалах 956x555, в эклипсе 700x533 на твоих шотах. и это ты еще работать ни там, ни там, не пытался. facepalm.jpg. типично, в вижуалах все намного компактнее настроено для работы.

то что ты померил зависит от размера экрана и октрытых боковых окон и т п. Речь шла про тулбар и вкладки. Да вкладки по умолчанию в еклипсе чуть больше, при желании можно настроить. Но в студии этих тулбаров аж 2 и забиты тем что большинство в 90% не использует от туда (копипаст и тп). И там и там лезть в настройки доводить до ума.

зачем куда-то подключать (отсутствующий) движок рефакторинга вижуалов — это большой вопрос.

У того же sublimetext gui имхо на порядок красивее еклипса и студии вместе взятых. Но с# в нем нельзя.

Но в студии этих тулбаров аж 2
И там и там лезть в настройки доводить до ума.

согласен.

тулбары в вижуалах убираются элементарно.

в эклипсе менее элементарно, но тоже убираются.

но (!) сделать гуй эклипсы компактным — то еще приключение.

а еще он аццки лагает.

У того же sublimetext gui имхо на порядок красивее еклипса и студии вместе взятых. Но с# в нем нельзя.

вероятно. но саблайм не ide.

ты кстати перечитай еще раз на что ответил. что именно ты собрался из вижуалов в саблайм подключать?

sublimetext

Он не IDE, он из другой оперы.

Но с# в нем нельзя.

кстати, я видел как люди в саблайме отлаживали C# код :)

всмысле, интерактивным дебаггером с вотчами и бряками.

но не знаю, опубликована ли эта работа.

А если б в sublime можно было «подключить плагином возможности рефакторинга и отладки с# (похоже уже может)», я бы в саму студию даже не заходил. Vim тоже не IDE, но в нем при желании можно java рефакторить)

посмотри по ссылке диплом Bruno Dinis Ormonde Medeiros на тему «Creation of an Eclipse-based IDE for the D programming language». ещё см. ссылку

модель <...>

Модель различных метапараметров, требующихся для других подсистем

Гуй нужен только как набор вьюх для всех этих вещей.

смотри в сторону LightTable и её системы плагинов.

или даже Emacs org-mode babel (у Eric Schulte есть неплохой обзор на домашней страничке: в статье в JoSS есть обзор LitProg/ReproResearch сред).

это что касается моделей с метамоделями. гуя правда нету.

а так есть ощущение, что написав на коленке Gopher+ сервер на elisp, (это ради +VIEW «набора вьюх» ) и чего-то микросервисного типа рест апи поверх можно прилепить сверху гуй и невозбранно достигнуть желаемого.

Да, у меня примерно такой же взгляд на это дело - наружу должно торчать ipc, желательно с сетвой прозрачностью.

Упирается всё как всегда в протокол[ы]. Несомненно на данный момент уже имеется ряд решений, аля ycmd и иже с ним, работающих по этому принципу.

Но они все достаточно разрозненны и плохо интегрируются друг с другом.

На хабре, там сейчас один перцуган вещает про свои наработки про vim, т.е. для людей как бы доходит потихоньку. Но очень медленно.

Идея витает в воздухе ещё со времен gdbserver, но её так никто и не ухватил за хвост.

Плагины в современной IDE устанавливаются с помощью package.el. Рыть в сторону MELPA.

но её так никто и не ухватил за хвост.

потому что те, кому это нужно, не могут, а тем, кто может, это не нужно (c)

Думаю дело не в этом, скорее в ресурсах.

Более того, учитывая куда ведут текущие тренды, таки оно запилиться.

Тем более я слабо верю в то, что те же мелкомягкие прям всю студию переписали, ради её web версии. У них даже спеки открытые, только вот транспорт подкачал.

неправда. Code::Blocks куда круче студии. он не жручий, кроссплатформенный и к нему можно прикрутить любой компилятор и вообще практически что угодно (я даже NASM прикручивала). он расчитан на кроссплатформенные проекты и на стопицот процентов удовлетворяет всем возможным настройкам проекта во всех системах. а студия - тормозное проприетарное УГ.

Насчёт тормознутости студии это спорный вопрос. И я тоже прикручивал туда всякое, например fasm.

А C::B как ни странно таки копирует студию в области юзабилити, чуть менее чем полностью. Мне не нравится ни то ни то с этой точки зрения.

Но топик таки про архитектурные особенности бэка, а не про качество фронта.

мне лично от «бэка» у IDE почти ничего не надо. я тут соглашусь с мнением, что IDE - это редактор плюс обёртка для тулчейна. и то я чаще собираю крупные проекты из командной строки. это быстрее и проще. а от IDE мне нужно редактор и возможность без особого гемора накропать тестовый проектик, чтобы что-то скомпилить и быстро проверить. ну и чтобы быстро прикручивать разные компиляторы.
томознутость студии выражается в её попытках объять необъятное. например, при подключении boost к проекту она может уйти минут на десять в парсинг всех его хэдеров (хотя нафиг это нужно). можно отключить парсинг, но тогда отвалится всё. Code::Blocks парсит оптимальнее и не страдает излишествами. к тому же, у него много плагинов и можно самому писать. и он работает под любыми системами, с которыми мне приходилось работать. удобно работать в одной IDE-шке под всеми системами. насчёт Eclipse - вроже тоже кросплатформа, но мне там ни разу не нравятся настройки: как-то сё слишком через задницу сделано. он явно не нацелен на работу с С++. а Code::Blocks писали именно программисты С++, для своих нужд. поэтому он получился удачнее.

Плагины - можно писать к любой современой ide, и даже к большинству редакторов.

По поводу парсинга той же VS - на проектах ~1кк строк кода, активно использующих буст и свою собственную шаблонную магию, тормозов не замеченно, вот качество выхлопа парсера, да - не всегда удовлетворительное.

У нас с тобой разные взгляды на IDE - как по мне мелкий тестовый проект проще запилить в vim'e аля

let &mp='gcc test.cpp -o test'

и то я чаще собираю крупные проекты из командной строки

Сборка проекта это слегка не тот вид работ, который приносит вэлуе.

А вот удобство навигации по коду, статистика зависимостей, рефакторинг, удобная отладка - это всё то, что на мой взгляд характеризуют удобную ide.

Вот как на вскидку, отладить крестовую либу, вызовы которые происходят из тестов на питоне, которые в свою очередь пускают бинарь, использующий эту либу?

В vs есть воркэраунд, который мне не удалось заставить работать не через сеть, в C::B я вообще такого из коробки не увидел, в qtc для этого есть пункт в меню отладка.

нет, как раз большие кодовые базы вообще в IDE никогда не собираются. например, я собираю ядра и мелкие дистры под эмбеддед девайсы. ни в одну IDE код ядра не засунуть. это было бы безумием.
а вот мелкие проектики на пару десятков файликов легко делать в IDE.
за более чем 20 лет программирования я так и не поняла, нафига считать какую-то статистику по коду и кому это нужно. обычно мне и навигация не нужна, я и так знаю, где что находится. я никогда не пользуюсь парсерами, которые пытаются представить классы или функции как-то графически. тоже непонятная для меня фича.
насчёт дебага - это, конечно, удобно. но мне редко приходится компилить под ту платформу, на которой я работаю. так что это только для тестовых проектиков пригождается. а там и без отладки всё понятно. если дебажить сложные сборные проекты - strace в помощь. можно прикрутить Google Breakpad, я его вот только что упоминала в одном треде. очень удобно и локально, и в продакшене.

нафига считать какую-то статистику по коду и кому это нужно

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

Например, для того что бы уменьшить количество зависимостей.

Если знаешь кодовую базу очень хорошо, или если она была написанна по большей части в чем нибудь типа vim, то обычно проблем по навигации с ней не возникает, да.

Но если например надо быстро разобраться как работает вон та здоровенная опенсурсная фигня, то лично мне перестаёт хватать grep'a, точнее не так - отсутсвие некоторых инструментов меня замедляет.

IDE это не что-то незаменимое, просто, если его правильно готовить, то оно ускоряет процесс.

До исходников ядра у меня руки пока что не добрались(хотя походу скоро придётся), но я слабо верю что они чем то принципиально отличаются от любой другой кодовой базы. Разве что системой сборки и способом деплоя.

Учитывая демки с прикрученой к emacs навигацией по ядрёным сорцам, думаю тот же qtc после небольшой допилки тоже вполне осилит, вот с отладкой уже вопрос встаёт, но насколько я знаю - это таки отдельная тема в данном случае.