Yo diría que la culpa es de node.js, y especialmente de todas las herramientas basadas en node.js que se usan para desarrollo frontend, pero lo cierto es que para desarrollar cada vez se usan más aplicaciones de línea de comandos y cada vez hay más plataformas (como .NET Core) que van en esa línea.
No es que usar herramientas de línea de comandos sea algo inventado por la comunidad Javascript (nada más lejos de la realidad), pero la ubicuidad de Javascript como lenguaje y el tirón que han tenido node.js y el desarrollo frontend han contribuido a popularizar formas de trabajar que antes resultaban más exóticas para el gran público.
Los que llevan toda su vida trabajando en entornos *nix, o con lenguajes como ruby o go, están muy acostumbrados a este tipo de herramientas, pero para los desarrolladores de .NET o Java, acostumbrados a depender (quizá demasiado) de sus potentes IDEs, es más novedoso.
Personalmente, le tengo cariño a las herramientas de línea de comandos desde mi época de linuxero pesado y llevo mucho tiempo usándolas para desarrollar también en .NET, pero comprendo las reticencias de algunos que las consideran un paso atrás y una vuelta al pasado.
En realidad, se trata de una cuestión de aprendizaje.
Las herramientas de líneas de comandos pueden tener una curva de aprendizaje más dura, sobre todo si no estás acostumbrado a utilizar este tipo de herramientas, y es normal que te dé pereza pensar que tienes que recordar muchos parámetros y que tienes que andar teclando una y otra vez largos comandos en una consola.
Afortunadamente, cuando ya conoces unas cuantas herramientas es más fácil encontrar sus similitudes, comprender las formas en las que suelen manejarse, y aprender a utilizar nuevas herramientas no se hace tan cuesta arriba.
Aun así, la cuestión no es tanto si son fáciles o difíciles de usar, sino si merece la pena usarlas.
¿Por qué querría invertir tiempo en manejar este tipo de herramientas cuando puedo tener un IDE en el que pulso un botón, sale un wizard que me va guiando, y consigo el mismo resultado?
La respuesta es sencilla: eficiencia.
Ólvidate por un momento de esas herramientas de línea de comandos tan antediluvianas que aborreces, y piensa en tu precioso IDE, que te conoces al dedillo y manejas con soltura.
Dentro del IDE hay ciertas tareas que requiren utilizar un asistente. Normalmente, estas tareas suelen ser más infrecuentes, requieren más pasos y es más fácil olvidar cómo se realizan, por lo que tener un wizard que te va guiando, aunque implique pasar por más pantallas y hacer más clicks, merece la pena.
También hay otras tareas que realizas con mayor frecuencia, y tener que pasar por 7 pantallas de un wizard en las que te van pidiendo un par de campos cada vez es muy tedioso. Por suerte suele ser posible saltarse el wizard, llegar a una pantalla llena de opciones, y conseguir el mismo resultado. Es menos guiado, pero resulta más rápido.
Aun así, hay tareas que haces tantas veces que tener que ir a pulsar un botón resulta un engorro, y te acabas aprendiendo un atajo de teclado. Hasta mi madre conoce Ctrl-C y Ctrl-V, y seguro que tú te sabes unos cuantos atajos de teclado del IDE que sueles usar. Memorizar un atajo de teclado es más complicado que explorar una barra de botones o un menú hasta encontrar la opción que estás buscando, pero a cambio te permite ser más rápido.
Las herramientas de línea de comandos son el paso siguiente. Quizá resulten más complicadas de aprender que algunos atajos de teclado (excepto si usas emacs y has memorizado cosas como C-c C-t t), pero no sólo te permiten ejecutar un comando con parámetros rápidamente, también te permiten automizar la ejecución de comandos.
Sí, la principal ventaja de las herramientas de líneas de comandos es que son «programables», y se supone que a nosotros nos gusta programar cosas.
Se supone que se nos da bien resolver problemas de otros escribiendo código, pero muchas veces nos cuesta usar nuestra capacidad de desarrollar aplicaciones para resolver nuestros propios problemas. Nos parece razonable que un cliente nos pague para diseñarle una aplicación que haga que sus empleados puedan hacer las cosas en menos tiempo y con menos esfuerzo, pero aplicar esa misma idea a nuestro propio trabajo ya es otro tema.
Cuando puedes lanzar una herramienta por línea de comandos es fácil integrarla dentro de un proceso mayor, por ejemplo dentro de un servidor de integración continua, en un lanzador de tareas como grunt o gulp o en las opciones de tu editor de texto.
Esto no implica que olvidemos los interfaces gráficos. Igual que tener un atajo de teclado no impide tener también la opción disponible en un menú, tener un interfaz de línea de comandos es perfectamente compatible con tener también una interfaz gráfica.
En el mundo linux es muy habitual ese escenario, con herramientas gráficas que actúan como frontend de una herramienta de línea de comandos, y tampoco es raro encontrar librerías que son utilizadas tanto por herramientas de línea de comandos como por aplicaciones con interfaz gráfica.
En mi opinión, las herramientas de desarrollo deberían contar siempre con algún mecanismo para invocarlas por línea de comandos, y de hecho he tenido que descartar herramientas bastante interesantes por no tenerlo.
Me aburre mucho tener que hacer tareas repetitivas, y pese a que los lenguajes de scripting son una de mis asignaturas pendientes, intento siempre automatizar todo lo que puedo mis flujos de desarrollo. Además de para ganar en eficiencia, tener las tareas automatizadas me permite aumentar la confianza en el proceso, porque sé que no se me olvidará darle a un botón y el resultado de lo que estoy haciendo será más predecible.
En definitiva, puede que las herramientas de línea de comandos sean algo del siglo pasado, pero a día de hoy todavía son la mejor opción para muchas tareas y, como decía Rubén (que tan amablemente me ha dejado usar su frase como título de este post), la consola mola.
Yo creo que una herramienta de consola de comandos tiene que venir ligada a algún tipo de «intellisense» para que acabe triunfando. Es decir, si haciendo tab obtienes el listado de operaciones que puedes ejecutar win-win. Si TODO es de cabeza… esta claro que será muy efectivo pero a qué precio.
Me encanta leer tuts posts, y como te cuestionas las cosas para avanazar siempre un psaos más.
Yo creo que lo resumes a tope con «En realidad, se trata de una cuestión de aprendizaje.»
Debemos ver la consola como una herramienta más, que nos aporta eficiencia (como tambien indicas) y permite automatizar muchas cosas.
No hace falta ser un gurú de vim o grep, por poner unos ejemplos, pero saber moverse por la consola, conocer unos minimos comandos, poder crear scripts que nos faciliten más la vida … deberia estar en el toolbox de cualquiera que quiera avanzar un paso más en desarrollo.
Hay un problema de base, y lo veo en toooooooodos los posts sobre esto (incluido este), en los twits, comentarios de facebook, discusiones en foros y whatnot.
El problema es que se confunde: «la consola» con «los comandos».
La consola es algo antediluviano que se debería de erradicar: es algo que se usaba porque los terminales eran de texto y valía para hacer comunicación rápida entre terminales (y hoy día se sigue usando con ssh porque linux es así).
Los comandos de texto son lo que permite la integración continua, scripts, etc… y lo que da todas las ventajas (las que tú también enumeras en este post) pero esos comandos no tienen por qué ir en una «consola» como la que enseñas en la imagen.
Ejemplos hay montones… para .NET desde Visual Studio está la línea de comandos de NuGet (que en realidad es un Powershell del copón). Powershell en sí, aunque es una aplicación de texto con «línea de comandos», tiene muuuuuuuuchas cosas que una «consola» no tiene por qué tener (desde autocompletado con tabs, hasta estados avanzados de variables no necesariamente de texto). Una cosa no tiene por qué ir con la otra… hablando de Powershell, está el Powershell ISE (y lo nombro porque viene con Windows), que te da autocompletar, intellisense, resultados inmediatos, etc.
Con Javascript tenemos la consola de desarrollo de chromium, que provee una línea de comandos, pero muchas más cosas también.
Creo que se confunde usar «comandos de texto», con abrir el «cmd» de windows o una shell pobre de linux (bash no es especialmente pobre, pero le queda mucho también para ser funcional para un desarrollador).
Yo estoy a favor de los comandos de texto: llevo haciendo «sistemas de script» desde mis días de desarrollo en MS-DOS. He hecho motores en OpenGL que funcionaban a base de scripts de texto, y una de las aplicaciones que mantengo hoy día (de gestión empresarial), internamente comunica las distintas ventanas del interfaz mediante comandos de texto (aunque eso no se ve en el UI). Me encanta, lo veo útil y le veo muchas ventajas…
Al «cmd» de Windows: no.
Sr. Campos, tiene usted toda la razón en la distinción entre consola y comandos de texto.
Si he usado el término consola era por poder aprovechar la pegadiza frase de Rubén y por emplear el término más habitual entre los no habituales de ese tipo de aplicaciones.
Gracias por la puntualización (y lamento las dificultades que has tenido para publicar el comentario ;-)
Pero entonces no sera que hay consolas «malas» y «buenas» (¿o simples y completas?). Quiero decir que si los comandos son de texto, ¿lo «natural» no es usarlos en un entorno en que la entrada principal, aunque no unica (y tal vez la salida) sea texto?
A veces menos es mas, y si la consola es muy completa igual creamos un nuevo ide con la opcion de meter comandos, que, oye, igual es lo que mola.
Siempre (desde 1988) me han gustado las consolas y siempre he añorado en Windows una consola como la de linux (no la única, pero si razón de que me cambiara a linux hace 6 años).
Seguro que en el futuro se creará un sistema mejor para interactuar con los ordenadores pero hoy en día, no veo otra forma mejor que definir un lenguaje sobre el que expresar tus intenciones.
En un lenguaje, la suma al combinar las partes es factorialmente mayor que la suma de las partes. Conseguir eso con una UI no es imposible, pero es muchísimo más difícil y tremendamente menos componible.
El factor psicológico presumo que también es importante (pero npi) pues a las personas se nos da bien recordar «historias visuales» mientras que es más difícil recordar gramáticas y reglas estrictas.
Una terminal (consola, etc…) no deja de ser un lenguaje más o menos rico y las posibilidades por tanto frente a una UI son mucho mayores.
Claro que debe salir a cuenta, si uno únicamente realiza 10 acciones en su día a día le bastan 10 iconos en el escritorio, las tareas de un programador suelen admitir soluciones más creativas.
Yo muchas tareas las hago desde el terminal directamente y a mi me salen a cuenta, chorradas como «vim -p `find -name pom.xml | grep -Ril xcosa`» o el consecuente `sed`, etc… me resultan mucho más cómodas.
¿Si merece la pena? pues no se, cada cual verá, pero si que me pongo un poco nervioso cuando estoy esperando delante del monitor de alguien a que termine de hacer su «baile del ratón» xD xD
Para los que añorais una consola linux en windows, con ls, ssh, etc…
Permite tb abrir powershell, http://cmder.net/