?

Log in

No account? Create an account

Wish list возможностей энвайронмента - Excelsior

May. 15th, 2010

01:16 pm - Wish list возможностей энвайронмента

Previous Entry Share Next Entry

Недавно я постучался в чят к zamotivator поговорить о моих сомнениях насчет сишарпа и дотнета. В процессе дискашена естественным образом всплыла тема IDE. Так, как с vs 2010 у меня не сложилось взаимопонимание насчет сглаживания текста, этот вопрос для меня тоже стоит весьма остро.

Спасибо Олегу, я получил очень интересное и очень детальное мнение по этому вопросу: 1) ide/debugger не нужны, 2) если они все-таки нужны, то программа написана хреново, 3) юзайте emacs для редактирования, grep для поиска и руки для рефакторинга. Для меня это звучит весьма радикально, но, тем не менее, интригующе. Надо будет при наличии свободного времени разобраться на практике.

Параллельно с вышеописанным революционным бранчем мыслей, существует и бранч эволюционный - составить список того, что мне мило сердцу в текущей связке vs 2008 + r# и оценить альтернативы, имея ввиду то, что кое-что из этого придется дописывать, а от кое-чего, может быть, даже и отказаться. Очень интересно будет мнение со стороны.

Итак, список:
1. Семантическая подсветка: used/unused, locals/fields, props/methods, strings. Лично мне это сильно облегчает парсинг и анализ кода. Может быть, я что-то делаю не так.
2. Поиск банальных синтаксических ошибок на лету. Очень удобно, лишь бы не тормозило так, как решарпер. Впрочем, как верно сказал Олег, REPL в динамических языках является адекватной заменой.
3. Интеллисенс (справка сигнатур и типов параметров, автокомплит), автоимпорт имен, а также вывод типов символов. Ессно, я не ожидаю, что это будет работать в динамических языках.
4. Навигация к определению, инкрементальный поиск классов/методов по имени или вайлдкарду.
5. Поиск: полнотекстовый, поиск использований в проекте, подсветка использований семантического элемента программы в текущем файле аля поиск в современных браузерах, но с учетом семантики (например, оверлоадов).
6. Интегрированный юнит-тест раннер с навигацией по стек-трейсу (аля решарпер).
7. Из рефакторинга, по сути, жить не могу только без переименования (неймспейсов/импортов, классов, функций, локальных переменных и параметров). Еще полезны инлайн переменной и вынос выражения в переменную но без них можно жить.
8. Спрятать/показать фрагменты кода.
9. Кастомизация билда, желательно без XML.
10. Отладка: брейк на упавших исключениях, отладка адвансед конструкций языка (для шарпа это, например, замыкания и итераторы), экстенсибилити дебажного просмотра, поддержка кастомно эмиченной дебажной инфы (для отладки сгенерированного кода).

upd от 28.01.2011. После некоторого отдыха от программирования вернулся обратно и сел кое-что покодярить в линкпаде (типа-репле для сишарпа). В результате получил следующий экспириенс:
1. Пункт 1 предыдущего списка нафиг не упал.
2. Пункт 2 предыдущего списка нафиг не упал.
3. Пункт 3 предыдущего списка в большинстве случаев не нужен. Опыт программирования без интеллисенса показывает, что мозгу так гораздо лучше концентрироваться. НО иногда реально невозможно без виджета, который бы показывал какую функцию/метод можно вызвать в данном контексте, ибо всех имен не упомнишь. Было бы крайне круто, если бы такая штука генерилась в бэкграунде на свободном ядре-двух и мгновенно показывалась по хоткею на втором мониторе.
4. Пункты 4, 5 и 7 я до сих пор считаю очень важными, даже на мелких файлах/проектах.
5. По поводу пункта 10 я серьезно пересмотрел свое мнение, ибо вещи вроде графов, для которых я хотел юзать плагины, гораздо лучше отлаживались трейсами и графвизом.

upd от 23.06.2011. Недавно в журнале у tonsky случился прекрасный дискашен To IDE or not to IDE?. В нем сабжевый топик получил новое развитие, а особенно интересно мне было почитать вот эту ветку обсуждения: http://tonsky.livejournal.com/231610.html?thread=1174714#t1174714. Я для себя оттуда вынес то, что иметь одновременно качественный текстовый редактор (отсутствие тормозов, кастомизация, удобство работы с клавиатуры) и IDE (поддержка семантики языка, интеграция типичных для платформы задач) на текущий момент невозможно. В плане, от чего-то все равно придется отказываться.

upd от 14.08.2011. Недавно я поставил себе емакс и начал подпиливать для поставленной цели: работы с дилайтом в интегрированном стиле. За неделю получилось подогнать сабж к моим привычкам после студии и заинтегрировать основные элементы воркфлова (компиляция при помощи sbt, работа с гитом). Читаем отчет: пост первый, пост второй, пост третий.

Comments:

[User Picture]
From:lionet
Date:May 15th, 2010 03:39 pm (UTC)
(Link)
Вот не поверишь — ни единого пункта из твоего списка я не использую, и не имею желание использовать!
(Reply) (Thread)
[User Picture]
From:ilya_portnov
Date:May 15th, 2010 06:46 pm (UTC)

Банально, но

(Link)
+1
:)
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 15th, 2010 08:29 pm (UTC)
(Link)
Супер! А можно описание типичной сессии кодяринга?
(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 15th, 2010 10:49 pm (UTC)
(Link)
Открыты два терминальных окна. На самом деле четыре, но два из четырёх — не основные, без них можно прожить, например, если не подключен внешний к ноутбуку монитор.

В одном терминальном окне сидит vi с файлом, который редактируется. В другом — командная строка с результатом последнего прогона make.

Типичная сессия кодинга выглядит так: хуячишь в vi в левом окошке, периодически компилируешь — в правом.

Вроде всё. А, да. Подсветки нет, ибо это вредно для мозга.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 15th, 2010 10:53 pm (UTC)
(Link)
>>Подсветки нет, ибо это вредно для мозга.
Лично мне это неслабо помогает парсить текст. Или это иллюзия, а я при этом теряю нечто гораздо важнее? Меня впечатлили ваши давешние наблюдения насчет таск-свитчинга - интересно, что я упустил в этом случае?
(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 15th, 2010 11:10 pm (UTC)
(Link)
Меня за долгие годы почти убедили в том, что подсветка не мешает, и может являться некой невредной привычкой. Но с другой стороны, при гетерогенной разработке (то в Dreamweaver, то в MSVC, то в IDEA, то ещё где) замучишься настраивать, синхронизировать, подгонять цветовые схемы друг к другу. Поэтому легче от этой привычки отказаться (я так думаю, просто у меня не было никогда её), чем постоянно иметь когнитивные проблемы с переходом с тула на тул. Но, опять же, похоже что это невредная привычка.

То, как код выглядит без подсветки: он светится изнутри. Ты видишь ровно то же, что и с подсветкой (если привык): мозг сам отмечает важные места, ты видишь структуру текста на синтаксическом, лексическом уровне. Я думаю, что подсветка — это лишняя сущность даже для мозга: если while всё время подсвечивается красным, мозг просто устраняет избыточность, давая сигнал «наверх» "тут while, я его заметил". Если while подсвеченный, то подразумевается "тут while, я его заметил, потому что написано while и он выделен красным". Если он не подсвечен, то подразумевается "тут while, потому что тут так написано и по окружающим операторам видно".

В любом случае, как бы не происходил первичный паттерн-матчинг мозгом, в итоге на уровень принятия решений приходит ровно то, что нужно для принятие решения, и ни битом больше: "вижу while".

А раз так, то происходят интересные вещи когда меняется цвет подсветки или подсветка убирается. Мозг, привыкший принимать во внимание подсветку, кричит: "ой, тут буквы w-h-i-l-e, но данных недостаточно для того, чтобы с быстро сказать, while ли это! да и написано зелёным". Мозг, который привык работать без подсветки, при смене цвета шрифта или фона совершенно не напрягается, но вот включение подсветки разными цветами сбивает его с толку: "тут написан while, но он какой-то цветной, может быть это что-то важное значит?" В любом случае, получается некий конфуз ;)
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:January 28th, 2011 03:29 pm (UTC)
(Link)
После долгого воздержания от программирования я сел покодить в линкпаде (типа-репл для сишарпа, без подсветки) и понял, что подсветка нафиг не нужна. Во дела - сам удивился =)
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 15th, 2010 11:04 pm (UTC)
(Link)
Плюс, можно пару слов в чем философское обоснование отказа от помощников в анализе коде? В том, что тогда у мозга нет искушения на что-то левое отвлекаться? Или просто "правильно" написанной программе ничего такого не нужно? Если да, то будет здорово услышать о том, что такое "правильно" написанная программа.

Еще интересно то, как вы обходитесь без дебаггера. Он тупо неприменим к вашей специфике? Он вообще не нужен потому, что вы пишете аккуратно и без багов? Его заменяют мелкозернистый репл и юнит-тесты? Или?

(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 15th, 2010 11:49 pm (UTC)
(Link)
Про первый абзац пока ничего не скажу — слишком много писать надо.

Про второй — скажу. Когда я писал в основном на C, дебаггер был нужен чтобы прочитать core файл (креш-дамп). И всё. Некоторые мои коллеги настолько были "в дебаггере", что для него писали даже скрипты, которые инструментировали gdb (gdb имеет свой скриптинг-язык). Это помогало им находить проблемы в своём коде, который был мал, прост, но похож на макароны и работал примерно так же.

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

Применим ли дебаггер к "нашей" специфике? Я много разных вещей делал, начиная от enterprise систем с окошками CRUD (для конторы под названием ИнвестЖилСтрой), заканчивая диспетчером задач для операционной системы в Cisco. В абсолютном большинстве этих задач дебаггер был "в порядке вещей", для разработчика. Так что я не могу сказать, что я делаю только то, что дебаггера не требует.

В задачах типа embedded, enterprise спасает (вернее, рулит!) логгинг. Библиотеки и подходы к логгингу, естественно, должны быть тщательно выбранными и выверенными. Это даёт больше, чем прыгание в gdb: ибо прыгание в дебаггере даёт локальный эффект, порождаемый каждый раз руками, зависящий от пальцев (или мышки), а логгинг — это уже автоматизация.

В задачах типа текущей (веб-разработка на языках высокого уровня) спасает интроспекция, логгинг тот же (который можно при желании динамически вставить в работающий процесс, который продолжает обслуживать клиентов), и юнит-тесты. Всё это даёт повторяемость и automated coverage, уровень которого в работе "через дебаггер" никто не достигает (даже если скрипты пишут к дебаггеру).
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 16th, 2010 06:29 am (UTC)
(Link)
Ага, значит, получается юзание дебаггера, с большего, это просто естественная, но вредная привычка, как, например, и таск свитчинг. Спасибо, приму к сведению.
(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 16th, 2010 01:57 pm (UTC)
(Link)
Я бы поспорил с тем, что она естественная. Помимо использования, условно говоря, логгинга и использования дебага есть более примитивная вещь, которая называется "подправим здесь единичку, и перезапустим, может починится?" Смысл такой, что происходит подгонка результата под ответ с использованием кода как чёрного ящика. На больших проектах это становится ужасающе неэффективно, поэтому народ скатывается, кто в логгинг (начиная с "добавим print вот здесь", кто в дебаг "поставим здесь брейкпоинт"). Оба этих начала (print it / брейкпоинтинг) просты, примитивны, ужасающе недостаточны для проектов покрупнее, но зато подход «print it» масштабируется в логгинг и внутреннюю инструментацию для мониторинга, а брейкпоинтинг так и остаётся процессом, выполняемым в преимущественно ручном режиме.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:January 28th, 2011 03:35 pm (UTC)
(Link)
Да, логгирование рулит. Полгода назад я этого не понимал. Признаю свою ошибку.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:January 28th, 2011 03:34 pm (UTC)
(Link)
Может быть, сейчас у вас будет время развернуть свою мысль по поводу первого пункта?

Недавно у меня произошло определенное просветление и кое в чем, из того, что мы обсуждали в каментах полгода назад, я с вами стал согласен, но до сих пор считаю, что пункты 4, 5 и 7 (навигация и пару избранных рефакторингов) очень важны.

Например, действительно круто, когда можно без проблем поменять [под]структуру проекта, перебросив классы между неймспейсами и переименовав некоторые более подходящим образом. Или же сделать поиск использований определенной сущности и оценить размеры грядущих изменений.

Да, эти тулы поощряют интеллектуальную мастурбацию бесконечного рефакторинга, но мне все-таки кажется, что выгода от них неслабая.
(Reply) (Parent) (Thread)
[User Picture]
From:cd_riper
Date:May 16th, 2010 07:29 am (UTC)
(Link)
> Для меня это звучит весьма радикально, но, тем не менее, интригующе

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

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

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

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

http://cd-riper.livejournal.com/226934.html
http://cd-riper.livejournal.com/210265.html

разворачивать холивор на тему IDE vs командная строка в очередной раз бесполезно. взрослый человек сам для себя в состоянии выбирать.

информация к размышлению -- некоторые разработчики яндекса, которые занимаются веб сервисами, написанными на плюсах, пишут код в Visual Studio. потому что они считают, что это максимально эффективный путь работы с плюсовым кодом.
(Reply) (Thread)
[User Picture]
From:lionet
Date:May 16th, 2010 02:00 pm (UTC)
(Link)
Пришёл cd-riper, насрал на "авторитетов", а затем сказал практически ровно то же самое, сославшись на свой блог ;)
(Reply) (Parent) (Thread)
[User Picture]
From:cd_riper
Date:May 16th, 2010 02:04 pm (UTC)
(Link)
не, ну вы ж не передергивайте... :)

современные IDE это наше все, а ваши грепы с емаксами мы в гробу видали...
(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 16th, 2010 07:09 pm (UTC)
(Link)
Да, грепы с эмаксами вредны — я за vi агитирую, в крайнем случае за vim, но у него подсветку надо выключать. А emacs разъедает мозг.
(Reply) (Parent) (Thread)
[User Picture]
From:Sergey Yelin
Date:May 24th, 2011 12:34 pm (UTC)
(Link)
Чем же? Я не флейма ради спрашиваю, просто интересна позиция.
Сам я обычно в Far Editor последнее время код правил, ну или Eclipse запускал, если какой-то масштабный рефакторинг надо было сделать.
С переездом на мак вернулся к подзабытому Emacs (плюс erlang-mode) со всеми выключенными в emacs "красотами" (включая меню), голое окно а-ля vim. Удобно что просмотр/редактирование и REPL в одном месте.

Да, надо попробовать выключить подсветку. :)
(Reply) (Parent) (Thread)
[User Picture]
From:permea_kra
Date:May 25th, 2011 12:14 pm (UTC)
(Link)
Емакс по сравнению с вимом подтормаживает и имеет дебильные кейбиндинги.
(Reply) (Parent) (Thread)
[User Picture]
From:cd_riper
Date:May 16th, 2010 02:17 pm (UTC)
(Link)
человеку после Visual Studio предложить vi, и рассказать как вредна подсветка синтаксиса (ага, от нее как и от ананизма, волосы на ладошках растут).
мля, ну это не смешно ни разу.
(Reply) (Parent) (Thread)
[User Picture]
From:lionet
Date:May 16th, 2010 07:05 pm (UTC)
(Link)
Вообще-то, я слез на vi именно что с Visual Studio. Ничего смешного не вижу — это достаточно обыденный процесс.

Но я не агитирую, так, на вопросы отвечаю. Первое, что я хочу подчеркнуть — это то, что IDE входит в привычку, но не приносит преимущества в результате. Насколько оно вредит (и вредит-ли!) — это другой вопрос. Вон Charles Petzold (автор известных книг по программированию под Windows) считает, что вредит: http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:January 28th, 2011 03:55 pm (UTC)
(Link)
Да, надо и сюда ответить. Действительно, у меня работа без интеллисенса как-то более погруженная что ли. Наверное, потому, что постоянное мельтешение и, что греха таить, время от времени неверные подсказки выбивают моск из контекста.
(Reply) (Parent) (Thread)
From:familom
Date:May 24th, 2011 10:41 am (UTC)
(Link)
Некоторые разработчики Bing'а не пишут код в Visual Studio, потому что мееедленно.
(Reply) (Parent) (Thread)
[User Picture]
From:cd_riper
Date:May 24th, 2011 10:46 am (UTC)
(Link)
как человек, каждый день работающий с большим плюсом проектом, могу тебе сказать, что узкое место не скорость IDE, а время компиляции и линковки.
(Reply) (Parent) (Thread)
From:familom
Date:May 24th, 2011 10:49 am (UTC)
(Link)
У нас CAD на 5М строк, компиляция и линковка естественно тормозят (поэтому распределенные), но и сама студия не очень быстрая.
(Reply) (Parent) (Thread)
[User Picture]
From:cd_riper
Date:May 24th, 2011 10:54 am (UTC)
(Link)
а чо там тормозить то может? открытие файла? ввод текста?
(Reply) (Parent) (Thread)
From:familom
Date:May 24th, 2011 07:28 pm (UTC)
(Link)
Про feacp.dll (intellisense) рассказывать? У нас почти у всех он переименован или удален. Visual Assist есть, но он тоже при старте педалит, к тому же ему часто сносит крышу в духе "boost::boost::boost::boost::". Иногда студия залипает вплоть до невозможности ввода текста. Дебаггер, хоть и нечасто, но начинает показывать абсолютный мусор и не реагирует на брейкпойнты (нужно их переустанавливать). Ну, блинкающее при разворачивании дерево проектов — уже мелочи.
(Reply) (Parent) (Thread)
From:ionial
Date:December 2nd, 2011 08:15 pm (UTC)
(Link)
Хочу добавить свои 5 копеек.
Работаю на джаве и с++, естественно пользуюсь эклипсом, а на предыдущей работе - интелиджеем.
Для с++ - Эклипс, а раньше - SlickEdit и Visual Studio.
Обратил внимание на интересные парадоксы - работая на джаве ручонки тянутся к пошаговой отладке, особенно юнит-тестов, работая на С++, даже в студии - приоритет логгингу, даже при отладке юниттеста.
Возможно, это связано с тем, что части на С++, если их тормозить дебаггером, просто будут работать совершенно иначе в силу своей мультипоточности, поэтому осознанно работаем логгингом.
На джаве, почему-то всё больше пошаговая отладка, даже, часто, удаленная, когда qa, вдруг, говорят, есть проблема.

В вопросе рабочей среды мой список необходимых фич довольно похож, но для полноты я бы добавил следующие штуки:
11. возможность интеграции с существующими билд-системами и их "comprehension", например, удобная поддержка для maven, ant, scons, make,
12. настоящая поддержка проектов и их конфигурации - либо на основании build scripts, либо собственная - проект должен четко определять какие объекты и откуда они берутся, включая dependencies и внешние includes.
13. навигация документации - для джавы - принос джавадока, для с/с++ - доксиджен если есть или man page или что там еще в boost для организации документации.
14. возможность легко прицепить исходники к внешним библиотекам и возможность делать навигацию по ним не переходя в другой проект/среду разработки
15. open call hierachy фича в эклипсе (вроде в intellij есть тоже) рулит и значительно удобнее, чем просто поиск по проекту.
(Reply) (Thread)