Teleskrypt (język programowania)

Telescript to język programowania zorientowany na agenty, napisany przez General Magic jako część ogólnego systemu Magic Cap . Programy teleskryptowe wykorzystywały zmodyfikowaną składnię podobną do C, znaną jako High Telescript i zostały skompilowane do języka opartego na stosie o nazwie Low Telescript w celu wykonania. Low Telescript działał w maszyn wirtualnych lub „silnikach Telescript” na komputerach hostach.

Podstawowy model Telescript jest podobny do Javy i różni się przede wszystkim miejscem uruchamiania aplikacji. Java została zamodelowana tak, aby umożliwić pobieranie aplikacji Java na dowolną platformę i uruchamianie ich lokalnie. Telescript zasadniczo odwrócił to, umożliwiając sprzętowi użytkownika końcowego o ograniczonych możliwościach przesyłanie programów Telescript na serwery, aby umożliwić im skorzystanie z możliwości serwera. Telescript może nawet migrować uruchomiony program; język zawierał funkcje porządkowania kodu programu i serializacji stanu, przenieś go do innego silnika Telescript (na urządzeniu lub serwerze), aby kontynuować wykonywanie, a na koniec wróć do pierwotnego urządzenia klienta lub serwera, aby dostarczyć dane wyjściowe.

Firma General Magic pierwotnie rozwijała się jako zespół w ramach Apple Inc. i została wyodrębniona w 1990 r. Kiedy w 1992 r. zaczęła generować szum prasowy, firma Apple zdecydowała się wejść na ten sam rynek ze swoim tabletem Newton . General Magic nie był w stanie znaleźć niszy na rynku, a usługi Telescript zostały wkrótce wycofane na rzecz nowych produktów niezwiązanych z komputerami mobilnymi .

Historia

W 1990 roku Marc Porat przekonał ówczesnego dyrektora generalnego Apple, Johna Sculleya , że ​​przyszłość informatyki leży nie w stacjonarnych komputerach osobistych , ale w znacznie mniejszych urządzeniach przenośnych, łączących moc obliczeniową, systemy komunikacyjne i dane ulokowane na serwerach dostępnych w sieci. Zauważył, że komputery przenośne zawsze będą miały mniejszą moc niż maszyny, do których byłyby podłączone, i zasugerował, aby było to częścią projektu - zamiast próbować zbudować komputer przenośny, który mógłby wykonywać zadania systemu stacjonarnego, urządzenie przenośne powinno niewidocznie wykorzystują moc obliczeniową serwerów, aby uzyskać podobny wynik.

Sculley zgodził się pozwolić Poratowi rozpocząć badanie koncepcji pod kryptonimem „Pocket Crystal”. Kluczowymi członkami wczesnego zespołu byli Porat oraz znani programiści komputerów Macintosh, Bill Atkinson i Andy Hertzfeld . Zespół szybko został zignorowany przez kierownictwo wyższego szczebla i odszedł, nieustannie walcząc o zasoby. Ponownie zwrócili się do Sculleya z pomysłem wydzielenia Pocket Crystal jako oddzielnej firmy. Sculley zgodził się na to, podobnie jak pomysł zaproszenia nowych partnerów po stronie sprzętu. Nowa firma, General Magic (GM), została utworzona w maju 1990 roku wraz z Apple, Sony i Motorola, każdy posiadający 10% udziałów. Rangi firmy wkrótce zapełniły się innymi absolwentami komputerów Macintosh, takimi jak Joanna Hoffman , Susan Kare , Dan Winkler, Bruce Leak i Phil Goldman .

Do 1992 roku GM podpisał umowy rozwojowe z wieloma firmami, które współpracowały ze środowiskiem Magic Cap, w tym Sony, Motorola, Matsushita , Philips , British Telecom i AT&T Corporation . Wywołało to spory „szum” w prasie. W tym czasie Apple rozpoczął projekt Newton , projekt większego podręcznego komputera przypominającego tablet, bardziej podobnego do pełnowymiarowego iPada . Po sukcesie General Magic w prasie, ponownie umieścili Newtona na tym samym rynku i przyspieszyli jego wypuszczenie w 1993 roku. Sprzedali również swoje udziały w General Magic i pozwali ich. Partnerzy General Magic wypuścili sprzęt dopiero w 1994 roku, kiedy to Newton zasadniczo zdefiniował, czym osobisty asystent cyfrowy (PDA), a systemy PDA były oceniane na podstawie ich możliwości rozpoznawania pisma ręcznego . Magic Cap był interfejsem typu „wskaż i kliknij” (podobnie jak HyperCard czy współczesny iOS ).

W 1995 roku firma była już tylko skorupą dawnego siebie i większość pierwotnych programistów odeszła. W 1996 roku Steve Markman został zatrudniony do przejęcia, a Kevin Surace poprowadził firmę w nowym kierunku. Nowy zespół opracował telefoniczny system asystenta osobistego Portico, który do dziś jest podstawą systemu OnStar . Oryginalna grupa urządzeń przenośnych została wydzielona w 1998 roku jako DataRover Mobile Systems Incorporated, a później przemianowana na Icras w 2000 roku, obsługując szereg rynków pionowych przed zamknięciem w 2001 roku. Pozostałości pierwotnej firmy zostały zlikwidowane w 2004 roku.

Opis

Podstawowe koncepcje

Telescript był wzorowany na koncepcji małych programów zwanych agentami , które wchodziłyby w interakcję z usługami komputerowymi znanymi jako miejsca , z których wszystkie działałyby na klastrze jednego lub więcej serwerów obsługujących tak zwaną chmurę Telescript. Urządzenie przenośne użytkownika było jednym z takich miejsc, aczkolwiek o ograniczonych możliwościach. W modelu założono, że większość informacji i usług będzie dostarczana przez miejsca działające na większych serwerach hostowanych przez dostawców usług komunikacyjnych, takich jak AT&T. Nawet wczesne dokumenty określają to jako działanie w chmurze . Programy skierowane do użytkownika składałyby się z wielu takich agentów, które mogłyby działać lokalnie, na hostach dostawcy lub nawet być przekazywane na serwery stron trzecich. Aby koordynować komunikację, Telescript zawierał również koncepcje nazwy telefonicznej , która jednoznacznie identyfikowała użytkowników, oraz teleadresów , które identyfikowały urządzenie nawet podczas przemieszczania się między sieciami.

Rozważmy na przykład aplikację zakupową, w której użytkownik prosi o znalezienie cen nowego grilla, który chce kupić. W tradycyjnym modelu klient-serwer aplikacja tworzyłaby szereg zapytań, wysyłała je do wielu usług, a następnie zbierała wyniki i wyświetlała je. W modelu Telescript aplikacja zamiast tego tworzyłaby nowego agenta wypełnionego danymi z żądania, stemplowała go nazwą i adresem, a następnie wysyłała go do miejsca przechowywania na serwerze w celu przetworzenia. Ten serwer mógłby następnie obsłużyć żądanie bezpośrednio lub przekazać agenta do innych miejsc, takich jak miejsca rzeczywistych dostawców, w celu dalszego przetwarzania. Wyniki mogą być umieszczane w wewnętrznych polach danych agenta i przesyłane z powrotem przez sieć do urządzenia użytkownika lub może zostać uruchomiony nowy agent „komunikator”, aby przenosić tylko dane wynikowe i odsyłany z powrotem, aby zminimalizować transfer danych w sieci.

Model różni się również od tradycyjnych rozwiązań sposobem wymiany danych w przypadku współpracujących ze sobą programów. Na przykład, jeśli użytkownik zdecyduje się kupić jeden z grilli, które znalazł podczas poprzedniego wyszukiwania, w konwencjonalnym systemie zadanie polegające na wypełnieniu formularzy zamówienia i potwierdzeniu płatności byłoby realizowane poprzez bezpośrednią komunikację między urządzeniem użytkownika a zdalnym serwerem, wymaga kanału komunikacji „na żywo” w trakcie całego procesu. W modelu Telescript nowy agent z informacjami potrzebnymi do sfinalizowania zakupu jest wysyłany do sklepu tego sprzedawcy, wchodzi w interakcję ze sklepem lub agentami sprzedawcy, a następnie wraca z sukcesem lub porażką. Główna komunikacja odbywa się między agentami i miejscami na zdalnym serwerze, więc komunikacja przez sieć jest wymagana tylko na początku i na końcu procesu.

Telescript był zorientowany obiektowo (OO) i używał wielu nietypowych terminów do opisania stanu obiektu i komunikacji. Atrybuty odpowiadają temu, co inne języki nazywają zmiennymi instancji lub polami. Wywołania metod były znane jako żądania , a czynność uruchomienia implementacji metody była znana jako jej wykonanie . Wszystkie takie wywołania zawsze odpowiadały komunikatem wskazującym na powodzenie lub niepowodzenie, do obiektu żądającego należało opcjonalnie uwięzić je i odpowiedzieć na nie . Wskazówki dotyczące przekazywania danych do i z wywołań metod były znane jako ograniczenia i obejmowały między innymi wspólne „ przez ref ” i „ przez wartość ”.

Telescript był ogólnie bezstanowy pod względem czasu życia danych. Wszystkie dane w programie, zarówno instancyjne, jak i zmienne lokalne, były zawsze serializowane. Agentów można było wezwać lub zawiesić w dowolnym momencie i nie straciliby swojego stanu. Ten sam mechanizm umożliwiał również łatwą komunikację agentów między hostami.

Składnia i układ

Chociaż sterowanie i układ Telescript był inspirowany C, jego dokładna składnia była znacznie inna. Jedną oczywistą różnicą było zastąpienie nawiasów klamrowych w stylu C nawiasami na poziomie definicji, zachowanie nawiasów klamrowych do grupowania instrukcji w logice i sterowania przepływem oraz użycie dwukropka do oddzielenia nazwy od jej definicji. Poniższy kod definiuje interfejs dla obiektów typu Pie :

Koło: interfejs(Obiekt) = (nazwa publiczna: Ciąg; zainicjuj: op(nazwa: Ciąg););

Zwróć uwagę na użycie słowa kluczowego op , które odpowiada funkcji lub podrzędnej funkcji występującej w innych językach. Implementacja Pie może być użyta w jednym lub kilku klasy , które można zorganizować w moduły w sposób podobny do konstrukcji przestrzeni nazw w Visual Basic .NET . #include służy do importowania plików nagłówkowych, ale import jest lokalny dla modułów , a nie dla całego pliku.

Koncepcje agenta i miejsc Telescript zostały wywołane po prostu przez podklasę tych dwóch klas, Agenta i Miejsca, z których obie były podklasami Procesu. Dla przejrzystości kodu można umieścić oba w jednym pliku, a nawet zebrać je w jednym module. Poniższy kod definiuje agentów potrzebnych do wdrożenia sklepu, który sprzedaje Pies:

PieStoreModule: module = ( #include "pie.i" PieBuyer: class(Agent) = ( public live: sponsorowana op() = { *.go(*.destination); myPie = [email protected](); *. go(*.originPlace); }; ); PieSeller: class(Miejsce) = (public sellPie: op() Pie = { aPie: Pie | Zero; aPie = *.getPieFromStock; if (aCiasto = zero) { PieBuyer(* .distributorTicket, Permit(zero)); aPie = *.waitForPie(); return aPie; }; }; ); );

Obiekt PieBuyer, agent, zawiera pojedynczą metodę live , standardową metodę uruchamiania używaną przez wszystkich agentów. Po prostu utworzenie PieBuyer i wywołanie go spowoduje wywołanie metody live , w sposób podobny do nowej operacji występującej w większości języków obiektowych, chociaż ta metoda jest wywoływana po instalacji. Znak * zastępuje to, co jest częściej implementowane jako self lub Me , odnosząc się do samego obiektu, w tym przypadku agenta PieBuyer. Kod zasadniczo mówi, że po utworzeniu obiekt powinien wysłać się (*.go) do lokalizacji przesłanej do niego podczas tworzenia (*.destination). Po dotarciu na miejsce powinien powiedzieć pasującemu obiektowi miejsca, w tym przypadku PieSellerowi, aby sprzedałPie. Po wykonaniu tego polecenia agent powróci do miejsca pochodzenia. Aplikacja wywołująca może następnie sprawdzić wyniki, sprawdzając zmienną myPie.

Obiekt PieSeller, Place, zawiera również pojedynczą metodę sellPie . Definiuje zmienną lokalną o nazwie aPie, definiując ją jako obiekt Pie lub „nic”, który jest używany w przypadku, gdy nie ma ciast. Następnie próbuje ustawić aPie na wartość, wywołując własną metodę getPieFromStock (nie pokazaną tutaj), a następnie sprawdza, czy zwróciła wartość. Jeśli nie powiodło się, na przykład, jeśli zapasy były puste, buduje własny nowy obiekt PieBuyer, wysyła to żądanie do innego sklepu, a następnie czeka na odpowiedź. Ten sklep może przekazać prośbę do innego i tak dalej. Kiedy ten łańcuch wydarzeń kończy się ciastem lub bezskutecznie, miejsce PieSeller w końcu zwraca to dzwoniącemu PieBuyerowi.

Obiekty są zwykle „własnością” miejsca, które je stworzyło. Własność nadaje również możliwości i ustawienia zabezpieczeń. Język może przejąć własność obiektu poprzez własną konstrukcję {} lub w tym przypadku użyć sponsorowanego słowa kluczowego, aby wskazać, że powinien działać w ramach własności miejsca, w którym działa. Można to wykorzystać na przykład do przyznania agentowi możliwość zobaczenia zapasów w inwentarzu, wartości, które w innym przypadku byłyby prywatne. Użycie sponsorowanych daje dokładnie taki sam rezultat, jak umieszczenie kodu we własnym bloku {} , ale pozwala na to w wywołującym.

Telescript zawiera kilka wbudowanych typów kolekcji, Set , List , Dictionary i Collection , z których ostatnia to zasadniczo lista z indeksami tekstowymi (połowa słownika). Jednym z powszechnych źródeł błędów w Telescript było to, że chociaż kolekcja jako całość mogła zostać przekazana agentowi, poszczególne elementy w jej obrębie były własnością miejsca. Tak więc, jeśli ktoś użył return MyCollection[someIndex]; , wróci na urządzenie użytkownika jako null. Rozwiązaniem była dodatkowa składnia, DictOwned i ColOwned podpowiedzi, które spowodowały zmianę własności zwróconych wartości po powrocie, a tym samym serializację wyników po powrocie do pierwotnego miejsca.

Podklasy były znane jako smaki ; opisana powyżej klasa PieBuyer jest odmianą agenta. Telescript zawierał również koncepcję klas mieszanych, które oferowały funkcje podobne do wielokrotnego dziedziczenia , umożliwiając tworzenie klas zawierających tylko kod, który można następnie włączyć do innych klas. Mieszanki nie były smakami.

Podobnie jak wiele współczesnych języków OO, Telescript oddzielił interfejs i implementację, umieszczając je w plikach .i dla interfejsu i plikach .t dla implementacji (t jak w „t” elescript). Niezbyt często język definiował również trzeci typ pliku, .d , który łączył ze sobą wiele plików .i . Skompilowany kod został umieszczony w .s , który był kierowany instrukcjami linkera w pliku .l . Zewnętrzna struktura aplikacji dopuszczała język C++ kod do wywołania przez Telescript.

Notatki

Cytaty

Bibliografia

  • Levy, Steven (kwiecień 1994). „Wspaniała przygoda Billa i Andy'ego II” . Przewodowy .
  • Clark, Richard; Knaster, Scott; i in. (maj 1995). „Wprowadzenie programisty do General Magic i Magic Cap” . MacTech .
  • Kanellos, Michael (18 września 2011). „General Magic: Najważniejsza martwa firma w Dolinie Krzemowej?” . Forbesa .
  • Odniesienie do języka telescript (PDF) . Magia ogólna. październik 1995.
  • Przewodnik programowania Teleskryptu . Magia ogólna. 1995.