Почему я должен использовать среду IDE?

В другом вопросе Mark высоко отзывается о IDE, говоря "некоторые люди все еще просто не знают", почему "они должны использовать один...". Как кто-то, кто использует vim для программирования, и работает в среде, где большинство/все мои коллеги используют vim или emacs для всей своей работы, каковы преимущества IDE? Почему я должен использовать один?

Я уверен, что это проблема для некоторых людей, и мне не интересно начинать пламенную войну, поэтому пожалуйста, ответьте только на причины, по которым вы полагаете, что подход на основе IDE превосходит. Мне не интересно узнать, почему я не должен использовать IDE; Я его уже не использую. Мне интересно слышать от "другой стороны забора", так сказать.

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

Ответ 1

Это зависит от того, какой язык вы используете, но на С# и Java я нахожу IDE полезными для:

  • Быстро переходить к типу, не беспокоясь о пространстве имен, проекте и т.д.
  • Навигация к членам, рассматривая их как гиперссылки
  • Автозаполнение, когда вы не можете запомнить имена всех членов наизусть
  • Автоматическое создание кода
  • Рефакторинг (массивный)
  • Организуйте импорт (автоматически добавляя соответствующий импорт в Java, используя директивы на С#)
  • Предупреждение по типу (например, некоторые ошибки даже не требуют цикла компиляции)
  • Наведение на что-то, чтобы увидеть документы
  • Сохранение вида файлов, ошибок/предупреждений/консольных/модульных тестов и т.д. и исходного кода на экране в то же время полезным способом.
  • Простота запуска модульных тестов из одного окна
  • Интегрированная отладка
  • Интегрированный источник управления
  • Перемещение туда, где ошибка компиляции или исключение времени выполнения происходили непосредственно из деталей ошибки.
  • Etc!

Все это экономит время. Это то, что я могу сделать вручную, но с болью: лучше бы было кодировать.

Ответ 2

Завершение кода. Это помогает в изучении кода.

Ответ 3

Короткий ответ о том, почему я использую IDE, - это лень.

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

Как я набираю код, IDE автоматически проверяет достоверность кода, я могу выделить метод и нажать F1, чтобы получить справку, щелкните правой кнопкой мыши и выберите "перейти к определению", чтобы перейти прямо к тому, где он определен. Я нажимаю одну кнопку, и приложение, с включенным отладчиком, запускается для меня. Итак, список продолжается. Все, что делает разработчик на повседневной основе, собирается под одной крышей.

Нет необходимости использовать среду IDE. Это гораздо труднее не делать.

Ответ 4

Я не считаю справедливым классический "текстовый редактор и консольное окно против IDE", когда "текстовый редактор" действительно emacs. Большинство функций, характерных для IDE: s, также находятся в emacs. Или, возможно, они даже появились там, а современные IDE: s - это в основном улучшения/упрощения интерфейса.

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

Ответ 5

Я пришел к этому вопросу с противоположного направления. Я был воспитан в программировании с очень небольшим количеством пит-стопов в земле Makefile + Emacs. От моего самого раннего компилятора на DOS, Microsoft Quick C, у меня была IDE для автоматизации вещей. Я много лет работал в Visual С++ 6.0, и когда я окончил Enterprise Enterprise, я работал с Borland JBuilder, а затем обосновался на Eclipse, который стал очень продуктивным для меня.

На протяжении всего моего первоначального обучения, обучения и профессиональной карьеры я пришел к выводу, что любая крупная разработка программного обеспечения, выполненная исключительно внутри IDE, становится контрпродуктивной. Я говорю об этом, потому что большинство IDE хочет, чтобы вы работали в своем стиле I-control-how-the-world-works. Вы должны нарезать и кусать свои проекты по их линиям. Вы управляете своими сборками проектов, используя свои нечетные диалоговые окна. Большинство IDE управляют сложными зависимостями построения проектов между проектами, а зависимости могут быть трудными для работы на 100%. Я был в ситуациях, когда IDE не создавала рабочую сборку моего кода, если бы я не делал Clean/Rebuild All. Наконец, редко существует простой способ переноса программного обеспечения из разработки и в другие среды, такие как QA или Production, из среды IDE. Обычно это щекотливый праздник, чтобы получить все ваши единицы развертывания, или у вас есть какой-то неудобный инструмент, который поставщик IDE дает вам возможность объединить вещи. Но опять же, этот инструмент обычно требует, чтобы ваш проект и структура сборки полностью соответствовали их правилам - и иногда это просто не будет работать для требований ваших проектов.

Я узнал, что для крупномасштабного развития с командой мы можем быть наиболее продуктивными, если разрабатываем наш код с помощью IDE и делаем все наши сборки с помощью написанных вручную сценариев командной строки. (Нам нравится Apache Ant для разработки Java.) Мы обнаружили, что запуск наших скриптов из IDE - это просто флеш-клик или кошмар автоматизации для сложных сборок, намного проще (и менее разрушительно) на alt + tab out к оболочке и запустить там скрипты.

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

По правде говоря, моя роль в создании вне IDE не повредила нам слишком плохо. Инструменты intellisense и refactoring в Eclipse по-прежнему полностью полезны и действительны - фоновая компиляция просто служит для поддержки этих инструментов. И, Eclipse - своеобразная обработка проектов, - это очень хороший способ мысленно разрушить наши проблемы, чтобы все могли понять (хотя все же немного подробный для моих вкусов). Я думаю, что одна из самых важных вещей в Eclipse - отличная интеграция с SCM, что делает развитие команды таким приятным. Мы используем Subversion + Eclipse, и это было очень продуктивно и очень легко обучить наших людей, чтобы они стали экспертами.

Ответ 6

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

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

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

Почему вы не использовали бы что-то настолько мощное, если у вас есть выбор?

В качестве эксперимента возьмитесь за использование среды IDE, скажем, за 30 дней, и посмотрите, как вы себя чувствуете. Я хотел бы прочитать ваши мысли об опыте.

Ответ 7

Наличие среды IDE имеет следующие преимущества:

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

Есть намного больше, возможно, вы должны попробовать.

Ответ 8

IDE в основном:

  • Редактор с завершением кода, рефакторингом и документацией
  • Debugger
  • Проводник файловой системы
  • Клиент SCMS
  • Инструмент сборки

все в одном пакете.

У вас может быть все это (и еще несколько) с помощью отдельных инструментов или просто отличный программируемый редактор и дополнительные инструменты, такие как Emacs (Vim также, но немного меньше IDEbility IMO).

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

Ответ 9

Eclipse:

Подчеркивая код, компилируя в фоновом режиме, указывая на мои ошибки, когда я иду.

Интеграция с javadoc, предлагающая имена переменных ctrl-Space.

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

Действительно хорошо интегрированный с JUnit, ctrl-F11 запускает тест, говорит, что тесты потерпели неудачу. Если в окне вывода есть исключение, я могу дважды щелкнуть по строке и перевести меня в строку, которая не удалась. Не только это, но ctrl-F11 гарантирует, что все будет скомпилировано до запуска тестов (что означает, что я никогда не забываю это делать).

Интеграция с ant. Одна команда для создания и развертывания приложения.

Интеграция с отладчиками, в том числе удаленная отладка веб-серверов.

FANTASTIC инструменты рефакторинга, поиск ссылок на раздел кода. Помогает мне узнать о влиянии изменения.

В целом, это делает меня более продуктивным.

Ответ 10

Это определенно приводит к улучшению производительности для меня. До такой степени, что я даже кодирую приложения Linux в Visual Studio на Vista, а затем использую виртуальную машину Linux для их создания.

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

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

Ответ 11

Я использовал Emacs в качестве основной среды для разработки и почты/новостей в течение примерно 10 лет (1994-2004). Я обнаружил мощь IDE, когда я заставил себя изучить Java в 2004 году, и, к моему удивлению, мне действительно понравилась IDE (IntelliJ IDEA).

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

Но есть одно преимущество с IDE над средами, связанными с Emacs/Vim, на которых я хочу сосредоточиться: вы тратите меньше времени на установку/настройку функций, которые вы хотите.

С Wing IDE (для Python) Я готов начать разработку через 15-20 минут после установки. Не знаю, сколько часов мне понадобится, чтобы получить функции, которые я использую и работаю с Emacs/Vim.:)

Ответ 12

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

  • Обеспечивает целостность проекта. Например, у меня будут все связанные файлы проектов в одном представлении.
  • Обеспечивает повышенную производительность кода, например
    • Подсветка синтаксиса
    • Обращение сборок
    • Intellisense
    • Централизованное представление базы данных и связанных с ней файлов пользовательского интерфейса.
    • Функции отладки

Конец дня, это помогает мне кодировать быстрее, чем я могу сделать в блокноте или на клавиатуре. Это довольно хорошая причина для меня, чтобы предпочесть IDE.

Ответ 13

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

Текстовый редактор может быть "превосходным", потому что IDE обычно ориентированы на один (или небольшой выбор) языков.

Если разработчик проводит большую часть своего времени в одном языке или "кластере" родственных языков (например, С# и T-SQL), в одной ОС, затем в графическом интерфейсе, отладке, intellisense, рефакторинге и т.д. инструменты, предлагаемые хорошей IDE, могут быть очень привлекательными. Если, например, вы проводите большую часть своего времени, работая в VB.NET, и, возможно, немного T-SQL время от времени, в среде Windows, тогда вам будет довольно глупо не смотреть на Visual Studio или сопоставимую среду IDE.

У меня нет предрассудков по отношению к тем, кто предпочитает IDE или текстовые редакторы, оба могут быть очень продуктивными и полезными, если они будут хорошо изучены!

Ответ 14

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

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

В настоящее время я работаю над проектами в Flex и .NET. Одна из самых приятных вещей в Flex - это то, как несколько разных способов сделать стандартную вещь - вытащить данные из базы данных, открыть/закрыть/прочитать/записать файл и т.д. (Тем не менее, я использую Flex Builder/Eclipse IDE - типичный тяжелый пример, такой как VS, потому что я все еще изучаю основы, и мне нужны тренировочные колеса. Я ожидаю, что смогу вернуться к vim, как только я буду уверен в своих моделях.) В этой точке зрения я могу сделать то, что Мне нужно сделать профессионально, зная несколько вещей действительно очень хорошо.

OTOH, я не могу себе представить, что с этим связано с .NET, потому что представление, которое я должен поддерживать, продолжает расширяться и меняться. Там гораздо меньше концептуальной целостности и над несколькими разработчиками проекта в течение нескольких месяцев, гораздо меньше согласованности, но IDE поддерживает это, возможно, поощряет его. Таким образом, разработчику действительно нужно (и, что легче), узнать многое другое. Что также может помочь им ответить (или даже понять) намного более высокий процент вопросов в StackOverflow. То есть мы можем иметь более глубокий стек знаний. И мы можем отреагировать на более широкий спектр объявлений, предназначенных для помощи.

Вещи могут зайти слишком далеко в обоих направлениях. Может быть, с областью "только для редакторов", это похоже на "если у вас только молоток, все выглядит как гвоздь". Благодаря подходу IDE, для чего вы хотите скреплять друг с другом, у вас есть широкий выбор крепежных элементов и соответствующих диапазонов инструментов для выбора: - налы/молотки, шурупы/отвертки, болты/гаечные ключи, клеи/клееные пушки/зажимы, магниты, и все и все - на кончиках ваших пальцев (с помощью мастера, который поможет вам начать работу).

Ответ 15

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

Я нашел IDE лучше для рефакторинга, просмотра и отладки и для определения того, что делать. Небольшие вещи затем выполняются прямо в среде IDE, большие вещи, которые я переворачиваю в vim, чтобы закончить работу.

Ответ 16

В дополнение к другим ответам, я люблю комбинировать развивающуюся мощь IDE с возможностью редактирования Vim, используя что-то вроде ViPlugin для Eclipse.

Ответ 17

IntelliSense, интегрированный отладчик и непосредственное окно делают меня чрезвычайно более продуктивным (Visual Studio 2008). Со всем, что у меня под рукой, я могу сохранить подавляющее большинство огромного проекта внутри моей головы при написании кода. Microsoft может продолжать бросать мяч на свои ОС, но Visual Studio является одним из лучших продуктов, когда-либо созданных.

Ответ 18

Я не понимаю, о чем вы спрашиваете. Вы спрашиваете: "Должен ли я использовать IDE вместо...", но я не понимаю, что альтернатива - Vim и Emacs выполняет множество функций, которые предоставит вам IDE. Единственный аспект, с которым они не справляются, заключается в том, что большая IDE может быть подобна дизайнеру пользовательского интерфейса. Тогда ваш вопрос сводится к простому "тому, что IDE следует использовать" с аргументами, которые необходимо сделать для более простой области Vim и Emacs.

Ответ 19

Для меня среда IDE лучше, потому что она позволяет ускорить навигацию в коде, что важно, если у вас есть что-то в своем уме для реализации. Предположим, что вы не используете IDE, требуется больше времени, чтобы добраться до места назначения. Чаще всего ваши мысли могут быть перепутаны. Это означает, что нужно нажать несколько кликов/больше клавиш. Нужно больше сосредоточиться на мысли о том, как реализовать вещи. Конечно, вы тоже можете записывать вещи, но затем нужно переходить между дизайном и реализацией. Кроме того, дизайнер GUI имеет большое значение. Если вы сделаете это вручную, это может занять больше времени.

Ответ 20

Экономит время на разработку
Делает жизнь проще, предоставляя такие функции, как Интегрированная отладка, intellisense.

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

Ответ 21

Я не уверен, что существует четкая разделительная линия между текстовым редактором и IDE. У вас есть "Блокнот" на одном конце шкалы, а лучшие современные IDE - на другом, но между ними много чего. Большинство текстовых редакторов имеют подсветку синтаксиса; редакторы, ориентированные на программистов, часто имеют различные другие функции, такие как легкая навигация по коду и автоматическое завершение. Emacs даже позволяет интегрировать отладчик. У IDE еще десять лет назад было гораздо меньше возможностей, чтобы помочь программистам, чем вы ожидали от серьезного текстового редактора в наши дни.

Ответ 22

Моя основная причина использовать его - когда код выходит за пределы 100 файлов.

Хотя ctags могут выполнять работу, некоторые IDE имеют довольно хороший способ легко перемещаться по файлам.

Это экономит время, когда у вас есть много работы.

Ответ 23

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

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

Ответ 24

IDE на основе графического интерфейса, такие как Visual Studio и Eclipse, имеют несколько преимуществ перед текстовыми IDE, такими как Emacs или vim, из-за их возможностей отображения:

  • Предварительный просмотр WYSIWYG и редактирование в реальном времени для дизайна графического интерфейса.
  • Эффективные редакторы свойств (например, выбор цвета с использованием палитры GUI, включая остановки градиента позиционирования и т.д.).
  • Графическое изображение контуров кода, файловых взаимосвязей и т.д.
  • Более эффективное использование экранной недвижимости для отображения точек останова, закладок, ошибок и т.д.
  • Улучшенная поддержка перетаскивания с ОС и другими приложениями
  • Интегрированное редактирование рисунков, изображений, 3D-моделей и т.д.
  • Отображение и редактирование моделей баз данных

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

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

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

Ответ 25

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

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

Мой дикий ответ о том, что существует пламенная война IDE/Command-line, заключается только в том, что исполняемое здание C/С++ не очень хорошо обрабатывается со стандартизованной точки зрения, в отличие от языка D; каждая платформа обрабатывает компиляцию/привязку/etc по-своему, поэтому, чтобы сделать ее менее беспорядочной, они создают среду IDE.

С вашей точки зрения было бы проще использовать командную строку, если бы был только один компилятор со стандартными параметрами, это было бы просто, но правда в C/С++ является гибкой, поэтому в конце, все платформы делают это по-своему, поэтому среда IDE не путается, объясняя, как это сделать.

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

Microsoft или Apple, все зло, которым они были бы, должны предложить прямой способ создания приложения без ввода деталей, а так как создание приложения напрямую зависит от архитектуры ОС, это вряд ли будет "стандартным" ", как и в командной строке.

Проще говоря, большие и сложные приложения, где вы не хотите углубляться в то, что он делает → IDE, небольшие части программного обеспечения или простое системное программное обеспечение - дизайн → командной строки. За исключением, конечно, тех изящных библиотек, которые вставляют Makefile, но это другая история.

Кроме того, я думаю, что IDE используются, когда приложение имеет какое-то отношение, по иронии судьбы, графический интерфейс или что-то, что имеет интерфейс или напрямую связано с ОС, поэтому опять же для людей, которые будут использовать интерфейс /GUI, не зная, как это работает, в то время как людям, которые будут программировать системы, не потребуется все это.

IDE - просто современное дерьмо, но я думаю, что через 100 лет командная строка все равно будет существовать.

Ответ 26

Я также почти исключительно использую Vim (почти потому, что сейчас я пытаюсь изучить emacs) для всех моих разработок. Я считаю, что явная интуиция (из GUI, конечно) является основной причиной, по которой люди любят использовать IDE. Будучи интуитивно понятным, для этого не требуется слишком мало обучения. Чем меньше накладные расходы на обучение, тем больше они могут получить работу.

Ответ 27

Мне нравится IDE, потому что у меня много функций на кончиках пальцев. Редактирование/Компиляция/видимость файлов в проекте - это все, что я ценю в среде IDE. Я использую Visual Studio сейчас, но в прежней жизни я использовал SlickEdit и обнаружил, что это упростило мой процесс разработки, чем когда я его не использовал.

Ответ 28

При принятии решения о том, следует ли использовать IDE или нет, нужно учитывать только одно: и что делает вас более продуктивным или нет.

Короткий вопрос так короткий ответ:)

Ответ 29

Несколько причин, которые я могу придумать для использования IDE:

  • Интегрированная помощь - любимая.
  • Встроенный рефакторинг с предварительным просмотром Visual Studio
  • IntelliSense, синтаксис hightlighting, простота навигации для крупных проектов, интегрированная отладка и т.д. (хотя я знаю, с добавками, которые вы, вероятно, можете получить многое из этого с Emacs и Vim).
  • Кроме того, я думаю, что в настоящее время среда IDE имеет более широкую пользовательскую базу и, вероятно, больше людей разрабатывает надстройки для них, но я могу ошибаться.

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

Ответ 30

Проще говоря, среда IDE предлагает дополнительные функции экономии времени над простым редактором.