У чым розніца паміж вызначэннем АОНА Кей OOP і акцёрскай мадэллю Карла Хьюітса?


адказ 1:

Алан Кей адказаў на гэта ад першай асобы.

Дазвольце мне дадаць некалькі каментарыяў з пункту гледжання таго, хто вучыўся ў Масачусецкім тэхналагічным інстытуце, калі Хьюіт займаўся ранняй акцёрскай дзейнасцю (шчыра кажучы, не памятаю, калі я калі-небудзь праходзіў курсы ў яго. Пра ПЛАННЕР напэўна гаварылі ў многіх класах , і я памятаю цэлую серыю размоваў з Карлам на 9-м паверсе Тэхналогіі плошчы 545. І як той, хто сачыў за працай і карыстаўся некаторымі вынікаючымі мовамі.

Як сказаў Алан - асноўныя ідэі былі падобныя. Аднак, калі ўсё пахіснулася, Smalltalk страціў уяўленне аб паралельнасці - і на самай справе не займаецца пытаннямі кантрольнага патоку. Пакуль жа ніколі не было сур'ёзнай рэалізацыі працы Хьюіта. Але ... аказваецца, што Эрланг - незалежна распрацаваны ў той жа перыяд - вельмі падобны на чыстае акцёрскае асяроддзе.

З пункту гледжання архітэктара сістэмы, Smalltalk, здаецца, выдзяляе (дадзеныя) аб'екты - вы праектуеце, вызначаючы набор аб'ектаў, якія трэба рэалізаваць. Акцёрскі фармалізм - асабліва ў дачыненні да Эрланга - прымушае задумацца над працэсамі. Акцёры, як правіла, думаюць пра апрацоўку падзеяў - адначасова апрацоўваецца шмат падзей. Я ніколі не знайшоў добры спосаб думаць пра паток кіравання ў архітэктуры аб'ектна-арыентаваных сістэм - магчыма, таму я ніколі не выбіраў Smalltalk, за выключэннем мовы цацак (нягледзячы на ​​тое, што казалі іншыя).

Каб прывесці канкрэтны прыклад: я працаваў у ваенных трэнажорах і вакол іх (напрыклад, імітуючы 100 танкаў, якія рухаюцца па полі бою):

  • Прадукты кампаніі былі распрацаваны вакол OOP (на C ++, але гэта не зусім актуальна). Кожны танк быў прадметам. У кожным цыкле (24 / секунду, калі я правільна памятаю) чатыры розныя працэсы дакраналіся да кожнага аб'екта - разлічанае поле зроку, іншае разлічанае рух, іншыя разлічаныя эфекты зброі, іншая апрацаваная інфармацыя адлюстравання. Увесь код быў спагецці - і для змены дробязяў паўсюль патрабаваліся змены. Вельмі брудна. Як чалавек, які шмат часу правёў у свеце сетак - дзе вы ствараеце працэсы для ўсяго, - я б распрацаваў кожны танк як асобны працэс і выкарыстаў падзеі для змены рэчаў - гэта значыць кожны танк - акцёр, а не аб'ект. Стральба з пісталета - гэта пытанне адпраўкі паведамлення (праўда, гэта становіцца крыху больш складана - бо вам таксама трэба вызначыць, ці ёсць траекторыя праз вобласць). Калі вы хочаце, каб сінхранізаваць час, адпраўце галачку на гадзіннік - аднак, глабальны цыкл не патрабуецца. [У той час людзі сказалі мне, што вы проста не можаце кіраваць такімі працэсамі - змяненне кантэксту адаб'ецца на прадукцыйнасці. І гэта дакладна тычыцца C ++ - гэта прымусіла мяне шукаць літаратуру і ў рэшце рэшт выявіць Эрланг.] Таксама ўлічыце, што раз вы распаўсюджваеце мадэляванне па сетцы - напрыклад. B. сеткавыя трэнажоры танкаў (SIMNET), сеткавыя баявыя трэнажоры (ВПС), раптам апынуліся ў свеце, падобным на незалежныя працэсы, якія перадаюць адзін аднаму пратакольныя паведамленні.

адказ 2:

Няма вялікай розніцы. Гісторыю, якую я пісаў пра гэта, можна знайсці ў сетцы "Ранняя гісторыя малых размоў".

У прынцыпе, у лістападзе 66 года ў мяне ўзнікла ідэя "Дынамічны аб'ект як цэлы кампутар", пад вялікім уздзеяннем і каталізацыяй Sketchpad і Simula (асабліва ранейшага), першыя чарнавікі для ARPAnet, сучасныя ўяўленні пра працэсы як віртуальныя машыны ў таймшары і шматпрацэсарных сістэмах і Аналогіі з майго матэматычнага і біялагічнага паходжання.

Я бачыў, што пашыраныя ідэі мовы Айрона таксама могуць быць спосабам прыёму паведамленняў у сістэму дынамічных аб'ектаў - і пашырэння сінтаксісу. Я наткнуўся на гэта ў сваёй дыпломнай працы.

Я пазнаёміўся з Сеймурам Папертам у 1968 годзе, і гэта змяніла мой погляд на асабістыя вылічэнні, прывяло да ідэі Dynabook і прымусіла мяне задумацца, што дзеці павінны зрабіць, каб даведацца "магутныя ідэі", асабліва з камп'ютэрам.

Я зразумеў, што павінен скончыць дысертацыю і адкласці Дынакнігу на наступны праект.

Але я выявіў, што мова ПЛАНЕРА Карла Хьюіта ў MIT - вельмі важны папярэдні (і суперсет) пралога. Гэта амаль мяне зноў падарвала, таму што было ясна, што было б выдатна запраграмаваць нешта падобнае.

У Парку я пачаў з мінулых тэзісаў думаць пра мову дзіцяці, дзе яны могуць рабіць рэчы, падобныя на лагатып, прадметы, падобныя на прадметы, а таксама рэчы, якія тычацца планавання. Напрыклад, праблемы з кладкай малпаў і бананаў і блокаў.

Гэта прывяло да распрацоўкі Smalltalk-71, якая была перарвана "стаўкі і ўзлому" і адразу спарадзіла Smalltalk-72, мову аб'ектаў у стылі Макарці, апісаную на адной старонцы, аб'екты якой былі нешта накшталт зашпілек, якія маглі б прааналізаваць іх уклад. . Я прачытаў лекцыю з MIT восенню 72, каб падзяліцца гэтымі ідэямі, і першая праца акцёраў, якая адаптавала некаторыя з гэтых ідэй, з'явілася ў наступным годзе.

У выніку праца акцёраў засталася больш вернай першапачатковым ідэям аб'екта, чым наша невялікая гутарковая праца ў Парку. Часткова гэта звязана з тым, што нашай мэтай было "вынайсці практычныя асабістыя вылічэнні на персанальным камп'ютэры" і выкарыстоўваць для гэтага мэты, арыентаваныя на аб'екты. Мы рабілі шырокія перапісы раз у два гады, жанр мяняўся раз у чатыры гады, каб зрабіць усё неабходнае для запуску і разгортвання рэальнай сістэмы з карыстацкім інтэрфейсам і мноствам функцый.

Некалькі гадоў таму мы ажывілі невялікую размову, якую мы выказалі ў 1978 годзе пра пераносны кампутар Notetaker - да выратаванай дыскеты, якую Xerox знішчыў. Потым я выкарыстаў гэта, каб ушанаваць Тэда Нэльсана. Варта паглядзець. Стыў Джобс бачыў гэтую сістэму падчас свайго знакамітага візіту ў 1979-м наступным годзе.

Акцёрскае даследаванне дало некалькі вельмі важных вынікаў. (І, зразумела, праца парка ў цэлым аказала вялікі ўплыў.) Аднак наступныя крокі для моў, якія любяць PLANNER, і асабліва для спалучэння ідэй PLANNER з ідэямі аб'ектаў, мелі менш плавучасці і поспеху. Гэта ўсё яшчэ добрыя ідэі, і людзі павінны думаць пра іх яшчэ раз.