Один из терминов, который привел меня в замешательство, - это «парадигма». Слишком долго я смешивал парадигму и реализацию и думал, что это одно и то же. Или, может быть, я никогда не думал, что это могут быть разные вещи.

Так было до тех пор, пока я не наткнулся на попытку понять DCI. Конечно, я был заинтригован и хотел понять это, но я продолжал спотыкаться о мелочах, и люди продолжали говорить мне, что я был неправ, невежественен и не понимал вещей должным образом. Ощущение, которое у меня возникло, было замешательством, гневом, раздражением и множеством других чувств, но я просто хотел использовать DCI.

Одно дело, когда случайные люди в Интернете называют вас невежественным, мне все равно. Конечно, когда такие люди, как Трюгве Реенскауг и Джеймс Коплиен, говорят Вы не понимаете ООП и Вы упускаете суть - это полностью другое дело. Тогда вы не можете просто отмахнуться от заявлений, вы должны отнестись к ним серьезно и провести исследование и прочитать статьи.

Они не говорили об этом злобно, и приведенные здесь утверждения перефразированы. Для смены парадигм нет простого пути, и вам нужно приложить усилия. Я хотел получить «быстрый ответ», но не так можно понять. Кроме того, да, слово «невежественный» было наиболее подходящим словом.

Я много спотыкался. И я могу проследить это до одной вещи, в частности

парадигма

Как в «DCI Парадигме» и «Объектно-ориентированной парадигме». Я понимал реализацию DCI и OO, но не понимал парадигму. Словарные определения этого слова тоже не помогли.

Так что же такое парадигма, спросите вы?

На самом деле есть лучший вопрос для понимания этого:

Почему сложно программировать на ассемблере?

В сборке есть много мест, где можно ошибиться, но следовать коду и его действиям довольно просто. Каждая строчка делает что-то очень простое.

Основная трудность заключается в том, чтобы воплотить наши мысли в сборку. Когда требуются изменения, нам нужно реконструировать некоторые мысли из сборки, изменить наши идеи и повторно воплотить их в сборку.

Есть существенная разница в том, как мы думаем и как работает машина. Первые языки, в том числе ассемблер, были разработаны, чтобы упростить перевод в машинный код. Они заменили несколько регистров «неограниченным» количеством переменных, которые помогали запоминать, что и где, поэтому вы могли использовать lineBuffer вместо 0x000180F4.

Это сгладило разрыв между людьми и компьютерами. Однако с увеличением размера программы все еще остаются проблемы. Есть так много разных мыслей и идей, что мы должны начать систематизировать свои мысли. Вот где появляется «парадигма»:

Изначально, наверное, произошло неформально, люди начали рисовать диаграммы кода. Со временем эти концепции стали более строгими и определены в такой классике, как О критериях, которые будут использоваться при декомпозиции систем на модули Дэвида Парнаса ».

Например, я мог бы разработать модули «Ввод», «Круговой сдвиг», «По алфавиту», «Вывод» и «Главный контроль». Идея «модулей» упорядочила наши мысли, и нам легче рассуждать о ней. Но наши мысли с таким же успехом можно было бы «читать из файла каждую строку, сохранять их где-нибудь и распечатывать результат», что могло бы сработать, но пострадала бы ясность.

Парадигма - это то, как мы рассматриваем и анализируем предмет.

Конечно, на практике граница между «реализацией» и «парадигмой» часто нечеткая. Даже в той степени, в которой парадигма может быть определена с точки зрения деталей реализации.

Очевидно, что нет лучшего способа думать обо всем, это было бы абсурдно, но есть несколько разных способов. Эти различные способы организации нашего мышления порождают парадигмы, которые у нас есть - поток данных, логика, основанный на ограничениях, императивный, функциональный, ориентированный на данные, объектно-ориентированный, ориентированный на классы, ориентированный на роли, и это лишь некоторые из них. Должно быть очевидно, что они не исключают друг друга и что некоторые из них еще предстоит изобрести.

Языки и парадигмы

Теперь, когда мы отделили парадигму от реализации, интересно подумать, что означает вопрос «Является ли Go объектно-ориентированным языком?» значит. Или как к ним относятся многопарадигмальные языки, такие как C ++.

Я думаю, что главная проблема в том, что сам вопрос основан на неверной предпосылке. Он по-прежнему предполагает, что «парадигмальность» является неотъемлемым свойством языка. Когда мы разделим их, идеи будет намного легче понять.

Лучше спросить: «Насколько хорошо Go поддерживает объектную ориентацию?». Для наблюдателя эти вопросы могут выглядеть одинаково ... но давайте также спросим: «Насколько хорошо Go поддерживает функциональное программирование?» Или «Насколько хорошо Go поддерживает логическое программирование?»…

Это гораздо более интересные вопросы - эти вопросы требуют понимания того, что такое «парадигматический образ мышления».

По сути, мы спрашиваем: «Насколько сложно воплотить парадигму в конкретной реализации». или «Насколько хорошо языковой код представляет нашу ментальную модель».

Интересно отметить, что существует несколько способов перевести парадигму в код. Вы даже можете написать объектно-ориентированный код на ассемблере, однако перевод потребует значительных усилий. Вот почему мы не называем ассемблер объектно-ориентированным языком, но можем писать объектно-ориентированный язык на ассемблере.

Это правда, что некоторые языки были разработаны с учетом какой-то парадигмы, но из-за необходимости разделить ментальную модель и компьютер мы всегда оставляем некоторые части незаметными при реализации.

Несоответствие парадигме

Также есть интересный случай, когда наша ментальная модель не соответствует «языковой парадигме». Например, когда вы пишете высокопроизводительный код, вам необходимо смоделировать то, что делает машина:

Наш язык усложнил реализацию. Теперь нам нужно смоделировать машину, затем перевести на язык высокого уровня, а затем попытаться угадать, во что переводится код высокого уровня.

Вы увидите похожие несоответствия, когда попытаетесь использовать функциональный язык с императивной парадигмой. Или, если вы попытаетесь написать функциональный код на языке, предназначенном для объектно-ориентированного программирования. Или попробуйте передать сложные математические уравнения с помощью Scratch.

Когда мы принимаем во внимание клиентов, деловых людей, конечных пользователей, экспертов в предметной области, программистов, интерфейсных разработчиков, back-end разработчиков, картина становится еще более сложной:

Нам нужно беспокоиться не только о том, как мы думаем, но и о том, как мы общаемся, как мы думаем, о том, как думают другие, как они говорят о своих мыслях, как я интерпретирую их мысли, как я представляю свои идеи и т. Д.

Попытка сгладить переход между различными ментальными моделями приводит к появлению разных способов разработки программного обеспечения (например, DDD).

Чем крупнее перевод на каждом этапе, тем больше вероятность ошибок и недоразумений. С другой стороны, некоторые мысли лучше продуманы и реализованы определенным образом.

Перспектива оценивается в 80 баллов IQ. - Алан Кей

В любом случае,

предполагая, что вы работаете с X, тогда:

  • Как лучше всего думать и общаться о X?
  • Поддерживает ли ваш язык такой образ мышления?
  • Все участники думают, что это лучший способ думать об этом?

Как обычно, парадигмы сводятся к компромиссам. Парадигма облегчает размышление о некоторых вещах, и, как следствие, некоторые другие вещи становятся более сложными.

Все модели неправильные, но некоторые полезны. - Джордж Бокс

Сделав шаг вперед, «Некоторые модели лучше других в определенной ситуации».

Хорошо подумать о том, как мы думаем, это может дать существенное представление о том, как мы делаем то, что мы делаем. Я оставлю свой анализ парадигм на другой раз.