Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

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

Где его форк шланга?

Исходники форка шланга и туториалы находятся в открытом доступе. https://gitlab.com/lock3/clang/wikis/Metaprogramming-Introductory-Tutorial

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

Даже Котечка заценил. Метапроговцы его знают.

Я почти уверен, что он сделал это не сам, а с единомышленниками.

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

Прочитав 5% туториала, я осознал, насколько это мощная и гибкая штука, что в моих глазах затмевает макросы лиспов.

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

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

Ок, запомню вас как человека, который не готов аргументировать свою позицию. No problem.

consteval код, который генерирует код на этапе компиляции. Принимает на вход AST, на выход тоже AST.

Позволяет творить магию. Для обычной структуры

struct Foo
{
   int a;
   std::string b;
   MyType *с;
};

можно автоматически нагенерировать БЕЗ внешних программ всю необходимую обвязку (геттеры-сеттеры, всякие InvokeMethod(pInstance, "MyMethod", 42);) и реализовывать на основе этого всякие прикладные вещи (ORM, автоматическая сериализация во что угодно, генерация формочек для редактирования как в игровых движках...). И всё это для любого кода - своего или стороннего. Можно сгенерировать это всё для любого типа данных ЯП, С или С++ сторонней бибилотеки, не меняя саму библиотеку, не нарушая ABI.

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

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

Lock3 это царь что ли? Или он свой личный форк на основе этого сделал?

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

твоя реакция(такая) многим очевидный слив

Привет, qulinxao! Давно не видно тебя было.

Лестно Легион.

какие мысли о https://ru.wikipedia.org/wiki/Манифест_о_трёхдневной_барщине

как долговременной цели нынешней компание 4 вместо 5 ?

Люди, кто-нибудь может поделиться книгами Егора Бугаенко? Я смог скачать лишь первый том его книги «Elegant objects». Егор рассуждает по нашему вопросу и о преимуществах неизменяемости объектов тут.

Поджигаем дальше? :3

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

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

Хотя опять же с тем же С++ сложно сказать развитие ли это. Тот же раст хотя бы пытается бороться с «неприятными» местами лоулевел языков вводя какие-то «новые» подходы (борроучекер), но все еще оставляет и возможность продолжать писать как на С. С++ же просто игнорирует их (ну хоть умные указатели есть и общий RAII подход и на том спасибо), иначе будут потери по производительности (которые итак есть когда вы пишите именно на С++ (именно на том подмножестве которое и является самой сутью С++, а не как обычно делают все, на помеси С и С++), жестко пресекая любые поползновения в С-style), в этом и есть его (С++) главная проблема самобытного развития, он не развивается, он пытается припрятать С, но так, чтобы не страдала производительность или совместимость чтобы можно было и дальше писать на сисиплюсплюс, языке с внушительным бюстом.

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

Я ничего не понял, ну и хорошо. Есть в этом мире что-то неизменное!

Хотя опять же с тем же С++ сложно сказать развитие ли это.

Развитие. Язык стал позволять делать то, что раньше было недоступно. А какие-то вещи, которые раньше были сложными, стали проще. Иногда сильно проще.

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

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

С этого места поподробнее, пожалуйста.

жестко пресекая любые поползновения в С-style

Что вы под этим подразумеваете? Или это так, праздный трындеж на форуме?

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

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

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

А если нужно доработать старую кодовую базу, начавшую свою жизнь лет эдак 15-20 назад, и которую просто так ни на какой Rust не перепишут, то развитие видно чуть ли не повсюду.

это скорее С развивается в лице С++. Оторвите от С++ С и у вас не будет никакого языка. Так то никто не оспаривает то, что эти костыли над С из года в год делают С удобнее.

в частности уровень твоих когнитивных

это скорее С развивается в лице С++.

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

Только вот проблема – вы, почему-то, не можете в предметный разговор.

Оторвите от С++ С и у вас не будет никакого языка.

Ага. Ну вааще.

https://b-ok.cc/s/?q=Elegant Objects

Интересный подход.
Трудно сказать хорош он или нет.
Были 40 свойств в классе, а теперь имеем класс, который использует 40 классов ...

https://b-ok.cc/s/?q=Elegant Objects

Спасибо. Я ищу второй том этой книги и еще «Code ahead». Книгу «Code ahead/Наш код» на русском языке я позавчера листал в книжном магазине, меня пока жаба давит платить деньги за неё.

Сам Бугаенко продаёт свои книги на «Амазоне» по 40 баксов за штуку. Похоже, что у народа, купившего эти книги по такой цене, тоже жаба давит выкладывать их бесплатно. Авось найдётся добрый «Робин Гуд» и на этого Бугаенку.

Авось найдётся добрый «Робин Гуд» и на этого Бугаенку.

Обязательно найдется.
А какой ISBN второго тома?

А какой ISBN второго тома?

ISBN-10: 1534908307
ISBN-13: 978-1534908307
Номера я взял отсюда.

А кратенько об понравившихся вам советов можете сказать?

правильнее «о понравившихся»

А кратенько об понравившихся вам советов можете сказать?

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

Грубо говоря функциональный подход где-то такой.
x ^ 2 должна уметь сделать только x ^ 2 и ни от чего не зависеть.

x ^ 2 должна уметь сделать только x ^ 2 и ни от чего не зависеть.

Да, тоже самое говорит Бугаенко в своих выступлениях на «Ютьюбе». Наследование кода классов - зло, потому что приводит к потере управляемости поведения родителя и потомков при разрастании кода со временем. Внедрение зависимости/dependency injection - зло, потому что теряется управление созданием объектов, превращая программистов в «глупых мартышек». Много любопытных мыслей.

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

Мне больше нравится rapid подход, который «скрывает» от программиста «детали» /приблизительно как если сравнить Си и ASM/.

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

Об этом я не могу ничего сказать, потому как сам только пытаюсь разобраться что к чему.
Бугаенко призывает мыслить от задачи, а не от данных. Каждый объект выполняет одну задачу от начала до конца, а не хранит и выдаёт данные по требованию. В итоге вся программа превращается в один огроменный объект, который использует и поглощает в себя все остальные менее крупные объекты, подавая им данные для обработки и забирая итог обработки данных каждым из объектов. У этого мегаобъекта будет конструктор с длиннющим списком объектов-параметров, чтобы пробрасывать зависимости в малые объекты и единственным методом run().

Разные подходы имеются.
Касторка ведь хороша в определенных случаях?

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

Касторка ведь хороша в определенных случаях?

Да, при кашле.

И от «сонливости» хорошо помогает.

касторка

при кашле

Чтобы пациент кашлянуть боялся?

Крайности - хождение по краю обрыва.

Оооооо /отличная мысль/!

Разные подходы имеются. Касторка ведь хороша в определенных случаях?

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

Хороший подход.

Советы - отлично.
Категоричность - бывает и плоха /не к тому, что Бугаенко давал плохие советы/.
Почитайте Бугаенко, ..., а выбор - за вами.

http://www.opennet.ru/opennews/art.shtml?num=51507 Microsoft открыл код стандартной библиотеки С++, поставляемой в Visual Studio
https://github.com/microsoft/STL MSVC's implementation of the C++ Standard Library.

Интересный comment

На Оупеннете встретить адекватного человека, также удивительно, как встретить на улице снежного человека.

Имхо, лямбды в С++ самые мощные из тех, что есть. Явное указание замыкания необходимо для языка без GC по умолчанию. Если надо - банально всё захватывается в замыкание по ссылке или значению.

Более-менее адекватная реализация замыканий есть в Расте, как я уже писал неделю назад здесь. То есть, контроль области видимости, полностью автоматический захват переменных извне, что в итоге может быть использовано для прозрачного захвата умных ссылок со счетчиком, для которых не нужно будет никаких GC.
Явное указание внешних переменных, как параметров лямбды, нужно потому, что в крестах были реализованы провальные принципы организации областей видимости, которые мало очевидны и слабо контролируются. Потому программист должен явно определять захват внешнего контекста, чтобы комиссия по стандартизации могла сказать «вот же ж, вы сами неправильно явно использовали переменную, потому получили undefined behaviour - мы тут не при чем».
Чем чреват и плох подобный код на практике? (комментарий)

Но все средства С++ по облегчению управлением памятью (умные указатели, Copy On Write, возможность запилить GC) спокойно работают в лямбдах.

Будешь умный указатель на каждый int ставить?

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

Сочетаются разве что в плане страстной любви к переусложнению языка.

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

Это bad practice by design, потому что именно в лямбдах введена поддержка замыканий.

С и С++ - это свобода и фундаментальность. За счёт этого в них можно реализовать любые концепции какие захочешь.

Я извиняюсь, но в питоне можно убрать сборку мусора, сделать компилируемую программу (Cython), или вообще переписать реализацию на другом языке (IronPython, Jython), или же написать интерпретатор питона на компилируемом в машинные коды подмножестве питона (RPython), что сделал PyPy - чем не свобода и фундаментальность? Си - это один из многих языков промежуточного уровня, просто он оказался самым популярным - но далеко не потому, что является самым лучшим. У того же раста инструменты вполне себе уровня Си, то есть - простые структуры и функции. Вопрос здесь только в готовых решениях и готовых оптимизирующих компиляторах, которых у раста нет, и у паскаля нет.

Весь рантайм питона, js'а, руби, луа и прочей скриптухи и даже джавы построен на С/С++.

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

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

Неактуально для того же питона. Он никак не завязан на Си.

Даже компилятор раста на расте построен на сишном llvm и все концепции построены на базе сишных концепций

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

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

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

Я извиняюсь, но в питоне можно убрать сборку мусора

Я извиняюсь, но где можно посмотреть на Python без сборки мусора?

На чём был написан компилятор REBOL 2.7 в 2011 году? Вестимо, на предыдущих версиях REBOL. На чём была написана самая первая версия REBOL, которая не умела селфхоститься?

А первый компилятор паскаля был написан на фортране.

То бишь по сути C ещё с 1999 года не нужен.

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