¿Por qué preferimos la línea de comandos a los GUIs?

17
3980

Revisando otros artículos me topé con esta pequeña pregunta que me causó mucha gracia, es verdad que una de las primeras cosas que nos sacan en cara usuarios de otros sistemas (excepto FreeBSD) es que no usamos los GUIs. A decir verdad, a mi también me pareció bastante curioso al principio de mi viaje por GNU/Linux. Debo admitir que con el pasar del tiempo, ahora utilizo mucho más la línea de comandos que cualquier otro programa con GUI, y muchas veces prefiero programas dentro de la línea de comando a programas más elaborados con GUIs deslumbrantes.

El mito

En realidad esto no es más que un mito urbano, pues a diferencia de otros sistemas cuyos nombres no serán mencionados aquí, es en GNU/Linux donde realmente tienes libertad de elección. Ya quisiera que en otros sistemas existiera la versatilidad que existe aquí. Pero veamos en más profundidad este asunto, que sino no quedan claras muchas cosas:


Servidores

Todos hemos oído de la palabra Servidor, algunos creen que son esas super computadoras que alimentan Google o Amazon, o la que está en tu empresa. Pero la realidad es que un Servidor responde a un modelo de trabajo. Usamos este término para hacer referencia a que tenemos un programa que está a disposición de los usuarios (clientes) y les entrega algo. Un ejemplo básico es Apache, el cual se usa para servir páginas web en internet. Este programa entrega html a los clientes que lo soliciten.

Servidor de imágenes

Pero no solamente un servidor puede estar en las super computadoras que hacen posible Google y otras muchas empresas, incluso la laptop más “antigua” puede ser un servidor, de manera especial cuando hablamos de imágenes. Todos corremos un servidor de imágenes en nuestras laptops para poder tener una pantalla funcional, en este caso el servidor y el cliente son la misma persona. El ejemplo más común es X (conocido como xorg-server en muchas distribuciones) y su nuevo reemplazo Wayland. No vamos a dar una explicación detallada de por qué el org, o cómo es que Wayland funciona, o las filosofías que existen atrás de estos grandes proyectos, pero si vamos a dejar claro que es gracias a ellos que nosotros podemos contar con un navegador web como Firefox o Chrome, o muchos otros programas.

Gestor de ventanas

Los gestores de ventanas trabajan directamente con el servidor de imagen, su trabajo es de un nivel más “bajo”, puesto que gestionan (valga la redundancia) cómo es que se crean, modifican, cierran las ventanas. Suelen ser bastante simples y sobre estos se construyen los entornos de escritorio. La lista es grande, pero solo dejaré aquí la idea de que son softwares minimalistas, los cuales permiten tener un control bastante básico del servidor de imagenes.

Entorno de escritorio

Un conjunto más especializado de software que permite no solamente un funcionamiento del servidor de imagen, sino también proporcionan capacidades de personalización. Dentro de estos los más antiguos y pesados son KDE y GNOME, pero también tenemos entornos más ligeros como LXDE o Mate, Cinnamon, etc.

CLI (Command Line Interface)

Tras un breve repaso por el mundo de los servidores de imágenes, ahora nos centramos nuevamente en nuestro tema. CLI, implica todo aquel programa que se ejecuta por línea de comando, ya sea git, vim, weechat, o bueno, cualquier otro que se les venga a la mente. Pueden apreciar que estoy hablando de programas que si bien se ejecutan en la línea de comando, muestran una especie de “interfaz gráfica” como weechat o vim. Para todos los que no los hayan probado, se los recomiendo, son básicamente los que uso todo el día.

Por qué CLI es mejor que GUI

Intentemos algo bastante sencillo 🙂 El otro día quería trabajar en un parche para Portage (el gestor de paquetes de Gentoo). Como todo buen proyecto colaborativo, la cantidad de líneas de código supera los 70k. Intenten abrir eso en un IDE como NinjaIDE (Portage está escrito en Python) y no tardarán en notar que en lo que empieza a cargar la pantalla, su máquina se pone sumamente lenta (al menos mi i7 si lo hacía) y esto solamente tratando de abrir el código y cambiar al color por defecto de “ayuda”.

Ahora intenten hacer lo mismo con vim, a mi me cargó en cuestión de milésimas de segundo, y al mismo tiempo que ponía los colores “bonitos” y todo lo demás.

CLI ha estado mucho antes

Algunos aquí dirán que esos programas son antiguos, yo los llamo robustos. Si pudiesen ver la cantidad de horas invertidas en construir emacs, vim, gdb, y otros cientos de programas para consola, podrán notar que la cantidad de código y funcionalidades es tan grande que practicamente ya han solucionado todo lo que necesitaban solucionar. Muchos GUI para programas que ya son robustos en su CLI jamás tendrán la misma cantidad de funcionalidades, esto sencillamente porque si hicieramos una pestaña para cada subcomando disponible de por ejemplo git, nos perderíamos entre las opciones y sería contraproducente, porque haría difícil el trabajar.

CLI es más rápido

La mágia comienza con la tecla Tab, esta no solamente es tu mejor amiga al momento de navegar por los escritorios en tu terminal, sino que cuando está bien configurada, te permite acortar sentencias largas a 2 letras y un Tab, 3 letras y un Tab, o incluso una letra y un Tab.

Pero esta no es la única ventaja, los que hemos tomado el tiempo de aprender vim o emacs podemos decir que aunque la curva de aprendizaje sea un poco mayor a la de los IDE de estos días, al final los resultados de productividad son asombrosos, uno no se imagina el tiempo que puede perderse al mover un mouse. El tener las manos en el teclado el 90% del tiempo no solo enseña concentración, además, el hecho de escribir tanto en el teclado te hace bastante ágil y productivo. Y ahora volvemos al punto anterior, al llevar tanto tiempo con nosotros, programas como estos ya cuentan con todas las funcionalidades que se le puedan ocurrir a alguien, un dicho bastante común para los que usamos vim me viene a la mente:

Si usas más de 4 teclas, puede haber una forma mejor.

Sencillo pero poderoso, vim te permite hacer todo con la gran cantidad de teclas y combinaciones posibles, uno nunca deja de aprender, pero no deja de ser verdad también que para poder usarlo no es necesario saberlas todas, bastan unas 10 o 15 para empezar a ser más productivo.

CLI te da el control absoluto

Cuando uno ejecuta operaciones con el mouse, o programas desde el servidor de imágenes, no siempre se tienen presente todas las configuraciones extra que se ejecutan al momento de dar click, esto no sucede con la terminal, aquí tu tienes el poder absoluto de lo que se ejecuta o no, con qué opción o hasta qué punto. Con el tiempo te vas dando cuenta que necesitas menos de lo que piensas, y eso te ayuda a hacer las cosas de forma más centrada.

GUI también tiene lo suyo

No voy a decir que todos deberíamos usar CLI siempre, eso tampoco es lo ideal, yo mismo uso GUIs casi todo el tiempo, para escribir este post estoy usando mi Chrome, y para ver mis correos uso Evolution (aunque también uso mutt bastante últimamente). Y supongo que este es el mayor mito de todos… que la gente piense que GNU/Linux son solamente termianles, a mi me gusta mi entorno de escritorio, es bastante minimalista, pero a mi me gusta así 🙂 Y usualmente solo tengo dos o tres programas corriendo, mi Chrome, mi Evolution y mi terminal 🙂

Estos son unos de los motivos por los que me gustan tanto las CLI y por los que los invito a darles una oportunidad, puede que después terminen como yo usando más CLIs que GUIs 😉 Saludos

17 COMENTARIOS

  1. “Como todo buen proyecto colaborativo, la cantidad de líneas de código supera los 70k. ” Esta parte me hizo demasiado ruido. Existe alguna imposibilidad técnica por la que el código tenga que verse compactado en una mismo archivo? No sería mejor separar comportamiento en diferentes entes (files/clases/modulos)?
    No pareciera ser una razón válida para imponer una tecnología por sobre otra, dejar de lado las ventajas que propone una por una carencia en la forma de desarrollo. De cualquier manera estoy hablando sin saber a qué proyecto en particular refiere, por ahí existe una causa mayor que fuerce esa forma de trabajo

    • Hola,

      Pues tal vez esto requiere un poco de explicación, pero a lo que me refiero como “buen proyecto” implica que la cantidad de líneas expresa que es una comunidad sana que se mantiene en crecimiento. Existen proyectos con una mucho menor cantidad de líneas, pero bastante sanos en su desarrollo. A decir verdad sí, portage está dividido en la mayor cantidad de archivos posibles, pero siempre es necesario mantener agrupadas porciones como librerías, o switchs que derivan en bastantes otras funciones. Pero al momento de importar un proyecto en muchos IDE de hoy en día, eso implica que va a leer todos los archivos del proyecto y tratar de poner el formato “visual” correcto.

      Espero dejarlo un poco más claro 🙂 y gracias por comentar.
      Saludos

  2. Uso de la línea de comandos? Sí, pero solo cuando proceda. Es decir, cuando sea más cómodo y rápido. Por ejemplo, si quiero instalar un determinado programa para mí es más cómodo escribir sudo apt install nombreprograma que abrir un gestor de software, buscarlo, marcarlo para instalar y pulsar “instalar”. Pero por lo general esto no es así. Por ejemplo: si quiero copiar las 20 canciones que más me gustan de un directorio a otro es super-cómodo hacer Ctrl+Click mientras revisas tranquilamente una enorme lista desde un gestor de archivos y después arrastrar y soltar. Otro ejemplo: si quiero particionar un disco es mucho mejor hacerlo a través de gparted (programa que ejecuta multitud de comandos mientras te muestra gráficamente cómo quedará el disco) que realizarlo manualmente. La lista podría ser interminable. Las GUI pueden (de hecho suelen) facilitar mucho el trabajo, además de añadir funcionalidades que para una determinada aplicación cli pudieran ser imposibles

    • bueno eso depende de qué tan cómodo se sienta uno con la línea de comandos… por ejemplo:

      find dir/musica -name "archivo" -exec grep cp {} dir/nuevo \;

      con un poco de mágia en bash puedes incluso hacer una función que ejecute lo mismo con tan solo poner el nombre de la canción:

      algo como

      mover(){
      find dir/musica -name $1 -exec grep cp {} dir/nuevo \;
      }

      y listo! puedes mover todas tus canciones con un simple

      mover cancion1.mp3

      🙂 En cuanto a lo segundo, aunque en parte las GUI hacen más “simple” el trabajo al evitar recordar y repetir comandos, esto solo es útil en marcos generales, cuando necesitas algo especializado, gparted o cualquier otro GUI puede quedar corto 🙂 y los GUI no añaden funcionalidades extra, solamente toman las que existen en CLI (no todas) y las agrupan, pero no las crean 🙂

      Saludos

      • por mucho que se automatice el proceso con:
        mover cancion1.mp3

        después, necesariamente, habrá:
        mover canción2.mp3
        mover cancion3.mp3
        .
        .
        .
        mover cancion20.mp3
        son muchos mover canciones…
        con cualquier gestor de archivos.. solo suponen 20 clicks y un gesto de drag&drop. No sé, pero al menos mi gestor (Dolphin) me permite de forma simple y superrápida (menos de 5 segundos) ordenar una lista de 100 canciones por nombre, fecha, tamaño, etiquetas, ranking, álbum, artista, duración, etc.. para mí eso es PRODUCTIVIDAD y también es añadir funcionalidades a la línea de comandos.

        En cuanto al otro ejemplo.. GParted: DE ACUERDO.. si se necesita algo muy especializado como por ejemplo variar el valor por defecto de los bytes por inodo a la hora de formatear se deberá acudir a la consola.. pero amigo, eso no es lo normal. El 99% de las veces GParted cumplirá perfectamente con nuestras necesidades de forma muy simple y muy rápida y, al menos para mí, eso también productividad

        Saludos

        • Bueno, eso es un ejemplo de automatización en su expresión más mínima, como tu dijiste “si quiero copiar mis 20 canciones que más me gustan de un directorio a otro”, todo eso cuenta con el tiempo que te toma revisar “calmadamente” tu lista tras ordenarla y además dar click y etc, la terminal permite eso y mucho más en solo una línea, tal vez unos 0.1 segundos de ejecución en tu procesador (así sea antiguo), si tus ojos y el mouse pueden superar eso, pues me voy a los GUI 🙂 y no es que yo haya dicho que no los uso, tienen muchas cosas útiles, no lo voy a negar, pero yo al menos he encontrado en la terminal una versatilidad mucho mayor, además de ayudarme a practicar un poco de programación todos los días al momento de automatizar trabajos. Un dicho muy común entre SysAdmins es “si haces lo mismo más de una vez al día, automatízalo, si lo haces una vez al día más de dos días, automatízalo, si lo haces incluso una vez al mes, automatízalo” .

          Pero bueno, en cuanto a gustos y colores cada uno tiene lo suyo, yo me limito a compartir las cosas que a mi me gustan 🙂 y tal vez haya mucha gente que le tiene “miedo” a cosas como emacs, vim, o la misma terminal, con estos posts solo intento darles un poco de confianza y curiosidad para que los prueben y decidan 🙂

          Saludos

          PS: Conozco a muchos developers a los que los GUI no les solucionan las cosas por la cantidad de complejidad que requieren en su día a día, que tal vez un usuario “común” nunca va a ver, pero eso no implica que los usuarios más “comunes” puedan usar estas herramientas y obtener los mismos beneficios más versatiles.

          • Sigo pensando que para esa tarea (y otras muchas más) se tarda muchísimo menos utilizando un gestor de archivos que con la la línea de comandos.. pero bueno, como dices hay gustos y colores para todos.

            yo no reniego ni tengo miedo a la terminal, pero tampoco lo veo como una condena casi obligatoria, por eso empecé diciendo “Línea de comandos sí, pero cuando proceda”

            En cuanto a los developers hay de todo, pero la balanza se inclina claramente hacia un lado: Te invito a que eches un vistazo a:

            https://pypl.github.io/IDE.html

            Parece que los developers “comunes” sí ven las ventajas de trabajar en un entorno gráfico lleno de facilidades si lo comparamos con quien apuesta por trabajar con editores “solo-texto”

    • Por ejemplo: si quiero copiar las 20 canciones que más me gustan de un directorio a otro es super-cómodo hacer Ctrl+Click mientras revisas tranquilamente una enorme lista desde un gestor de archivos y después arrastrar y soltar.

      Existen gestores de archivos de línea de comandos que son tan prácticos o más que los gráficos, como Vifm o Ranger. También para particionar discos hay aplicaciones en línea de comando como cgdisk con una interfaz e ncurses.

      • Pues es cierto 🙂 no sé muy bien por qué hay tanta gente que teme a la terminal, en realidad es una herramienta muy robusta y versatil, algo que todo el mundo debería probar al menos una vez a profundidad.

        Gracias por compartir y saludos.

      • Sí, los gestores de archivos de terminal existen desde antes que los gráficos. En cuanto a lo práctico depende de lo que se quiera. Cualquier gestor de archivos gráfico viene provisto de pestañas, favoritos, modos de vista, vista previa, posibilidad de ordenarlo de 1000 formas diferentes, de acoplar una terminal, instalar plugings, etc, etc, etc. lo que les ace muchísimo más versatil que cualquier gestor de archivos de texto.

        Lo bueno no tiene por qué ser necesariamente feo

    • es solo que aprendas hacer lo que haces en cli, y te lo garantizo que será más facil, lo que mencionas muy facil lo harias con rsync y lo puedes hacer facilmente un script.

      Te recomiendo un gestor de archivos de cli llamdo ranger que tiene todo eso que mencionas.

  3. Maravilloso!!
    Aún no me decido a instalar Gentoo 🙁 (estoy en BunsenLabs) actualmente uso openbox y utilizo nano para mis script en Bash
    Pero me dan ganas de aventurarme por Vim o Emacs!
    Saludos
    Disfruto leyendo tus entradas

    • Muchas gracias Alberto 🙂 me alegra mucho que les gusten mis artículos, yo disfruto escribiendo los posts.
      Ojalá te animes y claro que sí, la cosa es probar siempre algo nuevo 🙂

  4. Bueno con este termino de contestar a los últimos dos comentarios y agradecería a los moderadores ya no aceptar más al respecto, esto no está yendo a para a ningún lado y la idea no es llenar la lista de comentarios con una serie de argumentación a favor o en contra de uno u otro.

    En cuando a la “versatilidad”, tal vez quien opine esto considere que solamente los GUI tienen plugins, pero la verdad es que los plugins para terminal son tan variados y funcionales como las personas que los usan, el ejemplo más claro es

    https://vimawesome.com/

    Una casi interminable lista de plugins para vim que lo convierten en algo más versátil que muchos IDEs… y hablando de eso, ese link no menciona que esa lista incluye la gente que usa IDEs en Windows y Mac, lo que habla mucho mejor en realidad de Vim de lo que habla de Eclipse puesto que si comparamos la cantidad de gente que usa Eclipse en las tres plataformas, Vim no tiene nada de qué avergonzarse de tener un bien merecido 4to puesto.

    Pero yendo un poco más allá… que la gente “común” use algo no dice que esto sea necesariamente bueno, sino probablemente Windows sería mucho mejor que los demás sistemas 🙂 tal vez sea solo que prefieren no aprender a utilizar algo porque prefiere la opción fácil… o porque su empresa así ha decidido implementar el standard (Eclipse es standard en muchas empresas, eso explicaría la gran cantidad de usuarios… igual que Android y Visual Studio, los cuales son los únicos medios para trabajar con sus respectivos lenguajes… mientras que Vim es una elección LIBRE de los que lo usan)

    PS. “feo” es un término muy subjetivo, yo puedo considerar “feo” el diseño de Qt, o de WebKit, o incluso de la interfaz de Mac OS… pero eso no quiere decir que otro lo vea así, es solo cuestión de costumbres 🙂

    Saludos

  5. totalmente de acuerdo con Anonimo, mas en mi caso, soy un simple usuario, sin los conocimientos profundos de un analista o programador. y como tal, necesito de GUI que me failiten muchas de las treas en linux, por ejemplo al dia de hoy y siendo el año 2017, no hay una aplicacion GUI que facilite compartir carpetas en una red Linux, y digo Linux, no me salgan con Samba y Windows, hablo de una red netamente Linux. Para lograr compartir en una red Linux hay que configurar un tal NFS y solo de linea de comandos, se pierde tiempo y ademas no me explico por que es tan complicado tener una GUI quelo haga facil como ocurre en Windows.
    Segun ChrisADR “Soy un jóven desarrollador de software” y e ve que conoces mucho del tema, deberias desarrollar una aplicacion GUI que facilite lo que acabo de exponer o acaso lo tuyo es puro titulo y fanfarroneada?? Es lo mismo que, si un medico opinara sobre como es mejor realizar una cirugia, sin haber hecho nunca una. “en la cancha se ven los pingos” deberias desarrollar una aplicacion GUI antes de dar tu opinion desde tu lugar de “desarrollaor de software” y si es mejor o no usar el terminal, hay que ponerse en el lugar de quien usa Linux y para que lo usa. Ojala pueda ver un articulo de ChrisADR, presentando y commpartiendo su aplicacion GUI, para comparticion de archivos en una red Linux. De momento, no hay ninguna , a menos que uses Samba solo para compartir con Windows.

    • Crear un programa no es algo fácil de una tarde, requiere un esfuerzo de varias semanas al menos y lo que es peor, luego tenemos el esfuerzo de años arreglando errores, actualizándolo a la par que las nuevas librerías de funciones que dejen obsoletas las usadas anteriormente, el empaquetado para las distintas distribuciones, …
      Pero es que además, si ya tienes SAMBA que puedes usar también entre dos GNU/Linux sin necesidad de ningún Windows, ¿por qué quieres usar la solución de NFS?
      Aunque los manuales que veas por internet hablen de linux y windows, simplemente sigue las instrucciones para compartir una carpeta desde linux y luego para conectarte a otra carpeta en red desde linux también.
      Parece que Ubuntu 16.04 sigue teniendo una fácil implementación de este tema: http://www.hernanprograma.es/ubuntu/como-compartir-una-carpeta-desde-ubuntu-16-04-a-traves-de-samba/

Dejar una respuesta