W przemyśle, w którym można w kilka lat przejść od postaci legendarnej do bankruta, kariera Steve'a Jobsa jest raczej typowa. Spektakularny sukces z Macintoshem i spektakularna klapa ze zbyt drogim pudłem Next. Obecnie Jobs postawił sobie za cel wprowadzić rewolucję obiektową w swym projekcie NextStep.

Ze Stane'm Jobsem rozmawiała Maryfran Johnson, dziennikarka Computerworld. Rozmowę zamieszczamy z nieznacznymi skrótami za Computerworld Client/Server Journal (USA).

Czy Microsoft jest rzeczywiście takim strasznym konkurentem?

Jestem przekonany, że nie mają jeszcze zielonego światła na swoim kierunku obiektowym. Dokumenty nazywają obiektami, ale dokumenty to dokumenty. Object Linking and Embedding (OLE) nie jest modelem obiektowym. Jest to architektura złożonych dokumentów i na dodatek niezbyt udana, gdyż w efekcie to programista musi wszystko zrealizować. Jest to więc głównie specyfikacja.

Jak zamierzasz zabezpieczyć i utrwalić swój sukces wobec innych środowisk obiektowych, takich jak Cairo (Microsoft) czy Taligent (Apple)?

Przodujemy, ponieważ techniką obiektową zajęliśmy się prawie 5 lat wcześniej niż inne firmy. Mamy już trzecią wersję NextStep 3.2. Jak wiadomo wersja 1.0 każdego produktu jest niewiele warta.

Nasza strategia jest bardzo prosta: koncentrujemy się wyłącznie na rynku korporacyjnym. Zajmujemy się jego czterema sektorami: usługami finansowymi, telekomunikacją, usługami zdrowotnymi i agencjami rządowymi.

Sądzimy, że w wyścigu w zakresie techniki obiektowej liczyć się tylko będą: Microsoft, NextStep OpenStep i Taligent.

Co z Taligentem?

Taligent boryka się z kilkoma problemami. Po pierwsze, próbowali zrobić wszystko własnymi siłami - zarówno grafikę, jak i system operacyjny. My podeszliśmy do problemu zupełnie inaczej. Wyszliśmy poza naszą firmę i wykorzystujemy pracę innych. Naszą wiedzę i talent użyliśmy do stworzenia tego, co naprawdę się liczy - obiektów z którymi ma do czynienia programista.

Taligent włożył wiele wysiłku w opracowanie obiektóww z wnętrza systemu operacyjnego, których programista nigdy nie zobaczy. Komu na tym zależy?

Nikomu.

Jak twórcy programów klient/serwer powinni postrzegać Next?

Klienci, z którymi rozmawiamy nie chcą pozbywać się swoich mainframe'ów ponieważ mają na nich wiele aplikacji. Nie zamierzają przepisywać aplikacji do środowiska klient/serwer. Natomiast wszystkie nowe aplikacje będą już typu klient/serwer.

Na rynku istnieje bardzo dużo narzędzi do tworzenia aplikacji klient/serwer...

Technologia klient/serwer spowodowała znaczące obniżenie stosunku ceny do wydajności sprzętu, ale rewolucja [klient/serwer] straciła już swój rozpęd. Można przejść z mainframe'a na system klient/serwer i w ten sposób zaoszczędzić ogromne pieniądze. Nie osiągnie się jednak dzięki temu skrócenia czasu opracowania aplikacji.

Tak więc kolejną poszukiwaną rzeczą są proste narzędzia, takie jak PowerBuilder (PowerSoft) czy Visual Basic (Microsoft). Jądrem problemu jest to, że narzędzia tego typu plują ogniem i parzą. Gdy potrzebujesz zrobić coś naprawdę poważnego, musisz korzystać z ich ograniczonych języków. Alternatywą jest powrót do C umożliwiającego napisanie naprawdę porządnego kawałka kodu.

Czy problem nie zostanie rozwiązany jeżeli narzędzia te staną się dostępne na poziomie serwera?

Niezupełnie. W świecie klient/serwer większa część aplikacji powinna działać na komputerze klienta. Ostatnia rzecz, którą powinno się robić, to pisanie aplikacji na serwer. Wtedy wracamy przecież do modelu mainframe'a.

Co wobec tego sądzisz na temat syndromu "grubego klienta", to jest umieszczania całego kodu na maszynie klienta?

Maszyny klienta są coraz szybsze. Zator w aplikacjach klient/serwer powstaje w wyniku kłopotów z wykonywaniem aplikacji na maszynie klienta. My korzystamy z bardzo bogatej, obiektowej technologii pozwalającej, za pomocą NextStep, na budowanie aplikacji 10 razy szybciej niż przy użyciu czegoś innego.

Wierzymy, że rewolucja obiektowa, połączona z rewolucją w sprzęcie klienta i serwera, pozwoli by przetwarzanie klient/serwer pojawiło się jeszcze w tym wieku.

Niektórzy analitycy uważają, że macie kłopoty z określeniem pozycji systemu operacyjnego NextStep na rynku. Czy nie powinniście zająć się raczej narzędziami i obiektami, zamiast zajmować się podłożem?

Sądzimy, że Intel będzie, w naszym wypadku, najbardziej popularną platformą. Mam nadzieję że sprzedamy w tym roku ok. 300 tys. kopii systemu a w przyszłym roku ok. 500 tys.

Ma to dla nas zasadnicze znaczenie, gdyż dysponujemy tym samym systemem operacyjnym na wszystkich platformach. Jeżeli przenieślibyśmy [nasze obiekty] na 300 różnych wersji systemów operacyjnych, mielibyśmy koszmarne kłopoty z ich utrzymaniem i zgodnością.

Przenosicie jednak NextStep na system operacyjny Solaris SUN-a. Jaka to różnica?

SUN pokłada dużą nadzieję w NextStep. Dokonali wyboru jednej firmy, jednej technologii, jednej platformy i decyzji co do obiektów. Wybrali właśnie OpenStep.

Równocześnie jednak SUN nie zamierza zrezygnować ze swych planów obiektowych Distributed Objects Everywhere (DOE). W jaki sposób zostanie to zintegrowane?

DOE to warstwa podstawowa, infrastruktura. Sun ma własną i chce ją zatrzymać. OpenStep to specyfikacja, kawałek papieru. Jest to niezależna od systemu operacyjnego warstwa systemu NextStep 3.2, jakieś 95% tego systemu. SUN kupuje licencję na OpenStep i zamierza zrealizować go na Solaris.

Specyfikacja OpenStep jest już gotowa. Współpracujemy z firmą X/Open w celu udostępniania tej specyfikacji i licencjonowania jej za darmo.

Dlaczego tak późno przyjęliście koncepcję otwartości? Czy nie należało tego zrobić dwa lata temu?

Szkoda że nie porozumieliśmy się wtedy z SUN-em.

Wtedy, gdy szef SUN-a Scott McNeally mówił, że raczej wbije sobie szpilkę w oko niż będzie pracował z Next?

Oczywiście. Gdy tylko pozbyliśmy się naszego oddziału sprzętowego, doszliśmy do wniosku, że więcej nas łączy niż dzieli. Nasze kultury inżynierskie są prawie identyczne.

Jak NextStep/OpenStep ma się do Portable Distributed Objects (PDO)?

Są to całkowicie różne rzeczy. NextStep ma obiekty, które rozmawiają z innymi obiektami lub przesyłają komunikaty między sobą. W każdym innym systemie obiektowym (oprócz naszego), obiekty przesyłające sobie komunikaty muszą znajdować się w tej samej przestrzeni adresowej. Nie można wziąć obiektu z jednego programu i wysłać komunikatu do obiektu w innym programie.

Mniej więcej 2 lata temu przełamaliśmy tę barierę. To właśnie nasze obiekty są rozproszone. Oznacza to, że obiekt NextStep z programu na jednej maszynie może wysłać komunikat do obiektu NextStep w innym programie na tej samej maszynie lub poprzez sieć do programu na zupełnie innej maszynie Next.

Gdy rozpoczęliśmy wsółpracę z HP i ich procesorem PA-RISC, HP chciał używać niektórych obiektów NextStep na swych serwerach. Wycięliśmy więc cały model obiektowy i infrastrukturę przekazywania komunikatów z NextStep i uruchomiliśmy jako standardowy proces unixowy. Można je więc mieć na serwerach. I to jest właśnie PDO.

Obecnie PDO jest dostępne jedynie dla HP/UX, ale planujemy dostarczać je dla SunOS i Solaris oraz, w porozumieniu z Digitalem, na OSF/1 i Alpha.

NextStep jest napisany w Objective C. Microsoft i reszta świata zdążają w stronę C++. Czy nie sądzisz, że dokonaliście złego wyboru?

Nie. Tylko my mamy to, co jest niepowtarzalną cechą Smalltalk. Określiłbym to mianem Żywych Obiektów. Język C++ ma Martwe Obiekty, ponieważ cała konwersacja między obiektami zostaje zamrożona w chwili kompilacji programu.

W dobrze opracowanym programie podejmowanie decyzji następuje w czasie pracy programu. Przy użyciu Żywych Obiektów zmieniam obiekt raz, a on migruje do wszystkich aplikacji i zamienia istniejące tam obiekty.

Jaka jest aktualna sytuacja finansowa firmy?

Rok 1993 zakończyliśmy obrotem rzędu 11 mln USD. Sądzimy, że w 1994 r. uda się nam osiągnąć obrót wysokości 50 mln USD i sprzedać 100 tys. kopii NextStep. (Wywiad był przeprowadzony w 1994 r. - przyp. tłum.)

Czego nauczył Cię upadek sprzętowej części firmy?

No cóż, nie da się ludziom zaproponować firmowego rozwiązania sprzętowego za 8 tys. USD. Ale mamy satysfakcję, że znajdują się chętni do podjęcia ryzyka zakupienia kawałka oprogramowania za 800 USD.