Sobre IDEs y Herramientas

   Hace poco tuve una discusión bastante pelotuda con un amigo sobre si Vim es mejor que Eclipse o no, discusión que terminó en boludeces retóricas y cero aporte a algo, como medirse la pija pero con IDE's (Super triste, super foreveralone).
 
  Eso me lleva a analizar sobre las discusiones sobre IDEs y sobre los IDEs mismos.

  ¿Qué es un IDE?
   IDE es una sigla que significa Integrated Development Environment. O sea, Entorno integrado de desarrollo.

  ¿Cuál es su función? 
   Las tecnologías no evolucionan y aparecen de una manera realmente sistémica. Aparecen mas bien cuando son necesarias (sobre todo en el ámbito industrial). Eso hace que no tengan mucha consistencia las distintas herramientas que se utilizar para el desarrollo de software. Eso hace necesario que haya herramientas que integren estos mundos muchas veces distintos y faciliten tareas repetitivas y tediosas y disminuyan considerablemente la curva de aprendizaje a cubrir necesaria para comenzar a utilizar una tecnología. Un ejemplo icónico es Maven en el mundo de Java o derivados (groovy, scala, etc)
 
 ¿Cómo elegir un IDE? 
   Es muy importante no ponerse ninguna camiseta. Si se puede nunca ponerse una camiseta, excelente, sino por lo menos cuando se usa el sombrero crítico. No hay un Microsoft es una garcha, java es una mierda, o lisp es una genialidad o aguanten las db relacionales.

  Hay dos tipos de criterio a satisfacer para elegir: lo colectivo y lo individual.

  Lo colectivo
    No hay que olvidarse que el software contemporaneo es en general muy grande para que lo desarrolle una sola persona. Así que se suele trabajar en equipo.
   En los distintos lenguajes hay distintas convenciones, cada persona tiene distintos gustos en la forma de codear y cada proyecto tiene distintas herramientas para el control de versión.
   En este aspecto entonces, yo, tengo muy en cuenta el auto formateo de código y la capacidad del IDE para dejarme configurar el formateo de código como definimos con el equípo. De esta manera yo programo como se me cante a mi. Despues auto formateo como se convino y listo.
   También influye bastante para mí el saber que cosas cambie y poder hacer comparativas rapidas con versiones anteriores para los momentos de duda. Me es imperativo switchear lo minimo posible por que pierdo la concentración y me pongo a boludear.

En lo individual
 
   En lo individual me interesan varias cosas que puedo diferenciar entre funcionales y técnicas

   Funcionales  (que me gustaría que haga por mí)

       Lo mas importante para mí en este caso es lo que mas suelo hacer: browsear código. No me gusta perder tiempo buscando en que archivo esta cierta clase o cierto tipo o cierta función. Bastante con convivir con el hecho de que estoy programando en archivos.

     Después me importa en casi igual medida la integración con los tests dado que suelo programar usando la idea de TDD, para mí es muy importante esta forma de integración.  Poder correr los tests, saber donde falla cada test y por que y que relación tiene cada test con cada parte del código sin tener que recordar de memoria todo lo que hice hace una semana (ni hablar de un mes o dos años).

     Después me importa en casi igual medída tambien la capacidad de refactor y generación de código automático (esto es muy cierto para mi en java, y en menor medida en lenguajes menos burocráticos). Necesito poder generar esqueletos de código a partir de mis tests hechos antes que la funcionalidad, eso me permite mantenerme en la misma linea de pensamiento sin tener que pensar en cosas como 'tengo que crear un archivo'.

     Después en menor medida la predicción de código (la listita de mensaje aparece cuando ponés punto, o el token de mensaje pertinente). Esto tiene bastante importancia, permite que uno se abstraiga de implementaciones y de largas documentaciones. Sobre todo cuando los nombres de mensajes están bien puestos.

    Después la integración de herramientas terceras como software de gestión y construcción de proyectos , editores copados de xml, integración con servidores, tanto para deployment como para monitoreo. Muchos de estos softwares son no triviales para empezar a usar, y es una cagada perder el tiempo aprendiendo a usar maven por ejemplo, cuando podría uno sacarselo de encima y preocuparse por lo importante: las reglas de negocio. Es cierto que uno no puede evitar para siempre aprender estas tecnologías, pero al menos puede distribuir el aprendizaje en el tiempo.

   Después en menor medida snipets típicos de código, como un for, una clase, un html, etc.

   Todo esto, claramente tiene que estar resuelto agilmente, eso implica shortcuts. Es muy importante que haya shortcuts, mas intensivos sobre los primeros items de la lista y en el resto pueden ser en menor medida.

  Ténicos

    Bueno, en este caso, es de mayor importancia no mear afuera del tarro. Tiene que funcionar todo lo necesario dentro de la misma computadora, por lo que dependiendo de los recursos disponibles, lo que podamos elegir y lo que se pueda explotar.



  Entonces

    Es muy importante saber que dependiendo de los lenguajes que uno use, cuan nuevos y poderosos sean, cuanta metadata proporcionen, etc, se puede pensar en distintos niveles de herramientas. Así, mientras para lenguajes tipados el refactor automático puede ser trivial, para otros lenguajes como python, un rename de por sí ya es un desafío realmente complicado. Lo interesante es que se compensa en la versatilidad  y sencillez del lenguaje.

   Otros lenguajes como Scala o Haskell, son sencillos, versatiles y tienen una gran cantidad de metadata, pero son o muy nuevos o muy poco usados, por lo que hay menos herramientas. Y otros lenguajes como Smalltalk no tienen mucha meta data par dar, pero por las caracteristicas de la forma de ejecución esto es mas sencillo o no.


  Cual es la papa

    Creo que lo mas importante es que te sientas cómodo con lo que usas. Si no te sentís comodo, probá otra herramienta y así. Cada tecnología puede hacer que necesites otro IDE.
    Por razones obvias, no te pongas la camiseta. Hay que tener muy en cuenta que si no fuese por Visual Basic, ese horrendo producto de esa horrenda compañía, hoy por hoy tal vez no habría IDEs.
   
   Yo mientras codée en Java, Scala, Javascript con GAE o Android voy a seguir con eclipse por que me dá la maquina y por que pese a que el soporte de Javascript es una garcha, en los otros es sobresaliente en todos los aspectos que a mi me importan.

   Al final, elegir un IDE es como elegir cualquier otra cosa. Comodidad y sentido común.