Barrapunto

Buenas, la verdad es que yo tampoco he encontrado un IDE a la medida de mis necesidades, que veo que es lo que te ocurre a tí, y recalco: a la medida de mis necesidades. Al final uso la consola que es lo único que me las ha conseguido cubrir, aunque tenga que estar cada tres por dos echando mano de man :) No creas que no existen IDEs en Linux (aunque no los hay maduros, estables y cargados de características); lo que pasa es que no te resuelven la papeleta, y es que el estilo de programa de Linux no es el de Windows precisamente.

No entiendo muy bien lo de los fuentes remotos: en Linux puedes montar sistemas remotos como directorios, desde Windows (Samba), Unix (NFS) por ejemplo. KDE y GNOME tienen sistemas de ficheros virtuales, también. Además tienes sistemas de control de versiones (CVS, SVN) que puedes usar para sincronizar fuentes.

En cuanto a enlazar con ficheros cabecera, lo que se hace es enlazar con bibliotecas. Los ficheros cabecera se #includen. Es necesario consultar la documentación de GCG: Busca los parámetros -l e -I. Créeme, leer y comprender la documentación de GCC es imprescindible.

Antes que nada decir que el vim lo uso a menudo para hacer pequeñas scripts y editar ficheros de configuración, cosas sencillitas nada más, por lo que probablemente no aprovecho ni el 20% de sus posibilidades. Emacs lo desconozco casi por completo.

Sin embargo uso Eclipse a diario para programar en Java en mi trabajo, y aunque he dejado claro que desconozco las posibilidades reales de vim/emacs, me cuesta creer que con cualquiera de ellos lograse la misma productividad, especialmente en proyectos con miles de ficheros. Cosas como:

• Pulsar Control+Espacio autocompleta código, incluso pequeños "snippets" con esqueletos de código para bucles o similares.
• Compilador "sobre la marcha": te marca los errores de compilación a medida que escribes. En el árbol de código fuente te marca con una cruz roja las clases que no compilan en un momento dado.
• Al pulsar F3 sobre un método o una clase, me abre en una ventana el código fuente de esa clase. Si lo pulso sobre una variable, me lleva a su punto de declaración.
• Pulsar F2 me muestra en un "tooltip" la documentación (Javadoc) del método.
• Puedo refactorizar clases. Si renombro una clase, método de una clase o variable, Eclipse la renombra en todos aquellos archivos que la utilizan. Puede renombrarla incluso en comentarios y partes que no son código propiamente dicho.
• Con un par de clicks puedo construir un jar, exportar el código fuente a un zip.
• Editores personalizados para cada tipo de fichero: el editor de código fuente no es el mismo que el de XML, por ejemplo. Son totalmente personalizables.
• Permite crear perfiles de ejecución de una misma clase con distintos parámetros, entorno, etc., de forma sencilla.
• Tengo un entorno completamente integrado: todo lo hago con Eclipse. Casi nunca es necesario un programa externo: Eclipse incorpora herramientas de comparación de código, integración con CVS, depurador que te permite cambiar el código sobre la marcha (no me refiero a cambiar valores de variables, sino el propio código sin reiniciar la ejecución), gestión de scripts de Ant, herramientas de generación de código (getters y setters, por ejemplo).

Probablemente me dejo en el tintero otras cosas tan importantes o más que las que he nombrado. Con la infinidad de plugins que existen para Eclipse se puede multiplicar la funcionalidad por mil. En mi trabajo utilizamos plugins como Lomboz o MyEclipseIDE para gestionar el despliegue de aplicaciones J2EE en el servidor de aplicaciones, ya sea Tomcat, JBoss u otro.

Estoy por apostar que con vim o emacs se puede hacer todo o casi todo lo que he nombrado, pero lo mejor de todo es que Eclipse hace todo lo anterior "de serie", al menos para Java. Te bajas el fichero de instalación, abres el programa y tienes a tu disposición toda la funcionalidad anterior sin hacer ningún script, sin modificar ningún archivo de configuración ni instalar programas externos. Esto te permite dedicar tu tiempo a programar, que es lo que quieres hacer cuando usamos cualquiera de estas herramientas y que es también al fin y al cabo, por lo que nos pagan a los programadores. Os puedo asegurar que a estas alturas no necesito autocompletado de código porque desconozca el código que quiero generar, o que quiera que Eclipse me compile el proyecto porque yo no sepa compilar en línea de comandos con javac. Pero si tuviese que hacer eso yo, perdería tiempo, un tiempo en el que debería estar programando.

Como punto negativo para Eclipse está que consume más recursos que vim o emacs, pero eso importa poco a las empresas, ya que el coste de PC's potentes hoy en día (un procesador de 2 GHz y 1 GB de RAM es más que suficiente para Eclipse) es pírrico en comparación a lo que les cuesta pagar a la plantilla de programadores.

Por eso al final lo que cuenta es la prod

Hace tiempo que no lo miro, pero creo recordar que KDevelop trabaja sobre la estructura estándar GNU (Automake, etc). Tu haces los Automake a tu gusto (y con eso puedes hacer absolutamente cualquier cosa, no solo una librería estática, sino un proyecto completo con diferentes módulos de diferentes tipos), KDevelop los llama y te muestra la salida.

Creo que no tenía más historia. De todas formas, cuando te sueltes un poco verás que lo más cómodo es y será compilar desde la consola.

Totalmente de acuerdo con la opinión general. Apoyada además por mi experiencia: Trabajaba en GNU/Linux con Kate, gcc, gdb, make en mi anterior trabajo. Ahora con Visual C++, que explota cuando quiere si intento poner unos simples watchers incómodos ...

Tu problema es que no has aprendido a programar. Has aprendido a usar el Visual C++ y no sabes manejar conceptos y herramientas que son ESENCIALES, aunque Microsoft no lo crea.

Te animo a que comiences de 0 con un editor y un compilador, luego llegará el depurador, luego el make, luego el automake ... y habrás construído tu conocimiento en el orden natural.

Un saludo

Y no digo todo esto con animos de insultar, simplemente que los IDE, cuando tienes experiencia, sólo sirven para entorpecer tu trabajo, dificultar la compartición del código con el resto del equipo, y lo peor: sólo da problemas a la hora de distribuir el código fuente a terceros (léase software libre o simplemente a un cliente).

Saludos.