Работа не является функцией или назначением человека. Работа - это всего лишь инструмент выживания. Считать человека инструментом... ну, этически неверно. Нас стараются превратить в инструменты, заставить почувствовать себя инструментом и ИИ - один из способов это сделать. И именно свобода воли - это и есть принципиальное отличие. Человек всегда может поступить в соответствии со своими желаниями - невзирая на последствия. Животное - не может. Молоток - не может... В противном случае мы превратимся в муравьёв - четко организованную иерархическую структуру, где шаг вправо-влево - расстрел. И спустя какое-то время безропотно вымрем, не выдержав изменений среды...
Какой именно статистики? Самая непосредственная оценка является относительной, другие оценки будут неминуемо косвенными... Об этом я и написал...
Я к ЕГЭ отношусь спокойно (наверное потому, что живу в другой стране - у нас тут другие немного фишки, психотест называется 🙂), считаю, что с точки зрения объективности для каждого конкретного ученика это лучше, чем старая система экзаменации. Но это же не значит, что недостатков нет 🙂. А вот про относительность оценки ЕГЭ я просто не знал...
Предъявлять претензии ЕГЭ за подстройку под уровень реальных знаний по меньшей мере нелогично.
Тем не менее, это, пожалуй, самый большой минус - то есть, по результатам ЕГЭ нельзя судить о динамике уровня образования в стране с течением времени. Возможно, конечно, для этого применяются другие инструменты, но они, скорее всего, имеют косвенный характер...
ну есть она, как она помешает какой нибудь из имеющихся у конкретного человека модели - быть ограниченной?
"Она" - свобода воли? Она никому никак не помешает. Она отделяет субъекта от объекта. Делает различие между человеком и инструментом принципиальным. Ограниченность какого-то конкретного человека не означает, что человека можно взять и заменить пассатижами на основании того, что пальцами гвозди из досок невозможно выдирать. У человека, в отличие от пассатижей нет предназначения, каким бы дауном или тупым с чьей-то точки зрения он ни был.
люди уже всей этой ерундой страдают, и без дополнительных искусственных языковых моделей. Вероятно именно потому, что сами представляют из себя языковые модели невысокой точности.
Нельзя сравнивать человеческий разум и какие-то модели, пусть и языковые и большие. У человека есть такая вещь, как свобода воли. Мы сами ставим себе цели, ищем пути и строим инструменты для их достижения (в том числе и ЯМ, какими совершенными они бы не были). У человека нет и не может быть назначения. В противном случае мы из субъектов превратимся в объекты и история цивилизации на этом закончится.
"— Антропоцентрист, — сказал Витька с отвращением.
Хорошо и внятно написано... Одна из главных проблем AI - то, что это некоторая математическая формула, в которой проходит большое количество итераций с использованием ранее вычисленных значений.
По идее, AI должен прийти к выводу, что бессмысленно заниматься изучением Природы, поскольку всё, что "нужно" уже есть или может быть вычислено из имеющейся базы данных. Напоминает Выбегалловского "исполина духа", который вместо невероятного духовного и физического роста тупо прибирает к рукам всё до чего успевает дотянуться, а потом "сворачивает пространство" и "зацикливает время"... Нечто похожее есть и у Азимова в "Основании", где в Империи задачей ученого считается только изучение ранее накопленных знаний, в результате чего знания начинают искажаться, исчезать, игнорироваться и превращаться в инструмент для манипуляций Человечеством.
Учиться надо у Кристобаля Хунты, который считает бессмысленным поиск решения, если известно, что оно есть. "Цель - ничто, поиск - всё".
Непосредственно волшебные слова, о которых вы говорите, были созданы для одной задачи – продаж консультационных услуг большим корпоративным заказчикам в США.
Разве? При чём тут консультационные услуги? Проведите эксперимент - прочитайте описание, что такое "канбан" в Вики на русском языке и на английском. Разница просто удивительная. На английском - всё более-менее понятно, на русском - написана какая-то невнятная хрень... И это при том, что английский текст я читал по диагонали, а в русский пытался вчитываться. Я замечал эти вещи не один и не два раза по самым разным статьям и описаниям. И не только в Вики (ну, конечно, моветон же ж). Вообще, есть принцип - "чтобы делать отличные велосипеды, нужно их изобрести". Просто переносить все эти методологии, изобретенные когда-то в других производственных культурах для совершенно конкретных и, зачастую, очень простых нужд на чужую почву механически нельзя - они не заработают...
В любой решаемой задаче есть контекст в рамках которого вы должны её решать. В данном случае человек пришел на собес по программированию (чего он, кстати, не написал 🙂). Не по химии, не по биологии, не по философии - понятно, что это некоторая математическая задача, в рамках которой объекты задачи представляют собой идеализированные в рамках контекста параметры (мыши не умирают иначе, как от яда, независимо от концентрации, пробирка с ядом или с водой - это не разделяемые сущности, ничего никуда не надо переливать, время на подготовку решения и прочие манипуляции не считается и т.д.). С точки зрения математики условие задачи сформулировано полностью и там ничего не надо придумывать. Спойлеры приведенные автором - это просто подсказки читателям с целью не напрягать их мозг - на собеседовании такие подсказки не нужны.
Ну а претензия на полноту формулировки задач не должна противоречить принципу краткости - любая задача должна содержать только необходимые и достаточные условия для её решения в предложенном контексте...
То есть, речь не о "реальной жизни". Кстати, в примере с кастрюлей компота вы ошиблись в тексте - написали, что из-за конвекции нужно класть лёд "подо дном" - на самом деле, на крышку, ибо холодная жидкость опускается на дно и, благодаря этой самой конвекции процесс остывания проходит быстрее. И задача для школьника в этом случае подразумевает именно этот вопрос, а не то, на сколько заполнена кастрюля а иначе придется описывать слишком сложные процессы теплопередачи в стенках кастрюли и крышки, невозможность закрыть крышку без зазора и прочую чепуху, совершенно лишнюю в этом вопросе (это, кстати, вообще не задача, а вопрос на знание теории).
На мой взгляд дихотомия на "инженеров" и "барыг", особенно на примере SpaceX и Boeing, неправильна. Кто-то хочет сказать, что крупные исторические корпорации, как Боинг, Локхид, ИБМ и прочие - это "барыги", а SpaceX - "инженеры"?! Да это одни и те же барыги, просто есть "барыги зажравшиеся", а есть "голодные". И компании типа SpaceX - "барыги голодные" или "новые барыги"...
Если честно, чепуха там написана про классы... Если так упрощённо это всё представлять, то класс - это просто структура, содержащая, кроме полей данных ещё поля ссылок на код, обрабатывающий эти и другие данные. И тогда непонятно, зачем вся возня с ними. Понятие класса нельзя описывать вне контекста ООП.
"Имя является обязательным" - а почему? То есть, описывается не "кот вообще", а именно домашний кот, имеющий кличку. И вот тут можно было бы развить описание с точки зрения именно ООП-подхода - уровни абстракции, выделение интерфейсов, наследование, инкапсуляция, полиморфизм и прочее :). А так получилось просто очередное, довольно банальное описание полей и методов, где непонятно, для чего это всё громоздится... То есть, в чём смысл-то? Расписать класс "Кот" из книжки Буча? Это он там разбирал кота по косточкам.
Когда я читаю про все эти шаблоны управления, я не могу понять одного - столько умных людей пишут тонны умных статей про то, как надо управлять процессами на различных предприятиях. При этом в экономике (судя по другим статьям) дела, мягко говоря, не ахти. Сороконожка даже не столько пытается идти, сколько увлечена процессом пересчитывания ног и пальцев на них... Всё-таки, нужно сначала научиться заниматься делом, как таковым, а все эти паттерны управления использовать только там, где они реально могут что-то улучшить. Слишком много болтовни на тему "Как нам реорганизовать рабкрин"...
99 процентов людей эту статью не поймут вообще - все эти волшебные слова (agile, scrum, канбан) в конкретных условиях выглядят, как заклинания в мире, лишённом магии. Они были придуманы для другого мира, других пространств, заполненных чужими законами, традициями и обычаями, поэтому и не работают, а превращаются в своего рода религию...
"Богатое государство" не означает "богатые граждане"
Коммунистических государств в истории пока не было. И КНР и СССР - социалистические государства со смешанной, в той или иной степени, экономикой. В СССР, например, на всём протяжении его истории существовали кооперативные и различные коллективные формы собственности (артели, товарищества). Да и с колбасой не всё так однозначно, как некоторым сейчас кажется - я застал времена советских магазинов, под завязку забитых продовольственными и промышленными товарами - той же колбасой. И пропало это всё не из-за идеологии, как таковой...
А кто мешает использовать модули? И хранимые процедуры?
Так о них и речь - думаете, это что-то меняет?... Вместе с тысячестрочными процедурами... Просто, чтобы это всё правильно использовать, нужно худо-бедно заниматься проектированием - а кто там об этом думает, когда надо быстро и вчера? Проект начинали, грубо говоря, два человека - DBP и DBA (database programmer и database administrator)...
Кстати Oracle Pl/sql поддерживает объекты и работу с ними
Ну, это ещё не объектно-ориентированный, а, скорее, чисто объектный подход... В общем, в PL/SQL нет полной парадигмы, так, что-то похожее накручено. И снаружи этим не воспользуешься (из Oracle Forms, скажем)
Похоже писали чтобы было и прибивали гвоздями.
Не, ну так о том и речь - оно и есть... до сих пор, причём двенадцать лет это я только наблюдаю, а сам проект больше двадцати лет существует... Я в своё время пытался спросить "вы чё делаете?" На меня смотрели (и до сих пор смотрят), как на идиота, который ничего не понимает в fast stupid programming (а я действительно не понимаю). Но дело ещё в том, что сам процедурный подход стимулирует такой стиль.
У каждого подхода есть свои канделябры - просто каждый, отдельно взятый разработчик выбирает свой метод освещения...
Я на протяжении 12 лет наблюдаю жизнь PL/SQL кода в одной системе.
"Сделайте вот это!" "Ща, пять минут!"
Через два месяца "Чего-то данных не видно!" Через пару часов "Блин, бажина, надо чинить, дописывать" Через два дня "Вроде работает"
Через полгода "У нас появился новый клиент, у него всё то же самое, только чуть-чуть по другому" "Напишем IF..." Через месяц "Не, нужно отдельную процедуру лепить, Ctrl-C/Ctrl-V"
Через пару месяцев "Блин, у нас тут, оказывается, в самом начале баг - нужно всех клиентов править" "Ёлки, у всех по-разному написано...'
Через три года "Нужно после процедуры сохранять всё в истории". Через два месяца "Чё та в историю не всё попадает..."
Через двенадцать лет. "Процедура длиной в четыре тысячи строк? Да вы ох...ты боже мой..." "А они что, у каждого клиента в схеме разные?" "Да нет, там разница небольшая - ты на IF'ы смотри!"
Есть два подхода (ИМХО) к решению задач - системный и последовательный. Последовательный - когда человек, видя перед собой задачу, садится и начинает описывать последовательность действий, которая приводит его к решению, по пути перед ним встают сопутствующие задачи, которые он также описывает в виде неких последовательностей...
Системный подход - когда задача сначала подвергается декомпозиции (разбиению на простые сущности, слабо связанные между собой), анализу - для выявления связей между сущностями и синтезу в виде создания формального аналога исследуемой задачи в целевом диапазоне входных-выходных параметров. ООП - это способ (или метод) описания таких задач программным способом без необходимости разворачивать это всё в последовательное решение. Всякие там особенности ООП - это просто технология конкретного метода. Не нравится? Да решайте вы свои задачи как хотите и можете. Только не проклинайте потом всех вокруг, когда понадобится что-то решительно изменить, от чего-то решительно избавиться, а что-то решительно добавить...
Сложность задачи - величина постоянная и она не зависит от метода её решения. Сложность решения - величина переменная и она, как раз, зависит от его (решения) метода...
Это все вообще без особых проблем перекладывается на чистый С (без ++)
Первый компилятор с С++ просто переводил текст в С и компилировал его компилятором С. Любая корректная программа на любом языке может быть переписана в машинный код. ООП - это не язык...
Ну, для меня базой была книга Гради Буча "Объектно-ориентированный анализ и проектирование...". Там всё довольно просто. И ответ на вопрос "для чего нужно ООП" довольно банален - для борьбы со сложностью (это, скорее, на этапе проектирования), для борьбы с повторяемостью кода (в случае наследования, скажем), для упрощения развития готового продукта (масштабирование, внесение изменений, исправление ошибок)... ООП позволяет решать задачи примерно тем же способом, как это делает мозг - познание через анализ и синтез - это наше всё.
А я не понимаю тех, кто говорит, что ООП - это что-то непонятное, обман и т.п. По-моему, там всё просто и понятно. Просто ООП надо начинать изучать не с изучения каких-то языков, в которых накручено множество инструментов для реализации тех или иных концепций ООП, а с базовых понятий, которых не так уж и много. Понять, что ООП - не способ писать код, а способ решения сложных задач...
Похоже, автор подразумевал шпиндель токарного станка в комплекте с патроном - с большой натяжкой можно уловить некоторое сходство... Ну или он представляет себе посадочный модуль по картинкам в поп-журналах 50-х годов... Но вообще переведено странно. Скажем, у автора в статье вместо "Их капсула упала" написано "Их капсула приводнилась" (splashed down), ну или "плюхнулась", если с юмором переводить :).
Работа не является функцией или назначением человека. Работа - это всего лишь инструмент выживания. Считать человека инструментом... ну, этически неверно. Нас стараются превратить в инструменты, заставить почувствовать себя инструментом и ИИ - один из способов это сделать. И именно свобода воли - это и есть принципиальное отличие. Человек всегда может поступить в соответствии со своими желаниями - невзирая на последствия. Животное - не может. Молоток - не может... В противном случае мы превратимся в муравьёв - четко организованную иерархическую структуру, где шаг вправо-влево - расстрел. И спустя какое-то время безропотно вымрем, не выдержав изменений среды...
Какой именно статистики? Самая непосредственная оценка является относительной, другие оценки будут неминуемо косвенными... Об этом я и написал...
Я к ЕГЭ отношусь спокойно (наверное потому, что живу в другой стране - у нас тут другие немного фишки, психотест называется 🙂), считаю, что с точки зрения объективности для каждого конкретного ученика это лучше, чем старая система экзаменации. Но это же не значит, что недостатков нет 🙂. А вот про относительность оценки ЕГЭ я просто не знал...
Тем не менее, это, пожалуй, самый большой минус - то есть, по результатам ЕГЭ нельзя судить о динамике уровня образования в стране с течением времени. Возможно, конечно, для этого применяются другие инструменты, но они, скорее всего, имеют косвенный характер...
"Она" - свобода воли? Она никому никак не помешает. Она отделяет субъекта от объекта. Делает различие между человеком и инструментом принципиальным. Ограниченность какого-то конкретного человека не означает, что человека можно взять и заменить пассатижами на основании того, что пальцами гвозди из досок невозможно выдирать. У человека, в отличие от пассатижей нет предназначения, каким бы дауном или тупым с чьей-то точки зрения он ни был.
Нельзя сравнивать человеческий разум и какие-то модели, пусть и языковые и большие. У человека есть такая вещь, как свобода воли. Мы сами ставим себе цели, ищем пути и строим инструменты для их достижения (в том числе и ЯМ, какими совершенными они бы не были). У человека нет и не может быть назначения. В противном случае мы из субъектов превратимся в объекты и история цивилизации на этом закончится.
"— Антропоцентрист, — сказал Витька с отвращением.
— Да, — гордо сказал Эдик."
(© Стругацкие "Понедельник начинается в субботу")
Хорошо и внятно написано... Одна из главных проблем AI - то, что это некоторая математическая формула, в которой проходит большое количество итераций с использованием ранее вычисленных значений.
По идее, AI должен прийти к выводу, что бессмысленно заниматься изучением Природы, поскольку всё, что "нужно" уже есть или может быть вычислено из имеющейся базы данных. Напоминает Выбегалловского "исполина духа", который вместо невероятного духовного и физического роста тупо прибирает к рукам всё до чего успевает дотянуться, а потом "сворачивает пространство" и "зацикливает время"... Нечто похожее есть и у Азимова в "Основании", где в Империи задачей ученого считается только изучение ранее накопленных знаний, в результате чего знания начинают искажаться, исчезать, игнорироваться и превращаться в инструмент для манипуляций Человечеством.
Учиться надо у Кристобаля Хунты, который считает бессмысленным поиск решения, если известно, что оно есть. "Цель - ничто, поиск - всё".
Разве? При чём тут консультационные услуги? Проведите эксперимент - прочитайте описание, что такое "канбан" в Вики на русском языке и на английском. Разница просто удивительная. На английском - всё более-менее понятно, на русском - написана какая-то невнятная хрень... И это при том, что английский текст я читал по диагонали, а в русский пытался вчитываться. Я замечал эти вещи не один и не два раза по самым разным статьям и описаниям. И не только в Вики (ну, конечно, моветон же ж). Вообще, есть принцип - "чтобы делать отличные велосипеды, нужно их изобрести". Просто переносить все эти методологии, изобретенные когда-то в других производственных культурах для совершенно конкретных и, зачастую, очень простых нужд на чужую почву механически нельзя - они не заработают...
В любой решаемой задаче есть контекст в рамках которого вы должны её решать. В данном случае человек пришел на собес по программированию (чего он, кстати, не написал 🙂). Не по химии, не по биологии, не по философии - понятно, что это некоторая математическая задача, в рамках которой объекты задачи представляют собой идеализированные в рамках контекста параметры (мыши не умирают иначе, как от яда, независимо от концентрации, пробирка с ядом или с водой - это не разделяемые сущности, ничего никуда не надо переливать, время на подготовку решения и прочие манипуляции не считается и т.д.). С точки зрения математики условие задачи сформулировано полностью и там ничего не надо придумывать. Спойлеры приведенные автором - это просто подсказки читателям с целью не напрягать их мозг - на собеседовании такие подсказки не нужны.
Ну а претензия на полноту формулировки задач не должна противоречить принципу краткости - любая задача должна содержать только необходимые и достаточные условия для её решения в предложенном контексте...
То есть, речь не о "реальной жизни". Кстати, в примере с кастрюлей компота вы ошиблись в тексте - написали, что из-за конвекции нужно класть лёд "подо дном" - на самом деле, на крышку, ибо холодная жидкость опускается на дно и, благодаря этой самой конвекции процесс остывания проходит быстрее. И задача для школьника в этом случае подразумевает именно этот вопрос, а не то, на сколько заполнена кастрюля а иначе придется описывать слишком сложные процессы теплопередачи в стенках кастрюли и крышки, невозможность закрыть крышку без зазора и прочую чепуху, совершенно лишнюю в этом вопросе (это, кстати, вообще не задача, а вопрос на знание теории).
Терпеть? Чего они там терпят?
На мой взгляд дихотомия на "инженеров" и "барыг", особенно на примере SpaceX и Boeing, неправильна. Кто-то хочет сказать, что крупные исторические корпорации, как Боинг, Локхид, ИБМ и прочие - это "барыги", а SpaceX - "инженеры"?! Да это одни и те же барыги, просто есть "барыги зажравшиеся", а есть "голодные". И компании типа SpaceX - "барыги голодные" или "новые барыги"...
Если честно, чепуха там написана про классы... Если так упрощённо это всё представлять, то класс - это просто структура, содержащая, кроме полей данных ещё поля ссылок на код, обрабатывающий эти и другие данные. И тогда непонятно, зачем вся возня с ними. Понятие класса нельзя описывать вне контекста ООП.
"Имя является обязательным" - а почему? То есть, описывается не "кот вообще", а именно домашний кот, имеющий кличку. И вот тут можно было бы развить описание с точки зрения именно ООП-подхода - уровни абстракции, выделение интерфейсов, наследование, инкапсуляция, полиморфизм и прочее :). А так получилось просто очередное, довольно банальное описание полей и методов, где непонятно, для чего это всё громоздится... То есть, в чём смысл-то? Расписать класс "Кот" из книжки Буча? Это он там разбирал кота по косточкам.
Когда я читаю про все эти шаблоны управления, я не могу понять одного - столько умных людей пишут тонны умных статей про то, как надо управлять процессами на различных предприятиях. При этом в экономике (судя по другим статьям) дела, мягко говоря, не ахти. Сороконожка даже не столько пытается идти, сколько увлечена процессом пересчитывания ног и пальцев на них... Всё-таки, нужно сначала научиться заниматься делом, как таковым, а все эти паттерны управления использовать только там, где они реально могут что-то улучшить. Слишком много болтовни на тему "Как нам реорганизовать рабкрин"...
99 процентов людей эту статью не поймут вообще - все эти волшебные слова (agile, scrum, канбан) в конкретных условиях выглядят, как заклинания в мире, лишённом магии. Они были придуманы для другого мира, других пространств, заполненных чужими законами, традициями и обычаями, поэтому и не работают, а превращаются в своего рода религию...
"Богатое государство" не означает "богатые граждане"
Коммунистических государств в истории пока не было. И КНР и СССР - социалистические государства со смешанной, в той или иной степени, экономикой. В СССР, например, на всём протяжении его истории существовали кооперативные и различные коллективные формы собственности (артели, товарищества). Да и с колбасой не всё так однозначно, как некоторым сейчас кажется - я застал времена советских магазинов, под завязку забитых продовольственными и промышленными товарами - той же колбасой. И пропало это всё не из-за идеологии, как таковой...
Так о них и речь - думаете, это что-то меняет?... Вместе с тысячестрочными процедурами... Просто, чтобы это всё правильно использовать, нужно худо-бедно заниматься проектированием - а кто там об этом думает, когда надо быстро и вчера? Проект начинали, грубо говоря, два человека - DBP и DBA (database programmer и database administrator)...
Ну, это ещё не объектно-ориентированный, а, скорее, чисто объектный подход... В общем, в PL/SQL нет полной парадигмы, так, что-то похожее накручено. И снаружи этим не воспользуешься (из Oracle Forms, скажем)
Не, ну так о том и речь - оно и есть... до сих пор, причём двенадцать лет это я только наблюдаю, а сам проект больше двадцати лет существует... Я в своё время пытался спросить "вы чё делаете?" На меня смотрели (и до сих пор смотрят), как на идиота, который ничего не понимает в fast stupid programming (а я действительно не понимаю). Но дело ещё в том, что сам процедурный подход стимулирует такой стиль.
У каждого подхода есть свои канделябры - просто каждый, отдельно взятый разработчик выбирает свой метод освещения...
Я на протяжении 12 лет наблюдаю жизнь PL/SQL кода в одной системе.
"Сделайте вот это!" "Ща, пять минут!"
Через два месяца "Чего-то данных не видно!" Через пару часов "Блин, бажина, надо чинить, дописывать" Через два дня "Вроде работает"
Через полгода "У нас появился новый клиент, у него всё то же самое, только чуть-чуть по другому" "Напишем IF..." Через месяц "Не, нужно отдельную процедуру лепить, Ctrl-C/Ctrl-V"
Через пару месяцев "Блин, у нас тут, оказывается, в самом начале баг - нужно всех клиентов править" "Ёлки, у всех по-разному написано...'
Через три года "Нужно после процедуры сохранять всё в истории". Через два месяца "Чё та в историю не всё попадает..."
Через двенадцать лет. "Процедура длиной в четыре тысячи строк? Да вы ох...ты боже мой..." "А они что, у каждого клиента в схеме разные?" "Да нет, там разница небольшая - ты на IF'ы смотри!"
Ну, вы меня поняли... Схематичненько так...
Есть два подхода (ИМХО) к решению задач - системный и последовательный. Последовательный - когда человек, видя перед собой задачу, садится и начинает описывать последовательность действий, которая приводит его к решению, по пути перед ним встают сопутствующие задачи, которые он также описывает в виде неких последовательностей...
Системный подход - когда задача сначала подвергается декомпозиции (разбиению на простые сущности, слабо связанные между собой), анализу - для выявления связей между сущностями и синтезу в виде создания формального аналога исследуемой задачи в целевом диапазоне входных-выходных параметров. ООП - это способ (или метод) описания таких задач программным способом без необходимости разворачивать это всё в последовательное решение. Всякие там особенности ООП - это просто технология конкретного метода. Не нравится? Да решайте вы свои задачи как хотите и можете. Только не проклинайте потом всех вокруг, когда понадобится что-то решительно изменить, от чего-то решительно избавиться, а что-то решительно добавить...
Сложность задачи - величина постоянная и она не зависит от метода её решения. Сложность решения - величина переменная и она, как раз, зависит от его (решения) метода...
Первый компилятор с С++ просто переводил текст в С и компилировал его компилятором С. Любая корректная программа на любом языке может быть переписана в машинный код. ООП - это не язык...
Ну, для меня базой была книга Гради Буча "Объектно-ориентированный анализ и проектирование...". Там всё довольно просто. И ответ на вопрос "для чего нужно ООП" довольно банален - для борьбы со сложностью (это, скорее, на этапе проектирования), для борьбы с повторяемостью кода (в случае наследования, скажем), для упрощения развития готового продукта (масштабирование, внесение изменений, исправление ошибок)... ООП позволяет решать задачи примерно тем же способом, как это делает мозг - познание через анализ и синтез - это наше всё.
А я не понимаю тех, кто говорит, что ООП - это что-то непонятное, обман и т.п. По-моему, там всё просто и понятно. Просто ООП надо начинать изучать не с изучения каких-то языков, в которых накручено множество инструментов для реализации тех или иных концепций ООП, а с базовых понятий, которых не так уж и много. Понять, что ООП - не способ писать код, а способ решения сложных задач...
Похоже, автор подразумевал шпиндель токарного станка в комплекте с патроном - с большой натяжкой можно уловить некоторое сходство... Ну или он представляет себе посадочный модуль по картинкам в поп-журналах 50-х годов... Но вообще переведено странно. Скажем, у автора в статье вместо "Их капсула упала" написано "Их капсула приводнилась" (splashed down), ну или "плюхнулась", если с юмором переводить :).