Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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 будет меньше. Холиворный многогранный вопрос. Некоторые ответы могут шокировать и уходить в плоскость бизнеса аутсорц компаний — больше разработчиков в проекте больше ревенью посредника.

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

А дальше что?

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

А чего так мало? Надо было сразу 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».
Это есть явное передергивание, и искажение фактов.

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

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 будут
Станет он этого — ФЯ?
ну, или парадигма разработки на нем изменится от этой фичи?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Користь ООП не в ООП. Користь у рішенні ізолювати область яка буде змінюватися (бізнес-правила) від того що не важно (база даних, 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 символов), оно шустрое, но да, если вдруг надо поменять длину, и не влазит в тип — может полететь десяток-два хедеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

отдельно на

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

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

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

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

Ну и код...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:)

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

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

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

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

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

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

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

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

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

и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Богу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

конечно.

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

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

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

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

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

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

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

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 отказались — нафик не нужно ООП для создания микросервиса
хотя вот дженерики в интерфейсах — просятся. раз уж есть интерфейсы :)

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

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

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

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

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

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

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

Значит, если в языке есть структуры, то это ООП? Вообще, эволюция термина ООП достаточно интересно. Вначале трушным ООП был 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. Скорее всего, он своё мнение не поменял — но есть большие сомнения что он вникал что там поменялось.

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

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

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

Я до сих пор считаю код 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), и предоставлять возможность создавать высокоуровневые абстракции (как это делают всякие джавы). С учётом потребности сохранять обратную совместимость, естественно, этот язык поплатился за это своим заметным усложнением. Но ничего сверхсложного в нём нет. Кому интересно — разберётся, благо ресурсов сейчас в интернетиках хватает. Кому неинтересно или кто не хочет — бога ради, других языков сейчас хватает. Без работы никто не останется, было бы желание.

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

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

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

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

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

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

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

А боевые машины уже полностью готовы без кожаных мешков смотри тот же ж боинг 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< T, boost::pool_allocator< T > >;
или еще че ... смотря че профайлер покажет, скажем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То же самое было с холиваром 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(), который может замапить страницу памяти, если буфер закончился.

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.

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

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

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

когда ни будь

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

А если его использовать не правильно, как делают в 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’е например) =)

Что-то новое сейчас писать на 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++ / 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 умеет правильно копироваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну вообще-то оно достаточно похоже:
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++ так лямбды в нём вообще апофеоз красоты.

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

Я их для этого в 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 взлетів чи ні?
У реальності.

А що було хайповим після Ruby? node.js, Go, Elixir?

node.js — взлетів.
Go — не так стрімко, але поширенність зростає

Elixir — не взлетить :)
але можете вірити у його майбутнє — я ж не пророк.

Я вважаю що Ruby не переміг не через DSL

ще раз
Ruby взлетів чи ні?
у реальності?

чому — взлетіло щось що чи ні — то вже: пояснення факту чи фактів

ви ж не згодні з моїм
— факт — DSL не взлетел.
— щось не співпадає з реальністю.

то розкажіть про вашу реальність більше :)

Дайте означення «взлетів» та «не взлетів».

Стрімко, часто неочікувано, поширився у використанні.

В моїй реальності Ви ствердужуєте:

ні, я просив вас надати приклад з вашої реальності де
ви ж не згодні з моїм
— факт — DSL не взлетел.
— щось не співпадає з реальністю.

ви надали
— а от є Ruby!
моє
— так сам Ruby не взлетів

а якщо ви кажете:

Ruby не взлетів

то

Я лише хотів вказати Вам, що Ваше твердження неправильне

то DSL в ньому не можна використати проти тезіса

— факт — DSL не взлетел.

тому що DSL погана ідея

поки не з’ясуємо — ми в одній реальності живемо чи в різних — нема сенсу переходити до аналізу причин явищ

приведіть данні з в вашої реальності, котрі свідчитимуть що DSL стрімко поширюється у використанні (чи мав такий період, і вийшов на плато стабільності на графіку хайпу)
і є звичайним явищем при розробці ПЗ

Рубі однозначно взлетів після створення 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 оптимизировать. Те кому это интересно, этим и занимаются, что тоже может быть весьма занятно.

для расчета скидки на товары не нужен матаппарат.
достаточно знания арифметики на уровне младших классов.

ничего такого сложного бизнес-системы не считают.

скидка на пицу 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. До того ж С — це завжди ручне керування ресурсами, а там ой як легко зробити помилку.

Менше кода — менше багів. Менше кода — простіше його читати.

Нифига. 20 строк С часто лучше читаются, чем 5 строк С++. Про функциональщину молчу.

До того ж С — це завжди ручне керування ресурсами, а там ой як легко зробити помилку.

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

В С в одну строчку меньше влазит. В С++ больше. В Питоне — вообще страх какой-то.

Речь о том, что полотно-столбик на С проще читать, чем квадратный метод на С++

В этом случае даже пытаться читать на стоит

А вот в реальных проектах код на С++ легче читать, чем на С.

Конечно же нет! Похоже, что ты ни разу не видел С++ кода в ембеддеде. Основная жопа С++ в драйверах и при работе с железом это наследование.

sensor объявлен как базовый класс.

sensor->readdata(...);

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

Думаешь с говнокодом на С лучше — там вообще атас, если найти что-то нужно.

Ставишь бряку и смотришь, кто вызвал.

Но в С++ легко из без бряки.

Наш опыт не совпадает.

Я когда-то неделю разбирался, почему в новой версии Хромиума старый рендерер перестал работать. И вот без бряки ничего не помогает. С брякой хотя бы стек видишь. И так — неделю. Это — С++.

сейчас для этого есть valgrind, если софтина не сильно прожорливая

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 теж буває.

Эмбедед. Исторически там был С, но памяти стало больше.

Да любые, на изучении С++ у многих развитие заканчивается.
Что интересно, былые светочи (Александреску, Маерс) из С++ давно ушли. Умные люди.

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 разработке.

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

а потом рассказывают бекендерам как надо писать — бекенды
Бекендеры ж не умеют, фронтендеры лучше в этом разбираются :)
у них свежие идеи!

Один из весьма популярных примеров такой «жути» — это 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 :)
его тогда самого вообще нет.

Устроит поправка, что состояние на бэке не хранится постоянно в оперативной памяти?

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

Ну так всё верно. Новое состояние, хранящееся в персистентном хранилище (например, БД) можно вывести из предыдущего сохранённого состояния и пользовательского ввода через чистые функции. А вот уже сохранение нового состояния в БД — это тот самый «эффект».

вопрос же в том — насколько она будет востребована разработчиками Android

Идёт к тому, что будет. И на Android, и на iOS «официально» завозят функциональную реактивную модель (Combine и Compose соответственно). А оттуда уже и до Redux недалеко.

Устроит поправка, что состояние на бэке не хранится постоянно в оперативной памяти?

а какая разница где оно НЕ хранится?

где бы оно не хранилось — это и есть — состояние
если его нет — то ничего на сервере не хранится кроме статики и кода алгоритмов

Новое состояние, хранящееся в персистентном хранилище (например, БД)

то есть природа бэка как раз обратная stateless.

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

состояние есть или нет?

А вот уже сохранение нового состояния в БД — это тот самый «эффект».

то есть это просто новое слово для
изменение данных :)

и что меняет ввод нового термина для того же самого?

И на Android, и на iOS «официально» завозят функциональную реактивную модель

может быть, не следил

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

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

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

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

и назвать — изменение данных — эффектом.
слов в языках много. лет через 10 можно еще какое-то приделать к все тому же:

изменению данных
что в конечном итоге и есть
изменение состояния

а какая разница где оно НЕ хранится?
где бы оно не хранилось — это и есть — состояние

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

А строгий контроль над тем, когда и кем меняются данные в постоянном хранилище, помогает в предотвращении такого рода дефектов ещё больше.

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

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

а откуда компилятор знает про это:
кому куда надо лезть, а кому куда не надо, если об этом ему не рассказал программист?

А строгий контроль над тем, когда и кем меняются данные в постоянном хранилище, помогает в предотвращении такого рода дефектов ещё больше.

какого — такого рода?

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

Самый классический и «вырожденный» пример такого — глобальные переменные

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

для компилятора то какая разница, глобальные это переменные или нет??

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

ну так у вас же какой-то умный компилятор который все проконтролирует. если оно в операвной памяти конечно, я понял ограничение.

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

а откуда компилятор знает про это:
кому куда надо лезть, а кому куда не надо, если об этом ему не рассказал программист?

В функциональных языках программиста об этом заставляют рассказать. По умолчанию, всё immutable, и если у тебя появляется где-то mutable переменная за пределами локальной области видимости, то сама функциональная парадигма заставляет тебя чесать репу на тему того, почему у тебя здесь должен быть side effect, а не «чистая» функция.

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

Компилятор в случае функциональных языков всего лишь не даёт менять то, что не объявлено явно как mutable. Конечно, на это вы возразите — ну и что, и в C++ так можно, const никто не отменял. Да, можно, но нюанс в другом — ООП парадигма поощряет использовать изменяемое состояние. Пусть даже и инкапсулированное: как только есть методы для его изменения, всё — контроль за тем, кто и откуда может это состояние изменить, уже сильно ослаблен. Да, правильное примененение high coupling / low cohesion позволяет частично восстановить контроль, но — лишь частично, и контроль за этими вещами требует вдумчивых код ревью.

В ФП любое изменяемое состояние по умолчанию считается «опасной зоной» и поэтому выносится в наружный строго контролируемый слой, где допустимы так называемые side effects. Вне этого слоя — только чистые функции без побочных эффектов, поведение которых на 100% предсказуемо.

В функциональных языках программиста об этом заставляют рассказать.

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

По умолчанию, всё immutable

а какое отношение это имеет к — сервер stateless или наоборот?

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

а я думал это требование такое, к тому что делать сервер

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

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

ну так пусть программист объявит как mutable

Да, можно, но нюанс в другом — ООП парадигма поощряет использовать изменяемое состояние

потому что так работает — компьютер

В ФП любое изменяемое состояние по умолчанию считается «опасной зоной»

и что с того?

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

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

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

Задача: сервер обязан сохранить данные между вызовами.
как это может сделать stateless сервер?

контроль за этими вещами требует вдумчивых код ревью.

В холиравах об ФП у меня нередко возникает ощущение что адепты забыли азы:

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

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

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

P.S.
Более того

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

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

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

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

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

так в чем причина — в этих программистах или парадигме которую они выбрали, и которая НЕ позволяет писать крупное ПО тысячами программистов?

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

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

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

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

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

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

Я вообще против такого отношения к коллегам, но, в чём-то они таки правы: функциональщина гораздо более требовательна к пониманию мат. аппарата и развитости абстрактного мышления.

те ЯП которые позволяют это делать быстро, результативно

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

Главное — не упарываться по хардкору Haskell-style, когда вместо того, чтобы написать императивную оболочку вокруг ядра, реализующего алгоритмы и логику, начинают наворачивать монады над функторами.

Это не совсем убедительный аргумент

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

— Но вот факты которые не вписываются в вашу теорию...
— Тем хуже для фактов!

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

ФП тоже десятки лет.
LISP — 1958
Scheme — 1975

Популярность Scala в Big Data как бы намекает нам.

Scala — мультипарадигменный язык из мира Джавы.
и вялотекущий холивар там между хаскелистами и джавистами — там тот же.

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

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

И фишечки эти — не делают ЯП куда их вставили даже мультипарадигменными

Вишенка на торте — это конечно нужно.
но торт будет вкусным или нет и без нее.

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

я не выставлял ФП фуфлом.

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

Я вообще против такого отношения к коллегам, но, в чём-то они таки правы: функциональщина гораздо более требовательна к пониманию мат. аппарата и развитости абстрактного мышления.

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

как я говорю — неважно качество ручки — покажи написанное.
а если написанного нет — то может и самой ручки вообще нет?

неважно как ты знаешь мат аппарат, и какой у тебя IQ
выхлоп — какой?

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

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

например у хирургов полно таких хитровывернутых скальпелей.
с отличной стали!

а чего на кухнях у людей обычные ножи?
фи.

Главное — не упарываться по хардкору Haskell-style

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

начинают наворачивать монады над функторами.

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

один из простых критериев определить предвзятость
применение двойных стандартов

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

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

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

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

puts("Hello world!");

сколько уже можно, а?
когда наконец не добавят в ЯП специальную конструкцию, типа
p.H.W!

кратко, удобно

можно еще как-нить изящней.
обсуждать годами эстетику

но это уродство
puts("Hello world!");
уже сил нет терпеть!

потребуют гораздо больше кода.

зато чтобы написать на условном F# остальные 80% функционала ...

в итоге никто и не пишет :)
а на F# пишут модули, библиотеки, для которых имеет смысл его применять, а не более универсальный C#

зато чтобы написать на условном F# остальные 80% функционала ...

Ребята из Kaggle с вами несогласны. И из Credit Suisse тоже (причём, ещё 11 лет назад).

когда наконец не добавят в ЯП специальную конструкцию, типа
p.H.W!

Ну паясничать-то не надо... дискуссия скатывается в детский сад какой-то.

а на F# пишут модули, библиотеки, для которых имеет смысл его применять, а не более универсальный C#

Внезапно, на F# можно делать всё то же самое, что и на C#. Там есть ООП и императивные конструкции.

Беда в том, что со студенческой скамьи, а то и со школы мозг привыкает к какому-то из более распространённых императивных языков, а потом «нафига напрягать мозг и учить новое — и так сойдёт!»

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

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

Тобто імутабл занадто радикальний підхід?

На жаль, так.

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

«Всякому овочу своє місце» ©

Ну, на самом деле, мало кто на практике всё пишет в исключительно pure стиле. Это нетривиально, и не под каждый тип приложений подходит.

Есть более прагматичный подход, который называется functional core, imperative shell.

Там в core алгортмы. В куче задач core выродится в middleware, а шелл — в сервисы. В результате маємо те, що маємо, только назвать можно по-новому.

в этом самом наружном слое всё самое существенное и происходит

«Самое существенное» — это запись в базу, взаимодействие с устройствами ввода / вывода и т.п.? Даже не знаю, что сказать тогда... Бизнес-логику приложения мы к самому существенному не относим? :)

Бизнес-логику приложения мы к самому существенному не относим?

Бизнес-логика обычно занимает 80%, и часто stateful. Чем тогда этот подход отличается от OAL/HAL/DAL/Half-Sync-Half-Async?

Бизнес-логика обычно занимает 80%, и часто stateful

Можно, пожалуйста, чуть детальнее раскрыть выделенное жирным?

В моём понимании бизнес-логика — это алгоритмы, которые при одних и тех же входных данных всегда выдают один и тот же результат. Конечно, этот результат потом куда-то сохраняется — если вы именно это понимаете под stateful, то это никак не противоречит идее functional core.

OAL/HAL/DAL/Half-Sync-Half-Async?

Half-Sync-Half-Async — это, похоже, вообще не про бизнес логику, а про эффективную работу с I/O. Мы здесь точно не сравниваем яблоки с апельсинами? Прочёл по диагонали пару статей, объясняющих этот подход, и пока ощущение такое, что он совершенно ортогонален ООП и ФП парадигмам. Можно при необходимости реализовать и там, и там.

DAL — это абстрагирование от базы данных, если верно угадал аббревиатуру. Но, тогда, где здесь бизнес-логика? :)
И это помимо того, что ФП никак не запрещает dependency injection, просто там это делается несколько по-другому.

HAL — это что-то из области ядра системы и драйверов, там функциональщине, действительно, не место.

OAL — увы, не встречал эту аббревиатуру. Гугл быстрым поиском ничего вменяемого не выдаёт.

В моём понимании бизнес-логика — это алгоритмы, которые при одних и тех же входных данных всегда выдают один и тот же результат. Конечно, этот результат потом куда-то сохраняется — если вы именно это понимаете под stateful, то это никак не противоречит идее functional core.

Вот из моей жизни: трубка радиотелефона присылает набранный символ *
1) Если мы сейчас набираем номер, * добавляется к набранному номеру, запускается проверка номера на соответствие правилам набора номера всех учеток ИП телефонии, подключенных к этой трубке, если одно из правил сработало — начинается многошаговый асинхронный процесс установки соединения; если не сработало — перезапускается таймер ожидания следующего набранного символа.
2) Если у нас на трубке 1 установленный звонок — создаем новый исходящий звонок на другую трубку (тоже много логики, сохранения и изменения состояний)
3) Если на трубке 2 звонка — происходит перенос вызова, когда трубка-инициатор удаляется из обоих звонков, а другие стороны звонков соединяются друг с другом в один звонок.
Это можно назвать алгоритмом, но выносить из него состояния во входные параметры при том, что читаемых и записываемых сущностей много, и в зависимости от выбранной ветки идет доступ к, создание или удаление различных сущностей, выглядит рискованным.

Соглашусь, эта задача нетривиальная. С другой стороны, в ФП есть:

1) методы работы с передачей нетривиального состояния (та же монада State).
2) методы работы с конечными автоматами, в том числе асинхронными.

Если интересно, то вот пара простеньких примерчиков для п.2:

relentlessdevelopment.wordpress.com/...​te-machine-with-f-actors

red-green-rewrite.github.io/...​e-Construction-Kit-for-F

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

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

Такое в ФП решается с помощью так называемых «линз». Кому интересно, вот пример «на пальцах» в javascript: medium.com/...​n-javascript-e494948d1ea5.

Правда, в вашем случае более существенным противопоказанием к ФП может быть не это, а вычислительная мощность железки, на которой крутится код. ФП весьма требовательно к памяти, т.к. из-за иммутабельности происходит многократное копирование данных (где-то это оптимизируется с помощью copy-on-write, где-то — не очень).

OAL — OS Abstraction Layer.

Эти 4 парадигмы отделяют независимое от внешней среды ядро с бизнес-логикой от зависящей от внешних условий и платформы периферии. И это выглядит точно как описание functional core / imperative shell, только без слова functional.

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

OAL таких гарантий, как я понимаю, не даёт.

«Самое существенное» — это запись в базу, взаимодействие с устройствами ввода / вывода и т.п.?

Вот сижу пытаюсь вкурить, почему в сценарии при условиях X получается, что удалённой UAʼшке идут неверные SDP.
В контексте участвуют несколько автоматов состояний уровня call controller, session set controller, call session, UA, authorization life и ещё несколько сущностей поменьше, которые при этом меняют состояния, частично одновременно, частично в весьма специфическом танце (типа, один перешёл в stable, а второй в ответ в offer_got, и т.п.)

Что из этого всего я должен назвать «бизнес-логикой» в вашем понимании, и нафига его выносить в какие-то чистые функции, если это не облегчает разработку и поддержку?

Понаставляй ассертов везде — или какой-то сработает, или надо дальше думать.

Это же и ограничивает область применимости ФП RESTful задачами

Совершенно непонятно, откуда такой вывод. Ну почитайте, пожалуйста, хотя бы F# testimonials — очень разные задачи решаются.

А если заглянуть вот сюда: Commercial Users of Functional Programming 2008 — а дело, на минуточку, было 11 лет назад, то разнообразие будет ещё больше. Причём, среди докладчиков не какие-то никому неведомые хипстеры, а представители таких серьёзных организаций, как Credit Suisse, Yahoo, Citrix и Deutche Bank.

очень разные задачи решаются.

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

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

... R&D department, обычно

но это конечно не аргумент, для теоретиков :)

как и то что им приходится рыть ссылки, где, надо же, на целых пары страницах упоминания о проектах

А если заглянуть вот сюда: Commercial Users of OO Programming

скопипасть сотни страниц что выдаст гугл?

а дело, на минуточку, было 11 лет назад,

а воз и ныне там :)
сплошные холивары.

то есть приводятся данные указывающий что технология не взлетела аж 11 лет
в качестве аргумента что она взлетела выше всех. ну или вот-вот — после 11ти лет то разгону каааак взмоет в ввысь!

есть приводятся данные указывающий что технология не взлетела аж 11 лет

Я лично знаю кейс, где прекрасно взлетела в AdTech бизнесе в одной из крупнейших компаний в этой сфере.

Но... haters gonna hate.

сплошные холивары.

Если говорить о конструктиве, то ИМХО дело выглядит так: подходы и приёмы из ФП с пологой кривой обучения активно заимствуются, популяризируются и используются в языках общего назначения.

Более сложные вещи пока, скорее, да — остаются уделом R&D и отдельных энтузиастов.

в студию определение задачи.

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

Можно сделать одно большое изменяемое состяние и вносить туда изменения эффектами.

Смешно. В какой песочнице так проектируют?

Это позволяет добится очень чёткого контроля за состоянием, которого иф зен элсами и трай кетч файнали добится проблематично.

Упоминание про if/else и try/finally показывает, что вы даже не начали пытаться осознать реальные задачи.

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

даже это можно выразить через эффекты.

даже это можно выразить через эффекты.

Когда в руках молоток, всё вокруг кажется гвоздями — это про вас и про «эффекты».

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

Количество мест в коде всегда ограничено — как минимум, размером самого кода.

размером самого кода.

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

Вот для этого изобрели ООП с энкапсуляцией.

ООП с энкапсуляцией.

«Энкапсуляция» ведёт к хаотичному изменению состояния. Есть у тебя IStateChanger, а как он меняет состояние — неизвестно.

«Энкапсуляция» ведёт к хаотичному изменению состояния.

Докажи

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

Для этого есть старый паттерн Database Abstraction Layer. Более того, если его не поюзали — будут большие проблемы с переездом на другую базу, когда вдруг понадобится.

А теперь — при чем к данному примеру энкапсуляция? Энкапсуляция в данном случае в первую очередь разделяет систему на слои, только один из которых имеет доступ к базе, при этом в нем нет пользовательской логики (Layers architectural pattern). Далее идет разделение на потоки с разными ответственностями и приоритетами. Выделяется поток, который может блокироваться на доступе к базе, либо доступ делается асинхронным. И очевидно же, что UI обрабатывает неблокирующийся поток.
А если кто-то пишет рандомный код — значит, Вы не рассказали, какой модуль за что отвечает, либо человек хочет запортить проект. Так он и на Расте все функции или классы или что там есть отнаследует от писателя в базу и сделает то же самое, что в С++. Получите то же самое.

паттерн Database Abstraction Layer

спасибо, кэп.

если его не поюзали

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

Энкапсуляция в данном случае в первую очередь разделяет систему на слои

ЭИнкапсуляция скрывает то что под ней лежит, и при этом не выдаёт никаких гарантий по поводу того как поведёт содержимое.

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

Ниоткуда, и не нужно. Ты либо используешь чужой код, либо пишешь свой.
Откуда тебе знать, что в расте под интерфейсом не сделали квадратичный алгоритм или while(true) или exit()?

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

Раст выдает гарантии по поводу того, что делает код? Я не про интерфейс, а про контракт. Если есть чья-то функция SquareRoot(х), Раст гарантирует, что она вернет корень квадратный, а не квадрат? Или ты веришь, что она вернет корень, не заглядывая в ее начинку? Или ты читаешь начинку всего чужого кода перед тем, как его использовать?

что в расте

раст тут конкретно к чему? Это уже пошли правила демагога.

раст гарантирует, что она вернет корень квадратный, а не квадрат?

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

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

В одном сообщении пишешь, что энкапсуляция — это нехорошо, потому что непонятно, что энкапсулированная сущность делает (вдруг она лезет в базу и блочит поток). Поэтому С++ плохой, да?

В следующем — пишешь, что Раст не может убедиться, что сущность, написанная на Расте делает именно то, что от нее ожидает ее пользователь. Поэтому Раст хороший, да?

И, чтобы не видеть противоречие в своей логике, называешь логику «правилами демагога», да?

И, чтобы не видеть противоречие в своей логике, называешь логику «правилами демагога», да?

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

Раст не может убедиться, что сущность, написанная на Расте делает именно то, что от нее ожидает ее пользователь.

это уже балшит, который на уши не натянешь. Так можно говорить про js или питон. Раст предоставляет довольно широкие возможности пользователю обеспечивать желаемое поведение не при помощи письмён в комментариях аля do not change this line, а при помощи вещей проверяемых на уровне компиляции — например — с памятью, компилятор может доказать что вот эта программа не просрёт память, если ты используешь соответствующую модель памяти.

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

Поэтому С++ плохой, да?

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

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

Какие из следующих проблем отловит Раст в чужом коде, который ты используешь?
1) Использование O(N2) или O(eN) алгоритмов
2) Возможность уйти в thrashing
3) Вечный цикл в одной из ветвей логики итерации
4) Ожидание в Virtual Proxy или Lazy Acquisition
5+) Использование внешней библиотеки или ОС, написанной на С
Если одну из них не отловит — получишь блокировку потока, которой ты так боялся в С++, и от которой, по твоим словам, защищает Раст. Где твоя логика?

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

Какие выразительные средства Раст предоставляет для узнавания о приведенных выше 5 вариантах блокировки потока?

Зачем 5? Достаточно одного варианта блокировки не писатель на расте, но в языках здоровго человека этот способ есть называется higher kinds и монады. У нас есть тип F[_] к которому мы можем предъявлять требования специальным образом. По типу вот этого F[_] собственно и можно узнать, что и как оно делает.

в языках здоровго человека этот способ есть называется higher kinds и монады

Я вот сам сторонник ФП, но это уже немного перебор. Зачем же настраивать против себя оппонентов, делая предположение, что те языки программирования, которыми они пользуются — заведомо «плохие», «негодные».

зачем же настраивать против себя оппонентов

Иногда по работе приходится залазить в джаву, С++ и го. Столько негатива скапливается от этих писателей что на 10 полтораков хватит.

Так в этом языки виноваты, или писатели? :)

И языки что сподвигают так писать, и писатели которые сподвигаются.

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

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

«Человеческое, слишком человеческое»
никакой математикой, строгой логикой в холиварах об ФП и не пахнет.
и именно со стороны сторонников ФП :)

В языке определены типы для:

1) Использование O(N2) или O(eN) алгоритмов
2) Возможность уйти в thrashing
3) Вечный цикл в одной из ветвей логики итерации
4) Ожидание в Virtual Proxy или Lazy Acquisition
5+) Использование внешней библиотеки или ОС, написанной на С

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

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

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

А откуда ты знаешь, что в чужом коде блокирует, а что — нет?

Из исходников. Если их нет — по умолчанию блокирует.

И чем это лучше энкапсуляции в С++? В любом случае, чтобы узнать, блокирует ли код, тебе нужно читать чужие исходники.

Ну так тебе нужно лишь однажды прочитать и обернуть в Id[_] или Future[_] или ещё что. И уже будет ясно в следующий раз. А так тебе каждый раз обращения к этому коду нужно вспоминать — что это за фигня.

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

Комент напиши в хедере

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

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

Проблемы с указателями решаются либо RAII по-старинке, либо умными указателями в новых стандартах. Вот в С я от них пару раз огребал. А в С++ — это не реальная проблема.

откуда мне знать что класс там делает без того чтобы залезть в его инкасулированное?

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

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

принято доверять коду и его документации

документация не всегда есть. Если нашлёпали императивный код, да ещё и вынесли рантайм- зависимость, то там всё пиши пока, никаких гарантий и доверия.

)) Библиотеки не используете, которые на С написаны?

Если нашлёпали императивный код

_императивный_

Классная, профессиональная подтасовка. Уважаю. Ажно секунду.

ОК, есть:
10 SIP учеток, связывающихся с серверами, со всякими креденшлами и настройками. Подробнее набор можно глянуть тут www.pjsip.org/pjsua.htm либо тут svn.pjsip.org/...​include/pjsua-lib/pjsua.h

6 DECT трубок неизвестных производителей, которые могут регистрироваться к USB DECT базе, общение с которой идет через bulk USB мейлы, в которых находятся голосовые пакеты или команды. Примерный набор функциональности здесь www.etsi.org/...​0/ts_10252703v010601p.pdf

WiFi роутер, на котором нужно соединить это, чтобы: DECT трубки могли звонить в сеть через SIP сервера, и принимать от них звонки.

Звонки: до 2 звонков на трубку, возможно звонки между трубками без участия SIP учеток. У звонка есть данные, вроде номера и имени звонящего (из сети или из телефонной книги). Кодек, который может попытаться изменить один из участников, но это нужно синхронизировать с другим участником. Кроме того, так как DECT трубка является физическим устройством, а звонок — логической сущностью, запрос на изменение кодека нужно отсылать DECT трубке, например, если на ней меняется активный звонок, и у нового звонка кодек отличается от старого. И обработка запроса занимает порядка секунды времени, и в это время может произойти что-либо, например — смена звонков обратно, либо отсоединение активного звонка.

Софт-реалтайм передача голоса между сетью и ЮСБ без перекодировки.

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

Система настроек этого всего и CLI с парой десятков базовых команд.

Логирование событий с настриваемым уровнем.

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

ОК, есть:

слишком специфичная задача. У нас все разрабы земли делятся на тех кто пишет под роутеры и на тех кто пишет под микропроцессоры кофемолок? Статистика утверждает что задач с такими некислыми запросами под перформанс и потребление памяти достаточно мало. Чаще всего(веб, pc) эти вещи ограничиваются кошельком заказчика. Если заморочится, то думаю можно через scala native и сишные прокси что-то сделать, но компилятор там слишком молодой для таких целей. Всё тз которое ты поописывал, оно щелчком пальцев превращается в adt языка здорового человека, там нет ничего сверхсложного. перостое перекладывание данных с полки на полку.

Всё тз которое ты поописывал, оно щелчком пальцев превращается в adt языка здорового человека, там нет ничего сверхсложного. перостое перекладывание данных с полки на полку.

Там N томов стандартов SIP + 3 тома DECT. У тебя слишком длинные пальцы. SIP, правда, уже готов, а DECT — энкапсулирован, но местами надо понимать, что делаешь.

Перекладывание данных помогает до тех пор, пока не:
1) На трубке 1 был звонок А с кодеком Х, пользователь переключился в звонок Б с кодеком У, начали менять кодек, в этот момент пользователь переключился обратно на звонок А. Что делать?
2) Когда приходит звонок из сети, нужно позвонить на набор трубок, привязанных к учетке, с которой пришел звонок. Часть из них могут быть в переходном состоянии (например, отсоединяем прошлый звонок).
3) Часть трубок просто глючная, причем — по-разному. Если не приспосабливать свое поведение к этим глюкам — пользователи будут считать, что глючит твой продукт, так как их трубка с родной базой работала нормально.
4) Сеть может пропасть, сервер — упасть, запрос к нему будет висеть 5-10 сек, а UX никто не отменял. А UX зависит от того, что в данный момент с трубкой происходит. Одна и та же кнопка «*» может работать как обычный символ при наборе номера, как запрос на создание нового вызова между трубками, или как запрос на перенос вызовов (соединить двух участников двух звонков между собой в один звонок, а себя отсоединить). И перенос вызова зависит от того, каких типов были эти вызовы — одно дело — соединить 2 другие трубки, второе дело — перенести звонок с сервером на другую трубку, третье — отослать запрос на сервер на перенос вызова в сети. И не забыть при этом всем логирование и историю, в которых надо порезать 2 звонка и из их кусков создать новый, с вразумительными данными участников.

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

Перекладывание данных помогает до тех пор, пока не:

1) механизм канселейшнов. 2) держать статус 3) что мешает каждой трубке дать свою реализацию? 4)Вообще совсем не пробелма. RetryableFuture.backoff

Вопрос, что кроме этого кода останется.

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

1) механизм канселейшнов.

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

2) держать статус

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

3) что мешает каждой трубке дать свою реализацию?

то, что а) 98% кода одинаковые б) у одной трубки может быть несколько известных странностей, поэтому наследование не катит (многомерная система)

4)Вообще совсем не пробелма. RetryableFuture.backoff

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

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

В следующем проекте упакуешь 3 тома стандартов в маленькую, понятную и читаемую логику. Потом напишешь статью на ДОУ как это сделать.

Микросервисы ИМХО полезны в двух случаях:

1) Есть некая часть большого и сложного приложения, которую нужно независимо масштабировать по нагрузке. Масштабировать весь монолит — дорого, а вот отдельную часть можно вынести в микросервис и плодить его экземпляры на дешёвых относительно маломощных виртуальных серверах.

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

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

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

ЗЫ: писал один парень типа начинающий но амбицийный очень! якобы «а тут я использую (локальный фреймфорк для распараллеривания циклов)» ну и как спрашиваю работает? «да» отвечает. хотя я 146% уверен что он не понял что я спросил ))

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

Только я не совсем понял, почему многопоточность и микросервисы в одном ряду? Если не брать CUDA или нечто аналогичное специализированное, количество процессорных ядер, которые можно запихнуть в один чип, не так уж и велико. И если нужно держать огромную нагрузку, которая превышает возможности одного процессора (а есть ещё другие бутылочные горлышки в виде disk I/O), то scale-out вместо scale-up может быть вполне логичным решением.

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

Только я не совсем понял, почему многопоточность и микросервисы в одном ряду?

потому что вот ту меня объект вот у него метод и мне на самом деле глубоко всё равно он там многопоточный или микросервисный или это вообще супер пупер remote api т.е. чисто технически чисто теоретически я конечно понимаю что «на моей стороне» этот «объект» и не объект вовсе а какой-то там прокси который через какой-то там ремоутинг маршалируется на какой-то там стаб который уже в свою очередь выходит на реальный объект и вообще вот это всё... но постойте ка DCOM создан где-то в конце 90-х CORBA тоже где-то там же ж REST кажется посвежее SOAP вообще был в 10-ти заповедях дарованных Мойше а соврал! REST вообще со времён web потому там столько методов ))

... а первый си++ стандарт тоже в 98-м и вот 20 лет спустя меня #внезапно должна беспокоить «костыльная» реализация (тоже наверное в кавычках)

почему многопоточность и микросервисы в одном ряду

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

(а есть ещё другие бутылочные горлышки в виде disk I/O)

которые в свою очередь на сегодняшний день виртуализированны более чем полностью настолько что вон интел и ко. уже предлагают raw persistent memory access? а ну ок ))

ЗЫ: кстати да вот я хочу persistent memory object я просто пишу... что-то такое... а поскольку современный ssd на современном pcix4 работает уже почти на скорости оперативной памяти... почему сегодня почти в середине XXI века меня всё это должно волновать как «не реализованное нативно на уровне прикладного языка»? ))

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

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

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

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

Если это про NodeJS, так её создавали под вполне конкретные цели. Для которых важнее и, откровенно говоря, проще было реализовать быстрый асинхронный I/O, а не честную многопоточность. Автору Ноды и присниться не могло, что на Ноде начнут писать всё подряд, даже то, что на парадигму этой платформы натягивается хуже, чем сова на глобус.

фраза просто вырванная из контекста

таких фраз полно

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

кто в курсе, тот сразу понимал, зачем они нужны, и сколько придется «заплатить»

ну вы еще просто в не курсе :)

Распиливание должно происходить по тем местам где наименьшее количество связей

пилите, пилите, Шура. они золотые :)

зачем они нужны, и сколько придется «заплатить»

В нашем конкретном случае — заплатить в основном девопсам и за сервера. Потому что всё изначально на микросервисах писалось.

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

сколько типов сервисов у вас в проекте?

Достаточно много, больше десятка.

именно — микро
и именно написаных вашей командой?

если пара десятков типов микросервисов — то это какой-то игрушечный у вас проект :)

микро

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

понятие растяжимое

открою вам секрет

никаких монолитов давно не существует.

любая мало мальски приличная система — это набор жирных сервисов.
иногда и ядро системы — это пара-тройка сервисов
и это делалось еще до хайпа микросервисов.

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

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

Поэтому все кто реально писал эти самые пресловутые монолиты, выделял с них сервисы, или кластеризировал — ржут надорвав животы от «распилить на тьму микросервисов»

но, микросервисы — это молодежно=неопытно.
а ржут конечно то опытные=ретрограды, старперы

мало того.
когда удавалось узнать подробности о проекте, то обычно оказывается что запили микросервисы на ноде потому что
ничего кроме js не знали
при этом никакой потребности в горизонтальном масштабировании и не было
достаточно было написать нормально на джаве 1но приложение, в котором грамотно реализована работа с потоками и памятью
(яркий пример был как-то на хабре
какой-то функционал для танков: 4 сервера с инстансами на ноде загружали под 90% CPU — был переписан на спор, за пару дней на джаве
итого — 1 сервер, 1 инстанс приложения, пиковые нагрузки до 70% CPU)

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

верю!

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

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

він жеж може і нормальним бути.

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

Навіть чув як розпилювали на мікросервіси по вже існуючим модулям.

Всё надо делать с умом, а не просто потому что.

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

втф ти тільки шо написав шось в стилі «почему многие люди так ненавидят кофе и считают его скорее подкрашенной водой нежели вкусным напитком».

хто вважає? де вважає? весь світ пише на джаві з обрізками ооп.
як можна ненавидіти молоток?

шо за брєд я прочитав.

Ну вот например habr.com/ru/post/451982. Вполне себе хорошие аргументы.

Очевидные аргументы. Вывод то там же. Думать надо проектируя.

Очевидные аргументы. Вывод то там же.

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

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

Во всяком случае, я в курсе.

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

Думаешь, твой код другим читать будет легче через пару лет?

До выпуска и входа в мейнстрим Dotty — точно легче.

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

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

Практика «наследование перед аггрегированием» — закончилась в середине 90-х.

Вы просто не умеете готовить утконосов.

exception catcher все портит

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

Я б сказал это классика неправильного проектирования классов.

А что мешает сделать врезку с разветвлением в иерерахию? Понятно, что на это нужно согласование команд, кому нужна врезка и владельцами фреймворка.

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

А ну и да, вместо частей тела как property я бы сделал массив в объекте, как bodyparts а вот в него уже бы добавлял объекты частей тела. В финальных классах бы сделал read враперы типа legscount, который бы просматривал bodyparts и возвращал количество объектов типа legs.

ДА!!!

ЦеПеПе: вніманіє, много букафф

eax.me/c-vs-cpp
оттудаже
...
ООП. Кажется, сегодня уже вся индустрия осознала, что объединение кода и данных — идея так себе, не говоря уже про повсеместное использование наследования. В теории это, конечно, здорово, когда есть класс животное и от него наследуется кошка и лошадь. Но на практике реальная необходимость (ООП головного мозга — тоже тяжелый недуг!) строить такие иерархии возникает очень редко, и если возникает, то дело обычно ограничивается одним интерфейсом и многими классами, реализующими этот интерфейс. Последнее, если что, очень просто делается на С. И возникает вопрос, а какой вообще смысл использовать язык, одна из главных фишек которого — возможность легко писать код так, как это делать не надо?

....

заключєніє:

Не удивительно, что и сегодня даже для новых проектов многие программисты (Линус Торвальдс, пожалуй, является самым известным примером) выбирают язык C, а не C++. Стремление писать код на C — это стремление к максимально простому и понятному коду, стремление использовать ресурсы как можно более эффективным образом, и не в последнюю очередь это стремление к красоте. Технологии появляются и исчезают. Подходы, которые еще вчера считались общепринятой практикой, сегодня уже причисляют к антипаттернам. И только C прекрасен и вечен. На чем еще писать, если с 1972 года люди так и не придумали ничего лучше?

Звездеж, макаронного говнокода на С не меньше

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

так на С++ можна ваяти та ваяти хуліард рівнів абстракцій, він какгбе дажє поощряє,
вот щас прибило до берега приплюснутого, і як всігда, наоверінжинірив, маманєгорюй

можна ваяти та ваяти хуліард рівнів абстракцій,

Это можно на чем угодно

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

глобальные конечно не хорошо.

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

а потім тебе дешевше і легше звільнити і переписати з 0, чим страдати

git, python, php. Думаю, что на самом деле больше, wiki упоминает про

Because the layer of abstraction is thin and the overhead is low, C enables programmers to create efficient implementations of algorithms and data structures, useful for computationally intense programs. For example, the GNU Multiple Precision Arithmetic Library, the GNU Scientific Library, Mathematica, and MATLAB are completely or partially written in C.

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

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

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

кошка is животное
лошадь is животное

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

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

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

т.е. если возвращаться к контексту «развития си++ как языка» то тут вопрос уже прямой «а зачем именно си++ именно такое развитие?» так не проще ли и уж точно не эффективнее ли сделать уже новый язык в новой парадигме нового ооп и даже написать его на си++ с каким-то там interop если уж очень хочется хотя опять же ж непонятно «а зачем c++ interop?»

На чем еще писать, если с 1972 года люди так и не придумали ничего лучше?

дык люди же ж придумали Visual Basic и не слишком парятся ))

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

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

Та информация на которую я напарывался не дала развернутого ответа по этому поводу

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

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

ну или же почему люди так о них говорят

Поэтому никто особо и не объясняет эти факторы на программерских форумах :)

Тоже очевидно. Инструмент надо выбирать по поставленной задаче.

ну, вообще-то нет :)
в теории да

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

исключения конечно бывают.

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

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

описано в тьме книг типа Фактов и заблуждений профессионального программирования
Факт 1
Факты упрямая вещь — большинство очень важных и заметных явлений, происходящих в индустрии ПО, имеет отношение к менеджменту. Большинство наших неудач, к примеру, приписывается менеджменту. И большую часть наших успехов можно приписать менеджменту. В своей замечательной книге, посвященной принципам разработки ПО, Алан Дэвис [Davis, 1995] говорит об этом очень ясно в принципе 127: «Хороший менеджмент важнее хорошей технологии». Мне тяжело это признать, но Эл прав

о специфике разработки ПО, на практике, даже названия придумываются типа PeopleWare

Не правильно выбранный инструмент

вопрос же в критериях этой правильности :)

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

инструмент делает не конкурентным по цене результат.

когда работа по задаче началась — о какой конкуренции речь?

цена?
цена чего?

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

А что касается Тоpвальдса, для маленьких задач типа системы контроля версий или ядра ос — С самый лучший вариант. Никто не спорит.

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

Энтерпрайз с десятками разарботчиков... Прям на слезы пробивает. Десяток разработчиков это стартап получивший первый раунд финансирования а не какой не энтерпрайз.

Скажем, 2 десятка разработчиков в эльфии, с оплатой 100к/год каждый — это 2 млн на год. А есть ещё маркетинг с продажами (они обычно выжирают в 3-4 раза больше).

Сколько там составляет 1-й раунд финансирования?

Ну скажем стучались в линкедын не далее чем в воскресенье какие-то люди получившие 7,7 миллионов. Не в Эльфии, в Европах.

Ну и старая статапская пословица — между первой и воторой перерывчик — пару лет.

10 человек это стартап, который только начал нанимать кого-то кроме основателей.

Для сравнения на моем текущем прокте в широком смысле слова в какое-то время что-то около 2к человек работало..

я писал не о 10 человек, а о «десятках, если не сотнях задействованных разработчиков»

Работал в профинансированном стартапе раздувшем команду до 50+ человек.

лень сильно гуглить для такого примитивного вброса. вот данные с 2008 года, сейчас там существенно больше
Пакет Млн.строк
kernel-2.6.25i686 5.9
OpenOffice.org 4.9
Gcc-4.3.0-2 3.1
Enterprise Security Client 1.0.1 2.6
eclipse-3.3.2 2.2
Mono-1.9.1 2.1
firefox-3.0 2
bigloo3.0b 1.8
gcc-3.4.6 1.8
ParaView3.2.1 1.5

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

5 млн строк кернела — это ни о чём.

A к чему ты приплёл всякие прочие херни, 1) написанные на C++ (хотя, по тормознутости и убогости эклипса, я готов предположить, что этот уродец вообще написан на жабе) 2) не являющиеся частью ядра?

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

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

А потом Страуструп решил покончить с извращениями и сделал «С с классами» (не путать с C++). Отличная вещь до сих пор.

1) В табличке забыли браузеры.
2) В ядре (пускай меня поправят те, кто в него лазил) достаточно много кода должны занимать слабо связанные с остальной системой драйвера специфического железа (листья графа). В С++ проектах часто все связано со всем.

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

Найголовніше в ООП — це інкапсуляція, а вона безкоштовна з точки зору швидкості кода.

Не безкоштовна:
1) Втрачаємо оптимізацію статичних функцій та змінних
2) Якщо хочемо сховати імплементацію, то доводиться робити наслідування від абстрактного класу (інтерфейса), що сповільнює роботу через потребу доступа до таблиці віртуальних методів
3) Робота з екземплярами класів, виділеними через new, може буть повільнішою, ніж робота з статичними даними, через гіршу локальність в пам’яті.

Думаю, имелось в виду a->method() - те же яйца что и method(a) (в отсутствии виртуальных функций)

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

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

ага, new(buffer) MyChildClass; Вопрос, зачем это делать, если можно на С.

MyClass/MyStruct arr[10] — шо С, что С++. Вот в жабе да, все печальнее, это будет массив не на 10 инстансов, а на 10 ссылок, а сами инстансы могут располагаться как угодно.

динамически malloc (sizeof(MyStruct) * 10) — чем тебе особым от new отличается кроме вызова конструктора?

динамически malloc (sizeof(MyStruct) * 10) — чем тебе особым от new отличается кроме вызова конструктора?

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

Одно время была мода всё локальное по отношению к функции / методу хранить-таки на стеке во имя RAII.

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

Ніт.
1) Оптимізація та сама.
2) Навіщо це робити? Просто ховаєте деталі в private — цього вже достатньо, щоб захистити код від дурня.
3) Екземпляри класів можна створювати на стекі, в глобальній пам’яті, та де завгодно — бо є placement new.

1) Оптимізація та сама.

Різний scope якщо виносите оголошення класу в хедер проти статичних функцый та змынних в С. Compile-time optimization VS link-time optimization.

2) Навіщо це робити? Просто ховаєте деталі в private — цього вже достатньо, щоб захистити код від дурня.

Коли пишете OS Abstraction Layer для багатопоточності та примітивів синхронізації, наприклад, отримаєте 100500 #ifdef в приватній частині, якщо не зробити розумніше. + отримуєте залежність коду клієнтських програм від імплементації Вашого класу,якщо робите бібліотеку чи фреймворк.

3) Екземпляри класів можна створювати на стекі, в глобальній пам’яті, та де завгодно — бо є placement new.

Placement new заради енкапсуляції? Молодцем! Ще передайте в фабрику статичний буфер, куди плейсить поліморфний екземпляр, а перед цим — спитайте цю ж фабрику, якого розміру буфер їй потрібен.

Я бачу ми зовсім не «on the same page» і пояснення затягнеться на довго. Я просто приведу кусок коду, який показує, на скільке все зручніше з С++ (без віртуальних функцій і т.д.):

class Driver
{
...
private:
    PDRIVER_OBJECT              m_driverObject;
    Settings                    m_settings;
    PerformanceCollector        m_performanceCollector;
    Rules                       m_rules;
    MiniFilter                  m_miniFilter;
    RegistryFilter              m_registryFilter;
    scoped_ptr<NetworkFilter>   m_networkFilter;
    BfeStateWatcher             m_bfeStateWatcher;
};

По-другому:
Вариант 1:
пишется хедер platform.h для внутреннего использования:
#ifdef WIN32
typedef WinApiMutex mutex_t;
#elif defined __LINUX__
typedef pthread_mutex_t mutex_t;
#else
#error
#endif
После этого в коде API:
#include
class Mutex {
public:
Mutex();
~Mutex();
void Acquire();
void Release();
private:
mutex_t mutex_;
};

Вариант 2:
class Mutex {
public:
virtual ~Mutex();
void Acquire() = 0;
void Release() = 0;
};
Mutex* FactoryCreateMutex();

pimpl добавляет лишний переход по указателю:
&pointer->&implementation_instance
vs
&static_implementation

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

Единственное полезное свойство ООП, реализованное в урезаном виде, и не уникальное для ООП. А так, да ;)

Підписатись на коментарі