Вы упорно отказываетесь различать объекты и акторы, а это, очевиднейшим образом, разные вещи, что прекрасно видно на приведенном вами примере.
Я не отказываюсь их различать. Я намеренно их объединяю в одно понятие в рамках данной дискуссии, поскольку объекты изначально задумывались как акторы:
Что тут важно? Биологическая клетка или компьютер в сети — это активная действующая единица. На самом деле, термин "объект" крайне неудачно подходит для самой концепции, поскольку имеется в виду субъект действия, который может общаться с другими субъектами посредством обмена сообщениями. Всё остальное вторично.
Именно так реализованы акторы в Erlang/OTP. А объекты в Smalltalk реализованы не так (хотели так, но видимо для 1969 года идея оказалась слишком сложной). Глупо думать о книге, о строке, или о числе, как об отдельном компьютере в сети (даже умозрительно это был бы абсолютно иррациональный оверхэд, вдобавок затрудняющий понимание функционирования сети), поэтому они не могут быть объектами в Кеевском понимании. Вот собственно и всё резюме.
Объекты (по умолчанию) ничего не делают сами по себе, они лишь реагируют на сообщения
Сообщение можно интерпретировать как приказ/задачу сделать что-либо. Дальше объект должен мочь что-то сделать сам по себе (отреагировать). Книга, как объект физической реальности, не способна никак отреагировать, хоть сколько ей ни приказывай. Вам придётся самому что-то с ней сделать, чтобы она как-то изменилась, не путём сообщений, а путём прямого физического воздействия.
Книга не может менять название? Расскажите об этом писателям.
Писатель/редактор/цензор/издатель — это уже акторы, они могут изменить название книги, не вопрос (хотя даже у них есть ограничения, например, если книга напечатана, то никто уже не может изменить её название). А книга сама ничего не может, у неё нет никаких встроенных методов для этого. Вы серьёзно не видите разницы?
P.S. Не воспринимайте всё так, как-будто я не знаком с ООП во всех его современных проявлениях. Я специально пишу в такой манере, чтобы Вы могли взглянуть на вещи под другим углом, скинув привычные шоры.
Объект/актор — это тот, кто может что-то делать сам (имея данные, совершать действия). В нашей Вселенной такой опцией обладают, конечно, не только люди, но исключительно живые существа. Но посколько IT, в основном, автоматизирует деятельность людей, то достаточно ограничиться людьми и их должностными обязанностями для первичного описания полноценного и качественного ООП.
Проблема популярного ООП, в том числе и в Smalltalk, что создатели ЯП решили всё подряд назвать объектами (всё-таки неудачный термин, актор — гораздо точнее соответствует идеям Кея). И ещё внедрить напрочь безумную идею, что это похоже на реальный мир. Я вот ни разу не видел книгу, которая могла бы сама себе поменять название или посчитать кол-во страниц в себе. Потому что книга — это просто структура данных (да ещё и иммутабельная, если её не портить), и никаких методов она иметь не может. А в ООП-программах подобная дичь сплошь и рядом.
Да, в этом заключается идея синхронной посылки сообщения.
Вовсе необязательно. Можно ждать ответного сообщения.
В случае Smalltalk надо бы еще уточнить, что такое «вся программа».
Ну ok, в Smalltalk сама среда вряд ли упадёт, но остаться в состоянии, неспособном обрабатывать последующие запросы, вполне может.
В моем текущем (и не только моем) понимании сообщение отличается от вызова функции
Я думаю, непонимание цитаты началось именно с придирки к слову "функция", там очевидно имелся в виду "вызов метода". И про late binding (который Вы описали и который есть в куче ЯП) все знают, но это всё равно не обмен сообщениями. В Smalltalk у вызывающего объекта нет никакого способа получить ответ в виде сообщения. Как следствие, ни о каком обмене сообщениями говорить не приходится.
Вот это «по сути» — можно раскрыть? Где коренится эта самая суть?
В этой ветке уже многократно описали чем отличается пересылка сообщений в Erlang от вызова метода в какой-нибудь Java. А в чём тут отличие между Java и Smalltalk?
И там и там, получатель обязан иметь строго заданный тип (быть экземпляром класса, реализующего определённый интерфейс/протокол). И там и там, вызывающий объект не принимает сообщения от другого объекта, а ждёт return вызванного метода. И там и там объекты не изолированы на уровне виртуальной машины, как следствие вызов метода может уронить вызывающий объект, а точнее говоря всю программу.
Разве в Erlang сообщение — не «просто» терм? …А в Smalltalk — «просто» объект (но никак не метод) ;)
"«просто» объект"? В этом вся и проблема, в Smalltalk нет фактического разделения на объекты и сообщения. Есть только болтовня на эту тему.
Представьте, что объекты — это люди, которые выполняют какую-то работу. У каждого человека есть свои должностные обязанности. И ему прилетают задачи (сообщения) и встают в очередь того, что надо сделать. Человек постепенно делает эти задачи. Если не знает как сделать, то отправляет другому человеку, ну или в мусорку, в зависимости от должностных инструкций.
Собственно, Кей именно про такое и говорил, только на примере клеток. И что предлагает Smalltalk? Пересылать людей друг другу вместо обмена сообщениями :facepalm:
Я думаю, имелось в виду, что реализация обработки "сообщений" в Smalltalk ничем по сути не отличается от вызова метода в языках типа C++, Java и т.д. А в Erlang/Elixir она принципиально иначе реализована. Сообщение тут это не объект и не метод, а именно сообщение и ничто больше. Отправить его можно при желании кому угодно (любому актору), как и почтовый конверт любому адресату.
В Smalltalk, строго говоря, вообще нет отдельной концепции сообщений. Т.е. говорить о сообщении как о чём-то независимом от объекта там можно только в теории.
Бывают другие варианты? В Erlang/Elixir это не так? А как?
В Erlang/Elixir каждый объект (актор) имеет свой mailbox, куда приходят сообщения, и он их по очереди обрабатывает. Ну и 2 режима отправки сообщений: ждать результат обработки сообщения от объекта или не ждать.
Строго говоря, некоторые онлайн-чаты для интернет-магазинов так и работают. Сообщения со всех каналов валятся в одну админку, где операторы на них отвечают и эти ответы уходят туда, откуда пришёл вопрос. Проблема тут только в том, что не все мессенджеры имеют API. Например, WhatsApp принципиально его не делает.
Ну и ещё, свой вклад в сие неблагородное дело явно внёс Страуструп, называя свой язык ОО, и плотной ассоциации идеологии классов и стандартных «трёх китов»(+ абстракцию) с данным понятием.
Кстати, вполне возможно, что он и есть тот самый "диверсант", поскольку он начал позиционировать C with classes как объектно-ориентированный язык, коим он не являлся. А учитывая популярность C, ему удалось, как сейчас говорят, хайпануть на этой теме и завести IT-индустрию в многолетние мучительные поиски паттернов и антипаттернов, чтобы хоть как-то этим безобразием можно было пользоваться. А с приходом мультиядерных процессоров опять всё сломалось… Вдруг выяснилось, что shared data — это больно и вокруг этого нагородили ещё кучу костылей.
На фоне всего этого, Армстронг и вся команда разработчиков Erlang — просто гении, обогнавшие развитие индустрии на десятилетия.
В принципе, любое определение ООП, в котором есть слово "класс", уже неверно. Хотя бы потому что классы — это все-лишь один из способов реализации ООП. Соответственно все такие определения нарушают open-closed principle xD
Не суть важно, что ближе русским студентам… Важнее, более аккуратно формулировать определения. В этом плане даже структура этого раздела английской Википедии отличается хорошей точностью:
Как видно, модель акторов, классы, прототипы и т.д. — всё это просто разные реализации ООП. И ООП — это только то, что их объединяет.
Хм, я думал, статья будет про какие-нибудь порошки — размешал и все нужные питательные вещества получил. А оказалось, что «альтернативная еда» — это котлетоимитаторы xD
Ну, давайте посмотрим на определение общепринятого ООП:
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data, in the form of fields (often known as attributes), and code, in the form of procedures (often known as methods). A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another.
Как видите, никакого противоречия с "ООП в Smalltalk" тут нет.
Не знаю уж, кто первым придумал ассоциировать ООП с И.Н.П. и рассказывать студентам про 3 китов. Но этот человек явно заслужил премию "почётный диверсант" за введение в заблуждение огромного количества людей. Причём, насколько я замечал, эта дезинформация гораздо популярнее в РуНете.
Насколько я понял, имелось в виду, не то, что кроме 2 никого больше нет. А что 2 компании делят между собой более 90% рынка. Хотя, имхо, может быть устойчивая конфигурация и из 3 компаний.
Одна из основных задач программирования — это изоляция сайд-эффектов. Если у вас допустим идёт работа с БД, то можно сохранять данные по мере вычисления и размазать логику работы с БД по всей программе. А можно сначала подготовить все данные, а потом сохранить их все разом. Это можно делать в любой парадигме, но, применяя ООП, про это, к сожалению, часто забывают.
А если попутно ставится задание в очередь, о выполнении которого клиент потом уведомляется? Никак тут моделью функции, пускай и не чистой, не обойтись.
В чём проблема? Или вы представляете какую-то одну божественную функцию, которая делает всё? Это не так работает.
Постановка задания в очередь — это сайд-эффект, но тем не менее это никак не мешает вернуть какой-то ответ клиенту. А при выполнении задания, когда до него дойдёт очередь, уведомить клиента, например через веб-сокет.
Хм, имхо, наоборот… в LibreOffice есть специальный синтаксис для ввода формул текстом, что мега удобно, когда вам надо сотни формул вводить. А в MS Office, когда я его в прошлый раз видел, можно было только тыкая мышкой формулы вводить… Что может подойдёт для случая, когда вам нужно пару тривиальных формул ввести, но для чего-то посложнее — это ппц.
Если вы не заметили статья про "оценку сроков на разработку и тестирование задач". Про оценку проектов целиком тут никто не говорил. Оценка проекта — это тупо оксюморон, потому что нормальные проекты живут и развиваются, а не сдаются "под ключ".
Вы же пишете, что нельзя оценить ничего с приемлемой точностью на проектах, требующих R&D. И это неверно.
Я не отказываюсь их различать. Я намеренно их объединяю в одно понятие в рамках данной дискуссии, поскольку объекты изначально задумывались как акторы:
I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging".
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages. © Alan Kay
Что тут важно? Биологическая клетка или компьютер в сети — это активная действующая единица. На самом деле, термин "объект" крайне неудачно подходит для самой концепции, поскольку имеется в виду субъект действия, который может общаться с другими субъектами посредством обмена сообщениями. Всё остальное вторично.
Именно так реализованы акторы в Erlang/OTP. А объекты в Smalltalk реализованы не так (хотели так, но видимо для 1969 года идея оказалась слишком сложной). Глупо думать о книге, о строке, или о числе, как об отдельном компьютере в сети (даже умозрительно это был бы абсолютно иррациональный оверхэд, вдобавок затрудняющий понимание функционирования сети), поэтому они не могут быть объектами в Кеевском понимании. Вот собственно и всё резюме.
Сообщение можно интерпретировать как приказ/задачу сделать что-либо. Дальше объект должен мочь что-то сделать сам по себе (отреагировать). Книга, как объект физической реальности, не способна никак отреагировать, хоть сколько ей ни приказывай. Вам придётся самому что-то с ней сделать, чтобы она как-то изменилась, не путём сообщений, а путём прямого физического воздействия.
Писатель/редактор/цензор/издатель — это уже акторы, они могут изменить название книги, не вопрос (хотя даже у них есть ограничения, например, если книга напечатана, то никто уже не может изменить её название). А книга сама ничего не может, у неё нет никаких встроенных методов для этого. Вы серьёзно не видите разницы?
P.S. Не воспринимайте всё так, как-будто я не знаком с ООП во всех его современных проявлениях. Я специально пишу в такой манере, чтобы Вы могли взглянуть на вещи под другим углом, скинув привычные шоры.
После этой фразы я ожидал поворот статьи в сторону Haskell, или хотя бы PureScript :-)
Объект/актор — это тот, кто может что-то делать сам (имея данные, совершать действия). В нашей Вселенной такой опцией обладают, конечно, не только люди, но исключительно живые существа. Но посколько IT, в основном, автоматизирует деятельность людей, то достаточно ограничиться людьми и их должностными обязанностями для первичного описания полноценного и качественного ООП.
Проблема популярного ООП, в том числе и в Smalltalk, что создатели ЯП решили всё подряд назвать объектами (всё-таки неудачный термин, актор — гораздо точнее соответствует идеям Кея). И ещё внедрить напрочь безумную идею, что это похоже на реальный мир. Я вот ни разу не видел книгу, которая могла бы сама себе поменять название или посчитать кол-во страниц в себе. Потому что книга — это просто структура данных (да ещё и иммутабельная, если её не портить), и никаких методов она иметь не может. А в ООП-программах подобная дичь сплошь и рядом.
Вовсе необязательно. Можно ждать ответного сообщения.
Ну ok, в Smalltalk сама среда вряд ли упадёт, но остаться в состоянии, неспособном обрабатывать последующие запросы, вполне может.
Я думаю, непонимание цитаты началось именно с придирки к слову "функция", там очевидно имелся в виду "вызов метода". И про late binding (который Вы описали и который есть в куче ЯП) все знают, но это всё равно не обмен сообщениями. В Smalltalk у вызывающего объекта нет никакого способа получить ответ в виде сообщения. Как следствие, ни о каком обмене сообщениями говорить не приходится.
В этой ветке уже многократно описали чем отличается пересылка сообщений в Erlang от вызова метода в какой-нибудь Java. А в чём тут отличие между Java и Smalltalk?
И там и там, получатель обязан иметь строго заданный тип (быть экземпляром класса, реализующего определённый интерфейс/протокол). И там и там, вызывающий объект не принимает сообщения от другого объекта, а ждёт return вызванного метода. И там и там объекты не изолированы на уровне виртуальной машины, как следствие вызов метода может уронить вызывающий объект, а точнее говоря всю программу.
"«просто» объект"? В этом вся и проблема, в Smalltalk нет фактического разделения на объекты и сообщения. Есть только болтовня на эту тему.
Представьте, что объекты — это люди, которые выполняют какую-то работу. У каждого человека есть свои должностные обязанности. И ему прилетают задачи (сообщения) и встают в очередь того, что надо сделать. Человек постепенно делает эти задачи. Если не знает как сделать, то отправляет другому человеку, ну или в мусорку, в зависимости от должностных инструкций.
Собственно, Кей именно про такое и говорил, только на примере клеток. И что предлагает Smalltalk? Пересылать людей друг другу вместо обмена сообщениями :facepalm:
Разве "сообщение" в Smalltalk — это не объект? А оно обязано быть не объектом, чтобы быть чем-то иным по факту, а не на словах.
Я думаю, имелось в виду, что реализация обработки "сообщений" в Smalltalk ничем по сути не отличается от вызова метода в языках типа C++, Java и т.д. А в Erlang/Elixir она принципиально иначе реализована. Сообщение тут это не объект и не метод, а именно сообщение и ничто больше. Отправить его можно при желании кому угодно (любому актору), как и почтовый конверт любому адресату.
В Smalltalk, строго говоря, вообще нет отдельной концепции сообщений. Т.е. говорить о сообщении как о чём-то независимом от объекта там можно только в теории.
В Erlang/Elixir каждый объект (актор) имеет свой mailbox, куда приходят сообщения, и он их по очереди обрабатывает. Ну и 2 режима отправки сообщений: ждать результат обработки сообщения от объекта или не ждать.
Строго говоря, некоторые онлайн-чаты для интернет-магазинов так и работают. Сообщения со всех каналов валятся в одну админку, где операторы на них отвечают и эти ответы уходят туда, откуда пришёл вопрос. Проблема тут только в том, что не все мессенджеры имеют API. Например, WhatsApp принципиально его не делает.
Кстати, вполне возможно, что он и есть тот самый "диверсант", поскольку он начал позиционировать C with classes как объектно-ориентированный язык, коим он не являлся. А учитывая популярность C, ему удалось, как сейчас говорят, хайпануть на этой теме и завести IT-индустрию в многолетние мучительные поиски паттернов и антипаттернов, чтобы хоть как-то этим безобразием можно было пользоваться. А с приходом мультиядерных процессоров опять всё сломалось… Вдруг выяснилось, что shared data — это больно и вокруг этого нагородили ещё кучу костылей.
На фоне всего этого, Армстронг и вся команда разработчиков Erlang — просто гении, обогнавшие развитие индустрии на десятилетия.
В принципе, любое определение ООП, в котором есть слово "класс", уже неверно. Хотя бы потому что классы — это все-лишь один из способов реализации ООП. Соответственно все такие определения нарушают open-closed principle xD
Не суть важно, что ближе русским студентам… Важнее, более аккуратно формулировать определения. В этом плане даже структура этого раздела английской Википедии отличается хорошей точностью:
Как видно, модель акторов, классы, прототипы и т.д. — всё это просто разные реализации ООП. И ООП — это только то, что их объединяет.
Хм, я думал, статья будет про какие-нибудь порошки — размешал и все нужные питательные вещества получил. А оказалось, что «альтернативная еда» — это котлетоимитаторы xD
Ну, давайте посмотрим на определение общепринятого ООП:
Как видите, никакого противоречия с "ООП в Smalltalk" тут нет.
Не знаю уж, кто первым придумал ассоциировать ООП с И.Н.П. и рассказывать студентам про 3 китов. Но этот человек явно заслужил премию "почётный диверсант" за введение в заблуждение огромного количества людей. Причём, насколько я замечал, эта дезинформация гораздо популярнее в РуНете.
Насколько я понял, имелось в виду, не то, что кроме 2 никого больше нет. А что 2 компании делят между собой более 90% рынка. Хотя, имхо, может быть устойчивая конфигурация и из 3 компаний.
Одна из основных задач программирования — это изоляция сайд-эффектов. Если у вас допустим идёт работа с БД, то можно сохранять данные по мере вычисления и размазать логику работы с БД по всей программе. А можно сначала подготовить все данные, а потом сохранить их все разом. Это можно делать в любой парадигме, но, применяя ООП, про это, к сожалению, часто забывают.
В чём проблема? Или вы представляете какую-то одну божественную функцию, которая делает всё? Это не так работает.
Постановка задания в очередь — это сайд-эффект, но тем не менее это никак не мешает вернуть какой-то ответ клиенту. А при выполнении задания, когда до него дойдёт очередь, уведомить клиента, например через веб-сокет.
О, это хорошо! А то помню, как я с MS Equation мучался, когда в универе надо было именно в doc какую-нибудь работу сдать.
Хм, имхо, наоборот… в LibreOffice есть специальный синтаксис для ввода формул текстом, что мега удобно, когда вам надо сотни формул вводить. А в MS Office, когда я его в прошлый раз видел, можно было только тыкая мышкой формулы вводить… Что может подойдёт для случая, когда вам нужно пару тривиальных формул ввести, но для чего-то посложнее — это ппц.
Меня несколько смущает, что ничего не сказано про ленивость вычислений. Если уж отказываться от циклов, то это must have.
Тоже возник такой вопрос. А вообще лучше бы они Nemerle поддержали.
Если вы не заметили статья про "оценку сроков на разработку и тестирование задач". Про оценку проектов целиком тут никто не говорил. Оценка проекта — это тупо оксюморон, потому что нормальные проекты живут и развиваются, а не сдаются "под ключ".
Вы же пишете, что нельзя оценить ничего с приемлемой точностью на проектах, требующих R&D. И это неверно.