Telescript es un lenguaje de programación orientado a agentes escrito por General Magic como parte del sistema Magic Cap general . Los programas de Telescript utilizaron una sintaxis similar a C modificada conocida como High Telescript y se compilaron en un lenguaje basado en pilas llamado Low Telescript para su ejecución. Low Telescript se ejecutó dentro de intérpretes de máquinas virtuales , o "motores Telescript", en equipos host.
El modelo básico de Telescript es similar a Java y se diferencia principalmente en el lugar donde se ejecutarían las aplicaciones. Java se modeló para permitir la descarga de aplicaciones Java en cualquier plataforma y ejecutarlas localmente. Telescript esencialmente revirtió esto, permitiendo que los equipos de usuario final con capacidades limitadas carguen programas de Telescript en los servidores para permitirles aprovechar las capacidades del servidor. Telescript incluso podría migrar un programa en ejecución; las características del lenguaje incluido para Mariscal código de un programa y serializado estado, lo transfieren a otro motor Telescript (en un dispositivo o un servidor) para continuar la ejecución, y finalmente vuelven al cliente de origen o el dispositivo de servidor para entregar su producción.
General Magic se había desarrollado originalmente como un equipo dentro de Apple Inc. , y se escindió en 1990. Cuando comenzaron a generar cierto entusiasmo en la prensa en 1992, Apple decidió ingresar al mismo mercado con su computadora tableta Newton . General Magic no pudo encontrar un nicho en el mercado y los servicios de Telescript pronto quedaron obsoletos en favor de nuevos productos no relacionados con la informática móvil .
Historia
En 1990, Marc Porat convenció al entonces director ejecutivo de Apple, John Sculley, de que el futuro de la informática no estaba en las computadoras personales de escritorio , sino en dispositivos portátiles mucho más pequeños que combinaban potencia informática, sistemas de comunicaciones y datos ubicados en servidores accesibles en red. [1] Señaló que las computadoras portátiles siempre tendrían menos energía que las máquinas a las que se conectarían y sugirió que esto fuera parte del diseño, en lugar de intentar construir una computadora portátil que pudiera realizar las tareas de un sistema de escritorio, el El dispositivo portátil debería utilizar de forma invisible la potencia computacional de los servidores para producir un resultado similar. [2] [3]
Sculley acordó permitir que Porat comenzara a investigar los conceptos bajo el nombre en clave "Pocket Crystal". Los miembros clave del equipo inicial fueron Porat y los famosos desarrolladores de Macintosh Bill Atkinson y Andy Hertzfeld . El equipo rápidamente se vio ignorado por la alta dirección y se fue continuamente luchando por los recursos. Se acercaron a Sculley nuevamente con la idea de escindir Pocket Crystal como una compañía separada. Sculley estuvo de acuerdo con esto, así como con la idea de invitar a nuevos socios en el lado del hardware. La nueva empresa, General Magic (GM), se creó en mayo de 1990 con Apple, Sony y Motorola con una participación del 10% cada una. Las filas de la compañía pronto se completaron con otros alumnos de Macintosh, incluidos Joanna Hoffman , Susan Kare , Dan Winkler, Bruce Leak y Phil Goldman . [1]
En 1992, GM había firmado acuerdos de desarrollo con varias empresas para trabajar con el entorno Magic Cap, incluidas Sony, Motorola, Matsushita , Philips , British Telecom y AT&T Corporation . Esto generó un considerable revuelo en la prensa. [3] Para entonces, Apple había comenzado el proyecto Newton , un diseño para una computadora de mano más grande similar a una tableta más similar al iPad de tamaño completo . Con el éxito de General Magic en la prensa, reubicaron al Newton directamente en el mismo mercado y se apresuraron a lanzarlo en 1993. También vendieron su participación en General Magic y los demandaron. Los socios de General Magic no lanzaron hardware hasta 1994, momento en el que Newton había definido esencialmente lo que debería ser un asistente digital personal (PDA), y los sistemas PDA estaban siendo juzgados por sus capacidades de reconocimiento de escritura a mano . Magic Cap era una interfaz de apuntar y hacer clic (similar a HyperCard o al iOS moderno ). [2]
En 1995, la empresa era un caparazón de lo que era antes y la mayoría de los desarrolladores originales se habían marchado. En 1996, Steve Markman fue contratado para hacerse cargo, y él contrató a Kevin Surace para que llevara la empresa en una nueva dirección. Un nuevo equipo desarrolló el sistema de asistente personal telefónico Portico, que sigue vivo hoy como la base de OnStar . El grupo de dispositivos de mano original se escindió en 1998 como DataRover Mobile Systems Incorporated y luego pasó a llamarse Icras en 2000, [4] sirviendo a varios mercados verticales antes de cerrar en 2001. [5] Los restos de la empresa original se liquidaron en 2004. [3]
Descripción
Conceptos subyacentes
Telescript se inspiró en el concepto de pequeños programas conocidos como agentes que interactuarían con servicios informáticos conocidos como lugares, todos los cuales se ejecutarían en un clúster de uno o más servidores que alojaban lo que se llamó una nube Telescript. El dispositivo de mano del usuario era uno de esos lugares, aunque con capacidades limitadas. El modelo asumió que la mayor parte de la información y los servicios serían proporcionados por lugares que se ejecutan en computadoras servidor más grandes alojadas por proveedores de comunicaciones como AT&T. Incluso los primeros documentos se refieren a esto como ejecución en la nube . [1] Los programas orientados al usuario consistirían en varios de estos agentes, que podrían ejecutarse localmente, en los hosts del proveedor, o incluso reenviarse a servidores de terceros. Para coordinar las comunicaciones, Telescript también incluyó los conceptos de un nombre de teléfono que identificaba de forma única a los usuarios y direcciones de teléfono que identificaban el dispositivo incluso cuando se movía entre redes. [6]
Por ejemplo, considere una aplicación de compras que el usuario solicita para encontrar los precios de una nueva parrilla que desea comprar. En un modelo cliente-servidor tradicional , la aplicación formaría una serie de consultas, las enviaría a varios servicios y luego recopilaría los resultados y los mostraría. En el modelo de Telescript, la aplicación crearía un nuevo agente con los datos de la solicitud, lo estamparía con su nombre y dirección y luego lo enviaría a una tienda en un servidor para su procesamiento. Ese servidor podría manejar la solicitud directamente o transferir al agente a otros lugares, como los lugares de los proveedores reales, para su procesamiento posterior. Los resultados podrían colocarse en los campos de datos internos del agente y enviarse de vuelta a través de la red al dispositivo del usuario, o podría generarse un nuevo agente "mensajero" para llevar solo los datos del resultado y devolverse para minimizar la transferencia de datos de red. [7]
El modelo también se diferencia de las soluciones tradicionales en la forma en que se produce el intercambio de datos en el caso de programas interactivos. Por ejemplo, si el usuario opta por comprar una de las barbacoas que encontró en su búsqueda anterior, en un sistema convencional la tarea de completar los formularios de pedido y confirmar el pago se realizaría mediante comunicaciones directas entre el dispositivo del usuario y el servidor remoto, requiriendo un canal de comunicaciones "en vivo" durante todo el proceso. En el modelo de Telescript, un nuevo agente con la información necesaria para completar la compra se envía al lugar de la tienda de ese proveedor, interactúa con el lugar de la tienda o los agentes del proveedor y luego regresa con el éxito o el fracaso. Las comunicaciones principales tienen lugar entre los agentes y los lugares del servidor remoto, por lo que las comunicaciones a través de la red solo se requieren al inicio y al final del proceso. [8]
Telescript estaba orientado a objetos (OO) y usaba una serie de términos poco comunes para describir el estado de los objetos y las comunicaciones. Los atributos corresponden a lo que otros lenguajes denominan variables o campos de instancia . Las llamadas a métodos se conocían como solicitudes y el acto de ejecutar la implementación de un método se conocía como realizarlo . Todas esas llamadas siempre respondían con un mensaje que indicaba el éxito o el fracaso, dependía del objeto solicitante capturarlas opcionalmente y responderlas . Las sugerencias sobre cómo pasar los datos dentro y fuera de las llamadas a métodos se conocían como restricciones y cubrían el común " por ref " y " por valor ", entre otros. [9]
Telescript era generalmente apátrida en términos de vida útil de los datos. Todos los datos dentro del programa, tanto de instancia como de variables locales, siempre fueron serializados. Los agentes pueden ser invocados o suspendidos en cualquier momento y no perderían su estado. Este mismo mecanismo también permitió que los agentes se comunicaran fácilmente entre hosts.
Sintaxis y diseño
Aunque el control y el diseño de Telescript se inspiraron en C, su sintaxis precisa era considerablemente diferente. Una diferencia obvia fue el reemplazo de llaves de estilo C con paréntesis en el nivel de definición, reteniendo llaves para agrupar declaraciones dentro de la lógica y las declaraciones de control de flujo , y el uso de dos puntos para separar un nombre de su definición. El siguiente código define la interfaz para objetos del tipo Pie : [10] [N 1]
Pie: interfaz (Objeto) = ( público nombre: String; initialize: op (nombre: String); );
Tenga en cuenta el uso de la palabra clave op
, que corresponde a function
o que se sub
encuentra en otros idiomas. La implementación de Pie podría usarse en uno o más class
objetos, que se pueden organizar en modules
s de una manera similar a la construcción de Visual Basic .NETnamespace
. #include
se utiliza para importar archivos de encabezado, pero la importación es local modules
, no el archivo en su totalidad. [11]
Los conceptos de agente y lugares de Telescript se invocaron simplemente subclasificando esas dos clases, Agente y Lugar, las cuales eran subclases de Proceso. Para mayor claridad del código, se pueden colocar ambos en un solo archivo e incluso reunirlos en un solo módulo. El siguiente código define los agentes necesarios para implementar una tienda que vende pasteles: [12]
PieStoreModule: módulo = ( #include "pie.i" PieBuyer: class (Agente) = ( público en vivo: op patrocinado () = { * .go (*. destino); myPie = [email protected] (); * .go (*. originPlace); }; ); PieSeller: class (Lugar) = ( público sellPie: op () Pie = { aPie: Pie | Nulo; aPie = * .getPieFromStock; if (aPie = nil) { PieBuyer (*. DistributorTicket, Permiso (nulo)); aPie = * .waitForPie (); return aPie; }; }; ); );
El objeto PieBuyer, un agente, contiene un único método live
, el método de inicio estándar utilizado por todos los agentes. [13] Simplemente crear un PieBuyer e invocarlo hará live
que se llame al método, de una manera similar a la new
operación que se encuentra en la mayoría de los lenguajes OO, aunque este método se llama después de la configuración. El * reemplaza lo que se implementa más comúnmente como self
o Me
, refiriéndose al objeto en sí, en este caso el agente PieBuyer. El código básicamente dice que cuando se crea, el objeto debe enviarse a sí mismo (* .go) a la ubicación que se le envió durante la creación (* .destination). Una vez allí, debería indicarle al objeto de lugar correspondiente, en este caso un PieSeller, que sellPie. Cuando se complete ese comando, el agente regresará a su lugar de origen. La aplicación que invoca puede examinar los resultados inspeccionando la variable myPie. [12]
El objeto PieSeller, un lugar, contiene también un método único, sellPie
. Define una variable local llamada aPie, definiéndola como un objeto Pie, o "nada", que se utiliza en el caso de que no haya pasteles. Luego intenta establecer aPie en un valor llamando a su propio método getPieFromStock (no se muestra aquí) y luego verifica si eso devolvió un valor. Si no tuvo éxito, por ejemplo, si el stock estaba vacío, luego construye un nuevo objeto PieBuyer propio, envía esa solicitud a otra tienda y luego espera una respuesta. Esa tienda podría reenviar la solicitud a otra, y así sucesivamente. Cuando esta cadena de eventos concluye, ya sea con un pastel o sin éxito, el lugar de PieSeller finalmente lo devuelve al PieBuyer que llama. [12]
Los objetos son normalmente "propiedad" del lugar que los creó. La propiedad también confiere capacidades y configuraciones de seguridad. El lenguaje puede tomar posesión de un objeto a través de la own {}
construcción o, en este caso, usar la sponsored
palabra clave para indicar que debe ejecutarse dentro de la propiedad del lugar en el que se está ejecutando. Esto podría usarse, por ejemplo, para otorgar al agente la capacidad para ver las existencias en el inventario, valores que de otro modo serían privados. Usar sponsored
es exactamente el mismo resultado que colocar el código en un own {}
bloque, pero permite que esto suceda en la persona que llama. [14]
Telescript incluye varios tipos integrados de recogida, Set
, List
, Dictionary
, y Collection
, el último de los cuales es esencialmente una lista con los índices de texto (la mitad de un diccionario). Una fuente común de errores en Telescript era que, si bien una colección en su conjunto podía devolverse a un agente, los elementos individuales dentro de ella eran propiedad del lugar. Por lo tanto, si se usara return MyCollection[someIndex];
, volvería al dispositivo del usuario como nulo. La solución fue la sintaxis adicional, las sugerencias DictOwned
y ColOwned
, lo que provocó que la propiedad de los valores devueltos se cambiara al regresar y, por lo tanto, se serializara en los resultados al regresar al lugar original. [15]
Las subclases se conocían como sabores ; la clase PieBuyer descrita anteriormente es un sabor de Agent. Telescript también incluyó el concepto de clases mixtas, que ofrecían características similares a la herencia múltiple al permitir la creación de clases que solo contenían código que luego podría incluirse en otras clases. Las mezclas no eran sabores. [dieciséis]
Como muchos lenguajes OO modernos, Telescript separó la interfaz y la implementación, colocándolas en .i
archivos para la interfaz y .t
archivos para la implementación (t como en "t" elescript). De manera poco común, el lenguaje también definió un tercer tipo de archivo .d
, que combinaba varios .i
archivos juntos. [17] El código compilado se colocó en un .s
archivo, que fue guiado por las instrucciones del enlazador en un .l
archivo. [18] El marco de aplicación externo permitió que Telescript llamara al código C ++ . [19]
Notas
- ^ Estos ejemplos se modifican de los originales que se encuentran en la Guía, corrigiendo una serie de errores de sintaxis y ortografía.
Referencias
Citas
- ^ a b c Levy 1994 .
- ^ a b Clark y Knaster, 1995 .
- ^ a b c Kanellos, 2011 .
- ^ Dan Hanttula, "Magic Mirror" , Pen Computing , abril de 2000
- ^ Mark Beaulieu, "Arquitectura y aplicaciones de Internet inalámbrica" , Addison-Wesley Professional, 2002, 9780201733549, p. 12.
- ^ Referencia 1995 , p. 1.
- ^ Referencia 1995 , págs. 1-2.
- ^ Referencia 1995 , p. 2.
- ^ Referencia 1995 , págs. 8-12.
- ^ Guía de 1995 , p. 7.
- ^ Guía de 1995 , p. 8.
- ^ a b c Guía 1995 , p. 9.
- ^ Guía de 1995 , p. 66.
- ^ Guía de 1995 , p. 40.
- ^ Guía de 1995 , p. 42.
- ^ Referencia 1995 , p. 20.
- ^ Guía de 1995 , p. 3.
- ^ Guía de 1995 , p. 4.
- ^ Guía de 1995 , p. 5.
Bibliografía
- Levy, Steven (abril de 1994). "La excelente aventura de Bill y Andy II" . Cableado .
- Clark, Richard; Knaster, Scott; et al. (Mayo de 1995). "Introducción de un desarrollador a General Magic y Magic Cap" . MacTech .
- Kanellos, Michael (18 de septiembre de 2011). "Magia general: ¿La empresa muerta más importante de Silicon Valley?" . Forbes .
- Referencia del lenguaje Telescript (PDF) . Magia general. Octubre de 1995.
- Guía de programación de Telescript . Magia general. 1995.