QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Ужасность ООП и C++. Так ли все на самом деле?

В последнее время, я часто стал натыкаться на посты с высказываниями о том, что C++ и ООП это худшее что ныне существует в мире программирования. Причем, порой подобная критика исходила от именитых гуру, типа Линуса Торвальдса.

Мне захотелось лучше проникнуться этим вопросом и понять, из-за чего многие программисты так ненавидят объектно-ориентированные языки программирования и считают их скорее игрушкой, нежели полезным инструментом. Почему когда встает выбор между разработкой на C или C++, предпочтение скорее отдадут C(например, драйвера, ОС, бд и тд).

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

LinkedIn

Лучшие комментарии пропустить

Ничего ужасного на самом деле нет. Есть очевидные свойства самих механизмов, которые могут стать недостатками в определённых условиях, и есть табун крикунов, которые эти условия выпячивают как тотальное свойство мироздания и после этого обхаивают всё. И ещё есть абьюзинг самих механизмов, который стал нормой в некоторых традициях (кто сказал слово на J?), потому что некоторым авторам нравилась получаемая выразительность.
Но недостатки, которые существенны в 5% случаев, преподносятся крикунами как проблема для 100%, и они очень громко орут.

По поводу ужасности ООП — я продемонстрирую это одной картинкой
i.imgur.com/Q0vFcHd.png

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Функційне програмування фігове з точки зору швидкодії. Справжньою альтернативою ООП є data-oriented programming як entity component system

Только не альтернативой, а еще одним путем, который может жить и в симбиозе с ООП.

ООП, як і будь яка інша методологія програмування, це спроба зменшити прірву (gap) між понятійними базами application та implementation доменів. Якщо application domain — це ядро ОС збудоване без ООП то можна сказати що application та implementation домени співпадають і потреби використовувати ООП немає. Якщо ж application домен — це складна розподілена система з багатьма вузлами і нетривіальним обміном даних — то, як видається, ООП поки що найкраща методологія для таких задач. А коли application домен — модель соціуму то навіть ООП буде «замало».

Ну такое. Если привести аналогию то все эти классы это ящики на складе с задачей все упорядочить, изолировать, добавить модульности. Проблема в том что современные склады очень больших размеров, много ящиков расставлены на полки, много накладных расходов по их обслуживанию. При этом часто бывает открываешь большой ящик а там полезного груза на напёрсток, а то и вовсе нет. И тут дилема. Зачем это все, не проще выбросить этот весь склад и все полезное хранить в кучке которая по размеру в раз 50 будет меньше. Холиворный многогранный вопрос. Некоторые ответы могут шокировать и уходить в плоскость бизнеса аутсорц компаний — больше разработчиков в проекте больше ревенью посредника.

не проще выбросить этот весь склад и все полезное хранить в кучке которая по размеру в раз 50 будет меньше

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

Чем Ctrl+f плох ? Обычно ищут по содержимому а не по наклейкам на коробках. Бывает что классы так называют, что диву даешся как придумали такое название

А дальше что?

Чем Ctrl+f плох ? Обычно ищут по содержимому а не по наклейкам на коробках

Тим, що шукати доведеться не по інтерфейсам, а по реалізації? Довше, важче?

Ок, назови имя класса где используется настройка IsSuperUserAllowed. Или попроще, имя класса который проверяет пермишены, или имя класса есть ли какой-то юзер в базе. В скольки проектах эти классы будут названы одинаково ? Без Ctrl+f в большом проекте делать нечего. А вот про разные Class Explorer знают не все, потомучто можно обойтись

Object-Oriented Programming — The Trillion Dollar Disaster
medium.com/...​r-disaster-️-92a4b666c7c7

А чего так мало? Надо было сразу 18 квинтиллионов (2^64) долларов напророчить. Всё равно никто проверять не будет.

этот текст я уже вижу не один год :)

вот интересно, когда наконец хоть какой-то функциональщик осознает что

чистые функции, иммутабельность, это не достижение ФП. а всего лишь перенос математической нотации — где все функции чистые, и все без побочных эффектов на ЯП

а достижением ФП является как раз — возможность создавать ПО с мутабельностью :)

или вот
Why is mutable state such a big problem?

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

весь мир — мутабельный, с неповторяющимся результатом от того же действия
а они говорят, проблема! проблема!

или пишут постоянно
The Problem with Real World Modeling

А моделировать мир как детерменированную систему, в виде чистых функций — не проблема?

ну и конечно
The real world is not hierarchical

а истина наверное звучала бы:

The real world is one pure function

откуда вообще математики так уверены о своем знании real world?

Почему бы функциональщикам не начинать подобные статьи с
Mathematics is not an empirical science

откуда вообще математики так уверены о своем знании real world?

вот только не надо этих людей записывать в математики)

весь мир — мутабельный, с неповторяющимся результатом от того же действия

Это скорей про хаос в реальном мире

actually it’s entropy

Ентропия — это мера (причем их стадо). Не запутывай народ, за тобой повторять начнут.

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

ООП потрібне перш за все для того щоб створювати архітектуру яка буде сприяти зниженню затрат на розвиток та підтримку додатку або системи. Ні для чого іншого ООП не потрібне. Воно геть не потрібно щоб додавати котів до собак або кола до прямокутників. Люди які пишуть приклади поганої реалізації ООП на рівні класів круто паляться неусвідомлюючи цього. Їх рівень це вічний джун. Без ООП не можливо розробити архітектуру яку можна бути підтримувати не витрачаючи мільйони людино-годин.

Без ООП не можливо розробити архітектуру яку можна бути підтримувати не витрачаючи мільйони людино-годин.

Pipes and Filters?
Layers?
Actors?
MVC?
Client-server?
Microkernel / Plugins?
Чи їх усі в ООП запишете, з поліморфізмом та наслідуванням?

Я ж написав про палитися. Архітектура майже не має відношення до наведених вами мемів

Microkernel / Plugins

не есть архитектурой???? любопытно, что по вашему есть тогда архитектурой...

Пока это бездоказательно. Тут нужен эксперимент, когда две группы разработчиков в пределах одного бюджета решала бы одну и ту же задачу. И сравнить результаты.

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

Вы преподносите ООП, как некую серебрянную пулю, которая есть залогом успеха.
При этом используя замыкание «успешный проект» -> «значит благодаря OOP».
Это есть явное передергивание, и искажение фактов.

Ніт! ООП якщо по ділу це дуже складно. Тому більшість розробників залишаються на рівні мавпування патернів або «архітектури» та за нагоди залюбки починають розказувати що можна без ООП писати якісний код. Сам був такий, може і зараз такий. Щоб зрозуміти що таке ООП та чому це перш за все про архітектуру, а не про моделювання об’єктів, та чому MVC чи SOA не мають відношення до архітектури треба попрацювати з декількома проектами під час їх інтенсивного розвитку. Через декілька років почне з’являтися розуміння що основні імперативи програмування це зниження складності, однонаправленість зв’язків та відділення важливих частин від неважливих. Ще через декілька років можна бути сказати — Я знаю ООП, — а на питання на співбесіди про інкапсуляцію просто розсміятися як від гарного жарту.

. Через декілька років почне з’являтися розуміння що основні імперативи програмування це зниження складності, однонаправленість зв’язків та відділення важливих частин від неважливих.

SOLID

Вы преподносите ООП, как некую серебрянную пулю, которая есть залогом успеха.

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

вот второе можно было бы развивать как аргумент противникам ООП, но они тогда попадают в логическую ловушку — ведь они говорят что есть другие, более лучшие парадигмы :)

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

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

Чтобы узнать что лучше, а что хуже, нужны эксперименты. Результат которых очень часто идёт в разрез с интуицией. Если ОО лучше, то скажи тогда насколько она лучше в цифрах?

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

конечно.

и если эти факторы важнее на порядки чем парадигма — то для противников ООП плохие новости — мало кому интересно менять парадигму, если ее влияние мизерно.

Чтобы узнать что лучше, а что хуже, нужны эксперименты

кому нужно — тот пусть и платит :)

но никто почему-то не хочет оплачивать потребности перфекционистов и идеалистов :)

Результат которых очень часто идёт в разрез с интуицией

ну да, как я уже приводил — хороший менеджмент важней хорошей технологии

Если ОО лучше, то скажи тогда насколько она лучше в цифрах?

берете статистику по количеству рабочего кода и сравниваете с неОО кодом.

любым удобным для вас способом :)

либо — парадигма не влияет.
либо — если влияет, то вот она, лучшая.

а пара-тройка эксперементов с командами — не имеют статистической достоверности
их надо проводить наверное тысячами

кто ж на эту ерунду будет вбухивать деньги?
если исследования показывают, с конца 60ых, что применение новой технологии в программировании дает улучшение в диапазоне 5-35% Ближе к 5ти конечно, 35 в очень редких случаях

большинство успешных проектов реализовано в ОО парадигме

Приводите голословное утверждение, и делаете из него выводы. Хитро!

Приводите голословное утверждение

???
голословное?

вы простите с какой планеты к нам вчера попали?

успешных проектов реализовано в ОО парадигм

 По той простой причине, что экосистемы под другую парадигму не сделали — спецов нет, делать некому. Это как с JS, html и css — их вряд ли можно назвать сильно продуманными и качественными технологиями для того, для чего они используются, но их использую просто потому что ничего другого больше нет. Так вот точно также и с ООП. ООП предоставляет немного бенефитов по сравнению с алголами и паскалями, и мало отличается(не на макроуровне) по синтаксису на микро-уровне. На уровне текста в методе объекты это те же переменные — их поля — это переменные, их методы функции, есть свой изменяемый локальный (а иногда и глобальный) контекст, можно писать так ка на алголе только с поправкой на . Переучиватся не нужно. Если бы начали юзать хаскель? Там всё совсем не так как в алголах и паскалях. Интеропа с другим кодом нет, какие-то непонятные >>=, нет скобок программа постоянно не компилится, час командой думаем почему, а там оказывается таб закрался. По сему, количество усили для перехода на фп парадигму по сравнением с перехода со структурного на ООП, гораздо больше.

спецов нет, делать некому.

ну скоро то появятся, да?

ну чтобы вот функциональщина взлетела — раньше не было для нее спецов, делать было некому.
скоро будут толпы спецов и будет кому делать?

Это как с JS, html и css — их вряд ли можно назвать сильно продуманными и качественными технологиями

у них есть главное — они работающие технологии
да, эволюционно развивающиеся, никто в момент появления html не проектировал остальное под задачи 2019го года.

Так вот точно также и с ООП

не так :)

с JS, html и css есть невозможность выбрать другое для — веб браузера
хотя и выбирают, TypeScript, SCSS и т.п.

а выбрать другой ЯП (и транслятор для него) — можно

скоро будут толпы спецов и будет кому делать?

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

чтобы вот функциональщина взлетела

так делают же. Потихоньку вкручивают маленькие крупицы в мейнстримные языки.

не так :)

всё же выбирать там было не из чего. Не лабараторных функциональных языков тогда точно не было. Хаскель сделали в 1990-м году. Симула, из которой сделали ООП, была где-то около 1970, C++ cделали в 1983. К лиспу аппелировать не стоит, ибо он мало похож на, то что сегодня есть ФП.

а выбрать другой ЯП (и транслятор для него) — можно

всё же, среда исполнения у вас будет одна. Кроме как с dom больше работать не с чем. Можно конечно, навернуть на это абстракции, но последствия будут чувствоватся даже сквозь слои абстракций(а-ля scala-js).

но сейчас функциональщиков найти вполне реально, достаточно посмотреть на рейтинг заплат.

а зарплаты топ менеджеров еще выше.
мелочь просто — количество вакансий, и требуемые скилы :)

на скале

Скала мультипарадигменный язык :)
Для — джавистов
Причем, как сказал мне один руководитель проектов
Мы перешли на Скалу для отлова джавистов которые уперлись в стеклянный потолок, но не потеряли интерес к программированию, и потому стали изучать Скалу

То есть, решение было принято не из-за технологических преимуществ перед Джавой — а как дополнительный фильтр для соискателей :)

Ее успех, на фоне остальных ФЯ — в Джаве, ее экосистеме и трудовых ресурсах, а не ее мультипарадигменности

Где-то треть из здешних вакансий имеет отношение к фп.

точно? а если проверю? ;)

например
29 вакансий по запросу «Scala»
359 вакансий по запросу «Java»

И это еще неизвестно, как на ней пишут в этих проектах — как на улучшенной Джаве, или Хаскел лайте :)

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

Про это писал уже :)
Вишенка торте — не менят вкус торта

всё же, среда исполнения у вас будет одна.

я имел ввиду что пример ограничивающий среды браузера на выбор нельзя обобщать на ОО, императивное программирование

Хаскель сделали в 1990-м году.

8 июня 1995 года, вышел Personal Home Page (PHP Tools) version 1.0 — первый публичный релиз.

Помню, во время хайпа вокруг Ruby ему пророчили скорую смерть и полное забвение.
ну и где тот победитель — Ruby?

А в действительности PHP сейчас начинает влезать на поле Java/C# - энтерпрайз разработку. Не вытеснит конечно, но из малого бизнеса вытеснит.

Не говоря об остальном, родном для него :)

В него уже и лямбды завозят, в 7.4 будут
Станет он этого — ФЯ?
ну, или парадигма разработки на нем изменится от этой фичи?

Причем, как сказал мне один руководитель проектов

 Из одного человека делать обобщение на вообще всю скалу?

пример ограничивающий среды

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

Из одного человека делать обобщение на вообще всю скалу?

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

Но у вас конечно больше житейского опыта, как и в программировании.

Тогда когда повылезали первые ООП языки, ничего то особо и другого кроме структурного программирования то и не было.

да это понятно, что удобно игнировать то что тогда уже было :)

но ок, скоро ООП умрет, а на на императивщину будут показывать как на динозавров.
ждем.

Компании не проводят экспериментов, компании разрабатывают продукт. Никто не будет ставить двойной слепой эксперимент и разрабатывать один и тот же продукт дважды. Также результат любого эксперимента есть цифра. Соответственно вознимает вопрос, насколько это выгоднее? С точки зрения скорости разработки, количества ошибок, и т. п.? Если Вы не можете назвать точные цифры и погрешность, то все выводы взяты от фонаря. Так что если есть ссылки на исследования, а ещё лучше метаисследования, то мне было бы интересно почитать.

Не говоря о том, что выбор ООП, не ООП это куда больше вопрос моды, совместимости с существующими решениями и т. п.

таких исследований нет в большинстве случаев и в других областях

выводы взяты от фонаря

выводы взяты с эмпирических данных.

но, тут мы имеем классику:
Бремя доказательства лежит на утверждающем

ООПшнику, императивщику это не трудно — он предоставляет в качестве аргумента — действительность

а вот теперь пусть предоставят исследования, эксперементы кто НЕ принимает такой аргумент :)

І чому ви досі це не прочитали? Це ж все є у топ-5 книжок які повинен прочитати кожен програміст. У Макконела з графіками та цифрами, у дядечка Боба з глибокою філософією.

Кому й що повинен?

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

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

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

Просвітлене ООП дозволяє сягнути Евересту навіть паралізованої людини.

На лабутенах нъх
И в ослепительных(*) штанах
(*)ольгабогомолець эпплайд

(Тобто я не проти головної тези, але приклад занадто... того... ну це саме...)

Правильне ООП знижує складність. Неправильне робіть складність неосяжною.

Что такое правильное ООП и где посмотреть код?

правильных ОО парадигм несколько

а код, да полно
хоть с github.com/google/guava начинайте

если GUI — то Swing в Джаве вполне академически реализован. с небольшим отходом от MVC, ради практичности применения.
в свое время писал и на Java/Swing и на C#/WinForms, очень было интересно наблюдать разницу в подходах Sun и МS к архитектуре GUI

просто, как говорю кратко
ОО это не математика, а философия :)
потому не было и не будет единственно правильного ООП
плюс постоянная путаница

одни расшифровывают П как Программирование
другие как Проектирование
и холиварят — имея ввиду вообще-то разные области деятельности:
программирование и проектирование

правильных ОО парадигм несколько

Приехали. А так все хорошо начиналось... И тут внезапно оказывается, что среди адептов ООП согласья нет, и правильный для одних код будет не так чтобы очень тру для других. И кому верить? Вам со ссылкой на гуаву или собственно «папе ООП» Алану Кею, который говорит что по-настоящему большой идеей была коммуникация (messaging), а не объекты/классы и вот эта вся навернутая вокруг машинерия...

А не все ли равно, с чего начиналось? В ранней химии почти все идеи были неверными, а результат — вокруг нас.

Да я не о том, в общем-то. А о том, что человек, заявляющий

Саме ООП допомагає звичайним людям бути програмістами. Правильне ООП знижує складність. Неправильне робіть складність неосяжною.

должен быть в состоянии предоставить остальным, не постигшим тасзать глубины глубин, какие-то очень показательные примеры — что такое хорошо и что такое плохо. Чтобы сразу всем всё стало ясно-понятно. А в реале что? Красивые примеры в книжках на уровне птичек-бабочек да кружочков-квадратиков, но как только дело доходит до боевого кода одни адепты ООП до хрипоты, до драки спорят с другими адептами ООП на тему чье же кунгфу оопэ ровнее будет (см. срачик на тему анемичной vs рич модели, например).

Я почав з того що ООП на має відношення до коду. Якщо вам хтось показує код якій начебто реалізує ООП то перед вами людина яка ще нічого не знає про ООП. Це схоже на те як на співбесіді просять реалізувати якесь сортування, але усі знають що для того щоб реалізувати будь яке сортування треба лише вікіпедія й п’ять хвилин часу. Яке відношення має вміння писати сортування до вміння програмувати? Ніякого. Так саме будь який код який реалізує парадигмі ООП, SOLID тощо не має ніякого відношення до суті ООП, яка на мою думку, а також на думку багатьох дуже крутих перців полягає в тому що вартість змінювання та підтримки програми не повинна рости лінійно або навіть у якісь прогресії.
Щоб показати справжнє ООП треба показувати великий проект на мільйони людино-годин, та головне показувати його динаміку впродовж років. Я був би радий якби хтось показав це мені так щоб не було потрібно втикати пару тижнів. Якщо я скажу що треба програмувати інтерфейсами ви скажете що це банальна фігня і будете праві. Це дійсно банальна фігня.
Основна помилка з ООП з його сприйняттям це те що його починають пояснювати знизу, як ви просите, а потрібно починати зверху, з архітектури. Але тоді усі джуни будуть Architect, це недоцільно тому що джунам треба писати CRUD, там теж є своє ООП але воно дійсно не має ніякого сенсу й іноді з ним бува гірше.

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

"А вы, мыши, станьте ежами"

Щоб показати справжнє ООП треба показувати великий проект на мільйони людино-годин, та головне показувати його динаміку впродовж років.

Офигенно полезная парадигма получается, ага. Очень практично (а там, как грицца, «или ишак сдохнет, или падишах»)...

Тут потрібно розділяти користь. Усі програмісти які працюють за зарплатню зацікавлені лише у тому щоб зарплатня а) була б) потроху зростала. Ринок зараз проковтне будь який проект. Ну майже. Спагеті? Моноліт? Нема питань. Якщо воно приносить гроші то хай приносить. Тут користь ООП дуже тонка, її впровадження відбувається лише бажанням лідов або пєємів якось втискуватися у строки та бюджет. Але бюджети постійно ростуть. Тому що зараз на ринку дуже дуже багато грошей. Венчурний рай. Строки? Ні не чули. Окей, помножте на п’ять. І формально ООП не дуже потрібно.
Але якщо ви спробуєте щось велике зробити на свої гроші, яких наприклад буде не дуже багато, або з невеликою командою, або сам, тоді ви або будете в ООП або з великою вірогідністю завалите проект.
Користь ООП не в ООП. Користь у рішенні ізолювати область яка буде змінюватися (бізнес-правила) від того що не важно (база даних, UI тощо). Це дійсно корисне рішення. А ООП дозволяє це зробити у більш менш природній спосіб. Сама по собі ООП не має ніякої користі. ООП не є альтернативою ФП. Код з прикладами технік ООП не має ніякого сенсу. ООП може приносити шкоду. Іноді велику шкоду бо це дуже потужна парадигма.

Користь ООП не в ООП. Користь у рішенні ізолювати область яка буде змінюватися (бізнес-правила) від того що не важно (база даних, UI тощо).

1) База может поменяться, и, скорее всего, будет, при масштабировании. ЮИ и ОС — тоже.
2) Бизнес-логики обычно 80+%, поэтому смысл отделать 20% небольшой, если только ради этого.

Офигенно полезная парадигма получается, ага

ее полезность доказана эмпиричским опытом :)

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

ее полезность доказана эмпиричским опытом

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

Очевидный пример спорности этого аргумента — JS. Если признать эмпирический опыт применения достаточным доказательством ровности решения, то нужно тогда признавать и то, что джаваскрипт является примером идеального дизайна ЯП — ведь он стал де-факто не просто мейнстримом, а вообще безальтернативным (на пока что) языком в своей нише. Но нет же, до идеального дизайна там безумно далеко — секрет успеха в стечении многих обстоятельств...

Если признать эмпирический опыт применения достаточным доказательством ровности решения, то

То надо это делать в условиях, когда были и есть альтернативы, и результат победил в честном соревновании.

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

У JS не было универсальной альтернативы, просто не предоставляли (не будем вспоминать псевдоальтернативы типа ActiveX). С другой стороны, над ним сейчас есть куча надстроек типа TypeScript или Dart, исправляющих его самые плохие стороны. Поэтому сравнение некорректно.

ООП выжило в жестокой борьбе не потому, что его навязали, как Javascript в браузерах, а потому, что даёт колоссальные объективные преимущества. Да, не всегда и не везде; ну так это и не предполагалось.

У JS не было универсальной альтернативы, просто не предоставляли 

Да какая разница вообще? Поинт был в том, что эмпирический опыт — такое себе доказательство, слабенькое. Эмпирический опыт индейки, например, вплоть до Дня Благодарения утверждает, что эти странные двуногие будут ее сытно кормить и лелеять до конца дней...

ООП ... даёт колоссальные объективные преимущества. Да, не всегда и не везде; ну так это и не предполагалось.

Тю блин. Я можно сказать влез в этот тред только потому, что забавной показалась практически сектантская проповедь в голове треда, возводящая ООП в абсолют, захотелось пофлеймить на эту тему (вдруг постигну дзен). Если же это просто одна из парадигм (крайне популярная по каким-то причинам — то ли и правда так хороша, то ли просто «в нужное время в нужном месте»..., не суть) со своими ограничениями и проблемами то и спорить не о чем...

Поинт был в том, что эмпирический опыт — такое себе доказательство, слабенькое.

Вполне рабочее на длительном промежутке времени и при контроле условий применимости и адекватности.

Эмпирический опыт индейки,

Она не контролирует условия. Такой проблемы нет в обычной разработке. (С другой стороны, для неё практически важнее оказывается выживание вида в целом, а такой симбиоз идёт на пользу. Но это совсем другая тема.)

практически сектантская проповедь в голове треда, возводящая ООП в абсолют

Не нашёл ничего сектантского. Ну разве что это ваше «практически» понять в смысле «разделим остальные эпитеты на 3-5».

то и спорить не о чем...

Как это не о чем? Есть масса интересных пограничных случаев.

Но почему-то типовые спорщики начинают рассказывать про варианты типа «а у нас тут 146% ФП, зачем нам ваше ООП». Вот они обычно просто скучны. Некоторые интересны — которые показывают, как покрыть своей парадигмой больше, чем узкий круг ограниченных задач. Но «почему-то» в таком случае парадигма резко расплывается, теряет чёткость, и начинаются вопли «это неправильное X».

Эмпирический опыт индейки, например, вплоть до Дня Благодарения утверждает,

Рассел привел этот остроумный аргумент указав на слабость индуктивного метода, а не против эмпирического опыта, к которому применяется индуктивный метод
То есть даже сам индуктивный метод не отрицается, а указывается его недостаток :)

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

То есть, проще говоря, Рассел предлагал не делать далеко идущих обобщений на основе эмпирического опыта? Ну что же, спасибо дедушке за поддержку :)

Рассел указал на ограничения метода. Границы применяемости.

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

А почему это ограничение не приемлимо для того случая который обсуждается — вам уже ответили.

Ну что же, спасибо дедушке за поддержку :)

Афоризмов и пословиц полно.
Так что всякая ахинея может найти себе авторитетные источники.

я бы заменил JS на Lua спокойно, но никому морочится не охотас этим.

Не заменит. Да, она многим хороша, но противоестественна для нашего мышления.

то был сарказм :)

и не только в этом дело, хотя неественность функциональщины главный фактор.

из-за того что я много писал и на языках с динамической типизацией и со статической

я знаю разницу в скорости разработки
особенно — рефакторинга, который при статической типизации нередко вызывает перепроектирование.

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

меня оторопь берет когда я представлю систему с обычной (для меня) функциональностью в которой ничего нельзя добавить изменить без того чтобы тебя не выматерила система типов на этапе компиляции

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

а у функциональщиков все наоборот — чем матерее программист — тем больше будет бодаться с системой типов.

потом понял. например почему в Erlang выбрали динамическую типизацию :)

я вполне за статику в традиционных ЯП

просто представьте, вот такой гипотетический пример:
что у вас типы строк еще и от длины строки будут зависеть

и они после этого говорят что функциональщина — это удобно.

Я не сильно за этими филосовским спором слежу, так что и не понял, что сарказм.
Лично я уже давно забил на эти все споры о серебряных пулях.
Лично я для ФП слишком тупой. А вот императивный путь мне понятен, добавление в него объектов часто облегчает мою жизнь как программиста.

Лично я уже давно забил на эти все споры о серебряных пулях

та дело в том что ФП — это вообще не пуля :)

это лаботария по изучению материалов для пуль :)

и эта лаборатория поставила себе целью создать подход к программированию применение которого требует строго математического, детерменированного описания предметной области.
грандиознейшая задача я вам скажу.
какая-то там задача о 3ех телах — отдыхает.
но — уверенности то ого! — «все есть вычисление! цифровой компьютер — детерменирован, а значит ...»
и domain детерменирован? ;)
они даже не понимают в чем их тролят таким вопросом :)

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

что у вас типы строк еще и от длины строки будут зависеть

Можете смеяться, но я это сделал на С++ (основные строки 20 и 100 символов), оно шустрое, но да, если вдруг надо поменять длину, и не влазит в тип — может полететь десяток-два хедеров.

Можете смеяться, но я это сделал на С++

не буду — потому что на С++ можно так и не делать
а раз сделали так — значит надо было :)

а в тру функциональном — у вас не будет возможности делать по другому. вы всегда будете обязаны все вот так типизировать

Это подходу 100 лет в обед. И иногда он действительно нужен и ООП здесь поможет.

В либе armadillo ты вообще можешь задать какого размера матрицы держать на стеке, а от какого уже в хипе. В итоге для малых матриц, спасибо современным компиляторам, оверхеда 0.

«А вы, мыши, станьте ежами»

Он как раз тут прав. Всё ООП это конкретная реализация средств управления сложностью, основанная на тех самых трёх китах. А результат — отсутствие запредельной сложности.
Конкретные киты хороши именно тем, что они естественно ложатся на наше мышление с достаточно малыми проблемами (не без них, а как же — но вообще любое моделирование суть упрощение).

Офигенно полезная парадигма получается, ага.

А вот тут уже вопрос в дидактических проблемах, а не чисто практических. Надо показывать на реальных примерах — но нельзя показывать на них, чтобы вообще осилили. Вот и получаются упрощения разной степени извращённости...

Всё ООП это конкретная реализация средств управления сложностью, основанная на тех самых трёх китах. А результат — отсутствие запредельной сложности.

Как раз насчет конкретности этой самой реализации и возникают вопросы. Получается, что есть полу-философские постулаты — и имплементируй как понял. А если не понял — гуру разъяснят, иди читай умные книги...

На этом этапе, правда, выясняется, что разные гуру разъясняют по-разному, в некоторых аспектах выдвигая вообще противоречащие друг другу утвержения. А некоторые так вообще добавляют хаоса утверждая что херня это ваше оопэ, гладко было на бумаге да забыли про овраги. Ну и код... Примеры в книгах и статьях (даже объективно очень годных) отличаются от того, с чем приходится иметь дело в реале настолько, что цензурными словами это описать проблематично.

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

Вопрос: разве так должен выглядеть хороший инструмент?

Вопрос: разве так должен выглядеть хороший инструмент?

инструмент программиста находится между ушей.

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

это как если бы журналист жаловался:
так должна выглядеть классная тема для статьи??
а язык, язык то какой кривой косой и неудобный — так должен выглядеть язык для статьи?

Классика:
«Никакая инструкция не может перечислить всех обязанностей должностного лица, предусмотреть все отдельные случаи и дать вперёд соответствующие указания, а поэтому господа инженеры должны проявить инициативу и, руководствуясь знаниями своей специальности и пользой дела, принять все усилия для оправдания своего назначения».
Циркуляр Морского технического комитета № 15 от 29.11.1910 г.

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

у кого как получается, это да, это так.
как в жизни.
чем хуже с головой — тем больше на ней шишек набитых лично :)

никакой гуру из джуна не выточит синьора :)
потому что
инструмент программиста находится между ушей.

ЯП, парадигмы и прочее — это инструменты совсем другого свойства чем молоток с пилой.
к молоткам можно отнести тулзы, пакетные менеджеры, IDE и прочее

Но никак не такие эфемерные вещи как язык программирования, парадигма программирования, методы проектирования, и прочее

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

Получается, что есть полу-философские постулаты — и имплементируй как понял. А если не понял — гуру разъяснят, иди читай умные книги...

ничего личного, просто

На это мне давно нравится

дуракам закон не писан
если писан — то не читан
если читан — то не понят
если понят — то не так.

а так да, виноват язык, парадигма, начальник, гуры и полугурки, заказчик, ...

На этом этапе, правда, выясняется, что разные гуру разъясняют по-разному, в некоторых аспектах выдвигая вообще противоречащие друг другу утвержения. А некоторые так вообще добавляют хаоса утверждая что херня это ваше оопэ, гладко было на бумаге да забыли про овраги.

Ну раз не можете отличить гуру от полугурков и полных пригурков — тогда слушайте только меня. (А какого ещё совета вы тут ожидали?)
А я объснил, что в нём (ООП) хорошего, почему и где.

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

Задачи у многих ну очень разные.

Мне вот тоже 99% таких руководств не в тему, потому что у них какие-нибудь автоматизации рабочих мест кассиров или вебы, а у меня IP-телефония. И что? Всё равно можно понять принципы и перенести их себе.

Вопрос: разве так должен выглядеть хороший инструмент?

Да.

Хороший экскаватор не должен выполнять функции швейной машины, и наоборот. Аналогия далёкая, но идея должна быть понятна.

отдельно на

гладко было на бумаге да забыли про овраги. Ну и код...

потому что
Карта не местность.
Абстракция — есть упрощение, исключение оврагов

По определению.

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

Ну и код...

... в котором абстракции естественно потекут
обязательно потекут.

Как в классическом примере:
Система бронирования номеров в гостиннице считает что существует только 2 пола — М и Ж
и тут, тур группа бронирует два этажа, и список еще не точен, известно лишь количество...

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

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

потому что примеры в книгах являются иллюстрацией к изложению построения абстракций, а не инструкцией к применению
Картинкой в учебнике физики, к разделу об ОТО:
вагончик, человечек с фонариком

Как и эта картинка ничего не расскажет об ОТО, так и примеры ничего не расскажут об идее, которая объяснялась.

Есть конечно особый разряд книг — справочники
Но для программирования я таких не знаю
разве что стековерфлов :)

а так, обычно, книги учат — способам вывода умозаключений. то есть мышления.
те же паттерны ООП — яркий пример. Они ведь не код писать учат :)
потому с ними и беда приключилась, что немалым числом программистов они были восприняты как инструкция к выполнению.

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

да, потому что приходится сталкиваться с оврагами.

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

Вообще, я не искал правда, но не встречал пока и намека на книгу типа «История западной философии» Рассела, или «Драма идей в познании природы» Зельдовича

о развитии идей в компьютерном программировании.

самому писать пока не досуг, это на полгода минимум работы только по созданию «прототипа» :)

а так бы сослался, на то, как И почему менялись взгляды на ООП, при этом его основные идеи остались теми же, и что важно с практической точки зрения — конструктивными, полезными, применимыми.
не везде! там же, в следующей написаны ограничения вытекающие из этих основных идей!

:)

Вопрос: разве так должен выглядеть хороший инструмент?

Вопрос назад: а за что в ИТ деньги платят, и почему отрасль до сих пор не захватили роботы?

Вопрос назад: а за что в ИТ деньги платят

За дело платят, разумеется. Вообще, вся эта ветка была просто пятничным «а поговорить?».

Мои вопросы изначально возникли из вот этого утверждения

В результаті з’явилося ООП ... Інші переплачують.

(я уже молчу про эпичное «Саме ООП допомагає звичайним людям бути програмістами.» и «Просвітлене ООП...» — это уже вообще или годный троллинг, или лютое сектанство).

Попытки позадавать вопросы про примеры реализации, иллюстрирующие это сильное утверждение, привели к тому, что, оказывается

...ООП на має відношення до коду. Якщо вам хтось показує код якій начебто реалізує ООП то перед вами людина яка ще нічого не знає про ООП

и

...Надо показывать на реальных примерах — но нельзя показывать на них, чтобы вообще осилили...

То есть ООП у нас в этой ветке вырисовывается чуть ли не серебрянной пулей и сакральным тайным знанием, которое нельзя передать, в одном флаконе. А кто не понял, тот поймет ламер. Интересно девки пляшут: с одной стороны ООП зохватило мирЪ, потому что (в том числе) хорошо ложится на наш способ мышления. С другой — оказывается, что ложится-то хорошо, но неправильно, и если верить достигшему просветления меньшинству, это не у ООП имеются некоторые проблемы, это просто большинство готовят его не так, как положено. А те, кто знает как надо, научить не могут, потому что см. выше...

Ну и чем это отличается от риторики воинствующих евангелистов ФП (не путать с хорошими популяризаторами), которые чуть что маркируют всех остальных «неосиляторами» и удаляются в туман с высоко поднятой головой?

С другой — оказывается, что ложится-то хорошо, но неправильно, и если верить достигшему просветления меньшинству

то есть вы считаете искусственным, несправедливым распределение зарплат по категориям джуниор, мидл, синьор :)
джун же ничем в понимании ООП не отличается от синьора :)
у джуна и синьора поэтому ООП одинаково должно быть!

А те, кто знает как надо, научить не могут, потому что см. выше...

да, в том что существуют джуны — конечно виноваты синьоры.
напускают туману, нет чтобы раз и объяснить все.

это не у ООП имеются некоторые проблемы

а если у джуна и синьора разное ООП — то это проблемы ООП!

Синьор знает, где грабли лежат, а джун — нет. Вот и вся разница.

И не раскладывает их для других. Только знает — это про мидла.

именно.
но у джуна грабли виноваты, а у синьора — его незнание.

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

джуны — они такие :)

Ну.. как-то понадеялся на компилер, наваял глобальный operator new() поверх циклического менеджера памяти, чтобы парсер ускорить, а он, зараза, при перегрузке глобального оператора падает.

ну, TurboC я как-то тоже поймал
был у меня хитрый набор циклов в ифах, в которых циклы, и т.п.

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

так что бывает, бывает компилятор дуркует :)

P.S.
Хаскелистам сейчас легче.
Они в С код лезут, смотреть что из мат красотени им компилер нагенерил.
Встречал у них в блогах :)

Кто падает? Падает, если криво что написал там.
Более того, если нужно тестировать утечки и расстрелы памяти, то есть уже готовые либы для этого, что перегружают корректно.
Если же свой хип делаешь, то тут его долго и нудно отлаживать нужно.
Ну а если CG делать для С++ — то это бред — эффективнее просто взять язык с GC.

Oracle studio C++ компилятор падал через минуты 2 компиляции с ошибкой 255.

И что это за поделие??? Ты бы еще вспомнил gcc 2.95 или quickC от мелкомягких.

Странно, что эта хрень у тебя хоть что-то компилила.

Это было 6 лет назад на соляровском сервере, и админы не хотели там переставлять это все, ибо дофига можно зацепить.

2.95 был как раз отличной штукой.
Ты с «2.96» от редхата — не путаешь? Вот тот иногда прикольно глючил.

Я и не говорил, что он плохой. Просто безумно старый.
Ну а кастомные компиляторы от всяких айбиэмов и подобных — была еще та жуть.
Сейчас по сути 4 остались и они стараются следовать стандарту языка и в общем следуют ему неплохо.

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

Аппетит приходит в процессе. Чем легче делаешь маленькие хотелки заказчика, тем более странными и сложными хотелки становятся. Одно это увеличивает со временем затраты на допиливание фич. + все простые очевидные фичи уже давно сделали. + Хорошо работает lazy refactoring, но это значит, что в поздних стадиях проекта все модули закостылены, и изменения проходят хуже, чем вначале.

И тут внезапно оказывается, что среди адептов ООП согласья нет

оказывается? внезапно??
так его изначально не было. да и не могло быть :)

И кому верить?

Богу

а тому что поддается рациональному рассуждению верить не надо.
надо знать, думать — анализировать и синтезировать.

Вам со ссылкой на гуаву или собственно «папе ООП» Алану Кею

а вера Богу, Алану Кею возникает когда — не думать.

который говорит что по-настоящему большой идеей была коммуникация (messaging)

и правильно говорит.
и другие, с кем он дискутирует — тоже правильно говорят.

а не объекты/классы и вот эта вся навернутая вокруг машинерия...

Если верите а не думаете — тогда спор религиозный.

В теме о рич анэмик уже писал
большинство холиваров не конструктивны потому что их ведут верующие. причем теисты — то есть стоящие на позиции единственности Абсолюта.

поэтому и там и тут — сама тематика холиваров не важна, неинтересна. интересно выявление "символов веры"(ru.wikipedia.org/wiki/Символ_веры ) спорящих.
не важна — потому что эти верующие неспособны, в большинсве своем, перейти на философскую позицию многих истин :)

Повторяю, мне нужен двойной слепой эксперимент. Всё остальное — надевание совы на глобус, которое в силу особенностей мышления человек выполняет виртуозно. Макконела даёт только пару ссылок на исследования в главе , вроде An Empirical Comparison of Seven Programming Languages, но это тест только для одной достаточно несложной задачи, да и после 2000-го прошло много времени. И результаты особо непоказательны, и там C++ того образца и C того образца +/- совпадают.

Я чомусь впевнений що вам насправді нічого не потрібно. Але коли ви будете доїдати останній кактус у пустелі яка зветься «Світ без ООП» згадайте тих людей яких ви бачили перед початком шляху. Вони купували воду, багато води. Ви тоді крутили пальцем у скроні — Що вони роблять, вода дорога та важка. Якщо вам пощастить ви теж встигнете її купити, якщо ні будете вимагати у когось подвійного сліпого експерименту. Я не експериментую, я просто купую воду. Я вже був у пустелі.

Ви трохи не знаєте, які системи ця людина вже робила.

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

Никто не будет ставить двойной слепой эксперимент и разрабатывать один и тот же продукт дважды.

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

то все выводы взяты от фонаря.

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

по написанию одинаковой задачи

понимаете, задача — и программный продукт которому нужно жить и эволюционировать годы — не одно и тоже :)

Проект был достаточно игрушечный и бесполезный

конечно.

эт конечно не про ооп, но всё же, авторы пришли к выводу, что стат. типы. и доки ускоряют процесс разработки.

А практики в это время пишут статьи
Java убъет ваш стартап. PHP!

и показывают обратное :)
разумеется, картина сильно зависит от размера проекта.

И были когда-то про Smalltalk цифры, раза в 3 быстрее разработка чем на остальном тогда
Потому что
ООЯ и динамическая типизация

авторы пришли к выводу, что стат. типы. и доки ускоряют процесс разработки.

Зависит от размера проекта. Для мелочи работает шелл и питон — сравни какое-нибудь копирование или поиск файла в директории. Где-то от 10К строк будут проблемы с редко выполняемыми путями кода, тогда компилятор оправдывается. Доки — вообще только для командной работы и передачи между поколениями; как известно, командная работа медленнее индивидуальной.

Цій експеримент був проведений тисячі разів впродовж другої половини минулого сторіччя у багатьох компаніях. В результаті з’явилося ООП.

а потім в 2005 році вийшов ROR і показав як правильно готувати ООП. Такий підхід вийшов настільки економіно вдалим, що зараз в кожній мові по MVC фреймворку і навіть в джаві є Spring, Grails, Sprout etc.

Только Spring Framework появился в 2002, за 3 года до RoR

Без ООП не можливо розробити архітектуру яку можна бути підтримувати не витрачаючи мільйони людино-годин.

medium.com/...​n-a-nutshell-a0b47a1e9013
Layered pattern
Client-server pattern
Master-slave pattern
Pipe-filter pattern
Broker pattern
Peer-to-peer pattern
Event-bus pattern
Model-view-controller pattern
Blackboard pattern
Interpreter pattern

codeburst.io/...​e-and-design-7936abdd5830
де ООП?

ООП потрібне перш за все для того щоб створювати архітектуру яка буде сприяти зниженню затрат на розвиток та підтримку додатку або системи.

Ну... Для этой цели служит скорее разделение системы на независимые подсистемы. А ООП один из способ разработки ПО, где-то дающий замечательные результаты (GUI, разные финансово-экономические), а где-то его применимость лично для меня под вопросом (алгоритмические вычисления, возможно high performance). Это не говоря о том, что ООП может быть разный. Это объекты и сообщения между ними в стиле Smalltalk. Это указатели на функции в стиле Simula 67. И это утиный полиморфизм скиптовых языков. И возможно я что-то пропустил.

алгоритмические вычисления

Прекрасно работает, но не надо фанатствовать. Суть-то сам алгоритм и если фанатсвовать с ООП, то сам алгоритм прячется за деревьями.

Если бы это было так, то давно языки Maple, MATLAB, Mathematica и Fortran поддерживали бы наследование и полимирфизм на основе виртуальных функций или ещё как по крайней мере 20 лет назад. Ну а так, допустим, надо посчитать собственные числа или сделать архивацию bzip2. Где там можно воткнуть иерархию классов?

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

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

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

Для вычислений достаточно модулей, и даже если формально используются классы

а так и есть

поэтому в книжке по ООП сложно показать убедительно — на кой оно вообще надо, ООП это.
все примеры выглядят как из пушки по воробьям

и поэтому С жив и будет жить даже без имитациия классов.
на вполне сложных проектах

и поэтому в Go отказались — нафик не нужно ООП для создания микросервиса
хотя вот дженерики в интерфейсах — просятся. раз уж есть интерфейсы :)

MATLAB

Матлаб это все поддерживает, правда не настолько широко, как С++. На матлабе я использую ООП постоянно. Код получается понятнее и лаконичнее.

надо посчитать собственные числа

Вызвать готовую фуккцию из выбранной либы, из библиотеки продукта (если матлаб, например) и не маятся дурью. Это все давным давно написано и отлажено.
А иерархия классов для матричной математики, см Eigen или Armadillo. И могу сказать, что с появления С++ лет 20 пытались эту иерархию сделать и написать либу. За это время попыток было море, толпа либ умерла, пока не пришли к вариантам выше.
NumPy для Питона почти калька с этих двух. Более того, если бы грамотные ребята не разработали numpy, то о питоне сейчас бы все уже забыли.

Вызвать готовую фуккцию из выбранной либы, из библиотеки продукта (если матлаб, например) и не маятся дурью

Ну это пример, чтобы показать что нам надо сделать.

А иерархия классов для матричной математики, см Eigen или Armadillo. И могу сказать, что с появления С++ лет 20 пытались эту иерархию сделать и написать либу. За это время попыток было море, толпа либ умерла, пока не пришли к вариантам выше.

Ну... Если 20 лет пытаться, то возникает вопрос, а не переусложнена ли разработка?

Я бегло посмотрел на несколько классов Eigen. Ни в одном я не обнаружил виртуальную функцию. Возникает вопрос, как часто в практической работе надо наследоваться от классов Eigen, перекрывать виртуальные функции и т. п.? По первому впечатлению все реализовано процедурно, где классы это модули плюс более удобная запись, шаблоны это препроцессинг.

Вообще, делаем поиск по исходникам:

$ grep -Irn virtual . | wc -l
66
$ grep -Irn override . | wc -l
11

Про какое ООП тут может идти речь?

Переусложнена в С++ и сильно. Но другого ничего и нет сейчас кроме матлаба. FORTRAN помер (но его наследие с матрицей по столбцам до сих пор живее всех живых).
ООП — это не только virtual.
Ты может еще и ромбиками наследование увидеть там хочешь? За уже 25 лет программинга я такое видел только в некоторых учебниках (в стиле «а под эту музыку можно танцевать еще и так») — больше нигде.

Но можешь попробовать без возможностей С++ только на С написать либу для работы с матрицами удобно.

У тебе получится кривой аналог BLAS и LAPACK. Кто юзал их, знает, какая там жуть. Не в коде их (код там почти всегда на С и великолепен), а в юзании.

Значит, если в языке есть структуры, то это ООП? Вообще, эволюция термина ООП достаточно интересно. Вначале трушным ООП был Smalltalk, где объекты обменивались сообщениями. Достаточно быстро апологеты Smalltalk наткнулись на проблему, что логика сокрыта в небольших по размеру методах, и было сложно найти место, которое бы содержало нужную логику. Всё это делалось где-то... Даже Simula в то время не считалась ООП языком, хотя там уже были классы, наследование и виртуальные функции (читай Java). Потом появилась Ada, в которой были generic — прародитель шаблонов С++. Но и Ada стандарта 83 не считалась ООП.

Потом появился Страуструп, который скрестил синтаксис C, иерархию классов Simula (с наворотов в виде множественного наследование) и generic из Ada (с автоматическим выводом). Уж я не знаю, откуда пошла мода, но C++ тогда начали называть ООП языком. Три кита инкаплуляция (private), наследование и полиморфизм (virtual).

После этого появилась цела плеяда Object языков, которые добавляли возможности Simula в эти языки, вроде Object Pascal.

Соответсвенно, возникает вопрос, что, например, в этом коде, объектно ориентированного?
LDLT.h

Функции, функции, функции... Ну часть параметров запихнули в шаблоны.

FORTRAN помер

та лана! нам бы б так помереть )) Stable release Fortran 2018

Это ничего не говорит о том, что он жив.

Наверное ужасность не ООП и С++, а ужасноть их использования, одну и ту же задачу можно решить разными способами, одни из них хорошие, другие плохие. Еще наверное просто предпочтение людей, кому то нравится ООП, а кому то нет, кому то нравится ручное управление памятью, а кому то не хочется с этим заморачиваться, кто то любит Java а кто то С++, каждый хвалит свое болото. Кстати чем мне нравятся плюсы, так это тем что хочешь в ООП стиле кодишь или хочешь в процедурном, полная свобода.

Що Лінукс тако наречений не любить плюсів, це відомо. Але до чого тут ООП? Ядро, що в Лінуха, що у Вінди, написане з урахуванням ОО-підходу. Взагалі ООП та плюси — це ортогональні поняття. Можна писати на плюсах без ООП, можна ООП без плюсів робити — що найчастіше в достатньо великих проектах на простих С й роблять.

Більше того, можна на асмі писать цілком канонічний ОО-код.

Бо «О» зводиться до станів, поведінок та інтерфейсів. ОО-мови лише пропонують додатковий інструментарій для реалізації вот етого вот всього.

Он высказал свою точку зрения в 2007 году, до C++ 11 и Clang. Скорее всего, он своё мнение не поменял — но есть большие сомнения что он вникал что там поменялось.

Например, Джон Кармак тоже много лет был против С++, но со временем познал истину.

Он высказал свою точку зрения в 2007 году
Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Сказал — как отрезал

Например, Джон Кармак тоже много лет был против С++, но со временем познал истину.

Лучше предоставить слово самому Кармаку:

Я до сих пор считаю код Quake 3 более чистым — в известном смысле. Это венец эволюции моего стиля на C, и одновременно первая итерация моего стиля на C++. Но такое отношение может быть вызвано меньшим количеством строк или тем фактом, что я не особо-то и не заглядывал туда уже десять лет. Я думаю, что «хороший C++» лучше, чем «хороший C» с точки зрения читаемости, а всё остальное эквивалентно.

Я, конечно, поизвращался над C++ в Doom 3 — ведь я был опытным C-шным программистом с некоторым знанием ООП, пришедшим из Objective-C времён NeXT, так что я просто начал писать на C++ без нормального изучения юзкейзов и идиом. Вспоминая прошлое, я очень жалею, что не прочитал Effective C++ и некоторые другие книги. Часть остальной команды в прошлом имела опыт работы с C++, но они в целом следовали моим стилистическим решениям.

В течение многих лет я не доверял обобщённому программированию, и все ещё применяю шаблоны с опаской, но в итоге я решил, что удовольствие от статической типизации перевешивает нежелание иметь раздутый код в заголовках. В Id Software всё ещё идут споры об использовании STL, и со временем они становятся жарче. Если же вернуться снова к временам, когда началась разработка Doom 3, призыв использовать STL тогда стал бы неудачной затеей, но сегодня в пользу этого решения уже есть серьёзные аргументы, в том числе в геймдеве.

Также я теперь стал const-нацистом, и даю по рукам программисту, который не ставит const подходящим для этого переменным и параметрам.

Главным нововведением, интересным для меня, является функциональное программирование — оно позволяет избавиться от многих старых привычек и вновь отказаться от некоторых идей ООП.

Microsoft looking into Rust before any other memory-safe language is also not a bad decision. Besides being superior to C# in regards to better memory protections, Rust is also more popular with developers these days and might be easier to recruit for.

попробовал простую прожку на расте(байткод) запусnить под GraalVM, съело 400 мег, долго комплиилась, на расте в релизе 40 мег и выполняется в 2-3 раза быстрее, чтото не понимаю для чего нужен GraalVM
pastebin.com/q69Q61K4

При проектировании C++ ставились оцень амбициозные цели, среди которых
1. Совместимость с C;
2. ООП;
3. Zero overhead;
4. Максимум фичей;
5. Минимум кода.

Неожиданно выяснилось, что это достаточно нетривиальная задача, что добавило в язык много тонкостей. Но это естественно для первопроходцев. А дальше язык просто занял нишу (киллер-фича, имхо, совместимость с С и возможность писать p.move(5, 5) вместо point_move(p, 5, 5), был подхвачен гигантами и пошло-поехало).

ООП это другой вопрос. Если не говорить про cache-friendly (большинство операций требует лишь небольшую часть данных класса, остальные просто гоняются туда-обратно при кэшировани), то как по мне, ООП всегда приносит некоторый оверхид из-за построения иерархии классов. Если посмотреть на цепочку вызовов, то часто можно заметить, что много результатов либо в итоге нигде не используются либо выполняются дважды. Тем не менее, представление в виде объектов очень соостетсвует типу человеческого мышления и безусловно полезно в ряде задач, таких как GUI, ... Другая проблема ООП, которая известна ещё со времён Smalltalk, что в большом количестве маленьких методов сложно найти место, где выполняется требуемое действие (если ты, конечно, не автор).

Zero overhead;

прям zero там не получилось. Есть бенчмарки которые указывают что оверхед таки есть.

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

Шаблоны могут ускорить выполнение

ого неплохо это как? ))

Например, если брать qsort, то никуда не денешься от оверхида при вызове функции сравнения.

так себе пример но вообще на современных компиляторах оптимизация будет зависеть от реализации и «жОсткий инлайнинг» вполне себе уже норм.

Он может заинлайнить только то, тело чего ему подано при компиляции данного исходника.
Лежащая где-то в libc qsort под это не подпадает, а вот поданная в std::sort лямбда — на 100%.

Инлайнинг — это не всегда плюс. Посему в компиляторах с ним еще тот танец с бубном.

Кэп :)

но в среднем по больнице оно таки неплохо работает.

Паттерн стратегия / шаблонный метод с выбором стратегии как аргумента темплейта. Вполне себе работает для алгоритмов.

наверное имелся ввиду перенос процессорного времени из runtime в compile-time. Ведь используя шаблоны, препроцессором будет генериться код учитывающий все возможные типы, передаваемые в шаблон. Отсюда меньше времени будет на выполнение в рантайме, но больше в compile.

Не могут, но могут сделать код прозрачнее для читателя и понятнее.

Просто потрясающе сведено все к паре абзацев. (не сарказм)

В нем дерьма сильно поболее, чем в С++.

... и вот значит открываешь ты холодильник, и там лежит курица, вот ей мозги (про жава-скрипт) и *би !

// p.s. Старый наркоманский анекдот.

Вот только С++ — не ООП. И да, в C++ худшая в мире эмуляция ООП, если не брать во внимание эзотерические языки программирования.

Да в том же Pascal (freepascal) ООП намного лучше продумано чем в C++. В C#, Java ООП вполне на уровне, есть все что нужно и нет того, что больше мешает, чем помогает (как множественное наследования и магия темплейтов).

Да в том же Pascal (freepascal) ООП намного лучше продумано чем в C++.

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

множественное наследования

Не хочешь — не используй, проблем-то.
Мне требовалось (без виртуальной базы), работает без проблем.

магия темплейтов

Аналогично. Можно вообще и без простейшего vector писать. Но зачем?

Ну... я считаю идею считать машинные такты при использовании ООП несколько оптимистичной. Посему реализация Delphi мне представляется куда более практичной. В частности (1) общий предок всех классов с полезной информацией; (2) все классы это указатели, которые выделяются в хипе; (3) для копирования или ручные методы, или адский вариант Initialize/Adjust/Finalize (4) override всё-таки ввели в последних стандартах, но всё-таки отмечу; (5) множественное наследование только для интерфейсов, но примеси; (6) автоматическая инициализация всех полей нулями при инициализации.

В результате мы можем убрать ссылки, конструкторы копирования, переопределение операции присваивания, виртуальное наследование, облегчится понимание всяких исключений в конструкторе/деструкторе, и т. п. А в том незначительном проценте случаев когда таки нужно считать такты, я бы советовал обходиться структурами без ООП.

(2) все классы это указатели, которые выделяются в хипе;

Надеюсь, речь таки про объекты, они же экземпляры классов?

В остальном как-то ну очень похоже по описанию на стиль Java, C#. Кроме пункта 3, в котором что-то своё доморощенное.

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

Ссылки и указатели, если я правильно понял подход, одно и то же.
Конструкторы копирования — не вижу разницы, что там писать нестандартное, если нужно, что там.
Переопределять присвоение — почему бы и нет?
Виртуальное наследование — вообще очень полезная и совершенно банальная вещь, но в C++ её тупо недоработали, поэтому получилось кривовато. С другой стороны, я её ни разу не использовал.
Исключения — без разницы.
Ну а по сумме — повторюсь — тоже подход. Но другой. Может, более подходящий для инфраструктуры с GC.

Шаблоны мне больше всего нравяться в Ada :)

Они есть, но слабее плюсовых.

Ну... я сторонник того, что надо облегчить 99% случаев, а если задача подпадает в оставшийся 1%, то надо писать специфическое решение. Чем добавлять в общее решение тонкости, полезные в 1% случаев, но на которые должны обращать внимание во всех 100%. Программирование на шаблонах с использованием рекурсии, частичные спецификации всё-же очень специфично.

от именитых гуру, типа Линуса Торвальдса

Он может считаться гуру в несколько другой области. А в C++ он типичный истеричка-неосилятор уровня стримерши Карины (www.youtube.com/watch?v=S9Nkfi_NLXI).

Объектно-ориентированные языки (C#, Java) не ненавидят.
C++ некоторые ругают за его избыточную сложность, которая следует из желания данного языка усидеть на двух стульях: и позволять тюнить приложение на низком уровне (как C), и предоставлять возможность создавать высокоуровневые абстракции (как это делают всякие джавы). С учётом потребности сохранять обратную совместимость, естественно, этот язык поплатился за это своим заметным усложнением. Но ничего сверхсложного в нём нет. Кому интересно — разберётся, благо ресурсов сейчас в интернетиках хватает. Кому неинтересно или кто не хочет — бога ради, других языков сейчас хватает. Без работы никто не останется, было бы желание.

усидеть на двух стульях: и позволять тюнить приложение на низком уровне (как C), и предоставлять возможность создавать высокоуровневые абстракции

в некоторых прикладных облястях это один стул и там без С++ — никуда. А С++ сложный не потому, что его авторы что-то сделали нетак, а потому что программирование вообще сложное.

Я смеюсь, когда люди говорят, что С++ плох потому, что в нем «можно все» и, мол, из-за этого легче допустить ошибку. Но я тогда спрашиваю, а боевой самолет он тоже плох, потому что там пилоту можно все? Ведь пассажирский самолет ограничивает пилота во многом с тем, чтобы он не допустил ошибку. По логике критиков С++ получается, что это хороший самолет, а вот какой-нибдуь истребитель 5-го поколения, где пилот может делать все, что захочет — плохой самолет.

Если тебе надо спокойно и комфортно долететь с точки А в точку Б ты выбираешь пассажирский самолет и всячески хвалишь его после перелета. Если тебе надо выполнить сложную боевую или разведовательную задачу, ты сперва долго учишься, а потом берешь самолет, где «можно все» и стараешься не допустить ошибок, а успешно выполнив задание хвалишь свой боевой самолет. И когда тебе говорят какие-то люди, что, мол, пассажирский самолет на много лучше, а боевой — это говно, ты с них долго смеешься а потом тебе становится этих людей жалко, но ты не вступаешь с ними в дискуссию, так как понимаешь, что они не имеют представления о том, какие задачи существуют в мире и что иногда, когда «можно все» — это благо, а не порок

Но я тогда спрашиваю, а боевой самолет он тоже плох, потому что там пилоту можно все?

далеко не всё а только то что потянет сам кожаный мешок )) а современный боевой самолёт уже давно за пределами возможности кожаных мешков

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

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

вообще если подумать то аналогия с самолётами особенно боевыми довольно интересная ))

скажем старые самолёты действительно обладают «аналоговым интерфейсом» расчитанным на прямое прохождение информации через кожаных мешков и анализ и принятие решений и первичное (а то и полное силовое) воздействие именно ними самими но современные машины в т.ч. и гражданского класса уже способны полностью обрабатывать информацию самостоятельно и даже в общем-то самостоятельно принимать решения в т.ч. и сугубо ошибочные см. прецедент с «боингами» т.е. кожаные мешки как участники в процессе уже чисто технически «отдельный вопрос» и если подумать с современными ЯП та же ж история «что там под капотом» уже давно никто толком не запоминает и чтобы всё это использовать толком знать и не надо как не надо толком знать как работает электропривод системы управления самолётом и что там вообще электропривод а решения уже только высокого уровня «летим из точки А в точку Б по пути обходим грозовой фронт вот координаты вот расчётный маршрут автопилота вот момент нажатия кнопки включить автопилот».

ЗЫ: кстати классные слухи близкие к реальности но понятно художественные так вот наши отечественные лётчики «непривычные ко всем этим машинам» и «привычно им не доверяют» и потому летают в основном «вручную» в то время как «ненаши» почти весь маршрут проводят на автопилоте соблюдая при этом понятно положенный режим дежурства но именно как «нажал кнопку автопилота и сидит дежурит» вместо того чтобы рулить самому.

А боевые машины уже полностью готовы без кожаных мешков смотри тот же ж боинг MQ-25 хотя это даже ещё не боевая машина но они тоже придут.

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

ты не понял чувак если в первом случае ты ещё «запасной на случай сбоя автоматики» то во втором случае ты уже полностью лишний ))

но опять же ж современный боевой самолёт кожаным мешкам уже неподвластен настолько что говорить «пилоту можно всё» уже совсем бессмысленно просто потому что на самом деле в современном боевом самолёте пилот сам не может почти ничего только лишь «некое условное задание общей стратегии и непосредственное исполнение решений об применении оружия»

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

Но я думаю, что вы поняли, что в моей аналогии не важно кто упавляет самолетом — человек или компьютер — важно набор инструментов, предоставляемый этим самым самолетом тому, кто ним управляет. В конце концов компилятор С++ также выполняет море работы за программиста вне зависимости от того прораммист — это человек, обезьяна или какой-нибудь, прости господи, ИИ. Ну и да, авионику также программируют на С++ с (ограниченным до разумных пределов) примененим ООП.

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

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

ЗЫ: и ты это не пеши больши ты сейчас «делаешь вид шо спорешь» с чуваком с которым инженер авиаконструктор и самолёт именно боевой видел в самых разных ракурсах включая очень интересных

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

Плохая метафора подобна котёнку с дверцей.

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

Впрочем, ничего сверхкритичного лично я в этом не нахожу. Но некоторых людей это отталкивает. Тут уже дело индивидуальное.

Впрочем, ничего сверхкритичного лично я в этом не нахожу. Но некоторых людей это отталкивает.

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

Плохая метафора подобна котёнку с дверцей.

пруф неосиляторства Линуса в виде линка на стрим Карины впечатлил

Но ничего сверхсложного в нём нет.

Ну как сказать. Я программирую на плюсах уже больше пяти лет, и у меня до сих пор сводит зубы от задач «вот есть проект 20-летней выдержки, вот есть в нём самопальные умные указатели — ну простите, какой же проект 20-летней выдержки не обходится без самопальных умных указателей, а на STL’ные его уже фиг переведёшь — и вот здесь вот эти умные указатели КЕМ сломались, и надо определить, почему, где конкретно и кто виноват».

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

Я неосилятор? Да окей, мои заказчики все равно это не читают.

Можно ли было сделать эту часть в C++ проще? Конечно, но сделали как всегда.

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

А отдебажить?

Тобто ви звинувачуєте не програмістів, які вибрали мову програмування на проекті й написали код, а автора / комітет С++?

Ну как сказать. Я программирую на плюсах уже больше пяти лет, и у меня до сих пор сводит зубы от задач «вот есть проект 20-летней выдержки, вот есть в нём самопальные умные указатели — ну простите, какой же проект 20-летней выдержки не обходится без самопальных умных указателей, а на STL’ные его уже фиг переведёшь — и вот здесь вот эти умные указатели КЕМ сломались, и надо определить, почему, где конкретно и кто виноват».

То есть, проект 20 лет на них работал, и только сейчас они сломались? Звучит странно. Я с такими задачами пока не сталкивался. На моём опыте, если в проекте использовались самописные «альтернативы std», то они уже были достаточно отлажены и просто так не ломались.
Да и всегда можно посмотреть историю коммитов и/или подебажить, раз уж такое случилось. Разве такие вещи дебажить тяжелее, чем бизнесовые? Хз. Думаю, тут каждому своё. Лично для меня ковыряться в дженерик коде всегда было интереснее.

а для того, чтобы их решить, нужно перелопатить столько правил стандарта, относящихся к лайфтаймам/перемещению/копированию, что очень редкий юрист сможет постичь столько нелогичных, архаичных и просто идиотских правил

Похоже что таки неосилятор :( Ибо правил там не так много, чтобы это было настолько неподъёмным, как вы описываете.
«Лайфтаймы/перемещение/копирование» — это базовые вещи C++, а не какие-то тёмные закоулки. Не понимаешь даже их — возможно, стоит перестать грызть кактус и переключиться на другой язык.

Можно ли было сделать эту часть в C++ проще? Конечно, но сделали как всегда.

Если бы в начале девяностых все были такими умными, как мы в 2019.

Встречал несколько раз самопалы разных STL классов. Делал просто — удалял все нафик, делал внутри STL, а методы — обвертка вокруг стл. Именно в этом и преимущество ООП. Если оно есть — достаточно в 1 месте все менять.
А, если, программер не джун, то он еще чет такое сделает:
template
using VectorT = std::vector < T >;

просто на будущее, чтоб вдруг че менять.

Вот про такое джунам лучше не говорить.
Тут ты сразу задаешь проблему — левый псевдоним для стандартного и тем самым запутываешь читателя.
Но если у тебя должен быть не аналог std::vector, а нечто совсем другое, но ты не успеваешь это нечто сделать по разным причинам, то такой вариант корректен. Но в таком случае желательно дописать комментарий для чего и почему был введен псевдоним.

Да просто легче сразу писать.
А потом легким движением руки, что-то типа
std::vector< T, boost::pool_allocator< T > >;
или еще че ... смотря че профайлер покажет, скажем.

Но вообще, эт мне так удобнее...уже 6+мес ковыряю 16мб сырцов, которые с 2009г. 5000 глобальных замен const Some* и т.д. и т.п на псевдонимы, которые потом в шаред_птр перенаправил частями ... и вычитывал еще 3 недели....вопщем луче вот прям сразу всегда писать псевдонимы.

Зачем тебе вообще его рефакторить?
Или у заказчика лишние деньги?

В частности это опенсорс клон одной очень популярной ММО. Причем, там их много разных. Именно в этом вагон костылей, которые делают точное соотв. оригиналу. Но он нихрена не рабочий толком, даже на совр. железе. Есть уже вылизаные клоны, но там нет костылей :). И оригинала уже нет, чтоб повторить костыли. Как — то так.
Фанат етой ММО платит, чтоб работало, как старый добрый оригинал.

вопщем луче вот прям сразу всегда писать псевдонимы

Только для тех, для которых точно планируется делать кастомное что-то. Иначе код потом не читаем.

Вот на моем примере оказалось, что всегда лучше.

Есть один твой случай. Запросто его обобщаем на всё. Жжжжете товаришч.

А по моему опыту в 90% случаев псевдонимы — это синоним обфускации кода. И когда после с таким кодом приходится сталкиваться, очень большое желание найти того пейсателя и долго-долго бить его ногами.

Псевдонимы — just another layer of indirection.
Оно полезно, когда требования собираются меняться.
Когда требования фиксированы — смысла нет.
Но требования меняются в 90% проектов, или вначале не можешь обработать всю глубину задачи, и нужно начинать кодить, а потом — приспосабливать код к реальности. А когда приспосабливаешь код — indirection — кусок соломки, которую подстелил. Для этого он и нужен.

Извини это про благие намерения и дорогу в АД.
И да этим все молодые страдают. А после начинают понимать откуда TDD появилось и почему.
В частных случаях, когда вводишь свой похожий тип для оптимизации это правильно и хорошо. Но в общем случае синонимы — это зло в программинге.

TDD хорош, когда много лишних рук. Когда их нет — расставляешь ассерты и надеешься на тестировщика.

Нет. Вот он хорош всегда даже для случая вотерфола. Но как и любым инструментом можно и лоб разбить им.
И ассерты к этому не имеют отношения.
Мое же личное к ним отношения — толку от них мало. А ассерты в релизе — это смешно. Это уже полноценная проверка входных или выходных данных функций.
Но да, иногда ассерты позволяют часть ошибок отловить (но мне как-то никогда толком не помогали). В итоге я от них отказался, чтобы не обманывать себя. Там где нужна проверка чего-то, то ее и пишу явным образом.

Я книжки не пишу как Bartosz Milewski.
Так что от ассертов я отказался еще лет 8-10 назад.

Особо я там не читал, но что это за ассерты в релизе?

Это значит, что если твоя прога собралась глючить у кого-то из пользователей, то 80% что она вместо этого у него упадет. Если это его достанет — он пришлет тебе лог, ты увидишь, где упало и 80% быстро поймешь, что чинить.
В любом случае, глюков (UB) становится значительно меньше (они наступают на ассерты и падают), и они часто локализованы (видишь, где упало — обычно причина рядом).

И это решается, если писать проще и избегать UB (коих в С и С++ безумно много).

Не решается, поверь. Глюки есть и будут есть.

Есть и будут. Но ассерты часто вводят в самообман (типа проверено в дебажном режиме).
Вот только даже то, что проц делать будет сильно отличается в дебажном и релизном варианте с оптимизациями включенными. Можно сказать вообще два полностью различных кода.

Но ассерты часто вводят в самообман (типа проверено в дебажном режиме).
Вот только даже то, что проц делать будет сильно отличается в дебажном и релизном варианте с оптимизациями включенными. Можно сказать вообще два полностью различных кода.

Поэтому:
1) В релизе ассерты не выключаем.
2) Тестеры тестят релизную версию с этими самыми ассертами. А хороший тестер с плохой кармой так прогу выкрутит, что пользователям и не снилось.

То бишь обычные проверки называем ассертами?
Я ничего не имею против такого подхода — но я понимал ассерты, как проверки только в дебажном режиме.

Но и здесь нет серебряной пули. Тайминги поплывут — с проверками будут одни, без них другие.

Как-то давно, когда только начал разбираться с многопоточностью. Моя прога прекрасно работала на Пентиумах, но падала на 386. Фиксить не стал, потому как 386 были 1 на 100 штук.

Но и здесь нет серебряной пули. Тайминги поплывут — с проверками будут одни, без них другие.

Так проверки же не отключают, поэтому тайминги не полывут)

А в релизе сожрут кучи времени работы проги. А это часто ну очень важно.

Вот смотри в визуальных образах. Можно юзать RTX 2080 или Титан какой, а можно какое TPU. Проблема в цене за комплект, когда их хотят купить сотню.

95% кода занимают 5% времени выполнения. При этом в них содержится 95% проверок и 98% багов.
В тайм-критикал коде проверки можно поотключать, если надо. Обычно до такого не доходит — всегда есть дела важнее.

Да ладно. А мужики и не знают-то.
Паретто-то и с кодом работает, но немножко не так, как ты написал. В зависимости от продукта это отношение может быть в корне разное.
Сравни веб приложение и эмбедед приложение на калечной железке.

но я понимал ассерты, как проверки только в дебажном режиме.

Вот это и давно неадекватно. Хотя в некоторых местах (как Microsoft) те проверки, что остаются в релизе, зовутся иначе — может быть слово check, assume или как-то ещё... (видел такое в MFC)

А по системе уровней — у меня в одном сложном проекте разделялись явно «уровни» сохранения проверок в коде, типа четырёх вариантов сборки: глубокий дебаг, мелкий дебаг, обычный релиз, супероптимальный релиз — и соответственно 4 вида ассертов по тому, какой максимальный уровень они покрывают.
Правда, до суперотимальности мы недотянули :) но не поэтому.

Встречал несколько раз самопалы разных STL классов. Делал просто — удалял все нафик, делал внутри STL, а методы — обвертка вокруг стл.

А если самопальное — шустрее? Или оно там уже десятки лет лежит?

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

«сторонники ООП» никогда не пользовались альтернативными подходами

очень сильное обобщение :)
уровня — «мужчины ...»

противнки ООП

тоже самое — обобщение с которого невозможно ничего вывести

То же самое было с холиваром windows vs linux

«linux на десктопе — вечнозеленые помидоры»

но холивар этот затих, когда... десктопные дистрибутивы linux стали зрелыми. и вполне удобными и функциональными, а не когда кто-то кого-то переспорил :)
то есть когда действительность изменилась — исчез и смысл холивара. вернее его распространенность.

а вот с ФП не так :)
поэтому холивар будет массовым

есть много холиваров, затихших по причине завершихся ничьей в действительности
например
статическая vs динамическая типизация :)

но ФП в действительности остается нишевым десятилетиями
когда-то я думал почему, и писал свои версии.
но ФПшников не интересуют причины маргинальности этой парадигмы.

поэтому, в дополнение к объективным причинам добавляется и свойство их тусовки — хроническая неспособность вывести ФП из маргинального состояния.

поэтому холивар будет массовым, ярким еще долго.

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

Я говорю о том, что для каждой задачи есть свой инструмент.

да. в теории :)

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

но даже в теории...
а нет четких критериев определения инструментов для задач
есть только типа — «на джаве драйвера видеокарт не пишут»

Остальные тулят единственный изестный

не остальные — а большинство.
на практике :)

Дело тут в том, что ооп в С добавили уже по факту, поэтому имплементация его в С++ довольно корявая. Если нужен вариант «идеального» ооп то это не к С++, а скорее к яве или шарпу.

поэтому имплементация его в С++ довольно корявая.

не столько поэтому скажем так и не столько «корявая» сколько «неполная» но главная фишка даже не в этом но таки в том что эта реализация никак не развивалась с момента своего появления.

в свою очередь возможно это потому что никаких возможностей развития расширения etc. в самой модели придусмотрено не было.

взято комент з квори:
www.quora.com/...​elopers-switching-to-Rust

„go to the C++ committee and propose an addition”

And make C++ even more of a mess than it already is? That is actually a great idea. It needs to die and every new thing getting bolted onto what was originally a bad language design gets it closer to oblivion.

Of course you are right. There is some 30+ years of coding behind C++ and it will not simply go away. But I would be perfectly happy if it gets relegated to the role COBOL and FORTRAN play today, that of legacy code bases.

The reason I say this is because:

C++ is a mess. It is a language that never throws anything away and it is some 40 years old, so at this point it is sort of like a hoarder’s house, there might be some really cool, valuable things inside, but they are behind all the junk and crap and it is hard to tell the difference between junk and not junk.

Because of the above it is hard to learn C++ and close to impossible to learn good C++. There are hundreds of books and online guides out there, but it is near impossible to tell whether a given book teaches you good practices or not.

The OOP model in C++ is abysmal. It used to be that C++ was basically C with objects bolted on which was bad enough because half the language is in one paradigm and the other is in another and the two don’t really cross paths. You get a mess of class instances, basic types, structs, pointers and what not. And then it got worse because more shit got bolted on. Now you get shit like functors and smart pointers to add to that list.

Because of the three things above it is unsafe. It takes people many years of practice to learn to write safe C++ and a lot of times they do not succeed. You can shoot yourself in the foot with any language, but C++ basically gives you a hundred identical looking objects with the idea that touching ninety nine of these will result in you getting shot in the foot and then casually asks you to pick the right one Indiana Jones style.

I could continue. But this rant is already long enough. The point of Rust and why I think Rust or possibly a similar future language will replace C++ (although maybe not C) is because it is simple and safe. There is one way to do X and it is the right way. If it compiles, it is memory safe. There is one compiler. One base library. One dependency manager. Clear project structure. If you want to start a project in Rust, you can read the official Rust book, run a single command to install the compiler and toolkit, open your favorite editor and start coding. If you want to start a new C++ project... eh... good luck with that.

Це вже було неодноразово. Раст є просто ще однією мовою із безлічі інших, що дає «безпеку» за рахунок швидкості. Жодна з них не вбила С++, бо оце «за рахунок швидкості» вибиває їх із ніши С++.

cучасний С++ це джава подібна мова, який дозволяє менше думати та дохера кодити,
в результаті : (що я бачу в будованих системах) криві архітектурі та завалені проекти що рахітектяться\лідяться\розробляються понабігшими з ентерпрайс\веб\десктопа плюсатниками

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

веб

а от зараз обидно було!

Скорее наоборот, безопасность плюс скорость. Все проверки и гарантии в Rust статические, и выполняются на этапе компиляции, в рантайме = zero overhead. Собственно говоря, его и писали с расчётом на низкоуровневые вещи типа BIOS. За счёт же некоторых ограничений (все указатели в Rust грубо говоря или const или restrict) у компилятора куда больше возможностей оптимизации кода.

Минус Rust больше в том, что надо верифицировать код по его правилам на этапе компиляции.

А динамические ассерты там используются для верификации логики?

Все проверки и гарантии в Rust статические

Перевірка на index out of bounds статична та безкоштовна?

у компилятора куда больше возможностей оптимизации

А вони використовуються? Бо Rust наскільки я знаю використовує LLVM, яка задрочена під С та С++, і гарантії відсутньості аліасингів не дуже-то й використовуються.

Бо Rust наскільки я знаю використовує LLVM, яка задрочена під С та С++, і гарантії відсутньості аліасингів не дуже-то й використовуються.

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

С++ може практично повністю використовувати можливості компілятора С через їх спорідненість, а от що з цього не може Rust — питання. Що там із оптимізацією завантаження конвеєра інструкцій, що у C та С++ можливо робити завдяки as-if rule що дозволяє зробити більше, ніж у Rust, якраз завдяки різним UB? І там потім ще SSE з вирівнюваннями буде.

Все проверки и гарантии в Rust статические, и выполняются на этапе компиляции, в рантайме = zero overhead.

Не совсем так, мягко говоря. Только навскидку и от почти не писавшего на нём: Границы массивов. Жизнь RC и ARC объектов. Целочисленные переполнения.
Отсутствие GC (по крайней мере на видимом уровне) тут, кстати, заметно смущает (RC это не GC в случае кольцевых связей).

Собственно говоря, его и писали с расчётом на низкоуровневые вещи типа BIOS.

Видимо, только при сильном ограничении.

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

GC это оверхид всё-таки...

Только при условии, что её можно поместить в регистрах.

Такой же оверхед, как free() и delete.

Не, ГЦ запускается когда хочет и тормозит систему в самый неподходящий момент. free предсказуем — обычно даже в ОС не лезет, в отличие от malloc(), который может замапить страницу памяти, если буфер закончился.

free предсказуем

Ссылку, плиз, на стандарт, с гарантированным временем выполнения

Есть практика. При каких условиях и на чем он блокируется?

Определение «предсказуемости» подразумевает гарантии (на кот. основана предсказуемость)
Если гарантий нет, то нет и предсказуемости.
«Есть практика» === «у меня все работает».
Так GC и у меня работает, и систему не тормозит :), можно расходиться

Мой поинт в том, что память можно не освобождать, что gc и не делает без надобности (нет оверхеда)

GC оверхед при условии, что существует по крайней мере одна задача, которая без GC выполняется быстрее. Где-то я видел оценку, что в случае как только расход памяти превышает 50-70%, GC начинает создавать большие накладные расходы, потому как сильно увеличивается количество сборок мусора, которые бегают по всей памяти.

Я уже не помню где, но я читал, что львиная доля преимущества в производительности iOS перед Android заключается в том, что там отсутствует GC.

Так что разные задачи, разные требования. Rust разрабатывался прежде всего для high performance и embedded, поэтому включение в него GC тостаточно дискуссионно.

50-70% від чого? Від 128 Гб в х64?

З GC треба памʼяті в декілька разів більше ніж без нього (типово стараються вкластись в 2-3 рази, тому і такі цифри — але буває і в 10 разів). Це зрозуміла і неминуча ціна.
Але, якщо обмежити більш суворо (наприклад, 1.5 раза), то запусків GC буде більше. Ті 50-70% як раз типове граничне значення, при якому починається неефективність, але виражене навпаки (1/x замість x, нормально було б 1.5-2 — перевищення над обʼємом самих обʼєктів).

Кількість викликів гц залежить від кількості аллокацій на хіпї.

Аж ніяк. Залежить від темпу розходу памʼяті, порівняно з належним обʼємом.
Найкращий варіант для GC — це коли памʼяті в 100, 1000, 100500+ разів більше того значення, яке було б без GC. Тоді він врятує 1%, 0.1%, ... від обʼєктів, решту просто викине на смітник.

І реалізації GC типово діляться (не враховуємо тут покоління і інші хитрощі) на ті, що вмикають збір коли доходять до фіксованої межі (Java — класичні приклади), що вмикають збір за кількістю обʼєктів (CPython) або за перевищенням попереднього результату збору у фіксоване число разів (Lua). Зрозуміло, є і мішані стратегії. З поколіннями, це може окремо розповсюджуватись на кожне покоління.

бо в нього таргет якраз зменшити час на відвоювання пам‘яті

Так, але саме який час?
Якщо обчислювальна задача, типово міряти середній час, і тягнути до останнього, а потім — stop world. Так працював класичний GC в LISPах.
Якщо інтерактивна, обмежують час кожного нанокроку, навіть за рахунок середнього часу (Go).
В Java, C# роблять щось проміжне.

Також зауважимо, що якщо в програмі крітікал патз робить багато гарбаджу, то проблема не в гц, а в тому що той гарбадж знаходиться в непотрібному місці

Де це так? Щось ніде не бачив такої залежності.

За долю процесорного часу між початком прибирання і-2 та кінцем прибирання і-1

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

бо це єдине що можна хоч і евристично, але оптимізувати

А декому не треба його оптимізувати, а треба скоротити максимум тих пауз.

як це розподілено в реальному часі залежить від багатьох факторів поза контролем процесу: з гц чи без

Так, але вибір алгоритму інколи під контролем (Java — при старті VM).

А, зрозумів. Ну це звичайно і лікується схемою поколінь.
Все це сміття не переживає збір рівня 0.

джава при аллокації перевіряє видимість об‘єкту

«Escape analysis», так, методика давно відома.

навіть коли в нас є рестрікшн по пам‘яті, то нам все рівно прийдеться ділити адресний простір на швидкий і повільний

Для типових систем з GC це занадто складно. Хоча могли щось теоретичне відкрити...

50-70% от размера физической памяти. Я арендовал в Google Cloud машины с 640G оперативки для решения некоторых задач. Но ряд задач выполняется на мобильных телефонах, ряд на контроллерах.

Отдельно стоит вопрос cache friendly.

Я согласен, что GC может помочь во многих случаях, но я не уверен в том, что он будет бесплатен при решении всех задач.

Я согласен, что GC может помочь во многих случаях, но я не уверен в том, что он будет бесплатен при решении всех задач.

Он совсем не бесплатен именно по расходу памяти. Где-то её умножить в 2-3 раза это просто непозволительно.

Ну я особисто отримав 4х буст в одному місці, коли поборов не інлайнений індекс. У числодробилках таки буває. І С++ взагалі-то має можливість вставити перевірки, в тому числі нa out of bounds. Тільки білд стає десь у чотири рази повільнішим при цьому.

Причем, порой подобная критика исходила от именитых гуру, типа Линуса Торвальдса.

С чего вы взяли, что Линус Торвальдс — гуру? Это просто именитый ламер, не выучивший C++, и поэтому запилил свою поделку на чистом C. Всё просто на самом деле.

Уже упоминали поделку Линуса, на С++
Вы не владеете вопросом.

Серьезно? Ядро линукс — поделка? Интересно, знают ли об этот те сотни, а то и тысячи разработчиков, годами трудящиеся над этим проектом...

Знают, им Таненбаум рассказал. Все поржали.

Потому что пионэры ничего не понимают, но всюду лезут. ООП нужно уметь использовать правильно, тогда от него будет толк и упрощение кода. А если его использовать не правильно, как делают в 90% случаев — только головняк. Поэтому иногда проще отказаться от него совсем, что иметь дело с продуктами жизнедеятельности молодых и буйных коллег.

как же ж «от него отказаться» если на сегодня практически нет рабочих языков где вообще чисто физически можно «от него отказаться»? ))

Ну как это нету, Go прекрасно обходится без классового ООП и виртуального наследования, ты как будто не знал.

Нет, но можно использовать ООП в стиле «С с классами».

А если его использовать не правильно, как делают в 90% случаев — только головняк.

А если в 90% случаев используют неправильно, хреновый значит этот инструмент.

Мобильный телефон для игрушек?

Заявление-блеск. Ну тогда любой требовательный к скилу инструмент — хреновый.

Совершенно верно, хороший инструмент должен быть простой, удобный и эффективный. И соответствовать принципу KISS.

Молоток 100% удовлетворяет требованию.

Ты когда ни будь был ну скажем в нии химии? Ни одним из их приборов невозможно пользоваться без длительной подготовки.

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

и это кстати в свою очередь довольно интересная проблема программирования равно как и в свою очередь довольно интересная «палка о двух концах» когда «а давайте как-нибудь применим этот прибор» ну и что что не нужен и что мы не знаем как на самом деле им пользоваться и зачем тоже есть же ж прибор моё мнение против твоего давай применим какие аргументы против!? ))

когда ни будь

это феерично))

А если его использовать не правильно, как делают в 90% случаев — только головняк.

В 10% случаев. Но они отсвечивают так, что шуму на все 100.

ООП не любят когда фанатики ООП задалбывают. Так уж работает наш мозг. Если вас довольно долго тыкать в бок отверткой, вы возненавидите все отвертки.

Что до фанатиков ООП, то я лично работал с одним экземпляром, который умудрился обернуть реализацию хеш-функции в иерархию из 6 классов с ромбовидным (sic!) наследованием.

Всегда нужно на чем-то тренироваться.
Если бы не дали обернуть — он бы нашел контору на +500.

Что до фанатиков ООП, то я лично работал с одним экземпляром, который умудрился обернуть реализацию хеш-функции в иерархию из 6 классов с ромбовидным (sic!) наследованием.

Ты бы видел, что они вытворяли в своё время после прочтения Александреску, эффекты от LSD нервно курят в сторонке!

Если они вытворяли что-то настолько плохое — значит, они нифига не поняли Александреску. Суть его бородатой книжки (обидно, что некоторые в 2019 году помнят его только из-за неё, когда он уже опубликовал столько статей и докладов на самые разные темы) была именно в том, чтобы позволить кастомизировать шаблоны, не прибегая к дополнительным рантаймовым расходам. И в современном C++ это делается намного легче, чем было в начале двухтысячных.

Накладные расходы в компайл-тайме всё ещё имеют место, это да. Вот поэтому и стоит думать, когда нужно лепить очередную «стратегию», а когда лучше ограничиться одним захардкоженным решением и не насиловать моск. Не хочешь думать — твоя проблема, но прикрываться аргументами вида «я читал Александреску» в таком случае также не стоит.

я лично работал с одним экземпляром, который умудрился обернуть реализацию хеш-функции в иерархию из 6 классов с ромбовидным (sic!) наследованием.

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

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

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

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

это интересный вопрос. на самом деле интересный.

но к.м.к. относительно сабжа то на момент его появления концепция и реализация были крайне годными. как пруф тоны когда и так или иначе годного продукта (читай реально используемого) на нём написанного. но вот потом... как водится «что-то пошло не так» (к) (тм)

ибо у конкуррентов такое уже реализовано

... а потом конкуренты реализовали VB и JS ))

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

> ... а потом конкуренты реализовали VB и JS ))

А что именно они реализовали на VB или JS? Интересуют конкретные фичи, а не способ их воплощения в жизнь.

реализацию хеш-функции в иерархию из 6 классов с ромбовидным (sic!) наследованием.

Оно работало быстрее простой версии?

Всмысле, сишной реализации, которую он бережно копи-пастил в соответствующие методы? Да думаю, так же...

Просто всему своё место, мне в моих проектах(обработка сигналов в системах реального времени) всё это ООП как пятое колесо да и в целом плюсовики меня за мой стиль кода заплевали бы в первые же секунды.
С другой стороны я бы посмотрел какие бы они тут строили костыли пытаясь не нарушать правила ООП и как бы оно потом не стало работать ибо одна глобальная переменная с общим доступом из любого места решает очень много проблем.

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

А ещё очень многие кто любит говорить начинает городить страшные штуки с абстракциями создавая невменяемое нечто.

Да с ООП вроде всё ок, где проблемы тут?
Другое дело отлаживать код со SFINAE или метакод. Ненавижу их.
Даже этот грёбаный auto, если он не в каком-нибудь малом скопе, типа цикла, тоже ненавижу. Искать каждый раз потом реальный тип задалбывает, и IDE обычно тоже не очень дружат с ним (как и с макросами).

Эклипс макросы хавает. По крайней мере, не рекурсивные. По крайней мере в какой-то мере хавает.

В каких то мерах они все хавают, но меры эти очень скромненькие.

Например в случае с CLion + boost всё очень печально. Вот не решили ещё performance-problem с момента моего создания тикета:
youtrack.jetbrains.com/issue/CPP-16404
В таких случаях IDE тебе тупо не даёт писать код, т.к. парсинг выполняется не в отдельном потоке (как в QtCreator’е например) =)

В QtCreator я всю шланговую хрень отключил — раздражает.

Что-то новое сейчас писать на C — моветон. Есть прекрасный Rust.

Предположим, мы будем говорить о статически типизированных языках.
Т.к. отсутствие типизации — это отсутствие гарантий, верификации, и вообще боль и глупость для сколь-нибудь сложных систем. У динамических языков нет ни одного преимущества по сравнению со статическими.

Далее, рассмотрим само ООП. Вообще, ООП — это пёстрый набор ортогональных вещей. Мы не хотели, но вы просили, так что давайте рассмотрим подробнее:

— Абстракция. Математически это экзистенциальный квантификатор типа. Но в ООП языке, как правило, экзистенциальные квантификаторы явно не присутствуют, и в одном модуле (классе в даном случае) можем делать абстракцию лишь от одного типа (self-типа). В итоге имеем: нужная, но ограниченно реализованная функциональность.
— Переиспользование через наследование. Самая боль ООП и дичайший антипаттерн. Все советы сводятся к «предпочитать композицию наследованию». Когда же использовать наследование? В идеале — никогда. Если говорить про удобство, то хорошо, когда в языке есть возможность инклудить реализацию без создания вложенного контейнера (e.g. include модуля в OCaml; в принципе self-типы Scala похожи на это, но они и сами являются анти-паттерном, как в итоге убедились скалисты; что иронично, позже появился Swift и заявил об этом анти-паттерне как о фиче, забавно).
— Сабтайпинг. Потенциальный источник ошибок. Сам по себе делает затруднённым анализ типов, т.е. инвариантов поведения. Не факт, что является анти-паттерном (могу ошибаться), т.к. явная декларация типов хоть и дублирует информацию, но упрощает отладку при ошибках. В ООП зачастую отсутствуют размеченные типы-суммы (тип ИЛИ), которые заменяют неразмеченным типом-суммой (union), или сабтайпингом, что является костылём и функциональным ограничением языка. В целом AFAIK, сабтайпинг изоморфен эфи-рекурсивным типам данных (неразмеченная рекурсивная сумма типов), которые сами по себе также неоднозначны в плане типобезопасности.
— Сабтайпинг, ап-кастинг. При сабтайпинге апкастится деструктивно тип, лишая компилятор полной информации о типе. Более общий случай — row-type полиморфизм (сабтайпинг с сохранением части информации о типе в переменной типа), отсутствие которого в языке с сабтайпингом также выглядит как функциональная ограниченность.
— Сабтайпинг, даун-кастинг. Естественно, является антипаттерном, т.к. хак, и работает в обход системы типов. Приведение типов вообще может быть явным, что есть нормальное надёжное решение, но потенциально увеличивающее бойлерплейт, неявным, что есть хак и источник потенциальных проблем, либо же через имплиситы (неяно, но типобезопасно, в зависимости от контекста). Последнее, при наличии, даёт возможность адекватной типобезопасной реализации ad-hoc полиморфизма.
— Записи. Иногда обьекты используются просто как размеченное произведение типов, просто структура данных. Неразмеченное (туплы aka кортежи) иногда отсутствуют, хоть и являются потенциально более эффективными. В последнем случае это функциональная ограниченность языка.
— Мутабельность. Если у нас типобезопасный язык, то мутабельные дженерик-типы (те, которые с параметром типа, вроде массивов) лишаются тех немногих плюшек, которые даёт им сабтайпинг ввиду отсутствия алгебраических типов данных (суммы типов), т.к. мутабельность это, как правило, наличие геттера и сеттера, каждый из которых делает параметр типа одновременно ковариантным и контравариантным, т.е. в итоге инвариантным. ООП не обязательно подразумевает мутабельность вопреки распространённому мнению (пример чистые части Scala, да и OCaml). Кроме того, ошибки изменяемых состояний в эфемерных структурах данных (неперситентных aka мутабельных) — одна из самых распространённых причин ошибок, неявных, и трудно локализуемых. Вроде бы хорошее решение найдено в лице linear types (см. Rust).
— Маршрутизация методов (aka открытая рекурсия, отсылка к абстрактному self-типу, при позднем связывании). Является самой сутью Smalltalk-way ООП. Позволяет реализовывать ad-hoc полиморфизм (перегрузка методов, или ссылки на функции также позволяют, но являются хаком и анти-паттерном, т.к. идут в обход системы типов) через сабтайпинг абстрактного self-типа. Не то что бы является антипаттерном, но если язык предлагает позднее связывание лишь как опцию (OCaml), то, как правило, его никто не использует: это неэффективно, и очень редко, когда может сколько-нибудь улучшить выразительность, при наличии альтернатив.
— Номинальная типизация. Преимущество: строгость и однозначность. Недостаток: большее к-во бойлерплейта по сравнению со структурной типизацией. Не анти-паттерн, но при отсутствии последней — неудобство.

В виду слабой и ограниченной системы типов, в большинстве классических ООП языках невозможно оформление хороших практик в виде библиотек, потому появляются всевозможные «паттерны» и прочие карго-культы в тщетных попытках уйти от неотвратимой реальности. Например, так модно прибивать гвоздями реализацию интерфейса для некоторого типа в реализацию самого этого типа. Вместо того, чтобы вынести реализацию отдельно. Последнее решение улучшает модульность, но при отстутствии имплиситов (или тайп-классов, что есть интерфейсы и имплиситы в одном флаконе) без ad-hoc полиморфизма это увеличивает к-во бойлерплейта, неотвратимо.

И напоследок: модно приводить функциональные языки, противопоставляя их ООП. Но это ортогональные понятия. Наличие ООП опционально, и, строго говоря, не особо нужно, а по многим пунктам так и вообще зашкварно. Наличие функциональности: тут всё просто — язык либо функционален, либо дисфункционален: AFAIK типизация поверх лямбда-исчисления — это единственный математический аппарат для вычислений, который мы имеем, и поведение которого можем в некоторой степени верифицировать (от simple typed lambda calculus изоморфного конструктивистской логике, и дальше по лямбда-кубу и за него).

Математически это экзистенциальный квантификатор типа

Мне понравилось. Но после такого к расту не прикоснусь, уже сильно воняет.

Мыться не пробовали?)
А про экзистенциальные типы, ну, так, да. Естественно, инженер должен понимать, что та же абстракция, будь она класс, тайпкласс, модуль, или GADT — суть одна. Банальное вычисление предикатов, школьный курс за 8-й класс.

Я не раст и предпочитаю, чтобы другие поковыряли говно палочкой, по возможности.
Вот ты поковырял уже.

Если вас кто-то и ковырял, я к этому не имел никакого отношения.
Это такие аргументы у несчастных апологетов худо-спроективоранных легаси-языков — сводить дискуссию к фекалиям, или лично ваша проф-деформация?

А ты таки хам. Я про раст, а ты сразу к оскорблениям перешел. Это смузи так мышлению вредит?

Вбросил — и в кусты? Абаснуй за Rust, слышь.

Математически это экзистенциальный квантификатор типа

а дочого тут раст, це було про "

Абстракция.

"
Вітя, закушуй!

Что-то новое сейчас писать на C — моветон. Есть прекрасный Rust.
Математически это экзистенциальный квантификатор типа

Это про раст.

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

В расті ж, ніби, функціональне, і стан не можна зберігати?

???
так само як в С\С++: структура, мапа, вектор...

А чим воно тоді від С++ відрізняється, якщо можна зберігати стани в пам’яті між викликами функцій чи інтераптів?

Нет ООП в «трактовке» C++ / Java и им подобных языков.

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

так стой руст же ж не функциональный вроде ни разу

Тогда я вообще не понял, откуда столько шуму

Потому что это как С, только с полиморфизмом, модулями, другими штуками, без которых невозможно представить язык третьего тысячелетия (типа лямбд), и очень мощным статическим анализатором, который автоматически проверяет лайфтаймы объектов с помощью механизма borrowing, встроенного в сам язык.

А как он масштабируется? У С как раз с этим основная проблема, и для этого как раз ООП вводили.

Ну вполне масштабируется. Из святой троицы ООП остался только полиморфизм. Есть структуры и интерфейсы, и можно описывать реализации нужных интерфейсов для нужных структур.

stevedonovan.github.io/...​o/object-orientation.html

Ну вот ниразу еще лямбы не пригодились

Да ладно, вы никогда колбэки никуда не передавали? :)

А вот этого не надо, лямбды использовать в качестве коллбеков.

Почему? Лямбды для этого и нужны.

В теории некоторые обобщеннные лямбды и можно так юзать.
В С++ они для этого уродливы и код будет нечитабельным.
Заманаешься баги искать после.

Юзай обычные функции для колбеков и будет много меньше гемора с отладкой и поиском багов после.

Юзай обычные функции для колбеков

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

С возможностями уровня хотя бы 11-го — всё белое и пушистое прямым текстом.

Поясни детальнее. С и С++ сами стек разворачивают.

Поясни детальнее.

Типа

int y = ...;
std::shared_ptr<std::function<int(int)>> clos {
  [y] { return x+y; }
};
do_action(clos);

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

С и С++ сами стек разворачивают.

Не понял, при чём тут это.

Ух блин. Не сказал бы, что это гладко. Твой код хрен поймет джун.
Вот тут и сразу думается, что С таки лучше или юзайте что-то более высокоуровневое для задачи от Жабы до Жабаскрипта или Питона.

Ух блин. Не сказал бы, что это гладко. Твой код хрен поймет джун.

На самом деле просто надо познакомиться с идиомой и идеей, что оно умеет само схватывать аргументы. Потом уже можно начинать понимать, на чём это работает.

Кстати, меня чего-то заглючило — для простых случаев shared_ptr не нужен, function умеет правильно копироваться.

Вот тут и сразу думается, что С таки лучше

Нет, на нём как раз и получается сплошной закат вручную.

Нет, на нём как раз и получается сплошной закат вручную.

Зато понятный всем.

Понятно, когда твой код только для тебя и не предполагается его дальнейшее юзание кем-то еще.
Но в проектах чуть по другому. Пусть сеньор и напишет, но после фиксить баги и добавлять фичи будут джуны и мидлы. Отсюда сеньор должен писать код так, чтобы 50% джунов его могли понять и 90% мидлов. А это уже налагает ограничения на использхование фич С++ по полной.

Почему ты так взвился на совсем банальную фичу? Это ведь даже не какой-нибудь шаблон с переменными аргументами.

Не взвился. Просто написал очевидные вещи.

Все эти фичи хороши в петпроекте, но в продаваемом нужно учитывать многое другое (в том числе и программистов).

Эта фича как раз банальна и хороша везде.

В чём? Что мешает?

Люди. Нужно понимать все тонкости твоего подхода и хорошо знать С++. Но вот такими программисты становятся после 15 летнего опыта на С++ и не все.

Кличко — «а сегодня в завтрашний день не все могут смотреть...»
www.youtube.com/watch?v=YSsKw8gRVlY

Люди. Нужно понимать все тонкости твоего подхода и хорошо знать С++.

Вот всё равно не понимаю. Может, слишком сужу по себе, и по тем людям, с которыми приходилось плотно работать, но мне это зашло банально, в варианте:
1) замыкания есть чуть менее, чем везде (если язык с GC, так гарантированно, а остальные — тоже можно делать);
2) если их нет, приходится делать закат солнца вручную — уже надоело;
3) ух ты, есть штатный механизм, для которого надо выучить одно простое заклинание — в объёме не сильно большем, чем любому кодеру приходится учить за день, в крайнем случае два.

Или ты видишь какие-то грабли, а не просто незнакомство с механизмом?

(Ну да, есть случаи, когда надо помнить про cref, forward и т.п. — но это уже сильно дальше и в малой части случаев. Начало таки должно браться влёгкую.)

Вот всё равно не понимаю. Может, слишком сужу по себе

Да.

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

Недавно на онлайнере была стетейка по бизнесу о дураках и умных.
И там были 2 правильные мысли:
Если у тебя работают только умные, то бизнес не масштабируется.
Масштабируется, если работает много дураков.
На первый взгляд кажется бредом, но если подумать, то все именно так и есть.

Он сразу накладывает требования по минимуму квалификации.

Да. Всего лишь знать C++ на минимально приемлемом уровне.
Ну если бы я какой-нибудь boost::fusion применил, там да, нужен высокий уровень. Но что высокого в замыкании и shared_ptr? Это почти азы.

Масштабируется, если работает много дураков.

На такой миноопасный язык, как C++, это не распространяется, граница проходит по свойствам языков и тому, что в них не разрешается и от чего защищают программиста.
Как уже рассказал гугл и неоднократно подтверждали некоторые сверхагрессивные коллеги, хочешь применить много дураков — переходи на Go.

Не знаю, в event-based как-то не попадалось место под нее. Может, я колбеки не умею юзать и поэтому не сую никуда.

Ну у меня на коллбэках, увы, чуть менее, чем всё в центральной логике (там, где в SIP B2BUA переходим к тому, что лежит за этими самыми UA).

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

Более того для такого решения есть куча либ, начиная от MPI.
Но в сообщениях проблема с передачей больших объемов данных.

указатель передается вместе с правом собственности

Ну вообще-то оно достаточно похоже:
1. Один центральный тред, на котором движок событий. Он может слушать файлы, шедулить таймеры и дёргать коллбэки (внутри, те же таймеры, но с таймаутом 0).
2. Пул дополнительных тредов для блокирующих работ, управляющий модуль которого сидит под пунктом 1.

Но дальше всё равно начинается, например: пришёл звонок, мы проанализировали, кто и почему, послали запрос к биллингу.
Объект «звонок» породил запрос, написал коллбэк и ждёт. Один из параметров коллбэка — сам объект звонка.
Потом надо поискать, где зарегистрирован конечный участник, послать акаунтинги, регулярно перепроверять авторизацию... всё какие-то объекты звонков/авторизаций/etc. и коллбэки типа «вот ответ», «не шмогла»...

Альтернативой было бы, да, держать поток сообщений и уже локально его шедулить. Но цена лукапа получателя на каждый такой ответ мне кажется чрезмерной. Замыкание и shared_ptr — это всего лишь 1-2 дополнительных указателя (ну да, в куче, но и запрос к базе может потребовать сотни выделений в куче...) и чуть дисциплины за счёт того же shared, не обременительной.

А если звонок умрет до того, как на колбек ответят?

У меня по-другому (правда, у меня SIP клиент, и звонков поменьше будет):
1) Трубка прислала сообщение SETUP (offhook)
2) В центральном потоке сделали звонок, послали трубке ОК
3) Когда приходят цифирки, складываем их в звонке в буфер
4) Когда пора звонить — звонок начинает опрашивать учетки, сетапится в одну из них, она отправляет сообщение в SIP stack с ИД звонка.
5) Когда SIP ответит — на центральный поток со звонками полетит обратно сообщение, по ИД найдется правильный звонок, и у него дернется метод Alert() или Accept() - смотря что пришло. Там всякого покрутит и пошлет на трубку сообщение. Если по ИД звонок не найдется — в SIP stack пойдет отбой с тем ИД, который получили от него.
То есть, колбеки от SIP стека живут на его стороне, а не в центральном потоке, и только мапят ИД звонков стека на внутренние ИД и отсылают сообщения. Всей логикой занимается центральный поток, и он нигде не блокируется.

А если звонок умрет до того, как на колбек ответят?

Коллбэк проверяет состояние объекта звонка (значение общего состояния автомата, серийный номер состояния). Общее состояние может подразумеваться типом коллбэка, а сериаль фиксируется в параметрах замыкания. Пришло с опозданием — забыли и вышли.

В некоторых механизмах можно послать cancel, но, очевидно, его надёжность не гарантируется (хотя, если в замыкании есть указатель на параметры, и он сохранён в вызывающем объекте, можно сразу в этих параметрах ставить флаг cancelled). Но запросы к биллингу и базе у нас не канселлятся (может, и зря).

по ИД найдется правильный звонок, и у него дернется метод Alert() или Accept() - смотря что пришло.

Ну вот я и говорю — это лукап по табличке зарегистрированных сейчас. Может, это проще, но не всегда. А учитывая, что в SIP у нас неизбежно многоуровневое «убежище» уже завершившихся сущностей (transaction, dialog, UA), но выдерживающих свои 32 секунды на то, что могут прибежать опоздавшие сообщения, и на них надо адекватно ответить — то без проверки состояния не построить в любом случае. Потому эта проверка — во главе.

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

У нас тоже не блокируется. Все блокировки — в тредпуле исполнителей неизбежно блокируемых задач.

смотри лямбда это тупейший функтор образованный и сразу инстанциированный прямо по месту прямо на стеке и тупо скопировавший всё «зохваченное» себе во внутренние поля всё.

дальше он всё что умеет это делать f(...) с параметрами

int i = 0;
struct {
  int i;
  int operator()() {
    return i;
  } f { i };
  // в этом месте f это лямбда зохватившая внешнюю переменную i по значению всё
...
  // и дальше лямбду можно позвать чисто как функтор всё
  int what = f();

это полностью равносильно

int i = 0;
  auto а = [i]() { return i; };
  // в этом месте f это лямбда зохватившая внешнюю переменную i по значению всё
...
  // и дальше лямбду можно позвать чисто как функтор всё
  int what = f();

всё

И чё? Да, разница небольшая между функтором и лямдой в С++.

)) «нет никакой ложки» (к) (тм) нет никакой разницы просто исходи из этого и все остальные «обороты с лямбдами» тебе тут же ж станут понятными

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

а тебе по любому придётся точно так же ж освобождать в лямбде всё то что тебе вообще придётся вручную освобождать в принципе

я жы ж и говорю «плюсы» на сегодня стали настолько даже не суровы а именно хаотичны что подавляющее большинство таки реально практикующих на самом деле несут и пишут полную такую чухню которая чисто теоретически работает но лучше конечно не трогать ))

а тебе по любому придётся точно так же ж освобождать в лямбде всё то что тебе вообще придётся вручную освобождать в принципе

Давай конкретно.
Вот в этом коде где я что-то незаконно использую и оно могло бы сломаться? Предполагаем C++11.

всё то что тебе вообще придётся вручную освобождать в принципе

=> а поскольку у тебя там shared_ptr то ты его и не освобождаешь вручную в чём конкретно вопрос?

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

А потом разбирайся, куда делась память, или из какого потока вызвали деструктор.

вынужден признать я не понял вопрос shared_ptr это shared_ptr всё все вопросы уже к shared_ptr

Вот у меня к нему давно вопросы

К нему ответ только один — юзай там, где он реально необходим и нигде более.

то ты его и не освобождаешь вручную в чём конкретно вопрос?

Вот, не освобождаю. Про это и говорю — оно удобно и работает.
А то, какой магией внутри объекта типа std::function<> лежат данные — уже не ко мне, оно просто работает.

будет жить пока будет жить инстанс твоей лямбды либо его копии.

Именно. А на Си мне приходилось извращаться каким-то из 2-3 способов, но все потрохами наружу.

А то, какой магией внутри объекта типа std::function<> лежат данные — уже не ко мне, оно просто работает.

именно это я и имел в виду

Юзаю лямбди для сортування специфічного та різних агрегацій із < algorithm> Там вони дуже гарно та органічно виглядають та працюють. Ну ще колбеки тупі для кнопок у Qt фігачив.

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

Юзай обычные функции для колбеков и будет много меньше гемора с отладкой и поиском багов после.

дык лямбда же ж только в вырожденном состоянни когда не захватила ничего это функция а так она жи ж функтор ))

ЗЫ: более того «обычная практика» когда «по месту» клеят лямбду которая собственно уже только того и делает что «зовёт кого надо» ))

«Уродливы» и «нечитабельно» — это кому как.

Всё там вполне читабельно, что там нечитабельного? Квадратные скобки перед лямбдой? :)
Ну а по сравнению с некоторыми другими аспектами программирования на C++ так лямбды в нём вообще апофеоз красоты.

Меньше гемора с отладкой — нет, не меньше, лямбды дают возможность не размазывать действие и колбэк на это действие в разные функции, делая логику более локальной, а код — более читаемым.

Я я часто в STL их юзаю, удобно. Правда лямбда должна быть простой, иначе код уже не читабелен.

Я их для этого в Python использовал, но тоже только простые, чтобы я в голове полностью укладывались все возможные состояния. В С++ я редко использовал пока STL, поэтому и не применял.

Речь же про С++, а не про Питон. Я хер знаю, что там в этой части.
В С++ можно лямбды для этого юзать. Но по опыту или очень простые или чтобы остальных запутать, кто будет пытаться твой код читать.
Смысл лямбды для коллбэка в С++ не вижу. Всё одно адрес функции нужен и переход по нему. А читать легче, когда отдельная функция. Ну и коллбэк в большинстве случаев не проинлайнится.

Ну и коллбэк в большинстве случаев не проинлайнится.

в случае лямбды коллбек тоже не «инлайнится» инлайнится только вызов её конструктора которые в свою очередь в 146% случаев для такого простого объекта всё равно заинлайнится оптимизатором компилятором

При простом юзании в алгоритмах всё инлайнится, если компилятор посчитает это нужным.

Да, он не умеет в частичное применение функций, но имеет весьма недурственную типизацию. А вопрос про ООП, суть которого с т.з. типизации я и постарался расписать со своей колокольни.

Весьма хорошо, см. линейные типы.

Посмотрел. Не понял, зачем такое надо, если можно нормально писать и не шарить указатели между потоками.

Ага, и сразу без багов. Всегда так делаю :)

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

Если на проекте начинают шариться указатели между потоками без четкого распределения обязанностей — подозреваю, что там не умеют готовить.

Ну акторы тоже не идеальны. Например, как переиспользовать топологию их взаимодействия, если надо? Нужна схема, в идеале типизированная. А значит, явные мутабельные состояния при таком декларативном подходе особо и не нужны. Неявные для всякого разного кеширования — да, но локализованные в стандартных либах. Кроме того мутабельность — это отсутствие транзакций, да и необходимость помнить кто может модифицировать стейт, когда, и в какой очередности. Не лучше ли оставить это компилятору, а думать о бизнес-логике? А еще лучше о её валидации, чтобы не было ошибок в ней. Не помню кто сказал, возможно Кнут: любую программу можно написать в два шага: шаг 1-й — пишем DSL, шаг 2-й — логику на DSL. Ну а DSL логичнее всего сразу на типах.

Например, как переиспользовать топологию их взаимодействия, если надо?

Через каналы сообщений и фабрику, очевидно.

Нужна схема, в идеале типизированная. А значит, явные мутабельные состояния при таком декларативном подходе особо и не нужны.

Не понял.

Кроме того мутабельность — это отсутствие транзакций, да и необходимость помнить кто может модифицировать стейт, когда, и в какой очередности. Не лучше ли оставить это компилятору, а думать о бизнес-логике?

У меня большая часть бизнес-логики в переходах между состояниями. Когда звонок приходит из интернета на радиотелефон — компилятор сможет обработать INVITE, отослать {CC-SETUP} на все трубки с начинкой, соответствующей модели трубки, потом дождаться {CC-ALERT}, отослать номер звонящего, если один из телефонов пришлет {CC-CONNECT} — согласовать с ним кодек, установить голосовой канал, отослать {CC-RELEASE} на остальные трубки и 200 OK на сервер? И еще не запутаться в возможных наложениях сценариев друг на друга. Например, если одна из трубок инициировала исходящий звонок в тот момент, когда с сервера пришел входящий.

Не понял

схема декларативная, описывает какие инстансы создаются и какие каналы, тип фабрики, можно и так сказать. Я о том как выглядит, например, новая скаловская Akka с иммутабельной схемой в противовес задепрекейченной с мутабельными акторами.

И еще не запутаться в возможных наложениях сценариев друг на друга

Звучит как идеальный кейс для типизированой функциональщины.

Звучит как идеальный кейс для типизированой функциональщины.

Так функциональщина же не помнит состояния системы, не?

обычно функциональщики предлагают реализовать все
конечным автоматом :)

они вообще обычно так и видят: всякая программа реализует конечный автомат.

Так функциональщина же не помнит состояния системы, не?

Ага, мы только теоремы доказываем. Право же, смешно.

обычно функциональщики предлагают реализовать все
конечным автоматом :)

У вас очень странные предрассудки. Но да, если система может быть им, то грех таковой её не сделать. Как сказал один из авторов одного из распространнённых языков контрактов (лень гуглить) вместо термина «тьюринг-полный» логичнее использовать «тьюринг-уязвимый». В языках вроде Idris есть отличная возможность отделять гарантируемо завершаемые состояния и гарантированно конечные данные от потенциально не таких. Разве гарантии, и локализация потенциальных точек отказа — это не удобно, и не практично?

Ага, мы только теоремы доказываем. Право же, смешно.

ну не софт же пишите :)

на ООП говорите писали — 8 лет
а сколько лет пишите на функциональщине?

У вас очень странные предрассудки

да куда моим до девиза что «ООП умерло» :)

и что императивщина — это грехопадение. по недоразумению.

Как сказал один из авторов одного из распространнённых языков контрактов (лень гуглить)

автор Eiffel что-ли?
так Eiffel — ОО язык.

В языках вроде Idris

а где софт на нем написанный?

когда будет?

Разве гарантии, и локализация потенциальных точек отказа — это не удобно, и не практично?

докажите практичность использования Idris — софтом на нем написанным :)

вы же не только теоремы на нем доказываете, верно?
и может быть, прогоняете прототипы реализации алгоритмов.

значит скоро появится софт написанный на практичном и надежном Idris. или вроде него :)

я ж об этом писал уже
не надо ничего никому доказывать на форумах

пишите софт — быстрее и качественней.
и все.

но вот когда об удобстве и практичности говорится десятилетиями, а разработка ПО не ломанулась, ни в лице простых программистов, ни руководителей разной специализации и уровня — странно как-то звучит ваш вопрос

это не удобно, и не практично?

хотя слышал я и пояснение:
существует мировой заговор против знания о плоской Земле, тьху, ФП
попил денег, преднамеренное удорожание разработки, «причина болезней — врачи!» и т.п.

но теории мирового заговора, как всё нефальсифицируемое — я даже не тролю :)

вы же не только теоремы на нем доказываете, верно?

Там даже с этим огромные проблемы, причем сразу на элементарном уровне.

пишите софт — быстрее и качественней.

Спасибо за разрешение :)
Я-то пишу. И мне весьма ок. Вы же пытаетесь убедить меня, что это проблема. Это не проблема — раз. И возможности, которые не стоит упускать — два. Вероятно не вам.

Ну так: если у нас есть простой алгебраический тип (сумма «ИЛИ» и произведение «И», ну плюс типы-синглтоны, т.е. один экземпляр на тип), то мы можем строить автоматически верифицируемые типами выражения на очень простой конструктивистской логике. Если появляется абстракция (квантор существования) и параметрический полиморфизм (квантор всеобщности), то эта возможность расширяется до вычисления предикатов.

UPD: А вообще касательно перехода на личности — был не прав, и с похмелья, исправлюсь, но это не точно.

як можна обсуждати вкус раста не попробувавши його?

Точно. Но если что-то выглядит, как говно, то я без пробы обойдусь. пусть другие пробуют, если хотят.
Некоторые вот выше попробовали и описали ощущения свои.

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

Математически это экзистенциальный квантификатор типа.

Для кого как.

Вас страшные слова пугают из школьной программы? Концепция-то простая, как два байта.

Ага, как щас помню, как информатичка мне тройбан поставила за непрочитанный SICP.

Ага, как щас помню, как информатичка мне тройбан поставила за непрочитанный SICP.

Похоже на начало фантазии... Мне кажется, ты меня обманываешь. Но я тебе верю, продолжай...

инженер должен понимать

кому должен?

Факту быть инженером, и здравому смыслу, а также самому себе, если самому себе не враг.

Танунафиг. Деньги платят — значит, инженер. Пускай ХРы заказчику обосновывают.

Тоже имеет право на жизнь быть позиция. Но она уязвима к конкуренции со стороны стран с многомиллиардным населением, и более сильной экономикой. Грустно быть monkey-кодером в стране третьего мира.

к конкуренции со стороны стран с многомиллиардным населением

Назови хотя бы одну страну с многомиллиардным населением.

стран с многомиллиардным населением

Китай + Индия — уже почти два с половиной, население каждой — более миллиарда (больше одного — много).

и все это касается только — кодирования :)
проектировать же функциональщики не научились, и ничего предложить не могут.
и даже не понимают что вот это все типа крутое по удаленности от действительности находится где-то там же где холивар:
табы vs пробелы

математический аппарат для вычислений

для расчета скидки на товары не нужен матаппарат.
достаточно знания арифметики на уровне младших классов.

ничего такого сложного бизнес-системы не считают.

поведение которого можем в некоторой степени верифицировать

верифицировать что?
математичесие абстракции?

а код — кто писать будет и на чем? :)

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

есть даже мнение что математики — плохие программисты.
как и инженеры. как и экономисты
то есть плохи во всем где приходится сталкиваться с эмпирикой.

У вас похоже какая-то личная неприязнь к FP. Не знаю, каким образом ваши суждения релевантны сабжу, но отвечу: именно модульность FP и может предложить, при том на всех уровнях, от композиции функций до композиции параллельных вычислений, и типов, и модулей. Если бы вы внимательно читали, то заметили бы, что ООП — антипаттерн, а FP — единственная адекватная парадигма. И они не противоположны, можно смешивать бред и здравый смысл в любых пропорциях на свой вкус.

верифицировать что?

Ну код тащемта, значения, что ещё может типизироваться?

а каким боком математика применяется в проектировании информационных систем?
ответ —

Прямым. Это и есть математика. Если у вас какие-то комплексы по данному поводу, я не знаю, что предложить.

мнение что математики — плохие программисты.

Подтверждённый эмпирически в большинстве своём факт. Обычно потому что тело кода не является самоцелью, а лишь одноразовым средством проверки гипотез. И за потобную техноересь так нелюбимы нами :) Но обратное не обязательно верно. Кроме того, чтобы быть математиком, программист обязан быть в некоторой степени когнетивным психологом, оценивая поддерживаемость кода.
И ФП концепции тут гораздо очевиднее, чем магия на регистрах процессора, мютексах, и таблице виртуальных методов. Я не хочу думать, где что хранится, я хочу думать о том, что оно делает, и, если я ошибусь, забыв об этом, чтобы компилятор меня поправил. И потом просто использовать компоненты не задумываясь об их реализации. Либо реализуя интерфейс, не так важно, сверху вниз, или снизу вверх.

У вас похоже какая-то личная неприязнь к FP.

психотерапевт или телепат? ;)

именно модульность FP и может предложить

модульность не является уникальной фичей FP

то заметили бы, что ООП — антипаттерн, а FP — единственная адекватная парадигма

на ООП написано и пишется тьма систем. работающих.
а FP сродни единорогам :)
одни разговоры, и редкие примеры.

И они не противоположны, можно смешивать бред и здравый смысл в любых пропорциях на свой вкус.

да.
также как не противоположны фундаментальная наука и инженерные дисциплины.
вопрос только — а почему инженеров много больше чем ученых?
почему бы не заменить инженеров — учеными?
начав с вузов — убрать все инженерные дисциплины и учить только науке.

Ну код тащемта, значения, что ещё может типизироваться?

а что там верифицировать то?
процент от суммы покупки :D

Это и есть математика

когда и где :)

физики строят атомные реакторы?
почему не могут спроектировать?

назовите мне хотя бы текстовый редактор спроектированый математически.

Если у вас какие-то комплексы по данному поводу,

телепат. или все же психотерапевт?

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

вот именно.
поэтому и верификация кода не имеет отношения к проектированию — а главное к разработке информационных систем.

но даже для гипотез в виде прототипов информационной систему лучше использовать какой-нить руби на рельсах. быстрее получится :)

И ФП концепции тут гораздо очевиднее

если бы были очевиднее — писали в ФП парадигме :)

но так как совсем неочевидны, то и не стало ФП — мейнстримом.

опять же, та же слепота к эмпирике и в этом :)

как я говорю:
в каком году был доклад
«Почему ООП провалилось»?

ну вот, правду ж сказали, нету его, ООП этого вокруг.
доклад естественно делал матерый фпшник :)

он художник, он так видит

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

спелчекер поправит текст да. запятые расставит.

только вот если написана чушь — какой спелчекер поправит?

расскажете как математически отличить чушь от нечуши?

И потом просто использовать компоненты не задумываясь об их реализации

покажите в ФП такое.
сколько компонент написано?
или что там с стандартизацией лиспа например?
в чем заковыка то случилась?

а вот на ООП, да и обычном процедурном — тьма библиотек.
подключай — и вперед.

Я не хочу думать, где что храниться, я хочу думать о том, что оно делает,

а придется. в эмпирической действительности — думать об этом.
это и есть определяющая разница в видах деятельности, заботах между — инженером и ученым.

не хотите об этом думать — так что вы тогда можете посоветовать инженеру?
ессно — ничего.
но вы даже этого не понимаете, а как граманаци рассказываете о запятых, правильном роде кофе, и прочем.

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

теорией и практикой

Ну вот, вы меня уже в теоретики записали. Импонирует, право же, но увы.
Да, и психотерапевтом, и телепатом приходится быть, общаясь с продукт-оунерами, работа такая :)
Возможно я что-то упускаю из вашего эмпирического опыта, но я 8 лет писал на чистом ООП, и знаю, какой профит и буст привнесли тащемта базовые и тривиальные type theory знания. Может, я просто не умею в нормально донести, или же вы просто игнорируете мою попытку донести то что вне зоны комфорта.
А то что все используют — так не факт что оно адекватно. Вон, все qwerty используют и нессиметричную клавиатуру. Почему? Не от большого ума :) Но стандарт же :)
Если про экосистему, то Haskell и Scala ооочень норм. Благо, хвала мелкомягким (не верю, что это говорю), есть теперь language server protocol и редактор-независимые IDE, вот недавно Metal для скалы допилили, вроде.

только вот если написана чушь — какой спелчекер поправит?

Coq? Idris? Agda? Dependent Haskell? Lean? NuRPL? Isabelle? F*? Десятки их. Всё у чего есть зависимые типы. Но для большинства практических задач хватает верификации основных кейсов на более-мение простых типах.
Что я пытаюсь сказать, это то что не надо получать PhD, и высшего образования не надо, чтобы понимать type theory: λ-абстракция и β-редукция, кванторы ∀ и ∃, ⋀ и ⋁. Вот кагбы и вся база, школьный курс логики. А понимание это мало того что улучшает восприятие систем и вычислений в целом, так еще и открывает доступ к интересным вакансиям, а интересным вакансиям открывает доступ к отечественному IT-рынку. У меня на проекте несколько месяцев искали подходящих кандидатов по Украине на весьма вкусный оклад, в итоге наняли за пределами её. Грустно. Да и по мне это интереснее, чем монотонно тянуть лямку иллюзорной стабильности, которая вот-вот лопнет из-за набега гастарбайтеров-вайтишников.
Если кому интересно, советую читнуть «Типы в языках программирования» Пирса, и «Теория категорий для программистов» Бартоша.

Да, и психотерапевтом, и телепатом приходится быть, общаясь с продукт-оунерами, работа такая :)

я вообще-то намекнул на то что использовать демагогические приемы тоже стоит — грамотно.
безграмотность в их применении попахивает невежественностью в логиках.

но я 8 лет писал на чистом ООП

и за сколько лет на функциональщине вы написали столько же функционала?

или, дайте попробую догадаться — вы уже не пишите код, вырасли до какой-то лидской, аналитической позиции?

А то что все используют — так не факт что оно адекватно

факт что — используют
а дальше — эволюционный закон — выживает то что более адекватно действительности

из того же что НЕ используют ФП — никак нельзя сделать вывод что оно будет более адекватно действительности.
А функциональщики уверенно делают такой вывод.

Почему? Не от большого ума :)

да со снобизом понятно давно :)

Хошь умным показаться в тусовке программистов?
теоркат копни на уровне википедии и вворачивай в речь «моноиды» — все ахнут, и будут небыдлом считать

Если про экосистему, то Haskell и Scala ооочень норм.

Scala даже скалистов утомила ломкой совместимости
сказку про нее рассказывают тем кто не интересовался

Но ок.
Давайте сравним с экосистемами тех же Джавы, .NET, PHP, Node.js

Возвращаясь к модульности

Вы так важно сообщили это преимущество...

В действительности же проблема стопицот раз успешно решена

Возьмем для примера презренный Wordpress
Одна из причин его популярности и массовости применения — плагины.
То есть ребята, без всякой великой науки соорудили плагинную систему которая позволяет любому ремесленнику быстро освоить и написать — свой плагин.

То есть
пока функциональщики важно надувают щеки о потенциальных преимуществах — ремесленники(!) уже давно решили эти проблемы :)

Coq? Idris? Agda? Dependent Haskell? Lean? NuRPL? Isabelle? F*?

???
Вы опять про кодирование...

Классика:
Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка

что математически в этой фразе не так?

и кстати, вы написали

Т.к. отсутствие типизации — это отсутствие гарантий, верификации, и вообще боль и глупость для сколь-нибудь сложных систем.

конечно на всяких там руби, питонах и php ничего серьезного не пишется. это каждый знает.
но не каждый знает что и на Erlang’е ничего не написано и не пишется. а его авторы — полуграмотные ремесленники :)

Что я пытаюсь сказать, это то что не надо получать PhD

У меня был период когда я плотно интересовался ФП

И пошел к специалистам и программистам которые пишут более 8ми лет не на ООП, а на функциональных языках
И даже они говорят
Язык который требует ежегодно изучать несколько научных монографий — не годится для продакшн.

Вообще, всем совет — получать информацию у специалистов. Интересует ФП? идите к тем у кого это главный рабочий инструмент.

школьный курс логики

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

Вы не учились в школе что-ли?

type theory: λ-абстракция и β-редукция, кванторы ∀ и ∃, ⋀ и ⋁.

да, если интересует фундаментальная наука, и есть мечта стать ученым — вперед изучать.

У меня на проекте несколько месяцев искали подходящих кандидатов по Украине на весьма вкусный оклад, в итоге наняли за пределами её.

а мы на проекте обычных программистов обыскались

Да и по мне это интереснее, чем монотонно тянуть лямку иллюзорной стабильности

о вкусах не спорят.

Речь о том что

из истинности
0.1 + 0.2 = 0.3
НЕ следует что мы получим true:
if (0.1 + 0.2 == 0.3)

об этой разнице речь
которую теоретики либо не знают, либо игнорируют.

я вообще-то намекнул

Прекрасно понял вашу иронию, но вижу смысла идти на поводу провокаций того, кто отчаянно защищает святость невежества. Кроме того, вы настойчиво стараетесь записать меня то в неучи, то в математики, то в менеджеры. Что это, полный перебор? И с каких это пор лидская должность не подразумевает кодинга? Если так любопытно, могу рассказать биографию, но она скучна и непримечательна: родился, учился, не доучился, работал, работал, работал, работал, работал...

вы написали столько же функционала

на моей практике тот же объём функционала с меньшим колличеством багов выдаётся заметно быстрее, без мучительной борьбы с ООП-костылями и игры в паттерны. Старт проекта правда медленнее, на 2-3 месяца.

да со снобизом понятно давно :)

Т.е., если не вырывать мои слова из контекста, использование клавиатуры, небратимо приводящей к болезням суставов — не глупость? Или использование раскладки спроектированной замедлить набор текста, чтобы уменьшить износ рычажков печатных машинок, и удешевить их гарантийный ремонт. Расскажите мне ещё про эволюцию. Рынок IT очень молод, и подобное ещё будет отмерать веками, вместе с бейсиками, коболами, ооп, и

на всяких там руби, питонах и php ничего серьезного не пишется

и с ними тоже, надеюсь.

Вы опять про кодирование...

Классика:
Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка

что математически в этой фразе не так?

Всё так. А какая задача? Или вы снова подменяете контекст, и заменяете логическую дедукцию — индукцией. Боюсь последнее — тема очень большого етдельного топика. Но если вкратце то да, пока нет сильного ИИ, подобная задача считается алгоритмически очень сложной, но человеки внезапно в неё могут, в чём, собственно, и состоит соль нашей профессии.

о потенциальных преимуществах

Просто hoogle.haskell.org это. Не встречал подобных по удобству инструментов для других языков. Нужно что-то — находишь реализацию по типу.

да, если интересует фундаментальная наука, и есть мечта стать ученым — вперед изучать.

Да ладно, десятки паттернов, архитектур, kiss/solid etc — ок, а простое лямбда-исчесление — сложна?

Это в какой школе, в каком году дают логикИ

AFAIK, исчисление предикатов — во всех.

Вы не учились в школе что-ли?

=)

а мы на проекте обычных программистов обыскались

Как же вайтишники. Мейнстрим и ООП — это же так просто! If/for — и погнал! Ну там ООП, модули-плагины... Но что-то не так всё и просто, оказывается?

То есть ребята, без всякой великой науки соорудили плагинную систему которая позволяет любому ремесленнику быстро освоить и написать — свой плагин.

Так что ж вы не набираете любых ремесленников-то?

о вкусах не спорят.

Я — нет. Лишь изложил факт того, что ООП подход морально устарел, и языки проектировавшиеся с ним в фундаменте — тоже. Существуют гораздо более жизнеспособные альтернативы.

Язык который требует ежегодно изучать несколько научных монографий

Ну вот откуда беруться такие стереотипы. Да, когда знаешь три способа создать типизированный DSL, не хочетя упустить возможности узнать и четвёртый. Но это не обязательно. Вы же не запрещаете кодить тем, кто не знает GoF наизусть?

теоркат копни на уровне википедии

А надо глубже? Да, всё уже украдено до нас, известная терминология позволяет не изъясняться на уровне «берём штоквину, пхаем в хреновину, получаем фиговину», как с теми же паттернами же.

Речь о том что

из истинности
0.1 + 0.2 = 0.3
НЕ следует что мы получим true:
if (0.1 + 0.2 == 0.3)

Это вообще что такое? Что за язык Как определены = и ==? Какая алгебра литералов с точками? Зануды вроде меня предпочитают всё иметь расставленным по местам, а не гадать на кофейной гущe, веря в магию. Да, алгебру целых и действительных также можно и нужно разделять на уровне типов, как и то, что у нас определённое к-во битов можно представить кольцом вычетов по модулю.

кто отчаянно защищает святость невежества.

с каких это пор :)

я всего лишь говорю о неадекватности суждения, типа
опера — высшее вокальное искусство, и потому все люди ходили бы в оперу, но их обманывают всякой попсой!

Кроме того, вы настойчиво стараетесь записать меня

всего лишь гадаю :)
потому что не телепат и не психотерапевт :)

на моей практике тот же объём функционала с меньшим колличеством багов выдаётся заметно быстрее

да, функциональщики так говорят — сколько читал их агитацию

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

Рынок IT очень молод, и подобное ещё будет отмерать веками, вместе с бейсиками, коболами, ооп, и

а, вот он секрет — пару веков надо.

это ж из демагогии, вы не в курсе?

Аппеляция к будущему, как свершившемуся факту:
Раз в будущем победит коммунизм, то сегодня ...

Как же вайтишники. Мейнстрим и ООП — это же так просто!

про снобизм уже писал :)
функциональщик без снобизма — бывает ли?

Лишь изложил факт того, что ООП подход морально устарел

факт — это нечто свершившееся.

а вы изложили не факт, а свое мнение. ощущение, и т.п.

Так что ж вы не набираете любых ремесленников-то?

проект не позволяет :)
но функциональщиков точно нам не нать.

Да, когда знаешь три способа создать типизированный DSL

факт — DSL не взлетел.
вы пропустили пик надежд на DSL
пора слезать с этой мертвой лошади, не? :)

Это вообще что такое? Что за язык Как определены = и ==?

обычный. мейнстримовый
который генерит код для обычных компьютеров.

проще показать разницу между теорией и практикой и не знаю как

Вы же не запрещаете кодить тем, кто не знает GoF наизусть?

главное — кто ж функциональщикам то мешает:
алгебру целых и действительных также можно и нужно разделять на уровне типов

факт — DSL не взлетел.

щось не співпадає з реальністю.

тобто ви стверджуєте що більшысть проектів починається з розробки DSL після аналізу домена?

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

Але це ж і не мертва кобила.

«не взлетел» у подібних розмовах означає — не став нормою.
uk.wikipedia.org/wiki/Нормальний_розподіл

Кажуть що й COBOL не мертвий.
На ДОУ не так давно шукали програміста на Smalltalk(Cincom) (як з`ясувалось пізніше по всьому світу, для офіса у Канаді)
Мертва мабудь Ada, але не впевен

різного роду DSL’і широко використовуються в мовах

які теж не стали нормою, поширеними, популярними

і маємо той жарт:
«широко відомий у вузьких колах»

де ці ж DSL’і можна нормально написати.

і навіть там де DSL легко створити — це не є головний метод створення програм
Але ви легко може це спростувати — назвавши мови, створення ПЗ на яких зазвичай, у більшості випадків має обов’язковий етап — створення DSL
Можете запитати-перечитати Кожаєва, який є мабуть чи не єдиним спеціалістом з цього напрямку на ДОУ

Я назву ruby, обов’язкового етапу створення свого DSL немає, але створений кимось DSL використовується як технічний інструмент — active record моделі, робота з формами, опис бізнес логіки, фреймворк для тестів та багато-багато іншого. Фактично вся екосистема тримається на DSL.

Я назву ruby

Так, ruby має розвинуті засоби для метапрограмування та створення DSL

але, повертаємося до Вашого:

щось не співпадає з реальністю.

якщо ви не знали, то можете швидко нагуглити, що хайп про Ruby був десь в 2007-2011 роках
просто дивіться на дати статей про DSL у Ruby

причому, тоді було популярно вважати що через 10 років Ruby стане головним у web-розробці, а php буде для невігласів та застарілих або дрібних проектів.
причому це станется як раз тому що дуже зручне метапрограмування та створення DSL.

Зараз 2019ий

Давайте побалакаємо про реальність — наприклад поширенність Ruby.
Якщо вона збільшілась з того часу — то DSL взлетів, разом з Ruby
Якщо вона зменшилась — то

факт — DSL не взлетел

, разом з Ruby

Варіант для контрагументу, якщо Ruby не взлетів,
та сам DSL став нормою у мовах ...!

які це мови? назвіть

Давайте побалакаємо про реальність — наприклад поширенність Ruby.
Якщо вона збільшілась з того часу — то DSL взлетів, разом з Ruby
Якщо вона зменшилась — то

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

хайп про Ruby був десь в 2007-2011 роках

А що було хайповим після Ruby? node.js, Go, Elixir?

Спочатку стало потрібно писати стейфул чатики і через це node.js став популярним, але через недорозвинену екосистему та необхідність запускати багато процесів між якими ще потрібно комунікувати через якусь шину node.js вийшов з моди. Йому на зміну прийшли мови придатні для паралельного програмування.

Я вважаю що Ruby не переміг не через DSL, а через те що не встигав за зміною вимог до розробки веб аплікушок.

В рубі є купа інших недоліків, які нівелюють переваги та обмежують сферу використання:

я не питав про недоліки чи переваги

Ruby взлетів чи ні?
У реальності.

А що було хайповим після Ruby? node.js, Go, Elixir?

node.js — взлетів.
Go — не так стрімко, але поширенність зростає

Elixir — не взлетить :)
але можете вірити у його майбутнє — я ж не пророк.

Я вважаю що Ruby не переміг не через DSL

ще раз
Ruby взлетів чи ні?
у реальності?

чому — взлетіло щось що чи ні — то вже: пояснення факту чи фактів

ви ж не згодні з моїм
— факт — DSL не взлетел.
— щось не співпадає з реальністю.

то розкажіть про вашу реальність більше :)

Ruby взлетів чи ні?
У реальності.
Ruby взлетів чи ні?
у реальності?

Дайте означення «взлетів» та «не взлетів».

Якщо я правильно розумію ваше термінологію, рубі «взлетів» через ROR та MVC, а потім здувся через те що не адаптувався до нових вимог. DSL не був основною фішкою Ruby і казати, що ROR == DSL не правильно.

ви ж не згодні з моїм
— факт — DSL не взлетел.
— щось не співпадає з реальністю.

то розкажіть про вашу реальність більше :)

В моїй реальності Ви ствердужуєте:
1. Ruby == DSL
Успіх мови програмування, в даному випадку Ruby, залежить під багатьох факторів, а Ви спрощуєте так як вам зручніше. Я лише хотів вказати Вам, що Ваше твердження неправильне. Так само як і наступний висновок з нього.

2. Ruby не взлетів, тому що DSL погана ідея
На мою думку максимум можна було б сказати, що DSL не підходить для загальної розробки для вебу, якщо б був би такий же самий фреймворк як ROR, але без DSL який «взлетів». DSL не прижилися в вебі, але досі використовуються в інших галузях. MVC фреймворки домінують через успіх RORу, який дозволив взлетіти Ruby на деякий час.

Дайте означення «взлетів» та «не взлетів».

Стрімко, часто неочікувано, поширився у використанні.

В моїй реальності Ви ствердужуєте:

ні, я просив вас надати приклад з вашої реальності де
ви ж не згодні з моїм
— факт — DSL не взлетел.
— щось не співпадає з реальністю.

ви надали
— а от є Ruby!
моє
— так сам Ruby не взлетів

а якщо ви кажете:

Ruby не взлетів

то

Я лише хотів вказати Вам, що Ваше твердження неправильне

то DSL в ньому не можна використати проти тезіса

— факт — DSL не взлетел.

тому що DSL погана ідея

поки не з’ясуємо — ми в одній реальності живемо чи в різних — нема сенсу переходити до аналізу причин явищ

приведіть данні з в вашої реальності, котрі свідчитимуть що DSL стрімко поширюється у використанні (чи мав такий період, і вийшов на плато стабільності на графіку хайпу)
і є звичайним явищем при розробці ПЗ

Стрімко, часто неочікувано, поширився у використанні.

Рубі однозначно взлетів після створення ROR d33wubrfki0l68.cloudfront.net/...​-stackoverflow-trends.jpg

Чому він зараз не «на висоті»? Тому що є краще аналоги, які взлетіли і забрали частину його користувачів. Чи став взлетів/невзлетів має бути бінарним і зберігатися весь час?

приведіть данні з в вашої реальності, котрі свідчитимуть що DSL стрімко поширюється у викорстанні (чи мав такий період)

Я таке стверджував?
DSL це нішеве рішення і не повинно використовуватися, там де воно зайве. (Вода мокра, небо синє etc)

поки не з’ясуємо — ми в одній реальності живемо чи в різних — нема сенсу переходити до аналізу причин явищ

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

Рубі однозначно взлетів після створення ROR

а яким полупярним був Basic!

DSL це нішеве рішення

ну і я про це
Просто йому пророчили велике майбутнє.
Але — факт на зараз — це нішеве рішення

Чи став взлетів/невзлетів має бути бінарним і зберігатися весь час?

на кривій хайпу нема бінарності

Різниця між піком хайпу та плато продуктивності і є показником — взлетів чи не взлетів

Як на мене — коли X обіцяв знищити Y, а по факту Y поширився а X зменшується — то
X не взлетів.

Якщо X обіцяв те зробити за рахунок властивості D, а ні отой Y, ні інші Z, W, V не взяли собі оту властивість D, то
D — не взлетіла

Мертва мабудь Ada, але не впевен

Ну... говорят до 99% исходников Boeing 777 на Ada (proof). Последний стандарт Ada 2012 года (не так уж и давно), там было заимсвовано несколько идей из Eiffel (например, контрактное программироние) которые позволяют верифицировать код (математически доказывать, что он обладает некоторыми свойствами).Ну и новости на сайте adacore.com достаточно актуальны по датам.

заимсвовано несколько идей из Eiffel (например, контрактное программироние) которые позволяют верифицировать код (математически доказывать, что он обладает некоторыми свойствами)

Читаем книгу автора
Бертран Мейер. «Объектно-ориентированное конструирование программных систем»

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

И далее Бертран Мейер пишет:
Понятно ваше нетерпение и желание незамедлительно узнать, каков же эффект от утверждений при выполнении программы; ... Полный ответ на этот вопрос дать еще слишком рано, но предварительный использует любимое словечко адвокатов — это зависит (it depends).
Это зависит от того, что вы хотите. Можно рассматривать утверждения просто как комментарии, и тогда их нарушение не обнаруживается в период выполнения. Но их можно использовать для проверки того, что все идет по плану. Тогда во время выполнения окружение автоматически следит за выполнением утверждений и включает исключение при возникновении нарушений, завершая обычно выполнение и выводя сообщение об ошибке. Можно включить в программу обработку исключения, пытающуюся восстановить ситуацию и продолжить выполнение.
(конец цитаты)
То есть

Контрактное программирование призвано
1. не столько «верифицировать код (математически доказывать ...)» - а внести в код утверждения из спецификации к ПО, приблизить программный код к тексту спецификации
Для этого достаточно посмотреть на примеры использования — там не пахнет «математическими доказательствами, что он обладает некоторыми свойствами».
2. не является обязательным даже в Eiffel (хотя сам Мейер не раз высказывался что не понимает как можно говорить о промышленной разработке ПО без использования контрактного программирования. Кажется в книге «Пионеры программирования. Диалоги с создателями наиболее популярных языков программирования» Федерико Бьянкуцци, Шейн Уорден)

Ну... говорят до 99% исходников Boeing 777 на Ada (proof). Последний стандарт Ada 2012 года

жив значит.
просто — не взлетел :)

Ну... лучше взглянуть на SPARK. В частности, SPARK может доказать, что некоторый фрагмент кода свободен от таких ошибок, как выход индекса за пределы массива, выход за границы, деление на нуль. Так что идеи Eiffel были развиты дальше.

как выход индекса за пределы массива, выход за границы, деление на нуль

да, великое достижение :)

мне б такие проблемы :D
вернее они были когда был трейни на C
По Stack overflow мои программки завершались часто
Со временем перестали конечно :)

обычно то баги у программ другие.
эти как раз выявляются и фиксаются довольно быстро

вообще, многолетние труды функциональщиков на почве статической проверки выхода индекса за пределы массива мне часто напонимают народную притчу:

Будда с учениками сидел у реки и ждал лодочника. Появился йог, который перешел несколько раз по воде, и с пафосом обратился к Будде с вопросом:
— Ну, а ты, Просветленный, так можешь?
На что Будда спросил:
— Сколько времени ты затратил на то, чтобы достичь этого?
— Почти всю жизнь я затратил на то, чтобы научиться, провел много времени в суровых аскезах.
Пришел лодочник и Будда спросил его:
— Сколько стоит переправа?
— Три гроша, — ответил лодочник.
Будда, повернувшись к йогу, сказал:
— Слышал? Вот столько стоят все твои усилия.

эти как раз выявляются и фиксаются довольно быстро

Проблема в том, что иногда невозможно проверить программу runtime. Стоимость такой ошибки может быть равносильна стоимости самолёта или запуска к Марсу. Классика же:

Фирма Motorola испытывала новый процессор для автопилота на истребителе в Израиле. Всё было отлажено. Пилоты на испытаниях отправились «огибать рельеф» с севера до юга Израиля. Истребитель прекрасно пролетел на автопилоте над равнинной частью, над горной частью, над долиной реки Иордан и приближался к Мёртвому морю. Однако при подлете к нему неожиданно происходит общий сброс процессора, автопилот выключается на полном ходу, пилоты переходят на ручное управление и сажают истребитель.

Процессор отправили на доработку и тестирование. Все тесты прошли снова без сбоев. Снова начали реальную проверку. Истребитель пролетел над всеми территориями, но при подлете к Мёртвому морю ситуация повторилась: общий сброс, выключение автопилота, ручная посадка.

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

Или

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

Или

Причиной взрыва 4 июня 1996 года европейской ракеты-носителя Ариан-5 была программная ошибка. В системе управления ракеты использовалось модифицированное программное обеспечение ранее успешно работавшее на Ариан-4, но Ариан-5 ускорялась быстрее предыдущей модификации. В результате, когда на 40-й секунде полета одна из вспомогательных подпрограмм попыталась преобразовать длинное целое значение в короткое без проверки величины значения, то вышло за границы типа, произошло отключение системы управления ракеты, и она была взорвана по команде на самоликвидацию. Вместе с ракетой-носителем был потерян коммуникационный спутник. Ущерб от этого программного сбоя был оценен в полмиллиарда долларов.
Проблема в том, что иногда невозможно проверить программу runtime.

иногда всякое бывает

Стоимость такой ошибки может быть равносильна стоимости самолёта или запуска к Марсу

у таких проектов и бюджеты другие

Классика ж:
мало какой проект можно разрабатывать по стандартам NASA

Уже писал:
Разработка ПО подчиняется почти тем же ресурсным ограничениям как у других производств
Деньги, время, люди

Разработка ПО — это промышленное производство, со всеми требованиями к нему.
Например — никогда, ни в какие века промышленность не ждала пока наука что-то откроет, достигнет, и т.п.
Открыла, можно в дело взять? берем
Нельзя? будет через надцать лет готово? не берем.
для вот этой красотени нужно использовать нанотрубки? стоимостью ...?? не берем, будем делать с говна и палок — потому что с вашими нанотрубками не окупится
и все

А ваши примеры — это выковыривание изюма из булочки — выбор крайне специальных и очень дорогих проектов.

И пусть предлагающие улучшения с помощью нанотрубок сколько угодно попрекают производство с говна и палок
делаться будет с того что окупает себя, с учетом огнаничений:
деньги, время, люди

И то

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

ну а если бы пришло — то и деления на 0 бы не было.
то есть имеем проблему еще с уровня формирования требований и спецификаций.

Причина оказалась в том, что только он заходил на цель с точностью, превышавшей машинную точность

теоретики не учли способ хранения значений с плавающей запятой в реальном устройстве?
инженеров может надо было спросить?

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

опять реальность не была учтена

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

ну а если бы пришло — то и деления на 0 бы не было

Вот и задача верифицирования обращать внимания на такие места, которые не пришли никому в голову. В данной ситуации верификатор бы указал на то, что в данном месте возможно деление на нуль. Анализ показал бы, что деление на нуль возникает при высоте ниже уровня моря. А далее уже решали бы, возможно такое или нет.

Но и тут — а что с этапом тестирования?

Идея верификации состоит в том, чтобы отловить ситуации, которые никому не пришли в голову. Но могут случится. Как тут поможет тестирование?

В какой машинный код превратится проверка типов?

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

Так что такие ошибки таки случаются, и верификация кода это одно из стредств поиска. Опять же, SPARK активно развиватеся и активно используется в своей среде (гражданская авиация, военная авиация, системы контроля воздушного трафика,медицина, космос). Вот презентация с фичами.

Вот и задача верифицирования обращать внимания на такие места

на такие места обращает внимание аналитик
а если он не обратил
то при разработке случай не будет учтен.

В данной ситуации верификатор бы указал на то, что в данном месте возможно деление на нуль

и так как в спеке эта ситуация обозначена как невозможная
то верификатору бы «заткнули бы рот», и все.
никто не дал бы добро на ненужное расширение типа.

Идея верификации состоит в том, чтобы отловить ситуации, которые никому не пришли в голову.

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

Как тут поможет тестирование?

они минимум — надежнее, потому что тестируется уже собранная транслятором система или ее часть
а не на уровне статического анализа кода — логические неувязки

В случае верификации мы получим конкретное место, где может произойти выход за границы

если дома предлагается строить с учетом возможного падения метеорита — то предлагающего обзовут как-нить нехорошо

так и тут — если применение такой проверки приводит к существенному удорожанию разработки а то и ее сроков — то никто не будет внедрять такие дорогие способы

если при прочих равных к удешевлению, уменьшению сроков — то и рекламировать не надо — похитят сразу после доклада о преимуществах :)

Так что такие ошибки таки случаются, и верификация кода это одно из стредств поиска

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

Вот презентация с фичами.

полистал презентацию

(гражданская авиация, военная авиация, системы контроля воздушного трафика,медицина, космос

не увидел

но уже писал — бюджеты и сроки в этих областях как правило весьма большие. как и требования к надежности.
могут себе позволить? ок

и то, думаю что в этих областях ПО пишется на С, с, может быть, частичной кодогенерацией с хаскель или еще какого окамла

но далек. надо спрашивать тех кто разрабатывает.

а я уже с первой работы, на которой на С мы писали систему продажи билетов(GUI тоже на С, TurboVision еще не родился) — работаю в области финансово-экономического ПО

и поэтому никак не вижу — чем такие мелкие проблемы которые решает SPARK помогут в моей области.
Если уж прогонять спеки с бизнес-логикой на правильность, то Prolog куда более к месту. Но... не слышал о массовости применения Prolog для верификации хотя бы непротиворечивости бизнес-логики.

работаю в области финансово-экономического ПО

Мир не ограничивается финансово-экономическим ПО, понятно что в ващем случае цена ошибки в продакшене не измеряется миллионами долларов, если это не blockchain :)

Мир не ограничивается финансово-экономическим ПО

ну да, мир ограничивается разработкой ПО для авиации и космоса :)

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

вы привели примеры где цена высока
и?
там на чем софт пишут?

А вообще в эмбедед — на чем пишут?

ну или вот Linux
какова цена сбоя в ядре Linux?

когда ждать версии на «SPARK»
Ведь сам автор С назвал этот ЯП — опасной бритвой.

и еще раз о
— цена ошибки в продакшене не измеряется миллионами долларов
не смешите этими копейками
вот загуглите — Провалы внедрений ERP
Target — американская торговая сеть, крупнейший после Wal-Mart дискаунтер в США: 350 тыс. сотрудников, около 1,8 тыс. магазинов. В январе 2011 года компания анонсировала свой выход на канадский рынок, где к 2014-му планировала открыть не менее ста торговых точек.
...
Три года во внедряемом решении фактически отсутствовала подсистема верификации данных.
«Как потерять семь миллиардов из-за ERP-проекта»

Вы просто не в курсе о цифрах в мире ПО для бизнеса

но видать ТНК и не очень — нищеброды, раз не могут купить прекрасные решения на «SPARK», Haskell, ...

там же деления на 0 не бывает, и выход за рамки массива УЖЕ контролируется на этапе компиляции — верно?
пробелы вместо табов — это очень важно!

Это вообще что такое? Что за язык Как определены = и ==? Какая алгебра литералов с точками? ...

придумал как проще пояснить

есть старая байка:
197* год, вступительный по физике в некий политех.
принимающие заскучали колебаниями между «4» и «5», и
— Ладно, последний вопрос: С какой скоростью должна бежать кошка, чтоб не слышать звука консервной банки, привязанной к ее хвосту?
— Со скоростью звука, — не задумываясь выпаливает абитуриент, — 340 м/с.
— Идите, юноша, «4».
— ???
— Мы тут инженеров готовим, а не теоретических ученых. Тут думать
практичнее нужно — кошка с такой скоростью не бегает. Т.е. правильний
ответ — скорость должна нулю быть равна. Стоять кошка просто должна! Вот
так-то...

Так вот, насчет

if (0.1 + 0.2 == 0.3)

теоретик начнет рассуждать

Какая алгебра литералов с точками?

а инженер посмотрит в стандарт IEEE 754 описывающий формат представления чисел с плавающей точкой.
и — либо будет округлять при подобных сравнениях, либо перейдет на целочисленную арифметику

в этом то и разница между
теоретиками и практиками,
наукой и инженерией

Зануды вроде меня предпочитают всё иметь расставленным по местам

я тоже зануда. только на других уровнях абстракции :)

Но обратное не обязательно верно

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

Я все же сказал бы, что большинство хороших математиков могут стать хорошими программистами

а офицеры — солдатами

из чего делается вывод
надо солдат заменить офицерами и мы получим лучшую армию!

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

ну а пока идет холивар
пишется софт. работающий.

не соответствует правда высоким идеалам функциональщиков.
ну идеалистам то никогда нельзя угодить

а офицеры — солдатами

из чего делается вывод
надо солдат заменить офицерами и мы получим лучшую армию!

Тем не менее, этот процесс все же постоянно происходит, потому что в академической науке для математиков работы не хватает, а жрать что-то надо. В основном идут в мл/дс, но некоторые как раз начинают торговать воздухом под видом элементарной галиматьи «категория, функтор, монада».

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

да, и как скалисты говорят
заипал наплыв хаскелистов, с их упоротостью

Это те, что на Scala продолжают писать на Java? Ну, микроскопом можно и гвозди забивать при желании, да. Я не знаю концепцию чего вы защищаете, что язык должен быть понятен размороженному неандертальцу? Так ни ООП ни процедурный подход, как показывает практика, не решают этой задачи аж никак. Цели убедить лично вас не быть предвзятым у меня нет, так что дисскусия начинает быть скучной.

Я не знаю концепцию чего вы защищаете

никакую

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

Это те, чте на Scala продолжают писать на Java?

невежды конечно :D

сто бед — один ответ: Я дартаньян а вы пида-сы!

Это ж ваш главный аргумент, не так ли? ;)

не ваш лично, а типичного функционгальщика несущего свет Знания в массы.

такая схема холивара об ФП, сколько их не читал, и не участвовал :)

Я все же сказал бы, что большинство хороших математиков могут стать хорошими программистами

Ага, и при этом большенство тру математегов продолжает писать очень убогий код на своих питонах.

Это не тру, это современные местные датасатанисты и машинлеминги.

Но питон очень неплох, как язык для склейки модулей с математикой (которые почти все на С++ обычно, иногда на фортране).

И ФП концепции тут гораздо очевиднее, чем магия на регистрах процессора, мютексах, и таблице виртуальных методов. Я не хочу думать, где что хранится, я хочу думать о том, что оно делает, и, если я ошибусь, забыв об этом, чтобы компилятор меня поправил.

Ага, ток когда дело доходит до реального IO, и реального паралелизма, чет выясняеться что оно должно выполняться на

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

и карточный домик разваливаеться.

Скорее оборачивает стрёмную архитектуру процессора в легко используемые абстракции. Мне же не компиляторы под x86/amd64 оптимизировать. Те кому это интересно, этим и занимаются, что тоже может быть весьма занятно.

И тут оказывается, что для твоего кода нужно железо за 2000 бачей, а клиент согласен только на 200. И тут уже всплывает задача по оптимизации любыми способами.
Дело в том, что клиенты нужна 1000 таких железяк, а не одна.

для расчета скидки на товары не нужен матаппарат.
достаточно знания арифметики на уровне младших классов.

ничего такого сложного бизнес-системы не считают.

скидка на пицу 20% но это «бонус» от текущего заказа на заказ следующий причём в абсолютном значении сможешь привести математический ряд с доказательством схождения дающих цифру реальной скидки при условии одинаковой покупки каждый раз?

математики — плохие программисты.
как и инженеры.

в этом же ж и жопа что обратное тоже прямо верно

причём в абсолютном значении сможешь привести математический ряд с доказательством схождения дающих цифру реальной скидки

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

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

ни для сведения бух баланса, ни для оперденя, ни для формирования BOM для отдела поставок на основе договоров от дилерского отдела, ни для распредления призового фонда и прочих коэфов в гемблинг разработке

и опыт холиваров показывает, что когда начинаешь спрашивать — а как мне вашу штуку прикрутить «математики» либо не понимают о чем речь, либо скисают, и отвечают как филин мышам

Я не тактик — я стратег!!!
но если уж поняли какая полезная штука, то нужно
разогнать всю команду
набрать другую
переписать все с нуля
И будет вам счастье!

Но меня прикалывает даже не это.
Ладно когда филин — это какой-нить Пол Грэм

а часто густо то в филины себя записывают студенты старшекурсники :)
или программисты застрявшие на уровне мидла.

Ничего ужасного на самом деле нет. Есть очевидные свойства самих механизмов, которые могут стать недостатками в определённых условиях, и есть табун крикунов, которые эти условия выпячивают как тотальное свойство мироздания и после этого обхаивают всё. И ещё есть абьюзинг самих механизмов, который стал нормой в некоторых традициях (кто сказал слово на J?), потому что некоторым авторам нравилась получаемая выразительность.
Но недостатки, которые существенны в 5% случаев, преподносятся крикунами как проблема для 100%, и они очень громко орут.

Может все постоянно усложняется из-за ловли неловимок?
Квантовое значение появляется в процессе работы. Не до, ни после. Только в процессе когда что-то меняется на что-то другое, в процессе смены состояний. Можно сказать, что между состоянием ДО и состоянием ПОСЛЕ полно эдаких молний квантовых значений. Если их ловить с помощью языковых конструкций то получается ситуация перебора не просто большого числа вариантов, каждая новая языковая конструкция добавляет вам неловимок.

Ну вот жеж — виртуальные функции! — Без процесса ни хрена не понятно. Неловимки.

Пожалуй, это самый непонятный и самый сложный комментарий из тех, которые мне довелось прочитать под этим топиком)

Зацени еще — неловимки это Морфеусы, когда они прятались от агентов Матрицы между двумя стенками. Вот стенка первая, на которую смотрят агенты это или состояние ДО или состояние ПОСЛЕ (тут все зависит от направления стрелы времени) и агенты не видят Морфеусов.
Потому как Морфеусы спрятались, потому как агенты перед первой стенкой находятся, а Морфеусы за нею.
Это реально охренительно, когда нечто появляется как результат того, что некий процесс осуществляется в настоящий момент времени — словно флажок устанавливается в регистре процессора. И только на время взаимодействия. Потом снова в фалсе сбрасывается.
Чеширский котенок.

Без контекста не распарсить, ассоциации или случайны или нелогичны.
Если моя догадка верна, и имеет место быть шизотипическое расстройство личности, то это с одной стороны грусть и печаль, т.к. затрудняет общение шумом, а с другой — у таких людей удивительный талант построения нетривиальных аналогий и проведения неожиданных параллелей. Мои извенения, если это оценочное суждение в какой-либо степени некорректно.

А что такое «извенения» ?
Боюсь моя шизофазия не совсем понимает...

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

Все ок.
Вы спите на яву. Потому что опечатки у вас. Что касается фазии мне нра так и не нра как все. Тут есть особый смысл — слова приходят неупорядоченно в голову, потом выкладываются в виде неупорядоченного предложения, а упорядочивать это труд. Теперь к вопросу опечаток — сон на яву свойственен часто грезящим о чем-нить индиви, чем-то увлеченным наприме
Тогда буквы опережают друг друга.
Я сделал специально много в данном коммента.
В общем, я контролирую свою шизу чуть больше чем полностью, она для меня как звуковая отвертка для Доктора Кто. (правильнее отмычка)
Я убежден что шизофрения — это немерянная мощь, которая будучи примененная в кодировании и декодировании (а где же еще) может принести неслыханные барыши.
Это особенно обидно, потому что сейчас сижу голодный и без работы и при этом очень стараюсь думать о людях и социуме хорошо.

не так дуже давно читав книгу Ніклауса Вірта «Алгоритми та структури даних». Там він наводив приклади чому ООП це погано і як класно вирішувати задачі в процедурному стилі за допомогою його мови Оберон 2. Але його вирішення задач нічим не відрізнялись від рішення за допомогою ООП. Для мене це виглядало як просто самореклама його мови

Почему когда встает выбор между разработкой на C или C++, предпочтение скорее отдадут C

На С быстрее начать писать, потому что не заморачиваешься на OAL/HAL, и большинство архитектурных решений очевидны (делается «в лоб»).
На С++ нужно написать себе комфортные абстракции над всем вокруг (ОС, железо, чужие библиотеки) и служебные классы, что занимает пару месяцев. Зато потом писать относительно просто, удобно, и так, как хочется.
Поэтому для мелочи (где-то до 10 000 строк) — Питон или С, для более крупных — С++ или Джава (у С++ вместо стандартной библиотеки какие-то фрагменты батареек).

Так хотел именно по этому поводу накатать огромных размеров простыню да никак не соберусь. Но чувствую что всё же надо.

Физ-ру собери на завтра для начала.

Я сужу по твоему юношескому максимализму в этой теме.

Якщо буде англійською — можна буде викласти на www.reddit.com/r/programmingcirclejerk !

Я тебе помог ;) Хороший совет, кстати, про недо-тайпклассы. Если есть желание, можешь дополнить, или исправить, там много спорных моментов, и много экспрессии, но это dou, так что писал в стиле «вброс», рассчитывая, тем ни менее, обрисовать в целом от чего у тех, кто знаком с альтернативами — подгорает.

«Замечательной особенностью обьектно ориентированного программирования
является возможность с помощью него
превращать небольшую, несложную задачу
в серьёзнюу, крупную проблему»

Да, есть паттерны, да, есть наследование, да, есть суперштуки агрегация/композиция.

Плюс: максимально прозрачная архитектура(если конечтно к делу подошли с душой)
Минус: 100500 классов(всегда, вне зависимости от отношение программиста)

Но ООП, это всего лишь подход. И функциональщина — подход ..... , а то, почему многие его не любят => читаем про «Golden hammer»

максимально прозрачная архитектура

Зачастую это наглая ложь.

если конечтно к делу подошли с душой
если конечно к делу подошли с душой

почти всюду душу не используют, наляцкивают еле-рабочий код чтобы втюхать как бизнес валуэ. А всё потому что ООП-императивными методами делать что-то прозрачное требует титанических усилий, а надо в прод лить и на вчера. Зачем что-то делать хорошо если можно наляцкать и продать(minecraft каноничный пример, загляните в деобфусцированные сорцы, в любое место там можно свалится. Даже forge лучше написан, хотя по сравнению с тем что я пишу и читаю — кусок самизнаетечего)?

Сколько строк в том, что ты пишешь и читаешь?

Сколько строк в том, что ты пишешь и читаешь?

Сейчас бы мерять сложность проекта количеством строчек.
Количество строчек не играет такой особенной роли. Даже ядро линукса разрезано на кучу модулей upload.wikimedia.org/...​5/5b/Linux_kernel_map.png. И именно по этой причине, работая над проектом с 5 млн. строчками кода, в каждый конкретный момент ты работаешь с маленьким его кусочком в виде модуля, который хорошо изолирован от других таких кусочков и имеет связи с другими модулями в строго определённых местах. Со всеми 5 миллионами строчек кода одновременно не сможет работать ни один человек(человекочасов там понадобится больше чем человеческая жизнь) — даже в том же ядре есть мэинтейнеры этих самых модулей. Так что не стоит спрашивать одного-единственного человека про размер кода который он читает и пишет. Это раз.

Во вторых, я пишу на таком языке который позволяет сокращать вещи которые обычно в мейнстримных языках занимают О(количество фич) строк кода до О(1). Мне не нужно писать ручками кодеки, валидаторы и вообще много чего мне не нужно писать, за меня это делает сам язык, компилятор и либы(слава обобщённому программированию). В большинстве мест, код который занимает 200 строчек с хорошим форматированием, на условной джаве будет раздуватся 1200+ строк. Мне не нужно страдать адом дебага, ибо у меня есть компилятор и типы, и проверенные матемаикой абстракции. Это два.

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

То что мы юзаем, в мейнстриме почти не юзается, и твоя метрика просто не имеет ни малейшего смысла.

Алсо, галеры на моём языке по 600 человек на одном проекте — есть. И там всё хорошо, просто эти проекты не опенсорс, по этому ты там ничего не подсчитаешь.

язык, компилятор и либы(слава обобщённому программированию)

Либы еще на новый язык не переписали? Они же от этого лучше станут?

Мне не нужно страдать адом дебага, ибо у меня есть компилятор и типы, и проверенные матемаикой абстракции.

Вот это уже занятно. Компилятор проверяет корректность бизнес-логики?

новый язык не переписали

их не переписывали, их на нём написали.

Компилятор проверяет корректность бизнес-логики?

Если писать на Coq, то именно так и будет, твой код — конструктивное доказательство того что программа работает соответственно спецификации. Потом можно вытащить из этого доказательства код на одном из мейнстримных языков. На Coq я конечно же не пишу, но пересадить хотя бы какую-то часть логики на типы вполне возможно(спасибо, изоморфизм карри-говарда).

конструктивное доказательство того что программа работает соответственно спецификации

согласно спецификации
Скидка в размере X предоставляется при покупке свыше Y

для проверки этого утверждения нужен Coq?

Потом можно вытащить из этого доказательства код на одном из мейнстримных языков

и кому нужно писать на Coq, чтобы получить в итоге одну строчку, которую можно было написать и вручную, согласно спецификации:
Скидка в размере X предоставляется при покупке свыше Y

Ох уж эти «математики»...

и кому нужно писать на Coq, чтобы получить в итоге одну строчку, которую можно было написать и вручную, согласно спецификации:

Где гарантия того, что эта строчка будет работать правильно? Тесты такую гарантию не предоставляют.

вы даже не поняли о чем речь :)

но после сильной аргументации в виде мемчиков в другом посте — оно и неудивительно :D

Вы писали, что не дебажите.
Мне отладка нужна в 85% случаев для решения проблем бизнес-логики.
Вывод: у Вас слишком простая бизнес-логика, и она вся документирована и заморожена в спецификации.

Вывод: у Вас слишком простая бизнес-логика,

veralline.com/...​2017/07/05/683dc9b857.jpg нет, спецификации изначально не было как таковой. Её пришлось изобретать самостоятельно и проводить по этому вопросу длинный и трудоёмкий рисёрч.

и она вся документирована и заморожена в спецификации.

www.meme-arsenal.com/...​03d7aa7b83f2b9a76a4ad.jpg Часто меняется, и иногда неожиданным образом.

Вы писали, что не дебажите.

Я писал что у меня нет ада отладки. В большинстве случаев мне достаточно входа и выхода определённого куска кода, который обычно логгируется, чтобы объяснить что тут произошло и где править. За последние пол года мне понадобилось лезть в степ-бай степ всего один раз чтобы найти баг в десериализаторе замороченного бинарного формата.

А у кого есть ад отладки?
Если его ни у кого нет — зачем писать?

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

Это — признак локальности логики. Нет асинхронных сценариев, которые могут зависнуть либо привести к неожиданным результатам.

Мне не нужно писать ручками кодеки
их не переписывали, их на нём написали.

То есть, аудио и видео кодеки уже написаны не Расте? Или у Вас там обработка текста?

Или у Вас там обработка текста

или у нас там обработка байтиков, но довольно запутанная.

отчасти вы правы, отчасти нет. Пускай для вас я останусь романтиком, который при любом удобном случае предпочтёт сделать(насколько мне позволяет моя квалификация) свою работу качественно, но долго, чем на тяп-ляп и «пацаны ля какой кАстыль».
P.S я говорил про разработку не на от**** с самого начала, если у вас редко такое встречается, это тоже вполне себе норма, просто не нужно загонять ветку коммента в одну-единственную свою среду

Предпочитаю делать

свою работу качественно

насколько позволяет время, но быстро. Но не все люди так думают. Вон в Гугле подход к качеству имплементируемых фич — 0.7 от возможного качества.

Ирония в том, что в итоге такого отношения менеджмента к требованию качества в индустрии приводит к системам по качеству приближающихся к 0 (0.7 * 0.7 * 0.7 * 0.7 * ...).

отдадут C(например, драйвера, ОС, бд и тд).

Ну в случае с драйверами не могу представить ситуацию как это наложить на классы)

Построить ADT можно на любом языке, на самом деле вопрос тут один — оверхед на интероп.

А в чому проблема створити класи під абстракції в ядрі? Apple використовує С++ в IOKit, а Microsoft в
WDF. Ми у себе (в apriorit) широко використовуємо ООП для драйверів.

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

На С++ можна писати без віртуальних функцій, без ексепшенів і навіть без STL.

С++ дозволяє використовувати RAII. Ну і зручніше мати класс UnicodeString і бачити всі методи, що з ним працюють, чим полотно окремих С-шних функцій.

Це зветься
C with Classes

Якщо вам так зручніше. Звісно, що це підмножина С++. Але лямбди, темплейти і т.д. — все чудово працює і допомогає писати менше кода.

меньше — далеко не всегда лучше. Наследники твоего легаси с шаблонами потом тебя не раз вспоминать будут. И далеко не факт, что хорошим словом, если суёшь их куда не попадя.

меньше — далеко не всегда лучше

Менше кода — менше багів. Менше кода — простіше його читати.

Наследники твоего легаси с шаблонами потом тебя не раз вспоминать будут

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

P.S. До того ж С — це завжди ручне керування ресурсами, а там ой як легко зробити помилку.

P.S. До того ж С — це завжди ручне керування ресурсами, а там ой як легко зробити помилку.

Это норма для С. То что текут, блокируются ресурсы — это ни кого давно не удивляет. Правда ОСи уже умные и стараются подтирать за такими пейсателями жопы где только возможно.

Менше кода — менше багів. Менше кода — простіше його читати.

Нифига. 20 строк С часто лучше читаются, чем 5 строк С++. Про функциональщину молчу.

До того ж С — це завжди ручне керування ресурсами, а там ой як легко зробити помилку.

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

И что это у тебя за код на С на 20 строк. Опросить один датчик на ардуинкке?

А вот в реальных проектах код на С++ легче читать, чем на С.

В С в одну строчку меньше влазит. В С++ больше. В Питоне — вообще страх какой-то.

Питон — это интерпретатор со всеми вытекающими. Но я тебя могу обрадовать его всё больше и больше в ембединг впихивают — тормозит по жести. Но зато после можно долго оптимизировать и переписывать куски на С и С++.
И причем тут сколько в строчку влазит?
Речь же о компилируемых языках.

Речь о том, что полотно-столбик на С проще читать, чем квадратный метод на С++

Нет. В С++ обычно по файлам раскидывают, а не одной большой простыней пишут.

В этом случае даже пытаться читать на стоит

А я вот китайскому стили на простынях не обучен — и вообще он меня бесит. Такой вот я расист.

А вот в реальных проектах код на С++ легче читать, чем на С.

Конечно же нет! Похоже, что ты ни разу не видел С++ кода в ембеддеде. Основная жопа С++ в драйверах и при работе с железом это наследование.

sensor объявлен как базовый класс.

sensor->readdata(...);

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

Думаешь с говнокодом на С лучше — там вообще атас, если найти что-то нужно.

sensor->readdata(...);

Не смешно. Если фабрика, то понятно где искать. Если pimpl тоже.
А вот в С повесишься искать.

Ну и эта абстракция имеет смысл, если у тебя куча сенсоров и работа с ними одинакова.

Думаешь с говнокодом на С лучше — там вообще атас, если найти что-то нужно.

Ставишь бряку и смотришь, кто вызвал.

И в чем отличие с С++?

Ставишь бряку и смотришь, кто вызвал.

Но в С++ легко из без бряки.

Но в С++ легко из без бряки.

Наш опыт не совпадает.

Ага. Дело в том, что програмить я начинал еще с калькуляторов. И могу писать и на С и С++ (и крестиком вышивать тоже умею) и уже давно избегаю многословия и непонятностей в коде. Код пишется не для компилятора и процессора, а для того, кто после тебя его читать будет.

Более того в том же матлабе я использую ООП там, где мне нужно.

А в эмбединг не лезу потому что оное мне не нравиться с софтовым исправлением глюков железа.

Я когда-то неделю разбирался, почему в новой версии Хромиума старый рендерер перестал работать. И вот без бряки ничего не помогает. С брякой хотя бы стек видишь. И так — неделю. Это — С++.

Если бы там был С, ты бы и с бряками месяц провозился бы.
Найди где и кто там память похерил.

сейчас для этого есть valgrind, если софтина не сильно прожорливая

Он очень давно есть, но панацеей так и не стал.
Но ты не поверишь, я им очень очень редко пользовался. Не удобен он мне, да еще FP море выдает.

BTW любопытно, не использовал ли кто из уважаемых господ сишников недавних достижений цивилизации в лице compcert.inria.fr и fbinfer.com (оба вроде на OCaml писаны), и как оно им, наскольно рабочее?

Ну... там часто ООП и виртуальные функции, только реализованные ручками через указатели на функции:

struct dentry_operations {
   int (*d_revalidate) (struct dentry *, struct nameidata *);
   int (*d_hash) (struct dentry *, struct qstr *);
   int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
   int (*d_delete) (struct dentry *);
   void (*d_release) (struct dentry *);
   void (*d_iput) (struct dentry *, struct inode *);
   char *(*d_dname) (struct dentry *, char *, int);
};

В реальности, все гораздо хуже, чем на самом деле.
Joe Armstrong (создатель erlang) про OOP: www.cs.otago.ac.nz/...​fpriv/ok/Joe-Hates-OO.htm
Цитаты других «бородатых дядек» про C++: harmful.cat-v.org/software/c

Собственно, OOP и C++ это как ржавые жигули — про их эпичность могут говорить лишь те, кто не видел нормальных автомобилей (ie не осилил выучить другие языки и методологии)

например какие?

И что большое на них написано?

github.com/...​ritytech/parity-ethereum, эрланг юзают телекоммуникационные компании в софте который должен работать без даунтаймов. Хаскль- просто язык в котором всё сделано с умом.

где там статистика по количеству строк на разных языках?

Ищи сам, я за тебя ничего делать не собираюсь. Ты попросил, я дал, дальше сам.

Нафиг? Ты же доказываешь типа что раст на что-то способен? С++ уже давно всем доказал.

Ты же доказываешь типа что раст на что-то способен

Раст тоже доказал.

С++ уже давно всем доказал

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

А зачем это людям?

Я писал на Erlang, много.
Так вот — про какие-то суперпарадигмы, благодаря которым всё идеально лучше и без ООП — враньё.
ООП там в полный рост, просто объект = процесс (а иногда даже приложение, а не процесс) и обмен сообщениями. Иногда процесс — контейнер объектов.
«Без даунтаймов» лечится мерами, которые к объектности не имеют никакого отношения, а как раз к процессности. Причём новое поколение эти меры похерило и вместо этого полюбляет мастерить snap’ы через rebar/mad/etc, а на даунтайм им плевать.
Так что уже включение Erlang в этот список показывает, что вы просто не знаете, о чём говорите.
Про Haskell пусть расскажет, кто на нём пишет, но у него и у Rust фишка не в якобы отказе от ООП, а в расширяемости системы типов.

Ну это известно, что «Erlang is the Most Object Oriented Language» — blog.ryanlevick.com/...​object-oriented-language
Критика ООП — это критика «традиционной» мантры про инкапсуляцию, наследование и полиморфизм, а не оригинальных идей Алана Кея

Ну это известно, что «Erlang is the Most Object Oriented Language»

Смешное заявление.

Критика ООП — это критика «традиционной» мантры про инкапсуляцию, наследование и полиморфизм, а не оригинальных идей Алана Кея

Возможно. Но у идей Алана Кея свои, не меньшие проблемы.

На дворе 2019, а мы все меряем качество по строчкам кода?

Не качество, а количество)
На каких языках написаны браузеры?
Или офис?

Все 3 браузера и все 3 офиса?
Если С++ и используется в проекте (как правило, по историческим причинам), то это совсем не значит, что выбор языка был правильным, или что это (С++) хороший выбор на текущий момент. Из того, что я вижу, удел С++ это легаси, когда просто легче продолжать страдать, чем переписать. И достаточно легко составить список областей, которые С++ «просрал», имея доминирующее положение:

Desktop — теперь тут electron & javascript.
GameDev — еще остался, но вытесняется C#
Database — почти вся big-data и nosql это java, из того, что на С++ знаю только ScyllaDB, но не уверен, что оно production-ready.
Mobile — когда-то были WinCE, Samsung BADA, Symbian, Tizen, но кто про них вспомнит? Остались Java, Kotlin и Swift

Т.е. тенденции явно прослеживаются. Если знаете какую-то область, где С++ исторически не было, но он туда «просочился» — будет интересно узнать.

electron & javascript

тормозне гівно, шарпік і то краще. І на чому там сам electron написан і те, що жабаскрипт виконує?

GameDev — еще остался, но вытесняется C#

Хаха. AAA — виключно С++.

Database

Ніколи особливо не було.

Mobile

Нативне там теж буває, коли швидкість потрібна і це частіше С++, ніж С.

какую-то область, где С++ исторически не было, но он туда «просочился»

ML, HFT, у automotive он щойно вліз і у HPC присутній. Купа проектів у медицині ще є. Практично всюди, де швидкість критична, але ресурсів не так мало, плюс складність достатньо велика. Ядро ОС це таки доволі специфічний випадок.

ML

Разве что прослойка между Python/R и CUDA плюс математические библиотеки. Остальное в ML — Python и R во все поля.

Computer Vision з AR ще там, а його часто треба швиденько рахувати. І разом/замість Python/R теж буває.

Эмбедед. Исторически там был С, но памяти стало больше.

Desktop — теперь тут electron & javascript.

Лесом. Поэтому и пользуюсь тем, что написали задолго до смузихлебного безумия и поддерживают до сих пор.

GameDev — еще остался, но вытесняется C#

Посему и играбельны сейчас единичные за 5 лет игры.

Mobile — когда-то были WinCE, Samsung BADA, Symbian, Tizen, но кто про них вспомнит? Остались Java, Kotlin и Swift

В результате народ начинает покупать или самых дешевых китайцев или смузихлебы айфоны.

Да любые, на изучении С++ у многих развитие заканчивается.
Что интересно, былые светочи (Александреску, Маерс) из С++ давно ушли. Умные люди.

scottmeyers.blogspot.com/2015/12/good-to-go.html
en.wikipedia.org/...​Scott_Meyers#Publications
Кажись, решил, что пора перестать работать и начать жить. Публикаций по другим языкам не вижу.

Поэтому молодежь выбирает гироскутеры?

В них просто бомбить від того, який С++ афігєзний, а вивчити його вони не подужують!

Цей срач існує стільки, скільки існують мови програмування, в тому, чи іншому вигляді, не парься. Там де С++ є, там він і буде ще довго. Навіть Лінус Subsurface на С++ написав, і вінда таки на них написана. Нормально роби — нормально буде. З ООП легко впасти у єресь оверінжінірингу — то не треба такого робити. Нормально на це відповісти треба величезну портянку катати.

і вінда таки на них написана

Не припоминаю чтобы WinApi было на плюсах. Зато помню здоровые функции на 10 аргументов и структуры)

Пасиб, я видел сорсы .Net, не хочу снова шатать психику=)

И где этот COM теперь?
Еще BeOS вспомните

И этот COM теперь?

Ну как, где? А .NET — это что?

В книге Хорстманна про Java там куча примеров как было плохо в с++, как в джаве стало лучше

А ненависть скорее отого, что ничего не портит музыку, как ее фанаты. А фанаты ООП неадекваты еще те. Паттерны проектирования не знаешь??? Ты вообще не программист! И пофиг, что половина этих самых паттернов — это решение костылей самого ООП :D

И пофиг, что половина этих самых паттернов — это решение костылей самого ООП :D

Это решения, выстраданные на крупных проектах. Такого размера, о которых любители хипстерщины с проектами уровня сложности/размера «хелло ворлд» — знают лишь по наслышке, как о чём-то из паралелльной вселенной. Либо не знают вовсе.

Тут вон ниже, оратор приводит линукс-кернел с 5 млн строк, как пример крупного проекта. :)

выстраданные на крупных проектах

Большинство крупных проектов можно распилить на тучи маленьких модулей/микросервисов. От того что это не сделали — это вина архитектора что он допустил вот такой шар навоза.

Ага, чтобы всё это «разделённое» микросервисное говно — тут же выжирало всю доступную на машине память, да безбожно тоpмозило или вообще не шевелилось.

Это, если на одной машине. А если распределённое решение — так и вовсе не станет запускаться.

ут же выжирало всю доступную на машине память, да безбожно тоpмозило или вообще не шевелилось

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

всю доступную на машине память

один сервис — одна машина. На облачных хостингах так даже дешевле получается потому что можно брать кучу сдыхотных 1-4 ядерных хостов а не тачку на 32 ядра и за сотню оперативы.

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

Тебе парити этериум мало? Мозила переписывает свои компоненты на Rust: habr.com/ru/post/445670

Уже переписала? Уже сколько лет переписывает?
Сколько строк в парити этериуме? На других языках подобные проекты есть? Какой более зрелый и используемый?

Оно в продакшне?

Непоказательный вопрос. Движок современного браузера — это МЕГАсложная задача, реализовать которую займёт уйму времени на любом языке.

Есть факт, что С++ справляется с

МЕГАсложная задача

, а всякая функциональщина — неизвестно.

Можно же легко скачать Servo nightly build, зайти на www.servoexperiments.com и проверить.

Это уже не говоря о том, что Rust — далеко не чисто функциональный язык.

Two significant components used by Servo are based on existing C++ code from Mozilla. JavaScript support is provided by SpiderMonkey, and the 2D graphics library Azure is used to interface with OpenGL and Direct3D.

Получается, там лейаут, а не весь браузер уже.

Куски от него (парсер CSS) — в продакшне.

hacks.mozilla.org/...​ne-quantum-css-aka-stylo

Похоже, это не помогло догнать плюсовый хром www.phoronix.com/...​refox-quantum-bench&num=2

ну напиши браузер уже на расте

Так уже: github.com/servo/servo

Оно в продакшне?
ну если у вас костное закрепощение мышления растут и вы умеете только городить монолиты

Если на чём-то медленно крутится монолит — тот же монолит, в виде микросервисов, крутиться вовсе перестанет. Т.к. чудес не бывает.

Почитай, чем закончились потуги сделать микроядро — как замену традиционному ядру.

потуги сделать микроядро

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

потуги сделать микроядро

там было 3.5 анонимуса которые делали это чуть ли на голом энтузиазме. Тут по моему всё закономерно.

крутиться вовсе перестанет

ну чушь же собачья. Всегда микросервисы, если они правильно спроектированы, могут вертется в кластере, количество инстансов одного микросервиса можно увеличивать. С монолитом ты так по щелчку пальца не сделаешь.

Всегда...если
Доказано, что «всегда» возможно? Фаулер рекомендует сначала писать монолит, так как те, кто пытался стартовать с микросервисами, до продакшна не доживали.

Фаулер рекомендует сначала писать монолит

Ну мы не знали что мы до прода не доживём и дожили.

там было 3.5 анонимуса которые делали это чуть ли на голом энтузиазме. Тут по моему всё закономерно.

Их делали вполне реномированные универы — примерно так же, как и ядра юниксов 50-ю годами ранее.

Но ядра юникса есть и работают, а микроядра — оказались невзлетевшим говном,

Потому как, чудес не бывает.

Большинство крупных проектов можно распилить на тучи маленьких модулей/микросервисов.

Где доказательства?

Где доказательства?

Просто пойдите и почитайте статьи как это делается. Я за вас гуглить и обучать вас этому не собираюсь.

Статьи пишут теоретики, а код — практики.
Интересно, насколько быстро работал бы Хромиум, если бы его распилили на микросервисы.

Интересно, насколько быстро работал бы Хромиум,
распилили на микросервисы.

У тебя с головой всё хорошо? Я говорил о

на тучи маленьких модулей/микросервисов

. Распилка на модули имеет отношение к не-сервисам, а микросервисы имеют отношение к сервисам.
Распиливание на модули не привносит столько оверхеда. Это только архитектурный дизайн.

Туча маленьких модулей называется ravioli code. И пахнет)

Статьи пишут теоретики, а код — практики.

а в теории нет разницы между теорией и практикой!

а то что на практике она есть — никакому мальчику ссылающемуся на статьи и доклады не объяснить.

это ж как в старой статье Спецаильность — каменщик
И вот они становятся выпускниками. И получают степень бакалавра по профессии каменщика.

Их первое задание — «построить декоративную кирпичную стену».

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

но они будут доказывать о косности мозгов более опытным :D

Угу. А потім навколо розпиленого починають городити «обгортки», щоб воно все прогнозовано працювало. :)

Что забавно, с этим микросервисным хайпом, что Линус, Торвальдс который, давно уж сказал об обмане этой «мечты»

«Теоретически необходимость микроядра обосновывается следующим образом. Операционные системы сложны. Для их упрощения применяется модульный подход. Вся соль микроядра в том, чтобы оставить у ядра, которое является основой основ, как можно меньше функций. Его главная задача — обмен информацией. А все возможности компьютера реализуются в виде сервисов, которые обеспечивают коммуникационные каналы микроядра. Предполагается, что вы разбиваете проблемы на такие мелкие части, что вся сложность пропадает.

Мне это казалось глупым. Да, каждая отдельная часть получается простой. Но при этом их взаимодействие становится гораздо более сложным, чем при включении ряда сервисов в состав ядра, как это сделано в Linux. Представьте себе человеческий мозг. Каждая его составляющая проста, но их взаимодействие превращает мозг в очень сложную систему. В этом-то все и дело: целое больше частей. Если взять проблему, разделить ее пополам и сказать, что каждая половинка вполовину проще, то при этом вы игнорируете сложность интерфейса между половинками. Сторонники микроядра предлагали разбить ядро на пятьдесят независимых частей так, чтобы каждая часть была в пятьдесят раз проще. Они умалчивали о том, что взаимодействие между частями окажется сложнее исходной системы — при том, что и части сами по себе не будут элементарными.»

можно распилить на тучи маленьких модулей/микросервисов

распиливайте, кто ж мешает :)

Усложнение из-за неловимок. Хрен их обдумаешь.

именно.

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

но хайпующие о микро-(ядрах/сервисах/...) не в курсе что такое эти — эмерджентные свойства.
они просто верят, что главный секрет — в простоте элементов. и их число можно увеличивать — а конечная система будет такой же сложности как самый сложный элемент в ней.

отсюда и берется эта наивная мечта о тучах простеньких микросервисов которые сделают конечную систему проще, чем монолит
не знают они и того что систему нельзя сделать проще того что она «описывает». никакими методами.
сложнее да, можно.
но верят, что с них взять, они ж пока играются в слова и — простые идеи :)

Вот ты не поверишь, но я понял каждое твое слово и даже все словосочетания.
А самое приятное во всем этом, что ты описал экономику и то, что с ней делают в Украине. На другом, абстрактном уровне.

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

Что забавно, с этим микросервисным хайпом, что Линус, Торвальдс который, давно уж сказал об обмане этой «мечты»

фраза просто вырванная из контекста. Линус писал про непосредственно своё ядро, и свои представления о том как это сделать.

Но при этом их взаимодействие становится гораздо более сложным, чем при включении ряда сервисов в состав ядра

это называется распределённый монолит, это не то.

распиливайте, кто ж мешает :)

мне — ничего. Распиливание должно происходить по тем местам где наименьшее количество связей. Если таких мест нет — это спагетти и оно будет плохо работать в любом случае.

Распиливание должно происходить по тем местам где наименьшее количество связей. Если таких мест нет — это спагетти и оно будет плохо работать в любом случае.

Ok, cкажем есть в «монолите» какая-нибудь функция (в числе миллионов других). В «монолите» функция вызывается в едином адресном пространстве, при помощи джампа с последующим возвратом к месту вызова (call).

Ты предлагаешь эту функцию 1) выделить в микросервис 2) крутить в своём адресном пространстве 3) вызывать некими средствами ipc или даже удалённо через сеть.

И это должно выглядеть проще и работать быстрее и надёжнее, чем «монолит»? Лишь в фантазиях необразованных и неопытных хипстеров .

Ты предлагаешь эту функцию 1) выделить в микросервис

НЕТ. После этой фразы можно не читать, потому что это не есть микросервисы, это есть распределённый монолит. Распиливание это ПЕРЕПРОЕКТИРОВАНИЕ ВСЕЙ логики таким образом чтобы 1) разбить всё приложение на участки с малой связностью и меньшим размером. 2) использовать эту малую связность, чтобы иметь возможность держать это всё на разных машинах во многих экземплярах. Простым выносом функций этого не получится сделать от слова совсем.

И это должно выглядеть проще и работать быстрее и надёжнее, чем «монолит»

монолит очень неустойчивая штука, потому что существует в одном экземпляре. Одно непохендленное исключение-и вся аппа падает нафиг. А так у тебя: 1) обработчиков много, если один свалился на редком кейсе — он просто рестартнёт, а пока он поднимется — другие выполнят его работу. 2) Сделать ошибку гораздо проще в большой программе, чем в маленькой. Хотя бы по этому эта штука надёжнее.
Учитывая то как «нехипстеры» пишут код, падать оно должно много и часто.

Распиливание это ПЕРЕПРОЕКТИРОВАНИЕ ВСЕЙ логики таким образом чтобы

Функциональность-то о этого никуда не денется. И реализующие её миллионы функций (как для больших систем) — никуда не денутся тоже.

В «монолите» они крутятся все вместе. В «распределённом монолите» — могут крутиться в разных процессах/на разных машинах. Любители же микросервисов — предлагают делать микросервис, едва ли не под каждую отдельную функцию (т.к. если в микросервисе несколько функций — это уже «монолит»).

В общем, система из большой, ( виде «монолита») — в виде микросервисов не станет маленькой, а станет ещё более крупной, ещё более тяжёлой, тормознутой, сложной, слабо-синхронизованной, проблематичной в развёртывании, итп.

И в чём профит?

Функциональность-то о этого никуда не денется.

елаизация этой функциональности денется. Одной вычислимой функции существует счётное множество программ, её вычисляющую.

В общем, система из большой, ( виде «монолита») — в виде микросервисов не станет маленькой, а станет ещё более крупной, ещё более тяжёлой, тормознутой, сложной, слабо-синхронизованной, проблематичной в развёртывании, итп.

По вашему сценарию — станет распределённым монолитом.

Одной вычислимой функции существует счётное множество программ, её вычисляющую.

Я даже сказал континуум, если не ограничивать размер программ.

Одно непохендленное исключение-и вся аппа падает нафиг.

Ловится на ближайшем подходящем обработчике, делается какая-то соответствующая обработка (отказать клиентскому соединению, откатить транзакцию, и т.п.), летим дальше.

(Похоже, вы не знаете и что такое «монолит» в реальном мире.)

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

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

Даже в не сильно сложном случае может тянуть на диссер. Но вы с вашей песочницей ни разу не сталкивались даже с 1% этой проблемы, или просто похерили её — пусть клиент выкручивается.

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

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

переделать логику так, чтобы она параллелилась с общим состоянием

общее состояние там очень мало. Его почти нет. Все сервисы работают как функции.

Даже в не сильно сложном случае может тянуть на диссер. Но вы с вашей песочницей ни разу не сталкивались даже с 1% этой проблемы, или просто похерили её — пусть клиент выкручивается.

Так не стоит воротить глобальное изменяемое состояние, и его отовсюду изменять. Не используйте глобальное изменяемое состояние настолько, насколько это возможно, и тогда вы даже не столкнётесь

даже с 1% этой проблемы

.
И

просто похерили её

 будет в принципе не нужно.

общее состояние там очень мало. Его почти нет. Все сервисы работают как функции.

а в бизнес системах общее состояние навязывается содержанием базы данных :)

кто ж сомневался что у вас нет базы данных как таковой :)
как и конкуретного доступа к данным.

Так не стоит воротить глобальное изменяемое состояние, и его отовсюду изменять.

да, надо каждому типа микросервиса дать копию базы данных :)

будет в принципе не нужно.

да, убрать базу данных вообще — и нет проблем.

кто ж сомневался что у вас нет базы данных как таковой

она есть. Но повторюсь, сервисы работают таким образом что у него y by design нет никакого состояния которое бы могло повлият деструктивным образом при падении. Упасть оно может в любой момент, и кривого состояния не будет.

да, надо каждому типа микросервиса дать копию базы данных

не нужно.

да, убрать базу данных вообще

не умеете вы в сарказм.

не нужно.

если сервисы работают с одной БД — то они уже не микро

да и в бизнес системах именно работа с БД является затыком по производительности.
и какой тогда смысл распиливания монолита на тьму сервисов если они будут простаивать в ожидании ответа БД?

она есть ... Упасть оно может в любой момент, и кривого состояния не будет.

это чудо прямо какое-то!
ноу-хау в разработке — приложение упало при изменении данных, но в БД данные остались консистентными «by design»

как вам удалось добиться такого?
обязательно сделайте доклад об этом, и на ютьюбе поделитесь.

ноу-хау в разработке — приложение упало при изменении данных, но в БД данные остались консистентными «by design»

Трансакции называется?

Трансакции называется?

ну, не знаю как назовет свое изобретение Иван Камышан.

как выясняется, у него в проекте сплошные ноу-хау, одно круче другого, о которых айтимир не слыхивал.

сплошные ноу-хау, одно круче другого, о которых айтимир не слыхивал.

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

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

«Во блин! А мужики-то не знают...»

Во блин! А мужики-то не знают...

Мужики то знают, но пишут, что это по хипстерски и использовать это в реальных приложениях не зачем.

тупые, косные и невежды
что с них взять то.

не обращайте внимание.

Увы
1) транзакций ой не всегда достаточно.
2) писать каждый мелкий чих в базу данных — поломается кровать.
Остальное за меня в основном уже сказали.

писать каждый мелкий чих в базу данных — поломается кровать.

Очень зависит от базы. Есть в которые можно писать каждый чих.

Это не веб, тормоза такой записи не устраивают.

приложение упало при изменении данных

Нету процесса изменения данных, есть запись результатов работы. Вероятность того что оно там криво запишется крайне мала, а на то, что приложение упадёт во время обработки — совершенно по барабану.

Не используйте глобальное изменяемое состояние настолько, насколько это возможно,

«Мышки, станьте ёжиками» (tm)

Я по определению задачи не могу избавиться от глобального изменяемого состояния.

Предложения не от мудрой совы из башни из слоновой кости — будут?
Или как всегда?

Я по определению задачи не могу избавиться от глобального изменяемого состояния.

 в студию определение задачи. В большинстве случаев — можно. Можно сделать одно большое изменяемое состяние и вносить туда изменения эффектами. Тогда точки изменения этого состояния будут не беспорядочно разбросаны по коду, а собраны в очень малом множестве, а способы изменения состояния очень стандартизирваны. Это позволяет добится очень чёткого контроля за состоянием, которого иф зен элсами и трай кетч файнали добится проблематично.

Можно сделать одно большое изменяемое состяние и вносить туда изменения эффектами.

Жуть.

Интерфейсы в Java этим занимаются
Проекций или срезов по нужному сечению роль выполняют.

Один из весьма популярных примеров такой «жути» — это Redux. Прижился во front-end разработке, и теперь медленно, но уверенно расширяет свою экологическую нишу в mobile разработке.

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

так обычно то за микросервесы как серебряную пулю и топят — фронтендеры.

а потом рассказывают бекендерам как надо писать — бекенды
Бекендеры ж не умеют, фронтендеры лучше в этом разбираются :)
у них свежие идеи!

Один из весьма популярных примеров такой «жути» — это Redux.

который появился только из-за специфики окружения, в котором выполняется программа — веб браузер

но так как фронтендеры обычно больше никакой среды не знают — они тянут Redux и на бэк.

уверенно расширяет свою экологическую нишу в mobile разработке.

в смысле в семействах в FooNative, PWA и фонгапах?

тогда Redux ни при чем
его просто надувает вместе с трендом замены нативного UI — вебUI

они тянут Redux и на бэк

Ни разу не видел попыток притянуть именно Redux на бэк, да и не очень себе представляю, как это было бы возможно — особенно, учитывая stateless природу бэка. Разве что, в этих, как их... изоморфных приложениях (MeteorJS и иже с ним), но мода на них, вроде как, прошла уже несколько лет как.

в смысле в семействах в FooNative, PWA и фонгапах?

тогда Redux ни при чем
его просто надувает вместе с трендом замены нативного UI — вебUI

Внезапно, ни в React Native, ни во Flutter вебUI и не пахнет. А Redux есть и там, и там. Более того, не далее как неделю назад видел реализацию оного на Kotlin под честный православный Android.

учитывая stateless природу бэка

???
это как он может быть stateless :)
его тогда самого вообще нет.
а есть некий набор чистых функций которым выдали эндпойнты.

думаю и такое бывает, но это никак не типичный бэк, чтобы на основе такого говорить что природа бэка — stateless

Ни разу не видел попыток притянуть именно Redux на бэк

а именно — и не обязятельно.
там я кавычки пропустил

речь о том что типичный фронтедщик — это молодой человек, который ничего кроме этого не знает. просто в силу возраста.
и поэтому у него голова работает сугубо фронтендными паттернами, подходами.
без понимания — почему они такие, что влияло на то что они такие.

Внезапно, ни в React Native, ни во Flutter вебUI и не пахнет. А Redux есть и там, и там.

потому что что первое, что второе — и есть развитие тренда вебUI вместо nativeUI
так что внезапно — вы подтредили то что я и сказал :)

Более того, не далее как неделю назад видел реализацию оного на Kotlin под честный православный Android.

вопрос же в том — насколько она будет востребована разработчиками Android

это как он может быть stateless :)
его тогда самого вообще нет.

Устроит поправка, что состояние на бэке не хранится постоянно в оперативной памяти?

некий набор чистых функций которым выдали эндпойнты.<