>>187427
Сборщик мусора. В той нише, куда метил D это оказалось критическим недостатком. Можно отключить, но тогда перестанет работать стандартная библиотека.

>Кто знает язык D?

Кто-то знает, пожалуйста задавайте меньше мета-вопросов в /b/

>Думаю форкнуть его и добавить фичи. Подводные?

Ты хочешь форкнуть их компилятор, а не всю спецификацию языка. А компилятора у него три: свой, на базе gcc, на базе llvm. Тебе надо писать enhancement proposal и как-то его обосновывать, с примерами кода.

>>187433

> пожалуйста задавайте меньше мета-вопросов в /b/

Но почему?

>>187434

Я предполагаю, и даже не вполне безосновательно, что автор призыва задавать меньше мета-вопросов был под впечатлением ѿ сайта https://nometa.xyz/ (или аналогичного ему) до такой степени, что не обратил своё внимание на то, что сайт призывает не совершенно воздерживаться от мета-вопросов, а только тотчас же задавать болѣе конкретные вопросы вслѣдъ имъ.

>>187437

>а только тотчас же задавать болѣе конкретные вопросы вслѣдъ имъ.

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

>>187429

Да, если ѿрѣзать ѿ этой иллюстрации правый нижний угол (в котором указан 2015 год), то может показаться, что идея сегвееподобного или хотя бы электросамокатоподобного транспорта (компактного, индивидуального, для ѣзды лицом вперёд, стоймя, без приложения собственных физических усилий, кроме необходимых для удержания равновѣсія) старше, чѣмъ въ дѣйствительности.

Но нѣтъ!…

>>187475
Тащем-то идея сегвея берёт начало в XIII веке, в качестве доказательства привожу вот эту средневековую фотографию

>>187448
Получается, в ОП посте правило, связанное с мета-вопросами, выполнено полностью.

>>187429

>перестанет работать стандартная библиотека

Опять Поттеринг постарался?

>>187481

>Поттеринг

Ну не троль пожалуйста

>>187482
Думаешь, под ОП постом возможна адекватная дискуссия?

>>187485
С каких пор направление дискуссии на новере определяется оп-постом?

>>187500
С тех самых.

>>187500
Я тут недавно.

>>187503
Одна из картинок на главной была вдохновлена постоянными дерейлами в /b/

>>187506
Так вот что все это значит.

D - это плюсы сделанные правильней.

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

Зато по крайней мере откровенно плохих идей и мусора как в плюсах нет и ABI какое-никакое а есть.

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

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

Начнём с того что тебе вероятно придётся таки заняться как раз таки этим - нормальной реализацией druntime, а она во-первых не такая маленькая, во-вторых не особо документирована, а существующая к тому же местами жёстко завязана на glibc и/или x86.

>>187998

> откровенно плохих идей

Ето какие?

>>187998

>Сборщик мусора там может быть любой реализации, хоть с рефкаунтом

Важно не то, как он реализован, а гарантиях, которые он предоставляет, отчего логика кода, который полагается на RAII будет существенно отличаться от того же кода при использовании GC. В том же ублюдском Юнити приходится вручную расставлять Object.Destroy() и писать дополнительную логику там, где с std::shared_ptr<> проблема бы даже не появилась.

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

Эту задачу гораздо эффективнее решают пулы объектов в явном виде. Тем более, что в той же Юнити их всё равно приходится писать чтобы не провисало на внезапной сборке мусора, только без RAII они выходят ещё и неудобными - вручную расставлять retain и release по всему коду и ни в коем случае не ошибиться это то ещё удовольствие.

>и мусора как в плюсах нет

Давно пора принять волевое решение и сделать strict c++2 с чистого листа, как однажды было сделано с OpenGL3, а чтобы на него было проще переходить, заодно выпустить некоторый язык склейки вроде того же "Objective C++". Вопрос не только в мусоре, многие вещи в новых стандартах сделаны через жопу просто для того, чтобы не сломать бородатое легаси.

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

>>187999
Я думаю более коротким списком будут хорошие идеи которые там всё же затесались. Но если интересно, хорошей аггрегацией будет https://yosefk.com/c++fqa/

>>188000
Использование специфичных пулов для явных случаев оптимизации действительно как правило хорошая идея. RAII в этом случае может помочь с рефкаунтом, а корутины - с использованием рефкаунта даже в многопоточных и асинхроных сценариях.

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

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

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

Однако та ситуация что ты описываешь в юнити, едва ли имеет много отношение к тому или иному подходу, скорее к комбинации ограничений языка (C#?), продуманности апи конкретного фреймворка или конкретной реализации GC. Например, в go такой проблемы не существует как класс, а в случаях где речь идёт например о закрытии сокетов, файлов или ещё каких внешних контекстов - есть defer.

> Давно пора принять волевое решение и сделать strict c++2 с чистого листа

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

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

>>188024

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

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

> Например, в go такой проблемы не существует как класс

defer, как и using C# лишь частный случай и не про то. Такой пример, ты назначил 3 текстуры на десяток материалов, которые назначил 15 мешам, которые живут своей жизнью в разных частях кода, и внезапно встаёт задача вычислить, какие текстуры очистить, когда какие-то из мешей уничтожаются. С рефкаунтингом это вообще не вызывает проблем, передал текстуры как shared_ptr и они уничтожатся сразу же как только на них перестанут ссылаться. Так же удобно решаются задачи игровой логики с вовремя протухающими weak_ptr вместо, скажем, преследования несуществующих зомби-объектов. Не знаю, может, только в геймдеве возникают подобные задачи и ему нужен свой язык. Я успел уже устать и от плюсов, и от шарпа, и даже веб немножко зацепил.

>октровенно вредительских фичей вроде множественного наследования

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

>Все попытки тех у кого была мотивации таковые делать уже давно вылились в свои языки.

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

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

>>188031
Взгляни на vala.

>>188031

> кодогенерировал код на плюсах

Но зачем?

>>188030

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

В плане удаления текстур из gpu -- ситуация действительно специфичная, когда у тебя есть референс какого-то внешнего расшаренного ресурса. И тут проблема не столько в GC, сколько в отсутствии пропагируемых деструкторов, что в D как раз не случай.

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

Тут ключевая проблема, что код на С++ не совместим с самим кодом на C++, никакой стандартизации ABI нет до сих пор. Ломающийся ABI из версии в версию компиляторов, не говоря уже о совместимости между компиляторами, никуда не делся -- поэтому мы такую шизоту как header-only либы и имеем. А когда чему-то на C++ нужно сделать либу или ещё какой-то бинарный интерфейс, это приходится делать на C.

>>188038

>никакой стандартизации ABI нет до сих пор.

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

>>188096

>>188038
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

>With the Go implementation, the Read States service was not supporting its product requirements. It was fast most of the time, but every few minutes we saw large latency spikes that were bad for user experience. After investigating, we determined the spikes were due to core Go features: its memory model and garbage collector (GC).

Вот дураки там в дискорде, настроить не смогли

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

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

>>192412
Чем ооп не угодил?

>>192419
говняный подход созданный говняной безликой софтовой миникорпорацией, повсеместно появившейся в 90е.

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

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

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

берётся какая-нибудь популярная методика(раньше например mvc), которая вообще нихуя не имеет отношения к домэйну, а изначального дизайна мы в принципе делать не будем, т.к. манагеры ответственность на себя брать не хотят и платить архитекту нормально мы тоже не хотим. после этого один из молодых наивных сеньёров назначается тимлидом и ему поручается задача курировать общую разработку продукта, т.к. он лох и готов работать 12 часов в день за похвалу. потом вся тима занимается хуй пойми чем, пишет в лучшем случае структурный код, премачур оптимизирует, пишет какие-то хуёвины которые будут выкинуты, ходит согласовывать хуету, при этом каждый обязан знать ВСЮ кодобазу, так что по сути в итоге код пишет тот самый тимлид, остальные гоняют чаи, в итоге на демо мы выезжаем с кучей забагованного говна. тут какой-то манагер подрывается и говорит напишите тесты и отрефокторите. ну тесты естественно пишутся после кода, ведь в этом и есть их сакральный смысл, а рефактор представляет из себя кодгольф всем тем говнокодом, который загоняется в арбитрари классы по принципу наименьших усилий. потом лид и сеньёры в ахуе убегают и мы нанимаем новую тиму чтоб мэйнтейнить ``продукт". для того чтоб хоть как-то манажить весь этот анальный цирк придумали скрам/аджайл, а казалось бы можно было просто нормально организовать разработку изначально.

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

>>192419
>>192421
а, ну собственно проблема ооп в том что он энейблит тот самый второй подход, т.к. "классы" дают иллюзию контроля над кодом и неограничеснные возможности преждевнеменных эякуоптимизиций. ооп это методология-пиздабол, всё в нём пиздит. классы пиздят что они абстракция от структуры программы, инкапсуляция пиздит что она гарантирует разделения исполнения.

функция же абсолютно правдива - она трогает точно то что упомянает в аргументах, а иммутабельность гарантирует отсутствие сайдэффектов. функия это более гибкий элемент абстракции исполнения, и единственный аргумент против функций БУКВАЛЬНО является преждевременной оптимизацией. не надо преждевременно оптимизировать, не делой так, будь няшей как чень.

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

>>192443
что ты пони под хорошим кодом?

>не нарушал архитектуры

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

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

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

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

>>192421

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

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

>>192412

>для си сделали раст, который по сути настоящий си+

Гормоны принмаешь? Волосы красишь в малиновый, синий и так далее?

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

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

в расте дохуя умных людей, потому и трансов много.

алсо у нас есть алиса, она биологическая девушка.

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

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

>>192945

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

Это не вопрос мозгов, а вопрос морали, если ставить его так, как ставишь его ты. Если отвлечься от поддержки SJW, трансы - это вопрос психиатрии.

>в расте дохуя умных людей, потому и трансов много.

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

Почему в расте засилье джаваскриптеров и трансов? Дело в оголтелой пропаганде, которая уже превратилась в мем "приложите раст и CVE рассосётся". Тогда раст продавался как простенькая (не безопасная, а именно простенькая) замена C++ по последним стандартам хайпа в жабаскрипте (мода фронтендеров на ФП сюда тоже относится, что характерно, делать ФП в языке, для него не особо предназначенном - верх глупости). Ну и занимался растом у нас рассадник SJW, занимавшийся вебом. Вот и произошёл исход всей этой шушеры на язычок, при этом они как не были способны написать что-то полезное, так и не будут, но зато они будут вести оголтелую пропаганду раста, которая льётся сейчас изо всех щелей. И если они справятся со своим делом, то тогда на расте действительно появится что-то полезное.

Кстати, ЛГБТ-шушера в принципе не может написать ничего полезного просто потому, что в её целях это не стоит. ЛГБТ-шушера мечтает о том, чтобы писать статейки вроде тех, что на model-view-culture лежат, строчить в твиттер и выступать в роли красных комиссаров, приклейтед к моему предыдущему посту этому отличный пример.

Вернёмся к

>для си сделали раст, который по сути настоящий си+

Раст никогда не был убийцей C++. Судя по одному ансейфу, это убийца сишарпа, но без VM.

Да и серьёзные языки обычно делаются без цирка с макаками (централизованный репозиторий и своя система сборки проектов).

Убийцей Си раст не задумывался в принципе, если же ты так думаешь, вспомни слова «Если тебе нужен PL/I, ты знаешь, где его взять».

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

>>192948

>параграф апелляции к личности

олды, как я вижу, тут.

>>192943

Это не ответ, это тот же пространный пост "Макаки не могут реализовать ООП" и "Я думаю шо ООП говно тому шо я думаю шо ООП говно тому шо я думаю шо..."

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

>>192952
кодобаза должна хорошо надеваться на домэйн. объекты надеваются на всё как сова на глобус. функция более удобный уровень абстракции.

тезисно, ооп против функций
-инкапсуляция, бесполезное гавно
+иммутабилити, гарантирует детерминированное исполнение

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

-полиморфизм классов, но зачем?!
+полиморфизм как средство композиции, база

>>192952
Ему вумные программисты на JS в колготочках сказали, что ООП фу, ненужно и устарело. Потому и тезисы выглядят как

>бесполезное гавно
>гавно
>но зачем?!

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

>>192976
ООП предполагает что ты потратишь в 10 раз больше времени прописывая абстракции ради абстракций, зато когда-то потом с кодом будет легко работать, фиксить и адаптировать под новые требования.
Но знаешь с чем легко работать, фиксить и адаптировать? С функциями без сайд эфектов.

>>192978
у меня есть подозрение что ооп было продано манагерам джаваблядьми в девяностых как "можете описать всё в документации умл-диаграмами а программа практически уже будет".

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

Вы что, на серьезных щах предлагаете ебашить функциональщину в продакшен?

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

Если функциональная парадигма такая збс, то почему Хаскел и CL так и остались в основном на уровне домашних свистоперделок? CL уже даже из AI выжали. Кто? Питон c ООП. OpenAI целиком на питоне.

>>192982
ясно.

>>192978
ФП предполагает, что ты потратишь в десять раз больше времени, протягивая данные до I/O и аутируя за написанием чистых функций.
Зато когда-то потом с кодом будет просто работать, а, нет, не просто, придётся ещё один нюанс довести до I/O и стейт как-то поменять, а у нас чистые функции кругом. И понаписать отвязанной от логики программы абстрактной логики перемешивания стейта с функциями, чтобы хоть как-то свести концы с концами.
Не знаешь, с чем проще работать, мелкобуква, научившаяся в шифт? С процедурами.

>>192980
У меня есть подозрение, что ФП продаётся в твиттере сойбоями, не умеющими кодить, но очень хорошо умеющими ретранслировать чужие непроверенные выкрики. Довольно характерно то, что основные продвигатели ФП сидят не на хаскеле с лиспом, а на джаваскрипте.

А теперь мы поговорим про объективную реальность. Объективная реальность печальна. Что ФП, что ООП дают оверхед выше сишки и не кладутся так легко на ассемблерный код, требуя оптимизаций и вранья самому себе либо по поводу того, что в программе есть объекты, которые, видите ли, разговаривают друг с другом как 24 личности в голове у шиза, либо по поводу того, что программа, видите ли, ничего не изменяет и вообще в процессе работы программы полная иммутабельность данных, при этом в программу как-то попадает состояние и в ней как-то производится i/o, а ещё же как-то многопоточность работает на магических примитивах, которые стопроцентно функциональны, не говоря о том, что сама программа якобы должна быть чистой функцией от начала до конца (чего не бывает).
Объективная реальность такова, что на самом деле весь код состоит из процедур, на всё это сверху понавешали скрывающих нужное и протекающих там, где не надо абстракций, которые, внезапно, не могут жить полностью в себе и их постоянно прорывает до похабной процедурщины (объективной реальности) тем или иным образом. А если так, то зачем платить больше и придумывать себе мирки с розовыми понями и радугой, в которых всё безопасно, но которые почему-то всё так же текут по памяти, падают по OOM с ZeroPointerException и неистово насилуют malloc якобы без сайд-эффектов?

>>192984
я тебе привёл аргументы, но ты не можешь в риторику и они остались без ответа. как ты думаю понимаешь, если ты не можешь в риторику то врядли ты можешь в дизайн систем, и твоим мнением(а это действительно параграфы мнения) можно выретерь жопу.

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

Все соснули у процедур, а стейты не нужны.

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

>>192984

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

А что думаешь о метапрограммировании?

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

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

https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html

тем временем в расте гаты стабилизируют. ну вот и всё, раст официально дал посасать эфшарпу.
>>192991
и?
>>192998

>спасибо семён

>>193021
есть хачкель как идеал.

>Что касается метапрограммирования, оно бывает разное

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

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

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

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

>>193167

>мам чё такое монада

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

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

you wanna get on bottom? you know that's the point you probably wanna be.

>>193169
Абстракции и синтаксический сахар - это всё конечно здорово, но ни в отладке, ни в профайлере не помогают, если под капотом всёравно череда *как-то* оптимизированных вызовов чистых функций при их трансляции в байткод процессора.

>>193170
Не уверен почему ты мешаешь фп и раст, в расте ключевое не отсутствие мутабельности, а овнершип-контрол и рефкаунт. Владелец обьекта его мутирует как хочет и имеет непосредственный контроль над исполнением (если не считать квирки стандартной либы, но сама стандартная либа опциональна).

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

>>193175

>в профайлере

вот поэтому и нужен раст

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

в чём же секрет гуглопараши? гигантская корпорация, но НЕ МОЖЕМ ПОВТОРИТЬ поиск как на яндексе или переводчик как у дипл.

>>193162

> программист не разрабатывает программу, программист разрабатывает кодовую базу с мэйнтейнабилити, экстенсибилити и юзабилити ин майнд

Вот поэтому программы написаны на PHP, Python, Java, и C (с классами), а функциональщики продолжают пилить кодобазу.

>>194332
Пишу функциональным и процедурным стилем на питоне. Где твой Страуструп теперь?

>>194345

>функциональным стилем на питоне

Смешно пошутил, жги ещё.

>>192984

> ФП предполагает, что ты потратишь в десять раз больше времени, протягивая данные до I/O и аутируя за написанием чистых функций.

Это предполагает Хаскель. И даже в нём поняли, что прописывать везде явно контекст - это максимальное нинужно, и обмазали весь код неявным try ... catch.

> А если так, то зачем платить больше и придумывать себе мирки с розовыми понями и радугой, в которых всё безопасно, но которые почему-то всё так же текут по памяти, падают по OOM с ZeroPointerException и неистово насилуют malloc якобы без сайд-эффектов?

Может, потому что они не текут и не падают (если всё-таки пользоваться розовыми понями и радугой из предоставленного тебе мирка функционального API, а не ебошить всё через unsafePerformIO и unsafeReadArray)?

>>193162
А ничего, что написание программ на чём-либо, кроме машинных кодов - это и есть метапрограммирование?

>>193162
>>194369
А теперь вы оба пишите определение метапрограммирование и смотрите, чтобы оно у вас не отличалось.

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

>>194332

>Си с классами

Это блять целых три языка программирования ты указал:

1. Сишка с GObject
2. Objective C
3. C++

>>194345
>>194359
>>194378
NixOS поставьте сначала, а лучше Guile, клоуны.

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

> метапрограммирование это по сути...

Ты, наверно, перепутал этот термин с каким-то похожим по написанию. Давай ещё раз.

>>194385
Если C# пришпындяжить, будет четыре.

>>194368

>Это предполагает Хаскель.

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

>Может, потому что они не текут и не падают

Текут, да ещё как. И падают. Просто надо иногда смотреть в top и понимать, что gc - не панацея и справляется со своей задачей крайне плохо. Ситуация, когда ты говоришь "Докупите планку памяти и всё заработает" - это как раз она.

>если всё-таки пользоваться розовыми понями и радугой из предоставленного тебе мирка функционального API

Это не решит наличия GC и его пролётов мимо мусора, как и то, что "чистые функции" насилуют malloc и копируют объекты вместо того, чтобы их передавать или двигать. У хаскеля вообще в принципе (как и у раста) не задумывалось ничего на случай вылета нуля из malloc. То есть, закончилась память - смело и безальтернативно дохнем. И если программу на сишечке можно написать так, чтобы её требования памяти приближались к константе, программу на языках повыше так уже не напишешь. Особенно с GC.

>>192986
Это

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

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

>>193162

>ну вот и всё, раст официально дал посасать эфшарпу

Думали, раст убийца плюсов и сишки, а оказалось - убийца сишарпа.

>есть хачкель как идеал.

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

>>193175

>но сама стандартная либа опциональна

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

>194378
>определение не важно

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

Кто же сомневался, что протягивание стейта и запил абстрактной неоптимизированной груды кода у нас это, оказывается, солюшен? Вот так вот и пилили Servo, без оглядки на реальность. И высосали кучу денег из Мозиллы. Чушь из поста я комментировать, пожалуй, уже не буду, настолько она жирна.