¿Por qué no hay más lenguajes de programación que incorporen interfaces para el administrador de ventanas?

Question

La programación es fundamental para automatizar tareas en una computadora.
Presumiblemente, esas tareas normalmente serían realizadas manualmente por un humano.
Los humanos usan la computadora a través del teclado, el mouse y la interacción con la consola o el administrador de ventanas.
Pero muy pocos lenguajes han incorporado funciones que proporcionen una interfaz para estos objetos informáticos básicos.

Una excepción notable es autohotkey, un lenguaje de código abierto en Windows, que proporciona funciones integradas que permiten las siguientes tareas simples:
    * Obtener información de píxeles
    * Obtener la posición del mouse
    * Macros de teclado
    * Simular pulsaciones de teclas
    * Simular clic del mouse
    * Gestión de ventanas
Vea ejemplos en rosettacode .

Ha habido varios intentos de linux, muchos de los cuales se detuvieron sin explicación. Una es la biblioteca tcl inactiva: android. Busque el código de google para android, lang: tcl

Answer 1

Escribo el código del servidor web. Ningún ser humano interactúa con el código. Es simplemente una gran cantidad de complementos complejos para Apache.

" Los humanos usan la computadora a través del teclado, el mouse y la interacción con la consola o el administrador de ventanas. "

Esto es completamente falso en mi caso. El " usuario " envía solicitudes a través de HTTP. Sin teclado, sin mouse, sin consola, sin administrador de ventanas.

El usuario puede estar usando algún tipo de GUI elegante, pero no me importa a mí ni a mi software. Todo lo que veo son solicitudes HTTP GET y POST. Texto puro.

" Pero muy pocos lenguajes han incorporado funciones que proporcionen una interfaz para estos objetos informáticos básicos. "

Correcto. No tengo uso para el teclado, el mouse, la consola o el administrador de ventanas.

Answer 2

Todas las plataformas de computación personal tienen bibliotecas que lo harán.

El problema es que eso requeriría estandarizar las interacciones del usuario en todos los sistemas. Java intentó esto, sin mucho éxito. Ha habido otras bibliotecas con más o menos éxito, Qt probablemente sea la más prometedora hasta la fecha.

Ciertamente es posible escribir un lenguaje para una única plataforma que incluya todos los fundamentos de la interfaz de usuario. También es posible simularlo con una GUI y una biblioteca. Sin embargo, hay buenas razones para querer un lenguaje que se pueda usar en cualquier plataforma importante, ya sea que haya o no una GUI.

Answer 3

Dudo que la premisa sea cierta. Java puede hacer todo eso, excepto tal vez "gestión de ventanas" ya que no sé qué significa esto.

Me sorprendería si no puede hacerlo con C #.

Si hay muchos idiomas que no pueden hacer esto, supongo que es porque es difícil hacerlo sin vincular el idioma al sistema operativo.

Answer 4

En primer lugar, creo que se pregunta por qué las bibliotecas estándar de los lenguajes de programación no tienen interfaces integradas para el administrador de ventanas. El lenguaje en sí y sus bibliotecas son bastante distintos.

Una gran razón es la portabilidad. Si hay demasiadas funciones específicas en las bibliotecas de un lenguaje de programación, será más difícil portarlo a otros sistemas. Por ejemplo, E / S, funciones matemáticas, cadenas, varias estructuras de datos y algoritmos relacionados, son todos genéricos y pueden funcionar en prácticamente cualquier computadora.

Pero cosas como el administrador de ventanas, la GUI, etc., son mucho más específicas para ciertas plataformas, por lo que no están incluidas en las bibliotecas estándar. Esto es lo que hace que C / C ++ sea tan portátil.

Answer 5

Las tareas realizadas por computadoras sin ninguna interacción de dispositivo de interfaz humana superan en número a aquellas directamente accionadas por un humano por un factor enorme.

Answer 6

Los lenguajes de programación intentan (o al menos lo intentan actualmente) ser independientes con la plataforma. Ejemplo en .net, debe hacer referencia a alguna API de Win32 para hacer algunas de las cosas que especificó anteriormente. Al incorporarlo en el modelo de lenguaje de programación central, .net se vinculará demasiado con el sistema operativo, por lo tanto, crear su contraparte Mono será demasiado tedioso.

Con respecto a las pulsaciones de teclas, macros y algunas cosas, la forma más sencilla de hacerlo ahora es vbscript verdadero o en powershell :)