То что есть — какое-то адово убожество в 2Мп максимум, непригодное ни для чего.
Хм, я сначала вам не поверил… а потом поискал и убедился :-(
А ведь 10 лет назад были с 3.2Мп и вполне прилично снимали, на Sony Ericsson например. И даже какие-то модели с 8Мп были. Странно, зачем было делать деградацию камер на обычных телефонах?
Теперь нам приходится смириться с фактом, что свет, по-видимому, состоит из квантов, и кванты являются одновременно как частицами, так и волнами.
Не только свет, но и вообще всё состоит из волн, вся Вселенная — большая интерференционная картина. А представление в виде частиц — это просто следствие эффекта наблюдателя. Точно так же как в компьютере всё состоит из нулей и единиц, а то что мы на этой странице видим какие-то комментарии и форму ответа — не более чем эффект наблюдателя.
В этой цитате речь идёт только про синтаксис. На него в принципе без разницы. А в цитате выше речь была про то, что изменился механизм отправки сообщений и механизм приёма сообщений.
Хотя насчёт "too much freedom" я тоже не согласен. Когда получатель письма диктует отправителю в каком формате надо это письмо писать, это уже и не письмо, а заполнение анкеты. Так что ввод синтаксических ограничений тоже можно поставить в минус Smalltalk, но это не главное.
Так в этом то и вопрос, остались ли они сообщениями или стали замаскированными вызовами методов? Всё говорит в пользу второго. Но Вы упрямитесь и не хотите это признавать и готовы спорить хоть лично с Кэем, но почему-то тут, а не на Quora, где у него был бы шанс вам ответить.
Это не аналог исключений. Это основа для любой отказоустойчивой распределенной системы, обязательная часть её штатной работы (см. принцип Let It Crash).
Если бы этого не было, если бы пришлось думать о таких случаях как о чём-то исключительном, то систему пришлось бы назвать слишком сложной, более того она бы реально была бы крайне сложной.
Но именно общение акторов через честную передачу сообщений позволяет системе оставаться относительно простой. Поэтому ваши аргументы, что что-то подобное можно накостылить какими-то воркэраундами тут и не принимают. Нельзя ключевой аспект языка реализовывать через воркэраунды, он должен быть неотъемлемой частью.
Он говорит про 71–72 гг, какие еще слова он должен использовать?!? Прошу прощения, но это уже чушь какая.
Если бы сообщения в Smalltalk остались такими же по сей день, то ему не пришлось бы рассказывать про 72 год. Или он смог бы написать: "From the earliest versions of Smalltalk and till now a message send is ..." и так далее в Present Simple. Не согласны?
Ваши объяснения сводятся к утверждению «в Erlang-е сообщения полноценные, следовательно в других местах они ненастоящие».
Вовсе нет, такого вам никто не писал.
Они бы устроили, если бы где-то Кэй сказал, что начиная со Smalltalk-76 «сообщения уже не те»…
Я вам подскажу, в цитате выше есть слова "was" и "did", именно они в английском означают, что сейчас «сообщения уже не те».
Поэтому давайте так: вы уверены, что в Smalltalk-72 сообщения были полноценными именно в том смысле, который вы дружно вкладываете в этот термин?
Меня ещё и на свете то не было, когда Smalltalk-72 был в моде ))) Поэтому я тут полагаюсь только на слова Кэя. Зачем ему врать? Если там реально было так: "a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc.", то да — там были сообщения.
Эмулятор я видел, но им хрен разберёшься как пользоваться… В 70-е было модно что-ли программировать на символах, которые нельзя ввести в клавиатуры?
Ну если чисто технически к этому вопросу подходить. То как добиться уменьшения среднего значения любой величины? Найти максимальные отклонения от среднего в большую сторону и уменьшить их.
В контексте данного обсуждения, смотрим карту:
Видим, что минимум — 8, максимум — 50, среднее — 29. Во всех странах, где показатель равен 30 и выше, вводим какие-то меры, усложняющие наличие более 2 детей у одной женщины. Остальные страны вообще не трогаем. Итого: лет через 50 население планеты перестанет расти. Для пущего эффекта можно запретить переезд из стран с ограничением в страны без ограничения.
P.S. Я не призываю всё это воплощать, но если вопрос стоит: как остановить прирост населения Земли? То ответ будет в любом случае примерно такой, как я описал. Других гуманных и действенных способов в общем-то нет.
Ну спросите Кэя лично, если вам что-то непонятно в его формулировках. В чём проблема то? на Quora забанили? xD
Smalltalk-72, если судить по библиографии Хьюитта, просто не мог базироваться на модели акторов поскольку первое упоминание термина «Актор» относится к 73-му году.
Вот вы дотошный… Ok.
Smalltalk-72 базировался на том, что в 73 году переросло в модель акторов (вот Хьюитт — молодец, не стал всех путать термином "объект", а ввёл новый и более подходящий). Однако, сам Smalltalk пошёл дальше другой дорогой, и отказался от этих идей по performance-соображениям тех лет.
Игнорировать можно пустым методом (в том числе и #doesNotUnderstand:
Это не игнорирование, а ничегонеделание при обработке. Так тоже можно, но это совсем другой вариант.
Как часто мы хотим, чтобы получатель игнорировал полученные сообщения? Грубо говоря, это хорошо, если очень много посланных сообщений игнорируется?
Ну, в процентах я не могу сказать, это от конкретной программы зависит. Но в целом, это ни хорошо, ни плохо, это просто нормально. Получатель вообще может уже не существовать в момент отправки ему сообщения.
Я просто сократил "a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc." до "настоящие сообщения".
Вы же сами пытаетесь выяснить, что мы подразумеваем под "настоящими сообщениями" и почему в Smalltalk они ненастоящие. Наши объяснения Вас не устроили, поэтому я нашёл Вам ответ лично от Кэя.
Да, в Smalltalk-72 были сообщения, которые мы тут обозвали настоящими. Но эту идею не смогли реализовать приемлемо по скорости работы. Поэтому от неё отказались и заменили сообщения на "замаскированный вызов метода". А термин "сообщение" исторически остался от первых реализаций, в которых они были.
P.S. Если Вас даже объяснение от Кэя не устроит, тогда уже не знаю, что тут ещё дополнить. Не хочется перепечатывать уже написанное. По-моему, мы коллективными усилиями разжевали ответ на ваши исходные вопросы дальше некуда.
Погодите, какая разница, что там описывает класс, если классы — это необязательная часть ООП. Это просто один из вариантов реализации.
Отсюда и все недопонимания. Если хотите руководствоваться википедией в этих вопросах, то советую читать английскую. В русской слишком много некорректных формулировок.
А классическое определение ООП, если что, выглядит так:
Everything is an object.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Про другие определения можно применять эпитеты "популярное", "распространённое" и т.д. Но классическое есть только одно.
Про такое я что-то не слышал… можно целиком его привести? А то непонятно, что такое "сущности из области определения".
Да и метод, вроде как, не может представлять взаимодействие между объектами, т.к. он принадлежит одному из объектов. Другими словами, метод максимум может быть частью интерфейса возможного воздействия на объект (однако, это однонаправленное понятие, в отличии от взаимодействия). Но и то публичные методы — необязательная часть, т.к. объект может и активную "жизненную позицию" занимать и сам откуда-нибудь брать себе работу (из очереди например), без внешнего обращения к нему.
Почитайте ветку чуть выше. Я начал как раз с того, что настоящие объекты не должны представлять данные. И им не нужны вспомогательные объекты, им нужен интерфейс для получения нужных данных. А кто там выступит в роли провайдера этих данных, будет ли он один или несколько, не так уж важно.
По сути любая программа — это тупо набор конвейерных линий по обработке данных. Вы получаете пользовательский ввод, как-то его обрабатываете, в результате этой обработки что-то идёт на склад (в БД), а что-то отдаётся обратно пользователю.
А объекты — это рабочие на этих конвейерах, к ним приходят одни данные — уходят другие (обработанные) и отправляются к следующим объектам.
Нет, не значит. Иметь состояние — это нормально и для актора и для объекта. А вот что именно будет его состоянием зависит исключительно от роли, которую он выполняет.
Другими словами, не "данные и методы работы с ними", а "методы, реализующие определенную ответственность, и данные, необходимые для выполнения этой ответственности".
Звучит как будто разница не велика, но по факту разница огромна. Первый подход: у нас есть деревянный брусок, давайте опишем всё (методы), что можно с ним сделать. Второй подход: нам надо сделать скалку, давайте подумаем что (какие данные) нам для этого нужно.
Удобно структуры и методы для их обработки располагать в одном модуле
Лишь до тех пор, пока вы не начали писать хоть что-то нетривиальное. Когда одна и та же структура в разных контекстах обладает совершенно разным поведением, пихать все методы в один файл становится преступлением. В лучшем случае вы такие структуры продублируете аля Bounded Context, в худшем — получите классический God Object аля Active Record.
Если бы вы изначально проектировали от поведения, а не от структур, таких проблем бы даже не возникло. Но в этом случае вам бы даже в страшном сне не приснилось структуры и методы для их обработки надо располагать в одном модуле.
Иерархичное расположение структур позволяет сократить описание как структур, так и методов.
Сокращение описания структур — так себе цель. Во-первых, если у вас в структуре 30+ полей, а вы ещё от неё и наследуете, и полей добавляете — это уже плохо пахнет. Лучше подумать над доменной моделью, чем экономить десяток строк.
Одной инкапсуляции мало — вы правы.
ООП = обмен сообщениями + инкапсуляция + максимально позднее связывание.
А вот полиморфизм вообще к ООП никакого отношения не имеет.
Хм, я сначала вам не поверил… а потом поискал и убедился :-(
А ведь 10 лет назад были с 3.2Мп и вполне прилично снимали, на Sony Ericsson например. И даже какие-то модели с 8Мп были. Странно, зачем было делать деградацию камер на обычных телефонах?
Не только свет, но и вообще всё состоит из волн, вся Вселенная — большая интерференционная картина. А представление в виде частиц — это просто следствие эффекта наблюдателя. Точно так же как в компьютере всё состоит из нулей и единиц, а то что мы на этой странице видим какие-то комментарии и форму ответа — не более чем эффект наблюдателя.
В этой цитате речь идёт только про синтаксис. На него в принципе без разницы. А в цитате выше речь была про то, что изменился механизм отправки сообщений и механизм приёма сообщений.
Хотя насчёт "too much freedom" я тоже не согласен. Когда получатель письма диктует отправителю в каком формате надо это письмо писать, это уже и не письмо, а заполнение анкеты. Так что ввод синтаксических ограничений тоже можно поставить в минус Smalltalk, но это не главное.
Так в этом то и вопрос, остались ли они сообщениями или стали замаскированными вызовами методов? Всё говорит в пользу второго. Но Вы упрямитесь и не хотите это признавать и готовы спорить хоть лично с Кэем, но почему-то тут, а не на Quora, где у него был бы шанс вам ответить.
Это не аналог исключений. Это основа для любой отказоустойчивой распределенной системы, обязательная часть её штатной работы (см. принцип Let It Crash).
Если бы этого не было, если бы пришлось думать о таких случаях как о чём-то исключительном, то систему пришлось бы назвать слишком сложной, более того она бы реально была бы крайне сложной.
Но именно общение акторов через честную передачу сообщений позволяет системе оставаться относительно простой. Поэтому ваши аргументы, что что-то подобное можно накостылить какими-то воркэраундами тут и не принимают. Нельзя ключевой аспект языка реализовывать через воркэраунды, он должен быть неотъемлемой частью.
Если бы сообщения в Smalltalk остались такими же по сей день, то ему не пришлось бы рассказывать про 72 год. Или он смог бы написать: "From the earliest versions of Smalltalk and till now a message send is ..." и так далее в Present Simple. Не согласны?
Можно подумать, что у вас в программах вся нагрузка на процессор полезная xD
Стабильность и отказоустойчивость важнее экономии на спичках.
Вовсе нет, такого вам никто не писал.
Я вам подскажу, в цитате выше есть слова "was" и "did", именно они в английском означают, что сейчас «сообщения уже не те».
Меня ещё и на свете то не было, когда Smalltalk-72 был в моде ))) Поэтому я тут полагаюсь только на слова Кэя. Зачем ему врать? Если там реально было так: "a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc.", то да — там были сообщения.
Эмулятор я видел, но им хрен разберёшься как пользоваться… В 70-е было модно что-ли программировать на символах, которые нельзя ввести в клавиатуры?
Ну если чисто технически к этому вопросу подходить. То как добиться уменьшения среднего значения любой величины? Найти максимальные отклонения от среднего в большую сторону и уменьшить их.
В контексте данного обсуждения, смотрим карту:
Видим, что минимум — 8, максимум — 50, среднее — 29. Во всех странах, где показатель равен 30 и выше, вводим какие-то меры, усложняющие наличие более 2 детей у одной женщины. Остальные страны вообще не трогаем. Итого: лет через 50 население планеты перестанет расти. Для пущего эффекта можно запретить переезд из стран с ограничением в страны без ограничения.
P.S. Я не призываю всё это воплощать, но если вопрос стоит: как остановить прирост населения Земли? То ответ будет в любом случае примерно такой, как я описал. Других гуманных и действенных способов в общем-то нет.
Ну спросите Кэя лично, если вам что-то непонятно в его формулировках. В чём проблема то? на Quora забанили? xD
Вот вы дотошный… Ok.
Smalltalk-72 базировался на том, что в 73 году переросло в модель акторов (вот Хьюитт — молодец, не стал всех путать термином "объект", а ввёл новый и более подходящий). Однако, сам Smalltalk пошёл дальше другой дорогой, и отказался от этих идей по performance-соображениям тех лет.
Это не игнорирование, а ничегонеделание при обработке. Так тоже можно, но это совсем другой вариант.
Ну, в процентах я не могу сказать, это от конкретной программы зависит. Но в целом, это ни хорошо, ни плохо, это просто нормально. Получатель вообще может уже не существовать в момент отправки ему сообщения.
Я просто сократил "a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc." до "настоящие сообщения".
Вы же сами пытаетесь выяснить, что мы подразумеваем под "настоящими сообщениями" и почему в Smalltalk они ненастоящие. Наши объяснения Вас не устроили, поэтому я нашёл Вам ответ лично от Кэя.
Да, в Smalltalk-72 были сообщения, которые мы тут обозвали настоящими. Но эту идею не смогли реализовать приемлемо по скорости работы. Поэтому от неё отказались и заменили сообщения на "замаскированный вызов метода". А термин "сообщение" исторически остался от первых реализаций, в которых они были.
P.S. Если Вас даже объяснение от Кэя не устроит, тогда уже не знаю, что тут ещё дополнить. Не хочется перепечатывать уже написанное. По-моему, мы коллективными усилиями разжевали ответ на ваши исходные вопросы дальше некуда.
Погодите, какая разница, что там описывает класс, если классы — это необязательная часть ООП. Это просто один из вариантов реализации.
Отсюда и все недопонимания. Если хотите руководствоваться википедией в этих вопросах, то советую читать английскую. В русской слишком много некорректных формулировок.
А классическое определение ООП, если что, выглядит так:
Про другие определения можно применять эпитеты "популярное", "распространённое" и т.д. Но классическое есть только одно.
Про такое я что-то не слышал… можно целиком его привести? А то непонятно, что такое "сущности из области определения".
Да и метод, вроде как, не может представлять взаимодействие между объектами, т.к. он принадлежит одному из объектов. Другими словами, метод максимум может быть частью интерфейса возможного воздействия на объект (однако, это однонаправленное понятие, в отличии от взаимодействия). Но и то публичные методы — необязательная часть, т.к. объект может и активную "жизненную позицию" занимать и сам откуда-нибудь брать себе работу (из очереди например), без внешнего обращения к нему.
А какое из определений ООП вы считаете классическим?
P.S. Мне кажется, с ответа на этот вопрос должна любая статья про ООП начинаться :-)
Почитайте ветку чуть выше. Я начал как раз с того, что настоящие объекты не должны представлять данные. И им не нужны вспомогательные объекты, им нужен интерфейс для получения нужных данных. А кто там выступит в роли провайдера этих данных, будет ли он один или несколько, не так уж важно.
По сути любая программа — это тупо набор конвейерных линий по обработке данных. Вы получаете пользовательский ввод, как-то его обрабатываете, в результате этой обработки что-то идёт на склад (в БД), а что-то отдаётся обратно пользователю.
А объекты — это рабочие на этих конвейерах, к ним приходят одни данные — уходят другие (обработанные) и отправляются к следующим объектам.
Тут про полиморфизм речь шла, а не про наследование.
Нет, не значит. Иметь состояние — это нормально и для актора и для объекта. А вот что именно будет его состоянием зависит исключительно от роли, которую он выполняет.
Другими словами, не "данные и методы работы с ними", а "методы, реализующие определенную ответственность, и данные, необходимые для выполнения этой ответственности".
Звучит как будто разница не велика, но по факту разница огромна.
Первый подход: у нас есть деревянный брусок, давайте опишем всё (методы), что можно с ним сделать.
Второй подход: нам надо сделать скалку, давайте подумаем что (какие данные) нам для этого нужно.
Лишь до тех пор, пока вы не начали писать хоть что-то нетривиальное. Когда одна и та же структура в разных контекстах обладает совершенно разным поведением, пихать все методы в один файл становится преступлением. В лучшем случае вы такие структуры продублируете аля Bounded Context, в худшем — получите классический God Object аля Active Record.
Если бы вы изначально проектировали от поведения, а не от структур, таких проблем бы даже не возникло. Но в этом случае вам бы даже в страшном сне не приснилось структуры и методы для их обработки надо располагать в одном модуле.
Сокращение описания структур — так себе цель. Во-первых, если у вас в структуре 30+ полей, а вы ещё от неё и наследуете, и полей добавляете — это уже плохо пахнет. Лучше подумать над доменной моделью, чем экономить десяток строк.
Например, через протоколы вы можете достигать полиморфизма даже от типов, к реализации которых не имеете доступа.
Пример: https://medium.com/everydayhero-engineering/extensibility-in-elixir-using-protocols-2e8fb0a35c48
Ещё один вариант: Type Classes в Haskell.
Одной инкапсуляции мало — вы правы.
ООП = обмен сообщениями + инкапсуляция + максимально позднее связывание.
А вот полиморфизм вообще к ООП никакого отношения не имеет.