Чаму ГА смокча

Калі я ўпершыню пазнаёміўся з ідэяй ААП я быў настроены скептычна, але не ведаю, чаму - ён проста адчуваў сябе "няправільна". Пасля яго ўвядзення ААП стала вельмі папулярнай (я растлумачу, чаму пазней) і крытыкай ААП была хутчэй як "лаянку ў царкве". OOness стала тое, што кожны шаноўны мова усяго толькі трэба было мець.

Як Erlang стаў папулярным мы часта пытаюцца: "Ці з'яўляецца Erlang ГА" - ну, вядома, правільны адказ быў "няма, вядома, не" - але мы не гаварыць аб гэтым услых - так мы вынайшлі сур'ёзных нестандартныя спосабы адказу Пытанне, які быў распрацаваны, каб даць ўражанне, што Erlang было (накшталт) OO (Калі вы махалі рукамі шмат), але не вельмі (Калі вы слухалі тое, што мы на самай справе сказаў, і чытаць дробны шрыфт старанна).

У гэты момант я ўспамінаю праграмнай прамове тагачаснага боса IBM ў Францыі, які выступіў на сёмы IEEE логікі праграмавання канферэнцыі ў Парыжы. IBM пралогу было дададзена шмат пашырэнняў О.О., калі яго спыталі, чаму ён адказаў: Нашы кліенты хацелі OO пралогу так што мы зрабілі OO пралог

Памятаю, я падумаў ", як проста, без згрызот сумлення, ні душы-пошуку, не пытаючыся" Ці з'яўляецца гэта, што трэба рабіць "...

Чаму ГА смокча

Пярэчанне 1 - структура дадзеных і функцый, якія не павінны быць звязаны адзін з адным

• Функцыі рабіць. Яны маюць ўваходы і выхады. Ўваходы і выхады структуры дадзеных, якія атрымліваюць змененыя функцыі. У большасці моў функцыі складаюцца з паслядоўнасці імператывы: "Зрабіце гэта, і тое, што..." каб зразумець функцыі вы павінны разумець парадак, у якім ўсё робіцца (У гультаяваты FPLs і лагічных мовах гэта абмежаванне мякчэе).
• Дадзеныя структуры з'яўляюцца проста. Яны нічога не робяць. Яны унутрана дэкларатыўны характар. "Разуменне" структура дадзеных нашмат прасцей, чым "разуменне" функцыі.

Функцыі разумеюцца як чорныя скрыні, што пераўтварэнні уваходаў у выхады. Калі я разумею, уваход і выхад, то я зразумеў функцыі. Гэта не значыць, сказаць, што я мог бы напісаць функцыю.

Функцыі, як правіла, "зразумеў", заўважыўшы, што яны рэчы ў вылічальнай сістэме, чыя праца заключаецца ў перадачы дадзеных структур тыпу T1 ў структуру дадзеных тыпу T2.

Так як функцыі і структуры дадзеных зусім розныя тыпы жывёл гэта ў корані няправільна замкнуць іх у адной клетцы.

Пярэчанне 2 - Усё павінна быць аб'ектам.

Разгледзім "Час". У ГА мове "час", каб быць аб'ектам. Але ў не ГА мове "час" з'яўляецца асобнікам тыпу дадзеных. Напрыклад, у Erlang Ёсць шмат розных гатункаў часу, яны могуць быць выразна і недвухсэнсоўна паказваецца з дапамогай аб'яў тыпу, а менавіта:

 
 
-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...
 

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

Ёсць не звязаныя з ім метады.

Пярэчанне 3 - У вызначэннях OOPL тып дадзеных раскіданыя паўсюль.

У дадзеных OOPL вызначэння тыпаў належаць да аб'ектаў. Таму я не магу знайсці ўсе вызначэння тыпаў дадзеных у адным месцы. У Erlang або CI можна вызначыць усе мае тыпы дадзеных у адзіны файл ўключэньня ці слоўніка дадзеных. У OOPL я не магу - вызначэння тыпаў дадзеных раскіданыя паўсюль.

Дазвольце мне прывесці прыклад. Выкажам здагадку, я хачу, каб вызначыць усюдыісныя структуры дадзеных. ўсюдыісны тып дадзеных тыпу дадзеных, што адбываецца "на ўсім працягу месцы" ў сістэме.

Як шепелявить праграмісты ведаць на працягу доўгага часу гэта лепш мець невялікія колькасці усюдыісныя тыпаў дадзеных і вялікая колькасць дробных функцый, якія працуюць на іх, чым мець вялікую колькасць тыпаў дадзеных і невялікае лік функцый, якія працуюць на іх.

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

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

Пярэчанне 4 - Аб'екты маюць прыватныя стану.

Дзяржава корань усякага ліха. У прыватнасці функцыі з пабочнымі эфектамі варта пазбягаць.

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

Улічваючы, што дзяржава існуе ў рэальным свеце, якія сродкі павінны забяспечыць мовы праграмавання для працы з дзяржавай?

• OOPLs сказаць "схаваць дзяржавы ад праграміста". Станаў скрытыя і бачныя толькі праз доступ да функцый.
• Звычайных моў праграмавання (C, Pascal) кажуць, што бачнасць зменных стану кантралюецца правілаў вобласці мовы.
• Чыстая дэкларатыўныя мовы кажуць, што ні адна дзяржава. Глябальны стан сістэмы ажыццяўляецца ва ўсе функцыі і выходзіць з усіх функцый. Механізмы, як монады (для FPLs) і DCGs (лагічныя мовы) выкарыстоўваюцца, каб схаваць дзяржавы ад праграміста, каб яны маглі праграме "як калі б дзяржава не мае значэння", але мець поўны доступ да стану сістэмы павінны гэта будзе неабходна.

"Схаваць дзяржавы ад праграміста" варыянт абраны OOPLs гэта горш магчымы выбар. Замест выяўлення стану і спрабуюць знайсці спосабы, каб звесці да мінімуму нязручнасці ад дзяржавы, яны хаваюць яе.

Чаму О. быў папулярны?

• Прычына 1 - лічылася, можна было лёгка пазнаць.
• Прычына № 2 - Гэта была думка, каб зрабіць паўторнае выкарыстанне кода прасцей.
• Прычына № 3 - Гэта было разадзьмутымі.
• Прычына № 4 - Ён стварыў новую галіну праграмнага забеспячэння.

Я не бачу ніякіх сведчанняў 1 і 2. Прычын, як уяўляецца, рухаючай сілай тэхналогіі. Калі мова тэхналогія настолькі дрэнна, што ён стварае новыя галіны, каб вырашыць праблемы ўласнай вытворчасці, то яна павінна быць добрай ідэяй для дзяцей, якія хочуць рабіць грошы.

Гэта з'яўляецца рэальнай рухаючай сілай жаль.