¿El desarrollo de las aplicaciones de CLI se considera "atrasado"? [cerrado]

Tener la capacidad de trabajar con un CLI no es lo que consideraría al revés. Se ve muy bien en un currículum, especialmente si puede girarlo en su currículum con una frase como "Usado (Powershell / Bash) para crear un conjunto de herramientas de automatización para enviar mensajes SMS cuando la base de datos no funcionó".

Cuando soy responsable de contratar personas, busco un conocimiento práctico de la CLI.

Básicamente, se trata de "usar la herramienta adecuada para el trabajo".

Si tiene que interactuar con un usuario, querrá algún tipo de GUI. Tenemos décadas de investigación y experiencia que demuestran que hacen que la informática sea mucho más intuitiva y productiva. Es por eso que las GUI se han llevado inexorablemente al mundo desde 1984: simplemente funcionan mejor para interactuar con las personas.

Pero si está automatizando un programa con scripts, su programa no está interactuando con la gente; está interactuando con un guión. Y la mejor interfaz para eso es una basada en texto, por razones que deberían ser intuitivamente obvias.

El desarrollo de los programas CLI para que los usuarios trabajen directamente se considera al revés y con buena razón. Pero si eso no es lo que estás haciendo, si estás escribiendo herramientas de productividad de automatización, entonces no estás haciendo nada malo al darles un CLI.

La Programación del Arte de Unix de Eric Raymond es el trabajo canónico del argumento que está formulando. No intentaré condensar su excelente libro en un par de párrafos. Sin embargo, tenga en cuenta que los argumentos se aplican principalmente a los programadores, a los administradores que automatizan las tareas mediante scripts o a los usuarios avanzados de software altamente técnico como CAD.

Incluso con usuarios altamente técnicos, debes considerar qué sombreros están usando en ese momento. Por ejemplo, escribo software integrado para equipos de redes para la vida. Todos nuestros productos tienen una CLI y una GUI, pero los desarrolladores prefieren la CLI casi universalmente, debido a su flexibilidad, capacidad de script, disponibilidad, velocidad, etc.

Sin embargo, ese mismo grupo de desarrolladores exactamente prefiere la GUI en nuestro software de control de versiones, a pesar de que su CLI es más potente y está soportada y documentada tan bien como la GUI. La diferencia es que somos los usuarios finales del software de control de versiones, no los administradores ni los desarrolladores.

Considere cuidadosamente en qué roles están sus usuarios cuando están usando sus utilidades, y planifique la interfaz de usuario como corresponde. Si su jefe lo menciona, lo más probable es que necesite mejorar la documentación y / o capacitación en el CLI por lo menos. Si constantemente le está diciendo a la gente que la función solo está disponible en la CLI cuando la esperan para la GUI, es probable que necesite reconsiderar sus prioridades de desarrollo, teniendo en cuenta las necesidades de sus usuarios.

No solo Unix está controlado por programas de línea de comandos. Microsoft también se dirige hacia allí.

Microsoft ha estado presionando a PowerShell desde hace algún tiempo. Todo su software de servidor actual (Exchange, SharePoint, Server 2012, System Center, etc.) se puede controlar completamente a través de la línea de comandos de PowerShell. Y PowerShell se basa en pequeñas funciones que hacen una cosa bien y canalizan los datos a la siguiente (aunque canaliza objetos en lugar de solo texto).

La mayoría de las GUI para esos programas son simplemente una interfaz para los comandos de PowerShell, muchos incluso le dicen qué comandos se ejecutarán para facilitar las secuencias de comandos. Todo lo que puede hacer desde la GUI que puede hacer desde PowerShell. Lo contrario no es cierto: hay bastantes funciones que están expuestas solo en PowerShell.

Entonces, si * nix siempre lo ha hecho, y Microsoft se está dirigiendo de esa manera ... ¡no me parece muy al revés!

Definitivamente no diría que es algo malo. Lo bueno de los programas CLI es que al implementarlos, puede tener un alcance muy restringido. Por ejemplo, si quiero escribir un clon de cat o "un programa para imprimir el contenido de un archivo en la pantalla", eso es muy factible con CLI.

Sin embargo, si no usas CLI, entonces tendrías un programa básico con una GUI que mostraba algo de texto. Pero también tendrías que vincularse para abrir un cuadro de diálogo de archivo y conectarlo ... pero alguien también quiere poder modificar el texto y guardarlo en otro lugar ...

Scope creep es ridículo con las aplicaciones GUI. Sin embargo, es muy fácil de evitar con las aplicaciones CLI. "¿Desea editar el archivo y luego volver a guardarlo? cat foo > ed > bar " Con las aplicaciones CLI es trivial para sus usuarios (no usted, el desarrollador) combinarlo con otras herramientas.

Ahora, dicho esto, los programas CLI están comenzando a verse como "hacia atrás". Esto se debe a que gran parte del desarrollo de aplicaciones en estos días ocurre en los mercados donde los usuarios que combinan su herramienta con otras herramientas son casi imposibles. No voy a entrar en eso aquí, pero sí escribí un publicación del blog sobre cómo "los mercados imponen una mentalidad de maestro de nada", que es todo lo contrario de una aplicación CLI bien diseñada (para hacer una cosa y hacerlo bien)

La GUI y la CLI tienen su lugar. La GUI es ideal para permitir que un usuario realice ciertas operaciones enlatadas rápidamente. La CLI es para cuando desea hacer cosas que la GUI no le permite hacer. El CLI suele ser más poderoso y más difícil de usar.

Una buena herramienta CLI le permite al usuario hacer cosas que la persona que escribió la herramienta nunca pensó. Un ejemplo es el comando 'encontrar' de UNIX. Este comando:

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

encuentra los archivos en el directorio actual (pero limitado a 5 niveles abajo) que tienen un nombre que comienza con 'xyzzy' y se modificaron hace más de 3 días y luego los eliminan (nota: código no probado). Y eso es un uso moderadamente simple. Puede usar un administrador de archivos para hacer ese tipo de cosas, pero tomará más tiempo y es propenso a errores. Por supuesto, ser más poderoso significa que la CLI puede ser mal utilizada más fácilmente y crear problemas para ti mismo.

Un buen desarrollador podría escribir una herramienta CLI de tal manera que también tenga una GUI que permita realizar un conjunto limitado de operaciones. El usuario puede comenzar con la GUI y conocer las complejidades de la CLI más adelante.

Una buena (larga y sesgada (?)) leída en la compensación de CLI / GUI se encuentra en:

http://www.cryptonomicon.com/beginning.html

No, no está al revés en absoluto.

La "dirección" tiene mucho que ver con nuestra perspectiva. Un usuario satisfecho con la ruta actual hacia las interfaces simples, "una experiencia en todos los dispositivos" verá el CLI como un retroceso o una regresión con seguridad. No está en línea con sus expectativas generales.

Un programador, administrador o usuario avanzado puede verlo como la progresión lógica de las herramientas según su experiencia. Muchos de estos comienzan utilizando herramientas de GUI. Cuando quieren o necesitan escalar, rápidamente se dan cuenta de por qué existe el CLI y de que la progresión resuena con aquellos que crean más herramientas de CLI.

Hay algo de Paul Ferris: enlace

Para mí, personalmente, la idea de sintaxis diferencia las dos. Cuando la sintaxis está algo presente en una GUI, el resultado casi nunca es bueno y la sintaxis CLI tan flexible y bien pensada. Cuando esto se combina con tuberías y redireccionamiento, la GUI se desinfla debido a que no es muy útil fuera de los casos de uso planeados.

Mi preferencia personal en esto son las herramientas CLI que ofrecen una opción --gui o --verbose suficiente para permitir que un contenedor de GUI interactúe de una manera sólida, incluidas las barras de estado y otros elementos básicos que la gente busca en la GUI.

Por supuesto, el costo de esto es esencialmente dos programas con uno bastante inútil sin el otro, pero el mayor beneficio es poder incorporar una o más herramientas de CLI grandes en una GUI personalizada sin modificación a dichas herramientas de CLI. La mayoría de las veces, esto solo se hace para ofrecer una opción de GUI en una CLI particular, pero la idea de manejar múltiples herramientas con un "proceso" o una GUI orientada al "caso de uso" puede ofrecer resultados similares a la canalización, la redirección y la creación de scripts para ese caso de uso. ponerlo a disposición de las personas que no realizarían esas operaciones con la regularidad suficiente para alcanzar el dominio sin inhibir a los usuarios de la CLI.

Encontré este enfoque en SGI IRIX y realmente me gustó. Me encontré usando la GUI o la línea de comando según fuera necesario y lo bueno era saber exactamente lo que realmente hacían los botones de fantasía.

Donde hay muchos entornos operativos diferentes, las envolturas de GUI pueden diferir considerablemente sin afectar también a la herramienta CLI.

Veo esto en Linux hoy con cosas como las herramientas de disco / sistema de archivos, donde la GUI puede agregar mucho valor incluso a los usuarios conocidos de CLI.

En el caso de los sistemas de archivos / discos / dispositivos conocidos, eliminar la CLI no es difícil y, por supuesto, puede tener secuencias de comandos. Sin embargo, los errores pueden ser dolorosos.

Cuando no se conozcan, o tal vez no se realicen las operaciones con la regularidad necesaria para permanecer sólidas y sin errores, la ejecución de la GUI proporciona un entorno que puede verificarse fácilmente, las operaciones se pueden encadenar y luego ejecutar con confianza, no scripts requeridos.