LINUX.ORG.RU

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

 ,


2

4

Заранее прошу прощения за то, что не в Talks, а сюда. Так получается, что теперь в Talks просто так постить нельзя, нужна некая карма и я должен «страдать» (Почему я не могу писать в раздел Talks? (комментарий)). Я в упор не помню данные своего старого аккаунта. Зарабатывать карму здесь и сейчас у меня нет ни времени, ни возможности, ни необходимости. Почему сюда, а не на другие форумы? Потому что считаю, что здесь обитают люди, которые смогут ответить на вопросы ниже и, возможно, даже, которые застали те самые времена (если конечно те самые люди ещё здесь).

Всем доброго времени суток! Не срача ради, а понимания для. Хочется понять историчность и почему так произошло. Понятно, что сейчас уже стали внедрять функциональные фичи много куда (в те же Java, C++, C# и т.д.). Стало появляться много функциональных языков (в том числе совсем новых). Но почему спустя столько времени? Почему спрашиваю:
- Functional programming has its origins in lambda calculus, a formal system developed in the 1930s (!!!) to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus (отсюда: https://en.m.wikipedia.org/wiki/Functional_programming);
- Lisp появился ажно в 1958 году;
- после лиспа ещё была целая куча функциональных языков (APL, IPL, ML, Miranda, Erlang, etc.);
- C++ в 1985;
- Haskell в 1990;
- Java в 1995;

Сама идея ООП (и то я так понял весьма размытая, каждый понимал (и, кстати, по-моему до сих пор понимает) по-своему) вроде как витала со времени создания самого лиспа, но до конкретных реализаций она добралась ближе к концу 80-х - начала 90-х годов.
(поправьте меня, если не прав)
И это ещё при всём при том, что ФП имеет под собой весьма конкретный математический базис (чего я, пожалуй, не могу сказать про ООП).
Я так понял, что благодаря таким крупным компаниям как Microsoft, Oracle...
Но почему они так сильно повлияли на развитие этих технологий и как именно они это сделали я, честно говоря, не совсем понимаю.
Ок, ладно, тогда железо было не такое как сейчас, памяти было маловато для нормального существования функциональных языков на x86 платформе.
Но ведь была же та же, например, Symbolics, которая вроде бы весьма активно продавала лисп-машины?
Ок, Symbolics развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

Ответ на: комментарий от anonymous

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от yyk

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

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

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

arturianec100
()
Ответ на: комментарий от arturianec100

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

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

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

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

yyk ★★★★★
()
Ответ на: комментарий от abcq

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

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

trex6 ★★★★★
()
Ответ на: комментарий от yyk

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

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

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

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

arturianec100
()
Ответ на: комментарий от arturianec100

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

arturianec100
()
Ответ на: комментарий от trex6

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

abcq ★★
()
Ответ на: комментарий от anonymous

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

arturianec100
()
Ответ на: комментарий от arturianec100

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

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

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

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

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

abcq ★★
()
Ответ на: комментарий от abcq

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

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

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

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

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

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

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

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

abcq ★★
()
Ответ на: комментарий от abcq

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

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

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от Enthusiast

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

Enthusiast ★★
()
Ответ на: комментарий от Enthusiast

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Enthusiast ★★
()
Ответ на: комментарий от Enthusiast

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Enthusiast ★★
()

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

anonymous
()
Ответ на: комментарий от Enthusiast

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Enthusiast ★★
()
Ответ на: комментарий от Enthusiast

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Enthusiast ★★
()
Ответ на: комментарий от Enthusiast

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

anonymous
()
Ответ на: комментарий от anonymous

Интересный comment

На Оупеннете встретить адекватного человека, также удивительно, как встретить на улице снежного человека.
anonymous
()
Ответ на: комментарий от arturianec100

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от arturianec100

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от arturianec100

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

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

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

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

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

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

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

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

eao197 ★★★★★
()
Ответ на: комментарий от rebforce

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

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

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

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

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.