Чому я повинен використовувати IDE? [зачинено]

В іншому запитанні Марк високо говорить про ІДЕ, кажучи: "деякі люди все ще просто не знають", чому "їм слід використовувати одне ...". Оскільки хтось, хто використовує vim для програмування і працює в середовищі, де більшість / всі мої колеги використовують або vim, або emacs для всієї своєї роботи, які переваги IDE? Чому я повинен використовувати його?

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

Якщо ви вважаєте, що ІДЕ можуть підходити для деяких видів роботи, але не для інших, мені також цікаво дізнатись чому.

Це дійсно залежить від того, якою мовою ви користуєтесь, але в C # та Java я вважаю, що IDE корисні для:

• Швидке перехід до типу, не турбуючись про простір імен, проект тощо
• Навігація до членів, трактуючи їх як гіперпосилання
• Автозавершення, коли ви не можете запам'ятати імена всіх членів напам'ять
• Автоматичне генерування коду
• Рефакторинг (масивний)
• Організуйте імпорт (автоматично додайте відповідний імпорт на Java, використовуючи директиви в C #)
• Попередження як тип (тобто деякі помилки навіть не вимагають циклу компіляції)
• Наведіть курсор на щось, щоб побачити документи
• Одночасно корисним переглядом файлів, помилок / попереджень / тестів консолі / блоку тощо та вихідного коду на екрані.
• Простота запуску тестів одиниць з того самого вікна
• Комплексна налагодження
• Інтегрований контроль джерела
• Навігація туди, де трапилася помилка часу компіляції або виняток під час виконання безпосередньо з даних про помилку.
• І т.д.

Все це економить час. Це речі, які я міг би зробити вручну, але з більшим болем: я б краще кодував.

Заповнення коду. Це дуже допомагає при вивченні коду.

Коротка відповідь, чому я використовую IDE, - лінь.

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

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

Не потрібно використовувати IDE. Просто набагато складніше не працювати.

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

Це означає, що відповідь на оригінальне запитання не є настільки чітким. Це залежить від того, як люди на розглянутому веб-сайті використовують emacs, якщо вони в основному використовують його як текстовий редактор, або якщо вони все виходять і використовують спеціальні сценарії, вивчають команди для відповідних режимів, знають про тегування коду тощо.

Я підходжу до цього питання з протилежного напрямку. Мене виховували в програмуванні з дуже малою кількістю пістоптів у Makefile + Emacs land. З мого самого раннього компілятора на DOS, Microsoft Quick C, у мене було IDE для автоматизації речей. Я багато років працював у Visual C ++ 6.0, і коли я закінчив Enterprise Java, я працював з Borland JBuilder, а потім влаштувався на Eclipse, який став для мене дуже продуктивним.

Протягом моєї початкової самонавчання, коледжу, а тепер і професійної кар’єри я дізнався, що будь-яка велика розробка програмного забезпечення, що проводиться виключно в рамках IDE, стає контрпродуктивною. Я говорю це тому, що більшість IDE хочуть, щоб ви працювали над нимисвоєрідний стиль менеджменту як управління. Ви повинні нарізати і нарізати кубики своїми проектами. Ви керуєте своїми проектами за допомогою незвичайних діалогових вікон. Більшість IDE керують складними побудовими залежностями між проектами погано, і залежність може бути складною на 100% працювати. Я був у ситуаціях, коли IDE не створив би робочу збірку свого коду, якщо я не зробив "Очистити / відновити всіх". Нарешті, рідко існує чистий спосіб перемістити програмне забезпечення з розробки та в інші середовища, такі як QA або Production з IDE. Зазвичай це клацаючий фест, щоб створити всі свої блоки розгортання, або у вас є якийсь незручний інструмент, який постачальник IDE дає вам змогу комплектувати речі. Але знову ж таки,

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

Ручна побудова вимагає від нас пропустити деякі приємності в сучасній IDE, як фонова компіляція, але те, що ми отримуємо, є набагато критичнішим: чисті та легкі конструкції, які можуть жити в різних середовищах. "Тільки в один клік" всі ці спритні хлопці говорять? У нас це є. Наші сценарії побудови також можуть бути безпосередньо використані системами безперервної інтеграції. Побудова керованих за допомогою безперервної інтеграції дозволяє нам більш офіційно проводити стадію та мігрувати розгортання вашого коду в різні середовища, і дає нам знати про це майже відразу, коли хтось перевіряє неправильний код, який порушує тести збірки або одиниці.

По правді кажучи, моє взяття на роль будівництва від ІДЕ не зашкодило нам надто сильно. Інструменти інтелісценції та рефакторингу в Eclipse все ще повністю корисні та дійсні - фонова компіляція просто служить для підтримки цих інструментів. І, своєрідне розрізання проектів Eclipse послужило дуже приємним способом подумки розбити наші набори проблем таким чином, щоб кожен міг зрозуміти (все-таки багатослівний багатослівний на мій смак). Я думаю, що одна з найважливіших речей щодо Eclipse - це відмінна інтеграція SCM, саме це робить командний розвиток таким приємним. Ми використовуємо Subversion + Eclipse, і це було дуже продуктивним і дуже легко навчати наших людей, щоб вони стали експертами.

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

Під продуктивністю я маю на увазі здатність ефективно виконувати свою роботу з найкращими можливими результатами. ІДЕ дозволяють зробити це на багатьох рівнях. Я не є експертом Emacs, але сумніваюся, що він не має будь-яких особливостей основних ІДЕ.

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

Чому б ти не використовував щось таке потужне, якщо маєш вибір?

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

Наявність IDE має такі переваги:

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

Є набагато більше, можливо, ви повинні спробувати.

В основному IDE:

• Редактор з доповненням коду, рефакторинг та документація
• Налагоджувач
• Провідник файлової системи
• Клієнт SCMS
• Інструмент побудови

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

Ви можете мати все це (і деякі інші), використовуючи окремі інструменти або просто чудовий програмований редактор та додаткові інструменти, наприклад Emacs (а також Vim, але має трохи менше IMO IDEbility).

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

Затемнення:

Маючи підсвічування коду, компілюючи на задньому плані, вказуючи на мої помилки, коли я йду разом.

Інтеграція з javadoc, пропонуючи імена змінних за допомогою ctrl-Space.

Коли я компілюю, я отримую помилки прямо там. Я можу двічі клацнути помилку, і вона відображає відповідний рядок.

Дійсно добре інтегрований з JUnit, ctrl-F11 запускає тест, говорить мені, що тести не вдалися. Якщо у вихідному вікні є виняток, я можу двічі клацнути по рядку та перевезе мене до рядка, який не вдався. Мало того, але ctrl-F11 гарантує, що все складено перед тим, як запустити тести (це означає, що я ніколи не забуду це зробити).

Інтеграція з мурахами. Одна команда для створення та розгортання програми.

Інтеграція з налагоджувачами, включаючи віддалену налагодження веб-серверів.

Інструменти рефакторингу FANTASTIC, пошук посилань на розділ коду. Допомагає мені зрозуміти вплив змін.

Загалом, це робить мене більш продуктивним.

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

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

Але є одна перевага для IDE над Emacs / Vim, пов'язаними з ними, на яких я хочу зосередитись: Ви витрачаєте менше часу на встановлення / налаштування потрібних функцій.

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

Це безумовно призводить до підвищення продуктивності для мене. Я навіть кодую додатки Linux у Visual Studio на Vista, а потім використовую віртуальну машину Linux для їх побудови.

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

Інтеграція таких інструментів, як редактори моделей, підключення до та перегляд зовнішніх баз даних, керування колекціями «фрагментів коду», інструментів моделювання графічного інтерфейсу тощо. Усі ці речі можна було б отримати окремо, але наявність усіх у одному середовищі розробки дозволяє економити багато час і підтримує процес розвитку більш ефективним.

У різних людей можуть бути різні причини. Для мене це переваги.

1. Забезпечує комплексне відчуття проекту. Наприклад, у мене будуть всі відповідні файли проектів в одному поданні.
2. Забезпечує підвищення продуктивності коду, як
   1. Виділення синтаксису
   2. Посилання на збори
   3. Intellisense
   4. Централізований вигляд бази даних та пов'язаних з ними файлів інтерфейсу.
   5. Особливості налагодження

Кінець дня, це допомагає мені кодувати швидше, ніж я можу зробити в блокноті чи текстовій панелі. Це досить вагома причина для мене, щоб віддати перевагу IDE.

IDE може бути «вищим» вибором, залежно від того, що розробник намагається виконати.

Текстовий редактор може бути «вищим», тому що IDE, як правило, орієнтовані на одну (або невеликий вибір) мов.

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

Я не маю жодних упереджень щодо тих, хто віддає перевагу IDE або редакторам тексту, і те, і інше може бути дуже продуктивним і корисним, якщо добре вивчити !

Я думаю, що це здебільшого стосується сфери обізнаності розробника. IDE забезпечує макроскопічний вигляд робочого контексту розробника. Ви можете одночасно бачити ієрархії класів, посилання на ресурси, схеми баз даних, посилання на довідки SDK тощо. І з такою кількістю речей, на які впливають і впливають ваші натискання клавіш, і розширення обсягу архітектур та архітектурних перетинів, стає все складніше працювати виключно з одного острова коду одночасно.

OTOH, "тільки мені та vim та людині сторінки" дає мені набагато менший мікроскопічний - але інтенсивний і точний - погляд на мою роботу. Це нормально, якщо у мене є добре розроблена, добре розділена, рідко поєднана високо згуртована база коду, побудована на одній мові з одним набором статичних бібліотек, з яких можна працювати - не ваша типова ситуація, тим більше, що розміри команди розробників зростають та змінюють структуру коду з часом, відстані та особистих уподобань.

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

ОТО, я не можу уявити собі, як дістатися до цього. Концептуальна цілісність набагато менша, і кілька розробників над проектом протягом декількох місяців, набагато менша узгодженість - але IDE це підтримує, можливо, це заохочує. Тож розробнику справді потрібно (а може і легше) знати багато інших речей адекватно. Що також має перевагу допомогти їм відповісти (або навіть зрозуміти) набагато більший відсоток питань на StackOverflow. Тобто ми можемо мати глибший набір знань. І ми можемо реагувати на широкий спектр оголошень, що шукають довідки.

Речі можуть зайти занадто далеко в обох напрямках. Можливо, з областю "лише редактор" це схоже на "якщо у вас тільки молоток, все виглядає як цвях". Завдяки IDE-підходу, для того, що ви хочете скріпити разом, у вас є широкий вибір кріпильних елементів і пов'язаних з цим діапазон інструментів - назови / молотки, саморізи / викрутки, болти / гайкові ключі, клеї / клей-пістолети / хомути, магніти , і далі - все під рукою (з майстром, який допоможе розпочати роботу).

Не вважайте це виключним. Використовуйте IDE для переваг, які він надає, і переключіться на редактор тексту vim / бажаний текст, коли вам потрібно серйозну увагу.

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

На додаток до інших відповідей, я люблю поєднувати розвивальну потужність IDE з силою редагування Vim, використовуючи щось на зразок ViPlugin для Eclipse .

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

Я не розумію, про що ви питаєте. Ви запитуєте "Чи слід використовувати IDE замість ...", але я не розумію, яка альтернатива - Vim та Emacs виконують багато функцій, які вам нададуть будь-які IDE. Єдиний аспект, який вони не вирішують, що більший IDE може бути такими, як дизайнери інтерфейсу. Тоді ваше запитання зводиться до просто "що IDE я повинен використовувати" з аргументами для простішої сфери Vim та Emacs.

Для мене IDE кращий, тому що він дозволяє швидше навігацію в коді, що важливо, якщо у вас є щось на увазі. Якщо ви не використовуєте IDE, це займе більше часу, щоб дістатися до пункту призначення. Ваші думки можуть частіше заважати. Це означає, що потрібно натиснути більше клавіш / більше клавіш. Треба більше сконцентруватися на думці, як реалізувати речі. Звичайно, ви також можете записувати речі, але тоді потрібно переходити між дизайном та реалізацією. Також велике значення має дизайнер GUI. Якщо робити це вручну, це може зайняти більше часу.

На основі GUI IDE, такі як Visual Studio та Eclipse, мають ряд переваг перед текстовими IDE, такими як Emacs або vim, завдяки своїм можливостям відображення:

• Попередній перегляд WYSIWYG та редагування в реальному часі для дизайну GUI
• Ефективні редактори властивостей (наприклад, вибір кольору за допомогою палітри GUI, включаючи розміщення градієнтних зупинок тощо)
• Графічне зображення обрисів коду, взаємозв'язок файлів тощо
• Більш ефективне використання екранного нерухомості для показу точок прориву, закладок, помилок тощо
• Краще підтримка перетягування з ОС та іншими програмами
• Комплексне редагування малюнків, зображень, 3D-моделей тощо
• Відображення та редагування моделей баз даних

В основному за допомогою IDE на основі GUI ви можете отримати більше корисної інформації на екрані одразу, і ви можете переглядати / редагувати графічні частини вашої програми так само просто, як текстові.

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

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

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

IDE дозволяє легко працювати швидше і більш ... Я помітив , що я провів багато часу навігації в коді в простому текстовому редакторі ...

У гарному IDE цей час знижується, якщо IDE підтримує переходи до функцій, до попередньої позиції редагування, до змінних ... Також хороший IDE скорочує час експериментувати з різними мовними особливостями та проектами, як час запуску. може бути невеликим.

Пару причин, які я можу подумати для використання IDE:

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

І, чесно кажучи, мені подобається моя миша. Коли я використовую чисті текстові редактори, він стає самотнім.

Економить час на розробку
Полегшує життя, надаючи такі функції, як інтегрована налагодження, інтелігенція.

Їх багато, але рекомендую використовувати одне, вони більш ніж очевидні.

Я не впевнений, що між текстовим редактором та IDE є чітка лінія розмежування. Ви любите Блокнот на одному кінці шкали, а найкращі сучасні ІДЕ - на іншому, але між ними є багато чого. Більшість текстових редакторів мають виділення синтаксису; Редактори, спрямовані на програмістів, часто мають різні інші функції, такі як проста навігація кодом та автоматичне завершення. Emacs навіть дозволяє інтегрувати налагоджувач. У IDE ще десять років тому було набагато менше функцій для допомоги програмістам, ніж ви очікували від серйозного редактора тексту в ці дні.

Моя основна причина використовувати один - коли код перевищує 100 файлів.

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

Це економить час, коли вам належить зробити багато роботи.

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

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

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

З вашої точки зору, використання командного рядка може бути простішим, якби був лише один компілятор зі стандартними параметрами, це було б просто, але правда C / C ++ є гнучким, і врешті-решт, вся платформа зробіть це по-своєму, отже, IDE не марнуйте пояснення, як це зробити.

Якщо ви можете дізнатися, як виконуваний файл спілкується з ядром або якщо ви щось знаєте про дизайн компілятора, можливо, є спосіб працювати з належним командним рядком, але я сумніваюся, що у вас є.

Майкрософт або Apple, все зло, що вони були б, повинні запропонувати прямолінійний спосіб створення програми, не вводячи деталі, а оскільки створення програми безпосередньо залежить від архітектури ОС, навряд чи це буде "стандартним" як командний рядок є.

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

Крім того, я думаю, що IDE використовуються, коли доданий додаток має щось спільне з, як не дивно, графічним інтерфейсом або тим, що має інтерфейс або безпосередньо пов'язаний з ОС, тому знову ж таки, це також для людей, які будуть використовувати UI / GUI, не знаючи як це працює, тоді як люди, які запрограмують системи, не потребуватимуть цього всього.

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

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

Вирішуючи, використовувати IDE чи ні, слід враховувати лише одне, і це робить вас більш продуктивним чи ні.

Коротке запитання, така коротка відповідь :)

Це дуже залежить від того, чим ти займаєшся і якою мовою ти це робиш. Особисто я схильний не використовувати IDE (або "мій IDE складається з 3 xterms запускається vim, один працює клієнтом бази даних і один з a bash prompt або tailing журнали ", залежно від того, наскільки широко ви визначаєте" IDE ") для більшості моєї роботи, але, якби мені вдалося розробити власний графічний інтерфейс, я б шукав IDE, відповідний мові мить - IMO, IDE та графічне редагування форм чітко зроблені один для одного.