Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.
Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como "IDE" y las razones son las siguientes:
- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc
- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.
- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac... fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar...
- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.
- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras... sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.
Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.
Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep... lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones... pero los buenos programadores nunca nos confundimos :P
12 comentarios:
Pues sí. Un poquito masoca y radical. No es como no querer hacer uso de una calculadora ante la posibilidad de que no la tengamos a mano alguna vez no sepamos hacer determinadas operaciones?.
:P
Yo también estoy de acuerdo que es un poco radical :p
Hay conocimientos que ahora mismo son cuestionablemente útiles.
Yo no sé compilar una aplicación en .NET por línea de comandos, ni hacer un script de MSBuild, pero no considero que eso me haga mejor o peor programador. El día que lo necesite, me lo cojo, me lo meto entre pecho y espalda, y lo hago, como todo lo demás. No creo que saber hacer esas cosas tenga un misterio o un valor especial respecto a las demás.
Y el autocompletar también estoy en desacuerdo. No solo que cuando sabes lo que haces escribes más rápido, si no que te ayuda a explorar librerías tan inmensas como .NET, donde es imposible acordarse de todo, pero muchas veces tienes una idea de donde tiene que estar algo o como debería llamarse más o menos y el autocompletar te ayuda a descubrirlo sin tener que estar cada dos por tres yéndote a mirar la documentación.
La verdad que desde mi punto de vista no puedo entender a la gente que usa emacs, vim,... Excepto en el caso de que tengan que tocar 324234 lenguajes diferentes, pero para alguien que siempre trabaja en lo mismo? Un buen IDE y a ser productivo, que es de lo que se trata.
Hi,
pues menos mal que no usas emacs que si no.... :P Yo creo que ni tanto ni tan calvo.
Lo de la complejidad, depende del programa que vayas a hacer. Si en la solucion intervienen tropotocientos proyectos, vas a necesitar una herramienta para organizar el build y las configuraciones. Asi que, ademas, vas a tener que "arremangarte" y enterarte de que esta haciendo por debajo para configurar bien el build. Y ya ni te cuento si mezclas varios lenguajes y/o librerias como qt que necesitan una compilacion previa del codigo que hagas. Un cristo vamos.
Lo del autocompletado para sintaxis, piensa que al fin y al cabo es una forma de ver el manual. Ademas es muy util para inspeccionar clases etc... Ademas, a fuerza de consultar las cosas por narices se te quedan.
Con lo unico que estoy de acuerdo es en lo de los "wizards". Para codigo de produccion miraria con lupa el usar "wizards", y solo los usuaria por causa de fuerza mayor.
En fin, creo que cuando estas comenzado algo nuevo esta bien no usar herramientas que te oculten como funcionan las cosas. Ahora, una vez pillada la historia, usar tantas como las circunstancias lo requieran. Porque al fin y al cabo cuando entras en produccion vas a tener que saber que hace cada cosa por narices.
Un saludo,
Ruben Penalva
Yo ya sufro en el curro a varios programadores de vim, y sintiéndolo mucho para mi debería estar prohibido salvo que trabajes solo.
En un proyecto con miles de archivos fuente, el hacer botón derecho Refactor -> Rename (sea Visual Studio, Netbeans o Eclipse) no es que sea más o menos cómodo, es que sino la mitad de las veces se te colarán errores (incluso aunque grepees para buscarlo, a veces un espacio ya te lo fastidia).
Cambiar nombres de variables, dejarse documentación sin actualizar, simples resaltados de sintaxis de "variable no utilizada" o warnings de "primer uso de variable" (posible typo)...
Tengo decenas de argumentos en contra :P
Y lo que dices de trabajar en remoto, NetBeans es un poco cansino con el "Scanning project" desde SFTP, pero Eclipse + RSync y hasta desde Windows funciona...
Vamos, que yo también cuando no me queda otra y toca depurar algo en un servidor como sólo hay vim miro con vim ahi, pero para el dia a dia no sólo es masoquismo sino directamente mala práctica si trabajas en equipo.
"tu libertad de codificación termina donde comienzas a entorpecer a tus compañeros" - Adaptación guarreras mia xD
Por una parte Vim: cualquiera que lo haya usado mas de un año de forma seria siente un respeto, y posiblemente amor, enorme hacia este increíble editor :)
Estoy seguro que seria mucho mas usado si el gVim no fuera tan KISS :P
Hay que ver que va a pasar cuando salga TextMate 2 (un editor muy popular para Mac, que segun el autor la proxima version sera open source, multiplataforma y tendra una integracion practicamente completa de Vim.. pero manteniendo una interfaz agradable al usuario comun).
Por otra parte mi problema con los IDEs son los archivos de proyecto.. pongamos el caso de Visual C++, cada vez que sale una version nueva los proyectos viejos son incompatibles. Aun teniendo importadores, nunca es perfecto.. lo que es peor es que en algunas ocaciones es complicado encontrar cual es el problema.
En cambio con makefiles (usando automake, cmake, o lo que sea) el proyecto es independiende de con que fue desarrollado.
Es increible bajar aplicaciones de hace 15 años y poder compilarlas en un sistema actual sin tener que correr una maquina virtual para ejecutar un IDE del mismo año.
"La verdad que desde mi punto de vista no puedo entender a la gente que usa emacs, vim,... "
@Vicente: yo siento justamente lo contrario jajaj para mi usar el editor de VS, Eclipse, Netbeans o lo que sea es posiblemente lo mismo que para ti usar el Notepad ;)
@Kartones: tus argumentos en contra de usar unicamente Vim para un proyecto de software grande son parcialmente correctos. Tu error esta en pensar que un editor de texto debe realizar todas las tareas de desarrollo.
Existen miles de proyectos enormes que no estan basados en un IDE y son desarrollados por cientos de personas, ejemplo: el kernel Linux.
@r3d el problema no es usar la calculadora, el problema es no saber sumar sin ella.
@Vicente precisamente .NET es el ejemplo claro de lo que digo. Trabajar en C#, por ejemplo, es jarto difícil sin el IDE porque MS así lo ha querido y eso lleva a que la complejidad de lo que hay por debajo de IDE sea grande.
@Ruben precisamente con QT he trabajado el último año y con los makefiles de Qt era realmente simple gestionar las configuraciones necesarias. Es más, creo que si hay muchas configuraciones gestionar a maneta con un IDE es aún peor.
@Kartones: el problema no es del IDE, es de tus compañeros :P
Siempre lo mismo...
IDE bueno, IDE malo, para ser gurú, pro... hay que usar herramientas en terminal, nada de colores ni gráficos.
Todo depende del proyecto, tiempos, facilidad de uso. Si seguimos la filosofía de hay que conocer todo lo que pase por debajo, igual la gente que habla de lenguajes tipo .Net, Java... debería pensar en qué pasa con los registros del sistema, configuración de la máquina virtual...
Es decir, tenemos que llegar al punto intermedio. Claro que cuanto más conozcas mejor programarás y mejor software crearás, pero, no podemos hacerlo todo en asm, porque entonces no habríamos avanzado tanto en el mundo del software.
Yo uso: vi e IDE sin problema dependiendo del proyecto que lo requiera. Y para aplicaciones web, no pienso en hacer cosas en C y de la misma forma no pienso en html/java... para hacer scripts del sistema.
Un saludo. Muy buen blog.
Una discusión interesante
Yo también soy de los que prefieren programan a pelo, utilizar IDEs en proyectos grandes lo único que hace, como comentas, es meterte líneas y líneas de código genéricas.
Me gusta sentir y entender lo que hago y el proceso que sigue, sino me veo incapaz de tener una visión global de lo que realmente estoy haciendo y de el como mejorarlo.
A la larga por inercia cada vez trabajas más y más rápido a sabiendas de lo que haces, que existen más errores, puede ser, pero al menos aprendes de ellos.
Para proyectos muy grandes es cuestión de organizarse correctamente.
El mundo está lleno de imperfecciones, buscar un equipo de desarrollo perfecto y que nunca cometa fallos es una utopía.
No digo que mis compañeros sean paquetes ni peores que yo ni nada parecido, solamente que juegan con la desventaja de que ellos abren un fichero JS de 2000 lineas y ale, a confiar en sus skills para corregir un bug o limpiar el código "a mano".
Yo abro Netbeans y me marca desde variables sin usar hasta posibles problemas. De hecho para Netbeans mis compis han montado un template de reglas de estilo y codificación.
Con herramientas como FXCop se puede hacer desde fuera, si, pero te toca compilar, abrir otra ventana/terminal o lo que quieras, yo prefiero mil veces la comodidad de tenerlo todo junto y que me avise el propio entorno.
Cosas como botón derecho -> "go to definition" para mi no tienen precio, multiplicándose según aumentan el nº de ficheros de proyecto.
El argumento de la morralla que te añaden los proyectos/soluciones de los IDEs es medio correcto... pero siempre puedes cambiar los path por defecto (yo lo hago para no commitear basura de netbeans a las branches) y problema solucionado.
De hecho con CruiseControl.Net y NAnt alguna vez incluso me los generaba yo a mano y compilaba por linea de comandos para añadirle o no determinadas librerías según el tipo de compilación y si pasaban o no las baterías de tests...
Todo se puede hacer a mano, y hay cosas que sólo se pueden hacer a mano. Pero muchas muchas cosas se pueden hacer también con ayuda, y la ayuda actual no es como la del Turbo C de hace 15-20 años...
Cada uno elige cuales y como usa sus herramientas, y ciertamente, el usar IDEs te mal acostumbra a ellos.
Pero donde me muevo yo, enchufamos APIs de nuevas librerias dia si dia tambien, y el intellisense pasa a ser absolutamente fundamental para sacar adelante algo usando una libreria que apenas conoces.
Y lo sabes mejor que nadie: las librerias van y vienen, los APIs cambian constantemente, y no es plan ir memorizandolo todo; a mi me sirve de bien poco saberme de memoria un monton de APIs que ya no se usan.
De hecho, te voy a responder con una muy buena: tan malo es depender de un IDE, como de tu propia memoria; puedes acabar usando un API de forma incorrecta (porque dicho API ha cambiado) o perderte nuevos metodos añadidos en nuevas versiones que "magicamente" aparecen en el intellisense.
Por cierto, en c#, es cierto que el IDE te mete codigo por detras, pero es como todo, una vez entiendes como te mete el codigo por detras, puedes hasta sacarle provecho para hacer alguna que otra filigrana con poquisimo codigo. De hecho, en algunos casos hemos consegido que casi todo el codigo lo genere el propio IDE, dejando las clases editables practicamente vacias; ventajas: mucho menos codigo para mantener y debugear.
Pero eso si, otro tipo de proyectos diferentes a lo que estoy haciendo, desde luego, no los haria asi.
En lo de las teclas si estoy de acuerdo, es una mierda cuando te pasas de visual a eclipse o a algun otro.
Publicar un comentario