- иммутабельность
- функциональщина
- кодогенерация
- "всё есть объект"
- слабая типизация
- доступ к AST
Самомодифицирующийся код. Базарю, вынесет твой мозг.
Прыжки на батуте например
https://en.wikipedia.org/wiki/Trampoline_(computing)
В PLT самая годнота - системы переписывания в конкатенативных вариантах.
Основатели информатики дали вам самое ценное - линейно-адресуемый RAM с доступом за константное время. Круче только квантовые вычисления.
Свёртки. Каскадное кэширование. Мемоизация. Автоматное кодирование.
А впрочем, всё меркнет на фоне теории графов.
Зависимые типы
Пруфы будут? Можно подумать ты знаешь как устроены рантаймы таких языков. Ты просто выдумал байку. Имутабельные структуры можно прикрутить и к JS, и это никак не повлияет на потребление памяти. Чтобы рассуждать о таких темах, нужно в этом шарить. Ты не шаришь. Поэтому займись чем-то по-легче.
Подписался, схоронил
https://arhivach.ng/thread/536289/
Мимовкатывальщик
Логическое программирование, а именно Пролог:
- Bi-directional data. Предикат atom_chars(foo,Chars) даст Chars = [f,o,o], а atom_chars(Atom,[f,o,o]) даст Atom = foo.
- Жесткое мета-программирование. Программа на прологе может анализировать сама себя, перестраивать, модифицировать. Запилить систему типов поверх пролога? Как делать нехуй. Небольшой синтаксический сахар? Самое простое, что можно сделать в прологе.
- Мета-предикаты.
- Все есть данные и унификация(паттернметчинг). Термы можно рассматривать как quote в лиспе. Т.е предикат в прологе не редуцируются. writeln(5+5) напишет в sdout 5+5. В прологе ты полностью контролируешь процесс вычислений.
> Y-комбинатора
Какая-же бесполезная хуйня, хоть и забавная.
Можно ли написать Y-комбинатор на языке со строгой статической типизацией, без всяких оберток в object'ы?
Какое-то говно из под коня.
Это то что есть в любом нормальном языке типа С из коробки. Любой программист впитывает это на первых занятиях.
Только яйцеголовым ученым пришло в голову писать десятки заумных страниц на эту тему. Сами себе придумывают трудности чтобы потом героически их преодолевать.
https://pastebin.com/XiiF7A9B
Ну тут я начинал писать факториал по какому-то туториалу для JS, но когда понял, как это работает, дописывать не стал, так что не уверен, что будет особо полезно.
введение искуственных ограничений без получения какоголибо профита с етого.
надежды возложеные на "ленивое программирование" и "автоматическое распаралеливание" не оправдлаись.
человек делает ето намного лучше чем машина.
Дебилушка, естественно его профит в языках без каррирования и ленивости по-умолчанию, а так ж поддержки пойнтфри и прочих средств функциональной/комбинаторной композиции никак не ощущается. В своей императивной параше можешь как Духаст Вечаславыч на лабах учил писать while true.
Польза Y комбинатора на практике точно такая же если ты начнешь каждую "лямбда функцию" переписывать в лямбду калькулус
Все же знают что монада это вантуз запихивающий значение туда куда оно не пролезает.
Поражает тупость местной студентоты, которая ничего кроме императивной дрисни не видела, а поэтому не понимает назначения всех этих абстракций, и по быдло-логике считает их ненужными, так как они никак не помогают выгрузить вооон тот отчёт для Марьи Ивановны и заработать на жрат.
Может хотя бы пояснишь нахуй они нужны, чтобы их изобретать?
Ну вот например лисп-машины. Но они
>ушли с рынка
потому что
>а определённом этапе экспоненциального роста вычислительной мощности (закон Мура) аппаратная поддержка лямбда-исчисления утратила экономический смысл для компьютеров широкого потребления
Иными словами "нахуя мне аппаратная поддержка лямбда-исчисления, если мой компьютер достаточно быстр, чтобы с лёгкостью переваривать её программную реализацию?"
Поэтому лисп-машин нет, а лисп есть.
мимо
Вышеупомянутые тупо енумы в С не называют монадами (на уровне языка) из-за общепринятых реализаций монад в ФЯП
Ну раз нет аппаратной поддержки модулей и объектов, значит модульное и ОО-программирование не нужно, так что-ли?
Ты совсем ебобо, не видишь разницы между кодом, его абстрактным исполнителем и реализацией этого исполнителя?
Очевидно, для построения систем сложнее laba1, которое неизбежно требует вовлечения различных абстракций, процедурный байтопердолинг не подходит.
Эквивалентность машины Тьюринга и лямбда исчисления показывает, что нет принципиальной невозможности перевести лямбда-код в императивный код.
То что императивные исполнители на данный момент быстрее остальных, для нормальных людей причина писать оптимизирующийся компиляторы из языка для людей в байтоговно, для долбоебов - повод ничего не делать и продолжать жрать говно большой ложкой.
>ОО-программирование не нужно
Тащемта да.
>Очевидно, для построения систем сложнее laba1, которое неизбежно требует вовлечения различных абстракций, процедурный байтопердолинг не подходит.
Расскажи это авторам Линукса.
>То что императивные исполнители на данный момент быстрее остальных
Означает что они всегда будут быстрее остальных.
https://en.m.wikipedia.org/wiki/Lisp_machine
Более того, можно спокойно написать эмулятор x86 на лямбда исчислении.
>Расскажи это авторам Линукса.
Причем тут Линукс, долбоеб? Там императивный код, который пердолит императивные микросхемы, он и должен таким быть, это тупо эффективнее и быстрее в этом случае. А вот когда ты переходишь на другой уровень абстракции, то там уже императивная пораша начинает сосать с проглотом. Тебе уже написали, что функциональное программирование - это абстракция, компилятор оттранслирует это в эффективную императивную дрисню.
>Расскажи это авторам Линукса.
Долбоеб, у них там своя реализация ООП и других абстракций, про которые процессор знать не знает, и которые транслируются в машинную дрисню как и в любом языке.
Как я понимаю, чтобы сформулировать комбинатор неподвижной точки, тебе нужно выбрать хотя бы одно из этого списка:
- рекурсивные функции (изи, Y f = f (Y f))
- рекурсивные типы (самоприменение внутри тела комбинатора)
- нарушение типобезопасности (nuff said)
Если ты хочешь построить комбинатор неподвижной точки в simply-typed lambda calculus (i.e. нет рекурсии ни термов, ни типов), то это невозможно
Я как-то пытался переписать свой пет-проект в строгой функциональной манере на шарпе через повсеместные readonly struct. По началу даже код казался более красивым и лаконичным. Но в итоге получался чудовищный уродливый нечитаемый даже автором кривой монстр на костылях. Но возможно я просто тупой.
> do-нотации
(не нужны)
https://wiki.haskell.org/Do_notation_considered_harmful
function add(str, strArr ){
for (let i = 0; strArr.length > i; ++i) {
str + strArr;
}
return str;
}
В императивном языке у нас всего 2 переменных и 1 массив
Тем временем в функциональном не дорозумении:
add str strArr = if null strArr then str else add (str ++ head strArr) tail strAdd
У нас пропадает перменная счетчик но теперь вместо всего одного массива и 1 переменной у нас на каждый шаг свой массив и своя строка т.е. вместо 2 переменных и 1 массива у нас N переменных и N массивов (представьте если у нас массив из 1000 элементов вместо 1 счетчика 1 строки и 1 массива у нас тупо 1000 строк и 1000 массивов)
Думаю комментарии функцианальных макак излишни
действительно, если нормально написать, то не существует.
код из >>1620216 работает в ограниченной памяти (хоть и с бОльшим трафиком) для входных данных любого размера, в отличие от императивного накопления в переменной.
пикрелейтед - запуск на бесконечном списке строк.
если исполнение не прервать - будет бесконечно выводить "pr ", ограничившись несколькими МБ ОЗУ
Долбоёб, тебе уже сказали, все абстракции конвертируются в машкод, нет никакой разницы между оопешными объектами, HOFами, прологовской резолюцией и прочими другими человеческими абстракциями в этом смысле.
>на неестветсвенны
Неестественных для кого?
>но все это конвертируется все равно в императивность
И что? Это как то должно помешать писать не императивно?
Так пиши сразу на машкодах, хули ты какие-то высокоуровневые пользовательские процедуры вызываешь, в конце же всё в машкод превратиться.
Да и в рот их ебать.
Код пишется и читается людьми для обслуживания человеческих потребностей.
Главное чтобы: 1) кода было мало, писать его можно было быстро, читать и поддерживать легко, он был надёжный 2) оно не тормозило.
Первая задача решается развитием языков и исследованиями в этих направлениях, вторая - развитием компиляторов и железа.
В некоторых случаях есть дополнительные задачи, типа чтоб отрабатывало за точное время, потребляло точное количество ресурсов, тут к сожалению без говноедства до конца обойтись, но в целом прогресс тоже есть.
Машина должна и будет служить людям, она не шлюха, чтобы люди исполняли её прихоти. Отсюда байтобляди (а так же сочувствующие им императивные пидорасы, надрачивающие на показатели System.currentTimeMillis() - start) - пиздолисы, которые опускаются до полного говноедства, лишь бы ублажить её регистры и микросхемы. Альфапрограммисты, как и положено альфам, если машина не выполняет положенных ей задач и требует пресмыкаться перед ней и ублажать её байтами, просто берут и за патчкорды, ебашат с вертушки по передней панели и списывают машину на мороз, купив взамен ту, которая не будет выёбываться и выполнит код в сроки и без выебонов, будь там хоть 1000% неоптимизированного оверхеда. И настоящего программиста не волнуют вопросы выдрачивания и быстродействия - он решает важную задачу из предметной области гораздо более сложной, чем низкоуровневое дрочево, и отвлекаться на всякую подзалупную хуету вроде осоьбеннойстей какой-то там архитектуры ему некомильфо.
Чел, ты реально троллишь тупостью. Переменные - это оверхед в 1-2 инструкцию. Ооп - в пару косвенных переходов.
Но главное что при этом не отнимаются возможности мутабельных регистров/переменных. А твои бесконечные рекурсии и создания новых объектов на каждый чих - в десятки раз тормознее.
> кода было мало, писать его можно было быстро, читать и поддерживать легко, он был надёжный
Хорошо что обычный
while(true) { cout << "pr "; } этому удовлетворяет лучше чем
add str strArr = if null strArr then str else add cad cdr fmap (str ++ head strArr) tail strAdd
>Нет в каждой итерации перезаписывается ячейка со строкой
А строка это массив байтов, который какбэ нельзя просто так брать и увеличивать.
Либо создаётся новый объект "строка" и на него начинает указывать имя переменной (ну прямо как в функциональной помойке) а старый попадает под сборщик мусора, либо строка изначально является связным списком, что тоже в плане быстродействия фейл из десяти.
>В функциальной помойке будет вызываться рекурсия по значению с новыми переменными на каждый вызов функции
Которая будучи хвостовой, имеет порядок роста памяти O(1)
Как это, так в треде уже почти 200 постов, а так никто и не приплёл самую ахуенную архитектуру для разработки iOS приложений...
Ага, по фанчику запилить сырое MWP говно, в лучшем случае потом сплавить его кому-то на поддержку, потому что суппорт подразумевает тесты, фикс багов, покрытие эдж-кейсов, профилирование и устранение боттленков, рефакторинг, а это всё очень скучная инженерная РАБота, которая тру-визионеров стартапщиков не интересует.
Но это скорее исключение. Как правило никакого суппорта не будет, и всё закончиться просто проёбом инвесторских бабок, как обычно и go next. Лёгкость бытия.
> то и смысла в неимперативных языках нет.
Давай сразу на машинном коде писать, хули нет? Естественно, блядь, под любым декларативным кодом лежит императивный, так же как под асинхронным всегда находится синхронный код. Вот только толку от этой лапши из if'ов и for'ов, когда можно писать человекочитаемый высокоуровневый код?
>маняфункции f(f(f(f(f(f))))
если на уровне организации, то это тебя просто форсирует вычислять новое состояние только исходя из предыдущего.. обычная дисциплина, типа, не менять вручную инекс в форе и проч.
но так ты же ещё можешь использовать боголисп, где открыты просто любые возможности: хоть функциональщиной обмазывайся, хоть состояние нежно тереби.
На этот ответ уже поступило возражение, что дескать вкусовщина из десяти, раз уж отходить от концепции машинного кода, то нет принципиальной разницы в какую именно сторону. Если одному удобно мыслить императивно, это не значит, что другому не может быть удобно мыслить функционально или объектно.
То, что компьютер работает императивно, совершенно никого кроме ассемблероёбов не интересует и аргументом служить не может, мы на другом уровне абстракции а абстракция на то и абстракция, чтобы скрывать детали нижележащего слоя, а ты этот слои пытаешься намазать на вышележащий и продавить это намазывание как аргумент.
> раз уж отходить от концепции машинного кода, то нет принципиальной разницы в какую именно сторону.
Есть принципиальная разница. Надстройки над императивщиной добавляют мало оверхеда, а маняфункции - много. Потому что натягивается совершенно другая парадигма, которая запрещает пользоваться тем, что есть (мутабельные регистры процессора, последовательное выполнение инструкций, сайд эффекты).
>Если одному удобно мыслить императивно, это не значит, что другому не может быть удобно мыслить функционально
Это вообще лесом, речь идет об устройстве выполнения (процессорах)
>То, что компьютер работает императивно, совершенно никого кроме ассемблероёбов не интересует и аргументом служить не может
А, ну раз ты скозал.
> Надстройки над императивщиной добавляют мало оверхеда, а маняфункции - много.
Во-первых это спорное утверждение, т.к. та же оптимизация хвостовой рекурсии позволяет писать КАК УДОБНО но с нулевым добавленным оверхедом в рантайме (на компиляции может быть какой-то добавленный оверхед есть, но не в рантайме), т.е. порядок роста твоей f(f(f(x))) по памяти будет O(1), а не O(n) как при отсутствии такой оптимизации.
Во-вторых сейчас не семидесятые и можно гонять хоть килотонны неоптимизированного оверхеда и всем похуй - купить сервак помощнее выгоднее, чем нанять ещё троих сишников маэстро оптимизации.
>речь идет об устройстве выполнения
Устройству выполнения совершенно насрать. Поэтому и лисп-машины вымерли.
>А, ну раз ты скозал.
Я и рынок спроса на труд программистов.
Совершенно верно. Абстракции для того и предназначены, чтобы упрощать понимание и взаимодействие с необходимым уровнем. Есть барьеры абстракций, которые помогают склеивать уровни, и совершенно неважно что есть на нижнем уровне, когда ты работаешь поверх. Есть авто, а есть двигатель авто, это отдельная абстракция, и совершенно неважно какое авто, потому как двигатель существует отдельно. Точно также в двигателе существуют отдельно другие абстракции, как например поршневая система. И так далее...
Ну я так и понял, что это какой-то закон про пидоров и для пидоров.
По делу - пока машина твоя заводится тебе нет дела до того чё там внутри, это факт, то же самое касается работы компа мне поебать абсолютно как там внизу работает мой софт пока он не багует а будет баговать буду разбираться и в этом мне поможет чистый и кристально прозрачный код с уровнями абстракций а не с навалом ассемблерной лапши.
Машина должна и будет служить людям, она не шлюха, чтобы люди исполняли её прихоти. Отсюда байтобляди (а так же сочувствующие им императивные пидорасы, надрачивающие на показатели System.currentTimeMillis() - start) - пиздолисы, которые опускаются до полного говноедства, лишь бы ублажить её регистры и микросхемы. Альфапрограммисты, как и положено альфам, если машина не выполняет положенных ей задач и требует пресмыкаться перед ней и ублажать её байтами, просто берут и за патчкорды, ебашат с вертушки по передней панели и списывают машину на мороз, купив взамен ту, которая не будет выёбываться и выполнит код в сроки и без выебонов, будь там хоть 1000% неоптимизированного оверхеда. И настоящего программиста не волнуют вопросы выдрачивания и быстродействия - он решает важную задачу из предметной области гораздо более сложной, чем низкоуровневое дрочево, и отвлекаться на всякую подзалупную хуету вроде осоьбеннойстей какой-то там архитектуры ему некомильфо.
На практике в реальных приложениях, кроме некоторых особо гнилых отраслей, мест, требующих оптимизации не больше 10%, из них лишь мизерная часть требует низкоуровневых изъёбов.
Напоминаю, что оптимизация делает код сложнее в сопровождении, а лоулевел петушение ещё и повышает вероятность возникновения в них ебейших багов, как известно по печальным поделиям байтоблядей.
Машина должна служить людям, поэтому байтоебы командуют машине как ей себя вести, конкретно, а борщехлебы борются с хвостовыми рекурсиями и уговаривают пролог хоть как то ограничть перебор всего до тепловой смерти вселенной. Байтоебы приказывают имеющимся машинам, а борщехлебы копят с завтраков на более мощную машину, потому что на этой у них ничего не запустится.
>>1623845
Рынок показал что одинаково не нужны ни те ни те, но все же все макакинское говно работает поверх железа и систем созданными байтоебами. Браузеры, ос, сетевые стеки, сервера - все на сишке.
Пролог - это говно, где в какой то момент вместо решения задачи приходится бороться с системой. Но поскольку пролог представляет собой сорт оф черный ящик, нормальными командами указать ты ему это не сможешь, надо писать страницы кода чтобы убедить его сделать cut
Нюфаня, не слышавший про CGI?
Алсо бекенд http://cppcms.com/wikipp/en/page/main
Фронтенд на imgui через emscripten и вперед.
>пролог хоть как то ограничть перебор всего до тепловой смерти вселенной.
Пролог так то имеет императивную составляющую и позволяет отсечениями ограничить перебор. Говнарская хуйня, кстати. То ли дело Mercury с чисто декларативной системой модов для предикатов, которая высокоуровнее (как и весь язык), а работает намного быстрее.
Но дело даже не в этом. Игра "Жизнь" на прологе описывается знаешь во сколько строк? Меньше 100 LOC с комментариями. А теперь то же самое сделай на асме своём любимом, говнарик. То-то же.
Борщехлёбы, угомонитесь уже. На языках, в которые сложности добавляют ради самих сложностей, называя это математической красотой, никто никогда всерьёз писать не будет.
Имей совесть на асме 42 байта, 80 строк
http://olivier.poudade.free.fr/src/life42.asm
>но все же все макакинское говно работает поверх железа и систем созданными байтоебами. Браузеры, ос, сетевые стеки, сервера - все на сишке
С этим никто не спорил, и это никого не ебёт. Не примазывайся к славе тех байтоёбов, что пишут "браузеры, ос, сетевые стеки, сервера" - лучше заслужи её.
Абстракции нужны для людей.
Для выебанных в мозг операционной семантикой, аппликативным порядком и прочими прелестями процедурного пердолинга инвалидов, императивный стиль, наверное, больше подходит. Правда это не точно, ведь большинство из них ничего другого и не видели.
Пролог это просто способ решать задачу. Некий язык, который позволяет рассуждать о вычислениях, об алгоритмах, а не об устройстве какого то примитивного вычислителя. Его компилятор/интерпретатор берет на себя все сопутствующие проблемы, которые выплывают при использовании примитивных императивных языков. Его уровень абстракции находится в плоскости решения алгоритмических задач, а не в плоскости борьбы с императивным наследием ЭВМ. Зачем нужен язык программирования, если его уровень абстракции это противостояние несовершенству архитектуры компьютера? Может лучше написать такой умный транслятор, который будет давать такой уровень абстракции, который позволит не думать об архитектуре ЭВМ, а позволит решать таки алгоритмические задачи, которые позволят писать софт для людей. Нет необходимости говорить с компьютером на языке его архитектуры. Это неудобно для человека. Цель программирования, заставить компьютер общаться с человеком на удобном для человека языке. Для этого придумали удобные языки, как тот же Пролог, а заботу об взаимодействии Пролога с компьютером переложили на его транслятор.
Нормальный человек: пишет свой язык и оптимизирующий компилятор, который превратит удобные для него абстракции в процедурную байтодрисню. Или берёт готовые, в зависимости от задачи и на свой вкус.
Байтоговнарик: пишет процедурную байтодрисню руками, жутко гордиться этим, отрицает прогресс, стреляет себе в ногу, нажирается дешёвой водкой, позерски ноет о тяжести нищебросдкой жизни.
>Игра "Жизнь" на прологе описывается знаешь во сколько строк? Меньше 100 LOC с комментариями.
В том то и дело. Пролог может выглядеть странным, но он дает тот уровень абстракции, который позволяет не просто байты перекладывать, а решать реально сложные алгоритмические задачи, затрачивая на это минимум усилий.
Потому что они - адекватные уравновешенные люди (не шизики), прекрасно осведомлённые о недостатках языков, на которых пишут и понимающие, почему именно эти языки пригодны для именно их задач (а не для всех возможных задач), и реально работающие в этих отраслях.
Давай разберемся. Человеку нужен удобный язык, который позволяет решать задачу с минимальными усилиями. Не думать ни о чем кроме самой задачи. Все остальное за него решают компиляторы/интерпретаторы, фреймворки/библиотеки, etc. Это будет язык максимально приближенный к предметной области. Зачем человеку решающему сложную вычислительную задачу думать об архитектуре процессора, или о других не важных для решения его задачи вещах? Вопрос риторический. Человек хочет командовать компьютером, его укрощать. Пускай все проблемы несовершенства ЭВМ решают программы на нужном уровне абстракции. Например, компилятор Хаскела позволяет писать ленивый код, преобразуя его в подходящий код для процессора. Грубо говоря, можно написать такой интерпретатор, который будет преобразовывать любой самый абсурдный код с точки зрения процессора, в удобный для этого процессора вид. Программисту останется только освоить это язык, и больше не задумываться о том как устроен компьютер на низком уровне. За него будет думать компилятор/интерпретатор.
Чё ещё расскажешь?
Двачую, байтоёбы рабы во всём - рабы машины. рабы предубеждений, рабы производительности, рабы стереотипов, рабы обрабатываемых штеудом х86 типов данных - для них всё, что не кратно 2 байтам и больше 16 байт не может быть примитивным типом, хотя число - это просто число, оно может быть целым, дробным, рациональным, комплексным, но не "в 2 байта в 4 байта в 8 байт". Да, байтобляди были актуальны пару-тройку десятков лет назад, когда кроме этого пресловутого отлизывания регистров и микросхем не было способов заставить машину быстро решать задачу. Но теперь-то в нашем распоряжении оптимизирующие компиляторы, многоядерные процессоры с параллелизацией, которые производительнее машин 20летней давности в сотни тысяч раз. Жаль, что программирование было поглощено стереотипным быдлом, не могущим в думать, и способным работать лишь по зазубренной инструкции, написанной кровью и потом сотен павших хомячков-байтоёбов до него. Настоящее, полноценное программирование, благодаря подобным обмудкам, мало теперь где востребовано. Хотя там где оно востребовано, можно кататься как в масле сыр и получать в три раза больше не то что сениор-байтоёба, а ёбанного заместителя директора быдлоконторы в которой этот байтоёб работает. С другой стороны это и хорошо - в космическую промышленность, Data mining и прочие сложные и непосильные для императивных байтохомячков сферы попадает лишь элита.
>Не превратит.
Rust, OCaml, MLton, GHC, etc. Это умные компиляторы, позволяющие писать код не в рамках архитектуры фон Неймана. Они преобразуют код в нужный вид для процессора. С этим нет никаких проблем. Программисту остается только понимать как на них писать. Ему не нужно знать устройство процессора.
Разницу в 1-10 раз можно нивелировать правильно подобранным алгоримом, или увеличением мощности. Тупо используешь 10 машин вместо одной, и не ибешься с тоннами неподдерживаемого кода на Си. На Хаскеле кода будет во много раз меньше, и он будет удобен в поддержке.
> Не примазывайся к славе тех байтоёбов, что пишут "браузеры, ос, сетевые стеки, сервера"
После этого ты пишешь
>потому что?
Ты не переспрашивал нихуя, из чего я делаю вывод что ты прекрасно всё понял, а уже впоследствии ты якобы вспомнил что нихуя не понял и решил потроллить тупостью.
В реальном мире существуют процессоры, которые по тактам выполняют команды последовательно, и обладают мутабельными регистрами, возможностью передавать несколько параметров в функции и т.д. Умышленный отказ от этого всего, с маняфункциями без императивности, без мутабельности, создает дичайший оверхед, поскольку процессору приходится выполнять не алгоритм, а какую нибудь всратую виртуальную манямашину чтобы обслуживать надуманные конструкции языка.
Все эти "целые", "дробные", "комплексные" считаются на реальном железе с реальными регистрами такого размера. Благодаря байтоебам у нас еще хоть что то работает, а манякукаретики загаживают все своими маняфункциями, из за чего на смартфоне, который как ты выражаешься в сотни тысяч раз мощнее старых компов, ввод и вывод текста работает медленнее, чем на тех старых компах.
Учитывая скорость вообще похую что они там могут и умеют, всю программу можно редуцировать до одной инструкции mov и всё равно изменений в скорости работы большей её части заметить не удастся.
"Преждевременная оптимизация - корень всех зол", и сказал это ни кто иной как отец всея байтослесарства.
>создает дичайший оверхед
Вранье. Опять же, оверхед покрывается правильным алгоритмом или увеличением количества машин. Не помню кто сказал, вроде Кормен, или Ахо, что правильный алгоритм позволяет увеличивать производительность программы в сотни, тысячи, и даже более раз, а вот быстрый язык может увеличить производительность только раз в 10, как например Си против Хаскела, ну или против Окамла. Дело в том что, быстрый алгоритм на Хаскеле/Окамле/etc можно написать намного быстрее и проще чем на Си. В итоге Си не выиграет ничего. Если даже он будет быстрее, можно тупо увеличить количество машин.
>Вранье
Сухие факты. В том числе подтверждаемые бенчмарками, да и банальной логикой. Одно дело оверхед, скажем, для конструктора объекта в крестах, там все ограничивается парой слов и парой косвенных вызовов, и другое - оверхед от маняфункций f(f(f(f(f(x))))) нахуй не нужных зато чтоб иммутабельно
>оверхед покрывается правильным алгоритмом
Сравниваются эквивалентные алгоритмы. Если вдруг твой маняязык быстрее байтоебства, это значит что на нем использовали медленный алгоритм и его можно переписать быстрее.
>увеличением количества машин.
Закон мура не работает в паралеллизме, так как оверхед на синхронизацию и передачу состояний между машинами съедает весь прирост.
>быстрый алгоритм на Хаскеле/Окамле/etc можно написать намного быстрее и проще чем на Си.
Что там сложного-то? Берешь и пишешь пару циклов и проход парой указателей.
Дело не в том что не уступает, а в том, что конкретно в прологе придется писать портянки кода уговаривая пролог посчитать все за приемлимое время. В результате код на прологе выглядит ужасно грязно, с постоянными указаниями как делать перебор в дереве. Ну и зачем это надо, если можно просто на си написать цикл и там явным образом указать, как именно будет проходить перебор.
Твои доводы полная чепуха. Ты не напишешь такой же короткий и поддерживаемый код на Си какой можно написать на перечисленных мной языках. Аналогичный алгоритм на Си будет больше, сложнее, чем такой же на Окамле. При этом выигрышь в производельности врядли будет больше чем в 3 раза. Для не сложного вычисления это чепуха, его даже не заметишь. Если вычисление реально сложное, то можно просто увеличить количество машин. Профит. Это будет быстрее, дешевле, проще.
> можно просто увеличить количество машин
Это так не работает. Оверхед на синхронизацию быстро съест весь рост.
Типичный график перформанса от многопроцессорности выглядит так.
4 ядра дают меньше х2 прироста над 2 ядрами.
8 ядер дают меньше х7 прироста над 2 ядрами.
16 ядер дают всего х10 прироста над 1 ядром, а не х16.
>процессору приходится выполнять не алгоритм, а какую нибудь всратую виртуальную манямашину чтобы обслуживать надуманные конструкции языка.
Что это вообще значит? Ты же в компиляции и кодогенерации вообще не шаришь. Причём тут виртуальная машина, нахуй ты её сюда приплёл. Ты хоть понимаешь какие она решает задачи?
Алгоритм это и есть надуманные человеком операции, процессору вообще похуй, он выполняет тот машкод что ему выполнять.
При том, что если твой функциональный манякод окажется чуть сложнее f(f(f(f(x)))) от он не схлопнется в одну инструкцию, и компилятору придется эмулировать весь твой маняязык, в котором не существует мутабельных переменных, функций с более чем одним аргументом и так далее, ему придется перекидывать байтики туда-обратно, создавать тысячи временных объектов, и выполнять сотни вызовов на стеке.
Чел, в реальности жизни, кроме абсолютных показателей, типа выполнилось за столько-то писесекунд, используются относительные, если юзер своими глазами не замечает разницу, значит разницы нет. Поэтому абсолютно похуй за сколько наносекунд отработает логика твоего бекенда на асме, если 99.99% времени будет потрачено на запрос в базу/кеш, а если не в него, ты всё равно упрёшься в езернет. В виду этого, твои рассказы о оверхеде на синхронизацию как минимум смешны (и это в эпоху микросервисов). То же самое с фронтендом, мобилками и т.д., ты упираешься в браузер, платформу и так далее. Понимаешь, не все заняты автоматизацией сливных бачков на полудохлом МК. За оптимизированный код нужно платить и за оптимизацию без необходимости не берутся. В редких местах, можно написать императивный говнокод, тот же хаскель предоставляет средства написать "настоящий" квиксорт, предоставляет мутабельные массивы, IORefы и прочее говно, но к ним прибегают только в случае крайней необходимости.
Иметь 98% процентов хорошо читаемого и надёжного кода и 2% мутабельной императивной лапши для оптимизации боттлнеков лучше, чем иметь 100% мутабельной императивной лапши, просто ради в выйграше нахуй никому не нужных миллисекунд. А ещё лучше вообще не смешивать и доменную логику писать на высокоуровневом ЯП, а узкие места на том же расте/окамле и подключать их отдельно.
Ооо, твой уровень понятен. Ты небось ещё думаешь, что
при работе с иммутабельными данными, будут реально создаваться каждый раз новые структуры? Боюсь тебя огорчить, в сгенерированном коде этого не будет, а будет обычная, так любимая байтоговнарями, мутабельная процедурная дрисня с указателями.
Олсо, ты так и не написал, какое отношение к этому всему имеет виртуальная машина. Почему допустим хаскель код компилируется в нейтив и для выполнения ему никакая вмка не нужна?
>при работе с иммутабельными данными, будут реально создаваться каждый раз новые структуры?
Да, при нетривиальных программах сложнее хеллоу ворлда так и происходит. Что подтверждают бенчмарки где хаскиль медленне даже джавы.
>какое отношение к этому всему имеет виртуальная машина.
Доеб к словам, ты все прекрасно понял.
Ну это уже совсем ЖЫР пошёл.
Ну да, хорошо читаемый и надёжный это процедурные портянки на говняшной.
>Да, при нетривиальных программах сложнее хеллоу ворлда так и происходит.
И тут ты такой с пруфами.
И вот это вот
>Что подтверждают бенчмарки где хаскиль медленне даже джавы.
не является прямым, потому что оно может работать медленнее не конкретно из-за этого, а например из-за ленивости, которая действительно требует создания санков.
По факту, кто смотрел исходники GHC и генерируемый код, или хотя бы читал документацию, знают что при работе с иммутабельными данными никаких копий не происходит, а происходит переиспользование памяти с обычной передачей указателя.
>хорошо читаемый и надёжный это процедурные портянки на говняшной.
Да. Вот как выглядит простой и надежный код
1-2. инклюды чтобы строки и консолька работали
3-4. разработчики юникода и шиндоус мудаки, поэтому копипаста чтобы utf-16 работало
5. ненужный инклюд забыл убрать
6. конфиг. половинная ширина терминала (подобранная методом проб и ошибок)
7. функция для перевода символа юникода в его смещение относительно буквы А
8. функция добавления символа к строке с учетом текущих тегов.
9. если нет тегов или символ не конвертируемый, добавить как есть
10. если символ в нижнем регистре, то доп.смещение. потому что авторы юникода мудаки
11. автоматически высчитываемое смещение в зависимости от текущих тегов.
12. фикс пропущенных символов. потому что авторы юникода мудаки.
13. добавление к строке суррогатной пары. потому что авторы юникода и шиндоус мудаки.
15-16. глобальные переменные, вынесены туда из мейна для простоты.
17. функция, дописывающая к строке накопленные символы незавершенного тега. есть бага.
18. псевдохешмап, на два валидных и один невалидный тег
19. главная функция
20. копипаста чтобы utf-16 работало, потому что авторы юникоды и шиндоус мулаки.
21. цикл, считывающий строку целиком из консольки и сбрасывающий переменные
22. цикл для всех сивмолов в строке. есть бага.
23. если самый первый символ строки #, то вход в режим заголовка. сам # не добавляется к строке
24. добавление к строке символа в режиме заголовка
26. конечный автомат микропарсера тегов
27. в начальном состоянии, если символ открытия тега, то следующее состояние
28. иначе символ добавляется к строке с учетом текущих тегов
29. в состоянии ожидания буквы тега, если /, то переход в состояние закрывающегося тега
30. в состоянии ожидания буквы тега или закрывающегося тега, запомнить букву тега
31. в случае незавершенного тега, записать сохраненные символы.
32. в состоянии окончания открывающего или закрывающего тега, если тег валиден, то (кроме случая, когда тег не был открыт) увеличить или уменьшить счетчик активных тегов. И сбросить состояние конечного автомата.
33. как 31.
36. завершение последнего незакрытого тега в строке
37. обрезать обработанную строку по полуширине терминала
38. выровнять строку пробелами до полуширины терминала и отделить вертикальной чертой
39. вывести обработанную строку и подготовиться к вводу новой строки, вернув каретку в начало.
40. повторить весь цикл ввода.
Незалдуженная слава. Нет никакой практический разницы между изменением стейта напрямую и рекурсивным вызовом текущей функции с изменённым стейтом. Точно так же можно проебаться и передать неправильный стейт. Вся разница лишь в отсутствии локальных переменных и вынужденности инициализировать и передавать их извне. Абстракции текут повсеместно. Да, с математической точки зрения красиво. Но не забываем, что математика так и не научилась в абстракции, и в каждой теории тебя заставляют дрочить доказательства, даже если это сотню раз было доказано, и всем на это насрать. Как если бы для написания хеллоуворлда пришлось дрочить весь более низкоуровневый код от ядра и драйверов до исходников стандартной либы.
Ты-то что осилил сложнее факториала?
Как и зачем натягивать парадигмальную разницу в ООП кешах и полностью редуцируемого ФП кода - непонятно
Каким образом ты специфику языка с "пробрасыванием стейта" закидываешь в "архитектуру" непонятно
Для пробрасывания есть свои инструменты и паттерны, те же трансформеры
Если у тебя возникают какие-то проблемы с реализацией в ФП ты или делаешь что-то не так или пытаешься впихуть невпихуемое по определению
В ФП стейт передаётся явным образом просто как аргумент для тех функций, которые от него зависят. Он специально типизирован и код работающий со стейтом, как и с прочими сайд эффектами, изолирован от чистого кода. В императивной же дрисне сайд-эффектное говно перемешано с остальным кодом, в результате чего его безопасность в разы меньше.
Работа с сайд эффектами в ФП языках построена на его концептуальном базисе (монады в Haskell, линейные типы в Mercury и Clean), а для уменьшения синтаксического шума при работе с ней, обычно есть специальные конструкции типа do нотации, !IO и тд.
Кому-то доводилось использовать в проде зигохистоморфный препроморфизм?
Это никому не интересно. Вот у байтоебиков интересно, например есть в процессоре инструкция popcnt, которая считает кол-во единичных битов в слове, которую любят использовать игроделы, но которой нет в старых процессорах. Но это не проблема, так как ее можно заменить на небольшой цикл, а учитывая, что эта инструкция используется для какой-либо фигни, то такая замена на производительности не сильно скажется, допустим там до 5% всего медленнее будет. Остается вопрос, а как же вставить цикл, ведь он длиннее инструкции popcnt. Тут на помощь приходят трамплины. Сами байты инструкции заменяются на байты инструкции вызова подпрограммы, а в ней уже пишется сам цикл. Причем можно сделать так, что это будет происходить автоматически. Ведь у процессора есть прерывание несуществующая инструкция, при этом прерываение получает адрес, по которому инструкция расположена. А значит, можно по аналогии с pagefault подменить все и продолжить программу с того же места.
Лучший способ с ними разобраться - начать пытаться использовать.
Если только ты не математик-теоретик.
(далее я поменял : и :: потому что так эргономичнее)
Что это?
Их можно определить разными способами:
- как моноид в категории эндофункторов
- через сопряжённые функторы
- как тройку (m, pure, bind) с набором законов, где m : -> , pure : a -> m a, bind : m a -> (a -> m b) -> m b
- как тройку (m, pure, join) с набором законов, где m : -> , для m определён функтор, pure : a -> m a, join : m (m a) -> m a
- как категорию Клэйсли, где id : a -> m a, (.) : (b -> m c) -> (a -> m b) -> (a -> m c)
наверняка ещё как-то.
Но это всё не очень способствует понимаю.
Как о них можно думать?
Вычисления в некотором контексте или вычисления с эффектом.
Иногда - как о некоем контейнере с композицией порождающих его функций.
Ещё удобно смотреть на типы вида `a -> m b` как на `a —m—> b`, т.е. это не просто функция, а функция с сайдэффектами.
Зачем они нужны программисту?
Они предоставляют единый интерфейс для композиции вычислений с контекстом/эффектами.
Что при помощи них можно делать?
Допустим, у тебя есть тип m с монадкой и две функции `f : a -> m b` и `g : b -> m c`, ты хочешь скомпозить их и применить к некоторому `x : a`. `g (f x)` очевидно не сработает, т.к. типы не совпадают, зато ты можешь сделать `f x >>= g` или `pure x >>= f >>= g` или `(g <<< f) x` или ещё что-нибудь такое.
Как пользоваться?
Обычно в разных ЯП есть сахарок для монадок: в хаскеле do-нотация и monad comprehension, в скале monadic for, в f# - computation expressions, в c# - linq query syntax.
Но разумеется никто не запрещает использовать родные и милые сердцу pure/return, join/flatten, flatMap/SelectMany/>>= и прочее.
Какие бывают монады?
На примере хаскеля.
- `data Maybe t = Nothing | Just t` (оно же Option и Optional) - моделирует частичные функции, контекст опциональности. Например функция деления на целых числах частичная, т.к. не определена для делителя == 0, но её можно превратить в полную с помощью Maybe: `divSafe : Int -> Int -> Maybe Int`
- `data [t] = [] | t :: [t]` (он же List) - моделирует недетерменированные вычисления, т.е. как бы множество разных реальностей с разными результатами вычислений в них.
- `data State s a = State (s -> (a, s))` - моделирует чистое состояние. Со стэйтом у тебя получаются функции `a -> State s b`, что эквивалентно `a -> s -> (b, s)`, что эквивалентно `(a, s) -> (b, s)`, т.е. функция вдобавок к отображению `a -> b` ещё и производит отображение состояния `s -> s`. К этому типу прилагаются функции `get : () -> State s s` и `put : s -> State s ()`, обеспечивая доступ к состоянию на чтение и "запись".
- ST с магией экзистенциальных типов - моделирует мутабельное локальное состояние (т.е. разрушащие операции в памяти в некотором скоупе)
- IO с магией компилятора - моделирует ввод-вывод, по сути даёт возможность строить вычисления, композя их из более простых вычислений (можно думать о `putStr : String -> IO ()` как о функции, которая принимает строку и возвращает вычисление, печатающее строку в консольку. Этим вычислением ты можешь оперировать как обычным значением - передать в функцию, сохранить куда-то, скомпозить с другим вычсилением, выкинуть на мороз, высрать из main чтобы оно запустилось). Представляет из себя State, где состояние содержит весь мир.
и прочие, их бесконечно много.
Другие наиболее полезные - Reader, Writer, Cont, Identity, Free, Codensity.
Ещё их можно композить, но это сложно.
Есть Джон Кармак, эталонный байтоёб из палаты мер и весов. Топит за как можно более функциональный код (даже в нефункциональных языках). Есть мнение анона-байтоёба: "ряя, зумерки, рряяя, нахуй функциональщину".
Кому мне верить? Ну чисто так за советом обращаюсь.
Вот что интересно у байтоебиков https://github.com/utds3lab/pemu
Объясняю монады на примере ООП.
Допустим у нас есть объект с полем name
Мы можем обратиться к нему с помощью object.name
Также допустим у нас есть объект (скажем, запись в бд сотрудников), с полем person
Мы можем обратить к нему с помощью dbitem.person.
Но к имени этого человека без монад мы можем обратиться только написав
dbitem.person.name
Мы не можем получить имя напрямую из объекта dbitem, потому что оно "упаковано" в объект person
Но в джаваскрипте мы можем получить первое поле любого объекта, написав.
object.children[0]
Что дает нам единообразный способ доступа к вложенным объектам.
Например мы можем обрабатывать их как-то так
while((o = object.children[0])) process(o)
Можно сказать что речь идет о втором измерении, о "комплексных числах".
У нашего объекта есть поля
obj.field1,
obj.field2,
obj.field3
А монада - это движение вглубь
obj.inner1.inner2.inner3
Почему это важно фп-блядям?
Ну у них то все функции. Допустим у них функция возвращает другую функцию. А они хотят узнать не функцию, а ее значение. Вот мы и попадаем в ситуацию как я в начале описал.
>монада-массив
Ясно.
В принципе, любое объяснение по монадкам, начинающееся со слов
>на примере ООП
можно не читать, 100% там будет хуйня, и вот опять.
Это как объяснение простых вещей из школьного курса алгебры для умственных инвалидов. Уж лучше картинки с контейнерами.
Зато Пролог дает премиальные фичи. Только в прологе(ну и в лиспе) ты можешь решать уравнения естественным образом:
?- {10 =:= X*2}
X = 5
Только Пролог дает самый высокий уровень абстракций.
Только в Прологе код - это действительно данные. В прологе программа может анализировать свою же структуру! Такое даже лисп не умеет.
Вообще, я считаю, что идеальный язык программирования должен уметь работать со всеми парадигмами.
Начиная с байтлебства, язык должен иметь инструменты для постпоения абстракции более высокого уровня.
> но вообще хуйня без задач.
Свойства предикатов дают весьма полезные штуки.
Любимый пример с append.
Append делает конкатенацию двух списков. Реализация его очевидна для пролог-программиста:
append([], L, L).
append([H|T], L, [H|R]) :- append(T, L, R).
?- append([1,2],[3,4],X).
X = [1,2,3,4].
Однако! Из-за логической природы пролога, с помощью append можно не только для соединить списки, но и найти первый список по второму и результирующему:
?- append(X,[3,4],[1,2,3,4]).
X = [1,2].
Это просто ахуетельно. И вообще-то порой полезно.
Проблема пролога - недостатки в работе абстрактной машины-считалки.
- Пролог не умеет в детект левой рекурсии - пиои анализатор кода сам.
- Пролог не умеет по умолчанию в детект заведомо-ложных предикатов.
Если предикат никогда не будет верным, то скорее всего с этим предикатом что-то не так.
- Инструменты отладки есть, но ошибки искать ты должен сам - иди трейсь весь стек вызовов, и ищи там ошибку, лол.
Это наболевшие проблемы. Благо, часть из этих проблем можно решить самостоятельно, самоанализом программы самой-себя на наличие ошибок в самой-себе же.
> И нахуя это где-то вне лаба1?
Транспиляция кода из одного ЯП в другой, да и кодогеерация впринципе.
Построение своего DSL внутри пролога.
Краткие и выразительные решения практических задач.
> современные программы в обеих сферах оперируют гигабайтами данных, и от комбинаторного взрыва твой пролог охуеет?
Пролог не про байты, Пролог - интеллектуальная обертка над байтами.
>иммутабельность
Что хорошего в иммутабельности, которая значительно ухудшает производительность?
Ну вот к примеру есть у тебя лист из нескольких сотен элементов и тебе нужно заменить один из этих элементов на другой.
В случае с мутабельным листом, ты просто заменяешь этот элемент на другой.
В случае с иммутабельным листом, тебе приходится при помощи не сложных, но странных манипуляций, скопировать лист, заменив в копии листа необходимый элемент на другой.
Чепуш, какое мне дело, как там список работает? Это вы там ковыряетесь в кишках, нормальным людям похуй на это, пусть разработчики компилятора ебутся и оптимизируют это хоть на ассемблере, мы находимся ЗА этой абстракцией, нам поебать. Нам главное, что в самой программе не было сайд-эффектов, это помогает быстро писать надежный и простой код, пока ты там вручную вилкой ковыряешь говно в списке.
типы как объекты, каррированные функции как стрелки, HOFs как экспоненциалы, чистота, ссылочная прозрачность, аппликативность и свободные (при совпадении доменов-кодоменов) композиции, equational theory settings / reasoning как следствие, в терминах ТК, в том числе, начальные алгебры / финальные ко-алгебры как фреймворк для описания индуктивных рекурсивных данных (как выход - результаты, значения) и ко-индуктивных ко-рекурсивных потоков данных (как вход); функторы, монады, Kleisli категории - многие индуктивные [возможно] рекурсивные типы данных которые функторы (начиная с Identity, Maybe и List), также, обычные суммы, произведения и степени, то есть кортежи/записи, объединения/варианты и функции - writer, error и reader/environment, для функций более специального вида - prompt, parser, state и cont, par/conc/async как cont для fork/join/io/done языка; функторы, ко-монады, coKleisli категории - ко-индуктивные ко-рекурсивные типы данных которые функторы (простейшие потоки и деревья, например), те же произведения и степени (суммы?), указатели и изменяемые подструктуры (линзы, как функции в), зипперы; свободные монады вокруг типов данных которые функторы - iteratees (которые сами по себе потоки, то есть финальные коалгебры для соответвующих (строго-позитивных таки) функторов), разные языки (eDSL на ADT) и их интерпретаторы; ко-свободные ко-монады для типов данных которые функторы - ?; (под)категории и стрелки - линзы (категория, тензор, но не вполне стрелка), обычные функции, Kleisli стрелки, coKleisli стрелки, стрелки biKleisli категорий, функции ограниченные типом - списки-в-списки, потоки-в-потоки, деревья-в-деревья, сигналы-в-сигналы и поведения-в-поведения (как оно применяется в FRP) и т.п., автоматы, симуляции, преобразователи, некоторые языки-eDSL-на-ADT, опять же; монадические трансформеры как определённого вида натуральные трансформации для определённого вида функторов над разными монадами - WriterT, ErrorT, ReaderT, StateT, ContT, MaybeT, ListT и т.д., например, ReaderT (ConstEnvironment, MutableScope, Resources) IO - эффекты, injectable read-only / write окружение, список ресурсов пополняемый их захватами по мере выполнения и автоматически освобождаемый в конце; полугруппы, моноиды, сворачиваемые и обходимые типы и т.п. категорные и алгебраические типы и классы как «паттерны» и средства декомпозиции.
Хаскель - простой и понятный язык для нормальных людей вроде физиков и математиков, отчищенный от байтосодомии и делающий специально выведенных компьютерных опущенцев-программистов ненужными.
С дальнейшим развитием оптимизирующих компиляторов, байтоспарта закаленных еблей в жопу архитектурой фон Неймана и еблей в рот аппликативным порядком боевых пидарасов-программистов потеряет всякий смысл. Что останется делать после этого жалким недочеловекам, у которых пять лет в шараге вымывали из мозгов все человеческое? Остается только прерывание своего жалкого существования.
https://petr-mitrichev.blogspot.com/
Блог от самого крутого программиста эвер
Метапрограммирование
https://en.wikipedia.org/wiki/Metaprogramming
Императивное программирование, где пошагово описываешь, как изменять состояние - действительно крутая концепция. Потому что только она работает и только она похожа на реальный мир.
Очевидно, что читать рецепт приготовления салатика в духе "Нарезать X, добавить Y, перемешать, посыпать сверху Z" куда понятнее, чем "Салат - это посыпанное сверху Z перемешивание после добавления Y к нарезанному X".
Я уже отвечал где-то на подобный даунский наброс несколько раз. У говноедов даже фантазии не хватает.
Ещё раз, язык тумба-юмба "взять копьё; убить мамонта; съесть мясо" ака императивное говнище, не подходит для описания реальности. Он хорош для тупого пошагового исполнителя, типа кухарки из твоего примера, бездумно хуярящего примитивные инструкции, но для чего-то сложнее, например, описания свойств тех же продуктов, изменения этих свойств в процессе готовки, их влиянии на конечный продукт и прочих знаний, которые используют люди, что составляют потом рецепты для домохозяек-исполнителей, он совершенно не подходит. Мир описывается декларативно формулами и отношениями, потому что только так возможно абстрагирование и общение, и только клинический дебил, с отсутствием минимального абстрактного мышления, не может этого понять и чтобы что-то понимать, ему нужен набор инструкций на бумажке.
Какое еще "изменение" свойств? У тебя нет никакого изменения.
У тебя есть обрезанная императивщина, ее жалкое подмножество без присваивания с отложенным исполнением, обрезанная для твоей же безопасности, так как ты не в состоянии отслеживать состояние своей собственной программы, подходящая только для решения определенного типа задач: проведения параллельных вычислений, и принимающая от того уродливые формы
Хммм, а вот тебе другой пример:
1. «Квадратный корень из икс — это такое число, которое, будучи возведённым в квадрат даёт икс»
2. «нууу эта, кароче берёшь приближение, подставляешь его в уравнение, если не подошло берёшь среднее от приближения и результата и пробуешь опять»
Не всё так однозначно в этой жизни.
на дваче
> 1. «Квадратный корень из икс — это такое число, которое, будучи возведённым в квадрат даёт икс»
в реальной жизни https://stackoverflow.com/questions/19965149/integer-square-root-function-in-haskell
> один вариант перебор
> другой
> 2. «нууу эта, кароче берёшь приближение, подставляешь его в уравнение, если не подошло берёшь среднее от приближения и результата и пробуешь опять»
> в реальной жизни https://stackoverflow.com/questions/19965149/integer-square-root-function-in-haskell
В голос.
что значит понятно человеку? какому человеку? выспался он? покушал? учил ли матан? понимает ли он сам чего хочет?
окей нашли сферического в вакууме, а шо толку с его пониманий, если написанные им декларативные предикаты/программы/любая-другая-хуйня не превращаются в эффективный код на процах?
>если написанные им декларативные предикаты/программы/любая-другая-хуйня не превращаются в эффективный код на процах
Предпосылка взята с потолка. А что если в данном месте эффективный код не важен, и его можно выкинуть на мороз, заменив на понятный? Двадцать первый век на дворе.
Ты еблан, разные алгоритмы сортировки делают одно и то же и с одинаковой семантикой и апи, но под капотом одно и то же.
Иммутабельность дает другой апи, другие плюсы и минусы, поэтому пердоли сводящие все программирование только к оптимизации - дегенераты.
Твой аргумент инвалид, пошел отсюда нахуй.
>А что если в данном месте эффективный код не важен, и его можно выкинуть на мороз, заменив на понятный? Двадцать первый век на дворе.
Найдут очередную уязвимость и дропнут производиительность твоего i7 до уровня core 2 duo из блейзерного 2007, и вот ты уже бибу сосешь.
Так это оптимизированный код чаще всего содержит уязвимости, так как он трудно читается, трудно тестируется, плохо подлежит модификации, требует написания большего количества букав, а значит больше шанс обосраться, а если он содержит всякие байтоёбские изъёбы, то уязвимости там будут почти с 100% вероятностью.
>Ты определение "экономической целесообразности" введи хотя-бы
Цитирую википедию для тебя, дефисный ты наш:
>соотношение полученных результатов производства — продукции и услуг, и затрат труда и средств производства.
В данном случае бизнес не хочет платить за софт, сделанный с использованием трудноподдерживаемых, редких, неэффективных технологий.
Не знаю о чем ты, но держи:
>Про first-pass continuation style. Если не шаришь то помалкивай
Есть first class continuations, а есть continuation passing style.
Что такое first-pass continuations - вообще не ебу. Видимо, выдумка рашкована, не умеющего в ангельский.
Не понимаю ,как можно вот прямо супер восхищаться continuation passing style'ом. Это же красивый, конечно, но трючок для промежуточной трансформации в компиляторах нормальных лиспов. Писать самому код таким способом - очень странная затея.
Если не решается, и это херит быстродействие программы, то оптимизируй.
https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
Про выразимость не только функциональщики говорят, а вообще все ярые адепты любой технологии. Будь тред хоть про питон, js, раст, кресты, котлин, эрланг, лисп - везде эта "выразительность", потому что из-за синдрома утёнка дальше своего носа никто ничего не видит.
Выразимость это возможность что-то выразить в неких терминах. Ответ даётся в форме можно или нельзя. К примеру число пи нельзя выразить целыми числами.
Выразительность это субъективная характеристика, позволяющая среди альтернатив выбрать наиболее понятный и информационно ёмкий вариант.
Самая крутая концепция для меня это то, что надо задрачивать не крутость кода. Не красивые абстракции. А то что по факту этот код делает. То есть сам продукт. Вот это конечная цель, а все эти языки и концепции чисто вторичное - средство и не более того.
Что за хуйню я прочитал?
Дай я попробую. Представь, что у тебя нет эксепшенов, как будешь возвращать ошибку? Можно возвращать null, но тут возникает проблема с постоянными проверками на нулл на каждом шаге алгоритма (вспоминаем C-лапшу которая постоянно проверяет errno). Что если вместо этого создать класс NullMonad, который будет чейнить операции и выполнять их, если значение не нулл. Например можно будет написать const c = NullMonad.return(client);
const result = c.bind(Client.get_request).bind(Client.process_request).bind(Client.send_response). На каждом этапе наша монада проверяет результат на нулл, и выполняет переданную функцию если результат не нулл. Это просто уменьшает бойлерплейт.
Это один из примеров монад, так называемый OptionMonad.
А смысл? Идея монад, как я понимаю, это писать программу на более высоком уровне абстракций, на С таким просто никто не занимается, т.к. область применения другая.
Да и максимум что ты получишь, это нечитаемую магию на макросах. В хаскеле и окамле, ты сразу в типе функции видишь откуда, что и куда оно идет. Все это проверяется на этапе компиляции, а не в рантайме, тоесть ты не можешь просто забыть макросов навернуть и крашнуть программу на ошибке как в С.
потому что в си функции это по сути процедуры, возвращают результат работы через out параметры, а возвращаемое значение чаще всего используеться как флаг успешности, возвращая код успеха или номер ошибки
в фп языках функции это функции именно в математическом смысле чаще всего, возвращаемое значение и есть результат работы функции
естественно, приходиться опганизовывать другие, более сложные подходы к обработке ошибок, это не прихоть а необходимость
к.о.
https://kunaifusu.livejournal.com/242656.html
Отступы вместо { }
{ } вместо уебанских отступов.
do end вместо убанских отступов и { }
Ваномас программируя формошлёпинг (программа для замеров пластиковых окон) на с# в конторке вантуз системы зарабатывает 170к. При этом знает меньше любого в этом треде.
Символьные вычисления
Стрелочные функции