LINUX.ORG.RU

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

 ,


1

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

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

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

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

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

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

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

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

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

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

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

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

В школе/ВУЗе важно реализовать что-то самостоятельно (а есть и работа в команде).

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

Тысячи лет состоятельность языка определялась через написание на нём компилятора. Особенно в контексте производительности.

Почему это важно. У С/С++ и прочего - не было готовых ворованных компиляторов. Так было всегда. Возможности к реализации адептов каждого языка компилятора примерно одинаковые. И это позволяет их сравнивать.

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

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

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

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

На работе при решении прикладных задач использование чужого кода, который решает задачу (если лицензия подходит) часто не запрещается, а ПООЩРАЕТСЯ!

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

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

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

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

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

Вон недавно MS выложила...

Полная чушь. Говноstdlib от маздайсофта - самая мусорная реализация. Это говно ничего не стоит. Выклали в ОС её потому, что-бы 1) легально воровать код из других stdlib, 2) спихнуть на хомячков задачи по решению проблем. Получил баги/лаги/тормоза - можешь до скончания веков писать на в сапорт, а можешь коммитить.

Это уже лишь слова из-за ключевого слова «бы».

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

Ты украл в переходе диплом. К тебе подходят и говорят «Ты вор - ты несостоятелен» и ты начинаешь «у меня не было времени - я украл, а так бы я сделал». И именно это теперь определяет твою состоятельность. То, что ты бы сделал. Это же происходит и с растом. Его состоятельность его же адепты определяют через «бы» и ты это жрёшь.

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

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

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

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

Предпосылка номер два - в С++ есть какие-то проблемы, нужны какие-то системы сборки - нет. Это всё ненужно - это говно для бедных и бездарных. В основном эта пропаганда исходит и направлено на бездарных С++-адептов, которые жрут говно и ищут оправдания. Это типа того клоуна-вора.

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

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

Т.е. удобен и нужен говнарго только одной касте адептов - это бездарной школоте. Это те самые запартыши. Им нужно сдать зачётку - ничего понимать им ненужно. Спастил конфиг - спастил порятнки - сдал зачётку. Чем проще, тем клоунам лучше.

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

Именно поэтому в С++ нет унификации. Она никому ненужна. К тому же унификация есть - это ho. Этой концепции ненужны системы сборки, всякое нелепое говно и прочее.

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

Однако как удобно поддерживать проект на разных платформах, используя не header-only зависимости?

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

Тот же Qt (и все его аналоги в предметной области гуя).

Потуги несостоятельны. Ничего подобного в говнорасте нету.

Кстати - это ещё одно место, где тебя имеет раст-пропаганда. Я тебе опишу его ниже.

Компилировать только программу на Qt - норм, компилировать обязательно и программу, и сам Qt - леденящий душу п****ц. Тем более, софт с большой кодовой базой будет иметь ещё немало зависимостей.

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

К тому же- проблемы qt - проблемы qt.

И вообще, любую библиотеку с большой кодовой базой я предпочитаю иметь в предварительно скомпилированном виде, а не header-only.

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

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

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

Я тебе даже объясню как. Тебе раст-пропаганда постоянно впаривает «Решай проблемы на уровне мидла», «не используй мощь языка - жри говно». Знаешь почему тебе это впаривают? Почему тебе впаривают модули, раздельную сборку и прочий треш? Правильно - что-бы хомячки как можно больше орали и пацаны вынуждены были реализовывать всё это на уровне мидла. А Знаешь зачем это раст-пропаганде? Правильно, потом раст-пропаганда у тебя это украдёт.

И ты сам потерял профит и сам создал себе проблемы. Всё это нужно в мусорных недоязычках типа раста - тебе же это ненужно. Я даже больше скажу - это невозможно сделать.

Ты там выше рассказывал «как круто», но вот в чём проблема - ты не понимаешь. Твоё сознание забито пропагандой. То «круто» не будет работать в случае с раздельной компиляцией, в случае с хедерами для колхозников. Шаблоны так не работают, интроспекция/патчинг не работает. constexpr не работает - ничего не работает.

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

В реальности всё это нужно выкидывать. В ho и производных ненужен lto, ненужен pm, не нужны системы сборки, ненужны линкеры и прочий мусор. Т.е. ненужна та инфраструктура, которая является костылём и которая обязательна для всякого говна типа раста, но необязательна для тебя - вредна для тебя.

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

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

Именно на уровне языка можно однозначно и полностью решить проблему обновления сборки. Можно без проблем кэшировать сборку. Можно без проблем реализовать hot-reload и прочие фишки.

На базе этого можно реализовать полноценную C++-vm, которая обобщит constexpr и рантайм.

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

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 ()
Ответ на: комментарий от rebforce

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

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

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

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

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

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

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

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

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

У основной реализации питона, CPython, а также у Cython фундаментальным механизмом управления памятью является подсчет ссылок и освобождение объекта при обнулении счетчика. Причем, даже GC работает в рамках этого механизма, временно снижая счетчики для известных ссылок и разрушая те объекты, у которых счетчик оказался равным нулю. Instagram просто отключал у себя мусорщика, чтобы он после форка не жрал память через copy-on-write.
https://instagram-engineering.com/dismissing-python-garbage-collection-at-ins...
У PyPy счетчиков ссылок нет, а есть регулярно сливаемые целиком ясли (nursery), из которых живые объекты копируются в кучу, что больше похоже на какой-нибудь GHC в этом плане; у Jython и IronPython мусорщики стандартные JVM и CLR соответственно.

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

Ну так где можно посмотреть на Python без сборщика мусора? Где будут, например, команды для явного освобождения ставшей ненужной памяти. Где будет возможность управлять размещением объектов на стеке или в куче. И т.д.

Или такой Python, вместе с кучей других фантомов, живет только в вашей альтернативной вселенной?

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

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

del varname

Где будет возможность управлять размещением объектов на стеке или в куче.

CPython не умеет размещать объекты в стэке. По крайней мере, из коробки. Этого не умеет, к слову, и тот же Object Pascal. Вместо стэка есть поколения.

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

del varname

Допустим. Как тогда делить переменные на reference- и value? Например:

a = ["hello", ",", "world"]
b = a[0]
del b

Что из себя представляет b: ссылку или значение? Если ссылку, то каков эффект del b?

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

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

Я извиняюсь, но в питоне можно убрать сборку мусора, сделать компилируемую программу (Cython)

Нельзя, бездарность, как её нельзя убрать и из говнораста. Бездарность, наличие компилируемости ничего не значит. Никакой компилируемости не существует - существует она только в С/С++ в контексте чего-то маломальски живого.

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

Бездарность мусорная. Почему вы все, ублюдки, такие тупые. То, что всё это уже не будет питоном, бездарность.

Си - это один из многих языков промежуточного уровня

Показывай ещё один, мусор. бегом.

просто он оказался самым популярным

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

- но далеко не потому, что является самым лучшим.

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

У того же раста инструменты вполне себе уровня Си

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

, то есть - простые структуры и функции.

Нет, шлюха. Говнораст - это обёртка поверх llvm-ir, который является вариацией си, который написан на си, который существует в мире си. Ты же - существуешь в говне, мразь. Блеять.

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

Шлюха, а почему же их нету? А, мразь? Почему же всё это есть только у си и создано си и на си? Как так вышло?

Весь рантайм...

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

Он не построен, а реализован на Сихах

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

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

Актуально, шлюха. Именно поэтому говнораст 1в1 отражает семантику llvm-ir и семантику инфраструктуры llvm. Именно поэтому, мразь.

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

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

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

Почему я пишу код и ты в говне? Почему ты блеешь - и ты в говне? Почему ты, шлюха, рыдаешь когда видишь С/С++? Почему ты, шлюха, всегда в говне и блеешь мусорные оправдания? Что тебе не дали и именно поэтому ты не смогла?

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

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

Ты раб, ты шлюха мира С/С++ и ты блеешь что-то лишь потому, что тебе дали эту возможность. Люди глупые и думаю, что дав тебе возможность - ты поумнеешь. Нет, мразь не умнеет. Мразь - это биомусор, по определению.

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

К сожалению, хорошо писать хорошо оптимизирующий компилятор - весьма трудозатратно.

Нет, падаль. Это сделать очень просто. llvm/clang написан школотой, особенно в те времена, когда подобные тебе шлюхи начали кормиться за его счёт.

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

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

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

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

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

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

И это говно не работает с системой на уровне сисколов, шлюха. Оно работает с системой на уровне libc(и её расширений).

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

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

В Си нужно было добавить намного, намного меньше для того, чтобы язык стал конфеткой. А именно:
- структурированные исключения, которые позволяют погружаться во вложенные блоки без создания спагетти-кода для корректного выхода;
- автоматическое (на уровне компилятора) управление выделением-высвобождением структур, как это было сделано, например, в Object Pascal, где локальные массивы, структуры, строки, и интерфейсы компилятор оборачивает в инициализацию-финализацию, которая будет в блоке try..finally при наличии поддержки обработки исключений (а она не во всех компиляторах есть).

Всё. Не нужно классов, не нужно шаблонов - просто возможность объявить инициализаторы-финализаторы для некоего типа. Что они навыдумывали с крестами - это кошмар, всё, что только нашли на свалке, всё притащили: стул без ножки, сломанный телевизор, половину сверла (можно подточить), разорванные кроссовки.

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

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

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

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

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

Более-менее адекватная реализация замыканий есть в Расте, как я уже писал неделю назад здесь.

Прошмандовка - никакой реализации чего-то на говнорасте нету - это всё ir.

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

Нет, шлюха, ты опять обгадилась. Хотя после того как я тобою вымыл полы в теме про хаскель - ты ничего не поняла, шлюха.

Дак вот, лямбды в говнорасте - ворованные из С++(есть инфа, что ворованные из руби. Но это очень сомнительно. Как максимум это лишь повлияло на трансформацию [] на || т.к. [] не вмещается в говносинтаксис) вариация []{}.

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

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

Тупая ты прошмандовка. Явно указание ненужно в С++, тупая ты шлюха. Явно указание нужно для конфигурации захвата. В говнорасте конфигурации никакой нет - есть только move вариация. Хотя move в этом говне нихрена не move.

Дак вот, шлюха, в С++ всё это есть. Но в отличии от твоего говна - я могу ещё и указать конфигурацию для КАЖДОГО захвата, либо для ОТДЕЛЬНЫХ захватов. Чего ты, шлюха, в говнорасте сделать не сможешь.

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

Какое же это говно мусорное бездарное. Что несёт эта шлюха? Это либо совсем тупая шлюха, либо попросту второсортная пропаганда.

Шлюха попросту врёт в очевидных вещах. Тупая ты падаль гнилая.

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

Всё. Не нужно классов, не нужно шаблонов

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

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

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

Егора Бугаенко... «Elegant objects».

Статические методы в любом контексте — безошибочный индикатор плохого программиста, понятия не имеющего об ООП. Для применения статических методов нет ни единого оправдания ни в одной ситуации. Забота о производительности не считается. Статические методы — издевательство над объектно-ориентированной парадигмой. Они существуют в Java, Ruby, C++, PHP и других языках. К несчастью. Мы не можем их оттуда выбросить, не можем переписать все библиотеки с открытым исходным кодом, полные статических методов, но можем прекратить использовать их в своем коде.

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

Егор рассуждает по нашему вопросу и о преимуществах неизменяемости объектов https://youtu.be/lfdAwl3-X_c

Напомнило: https://www.youtube.com/watch?v=5Srg0i3Vc2o

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

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

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

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

a = [«hello», ",", «world»]
b = a[0]
del b

Что из себя представляет b: ссылку или значение? Если ссылку, то каков эффект del b?

Переменная в CPython - это всегда ссылка на объект. del b удаляет ссылку и снижает счетчик ссылок у объекта. Когда у объекта будет ноль ссылок - вызовется деструктор объекта. В данном примере b - это ссылка на объект-строку «hello», на которую также ссылается список a. Конкретно строки в питоне неизменяемы, потому изменение строки будет изменением ссылки, а не изменением самой строки.

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

llvm/clang написан школотой, особенно в те времена, когда подобные тебе шлюхи начали кормиться за его счёт.

У нас тут целая индустрия школьников, судя по всему:

История LLVM началась в 2000 году в Университете Иллинойса. В настоящее время LLVM используется, в том числе, в компаниях Adobe, Apple и Google. В частности, на LLVM основана подсистема OpenGL в Mac OS X 10.5, а iPhone SDK использует препроцессор (фронтенд) GCC с бэкэндом на LLVM. Apple и Google являются одними из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — 11 лет работал в Apple. C января 2017 Крис работает в компании Tesla Motors

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

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

Какой же он бред несет, это жуть. Приходится периодически отвечать, чтобы не создавать ощущение, что с ним согласны:
https://github.com/kmcallister/syscall.rs - Raw system calls for Rust https://crates.io/crates/syscall

byko3y ()