¿El desarrollo de aplicaciones CLI se considera "hacia atrás"? [cerrado]

Soy un incipiente DBA con mucha experiencia en programación.

He desarrollado varias aplicaciones CLI no interactivas que resuelven algunas tareas repetitivas diarias o eliminan el error humano de tareas más complejas, aunque no tan cotidianas. Estas herramientas ahora son parte de nuestra caja de herramientas.

Creo que las aplicaciones CLI son geniales porque puedes incluirlas en un flujo de trabajo automatizado.

Además, la filosofía de Unix de hacer una sola cosa, pero hacerlo bien, y dejar que el resultado de un proceso sea la entrada de otro, es una excelente manera de construir un conjunto de herramientas que se consolidarían en una ventaja estratégica.

Mi jefe comentó recientemente que desarrollar herramientas de CLI es "hacia atrás" o constituye una "regresión".

Le dije que no estaba de acuerdo, porque la mayoría de las herramientas de CLI que existen ahora no son heredadas, sino proyectos en vivo con versiones mejoradas que se lanzan todo el tiempo.

¿Se considera este tipo de desarrollo "hacia atrás" en el mercado?

¿Se ve mal en un currículum vitae?

También consideré todas las soluciones, ya sean web o de escritorio, deben tener opciones de línea de comandos, no interactivas. Algunas personas consideran que esto es un desperdicio de recursos de programación.

¿Es este objetivo digno en un proyecto de software?

También creo que para una aplicación web o de escritorio, tener una interfaz CLI alternativa es una excelente manera de demostrar que la lógica empresarial está completamente desconectada de la GUI.

Tener la capacidad de trabajar con una 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 estaba inactiva".

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

Básicamente se reduce a "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 apoderado inexorablemente del 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 las personas; 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 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á haciendo, si está escribiendo herramientas de productividad de automatización, entonces no está haciendo nada malo al darles una CLI.

The Art of Unix Programming de Eric Raymond es el trabajo canónico para el argumento que está haciendo. No intentaré condensar su excelente libro en un par de párrafos. Sin embargo, tenga en cuenta que el argumento se aplica principalmente a los programadores, administradores que automatizan tareas mediante secuencias de comandos o usuarios avanzados de software altamente técnico como CAD.

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

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

Por lo tanto, considere cuidadosamente qué roles tienen sus usuarios cuando usan sus utilidades, y planifique la interfaz de usuario en consecuencia. Si su jefe lo menciona, lo más probable es que necesite mejorar la documentación y / o capacitación en la CLI como mínimo. Si constantemente le dice a las personas que una función solo está disponible en la CLI cuando la esperan para la GUI, probablemente deba repensar sus prioridades de desarrollo, teniendo en cuenta mejor las necesidades de sus usuarios.

No es solo Unix el que está impulsado por los programas de línea de comandos. Microsoft también se dirige hacia allí.

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

La mayoría de las GUI de 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 lo 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 dirige hacia allí ... ¡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 catclon o "un programa para imprimir el contenido de un archivo en la pantalla", eso es muy factible con CLI.

Sin embargo, ¿qué pasaría si no usara la CLI? Bueno, entonces tendría un programa básico con una GUI que mostraría algo de texto. Pero también tendrías que vincular la apertura de 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 para usted, el desarrollador) combinarlo con otras herramientas.

Ahora, dicho esto, los programas CLI están comenzando a verse como "al revés". Esto se debe a que gran parte del desarrollo de aplicaciones en estos días ocurre en mercados donde los usuarios que combinan su herramienta con otras herramientas es casi imposible. No voy a entrar en eso aquí, pero escribí una publicación de blog sobre cómo "los mercados hacen cumplir la mentalidad de maestro de ninguno", 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 excelente para permitir que un usuario realice ciertas operaciones enlatadas rápidamente. La CLI es para cuando quieres hacer cosas que la GUI no te permite hacer. El CLI suele ser más potente 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 {} \;

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

Un buen desarrollador puede 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 aprender las complejidades de la CLI más adelante.

Una buena lectura (larga y sesgada (?)) En la compensación CLI / GUI está en:

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

No, no es al revés en absoluto.

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

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

Existe esto por Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

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

Mi preferencia personal en esto son las herramientas CLI que ofrecen una opción --gui o --verbose suficiente para permitir que un contenedor GUI interactúe de manera robusta, incluidas las barras de estado y otros elementos básicos que las personas buscan 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 excelentes herramientas de CLI en una GUI personalizada sin modificar dichas herramientas de CLI. En la mayoría de los casos, esto solo se hace para ofrecer una opción de GUI en una CLI particular, pero la idea de manejar múltiples herramientas con una GUI orientada a "procesos" o "casos de uso" puede ofrecer resultados similares a las tuberías y la redirección y la secuencia de comandos para ese caso de uso, poniéndolo a disposición de las personas que no realizarían esas operaciones con la suficiente regularidad como para alcanzar el dominio sin inhibir a los usuarios de CLI.

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

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

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

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

En los casos en que no se conocen, o tal vez la realización de las operaciones no se realiza con la suficiente regularidad como para permanecer sólida y libre de errores, la ejecución de la GUI proporciona un entorno que puede verificarse fácilmente, las operaciones encadenadas y luego ejecutarse con confianza, sin necesidad de secuencias de comandos.