¿Por qué debería usar un IDE? [cerrado]

En otra pregunta, Mark habla muy bien de los IDE, diciendo que "algunas personas todavía no saben" por qué "deberían usar uno ...". Como alguien que usa vim para la programación y trabaja en un entorno donde la mayoría / todos mis colegas usan vim o emacs para todo su trabajo, ¿cuáles son las ventajas de los IDE? ¿Por qué debería usar uno?

Estoy seguro de que este es un problema acusado para algunas personas, y no estoy interesado en comenzar una guerra de llamas, así que solo responda con las razones por las que cree que un enfoque basado en IDE es superior . No me interesa saber por qué no debería usar un IDE; Ya no uso uno. Estoy interesado en escuchar "del otro lado de la cerca", por así decirlo.

Si cree que los IDE pueden ser adecuados para algunos tipos de trabajo pero no para otros, también me interesa saber por qué.

Realmente depende del lenguaje que esté utilizando, pero en C # y Java encuentro que los IDE son beneficiosos para:

• Navegando rápidamente a un tipo sin tener que preocuparse por el espacio de nombres, proyecto, etc.
• Navegar a los miembros tratándolos como hipervínculos
• Autocompletar cuando no puede recordar los nombres de todos los miembros de memoria
• Generación automática de código.
• Refactorización (masiva)
• Organice las importaciones (agregue automáticamente las importaciones apropiadas en Java, utilizando directivas en C #)
• Warning-as-you-type (es decir, algunos errores ni siquiera requieren un ciclo de compilación)
• Pasando el cursor sobre algo para ver los documentos
• Mantener una vista de archivos, errores / advertencias / pruebas de consola / unidad, etc. y código fuente, todo en la pantalla al mismo tiempo de una manera útil
• Facilidad de ejecutar pruebas unitarias desde la misma ventana
• Depuración integrada
• Control de fuente integrado
• Navegando hacia donde ocurrió un error en tiempo de compilación o una excepción en tiempo de ejecución directamente desde los detalles del error.
• Etc!

Todo esto ahorra tiempo. Son cosas que podría hacer manualmente, pero con más dolor: prefiero codificar.

Código de finalización. Ayuda mucho con la exploración de código.

La respuesta breve de por qué uso un IDE es la pereza.

Soy un alma perezosa a la que no le gusta hacer las cosas de una manera difícil cuando hay una manera fácil de hacerlo. Los IDE hacen la vida fácil y nos atraen a la gente perezosa.

A medida que escribo el código, el IDE verifica automáticamente la validez del código, puedo resaltar un método y presionar F1 para obtener ayuda, hacer clic derecho y seleccionar "ir a definición" para saltar directamente a donde está definido. Aprieto un botón y la aplicación, con el depurador conectado automáticamente, se inicia para mí. Y la lista continúa. Todas las cosas que un desarrollador hace a diario se reúnen bajo un mismo techo.

No hay necesidad de usar un IDE. Es mucho más difícil trabajar para no hacerlo.

No creo que sea justo hacer el clásico "editor de texto y ventana de consola vs IDE" cuando el "editor de texto" es realmente emacs. La mayoría de las características típicas de IDE: s también están en emacs. O tal vez incluso se originaron allí, y los IDE modernos son principalmente mejoras / simplificaciones de la interfaz.

Esto significa que para la pregunta original, la respuesta no es tan clara. Depende de cómo las personas en el sitio en cuestión usen emacs, si lo usan principalmente como un editor de texto, o si hacen todo lo posible y usan secuencias de comandos personalizadas, aprenden los comandos para los modos relevantes, conocen el etiquetado de códigos, etc.

Llego a esta pregunta desde la dirección opuesta. Fui criado en programación con muy pocas paradas en boxes en Makefile + Emacs land. Desde mi primer compilador en DOS, Microsoft Quick C, tuve un IDE para automatizar las cosas. Pasé muchos años trabajando en Visual C ++ 6.0, y cuando me gradué en Enterprise Java, trabajé con Borland JBuilder y luego me decidí por Eclipse, que me ha resultado muy productivo.

A lo largo de mi autodidacta inicial, la universidad y ahora mi carrera profesional, he aprendido que cualquier desarrollo importante de software realizado únicamente dentro del IDE se vuelve contraproducente. Digo esto porque la mayoría de los IDE quieren que trabajes en supeculiar estilo de "yo controlo cómo funciona el mundo". Tienes que cortar y cortar tus proyectos a lo largo de sus líneas. Ha gestionado las compilaciones de su proyecto utilizando sus cuadros de diálogo extraños. La mayoría de los IDE manejan las dependencias de compilación complejas entre los proyectos de manera deficiente, y las dependencias pueden ser difíciles de hacer funcionar al 100%. He estado en situaciones en las que los IDE no producirían una compilación funcional de mi código a menos que hiciera un Clean / Rebuild All. Finalmente, rara vez hay una manera limpia de mover su software fuera del desarrollo y a otros entornos como QA o Production desde un IDE. Por lo general, es un festival clicky para construir todas sus unidades de implementación, o tiene alguna herramienta incómoda que el proveedor de IDE le brinda para agrupar cosas. Pero otra vez,

Aprendí que, para hacer un desarrollo a gran escala con un equipo, podemos ser los más productivos si desarrollamos nuestro código usando un IDE y hacemos todas nuestras compilaciones usando scripts de línea de comandos escritos manualmente. (Nos gusta Apache Ant para el desarrollo de Java). Hemos descubierto que ejecutar nuestros scripts fuera del IDE es solo un festival de clics o una pesadilla de automatización para compilaciones complejas, es mucho más fácil (y menos disruptivo) hacer alt + tabular a un shell y ejecutar los scripts allí.

Las compilaciones manuales requieren que nos perdamos algunas de las bondades de la compilación de fondo IDE moderna, pero lo que obtenemos es mucho más crítico: compilaciones limpias y fáciles que pueden vivir en múltiples entornos. ¿La "construcción de un clic" de la que hablan todos esos tipos ágiles? Lo tenemos. Nuestros scripts de compilación también pueden ser invocados directamente por sistemas de integración continua. Tener compilaciones administradas a través de la integración continua nos permite organizar y migrar más formalmente sus implementaciones de código a diferentes entornos, y nos permite saber casi de inmediato cuando alguien registra un código incorrecto que rompe las compilaciones o las pruebas unitarias.

En verdad, quitarle el rol de construir al IDE no nos ha lastimado demasiado. Las herramientas de intellisense y refactorización en Eclipse siguen siendo completamente útiles y válidas: la compilación en segundo plano simplemente sirve para admitir esas herramientas. Y, la peculiar división de proyectos de Eclipse ha servido como una manera muy agradable de desglosar mentalmente nuestros conjuntos de problemas de una manera que todos puedan entender (aunque todavía es un poco detallado para mis gustos). Creo que una de las cosas más importantes sobre Eclipse es la excelente integración de SCM, eso es lo que hace que el desarrollo del equipo sea tan agradable. Usamos Subversion + Eclipse, y ha sido muy productivo y muy fácil capacitar a nuestra gente para que se conviertan en expertos.

Siendo el autor de la respuesta que resalta en su pregunta, y admitiendo que llegó un poco tarde, debo decir que entre las muchas razones que se han enumerado, la productividad de un desarrollador profesional es una de las más importantes. habilidades de gran prestigio.

Por productividad, me refiero a la capacidad de hacer su trabajo de manera eficiente con los mejores resultados posibles. Los IDE permiten esto en muchos niveles. No soy un experto en Emacs, pero dudo que carezca de alguna de las características de los IDE principales.

El diseño, la documentación, el seguimiento, el desarrollo, la construcción, el análisis, la implementación y el mantenimiento, los pasos clave en una aplicación empresarial, se pueden realizar dentro de un IDE.

¿Por qué no usarías algo tan poderoso si tienes la opción?

Como experimento, comprométase a usar un IDE durante, por ejemplo, 30 días, y vea cómo se siente. Me encantaría leer tu opinión sobre la experiencia.

Tener un IDE tiene las siguientes ventajas:

• La compilación suele estar "sobre la marcha", lo que significa que ya no es necesario cambiar a la línea de comando para compilar
• La depuración está integrada, y tener eso en un IDE significa que el depurador de pasos realmente usa su editor en el lugar para mostrarle visualmente qué código se ejecuta
• Los IDE generalmente tienen un mayor conocimiento semántico del idioma en el que está trabajando y pueden mostrarle posibles problemas mientras escribe. La refactorización es mucho más poderosa que el "reemplazo de búsqueda".

Hay mucho más, tal vez deberías probarlo.

Los IDE son básicamente:

• Editor con finalización de código, refactorización y documentación
• Depurador
• Explorador del sistema de archivos
• Cliente SCMS
• Herramienta de construcción

Todo en un solo paquete.

Puede tener todo esto (y algo más) usando herramientas separadas o simplemente un excelente editor programable y herramientas adicionales, como Emacs (también Vim pero tiene un poco menos de IDEbility IMO).

Si te encuentras cambiando mucho entre una utilidad y la siguiente que podría integrarse en el entorno o si te faltan algunas de las habilidades enumeradas aquí (y más completamente en otras publicaciones), tal vez sea hora de pasar a un IDE (o para mejorar la IDEbility de su entorno agregando macros o lo que no). Si ha creado un 'IDE' (en el sentido que mencioné anteriormente) usando más de un programa, entonces no hay necesidad de pasar a un IDE real.

Eclipse:

Tener resaltado de código, compilar en segundo plano, señalar mis errores a medida que avanzo.

Integración con javadoc, sugiriendo nombres de variables con ctrl-Space.

Cuando compilo, recibo errores allí mismo. Puedo hacer doble clic en un error y muestra la línea apropiada.

Muy bien integrado con JUnit, ctrl-F11 ejecuta la prueba, me dice que las pruebas han fallado. Si hay una excepción en la ventana de salida, puedo hacer doble clic en una línea y me lleva a la línea que falló. No solo eso, sino que ctrl-F11 se asegura de que todo esté compilado antes de ejecutar las pruebas (lo que significa que nunca me olvido de hacer eso).

Integración con hormiga. Un comando para compilar e implementar la aplicación.

Integración con depuradores, incluida la depuración remota de servidores web.

FANTÁSTICAS herramientas de refactorización, buscando referencias a una sección de código. Me ayuda a conocer el impacto de un cambio.

En general, me hace más productivo.

He usado Emacs como mi entorno principal para el desarrollo y el correo / noticias durante aproximadamente 10 años (1994-2004). Descubrí el poder de los IDEs cuando me obligué a aprender Java en 2004, y para mi sorpresa, en realidad me gustó el IDE ( IntelliJ IDEA ).

No entraré en razones específicas ya que muchas de ellas ya se han mencionado aquí, solo recuerda que a las diferentes personas les encantan las diferentes características. Yo y un colega usamos el mismo IDE, ambos usamos solo una fracción de las funciones disponibles, y no nos agradó la forma en que usamos el IDE (pero a los dos nos gustó el IDE en sí).

Pero hay una ventaja con los IDE sobre los entornos relacionados con Emacs / Vim en los que quiero centrarme: pasa menos tiempo instalando / configurando las funciones que desea.

Con Wing IDE (para Python) estoy listo para comenzar a desarrollar 15-20 minutos después de la instalación. No tengo idea de cuántas horas necesitaría para obtener las funciones que utilizo y ejecuto con Emacs / Vim. :)

Definitivamente me lleva a una mejora en la productividad. Hasta el punto en que incluso codifico aplicaciones Linux en Visual Studio en Vista y luego uso una máquina virtual Linux para construirlas.

No tiene que memorizar todos los argumentos de una función o llamada de método, una vez que comience a escribirlo, el IDE le mostrará qué argumentos son necesarios. Obtendrá asistentes para configurar las propiedades del proyecto, las opciones del compilador, etc. Puede buscar cosas en todo el proyecto en lugar de solo el documento o los archivos actuales en una carpeta. Si obtiene un error del compilador, haga doble clic en él y lo llevará directamente a la línea ofensiva.

Integración de herramientas como editores de modelos, conexión y exploración de bases de datos externas, gestión de colecciones de "fragmentos" de código, herramientas de modelado de GUI, etc. Todas estas cosas se pueden obtener por separado, pero tenerlas todas dentro del mismo entorno de desarrollo ahorra mucho tiempo y mantiene el proceso de desarrollo fluyendo de manera más eficiente.

Puede haber diferentes razones para diferentes personas. Para mí estas son las ventajas.

1. Proporciona una sensación integrada al proyecto. Por ejemplo, tendré todos los archivos de proyectos relacionados en una sola vista.
2. Proporciona mayor productividad de código como
   1. Resaltado de sintaxis
   2. Referencia de conjuntos
   3. Intellisense
   4. Vista centralizada de la base de datos y archivos de UI relacionados.
   5. Funciones de depuración

Al final del día, me ayuda a codificar más rápido de lo que puedo hacerlo en un bloc de notas o wordpad. Esa es una buena razón para que prefiera un IDE.

Un IDE puede ser una opción "superior" basada en lo que un desarrollador está tratando de lograr.

Un editor de texto puede ser 'superior' porque los IDE generalmente están orientados a uno (o una pequeña selección) de idiomas.

Si un desarrollador pasa la mayor parte de su tiempo en un solo idioma o en un 'grupo' de lenguajes relacionados (como C # y T-SQL), en un sistema operativo, entonces las herramientas de diseño, depuración, inteligencia, refactorización, etc. de la GUI que ofrece Un buen IDE puede ser muy convincente. Si, por ejemplo, pasa la mayor parte de su tiempo trabajando en VB.NET, con tal vez un poco de T-SQL de vez en cuando, en un entorno de Windows, sería bastante tonto no mirar Visual Studio o un IDE comparable .

No tengo prejuicios hacia aquellos que prefieren IDEs o editores de texto, ¡ambos pueden ser muy productivos y útiles si se aprenden bien !

Creo que tiene que ver principalmente con el alcance de la conciencia para el desarrollador. El IDE proporciona una vista macroscópica del contexto de trabajo del desarrollador. Puede ver simultáneamente jerarquías de clases, recursos referenciados, esquemas de bases de datos, referencias de ayuda del SDK, etc. Y con tantas cosas afectadas por sus pulsaciones de teclas y el volumen en expansión de arquitecturas e intersecciones arquitectónicas, cada vez es más difícil trabajar únicamente desde una isla de código a la vez.

OTOH, "solo yo, vim y las páginas de manual" me da una visión microscópica mucho más ágil, pero intensa y precisa, de mi trabajo. Esto está bien si tengo una base de código altamente coherente, bien diseñada, bien particionada, escasamente acoplada y construida en un idioma con un conjunto de bibliotecas estáticas para trabajar, no es su situación típica, especialmente a medida que el tamaño del equipo de desarrollo crece y cambia la estructura del código con el tiempo, la distancia y las preferencias personales.

Actualmente estoy trabajando en proyectos en Flex y .NET. Una de las mejores cosas de Flex es la poca cantidad de formas diferentes que hay de lograr una cosa estándar: extraer datos de una base de datos, abrir / cerrar / leer / escribir un archivo, etc. (Sin embargo, estoy usando Flex Builder / Eclipse IDE - un ejemplo típico de peso pesado como VS, porque todavía estoy aprendiendo lo básico y necesito las ruedas de entrenamiento. Espero evolucionar de nuevo a vim una vez que estoy seguro de mis patrones.) En esta vista, puedo hacer lo que Necesito hacerlo profesionalmente sabiendo algunas cosas realmente muy bien.

OTOH, no puedo imaginar llegar a ese punto con .NET porque la vista que se espera que mantenga se expande y cambia. Hay mucha menos integridad conceptual y más de varios desarrolladores en un proyecto durante varios meses, mucha menos consistencia, pero el IDE respalda eso, tal vez lo alienta. Por lo tanto, el desarrollador realmente necesita (y puede más fácilmente) saber muchas más cosas adecuadamente. Lo que también tiene el beneficio de ayudarlos a responder (o incluso comprender) un porcentaje mucho mayor de las preguntas en StackOverflow. Es decir, podemos tener una pila de conocimientos más profunda. Y podemos responder a una variedad más amplia de anuncios de búsqueda de ayuda.

Las cosas pueden ir demasiado lejos en ambas direcciones. Tal vez con el alcance "solo para el editor", es como "si solo tienes un martillo, todo parece un clavo". Con el enfoque IDE, para lo que quiera sujetar, tiene una amplia selección de sujetadores y una gama de herramientas asociadas para elegir: nals / martillos, tornillos / destornilladores, pernos / llaves, adhesivos / pistolas de pegamento / abrazaderas, imanes , y así sucesivamente, todo a su alcance (con un asistente que lo ayudará a comenzar).

No pienses en ello como exclusivo. Use el IDE para obtener los beneficios que brinda y cambie al editor de texto vim / preferido cuando necesite un enfoque serio.

Encuentro el IDE mejor para refactorizar, navegar y depurar y para descubrir qué hacer. Luego se hacen cosas pequeñas en el IDE, cosas grandes que paso a vim para terminar el trabajo.

Además de las otras respuestas, me encanta combinar el poder de desarrollo de un IDE con el poder de edición de Vim usando algo como ViPlugin para Eclipse .

IntelliSense , el depurador integrado y la ventana inmediata me hacen mucho más productivo ( Visual Studio 2008 ). Con todo a mi alcance, puedo mantener la gran mayoría de un enorme proyecto dentro de mi cabeza mientras escribo código. Microsoft puede seguir dejando caer la pelota en sus sistemas operativos, pero Visual Studio es uno de los mejores productos jamás desarrollados.

No entiendo lo que me estas preguntando. Usted pregunta "¿Debería usar un IDE en lugar de ...", pero no entiendo cuál es la alternativa? Vim y Emacs cumplen muchas funciones que cualquier IDE le dará. El único aspecto que no manejan que puede tener un IDE más grande son cosas como los diseñadores de UI. Luego, su pregunta se reduce simplemente a "qué IDE debo usar" con argumentos para el reino más simple de Vim y Emacs.

Para mí, un IDE es mejor porque permite una navegación más rápida en el código, lo cual es importante si tienes algo en mente para implementar. Supongamos que no utiliza un IDE, lleva más tiempo llegar al destino. Sus pensamientos pueden ser interrumpidos más a menudo. Significa que se deben presionar más clics / más teclas. Uno tiene que concentrarse más en el pensamiento de cómo implementar las cosas. Por supuesto, también puedes escribir cosas, pero entonces uno debe saltar entre el diseño y la implementación. Además, un diseñador de GUI hace una gran diferencia. Si lo hace a mano, puede llevar más tiempo.

Los IDE basados ​​en GUI como Visual Studio y Eclipse tienen varias ventajas sobre los IDE basados ​​en texto como Emacs o vim debido a sus capacidades de visualización:

• Vista previa WYSIWYG y edición en vivo para diseño GUI
• Editores de propiedades eficientes (por ejemplo, selección de colores usando una paleta GUI, incluyendo paradas de gradiente de posicionamiento, etc.)
• Representación gráfica de esquemas de código, interrelaciones de archivos, etc.
• Uso más eficiente de la pantalla de bienes raíces para mostrar puntos de interrupción, marcadores, errores, etc.
• Mejor soporte para arrastrar y soltar con SO y otras aplicaciones
• Edición integrada de dibujos, imágenes, modelos 3D, etc.
• Visualización y edición de modelos de bases de datos.

Básicamente, con un IDE basado en GUI, puede obtener más información útil en la pantalla a la vez y puede ver / editar porciones gráficas de su aplicación tan fácilmente como porciones de texto.

Una de las mejores cosas para experimentar como desarrollador es editar un método que calcule algunos datos y ver la salida en vivo de su código visualizado gráficamente en otra ventana, tal como lo verá su usuario cuando ejecute la aplicación. Ahora que es la edición WYSIWYG!

Los IDE basados ​​en texto como Emacs y vim pueden agregar características como la finalización de código y la refactorización a lo largo del tiempo, por lo que a largo plazo su principal limitación es su modelo de visualización basado en texto.

También uso casi exclusivamente Vim (casi porque estoy tratando de aprender emacs ahora) para todas mis cosas de desarrollo. Creo que la intuición pura (de la GUI, por supuesto) es la razón principal por la que a las personas les gusta usar IDE. Al ser intuitivo, se requiere poca o ninguna sobrecarga de aprendizaje de la herramienta. Cuanto menor sea la sobrecarga de aprendizaje, más podrán hacer el trabajo.

Un IDE le permite a uno trabajar más rápido y más fácilmente ... Me di cuenta de que pasé mucho tiempo navegando en el código en un editor de texto simple ...

En un buen IDE, ese tiempo disminuye si el IDE admite saltar a funciones, a una posición de edición anterior, a variables ... Además, un buen IDE reduce el tiempo para experimentar con diferentes características y proyectos de lenguaje, como el tiempo de inicio puede ser pequeño

Un par de razones que puedo pensar para usar un IDE:

• La ayuda integrada es un favorito.
• El Refactor incorporado con Vista previa de Visual Studio
• IntelliSense , resaltado de sintaxis, facilidad de navegación para proyectos grandes, depuración integrada, etc. (aunque sé que con los complementos probablemente pueda obtener mucho de esto con Emacs y Vim ).
• Además, creo que los IDE en estos días tienen una base de usuarios más amplia y probablemente más personas que desarrollan complementos para ellos, pero podría estar equivocado.

Y francamente, me gusta mi mouse. Cuando uso editores basados ​​en texto puro, me siento solo.

Ahorra tiempo para desarrollar
Hace la vida más fácil al proporcionar funciones como depuración integrada, intellisense.

Hay muchos, pero recomendaré usar uno, son más que obvios.

No estoy seguro de que haya una línea divisoria clara entre un editor de texto y un IDE. Tiene los gustos de Notepad en un extremo de la escala y los mejores IDEs modernos en el otro, pero hay muchas cosas en el medio. La mayoría de los editores de texto tienen resaltado de sintaxis; Los editores dirigidos a los programadores a menudo tienen varias otras características, como la navegación de código fácil y autocompletar. Emacs incluso le permite integrar un depurador. Los IDE de hace diez años tenían muchas menos funciones para ayudar a los programadores de lo que cabría esperar de un editor de texto serio en estos días.

Mi razón principal para usar uno es cuando el código va más allá de 100 archivos.

Aunque los ctags pueden hacer el trabajo, algunos IDE tienen una forma bastante buena de navegar fácilmente por los archivos de manera súper rápida.

Ahorra tiempo cuando tienes mucho trabajo por hacer.

Para mí es solo la versión GUI de todo lo que hicimos en los viejos tiempos de la terminal. Siempre estaré de acuerdo en que IDE no es muy superior porque ocultan muchas cosas, especialmente en relación con las cosas de enlace, pero tienen una ventaja notable en algunos casos, por ejemplo con ciertas plataformas de desarrollo como Qt.

Algunos IDE, como el visual de otros, incluso parecen analizar su código a medida que lo escribe, y detectan errores incluso antes de compilar: parece lógico que solo un IDE pueda trabajar estrechamente con un compilador para detectar inmediatamente el problema en la fuente escrita.

Mi respuesta descabellada de que existe la guerra de llamas de IDE / línea de comandos es simplemente porque el edificio ejecutable C / C ++ no se maneja muy bien desde un punto de vista estandarizado, a diferencia del lenguaje D; cada plataforma maneja la compilación / vinculación / etc. a su manera, por lo que para que sea menos complicado, crean un IDE.

Desde su punto de vista, podría ser más simple usar la línea de comandos, si hubiera habido un solo compilador con opciones estándar, hubiera sido fácil, pero la verdad es que C / C ++ es flexible, por lo que, al final, todas las plataformas hazlo a su manera, de ahí el IDE para no desperdiciar explicando cómo hacerlo.

Si puede aprender cómo un ejecutable habla con el núcleo o si sabe algo sobre el diseño del compilador, tal vez haya una manera de trabajar con una línea de comandos adecuada, pero dudo que lo tenga.

Microsoft o Apple, por muy malvados que sean, tienen que proponer una forma directa de crear aplicaciones sin ingresar los detalles, y dado que la creación de una aplicación depende directamente de la arquitectura del sistema operativo, difícilmente será "estándar" como el línea de comandos es.

Para decirlo, aplicaciones simples, grandes y complejas donde no desea profundizar demasiado en lo que hace -> IDE, pequeñas piezas de software o diseño simple de software de sistema -> línea de comandos. Excepto, por supuesto, esas ingeniosas bibliotecas que incorporan un Makefile, pero esa es otra historia.

También creo que los IDE se usan cuando la aplicación entregada tiene algo que ver, irónicamente, con una GUI o algo que tiene una interfaz o está directamente vinculada a un sistema operativo, por lo que, nuevamente, también es para personas que usarán una UI / GUI sin saber cómo funciona, mientras que las personas que programarán sistemas no lo necesitarán todo.

IDE es una mierda moderna, pero creo que dentro de 100 años la línea de comandos seguirá existiendo.

Me gusta un IDE porque pone mucha funcionalidad a mi alcance. La edición / compilación / visibilidad de los archivos en el proyecto son todas las cosas que valoro en un IDE. Ahora uso Visual Studio, pero en una vida anterior usé SlickEdit y descubrí que hizo que mi proceso de desarrollo fuera más ágil que cuando no lo estaba usando.

Solo hay una cosa a considerar al decidir si usar un IDE o no, y eso es si te hace más productivo o no.

Pregunta corta, respuesta corta :)

Depende en gran medida de lo que esté haciendo y en qué idioma lo esté haciendo. Personalmente, tiendo a no usar un IDE (o "mi IDE consiste en 3 xterms que ejecutan vim, uno que ejecuta un cliente de base de datos y otro con un bash prompt o tailing logs ", dependiendo de cuán ampliamente defina" IDE ") para la mayor parte de mi trabajo, pero si tuviera que desarrollar una GUI nativa de la plataforma, buscaría un IDE apropiado para el idioma en un instante: la OMI, los IDE y la edición gráfica de formularios se hacen claramente el uno para el otro.