- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
// https://habr.com/ru/post/490222/
Почему мы должны сломать ABI
Прежде всего, есть несколько полезных изменений в реализации стандартной библиотеки, которые можно внедрить, если нарушить текущий ABI:
...
* Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex)
Follow us!
Блядь, как всё сложно. Модули-хуёдули, ABI какие-то. Взять бы всё, и на ассемблер переписать.
C этого момента поподробней.
Как оказалось не совсем.
Крестушачие конструкторы/деструкторы всё портят.
https://youtu.be/MWBfmmg8-Yo?t=484
> Если вы разработчик встраиваемых систем, то эти 5% могут стать гранью между работающим продуктом и необходимостью купить более дорогой и мощный чип, а он может стоить миллионы
А не пойти бы вам нахуй? Никакой гранью это не станет, это просто приведет к выкидыванию нахуй этой вашей триждыблядской крестоговняной стдлибы (возможно даже вместе с самим крестоговном и переходом на Си)
А вы выдрали из контекста кусочек, и опровергли. И я плюсанул не глядя.
>Большего можно добиться некоторыми оптимизациями
Главное-то здесь!
Лучшие алгоритмы дают ускорение НА ПОРЯДКИ.
Не какая-то заумная хрень. А простой отказ от алгоритмов маляра Шлемиэля.
Ассемблерные вставки в нужных местах дают ускорение В РАЗЫ.
"5-10% - питушня", по сравнению с профитами проистекающими от других отпимизаций.
> Главное-то здесь!
> Лучшие алгоритмы дают ускорение НА ПОРЯДКИ.
> Ассемблерные вставки в нужных местах дают ускорение В РАЗЫ.
Бывает так, что алгоритм и так самый лучший. Но при этом улучшать еще есть куда, и это оправдано. И кстати, можно взять самый лучший алгоритм, реализовать его на какой-нибудь скриптушне, например напитоне и на ассемблере - там тоже ускорение от ассемблера может быть на порядки из-за некоторых говноособенностей скриптушни
В ассемблере никаких локалей нет. Именно поэтому я за ассемблер
В ассемблере никаких regexов нет. Именно поэтому за «PHP».
Зачем? Зачем?
Просто сделайте новый метод.
> Это первое и очевидное решение. Если мы не можем поменять std::unordered_map, может нам просто добавить std::fast_map? Есть несколько причин, почему так делать плохо. Добавление типов в стандартную библиотеку обходится дорого как с точки зрения расходов на поддержку, так и с точки зрения образования. После введения нового класса неизбежно появятся тысячи статей, в которых объясняется, какой контейнер стоит использовать. К примеру, мне следует использовать std::scoped_lock или std::lock_guard? А я понятия не имею! Мне нужно каждый раз гуглить.
А у «Оберона» спецификация чуть ли не на одной странице. Вру, одна страница на синтаксис, 20 страниц — полное описание. Стандартная либа состоит из питушни вроде Texts.Scan и Texts.WriteString. Реальный пример:
А сколько страниц займет стандарт крестов, если из него выбросить стандартную либу? Я думаю что тоже очень и очень дохуя.
Сишку, кстати, можно в две страницы формального описания уместить?
Хех, а ведь когда-то этот том реально было прочитать.
Рекомедую попробовать ужать хотя бы JLS хотя бы на десяток A4.
Да, четырёх человек в десяток листов A4 вряд ли получится сжать.
Ты что, 15-ти летняя девочка?
А что если использовать «принцимп мухи»?
Если спамерство ещё можно простить, то двухпробельным говном срут только больные ублюдки.
TLC принципиально другой: если выкинуть команду expr и её синтаксис (по сути это язык в языке), то он вообще на пол страницы влезет. Правда, тогда придется потерять условные выражения, и он кажестя станет не ТП.
Альтернатива, которую они предлагают: сломать нахуй всё, ради глупой питушни. Питушни, которую в будущем они ещё несколько раз поменяют.
Это свидетельство анскильности комитета, который сперва бездумно принимает всякую хуйню. А когда она пошла в прод, пытается переделать её.
>Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению...)
А нужно было просто сделать std::php::regex
Именно поэтому я за Си - там комитет почти нихуя не меняет
По этому я за поссаль
Деструкторы, женерики, неймспейсы, динамические массивы.
Очень много.
https://wiki.freepascal.org/FPC_New_Features_3.0.0
https://wiki.freepascal.org/FPC_New_Features_3.2.0
«Object Pascal» от «Standard Pascal» отличается примерно как «C++» или «Objective C» от «Plain C».
http://pascal-central.com/docs/iso10206.pdf
Но речь даже не о багланде, а об fpc. И туда регулярно завозят новые фичи.
«fpc», как и «Delphi», реализует «Object Pascal». Сейчас они немного разошлись: в «fpc» завезли одни конструкции, в «Delphi» — другие. Стандарта на «Object Pascal» нет. На базе «Object Pascal» ещё несколько проектов: «PascalABC», «Oxygene»...
Мне нравится «Object Pascal»: он не такой примитивный, как «Standard Pascal» или «Oberon», но и не такой сложный, как «язык Ада».
Собственно и lua не меняется уже лет 17, только мелкие исправления и минимальное добавления функции. Вот 30 июня вышла новая версия.
И багор, именно из-за того что он меняется.
https://govnokod.ru/26508#comment534819
https://github.com/bolknote/SedChess
Я всегда говорил что ed и его производные — выбор скилльных пацанов.
В статье ссылки на «тетрис», «сокобан» и «калькулятор».
https://catonmat.net/ftp/sed/turing.txt
Какой GUI )))
Например первый ход Ng1-f3 записывается как «g1 f3».
Так же в игре есть особенность. В отличие от нормальных шахмат король может уходить «под бой». И для победы его надо явно забрать.
Король спасась от мата может «есть» свои фигуры.
Пример:
В обычных шахматах на невозможности friendly-fire построено огромное количество трюков и моментов. Например паттерн «спёртый мат».
Но многие вореции эзотерических шахмат, вроде js на 1kb альтернативно трактуют те или иные сложнореализумые правила. Вроде рокировки, выбора фигуры превращения и взятия-на-проходе.
Интересно было бы ещё изучить как он ведёт себя когда ему «пат».
Но спать уже хочу нереально.
Судя по коду полагаю что король просто пойдёт под бой, где его можно будет съесть. Что впрочем соответствует очень старым правилам, где и «пат», и «мат» считались победой.
Это как застывшее говно мамонта, которое никому не нужно.
Или студенческая поделка на гитхабе, на которую забил её единственный автор.
Тем более что все полтора адепта begin~end используют совершенно другие диалекты Паскаля.
ruby?
Сейчас можно скачать «FPC», который можно запустить на ARM («Linux», «WinCE», «Android», игровые сосноли), на PPC («Amiga», «AIX», «Linux», «Mac OS X», игровые сосноли), на SPARC («Linux», «Solaris»), на 68000 («Amiga», «Linux»), на x86 в 32-битном режиме («Windows», «Linux», «Mac OS X», «FreeBSD», «Solaris», «OS/2», «Haiku», DPMI), на x86 в 16-битном режиме (голый «DOS»), на x86 в 64-битном режиме («Windows», «Linux», «FreeBSD», «Solaris»).
Поддержка «DOS» нормальная, даже круче, чем у «Турбо Паскаля» (добавили указатели типа huge), не то, что экспериментальный проект «gcc-i8086», который даже указатели типа far не поддерживает.
Помимо этого можно собрать или скачать готовые кросскомпиляторы для целевых платформ AVR («Arduino»), «Win16», «JVM», «UEFI», «NativeNT» (можно писать программы, которые зависят только от «ntdll.dll», а не от клиентских библиотек, и даже драйвера нулевого кольца). Даже давно забытый «MIPS» не обошли стороной.
https://wiki.freepascal.org/FPC_JVM
https://wiki.freepascal.org/DOS
https://wiki.freepascal.org/AVR
https://wiki.freepascal.org/ARM
https://wiki.freepascal.org/UEFI
https://wiki.lazarus.freepascal.org/Target_NativeNT
https://wiki.freepascal.org/MIPS_port
Самое удивительное что у них вся инфраструктура родная: компилятор и экосистема написаны на Паскале.
В отличии от «пuтушни» и остальных clang/gcc-based недоязычков где всё ворованное.
Проверку дискриминанта у записи с вариантами они реализовывать не стали (проверку реализовали в «Irie Pascal», а больше реальных примеров я не знаю). Сделали точную копию сишного union, как и в «TP».
Единственное, что пока не очень радует — слабоватый оптимизатор. Даже у «Delphi» и у «Virtual Pascal» код был чуть-чуть быстрее. Но их можно понять: они начали с нуля, не используя кодогенератор «gcc» или «llvm», при этом поддержали несколько разных процессоров.
Ага, я видел.
https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_code_generation_through_LLVM
Ну шланг они в транке прикрутили, как опциональный кодогенератор.
В игрушечном стандартном «Паскале» была ещё одна особенность, которую редко реализовывали: разыменовывание файловой переменной. Реальный пример: Эту неявную питушню «fpc» реализовывать не стал.
Прямо ко-ко-кое-то «MMIO».
Что-то типа volatile.
В «Турбо Паскале» (и в других компиляторах вслед за ним) заморачиваться не стали и вместо перегрузки разыменования положили в стандартную библиотеку процедуры Read и Write.
Он тут читает по одному и тому же адресу. Через «mmap» таким образом он бы прочитал одну запись, которая находится в начале файла.
Т. е. f^ — это ещё не геттер-сеттер, это «буфер».
*****
Когда я учился, нам приходилось переводить с «ISO 7185 Standard Pascal» на «Turbo Pascal 7.0», потому что в библиотеке были задачники по «ISO 7185 Standard Pascal», а на компьютерах был установлен «Turbo Pascal 7.0» (даже полный «Borland Pascal»). Так что нам приходилось объяснять преподам (которые в совершенстве знали только «Фортран»), почему наши конструкции отличаются от тех, которые в задачниках. По идее я должен был получить навык перевода с одного диалекта на другой на автомате.
Ждем std::mysql::real_escape_string
З.Ы. А ещё там есть unique_lock...
Никак, пишем свои.
Сломаешь биоритм, потом хер заснёшь.
Именно поэтому «Спокойной ночи».
Но... там же void...
А вообще я джва года жду кококой-нибудь movable_pop_back(). Чтобы можно было не писать питушарское «x = vec.back(); vec.pop_back()».
Зачем? Зачем?
>можно было не писать питушарское «x = vec.back(); vec.pop_back()».
> я джва года жду кококой-нибудь movable_pop_back()
Комитет будет всякую хуйню апрувить, а реально полезные вещи вроде этой — нет.
Откуда такие сумасшедшие вообще лезут.
Сумасшедший тут только комитет, который живёт в своём мире со стабильным ABI с розовыми пони и не видит, что происходит в реальности...
А в реальности только слабоумные и отважные решаются передавать std'шную хуйню между либами, собранными разными тулчейнами. Потому что в реальности какая-то мелочь да ломается. И проще пересобрать всё с нуля и не задумываться про ABIпроблемы.
> But sometimes, removing functions is actually a useful non-breaking change.
А я полагаю что автор. Который постоянно путает API и ABI
Когда питушня нравится ко-ко-комитету - "Как же, как же, столько кода сломается!"
Когда питушня не нравится ко-ко-комитету - "А хрен с вашими кучами кода. Перепишете!"
а так как существование бога никому пока не удалось доказать,
Как можно сломать то, чего нет?
З.Ы. У конкретных компиляторов то оно есть, само собой. Но не в стандарте.
Стандартизаторы, видимо, живут в своём мире, где после выхода нового конпелятора не надо пересобирать всё крестодерьмо.
По тону статьи оно звучит как API (сигнатуры методов, аргументы).
Но меня насторожило другое. Предлагается сломать всё нахуй ради мифического пиздежа про 5% пирфоманса.
Аргументы потрясающие:
The estimated performance loss due to our unwillingness to break ABI is estimated to be 5-10% This number will grow over time. To put that in perspective
> If you are a Big Tech company, you can buy a new data center or pay a team to maintain a library
Вот так и представляю, сидит правление компании с миллиардными прибылями и думает куда деть лишний миллион.
Айтишным обезьянам на поддержку говнолибы или начальству на шлюх и кокаин бонусы.
> If you are a game company, it might be the difference between your game being great or your user vomiting in their VR headset
> If you are in trading, it might be the difference between a successful transaction or not.
И вообще если судьба человечества так сильно зависит от 5% пирфоманса, что было бы если б вдруг рост процессорных частот остановился в районе 1-2Ггц. Походу коллапс мироздания.
Анскильному отребью конечно неизвестно, что улучшение алгоритмов ускоряет программы В РАЗЫ.
Представь, что ты добавил новый опциональный аргумент в какой-то метод. API не изменилось, старый код нормально скомпилится. А вот ABI сломано и неперекомпиленный код распидорасит при вызове.
И добавление новых аргументов не то чтобы ломает программу. Но заставляет вызываться другой перегруженный метод.
И это пиздец. В Свифте точно такая же вафля.
Стало:
Вызов
a(new Object[]{1,2,3})
стал ходить в другую сигнатуру
посылает нахуй с "Cannot convert value of type '[Int]' to expected argument type 'Int'"
Я думал только скриптухи себе такие неоднозначные перегрузки позволяют... Как console.log() или конструктор массива в js, к примеру.
Т.е. мне придется писать new Object[](new Object[1, 2, 3])) чтобы вернуть старый смысл?
>Т.е. мне придется писать new Object[](new Object[1, 2, 3])) чтобы вернуть старый смысл?
Я бы так писать не стал. Вдруг там:
>только скриптухи себе такие неоднозначные перегрузки позволяют...
То ли дело кресты с миллионом правил ADL и SFINAE.
>Т.е. мне придется писать new Object[](new Object[1, 2, 3])) чтобы вернуть старый смысл?
Я бы так писать не стал. Вдруг там:
void a(Object[][] o) {
}
Ну по крайней мере в крестах нельзя отстрелить себе ногу одной функцией без всяких там перегрузок...
Подтверждаю.
В скомпилированном коде нет никаких имён полей (они могут быть в отладочных таблицах и в RTTI, но на выполнение программы они не влияют), в нём только смещения. После переставления полей меняются их смещения.
Если вызывающий код и вызываемый компилировали с разным порядком полей, данные распидорасит.
На нашу репу из трёх бранчей...
> Сап, двощ. Я работаю курьером Delivery Club в ДС1.
> Есть один программист (я буду так называть его), на внешку бебифейс, но с патлами и бородой, возможно 24 — 26 года. Почти каждый !!! день с 2017 он заказывает еды на 500-1500 рублей. Чаще всего вечером. Сегодняшний случай заставил создать меня этот тред.
> Данный господин живет в трешке, видимо один, ибо это пиздец: вся хата — совковый интерьер, под стеной висит веревочный включатель времен совка, выцвевшие обои, некоторе места заклеены газетами аля «советский спорт», на полу часто видны тараканы, летают мухи.
> Но, картину ломают аккуратно сложенные коробки от процессоров, материнских плат, макбука. В некоторых валяются какие-то гайки и куски хлеба, коробки иногда пропадают, перемещаются или снова появляются старые. Сам задрот с патлами до поясницы и хуй пойми как растущей бородой, месяцами носит одну и ту же футболку. Весь его интерьер я разглядывал как и сказал с 2017, дальше порога я, увы, не заходил. Я видел у него какие-то книги по С++, которые валялись в коридоре, поэтому я называю его программистом.
> Нахуя я создал этот тред
> Когда я передавал ему заказ, я постоянно слышал воркование, и крики птенцов голубей (звук знаком с детства, проведенного на крышах), почти каждый день. Я думал это телевизор, но сомнения быстро рассеялись, потому что это было каждый день.
> Сегодня, передавая очередной заказ, я увидел ГОЛУБЯ! Он вылетел из дальней комнаты, и сел на совковый холодильник, который стоял в коридоре, и начал клевать какую-то хуйню там. У меня просто не было слов, я боюсь теперь туда ходить, думаю увольняться, потому что клиента не выбирают, нельзя там так — его заказы попадаются мне довольно часто. Определил его балкон — там часто тусуются всякие птицы.
Вот к чему крестоговно приводит!
https://tools.ietf.org/html/rfc6214
Адаптация RFC 1149 (это как 2549, но без QoS) к IPv6.
Звучит как болезнь. Опасная.
Программистская секта обладает очень серьёзными высокоразвитыми технологиями, которые и не снились даже инопланетянам. Они изучили днк таракана в совершенстве и управляют им как индивидуально, так и в массовом порядке на больших расстояниях.
Последние годы в мире появилось множество тараканов зрелого возраста абсолютно здоровых, но с полностью отсутствующей днк. Так вот это у Программистов произошла утечка прибора способного стирать с таракана человека всю информацию, но при этом ничего не записывать обратно.
И Программисты усердно ищут этот прибор, и кто его украл. Это как всем известный сайт домена в зоне org, которую контролируют шестипалые. Этот энергетический центр rfc6-2-1-4 находится в интернете в параллельном нашем мире только в другом измерении на севере-востоке ietf.org в 333-х хопах от него.
> Проснувшись, я увидел, что хлеб, который я оставил в пакете на столе, погрызен крысами, «Ну и чёрт с ним, что крысы в доме. Буду прятать продукты в металлический холодильник» — подумал я в тот момент и пошёл на улицу. Выйдя на улицу, я почувствовал покусывания в ногах, закатав колоши, я увидел кучу блох (14 штук). Изучив квартиру, я обнаружил, что они обитают в определенном месте в доме, которое находится далеко от комнаты, где я сплю, но чтобы выйти на улицу, я должен пересечь их логово. В общем, большую часть времени я находился в безопасной комнате (и блох на мне действительно в это время не появлялось), а когда нужно было выйти на улицу, я быстро пробегал через блохастую комнату, иногда даже выходя на улицу не подцепив ни одной блохи, но чаще всего 1-2 все же цеплялись.
Там видимо тоже какой-то протокол с блохами и крысами тестировался
Подозрительный курьер, про кресты знает...
А куда сейчас с TCL'ом можно пойти кроме курьерства? Циски админить разве что...
Последнюю строку даже проверил в интерпретаторе. Поначалу по ошибке передал f.call вместо f в f.call.apply.
> 'f'
Сила PHP!
В JS только поля можно по имени доставать, а питушни из скоупов - нет. Зачем, зачем?
Именно поэтому
"C++" тем крут, что можно без изменения стандарта придумывать новые фичи в синтаксис (хотя, ко-комитет так не умеет).
Не знаю, можно ли в чистой функциушне сделать циклическую сосульку. В данных вроде нельзя, иначе пришлось бы один раз присваивать. А в конструкциях, нужных для исполнения функциушни?
На ум приходят кобенаторы, хотя там на функцию ссылается не она сама, а объект-вызыватель, и вообще они зацикливают программу до смерти, там пофиг на циклование данных. Хотя, для зумерка не пофиг. Интересно, его можно сделать через код со сборкой сосулек?
Ну и использование питушни до того, как она была создана.
Кстати, функции можно перегрузить так, чтобы у них operator () для питушни, содержащий питушню вида _1, ... вызывал operator () от operator &. А operator & чтоб делал std::bind.
Вариадический питузок будет следить за каррированием. Если что, ему можно отдать operator , или ещё какой ненужный.
Паттерн матчинг можно попробовать накрутить через виртуальную питушню.
Как генерить АТД? Не знаю, может быть
type<a,b,c> будет эквивалентен type_<1,a,b,c>, type_<...> наследуется от type__ и expr.
Внутри | будет кастовать правый операнд - в type_<n+1,d,e,f>, если левый был type_<n,a,b,c>. Так вореанты будут пронумерованы, и паттерн матчинг сможет использовать разные классы для своей работы.
С вариадическими питухами и новыми возможностями C++ (например, perfect pituzing) можно сделать функциональную питушню повыразительнее, чем она была раньше.
type_<n> наследуется от func_<expr>
_1 - func_<expr, expr>
_1+_2 - func_<expr, expr, expr>
(_1+_2) & 1 - call_<func_<expr, expr, expr>, int> наследуется от func_<expr, expr>
Мне на глаза в комментариях на ютубе попался старый боян.
МатематикуПрограммисту и физику была предложена одна и та же задача: вскипятить чайник. Даны подсобные инструменты: плита, чайник, вода, спички. Оба поочередно наливают воду в чайник, включают газ, зажигают его и ставят чайник на огонь.
Затем задачу упростили: предложен чайник, наполненный водой и плита с горящим газом. Цель та же — вскипятить воду. Физик ставит чайник на огонь.
МатематикПрограммист выливает из чайника воду, выключает газ и говорит: "Задача свелась к предыдущей."
Так вот. Я его прочитал и понял что у программиста на крестах компилер должен догадаться сделать move-семантику.
Взять воду с чайника и выпилить деструктор/конструктор, то есть стадию выливания/наливания*.
* если чайник с водой был аллоцирован на стеке
Мысль избавиться от циклической питушни C++, делая все структуры немутабельными — красивая.
Тогда не придётся дрочиться с weakref и можно пилить всё на shared_ptr и uniq_ptr.
Зумерок - Z-комбинатор.
expr имеет в своём интерфейсе (), +, -, *, ...
a + b для expr<a_t>, expr<b_t> - объект типа expr<add<a_t, b_t>>. В случаях, когда a или b - вычисленные значения (не функции), за счёт вычислений над типами на этапе компиляции может быть достигнут тип expr<decltype(a_t() + b_t())>, а add использовать только когда один из операндов - функция.
Напомнило эту статью.
https://habr.com/ru/post/218341/
Избранные цитаты:
>Не компилируется. И лог ошибок на 64 килобайта. Почему?
>К сожалению, дождаться вычисления факториала семи мне не удалось, не говоря уже о том, что на 32-битных системах компилятор попросту умирает от переполнения стека. Но всё равно!
>Всё время, пока я писал пост, меня не покидала мысль: «Это или уже есть в Бусте, или пишется там в три строки».
Для каррирования есть std::tuple, std::tie.
Меня только раздражает что нужно писать РОВНО столько аргументов, сколько полей в кортеже.
Я знаю про std::any, но всё же.
>Паттерн матчинг можно попробовать накрутить через виртуальную питушню.
Его завезут в новом стандарте.
https://govnokod.ru/26337
Префиксный & - сахарок для std::bind (и чтобы потом при вычислении подставили значения()) для реализации ленивых вычислений.
Инфиксный & - сахарок для каррирования.
Кстати, префиксный & можно выкинуть в моём примере, если соблюдается ссылочная прозрачность, и h(10) дешевле вычислить сразу же при определении f.
Что интересно, префиксный & наверно понадобится только для замыканий. Хотя, аргументы замыкания - это всё равно особая питушня вида _1, _2, либо зависящая от _1, _2, а потому до вызова функции - функция.
В общем, префиксный & наверно встанет в один ряд со строгим паттерн хаскелевским матчингом и строгими версиями свёрток там же - где функциушня столкнулась с реальным миром.
Допустим паттерн-матчинг можно реализовать простым массивом struct с кортежем для матчинга и лямбдой.
std::any может интерпретироваться как истинный предикат.
>со строгим паттерн хаскелевским матчингом
А вот более сложные формы, вроде матчинга аргументов по типам, такого конечно не сделать. Но в крестах для этого есть шаблонные перегрузки и ADL (https://en.cppreference.com/w/cpp/language/adl)
1. Максимально функциональные языки. Они изначально проектировались под функциональщину, поэтому выражение функциональных парадигм в них наиболее простое и ёмкое. По-хорошему, «функциональными» нужно называть именно такие языки: «Haskell», «ML», etc.
2. Удачно-функциональные языки. Это мультипарадигменные ЯП, которые, тем не менее, обладают мощной и удобной функциональной составляющей. Возможно, это так задумывалось при проектировании, а, может, просто так получилось. Идеальный пример — «JavaScript».
3. Неполноценно функциональные языки. Это, опять же, мультипарадигменные ЯП, в которых присутствуют функциональные элементы: функции высшего порядка, замыкания, etc., но которые проектировались без учёта (или со слабым учётом, «на отъебись») функциональных парадигм. В принципе, на таких языках можно писать в функциональном стиле, но выглядеть это будет… хуёво. Реальный пример — «C++». Реальный пример реальной хуйни — последняя строка из моего комментария. Простая логика подсказывает, что там должно быть «apply(bind(invoke, f, _1, _2), x, y)»… А вот нихуя. Из-за каких-то чрезвычайно запутанных ограничений (кажется, invoke() принимает аргументы по rvalue-ссылке, а apply() не может их правильно пробросить в результат bind-а… примерно такая хуйня, короче) нельзя просто взять и написать идиоматичный функциональный код, а вместо этого приходится ебаться с компилятором и читать тонны ошибок в шаблонах. Поэтому ФП в крестах ограничивается простенькими лямбдами с, иногда, биндами. А кто пытается сделать что-то более сложное — тому в дурку надо (ну, если результат такого творчества в продакшен пойдёт, конечно).
4. Языки без ФП: нет либо функций высшего порядка, либо функций вообще. Борманд знает!
1. Максимально кастомизируемые языки. В них можно описать синтаксис и семантику любого языка и использовать (языки будущего).
2. Широко кастомизируемые языки. Можно наворачивать питушни, что код будет не похож на код на этом языке (например, Haskell; местами C++)
3. Малость кастомизируемые языки. В них можно только создать функцию и всё (C без препроцессора)
4. Некастомизируемые языки (brainfuck)
Кастомизация может поднять язык по оси функциональной выразительности. Я именно предлагаю поднять C++. И это не будет сильно страшно. Есть же boost::lambda, boost::phoenix, и такую питушню даже в стандарт пустили.
- Лишп изобрели, когда моя бабушка ещё была молодой, лол
2. Джава седьмая не нужна.
Следует ли из этого, что функции высшего порядка не нужны?
https://pecl.php.net/package/operator
Можно было бы перегрузить плюс... но автор его адаптировал только для 5.3 и 5.4, а потом приуныл.
Но вообще да, думаю, что минимум половина комментариев от фаек админа, ещё часть от ботов.
Кстати, насколько сложно задеанонить админов такого сайта?
Ты сидишь и ждёшь его давно.
Может, он забыл, что ты сказала,
Или человек — человек-говно.
https://youtu.be/5WJqEh7KvPU
https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
Там же ссылка на трюк Бартона — Накмана:
https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick
Ещё в одном термине опечатка, следует читать как NRVO:
https://en.wikipedia.org/wiki/Copy_elision
https://en.cppreference.com/w/cpp/language/copy_elision
SFINAE недавно обсуждали.
Как хорошо, что в «PHP» ничего из этого нет.
https://knowyourmeme.com/memes/i-accidentally
И тут мы приходим к тому, о чём я уже говорил.
https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html
СУКА. БЛЯТЬ. СУКА. БЛЯТЬ. СУКА.
У меня от этого говна до сих пор БИТОВОЕ И.
Какой выблядок придумал столько этих ебаных значков?