Так ли важны фичи IDE для продуктивного написания кода? Или может быть удобный расширяемый текстовый редактор важнее?
IDE неудобны тем, что загоняют пользователя под определенный стиль работы, в котором преобладает движения мышкой, вызов всяких контекстных меню и навигацию по пользовательскому интерфейсу. В тоже время программист больше времени проводит за написанием кода. Тут ему скорее нужен эффективный текстовый редактор, чем развесистая IDE.
Поэтому я всегда предпочитал low-tech solution. VI+plugins+ctags — на первый взгляд ни ахти что, однако если освоиться, то можно творить неплохие вещи. Приемущество заключается в том, что я мог найти все эти компоненты на любой платформе, где мне приходилось работать. И не только находить, но и достаточно быстро приспосабливать под мой стиль работы. Самое интересное, что в какой-то момент Visual Studio начала меня раздражать частой необходимостью хвататься за мышку. Спасло только то, что я нашел для нее эмулятор VI.
Да, рефакторинг — это очень полезная вещь, которой обладают IDE, но не текстовые редакторы. Однако в C++ надежный автоматический рефакторинг — вещь очень редкая. Гораздо важнее, по-моему, знать методы рефакторинга, чем иметь фичи в IDE. В IDE для рефакторинга нужен доступ ко всему проекту, что это может быть невозможно из-за большого объема кода. А продвинутый текстовый редактов предоставляет необходимые возможности для организации эффективного рефакторинга в локальном виде, когда часто необходим доступ только к нескольким из тысячи файлов.
.
A>Хочу представить свою IDE, которую я использую уже много лет: http://www.youtube.com/watch?v=3Dn8p3bCwMg (видео от части шутка, но все-же в ней есть доля шутки)
A>Так ли важны фичи IDE для продуктивного написания кода? Или может быть удобный расширяемый текстовый редактор важнее?
Если есть лишнее время, чтобы тратить 6 минут на половину того, что со студией делается за 2, вперед...
A>IDE неудобны тем, что загоняют пользователя под определенный стиль работы, в котором преобладает движения мышкой, вызов всяких контекстных меню и навигацию по пользовательскому интерфейсу. В тоже время программист больше времени проводит за написанием кода. Тут ему скорее нужен эффективный текстовый редактор, чем развесистая IDE.
Ткнуть мышкой в название метода почти всегда быстрее, чем набрать его в консоли (разве что у Вас методы называются a(), b() и т.п.)
A>Поэтому я всегда предпочитал low-tech solution. VI+plugins+ctags — на первый взгляд ни ахти что, однако если освоиться, то можно творить неплохие вещи. Приемущество заключается в том, что я мог найти все эти компоненты на любой платформе, где мне приходилось работать. И не только находить, но и достаточно быстро приспосабливать под мой стиль работы. Самое интересное, что в какой-то момент Visual Studio начала меня раздражать частой необходимостью хвататься за мышку. Спасло только то, что я нашел для нее эмулятор VI.
А обеспечить себя привычной и удобной платформой перед решением задачи не судьба? Зачем привыкать к десятку платформ, если всегда можно пользоваться одной?
A>Да, рефакторинг — это очень полезная вещь, которой обладают IDE, но не текстовые редакторы. Однако в C++ надежный автоматический рефакторинг — вещь очень редкая.
Ну если "студия умеет, vim под Linux не умеет, vim под FreeBSD не умеет, vim под Cygwin не умеет, vim под MacOS не умеет" это "редкая фича", то да... A>Гораздо важнее, по-моему, знать методы рефакторинга, чем иметь фичи в IDE. В IDE для рефакторинга нужен доступ ко всему проекту, что это может быть невозможно из-за большого объема кода. А продвинутый текстовый редактов предоставляет необходимые возможности для организации эффективного рефакторинга в локальном виде, когда часто необходим доступ только к нескольким из тысячи файлов.
Одно другому не мешает. Но зная методы задача решается проще, если возню с парсингом всех файлов и "умной" заменой берет на себя IDE.
.
A>Хочу представить свою IDE, которую я использую уже много лет: http://www.youtube.com/watch?v=3Dn8p3bCwMg (видео от части шутка, но все-же в ней есть доля шутки)
A>Так ли важны фичи IDE для продуктивного написания кода? Или может быть удобный расширяемый текстовый редактор важнее?
A>...поскипано...
Думаю так:
IDE — для разработки.
Текстовый редактор — для программирования.
Разрабатывать надо чаще быстро, чем медленно, и плевать на удовольствие — ибо!
Программировать же можно позволить себе медлено, наслаждаясь процессом.
При этом разработка и программирование не исключают друг друга, но всё таки различать их имхо надо.
Ваше видео длится 4 минуты. Много вы за эти 4 минуты успели?
A>Так ли важны фичи IDE для продуктивного написания кода?
Важны.
A>Или может быть удобный расширяемый текстовый редактор важнее?
Лучше удобная, расширяемая IDE.
A>IDE неудобны тем, что загоняют пользователя под определенный стиль работы, в котором преобладает движения мышкой, вызов всяких контекстных меню и навигацию по пользовательскому интерфейсу.
Ерунда.
A>В тоже время программист больше времени проводит за написанием кода. Тут ему скорее нужен эффективный текстовый редактор, чем развесистая IDE.
Слухи об эффективности vim преувеличены.
A>Поэтому я всегда предпочитал low-tech solution. VI+plugins+ctags — на первый взгляд ни ахти что, однако если освоиться, то можно творить неплохие вещи. Приемущество заключается в том, что я мог найти все эти компоненты на любой платформе, где мне приходилось работать. И не только находить, но и достаточно быстро приспосабливать под мой стиль работы.
В лыжах и гамаке тоже можно творить неплохие вещи.
A>Самое интересное, что в какой-то момент Visual Studio начала меня раздражать частой необходимостью хвататься за мышку. Спасло только то, что я нашел для нее эмулятор VI.
Не всем под силу найти окошко настройки горячих клавиш.
A>Да, рефакторинг — это очень полезная вещь, которой обладают IDE, но не текстовые редакторы. Однако в C++ надежный автоматический рефакторинг — вещь очень редкая.
Это правда. Для С++ что ни бери, эффективной разработки не получится.
A>Гораздо важнее, по-моему, знать методы рефакторинга, чем иметь фичи в IDE.
IDE позволяют иметь и то и другое.
A>В IDE для рефакторинга нужен доступ ко всему проекту, что это может быть невозможно из-за большого объема кода. А продвинутый текстовый редактов предоставляет необходимые возможности для организации эффективного рефакторинга в локальном виде, когда часто необходим доступ только к нескольким из тысячи файлов.
"Необходимые возможности" — это поиск и замена да? В IDE такое тоже бывает
да, для программ типа hello world без разницы в чем писать
а вот если приходится иметь дело с сотнями мегабайт страшного, goto-ориентированного кода, какой вам и в кошмарах не снился то только IDE
Здравствуйте, пыщьх, Вы писали:
П>Если есть лишнее время, чтобы тратить 6 минут на половину того, что со студией делается за 2, вперед...
Спорный вопрос. Смотря что делать.
П>Ткнуть мышкой в название метода почти всегда быстрее, чем набрать его в консоли (разве что у Вас методы называются a(), b() и т.п.)
Полное имя метода никогда набирать не приходится. Либо его можно скопировать в один из буферов, либо как в случае тагов, он просто дополняется из неполного имени.
П>А обеспечить себя привычной и удобной платформой перед решением задачи не судьба? Зачем привыкать к десятку платформ, если всегда можно пользоваться одной?
Судьба у нас такая . Я не привыкаю к десятку платформ, а унифицирую их. Но и в случае с одной платформой постоянно приходится делать что нибудь не на своей машине.
.
XC>да, для программ типа hello world без разницы в чем писать XC>а вот если приходится иметь дело с сотнями мегабайт страшного, goto-ориентированного кода, какой вам и в кошмарах не снился то только IDE
Я работал с гигабайтами кода. Студия такого вообще не берет (у нее даже на разумного размера проектах ncb файлы улетают в небеса). Проблема IDE в том, что если она что-то не нашла (или просто нет такой возможности включить все в проект), то большинство фич этой IDE становятся недоступными, а сама IDE превращается в тупой текстовый редактор.
Здравствуйте, пыщьх, Вы писали:
A>>Так ли важны фичи IDE для продуктивного написания кода? Или может быть удобный расширяемый текстовый редактор важнее? П>Если есть лишнее время, чтобы тратить 6 минут на половину того, что со студией делается за 2, вперед...
Набирание кода — самая незначительная часть из всех этапов разработки. То же самое что при оптимизации добиваться прироста в 30 миллисекунд в методе выполняющемся либо 2 раза за время жизни приложения, либо никогда.
.
XC>>да, для программ типа hello world без разницы в чем писать XC>>а вот если приходится иметь дело с сотнями мегабайт страшного, goto-ориентированного кода, какой вам и в кошмарах не снился то только IDE
A>Я работал с гигабайтами кода. Студия такого вообще не берет (у нее даже на разумного размера проектах ncb файлы улетают в небеса). Проблема IDE в том, что если она что-то не нашла (или просто нет такой возможности включить все в проект), то большинство фич этой IDE становятся недоступными, а сама IDE превращается в тупой текстовый редактор.
Создается Makefile Project и прописываются руками все пути и дефайны. После чего, студия все находит. Про ncb файлы, вам жалко гигабайта на диске под временный ncb файл? Ну пишите тогда руками в vim, если собственное время ценится дешевле места на харде.
Здравствуйте, alexeiz, Вы писали:
A>IDE неудобны тем, что загоняют пользователя под определенный стиль работы, в котором преобладает движения мышкой, вызов всяких контекстных меню и навигацию по пользовательскому интерфейсу. В тоже время программист больше времени проводит за написанием кода. Тут ему скорее нужен эффективный текстовый редактор, чем развесистая IDE.
Это бред. Набор кода это уже дело десятое.
Самая большая работа это чтение кода проекта, изучение.
Единственная проблема — именно во время набора кода вносятся ошибки, поэтому IDE берет на себя задачи качественного изменения кода.
Развесистая ИДЕ нужна для того, что бы не отвлекать программиста от единственно важной функции — думать, решать задачи.
Здравствуйте, Ikemefula, Вы писали:
A>>IDE неудобны тем, что загоняют пользователя под определенный стиль работы, в котором преобладает движения мышкой, вызов всяких контекстных меню и навигацию по пользовательскому интерфейсу. В тоже время программист больше времени проводит за написанием кода. Тут ему скорее нужен эффективный текстовый редактор, чем развесистая IDE.
I>Это бред. Набор кода это уже дело десятое. I>Самая большая работа это чтение кода проекта, изучение.
+1
I>Единственная проблема — именно во время набора кода вносятся ошибки, поэтому IDE берет на себя задачи качественного изменения кода.
А вот здесь толку от нее не так и много. Умная IDE подчеркнет опечатку в идентификаторе, но логическую ошибку всё равно не заметит.
I>Развесистая ИДЕ нужна для того, что бы не отвлекать программиста от единственно важной функции — думать, решать задачи.
Ну вот весь флейм как раз о том, получается ли это у нее. Больше всего масла в огонь подливает тот факт, что в IDE почему-то кладут очень убогие текстовые редакторы.
Здравствуйте, Roman Odaisky, Вы писали:
RO>А вот здесь толку от нее не так и много. Умная IDE подчеркнет опечатку в идентификаторе, но логическую ошибку всё равно не заметит.
Ты сильно заблуждаешься насчет возможностей современных IDE под современный ЯП. Они умеют отслеживать очень большой класс ошибок, далеко не только опечатки в идентификаторе.
Здравствуйте, Roman Odaisky, Вы писали:
I>>Единственная проблема — именно во время набора кода вносятся ошибки, поэтому IDE берет на себя задачи качественного изменения кода.
RO>А вот здесь толку от нее не так и много. Умная IDE подчеркнет опечатку в идентификаторе, но логическую ошибку всё равно не заметит.
Это ты сильно не прав. Дизайнеры, визарды и всякие специальные редакторы экономят вагоны времени отладки. Рефакторинг экономит еще больше.
В текстовом редакторе ты вынужден будешь заниматься именно текстовой работой, до логики дело может просто и не дойти
I>>Развесистая ИДЕ нужна для того, что бы не отвлекать программиста от единственно важной функции — думать, решать задачи.
RO>Ну вот весь флейм как раз о том, получается ли это у нее. Больше всего масла в огонь подливает тот факт, что в IDE почему-то кладут очень убогие текстовые редакторы.
Потому что набор кода это задача не самая приоритетная и время в разработке ИДЕ уходит на более серьезные вещи, как наример отладка, рефакторинг, визарды, дизайнеры и тд и тд и тд.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, пыщьх, Вы писали:
П>>Создается Makefile Project и прописываются руками все пути и дефайны.
RO>Прямо юникс-вей .
Но при этом с трудом дотягивает до достаточно обычной конфигурации на виме.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Roman Odaisky, Вы писали:
RO>>А вот здесь толку от нее не так и много. Умная IDE подчеркнет опечатку в идентификаторе, но логическую ошибку всё равно не заметит.
НС>Ты сильно заблуждаешься насчет возможностей современных IDE под современный ЯП. Они умеют отслеживать очень большой класс ошибок, далеко не только опечатки в идентификаторе.
Здравствуйте, x-code, Вы писали:
XC>а вот если приходится иметь дело с сотнями мегабайт страшного, goto-ориентированного кода, какой вам и в кошмарах не снился то только IDE
Ну-ка, ну-ка, и что же такого полезного может делать в таком случае IDE? (кроме как мешать работать )
Здравствуйте, Ikemefula, Вы писали:
I>Это ты сильно не прав. Дизайнеры, визарды и всякие специальные редакторы экономят вагоны времени отладки. Рефакторинг экономит еще больше.
Как-то мне никогда не нужно было полагаться на визарды и дизайнеры. Обычно это либо клепка UI (дизайнеры) или там где сам язык кривоват или интерфейс библиотеки не позволяет использовать ее эффективно (визарды). В майкрософте, кстате, любят этим развлекаться. Сделают какую нибудь библиотеку, которую невозможно использовать, а потом визардов к ней прикручивают.
Кстати в расширяемых редакторах (vi, emacs) можно своих (маленьких) визардов понаписать если сильно захочется с помощью скриптов. А вот в IDE свой визард так просто не добавишь.
Здравствуйте, Roman Odaisky, Вы писали:
RO>А вот здесь толку от нее не так и много. Умная IDE подчеркнет опечатку в идентификаторе, но логическую ошибку всё равно не заметит.
Но даже тут IDE может сильно помочь.
1. Запуск юнит-тестов с автоматическим переходом к тексту упавшего теста и удобной навигацией по стектрейсу.
2. Удобная работа с отладочной печатью (см. IntelliTrace)
3. Ну и собственно отладка.
то только IDE
