Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет..
Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной
Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.
Так и осталось непонятным зачем этот ряд
Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
Про унарный оператор ~v0s меня уже опередил. С этим как раз ничего менять не пришлось бы. Технически бинарный оператор ^ добавить то можно, но вряд ли одному символу станут придавать настолько разный смысл в зависимости от кол-ва операндов.
А x?. по мне всё равно дико смотрится, особенно для тех, у кого есть опыт работы с Ruby, где существует совершенно логичная конвенция, что x? всегда возвращает boolean, ну типа active? вместо isActive. Думаю, всё равно в итоге нормальную Maybe монаду завезут и эти? после x станут deprecated.
Хз, зависит от условий конкретной стажировки. Может и можете. Я просто к тому, что если у человека 0 лет опыта работы, то лучше написать что и как долго он изучал, чем ничего не написать.
Ну так в резюме и пишут опыт работы в годах. Но тут то речь о стажировке и первом потенциальном месте работы, так что можно писать, что угодно (просто для информации).
Да фичи то ещё ладно, а вот синтаксис для них они выбирают какой-то слишком странный.
В MiddleName?[0] знак вопроса ни к селу, ни к городу, семантики никакой. Сделали бы просто, что для переменной Nullable-типа вызов любого метода возвращает null обёрнутый в Nullable-тип возврата, если в самой переменной был null. ^0 как автор в статье написал, лучше бы для возведения в степень использовали.
А тут можно было бы ~0
термин recursive patterns — это еще на порядок хуже
Зачем для этого вообще отдельный термин? Это же самый обычный паттерн-матчинг с нормальной деконструкцией и биндингом сматченных значений в переменные.
Можно было бы обозвать "Pattern matching restrictions have been eased."
Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются.
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Так имеет Smalltalk отношение к сути вопроса или не имеет?
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
У Вас
sendMsgAsync(eventLogger, event)
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю: sendMsg ({куда}, {сообщение});
И «прокинуть эвент для обработки ряду объектов» это не
Разумеется конкретному,
Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет.
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.
В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана.
Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.
Термин «извращение» не мат. термин
В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?
Т.е. никакой из существующих ЯП такой механизм не использует?
Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.
sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
И что?
Должен быть единый список сообщений, понятный всем объектам?
Нет.
Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
Любой. Any Data.
Если сообщения в инете, то они должны шифроваться для безопасности?
Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.
Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
Everything is an object.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI
Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
Чем это отличается от передачи событий ОС, нпр., Виндов ХР? Для обменов клиент-сервер обычно применяют технологии типа COM и, даже, CORBA.
Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA (неужели это кто-то до сих пор использует?). Они все нафиг не нужны, когда у вас есть ООП на базе классического определения.
Если у вас есть ООП — у вас уже есть клиент-серверное программирование. Если его нет, то у вас нет и ООП. Вот цитата с OOPSLA 1997:
"So this is an early insight that objects basically are like servers. This notion of polymorphism, which used to be called generic procedures is a way of thinking about classes of these servers. Everybody knows about that."
Только задумайтесь, 22 года назад все знали, что объекты должны играть роль минисерверов. А сейчас приходится это разжёвывать.
Какой это ЯП? Что означает в ":ok" двоеточие? что значат фигурные скобки в "{:ok, event} = sendMsg(eventEnricher, event)"?
Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.
P.S. Почитайте статью, которую вы упустили из виду.
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Возьмем класс TRect из моего примера.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
Потому что это специализация по сфере деятельности. Невозможно одинаково хорошо владеть и веб-разработкой, и мобильной, и разработкой под встраиваемые устройства, и т.д. Но даже внутри одной специализации вам всё равно необходимо знать несколько языков.
Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
Ага, даже интересно посмотреть на такого кадра, который возьмёт на позицию мидла человека с резюме "в течение года учил Python на курсах".
Я понимаю, что пост — реклама Geekbrains, но нельзя же настолько топорно впаривать.
Вот ещё фееричный пассаж:
В базовой конфигурации Python лежит около 70 функций и несколько десятков зарезервированных слов, но даже крутой программист не обязательно использует их все. То есть, чтобы выучить сотню слов и понять, что они делают, можно потратить одну-три недели при желании и активной работе
Это из серии: в русском языке всего 33 буквы, то есть чтобы их выучить достаточно потратить один-три дня. Про то, что это никак не связано с умением выражать свои мысли на языке и вообще неважно сколько там функций и зарезервированных слов, почему-то умолчали.
Мы запускаем цикл статей в которых подробно расскажем о каждой профессии через опыт людей. В первом выпуске обсуждаем Python-разработчиков.
Кхм, а ничего, что не существует такой профессии?
Профессия называется инженер-программист. А инженер-программист, владеющий только одним языком программирования, — это примерно как столяр, который только одним видом пилы умеет пользоваться.
Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.
Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
Про унарный оператор
~v0s меня уже опередил. С этим как раз ничего менять не пришлось бы. Технически бинарный оператор^добавить то можно, но вряд ли одному символу станут придавать настолько разный смысл в зависимости от кол-ва операндов.А
x?.по мне всё равно дико смотрится, особенно для тех, у кого есть опыт работы с Ruby, где существует совершенно логичная конвенция, чтоx?всегда возвращает boolean, ну типаactive?вместоisActive. Думаю, всё равно в итоге нормальную Maybe монаду завезут и эти? после x станут deprecated.Хз, зависит от условий конкретной стажировки. Может и можете. Я просто к тому, что если у человека 0 лет опыта работы, то лучше написать что и как долго он изучал, чем ничего не написать.
Ну так в резюме и пишут опыт работы в годах. Но тут то речь о стажировке и первом потенциальном месте работы, так что можно писать, что угодно (просто для информации).
Да фичи то ещё ладно, а вот синтаксис для них они выбирают какой-то слишком странный.
В
MiddleName?[0]знак вопроса ни к селу, ни к городу, семантики никакой. Сделали бы просто, что для переменной Nullable-типа вызов любого метода возвращает null обёрнутый в Nullable-тип возврата, если в самой переменной был null.^0как автор в статье написал, лучше бы для возведения в степень использовали.А тут можно было бы
~0Зачем для этого вообще отдельный термин? Это же самый обычный паттерн-матчинг с нормальной деконструкцией и биндингом сматченных значений в переменные.
Можно было бы обозвать "Pattern matching restrictions have been eased."
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю:
sendMsg ({куда}, {сообщение});Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
Точнее, он определил диапазон:
223/71 < π < 22/7
Если для него взять среднее, то получится 3.1418511
В статье же есть намёк на методику расчёта. Получается от $100 млн.
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.
Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.
В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?
Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.
Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
И что?
Нет.
Любой. Any Data.
Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.
Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA (неужели это кто-то до сих пор использует?). Они все нафиг не нужны, когда у вас есть ООП на базе классического определения.
Если у вас есть ООП — у вас уже есть клиент-серверное программирование. Если его нет, то у вас нет и ООП. Вот цитата с OOPSLA 1997:
"So this is an early insight that objects basically are like servers. This notion of polymorphism, which used to be called generic procedures is a way of thinking about classes of these servers. Everybody knows about that."
Только задумайтесь, 22 года назад все знали, что объекты должны играть роль минисерверов. А сейчас приходится это разжёвывать.
Много чего есть… Можете ознакомиться: https://en.wikipedia.org/wiki/Programming_paradigm
Но если хотите предметно поговорить про ООП, то сначала ознакомьтесь с этой частью:
Actor-based OOP (ближе всего к классическому ООП)
Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.
P.S. Почитайте статью, которую вы упустили из виду.
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
И тем не менее, ни одна из этих профессий не ограничивается знанием Python.
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
Да вроде Embarcadero ещё жива, и буквально полгода назад свежий релиз Delphi был.
Lazarus опять же есть. Так что поучиться есть на чём.
Потому что это специализация по сфере деятельности. Невозможно одинаково хорошо владеть и веб-разработкой, и мобильной, и разработкой под встраиваемые устройства, и т.д. Но даже внутри одной специализации вам всё равно необходимо знать несколько языков.
Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
Ну, я не стал в очередной раз по бедной букве Ё проходиться )))
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
Ага, даже интересно посмотреть на такого кадра, который возьмёт на позицию мидла человека с резюме "в течение года учил Python на курсах".
Я понимаю, что пост — реклама Geekbrains, но нельзя же настолько топорно впаривать.
Вот ещё фееричный пассаж:
Это из серии: в русском языке всего 33 буквы, то есть чтобы их выучить достаточно потратить один-три дня. Про то, что это никак не связано с умением выражать свои мысли на языке и вообще неважно сколько там функций и зарезервированных слов, почему-то умолчали.
Кхм, а ничего, что не существует такой профессии?
Профессия называется инженер-программист. А инженер-программист, владеющий только одним языком программирования, — это примерно как столяр, который только одним видом пилы умеет пользоваться.