Вполне себе понятная вещь: код, который будет выполнен в будущем.
Это просто код. Добавка «который выполнен в будущем» либо требует уточнений, либо не имеет смысла (потому что не несёт никакой дополнительной информации — абсолютно любой с код с тем же успехом может быть выполнен в будущем).
ФП тут не нужно - идее обработчиков уже сто лет в обед.
ФП это делает юзабельным.
«Классическое» ФП а-ля нетипизированный лисп — потому что обработчики можно композировать. Сишные указатели на функции, как мы с вами оба согласились, композировать нельзя.
«Современное» ФП а-ля обмазали системой типов посильнее — потому что о коде после этого легче рассуждать. И вам не нужно делать interface ITextPredicate вместе с ITextOr и ITextAnd, вы можете просто написать string → bool.
Ну, на самом деле, имелись в виду просто множества - входных параметров и результатов. Множествами тоже мыслить непросто, кстати, привычка нужна, хотя их и в школе проходят (ну, я точно проходил).
Я и множествами не мыслю. Мыслю максимум типами, но почти синтаксически, точно так же, как работает proof finding в некоторых языках: условно, если у меня есть функция типа a → b и другая функция типа b → c, а мне надо a → c, то очевидно, как их совместить. Даже думать не надо, ни о морфизмах, ни о категориях, ни о множествах.
А вы, как я понял, мыслите действиями. Так вот, что, в вашем понимании, есть действие?
В моём — любой терм, тип которого имеет стрелочку первым конструктором типов. Ну, короче, что-то вида a → b.
может, проще захардкодить вызов этих двух функций в отдельном методе, и передавать его делегат
Кому проще и почему?
Вы там дальше про ASP.NET пишете, но у меня с ним ровно ноль опыта. В моём же опыте это оправдано тогда, когда одна и та же последовательность действий повторяется часто. Правда, тогда весь хардкод сводится к
compositeAction = f2 . f1
Написан ли уже этот accumulate?
Да. Это почтиstd::accumulate (только последний принимает пару итераторов вместо одного рейнджа, а std::ranges::accumulate почему-то не сделали, но для дискуссии это несущественно).
И если да, помнит ли про него программист, или ему надо в документацию лезть?
А вот это косвенно мой вам вопрос :]
Есть философия, что надо пользоваться стдлибкой по максимуму. Если вы придёте на конференцию по плюсам или почитаете модный блог, то там вам расскажут про std::for_each, std::accumulate, std::inner_product какой-нибудь, и так далее, и скажут, что их надо предпочитать голым циклам (потому что они делают код выразительнее, интент — понятнее, реализацию — безопаснее, и так далее).
Так про них-то и речь. Концепт один и тот же: сделать из двух действий третье. Просто в классическом ООП реализация такая, что за деревьями теряется лес.
Если вы про шаблон Стратегия, то он про другое - про вынос во внешний объект логическисогласованного набора методов.
Не обязательно набора. Там и один метод выносится, и этот метод обзывается «точкой конфигурации» или чем-то таким. Только смысл у него простой: он, собсна, выражает действие.
Я там весь ваш спор не читал, но по тому что прочел, он идет о том, как писать проще, что отождествляется с короче. Так? В таком виде этот вопрос мне обсуждать не интересно. Проблема с подходом ФП, на мой взгляд - что он не для людей, а для роботов: ну не мыслят люди (кроме специально обученных) малыми категориями и морфизмами.
Я ни разу не мыслил малыми категориями и морфизмами, и ими там мыслить совершенно не нужно.
Я мыслю операциями «применить к каждому узлу дерева такую-то функцию и собрать результаты в новое дерево» (это traverse), а затем, если надо, «собрать все эффекты из узлов нового дерева» (это sequence). Никакого теорката, ничего.
Лично я вот смотрю а программу чисто конкретно - как на рецепт, на последовательность действий, чтобы получить результат.
Тогда вам тот же вопрос, что и исходному товарищу. Что лучше,
int sum = 0;
for (int i = 0; i < vec.size(); ++i)
sum += vec[i];
Тезис «я ща вас побежду на вашем же поле» очень резко превратился сначала в продолжительное уточнение вопроса, кульминировавшее в на порядок большем количестве кода, вопрос не решающем, а потом в «да это всё игрушечные задачи и не нужно, и важны только 100%-о работающие компиляторы, только если это не компиляторы имеющихся языков».
Лично знаком с людьми, имеющими аналогичные идеи в Аляске, Вермонте и NH, и там поддержка, конечно, не большинства, но и ненулевая.
и то это, положа руку на сердце, инфантильные бредни какието
Почему? Не считаю это инфантильными бреднями. Техас отдаёт федералам больше денег, чем получает от них, у Техаса достаточно ресурсов для энергонезависимости, да и для военной независимости тоже, ЕВПОЧЯ.
США в данном случае первоначально создалась как куча раздробленных колоний которые за все время их существования слились в один конгломерат
И единым у этого конгломерата была только армия и отсутствие экономических барьеров. Внутренняя политика каждого из штатов могла быть произвольной.
ведь "желанные страны" - это желание переехать в удобное окружение для жизни. для белого человека это очевидно страны 1 мира, и почему бы не стремится к тому чтобы вся планета не была страной 1 мира?
Какие конкретно действия для этого надо совершать, кому именно, и зачем им это?
во первых, концепт единого государства на весь мир - решит довольно много проблем
С какими правилами? Ближе к КНР? Ближе к РФ? Ближе к США? Ближе к вашим конкретным фантазиям, потому что вы определённо хотите добра всем во всём мире, поэтому ваши фантазии к нему приведут, и поэтому же они и сбудутся?
объединение и стандартизация моральных принципов
На базе христианства, например. Ну вот просто большинством голосов. Готовы к полному запрету абортов?
Для маленькой симуляции объединения и стандартизации предлагаю вам остаться до конца жизни в РФ (вы ж до сих пор не уехали, верно?) и выгибаться буквой зю, но соответствовать её моральным принципам. Вместо РФ можете выбрать любую другую страну, где одобрямс моральных принципов зашкаливает за 86%, а оппозиции нет, потому что как же можно оппонировать такому мудрому и стандартизированному правительству.
Почему же вам не хочется? Может, потому, что нихрена моральные принципы на самом деле не стандартизовались, и пригодность страны для жизни коррелирует с (по крайней мере) историческим плюрализмом мнений в ней?
И, может, потому, что конкуренция между государствами хотя бы минимально заставляет их работать на благо населения — а то шарящее население уедет куда-то ещё, и государство кончится?
а последние лет 200 с экспансией запада (в т.ч. и России, запада - в том смысле что белого мира) и его взглядов на мир
«Конец истории» оказался несколько преждевременным, как показывает практика.
т.е. как идея - она принесет огромное количество плюсов и поднимет уровень жизни во всем мире.
Это если победят все правильные идеи, а все неправильные идеи не победят. Правда, тут есть один нюанс: почти любой носитель почти любой идеи искренне считает именно свою идею правильной, а остальные — ересью.
но вот идея с миллионом мелких государств со своими принципами - очевидно провальная
Неочевидно.
пока вполне очевидно что все проблемы с территориальными претензиями
Территориальные претензии как раз давно кончились, кроме пары маленьких, но гордых исключений, но не будем вскрывать эту тему. Остаются претензии к ресурсам (и это вполне возможно и в рамках одного мегагосударства, потому что ресурсы — они для моей клики или вашей клики, которые исторически ассоциируются с нацгосударствами), и так далее.
Физиологически гетерогаметному полу обычно хуже. Следовательно, мужчины должны выходить на пенсию раньше и иметь приоритетное обслуживание в медицинских учреждениях.
— Могу ли я написать функцию? — Да. Только не функцию.
Гм.
Ладно. Функции вычёркиваем.
В C# это сделать несложно даже в старом синтакисисе, без стрелочных функций: создаете объект
Ура, мы пришли к тому, о чём я говорил изначально: создаёте объект.
Кажется, умные люди в умных ООП-книгах называют это «стратегией» (вернее, частным случаем), и, кажется, я ровно такой пример видел в одной из них (но напрочь не помню, в какой). Там, правда, развешивалась целая иерархия в духе
interface ISomeStrategy
{
T run(T);
}
class Composite : ISomeStrategy
{
ISomeStrategy S1;
ISomeStrategy S2;
T run(T arg)
{
return S2.run(S1.run(arg));
}
}
вместо простого
compose s1 s2 = \arg → s2 (s1 arg)
(которое полиморфно и работает для любых функций, покуда типы подходят, и которое, тем более, во всех известных мне ФП-языках встроено в стандартную либу языка и пишется, скажем, просто как .), но это ведь то же самое и почти так же легко, поэтому программисты не будут лениться и избегать этим пользоваться, не так ли?
В C++, насколько я его представля, сложнее - там память этого объекта надо вовремя освободить, насколько это автоматизировано в современном синтаксисе - не в курсе.
Степени оптимизации, разворачивание циклов, поддержка разных типов архитектур, всяких версий наборов sse/avx, скорость компиляции, кроссплатформенность, логгирование. Я не разбираюсь в компиляторах, никогда не писал, но это список навскидку.
Про это я тоже писал: моя реализация давала более производительный код (и ещё имела зачатки статического анализа, лол).
Разница в том, что проценты поддержки семантики нельзя сравнивать напрямую. Я, к примеру, могу написать компилятор, с поддержкой 90% семантики за месяц. С кучей нюансов, да. И говорить, что эти идиоты писали свой годами. Что тоже будет некорректно.
Если они будут поддерживать не 90, а меньше, и выплёвываемый ими код будет работать медленнее, то вполне себе корректно.
Впрочем, в том месте я имел в виду, что мне всё равно, что моя программа корректно скомпилится на 90% или на 40%. Она всё равно не запустится.
Не понял, что это за «эргодичность» такая? В одном случае компилируется 90% программ, в другом — 40%. Это не то же самое.
Но сложный проект обязательно имеет много строк.
Вот здесь мы и несогласны, и весь тред выше — моя попытка пояснить примерами, за счёт чего именно.
Не в 10 раз никак.
И в 10 раз тоже.
Определитесь.
Давно определился: в первой (моей цитате речь не о сложности, а во второй (вашей) — о сложности.
Циркулярка может пилить доски вдоль. Торцовочная - только поперёк. Остальные ваши рассуждения про "пересекающиеся области" смысла не имеют.
Во-первых, мне ни разу не нужно было распилить плинтуса вдоль. Я их пилил только поперёк, и эту задачу могут решить и циркулярка, и торцовочная, и даже лобзик. Эта задача на пересечении.
Во-вторыю, циркулярка не может пилить доски вдоль сама по себе, потому что вам нужна обвязка, чтобы доску зафиксировать, например. Здесь есть тоже кое-какие параллели с этими нашими ЯП, но не будем об этом.
Нет. I said what I said. Я сказал, что ваше утверждение ошибочно.
Потому что что-то там про сложность и мощность.
У ПО есть всего две задачи: делать то, что требуется и не делать то, что не требуется.
Управление сложностью что-то очень резко сдулось, сразу после ФП в шарпе.
И у вас там в голове ничего не щёлкнуло, когда это писали, не? No bells ringing? Нормально вообще требовать семантики хаскеля от кода на шарпе?
Так я-то и не требую. Я констатирую факт, что у шарпа меньше средств выражения семантики композируемым и проверяемым компилятором образом, чем у хаскеля (а у хаскеля меньше, чем у идриса, например).
И я не вижу ваших проектов. Ни гитхаба ни продуктов в паблике. И у меня возникает интересный вопрос.
Предположим, я вам дам ссылку на, скажем, интерпретатор языка смарт-контрактов для одного из блокчейнов, куда я контрибьютил. Дальше что? Пойдёте переписывать его на сишарпе, чтобы сравнить сложность?
Должен ли житель глубоко южного штата, где снег идёт раз в год, сдавать такие же нормативы на вождение зимой/по льду, как житель глубоко северного штата?
Какие должны быть стандарты для сильно rural-штата, где 90% людей вне крупных городов, и как они отличаются от стандартов для «городских» штатов? Это не только вождение в городских условиях, это и послабление стандартов для того, чтобы люди могли куда-то добраться и быть продуктивными членами экономики.
В некоторых штатах можно делать right on red, в некоторых — нет, в некоторых — если подождать. Как унифицировать и почему?
Дальше чисто политически-философские вопросы: исторически федеративная система Штатов даёт очень много власти в руки отдельных, собсна, штатов, и федералам оставляет только регуляцию взаимодействий между штатами. Подобная децентрализация — это одна из тех самых мэдисоновских сдержек против централизации власти и следующей за ней тирании. Обсуждать в этом контексте права, конечно, смешно, но, во-первых, это смешно до первой отмены прав при голосовании не за того президента или выхода на протесты против результатов голосования, а, во-вторых, централизация одних аспектов власти в глазах общества легитимизирует централизацию других аспектов, где может быть ещё менее смешно.
При этом я по правам одного штата вполне могу ездить в (и, тем более, проезжать через) другой штат. Есть требования сдать старые права и получить права/ID нового штата (если старые права есть), если вы становитесь резидентом нового штата, но это требование тяжело энфорсить, особенно в граничных случаях.
И да, обмен прав на новые не требует сдавать экзамен по нормативам целевого штата (насколько я знаю, но IANAL). Учитывая, что в разных штатах могут быть очень разные требования, это получается забавно.
«расскажи, зачем снимаешь деньги со своего счёта и как их потратишь»
Или там,
Canadian Police Chief: “If you ever find yourself the victim of a home invasion, we are urging citizens not to take matters into your own hands... The best defense is to comply...”
(ведь наказывать преступников, или там вообще самооборона — это не либерально-просвещённая идея)
боюсь что человечество вообще не готово не то чтобы двигаться в эту сторону но и пытаться обсуждать эту проблему
Я готов обсуждать эту проблему. Давайте?
хотя они все одинаковые люди - мешки с костями, отличаются только записью в бумажке которая лежит в определенном месте на планете...если бумажка "такойто такойтович родился 1 апреля" лежит в Судане, вам не повезло, если в США - повезло
Они одинаковые мешки с костями (плюс-минус), это да. Но у них разная фирмварь, сформировавшаяся под влияниием культуры и условий что рождения, что даже немножко жизни матери.
Поэтому если чувак родился в Судане… хотя не, про Судан не знаю, так вот, если чувак родился, скажем, в Пакистане, а не в США или Европе, то куда больше вероятность, что в его культуре и парадигме отношений с обществом будут понятия кровной мести, скажем, а понятий толерантности (в классическом смысле) — не будет.
И поэтому это, например, выливается в очень прикольные графики о том, какие люди из какой страны рождения где-то там совершают сколько изнасилований.
И поэтому, например, мне было бы очень интересно послушать, почему я должен предпочитать наличие «беженцев» в своём месте жительства его отсутствию, или почему я должен предпочитать суданцев, сомалийцев и пакистанцев, скажем, белым африканерам, бегущим от геноцида.
Таки являются: в C++ - там есть унаследованный из C указатель на функцию, а ещё есть указатель на функцию-член (метод, иначе говоря)
Этого недостаточно.
Я могу написать функцию, принимающую два инта и возвращающую третий (их сумму). Могу ли я написать функцию, принимающую два указателя на функцию и возвращающую третий, указывающий, скажем, их композицию?
Олсо, для протокола: C++ — мультипарадигменный язык, поэтому для обсуждения «в ООП принято» лучше читать книжки по ООП, а не языки, которые среди прочего поддерживают ООП (но это неточно).
Это я ещё не касался других параметров. Скажем так, одну и ту же работу можно сделать множеством способов и помимо очевидного процента разборки токенов есть ещё сотни нюансов.
Например? Можно конкретнее?
Я устал от демагогии. Речь шла про, цитирую " 90% набора в правильно исполняемый код ".
На что вы ответили, что либо 100%, либо не считается. Так вот, компилятор плюсов (любой) не обрабатывает 100% исходников, соответствующих стандарту, так, как того требует стандарт. В чём разница?
Неопровержимих причин чтобы что?
Чтобы сказать, например, что «есть сотни нюансов».
Возвращаю: я утверждал, что ООП нужен для управления сложностью. Вы утверждали, что ваш "большой" проект на 5к строк справляется без ООП. Я утверждаю, что проект на 5к строк не может считаться большим. Какая нахуй вера?
Нет. Я утверждал, что судить о сложности проекта по количеству строк — бред, потому что разные языки обладают разной выразительной силой, и если две программы решают одну и ту же задачу, то они имеют одинаковую внутреннюю (которая intrinsic) сложность.
Да, проект на 50к строк (решающий то же, что проект на 5к строк) может иметь большую «добавленную» сложность из-за языка, и там ООП действительно может помочь. Но тогда ООП помогает не «решать задачи», не «управлять сложностью проектов», а обкостыливать кривые языки. И это другой тезис (с которым я даже не буду спорить).
Просто, в частности, из вашего тезиса следует, что крупные проекты без ООП невозможны/тяжелы/етц (выберите модальность по вкусу), а из моего — нет.
То, что я пишу - это вполне научные методы.
Научные методы «сотни нюансов» — это на уровне научных методов «святой имени всех электриков помог».
Есть моё предположение, что возможно вы переоцениваете своё творение. Это ни разу не фантастика, а характерное когнитивное искажение разработчика.
Вполне научные данные я уже привёл в виде измеримых критериев: объём кода, процент решаемых задач, производительность, например. Вы говорите, что это всё ерунда и когнитивные искажения. Штош.
Мерить успешность в процентах ключевых слов - бред. При незаконченности обоих вариантов - тем более.
Даже C++23 (вышедший почти три года назад уже) целиком не поддерживает ни один компилятор, что не мешает писать -std=c++23 во флагах сборки, сравнивать разные компиляторы, и так далее.
Кстати, есть ещё третий вариант people forget exists. Но он вам тем более не понравится.
Там на самом деле реализовался третий вариант, и он мне на самом деле не понравился, но это уже корпоративная политика, а не тонкости языка.
Речь была про то, что "инструмент, который может отпилить пальцы - плохой инструмет". Так чтож вы плохим инструментом-то пользуетесь?
Потому что остальные ещё хуже [по совокупности доступных критериев]. Неважно, на самом деле, является ли инструмент «плохим» или «хорошим». Важно, лучше он других или хуже (для данных задач). А как вы его назовёте — это неважно, важна лишь его сравнительная позиция.
Пытаться ловить собеседника на этом, «что ж вы плохим пользуетесь» — это как раз та самая демагогия, которая вас вроде как утомила.
Неправильно. Опять демагогия. Опять манипуляции. Ненавижу этот манипулятивный приём, когда собеседник берёт мои слова и начинает искажать, гиперболизируя.
А к чему эти слова были написаны? Ваш тезис, который вы тут отстаиваете — что $smth не подходит для крупных проектов и управления сложностью. Если вы пишете какие-то тезисы и не пишете явно, что из них следует, то естественно предполагать, что вы ими подтверждаете ваш исходный тезис. Ну или напишите явно, что из них следует-то, и тогда обсудим.
Или, например, инвертируя, как было с инструментами: Отличный вывод, да? А я что, говорил, что следует?
Вы пользовались отрицаниемвашего утверждения для вывода, что критика инструментов, могущих нанести много вреда долбоёбу — плохая идея.
Шарп - статически типизированный язык. У него всё нормально с типами.
Non sequitur. C (без шарпа и плюсиков) — тоже статически типизированный язык, но утверждение «у C всё нормально с типами» — это кекспертиза уровня opennet.
Они есть, они проверяются на этапе компиляции и всевозможные чекеры работают в реалтайме, пока пишешь код.
Важно не то, что они есть, а то, какие поведения они могут запретить. Чем мощнее система типов, тем больше поведений запрещается, тем проще рассуждать о коде, глядя только на типы, и тем больше проверяет компилятор, а не ваш (или мой) величественный взор на PR-ревью.
Решена. Метод вызывается? Ошибки ловятся? Дерево обходится? Чего ещё надо?
Собрать все ошибки, если есть хоть одна, выразить семантику «либо ошибка, либо коммент», и ещё ряд пунктов по списку. Мне его сюда закопипастить?
JS — неудивительно, там же вдохновление из лиспов брали :]
Но тут вопрос не в языках, которыми пользуются ООП-программисты, а в том, что эти ООП-программисты делают. По крайней мере, в моём личном опыте я не особо много использований этих фич видел в коде на питоне или JS.
Делать выводы что компилятор не понимающий 100% - негодный правильно.
Вы делаете не этот вывод. Вы делаете вывод, что до дописывания до 100% сравнивать нельзя.
Начнём с того, что это не соответствует действительности: в компиляторах есть известные баги, компиляторы известно реализуют стандарты/спеки не до конца, и так далее, и это не мешает компиляторами пользоваться. Этот ваш cl.exe вроде как не поддерживал такую базовую штуку, как two-phase lookup, и ничего, люди его не то что сравнивали, люди им пользовались и разрабатывали работающие продукты.
Это не вопрос веры. Я сказал "возможно в варианте В были решены более сложные задачи". Где здесь вера? Это за что меня в религию записывают?
Вера в нахождении всё менее реалистичных и всё более неопровержимых причин. Неопровержимых потому, что вы не воспримете, конечно, утверждение в духе «нет, множество проходящих у них тестов было собственным подмножеством проходящих у меня тестов».
Торцовочная пила. У неё другие задачи, как видно из названия.
Мне не видно, я её для выпиливания плинтусов купил вообще и не шарю, но неважно.
Есть пересечение задач, которое может быть решено обоими видами пил. На этом пересечении эти вещи вполне можно сравнивать.
Во-первых я так не делал. Я говорил про управление сложностью. Слов "не готов" я не писал.
Окей, справедливо. Переформулирую в ваших терминах: язык C++ не позволяет управлять сложностью потому, что там компилятор жрёт много памяти и компилирует долго. Правильно, да?
Ну и с хот релоадом там тоже довольно печально (dlopen/dlclose — это не хот релоад).
А что, бывает иначе?
В некоторых плюсовых проектах — да. Там либо всё красненькое, потому что LSP отвалился, либо ничто не красненькое, потому что LSP снова отвалился, но в другую сторону.
Это не значит, что его там нет или что он хуже.
Наоборот, это значит, что с точки зрения управления сложностью (типы — они для этого) сишарп в этом аспекте хуже.
Потому что, во-первых, у меня не 10 строк обхода дерева.
Но у вас и задача до конца не решена.
Во-вторых у вас не одна строка.
В данном случае строку с типом можно вообще убрать. Воспринимайте её как комментарий.
Это просто код. Добавка «который выполнен в будущем» либо требует уточнений, либо не имеет смысла (потому что не несёт никакой дополнительной информации — абсолютно любой с код с тем же успехом может быть выполнен в будущем).
ФП это делает юзабельным.
«Классическое» ФП а-ля нетипизированный лисп — потому что обработчики можно композировать. Сишные указатели на функции, как мы с вами оба согласились, композировать нельзя.
«Современное» ФП а-ля обмазали системой типов посильнее — потому что о коде после этого легче рассуждать. И вам не нужно делать
interface ITextPredicateвместе сITextOrиITextAnd, вы можете просто написатьstring → bool.Я и множествами не мыслю. Мыслю максимум типами, но почти синтаксически, точно так же, как работает proof finding в некоторых языках: условно, если у меня есть функция типа a → b и другая функция типа b → c, а мне надо a → c, то очевидно, как их совместить. Даже думать не надо, ни о морфизмах, ни о категориях, ни о множествах.
В моём — любой терм, тип которого имеет стрелочку первым конструктором типов. Ну, короче, что-то вида a → b.
Кому проще и почему?
Вы там дальше про ASP.NET пишете, но у меня с ним ровно ноль опыта. В моём же опыте это оправдано тогда, когда одна и та же последовательность действий повторяется часто. Правда, тогда весь хардкод сводится к
Да. Это почти
std::accumulate(только последний принимает пару итераторов вместо одного рейнджа, аstd::ranges::accumulateпочему-то не сделали, но для дискуссии это несущественно).А вот это косвенно мой вам вопрос :]
Есть философия, что надо пользоваться стдлибкой по максимуму. Если вы придёте на конференцию по плюсам или почитаете модный блог, то там вам расскажут про
std::for_each,std::accumulate,std::inner_productкакой-нибудь, и так далее, и скажут, что их надо предпочитать голым циклам (потому что они делают код выразительнее, интент — понятнее, реализацию — безопаснее, и так далее).А есть философия, конечно, что это всё бесовское.
Вы читаете код. Оба варианта уже написаны.
Так про них-то и речь. Концепт один и тот же: сделать из двух действий третье. Просто в классическом ООП реализация такая, что за деревьями теряется лес.
Не обязательно набора. Там и один метод выносится, и этот метод обзывается «точкой конфигурации» или чем-то таким. Только смысл у него простой: он, собсна, выражает действие.
Я ни разу не мыслил малыми категориями и морфизмами, и ими там мыслить совершенно не нужно.
Я мыслю операциями «применить к каждому узлу дерева такую-то функцию и собрать результаты в новое дерево» (это
traverse), а затем, если надо, «собрать все эффекты из узлов нового дерева» (этоsequence). Никакого теорката, ничего.Тогда вам тот же вопрос, что и исходному товарищу. Что лучше,
или
?
А, сорян, я думал, есть какие-то конкретные предложения. Пока что это всё выглядит как «как здорово было бы всем собраться и быть лучше среднего».
Тезис «я ща вас побежду на вашем же поле» очень резко превратился сначала в продолжительное уточнение вопроса, кульминировавшее в на порядок большем количестве кода, вопрос не решающем, а потом в «да это всё игрушечные задачи и не нужно, и важны только 100%-о работающие компиляторы, только если это не компиляторы имеющихся языков».
На разных языках, да.
Оооох броо, у меня есть новости!
Proposed Initiative Enters Circulation Requires Future Vote on Whether California Should Become Independent Country. Initiative Statute
California, the most populous state in the United States and third largest in area after Alaska and Texas, has been the subject of more than 220 proposals to divide it into multiple states since its admission to the Union in 1850,[1] including at least 27 significant proposals prior to the 21st century.[2] In addition, there have been some calls for the secession of multiple states or large regions in the American West (such as the proposal of Cascadia) which often include parts of Northern California.[3]
Лично знаком с людьми, имеющими аналогичные идеи в Аляске, Вермонте и NH, и там поддержка, конечно, не большинства, но и ненулевая.
Почему? Не считаю это инфантильными бреднями. Техас отдаёт федералам больше денег, чем получает от них, у Техаса достаточно ресурсов для энергонезависимости, да и для военной независимости тоже, ЕВПОЧЯ.
И единым у этого конгломерата была только армия и отсутствие экономических барьеров. Внутренняя политика каждого из штатов могла быть произвольной.
National divorce? Не, не слышали.
Какие конкретно действия для этого надо совершать, кому именно, и зачем им это?
С какими правилами? Ближе к КНР? Ближе к РФ? Ближе к США? Ближе к вашим конкретным фантазиям, потому что вы определённо хотите добра всем во всём мире, поэтому ваши фантазии к нему приведут, и поэтому же они и сбудутся?
На базе христианства, например. Ну вот просто большинством голосов. Готовы к полному запрету абортов?
Для маленькой симуляции объединения и стандартизации предлагаю вам остаться до конца жизни в РФ (вы ж до сих пор не уехали, верно?) и выгибаться буквой зю, но соответствовать её моральным принципам. Вместо РФ можете выбрать любую другую страну, где одобрямс моральных принципов зашкаливает за 86%, а оппозиции нет, потому что как же можно оппонировать такому мудрому и стандартизированному правительству.
Почему же вам не хочется? Может, потому, что нихрена моральные принципы на самом деле не стандартизовались, и пригодность страны для жизни коррелирует с (по крайней мере) историческим плюрализмом мнений в ней?
И, может, потому, что конкуренция между государствами хотя бы минимально заставляет их работать на благо населения — а то шарящее население уедет куда-то ещё, и государство кончится?
«Конец истории» оказался несколько преждевременным, как показывает практика.
Это если победят все правильные идеи, а все неправильные идеи не победят. Правда, тут есть один нюанс: почти любой носитель почти любой идеи искренне считает именно свою идею правильной, а остальные — ересью.
Неочевидно.
Территориальные претензии как раз давно кончились, кроме пары маленьких, но гордых исключений, но не будем вскрывать эту тему. Остаются претензии к ресурсам (и это вполне возможно и в рамках одного мегагосударства, потому что ресурсы — они для моей клики или вашей клики, которые исторически ассоциируются с нацгосударствами), и так далее.
Физиологически гетерогаметному полу обычно хуже. Следовательно, мужчины должны выходить на пенсию раньше и иметь приоритетное обслуживание в медицинских учреждениях.
— Могу ли я написать функцию?
— Да. Только не функцию.
Гм.
Ладно. Функции вычёркиваем.
Ура, мы пришли к тому, о чём я говорил изначально: создаёте объект.
Кажется, умные люди в умных ООП-книгах называют это «стратегией» (вернее, частным случаем), и, кажется, я ровно такой пример видел в одной из них (но напрочь не помню, в какой). Там, правда, развешивалась целая иерархия в духе
вместо простого
(которое полиморфно и работает для любых функций, покуда типы подходят, и которое, тем более, во всех известных мне ФП-языках встроено в стандартную либу языка и пишется, скажем, просто как
.), но это ведь то же самое и почти так же легко, поэтому программисты не будут лениться и избегать этим пользоваться, не так ли?Можно в лямбду по значению захватывать, но да.
Про это я тоже писал: моя реализация давала более производительный код (и ещё имела зачатки статического анализа, лол).
Если они будут поддерживать не 90, а меньше, и выплёвываемый ими код будет работать медленнее, то вполне себе корректно.
Не понял, что это за «эргодичность» такая? В одном случае компилируется 90% программ, в другом — 40%. Это не то же самое.
Вот здесь мы и несогласны, и весь тред выше — моя попытка пояснить примерами, за счёт чего именно.
И в 10 раз тоже.
Давно определился: в первой (моей цитате речь не о сложности, а во второй (вашей) — о сложности.
Во-первых, мне ни разу не нужно было распилить плинтуса вдоль. Я их пилил только поперёк, и эту задачу могут решить и циркулярка, и торцовочная, и даже лобзик. Эта задача на пересечении.
Во-вторыю, циркулярка не может пилить доски вдоль сама по себе, потому что вам нужна обвязка, чтобы доску зафиксировать, например. Здесь есть тоже кое-какие параллели с этими нашими ЯП, но не будем об этом.
Потому что что-то там про сложность и мощность.
Управление сложностью что-то очень резко сдулось, сразу после ФП в шарпе.
Так я-то и не требую. Я констатирую факт, что у шарпа меньше средств выражения семантики композируемым и проверяемым компилятором образом, чем у хаскеля (а у хаскеля меньше, чем у идриса, например).
Предположим, я вам дам ссылку на, скажем, интерпретатор языка смарт-контрактов для одного из блокчейнов, куда я контрибьютил. Дальше что? Пойдёте переписывать его на сишарпе, чтобы сравнить сложность?
Должен ли житель глубоко южного штата, где снег идёт раз в год, сдавать такие же нормативы на вождение зимой/по льду, как житель глубоко северного штата?
Какие должны быть стандарты для сильно rural-штата, где 90% людей вне крупных городов, и как они отличаются от стандартов для «городских» штатов? Это не только вождение в городских условиях, это и послабление стандартов для того, чтобы люди могли куда-то добраться и быть продуктивными членами экономики.
В некоторых штатах можно делать right on red, в некоторых — нет, в некоторых — если подождать. Как унифицировать и почему?
Дальше чисто политически-философские вопросы: исторически федеративная система Штатов даёт очень много власти в руки отдельных, собсна, штатов, и федералам оставляет только регуляцию взаимодействий между штатами. Подобная децентрализация — это одна из тех самых мэдисоновских сдержек против централизации власти и следующей за ней тирании. Обсуждать в этом контексте права, конечно, смешно, но, во-первых, это смешно до первой отмены прав при голосовании не за того президента или выхода на протесты против результатов голосования, а, во-вторых, централизация одних аспектов власти в глазах общества легитимизирует централизацию других аспектов, где может быть ещё менее смешно.
Поэтому не, не соглашусь с вами.
Надеюсь, что нет, потому что, если вкратце, конкуренция юрисдикций, правовых систем и законов — это тоже хорошо.
Вам будет очень тяжело найти более прооружейного человека, чем я, но я против carry reciprocity, например.
При этом я по правам одного штата вполне могу ездить в (и, тем более, проезжать через) другой штат. Есть требования сдать старые права и получить права/ID нового штата (если старые права есть), если вы становитесь резидентом нового штата, но это требование тяжело энфорсить, особенно в граничных случаях.
И да, обмен прав на новые не требует сдавать экзамен по нормативам целевого штата (насколько я знаю, но IANAL). Учитывая, что в разных штатах могут быть очень разные требования, это получается забавно.
Олсо, тем временем поговаривают не только о правах, но и об universal carry reciprocity.
«расскажи, зачем снимаешь деньги со своего счёта и как их потратишь»
Или там,
(ведь наказывать преступников, или там вообще самооборона — это не либерально-просвещённая идея)
Много там приколов.
теперь?
Я готов обсуждать эту проблему. Давайте?
Они одинаковые мешки с костями (плюс-минус), это да. Но у них разная фирмварь, сформировавшаяся под влияниием культуры и условий что рождения, что даже немножко жизни матери.
Поэтому если чувак родился в Судане… хотя не, про Судан не знаю, так вот, если чувак родился, скажем, в Пакистане, а не в США или Европе, то куда больше вероятность, что в его культуре и парадигме отношений с обществом будут понятия кровной мести, скажем, а понятий толерантности (в классическом смысле) — не будет.
И поэтому это, например, выливается в очень прикольные графики о том, какие люди из какой страны рождения где-то там совершают сколько изнасилований.
И поэтому, например, мне было бы очень интересно послушать, почему я должен предпочитать наличие «беженцев» в своём месте жительства его отсутствию, или почему я должен предпочитать суданцев, сомалийцев и пакистанцев, скажем, белым африканерам, бегущим от геноцида.
Готовы обсуждать, или не?
Этого недостаточно.
Я могу написать функцию, принимающую два инта и возвращающую третий (их сумму). Могу ли я написать функцию, принимающую два указателя на функцию и возвращающую третий, указывающий, скажем, их композицию?
Олсо, для протокола: C++ — мультипарадигменный язык, поэтому для обсуждения «в ООП принято» лучше читать книжки по ООП, а не языки, которые среди прочего поддерживают ООП (но это неточно).
Например? Можно конкретнее?
На что вы ответили, что либо 100%, либо не считается. Так вот, компилятор плюсов (любой) не обрабатывает 100% исходников, соответствующих стандарту, так, как того требует стандарт. В чём разница?
Чтобы сказать, например, что «есть сотни нюансов».
Нет. Я утверждал, что судить о сложности проекта по количеству строк — бред, потому что разные языки обладают разной выразительной силой, и если две программы решают одну и ту же задачу, то они имеют одинаковую внутреннюю (которая intrinsic) сложность.
Да, проект на 50к строк (решающий то же, что проект на 5к строк) может иметь большую «добавленную» сложность из-за языка, и там ООП действительно может помочь. Но тогда ООП помогает не «решать задачи», не «управлять сложностью проектов», а обкостыливать кривые языки. И это другой тезис (с которым я даже не буду спорить).
Просто, в частности, из вашего тезиса следует, что крупные проекты без ООП невозможны/тяжелы/етц (выберите модальность по вкусу), а из моего — нет.
Научные методы «сотни нюансов» — это на уровне научных методов «святой имени всех электриков помог».
Вполне научные данные я уже привёл в виде измеримых критериев: объём кода, процент решаемых задач, производительность, например. Вы говорите, что это всё ерунда и когнитивные искажения. Штош.
ХЗ, тут вот измеряют, и на эту страницу даже часто ссылаются, хотя там видно, что никто ничего до конца не поддерживает: https://en.cppreference.com/w/cpp/compiler_support.html
Даже C++23 (вышедший почти три года назад уже) целиком не поддерживает ни один компилятор, что не мешает писать
-std=c++23во флагах сборки, сравнивать разные компиляторы, и так далее.Там на самом деле реализовался третий вариант, и он мне на самом деле не понравился, но это уже корпоративная политика, а не тонкости языка.
Потому что остальные ещё хуже [по совокупности доступных критериев]. Неважно, на самом деле, является ли инструмент «плохим» или «хорошим». Важно, лучше он других или хуже (для данных задач). А как вы его назовёте — это неважно, важна лишь его сравнительная позиция.
Пытаться ловить собеседника на этом, «что ж вы плохим пользуетесь» — это как раз та самая демагогия, которая вас вроде как утомила.
А к чему эти слова были написаны? Ваш тезис, который вы тут отстаиваете — что $smth не подходит для крупных проектов и управления сложностью. Если вы пишете какие-то тезисы и не пишете явно, что из них следует, то естественно предполагать, что вы ими подтверждаете ваш исходный тезис. Ну или напишите явно, что из них следует-то, и тогда обсудим.
Вы пользовались отрицанием вашего утверждения для вывода, что критика инструментов, могущих нанести много вреда долбоёбу — плохая идея.
Non sequitur. C (без шарпа и плюсиков) — тоже статически типизированный язык, но утверждение «у C всё нормально с типами» — это кекспертиза уровня opennet.
Важно не то, что они есть, а то, какие поведения они могут запретить. Чем мощнее система типов, тем больше поведений запрещается, тем проще рассуждать о коде, глядя только на типы, и тем больше проверяет компилятор, а не ваш (или мой) величественный взор на PR-ревью.
Собрать все ошибки, если есть хоть одна, выразить семантику «либо ошибка, либо коммент», и ещё ряд пунктов по списку. Мне его сюда закопипастить?
JS — неудивительно, там же вдохновление из лиспов брали :]
Но тут вопрос не в языках, которыми пользуются ООП-программисты, а в том, что эти ООП-программисты делают. По крайней мере, в моём личном опыте я не особо много использований этих фич видел в коде на питоне или JS.
Вы делаете не этот вывод. Вы делаете вывод, что до дописывания до 100% сравнивать нельзя.
Начнём с того, что это не соответствует действительности: в компиляторах есть известные баги, компиляторы известно реализуют стандарты/спеки не до конца, и так далее, и это не мешает компиляторами пользоваться. Этот ваш cl.exe вроде как не поддерживал такую базовую штуку, как two-phase lookup, и ничего, люди его не то что сравнивали, люди им пользовались и разрабатывали работающие продукты.
Вера в нахождении всё менее реалистичных и всё более неопровержимых причин. Неопровержимых потому, что вы не воспримете, конечно, утверждение в духе «нет, множество проходящих у них тестов было собственным подмножеством проходящих у меня тестов».
Мне не видно, я её для выпиливания плинтусов купил вообще и не шарю, но неважно.
Есть пересечение задач, которое может быть решено обоими видами пил. На этом пересечении эти вещи вполне можно сравнивать.
Окей, справедливо. Переформулирую в ваших терминах: язык C++ не позволяет управлять сложностью потому, что там компилятор жрёт много памяти и компилирует долго. Правильно, да?
Ну и с хот релоадом там тоже довольно печально (dlopen/dlclose — это не хот релоад).
В некоторых плюсовых проектах — да. Там либо всё красненькое, потому что LSP отвалился, либо ничто не красненькое, потому что LSP снова отвалился, но в другую сторону.
Наоборот, это значит, что с точки зрения управления сложностью (типы — они для этого) сишарп в этом аспекте хуже.
Но у вас и задача до конца не решена.
В данном случае строку с типом можно вообще убрать. Воспринимайте её как комментарий.