В 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. И это неверно.
По моему, вы просто не совсем понимаете что такое R&D, возможно просто не сталкивались с проектами на старте которых бывает вопросов больше чем ответов но в целом все участники согласны, что все выполнимо в некоей «среднесрочной перспективе».
Вот уже 8 лет только с проектами такого рода и работаю. Для крупных проектов, которые длятся много лет, оценка сроков выстраивается по принципу: какой функционал можно успеть реализовать в ближайшие 3 месяца, месяц, 2 недели.
Само собой, никто не оценивает подобный проект целиком, хотя бы потому что требования к нему поменяются 100 раз в процессе разработки и дальнейшей эксплуатации. Однако ваш начальный тезис "С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности" в корне неверен. Полезные оценки можно давать для проектов любой сложности. Да, это сложнее, чем для типовых. Да, нужен навык и хорошее понимание как предметной области проекта, так и возможностей членов команды разработки. Но тем не менее, это вполне возможно.
R&D естественно делается без оценки, просто итерационно с подведением промежуточных результатов. Однако, фаза R&D всё равно должна проходить достаточно бодро, бизнес не может ждать пока вы там 2 года исследованиями будете заниматься, особенно на старте проекта. В конце концов, сам проект можно декомпозировать и выделить пресловутый MVP.
Короче, давно уже есть работающие практики, как выстраивать работу с приемлемой точностью эстимейтов. Можно зашориться и их не замечать, но бизнес всё равно будет у вас спрашивать сроки. Очень часто тут имеет место ситуация, что если задача слишком объёмная, то её тупо не выгодно даже начинать. Именно для этого нужна оценка в нулевом приближении — понять начинать вообще задачу делать или нет. Если да, то оценка уточняется более детально.
чтобы выяснить, что именно на что в итоге декомпозировать нужно сделать не менее 60% всей работы.
60% по сложности — крайне редко, но теоретически может быть, но по объёму (а соответственно и по временным затратам) 80% работы — это мартышкин труд на любом проекте.
В оценки таких проектов с точностью 20% я не верю абсолютно, ибо еще ни разу в моей практике такие оценщики не попадали в диапазон с кратностью меньше двух.
Ну что тут сказать, набирайтесь опыта. Оценивание — это такой же навык, как и другие, он вполне себе тренируется. Но если вы будете себя ограничивать убеждением, что это невозможно, то для вас это и останется невозможным.
Сложность проекта чаще растёт из-за накопленного технического долга, а не из-за R&D. Если не накапливать кучу этого долга, то всё достаточно просто:
1) выделяется время под R&D
2) результаты анализируются, если они перспективны, но сыроваты, то итерация повторяется ещё раз
3) полученные результаты R&D позволяют весьма точно оценить объёмы и сроки дальнейших работ
Само собой, глупо оценивать задачу, требующую R&D, до проведения этого самого R&D. Справедливости ради, таких задач меньшинство даже на самых сложных проектах.
В большинстве случаев достаточно банальной декомпозиции, чтобы оценить с точностью ±20%.
Справедливости ради, надо сказать, что слова коммуникабельность, комфортабельность, рентабельность входят в литературную норму русского языка довольно давно. И их английское происхождение под большим вопросом, скорее французско-немецкое.
Найдите -абельный в Евгений Онегин.
Довольно странная отсылка, с учётом количества французских слов в данном произведении. Да и кальки из английского там присутствуют, типа денди, ростбиф, etc.
Кстати, почему-то популярно считать, что лауреат Нобелевской премии / профессор Стенфорда/МГУ/etc. априори всегда говорит что-то умное и безусловно верное.
Интересно откуда берётся это заблуждение… Поскольку совершенно очевидно, что абсолютно любой человек, вне зависимости от званий, премий и прочих достижений, временами несёт всякую чушь, а по каким-то вопросам имеет глубокие заблуждения.
В 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. И это неверно.
Вот уже 8 лет только с проектами такого рода и работаю. Для крупных проектов, которые длятся много лет, оценка сроков выстраивается по принципу: какой функционал можно успеть реализовать в ближайшие 3 месяца, месяц, 2 недели.
Само собой, никто не оценивает подобный проект целиком, хотя бы потому что требования к нему поменяются 100 раз в процессе разработки и дальнейшей эксплуатации. Однако ваш начальный тезис "С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности" в корне неверен. Полезные оценки можно давать для проектов любой сложности. Да, это сложнее, чем для типовых. Да, нужен навык и хорошее понимание как предметной области проекта, так и возможностей членов команды разработки. Но тем не менее, это вполне возможно.
R&D естественно делается без оценки, просто итерационно с подведением промежуточных результатов. Однако, фаза R&D всё равно должна проходить достаточно бодро, бизнес не может ждать пока вы там 2 года исследованиями будете заниматься, особенно на старте проекта. В конце концов, сам проект можно декомпозировать и выделить пресловутый MVP.
Короче, давно уже есть работающие практики, как выстраивать работу с приемлемой точностью эстимейтов. Можно зашориться и их не замечать, но бизнес всё равно будет у вас спрашивать сроки. Очень часто тут имеет место ситуация, что если задача слишком объёмная, то её тупо не выгодно даже начинать. Именно для этого нужна оценка в нулевом приближении — понять начинать вообще задачу делать или нет. Если да, то оценка уточняется более детально.
60% по сложности — крайне редко, но теоретически может быть, но по объёму (а соответственно и по временным затратам) 80% работы — это мартышкин труд на любом проекте.
Ну что тут сказать, набирайтесь опыта. Оценивание — это такой же навык, как и другие, он вполне себе тренируется. Но если вы будете себя ограничивать убеждением, что это невозможно, то для вас это и останется невозможным.
Сложность проекта чаще растёт из-за накопленного технического долга, а не из-за R&D. Если не накапливать кучу этого долга, то всё достаточно просто:
1) выделяется время под R&D
2) результаты анализируются, если они перспективны, но сыроваты, то итерация повторяется ещё раз
3) полученные результаты R&D позволяют весьма точно оценить объёмы и сроки дальнейших работ
Само собой, глупо оценивать задачу, требующую R&D, до проведения этого самого R&D. Справедливости ради, таких задач меньшинство даже на самых сложных проектах.
В большинстве случаев достаточно банальной декомпозиции, чтобы оценить с точностью ±20%.
А Вы читали про полемику о старом и новом слоге? В которой Пушкин выступал как раз за "коверкание" русского языка. И в упомянутом выше Евгении Онегине, даже подкалывал лидера любителей русского слова: https://mybook.ru/author/aleksandr-sergeevich-pushkin/evgenij-onegin/citations/261690/
Сейчас то есть, но 200 лет назад это было ничуть не лучше, чем "юзабельность" сейчас.
Справедливости ради, надо сказать, что слова коммуникабельность, комфортабельность, рентабельность входят в литературную норму русского языка довольно давно. И их английское происхождение под большим вопросом, скорее французско-немецкое.
Довольно странная отсылка, с учётом количества французских слов в данном произведении. Да и кальки из английского там присутствуют, типа денди, ростбиф, etc.
Кстати, почему-то популярно считать, что лауреат Нобелевской премии / профессор Стенфорда/МГУ/etc. априори всегда говорит что-то умное и безусловно верное.
Интересно откуда берётся это заблуждение… Поскольку совершенно очевидно, что абсолютно любой человек, вне зависимости от званий, премий и прочих достижений, временами несёт всякую чушь, а по каким-то вопросам имеет глубокие заблуждения.