Data: Środa, 23 lipca 2003 09:33:31 -0800 Do: Stefan Ram [usunięty ze względu na prywatność] Od: Alan Kay [usunięty ze względu na prywatność] Temat: Re: Wyjaśnienie „obiektowego”
Cześć Stefan -
Przepraszam za opóźnienie, ale byłem na wakacjach.
O 18:27 +0200 7/17/03 Stefan Ram napisał:
Drogi Dr. Kay,
Chciałbym uzyskać wiarygodne słowo na temat „programowania obiektowego” na mojej stronie z samouczkiem na ten temat. Jedynymi dwoma źródłami, które uważam za „autorytatywne”, są Międzynarodowa Organizacja Normalizacyjna, która definiuje „zorientowany obiektowo” w „ISO / IEC 2382-15” oraz Ty, ponieważ, jak to mówią, ukułeś ten termin.
Jestem pewien, że tak.
Niestety trudno jest znaleźć stronę internetową lub źródło z definicją lub opisem tego terminu. Istnieje kilka raportów na temat tego, co mogłeś powiedzieć w tym względzie (np. „Dziedziczenie, polimorfizm i enkapsulacja”), ale nie są to źródła z pierwszej ręki. Wiem również, że później kładziecie większy nacisk na „przesyłanie wiadomości” - ale nadal chciałbym wiedzieć o „obiektowym”.
Jeśli chodzi o zapisy, moją stronę z samouczkami oraz dalszą dystrybucję i publikację, proszę wyjaśnić:
Kiedy i gdzie najpierw użyto terminu „obiektowy”?
W Utah, jakiś czas po 66 listopada, kiedy pod wpływem Sketchpada, Simuli, projektu ARPAnet, Burroughs B5000 i mojego doświadczenia w biologii i matematyce, pomyślałem o architekturze programowania. Prawdopodobnie w 1967 roku ktoś zapytał mnie, co robię, a ja powiedziałem: „Programowanie obiektowe”.
Jego pierwotna koncepcja składała się z następujących części.
Pomyślałem o obiektach będących komórkami biologicznymi i / lub pojedynczymi komputerami w sieci, które mogą komunikować się tylko z wiadomościami (więc wysyłanie wiadomości pojawiło się na samym początku - zajęło trochę czasu, aby zobaczyć, jak robić wiadomości w języku programowania wystarczająco wydajnym, aby być użytecznym).
Chciałem pozbyć się danych. B5000 prawie to zrobił dzięki prawie niewiarygodnej architekturze sprzętu. Uświadomiłem sobie, że metafora komórka / cały komputer pozbyłaby się danych, a „<-” byłoby tylko kolejnym tokenem wiadomości (zajęło mi to sporo czasu, aby to przemyśleć, ponieważ tak naprawdę myślałem o tych wszystkich symbolach jako nazwach funkcje i procedury.
Moje pochodzenie matematyczne uświadomiło mi, że z każdym obiektem może być powiązanych kilka algebr, a mogą istnieć ich rodziny i że będą one bardzo, bardzo przydatne. Termin „polimorfizm” został narzucony znacznie później (myślę, że Peter Wegner) i nie jest całkiem poprawny, ponieważ tak naprawdę pochodzi z nomenklatury funkcji, a ja chciałem czegoś więcej niż funkcji. Stworzyłem termin „ogólność” do radzenia sobie z rodzajowymi zachowaniami w formie quasi-algebraicznej.
Nie podobało mi się to, że Simula I lub Simula 67 dziedziczyły (chociaż myślałem, że Nygaard i Dahl byli po prostu wspaniałymi myślicielami i projektantami). Postanowiłem więc pominąć dziedziczenie jako funkcję wbudowaną, dopóki nie zrozumiałem go lepiej.
Moje oryginalne eksperymenty z tą architekturą zostały wykonane przy użyciu modelu, który zaadaptowałem z „Generalizacji Algolu” van Wijngaarten i Wirtha oraz Eulera Wirtha. Oba były raczej podobne do LISP, ale miały bardziej konwencjonalną czytelną składnię. Nie rozumiałem wtedy potwornego pomysłu LISP na namacalny metaljęzyk, ale zbliżyłem się do pomysłów na temat języków rozszerzalnych czerpanych z różnych źródeł, w tym IMP Ironsa.
Drugim etapem tego było zrozumienie LISP, a następnie wykorzystanie tego zrozumienia do stworzenia znacznie ładniejszych i mniejszych oraz mocniejszych i opóźnionych konstrukcji podziemnych. Teza Dave'a Fishera została wykonana w stylu „McCarthy'ego”, a jego pomysły dotyczące rozszerzalnych struktur kontrolnych były bardzo pomocne. Innym dużym wpływem w tym czasie był PLANER Carla Hewitta (który nigdy nie zyskał uznania, na jakie zasługuje, biorąc pod uwagę, jak dobrze i jak wcześniej mógł przewidzieć Prolog).
Oryginalny Smalltalk w Xerox PARC wyszedł z powyższego. Na kolejnych Smalltalk narzekano pod koniec rozdziału Historia: cofnęli się w kierunku Simuli i nie zastąpili mechanizmów rozszerzenia bezpieczniejszymi, które były prawie tak przydatne.
Co oznacza dla Ciebie „programowanie obiektowe”? (Nie jest potrzebne wprowadzenie przypominające samouczek, wystarczy krótkie wyjaśnienie [jak „programowanie z dziedziczeniem, polimorfizmem i enkapsulacją”] w kategoriach innych pojęć dla czytelnika znającego je, jeśli to możliwe. Ponadto nie jest konieczne wyjaśnianie „obiektu ”, ponieważ mam już źródła z wyjaśnieniem„ obiektu ”z„ Early History of Smalltalk ”).
(Nie jestem przeciw typom, ale nie znam żadnych systemów typów, które nie są kompletnym bólem, więc nadal lubię dynamiczne pisanie.)
OOP oznacza dla mnie tylko wysyłanie wiadomości, lokalne przechowywanie, ochronę i ukrywanie procesów państwowych oraz ekstremalne późne wiązanie wszystkich rzeczy. Można to zrobić w Smalltalk i LISP. Możliwe są inne systemy, w których jest to możliwe, ale nie jestem ich świadomy.
[Także] Jedną z rzeczy, o których powinienem wspomnieć, jest to, że istniały dwie główne ścieżki, które były katalizowane przez Simulę. Wczesna (przypadkowo) była drogą, którą wybrałem metodą bio / net bez procedury danych. Drugim, który pojawił się nieco później jako przedmiot badań, były abstrakcyjne typy danych, co znacznie się poprawiło.
Jeśli spojrzymy na całą historię, zobaczymy, że proto-OOP zaczęło się od ADT, miał mały rozwidlenie w kierunku tego, co nazwałem „obiektami” - co doprowadziło do Smalltalk itp. - - ale po małym rozwidleniu Zakładanie CS prawie zrobiło ADT i chciało trzymać się paradygmatu procedury danych. Historycznie warto przyjrzeć się systemowi plików USAF Burroughs 220 (który opisałem w historii Smalltalk), wczesnej pracy Douga Rossa z MIT (AED i wcześniejszych), w której zalecał osadzanie wskaźników procedur w strukturach danych, Sketchpad (który miał pełny polimorfizm - gdzie np. to samo przesunięcie w jego strukturze danych oznaczało „wyświetlanie” i byłby wskaźnik do odpowiedniej procedury dla typu obiektu reprezentowanego przez strukturę itp. oraz Burroughsa B5000, których tabele odwołań do programu były prawdziwymi „dużymi obiektami” i zawierały wskaźniki zarówno do „danych”, jak i „procedur”, ale często mogły zrobić coś dobrego, jeśli próbowały szukać danych i znalazły wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur. ale często może zrobić coś dobrego, jeśli próbuje podążać za danymi i znaleźć wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur. ale często może zrobić coś dobrego, jeśli próbuje podążać za danymi i znaleźć wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur.
Ludzi, którzy lubili obiekty jako nie-dane, było mniej i obejmowali mnie, Carla Hewitta, Dave'a Reeda i kilku innych - prawie cała ta grupa pochodziła ze społeczności ARPA i w ten czy inny sposób była zaangażowana w projekt ARPAnet → Internet, w którym podstawową jednostką obliczeniową był cały komputer. Ale żeby pokazać, jak uparcie pomysł może się utrzymać, przez lata siedemdziesiąte i osiemdziesiąte, wielu ludzi próbowało przetrwać dzięki „zdalnemu wywoływaniu procedury” zamiast myśleć o przedmiotach i komunikatach. Sic tranzyt gloria mundi.
Twoje zdrowie,
Alan Kay