З точки зору фізики, фільм один великий косяк, але це взагалі неважливо.
Фільм про відносини, а не про фізику. Тому не треба цим псувати собі враження від фільму.

Фільм місцями смішний, але це точно не комедія. Рекомендую для перегляду.

Про те і мова, ці обмеження виключно на рівні уявлень окремої людини. Навчитесь думати по різному, у вас буде більше можливостей в рамках наявних інструментів. Ось наприклад, github.com/cedardb/DOOMQL — DOOM на SQL :)

У статті ці підходи стоять поруч не тому, що вони однакові, а тому, що це різні способи мислення при розв’язанні задач — виражені у формі функцій, конфігурацій чи SQL-запитів.
Функціональний і декларативний підходи мають різну природу, але обидва можуть використовуватись для розв’язання конкретних задач, тому логічно розглядати їх поруч у контексті еволюції підходів до програмування.

Щодо статистики використання мов. Деякі мови програмування зручніші для певних парадигм, тож я допускаю що популярність мов відображає популярність відповідних способів мислення.

Мій особистий досвід, звісно, не статистика, але здебільшого бачу імперативний стиль, далі — об’єктний, а функціональні чи декларативні елементи застосовуються точково для окремих задач.

Якщо у вас є об’єктивніші джерела чи дослідження — з цікавістю почитаю.

Киньте пожалуйста ссылку на то, где можно почитать про такую классификацию естественных языков. о гипотезе лингвистической относительности я знаю, а вот классификации обьектные, ... (какие еще?) не встречал.

Дякую за змістовний і детальний коментар!

Коли я говорю про історію парадигм чи технологій, то маю на увазі не момент їхньої появи, а момент поширення — коли ідея стала масовою.
Аналогічно з книгодрукуванням: можливість друкувати існувала задовго до Гутенберга, але саме його верстат започаткував епоху широкого використання друку, тому від нього й ведемо відлік.

Щодо процедурного програмування — згоден, сама ідея з’явилася раніше. Мова C лише зробила її більш практичною та зручною для масового використання. GOTO ніхто й сьогодні не забороняє, але його застосування — радше ознака поганого стилю, ніж інженерної необхідності.

Стосовно ООП — тут справді холіварна тема. Особисто я орієнтуюсь на поширене трактування ООП у сучасних мовах, де головний акцент — на наслідуванні як інструменті повторного використання коду. У цьому сенсі розробників можна умовно поділити на тих, хто вміє ефективно працювати з наслідуванням, і тих, хто його хейтить.

Щодо Go — повністю погоджуюсь: відсутність наслідування справді призводить до дублювання логіки.

Коли ми говоримо про технології, не можна відривати їх від людського фактору. Популярність часто визначає не лише технічна доцільність, а й маркетинг.
Достатньо згадати, що компанія Sun Microsystems витратила близько 500 мільйонів доларів на просування Java у перші роки її існування.

Загалом, стаття не про процедури чи класи, скільки про те, що, навчившись мислити по-різному й розуміти різні варіанти розв’язання задач, розробник отримує змогу вибирати найбільш оптимальний підхід у конкретній ситуації, незалежно від мови програмування.

Якраз про це й ідеться — складність (згідно попереднього визначення ) не є абсолютною характеристикою системи, а залежить від того, хто і як із нею працює.
Наприклад, зрозуміти код стає простіше, якщо його просто підсвітити різними кольорами — як це роблять сучасні IDE. Сама система при цьому не змінюється, але розробнику працювати з нею легше.

Метрики — це лише спроба об’єктивізувати те, що насправді впливає на розуміння людини.
Тож мій контекст — не «я так бачу», а усвідомлення того, що програмна система складна настільки, наскільки складно її зрозуміти й змінити.

В контексті розробки ПЗ важливо наскільки ви гарно розумієте код та систему в цілому, для того щоб мати можливість її змінювати і розвивати.

Тому говорячи про складність я і беру контекст розробника. Один розробник гарно знає систему, для нього система не складна. Інший, наприклад тільки почав з проектом працювати, і тому реалізація логіки у нього може викликати труднощі. Система одна, але для різних розробників вона по різному складна.

Звісно чим більше файлів, зв’язків, методів, і т.д. тим важче для розробника буде зрозуміти програмний проект. На основі цих артефактів можна порахувати метрики складності, і скоріше за все при збільшенні значень метрик буде зростати розумове навантаження програміста.

Тому, якщо брати ваш приклад, то так, система з 10ох елементів скоріше за все буде складнішою для розуміння за систему з 2ох.

Метрики складності коду корелюють з розумовим напруженням розробника який має справу з кодом. Тому рахувати метрики і намагатись їх зменшити корисна штука.

Ось вам задача:
У системі соціальної мережі великого розміру потрібно визначити, чи пов’язані між собою два користувачі ланцюжком знайомств будь-якої довжини, та за потреби визначити послідовність користувачів, через яких проходить цей зв’язок.
Порівняйте рішення на основі Postgres та Neo4j по простоті рішення і часу відповіді.

Щоб відповісти на це запитання, спершу треба визначити, що таке складність.
Складність — це не властивість системи сама по собі, а когнітивне навантаження, яке виникає, коли ми стикаємось із проблемою (детальніше — у посиланні наприкінці статті).

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

Спочатку, коли ви опановуєте нові інструменти чи підходи, дійсно здається, що стає складніше. Але коли застосовуєте їх у реальних задачах, рішення стають простішими — для вас і для команди.

Наприклад, DDD пропонує створити спільну мову проєкту — це може виглядати складно на старті, зате пізніше значно спрощує спілкування в команді й зменшує непорозуміння.
Так само й обмежені контексти: їх важко визначити спочатку, але працювати в межах чітко окресленого контексту набагато легше, ніж у хаосі всього проєкту.

Спробую пояснити на прикладі. Уявіть, що ви проєктуєте нову систему й обираєте базу даних, яка найкраще відповідає задачі.
Для соціальної мережі логічно взяти графову БД — вона природно відображає зв’язки між користувачами. Для CRM, швидше за все, зручніше реляційна БД, де дані організовані у таблицях. А для системи аналітики поведінки користувачів — колонкова, як-от Redshift.

Так само і з парадигмами: одну й ту саму логіку можна реалізувати по-різному, і кожен підхід має свої сильні сторони. Ваш код може бути зрозумілішим, ефективнішим або лаконічнішим — залежно від того, наскільки вдало ви обрали підхід до задачі.

Тож питання не у зростанні вимог до розробника, а у розширенні його можливостей і глибшому розумінні інструментів, якими він володіє.

Отсюда следует что язык и способ мышления зависит еще и от архитектуры процессора.

Якщо ви пишете на низькому рівні, то без сумнівів залежить. Проте інструменти, як обгортки дозволяють речі, залежні від архітектури заліза приховати.
Для вирішення практичних задач можна створювати свої «обгортки», інструменти над мовою програмування у вигляді бібліотек, і таким чином спрощувати опис задачі.
Гарний приклад UI бібліотеки типу React. Під капотом JS, але бібліотека дає інший спосіб мислення при побудові інтерфейсу. А до процесора ще буде декілька шарів, які дозволяють на його архітектуру не зважати.

Вот я не обнаружил здесь парадигму логического разбора (интерпретаций) язык Пролог.

я робив зауваження, що буду згадувати тільки найбільш розповсюджені. А загалом їх багато.

І дякую за цікавий приклад.

Ваш коментар — гарний приклад різних парадигм мислення 🙂. «Я не побачив сенсу у викладеному матеріалі...»:
— отже, матеріал поганий, бо я найкраще знаю і розумію цей предмет;
— можливо, варто уважніше ознайомитися з контекстом і джерелами, щоб зрозуміти задум автора.
Зрештою, саме вам обирати той підхід, який видається більш конструктивним і корисним особисто для вас.

Тоді буду вдячний за конструктивні зауваження. На жаль, ваша порада занадто лаконічна, щоб навколо неї можна було вести дискусію.

Схоже, ви зупинилися на заголовку і не читали саму статтю.

Анекдот гарний, але не про те. :) Наведу приклади «способів мислення», щоб ідея була зрозумілішою:

— У процедурному стилі ми мислимо послідовністю інструкцій: зроби А, потім Б, потім В.
— В ООП ми уявляємо систему як об’єкти, що взаємодіють між собою.
— У ФП ми розкладаємо задачу на чисті функції, які можна комбінувати.
— У декларативному стилі ми формулюємо не як робити, а що хочемо отримати.

Парадигма програмування — це спосіб мислення і підхід до побудови програм, який визначає, як формулюються задачі та як організовується код для їх розв’язання.

Різні способи мислення дійсно існують :)
А інструменти більшою чи меншою мірою дозволяють реалізувати на практиці те, що ви напроєктували, виходячи зі свого способу мислення.

Стаття про те, що треба використовувати ту парадигму, яка в даних умовах є найбільш доречною. Відповідно, щодо UI потрібно враховувати швидкість і ресурси. Те, що може виглядати доречно з точки зору зрозумілості коду і моделі, на практиці може працювати недостатньо продуктивно або споживати велику кількість ресурсів.
Ідея в тому, що можна розширити свої можливості в межах однієї мови, просто навчившись мислити по-іншому.

Все правильно: заголовок зроблено лише для привернення уваги. Хоча часто зустрічаю (на жаль) проєкти, де ООП радше «мертве», ніж «живе» — навіть там, де воно було б цілком доречним. Те саме з ФП та SQL: щоб отримати від них користь, потрібно не просто використовувати терміни, а справді знати й уміти застосовувати ці підходи.

Ажіотаж навколо мікросервісів — це передусім результат маркетингу хмарних провайдерів. Формується думка, що це «модно, стильно, молодіжно». Коли доходить до практики, у розробників виникає бажання спробувати цей підхід. До того ж мікросервіси легше «продати» бізнесу або замовнику. Дякую автору за адекватну й зважену статтю!
Як і будь-що інше, мікросервіси не є «гарними» чи «поганими» — головне розуміти, коли вони доцільні.