Comments 103
PL1 же. Противоположная парадигма - попытка добавить в язык все известные средства выражения. Максимизация вместо минимизации.
Функциональное программирование хорошо в одном лишь случае - когда этим не злоупотреблять и не строить вокруг этого центр вселенной, как пытаются делать многие фанаты-функциональщики.
Статья хорошая однако уже на первых примерах хорошо видно, почему функциональное программирование это не про код а про решение проблем самой функциональной парадигмы и игру с конструктом языка, чем решение прикладных проблем. Но это лишь мое имхо...
Если подумать, то это не так. Отталкиваясь от размышлений автора, можно прийти к тому, что для решения прикладных задач достаточно использовать абстракции верхнего уровня, предполагая под ними функцию, а не объект. Не обязательно все программировать используя базовый кирпичик (функцию, Слово, йоту). Это как программировать даже не на ассемблере, а на 1 и 0. Можно использовать абстракции верхнего уровня и спокойно писать код как привыкли, но держать в уме, что это все функции. И язык lisp помогает это делать проще, т.к. он изначально задумывался как функциональный. Но нам ведь ничего не мешает применять это в разработке и на других языках. Это как в питоне - все есть объект. Мысленно подменяем объект на функцию, и спокойной решаем поставленную задачу. Кстати, мышление в той парадигме, что все есть функция, помогает проще решать сложные задачи, типа компьютерного зрения или разработки ИИ.
Статья потрясающая, закинул себе в закладки, чтобы иногда перечитывать!
Не обязательно все программировать используя базовый кирпичик (функцию, Слово, йоту). Это как программировать даже не на ассемблере, а на 1 и 0.
Жаль лайкнуть не имею возможности вашу мысль, но развить её стоит - крайняя форма такого программирования описана у Павла Шумилова "Иди, поймай свою звезду":
"Знаешь анекдот, как программист кипятит чайник. Дано: пустой чайник, кран, спички, газовая плита. Программа действий: наполнить чайник водой из-под крана, поставить на плиту, зажечь газ. Ждать, пока закипит чайник. Эта программа оформляется как объект. Второй случай. Все то же самое, но чайник с водой уже стоит на плите. Действия программиста: вылить воду из чайника и выполнить предыдущий объект.
Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ зажечь?
Нельзя. Можно добавить новое свойство или действие. В нашем случае - воду вылить. Будет новый объект. Но внутрь влезть нельзя. Объект дается как единое целое. Никто не знает, что там внутри. Все давно забыли, откуда ноги растут. В результате получается колоссальное дублирование кода и данных и огромная потеря производительности компьютера. С каждым годом компьютеры требуют все больше памяти, а работают все медленнее."
Так это же старый анекдот про математика и физика.
Математику и физику была предложена одна и та же задача: вскипятить чайник. Даны подсобные инструменты: плита, чайник, водопроводный кран с водой, спички. Оба поочередно наливают воду в чайник, включают газ, зажигают его и ставят чайник на огонь.
Затем задачу упростили: предложен чайник, наполненный водой и плита с горящим газом. Цель та же — вскипятить воду. Физик ставит чайник на огонь. Математик выливает из чайника воду, выключает газ и говорит: "Задача свелась к предыдущей."
Так одно другому не противоречит. Прикладное программирование есть то самое вытачивание неидеальных кругов на станке. Статья посвящена высшей абстракции, которая, так совпало, называется тем же словом.
Я всегда люблю приводить пример «заказ пиццы» и «рецепт пирога». Когда мы заказываем пиццу, мы используем декларативный стиль - мы не пишем для пиццерии пошаговую инструкцию, что делать, а лишь указываем, какую пиццу мы хотим получить, в каком количестве, где и когда. Это просто и удобно.
С другой стороны, когда мы пишем рецепт пирога, мы используем императивный стиль:
1. Возьмите белки от двух яиц
2. Смешайте с молоком и мукой в определенной пропорции
3. …
N. поместите в духовкуЕсли бы рецепт выглядел как «выньте из духовки помещенную туда час назад при температуре 210 градусов тщательно перемешанную и без комочков смесь молока, муки и белков от двух яиц», это был бы ужасный рецепт.
Иногда две парадигмы могут совмещаться при решении одной задачи - например, мы заказываем пиццу, а курьеру пишем пошаговую инструкцию, как найти нашу квартиру. Никому в голову не приходит везде использовать только одну парадигму и фанатично отстаивать ее превосходство - под разные ситуации лучше подходят разные способы доносить информацию. Почему же в написании кода должно быть по-другому?
Разве в статье говорится о лучшем языке для написания кода?
Вот так намного проще?
выньте из духовки -
помещенную туда час назад при температуре 210 градусов -
смесь тщательно перемешанную и без комочков -
молока
муки
белков -
от двух яицИ даже так
Одно и то же дерево из "функционального рецепта по приготовлению пирога".
Просто отрисованное в другую сторону. Кажется что левое функциональное дерево читается также как императивный рецепт. И особой разницы нет.
Но функциональный редактор потребует скобочек как в lisp / отступов как в питоне/ дерева или какого-то другого оформления.
выньте из духовки - помещенную туда час назад
"Залейте компоненты в колбу и хорошенько перемешайте. Только осторожно, иначе может взорваться"
выньте из духовки - помещенную туда час назад - вполне норм. Ведь исполнение идет изнутри. Сначала запечь на 1 час, а потом вынуть. При такой последовательности как в лиспах ничего не взрывается.
Это эзотерический пример. Может надо даже так
- вынуть (через час)
- запекать (210 градусов)В случае же компонентов в колбе пишем
- перемешать (осторожно, содержимое)
- залить (осторожно, компоненты)А вот эта инструкция очень странная:
"Залейте компоненты в колбу и хорошенько перемешайте. Только осторожно, иначе может взорваться" и будет, как я понимаю такой 😄
- следить и делать осторожно
- перемешать хорошо
- залить компоненты
Нинада. Люди плохо думают в обратной польской нотации или AST-деревьями.
У компьютера и у человека голова по разному работает. Для компьютера это рецепт как рецепт, а вот человеку, чтобы такие рецепты писать и читать, надо делать огромное усилие. Поэтому LISP по своему прекрасен, но пользоваться им хотят только тонкие ценители красоты, а широкие народные массы - не хотят (и вряд-ли захотят в будущем).
Ну, все-таки надо подметить что на "самом низком" уровне машинных инструкций компьютера все-таки скорее сугубо декларативны. Функциональные языки на этом фоне для значительной части компьютеров выглядят более чуждыми чем декларативные.
Были компьютерные архитектуры специально для лиспа: https://ru.m.wikipedia.org/wiki/Лисп-машина
Оно и естественно, потому что фон Нейман был человек.
Лисп - отличный прикладной язык, куда за время его существования запихали множество разных идей, в том числе из других языков. А многие в рамках лисп-культуры и придумали, откуда они разошлись по другим языкам.
И никакой он не строго функциональный, а мультипарадигменный. Есть там и императивная часть, и ООП (причем куда более навороченный, чем в том же С++). А уж в плане генерации кода - это мать всех прочих языков.
Я рекомендую вам с ним ознакомиться. Писать на нем вы вряд ли станете, но полезного можно утащить немало.
А вот описания, подобные этой статье, создают совершенно ложное впечатление, будто это нечто эзотерическое и доступное только жрецам.
мы не пишем для пиццерии пошаговую инструкцию, что делать, а лишь указываем, какую пиццу мы хотим получить
Но ведь рецепт не нужно писать заказчику только потому, что в самой пиццерии уже есть жёстко забитый список императивных рецептов. А вот если вы хотите заказать пиццу "как мой коллега привозил на работу на дни рождения" - вам придётся явно указывать набор ингредиентов... если ваша пиццерия вообще позволяет менять состав.
Впрочем, с функциональными языками (особенно с теми, которые чистые) так и есть - как только доходит до деталей выполнения, то обязательно нужна прослойка-рантайм этих самых "рецептов", а то и железо у нас императивно-пошаговое, и сайд-эффекты нужны (хотя бы ввод-вывод), и ресурсы мало того, что не бесконечные, так ещё их явно запрашивать у ОС надо...
Ну с числами, разобрались. А с символами? Автор, а можете теперь данные о положении символов в тексте и в таблице символов ужать до функции одной. Скажем, что-то по типу множества мандельброта. А затем несколько тысяч итераций пропускать тексты в нейросеть, модифицируя эту функцию (для каждого символа/знака) и потом попробовать заставить нейросеть продолжать фразу?
Не все числа можно представить как результат функции. Есть трансцедентные числа, они не выразимы с помощью многочлена (как я понял, функции); они не счётны, в отличие от алгебраических (выразимых с помощью многочленов), то есть для них невозможна операция в духе "получить следующее число применением функции next к уже имеющемуся числу"
Тут речь не о многочленах. Трансцендентные числа тоже вычислимы в большинстве своем. Например пи и е можно выразить через тригонометрические функции.
Трансцендентные числа тоже вычислимы в большинстве своем.
В меньшинстве. Рандомно выбранное действительное число невычислимо с вероятностью 100%. Просто потому что множество алгоритмов счетное.
Другое дело, что невычислимые числа и трансцендентные - это разные сущности. Среди трансцендентых чисел есть вычислимые.
Вообще практические вычисления, особенно вычисления на компьютере имеют дело только с даже не целыми числами, а натуральными + ноль. Все другие числа полюбому как-то моделируются с помощью них (ноль минус пять, два разделить на три, шесть поюс 4 корня квадратных из минус единицы ...).
Поэтому вычислить точно даже 1/7 вы не можете, не то что пи! ( вспоминаем проблему с 3 * 0.(3) )
Но зато в функциональную парадигму всё ложится замечательно! 1+2 - полностью взаимозаменяемо с 3. А значит и 13/17 - полностью взаимозаменяемо с "истинным" значением результата этой операции деления. С пи - алгоритм "получения" поабстрактнее и посложнее, но принцип тот же.
13/17 это рациональное число, его можно выразить как выход функции деления, на вход которой подали числа 13 и 17 и поэтому оно ложится в концепцию функционального программирования. Число Пи - другое, его нельзя выразить как результат какой-то функции, я не знаю, как оно ложится в концепцию функционального программирования.
Алгоритм получения числа Пи: измеряем длину окружности, измеряем диаметр, делим.
Понятие "измерение" - оно, конечно, внешнее по отношению к математике.
НО. Нет никаких других способов (ну кроме как выдумать) получить исходные числа для математических вычислений.
В концепции функционального программирования любое исходное, заданное число - это и есть подобный "внешний алгоритм" (число и способ его получения - взаимозаменяемы, даже если способ получения - "нематематический").
В функциональном подходе числа являются как бы API математики к внешнему миру. Заданные в теле программы константы или полученные с внешних датчиков 0, 1 или 3454,7(647) тоже не являются результатом какой-то функции.
Однако т.к. это именно числа - то эти "внешние алгоритмы" можно комбинировать так же как и числа с помощью различных функций и получать полезный выхлоп. В этом весь смысл, как я понимаю.
Число пи можно вычислить и чисто алгоритмически, с любой заранее заданной точностью. Берём бесконечный ряд Лейбница (например) и считаем, пока не будет достигнута нужная погрешность.
Ну так просто получить число Пи не выйдет: допустим измерили диаметр, он оказался равен 10 попугаям, измерить длину окружности в тех же попугаях не выйдет, нужно будет измерять в мартышках, допустим 5 мартышек. Как разделить 5 мартышек на 10 попугаев непонятно, они несоизмеримы.
Просто потому что множество алгоритмов счетное.
Тут тонкое дело, упирающееся в то, как мы определим понятие алгоритма. Если алгоритм определить как последовательность шагов для получения результата, то множество алгоритмов счётно. Но алгоритм можно определить просто как способ получения результата, и тогда множество алгоритмов может быть любым.
Множество алгоритмов с конечным числом шагов по любому счётно. А вот если мы возьмём и алгоритмы с бесконечным числом (прописанных) шагов - то тогда континуально.
А насчёт определения: в течении тысячелетий под алгоритмом понимали только порядок выполнения расчётов (алгоритм - это всё тот же аль-Хорезме (aka "алгебра"), только искажённый по другому). Ну там деление в столбик, вычисление логарифма на счётах. И теорию таких алгоритмов хорошо развили и проработали в середине 20-го века Тьюринг и другие.
Но связи с развитием футуризма и появления идеи робота понятие алгоритма поползло в реальную жизнь. Алгоритмами начали называть и кулинарные рецепты и прочую нематематическую хрень. Это очень существенное расширение понятия.И я как-то не знаю серьёзных попыток научно проработать теорию таких расширенных алгоритмов (разве что ТАУ - но это не про алгоритмы). Просто тупо расширять машину Тьюринга будет некорректно.
Никто не обещал, что алгоритм состоит из шагов. Аналоговая вычислительная машина, например, работает по-другому.
А что касается Тьюринга, то он позднюю часть своей научной карьеры посвятил алгоритмам супервычислений, где действует оракул, принципиально не сводимый к последовательности шагов.
Популярное понимание вопроса застыло примерно на уровне аспирантских лет Тьюринга.
Никто не обещал, что алгоритм состоит из шагов.
Ну как минимум Википедия обещает. Там везде "set/sequence/step-by-step".
А вот большевики - действительно явно не обещали (хотя и подразумевают). Кому верить? ¯_(ツ)_/¯
Алгебра всё-таки от аль-джебр, хоть и того же автора.
«Дорогой, мой отец - энтерпрайз Java разработчик, давай без разговоров про LISP и Haskell за столом»
Я после одной рюмки:
Отличный язык для написания бизнес-логики, со вводом-выводом из окружения в нём как работать?
Чувствовал, что большинство выберет в качестве языка дьявола JS. Но как поклонник С++ я искренне убежден, что это именно он.
А раз ничего другого кроме формул и чисел мы о Вселенной содержательно сказать не можем, то стоит заключить, что наша Вселенная - это просто огромная математическая структура.
Не, не стоит так заключать. То что мы можем содержательно только на уровне формул и чисел сказать о вселенной, говорит лишь о том что наши инструменты для выражения и познания вселенной имеют ограничения физиологического характека. Формулы и числа - конструкт символьной системы мышления, как способа интерпретации сигналов человеческой сенсорики, за пределы которой не выпрыгнешь, можно только расширять сенсорику техническими средствами, и все равно результаты перегонять в область символьного восприятия человека - теряя информацию по пути.
Эссе, оно и есть ЭССЕ
Я бы не абсолютизировал математику и функции как "основу мироздания" - потому что как минимум половина нашей математики говорит о человеке, а не о мироздании. 1+1=2 нам кажется элементарным, потому что мы можем взять один камешек и другой камешек, и убедится, что теперь у нас два камешка, и соседу показать, а 4-тензор кажется сложным потому что для его понимания и объяснения придётся подтягивать математический аппарат, шлифовавшийся столетиями. Идеальные геометрические фигуры - это не столько чудо природы, сколько апогей ленивых вычислений, они идеальны по соотношению "цена/качество" для нашего мозга, позволяют выкинуть максимум информации о геометрии реальных объектов и всё ещё полезно оперировать ими в воображении.
Почти под каждым моим постом на Хабре восхищенные читатели пишут мне доброжелательные комментарии вроде этого:
Автору с таким перепутанным мировоззрением светит только психиатрическая палата или монастырь (первое предпочтительнее — там есть лечение и хоть какие‑то перспективы).
Наивно полагать, что мягкие стены остановят полет мысли, ведь управлять Вселенной можно и оттуда.
(с) SergioShpadi, Как управлять Вселенной, не покидая психиатрической лечебницы
Видимо, продолжаете цикл статей.
Очень режут глаз присваивания в разговоре о функциональном программировании и тем более о лямбда-исчислении.
А где там присваивания?
А как ещё понимать знаки равенства в статье?
Как вообще вы интерпретируете запись:
y = λx.x+1
?
"y равна по определению λx.x+1"
Или, что то же самое, "определим y как λx.x+1"
Давайте не так быстро. x – это связанный терм в инфиксно записанном лямбда-выражении справа, включающем также свободный терм 1. А что такое вообще здесь y?
Псевдоним для терма λx.x+1
Ну назовите определением псевдонима, а не присваиванием, разницы нет. Это не лямбда-исчисление тогда. Лямбда-исчисление основано на бета-редукции, то есть на чисто формальном преобразовании цепочки символов, которое теряет свою применимость при таком переобозначении.
Никакой внутренней семантики вычислительного процесса, отличной от эквивалентного синтаксического преобразования цепочки символов, составляющей лямбда-выражение, в лямбда-исчислении нет.
Результат редукции лямбда-выражения полностью содержится в его записи.
Разница есть, и принципиальная. Присваивание происходит в рантайме, а определение - всего лишь часть синтаксиса языка. Иными словами, присваивание - это связывание переменной и значения, а определение - это связывание имени и терма.
Лямбда-исчисление основано на бета-редукции, то есть на чисто формальном преобразовании цепочки символов, которое теряет свою применимость при таком переобозначении.
Попробуйте найти хоть одну нетривиальную математическую работу по лямбда-исчислению, в которой ни разу не был бы объявлен псевдоним. А потом объясните, почему в математических работах псевдонимы допускаются, а в программировании они недопустимы.
Присваивание происходит в рантайме
Совершенно не обязательно, но допустим.
Иными словами, присваивание - это связывание переменной и значения, а определение - это связывание имени и терма.
В контексте разговора о языке Лисп от меня ускользает, чем одно связывание слота атома со списком отличается от другого.
А потом объясните, почему в математических работах псевдонимы допускаются, а в программировании они недопустимы.
Они допустимы в программировании, как всякий синтаксический сахар. И даже функция setq в Лиспе существует. Но они не являются частью концепции функционального программирования, и не на их основе было бы разумно объяснять основы.
В контексте Лиспа я тоже не понимаю чем они отличаются и почему вообще Лисп считают функциональным языком.
Однако, запись y = λx.x+1 совершенно точно не является частью программы на языке LISP.
Но они не являются частью концепции функционального программирования, и не на их основе было бы разумно объяснять основы.
Возможность определить псевдоним для терма является базовой "фичей" математики, и было бы неразумно ей не пользоваться при объяснении чего бы то ни было.
Однако, запись
y = λx.x+1совершенно точно не является частью программы на языке LISP.
Вопрос в том, частью чего она является.
Возможность определить псевдоним для терма является базовой "фичей" математики, и было бы неразумно ей не пользоваться при объяснении чего бы то ни было.
Ага, а потом Бурбакам приходится за эти псевдонимы отдуваться сотнями страниц аксиоматических определений (кстати, бурбакизм очень идейно близок к функциональному программированию).
Вопрос в том, частью чего она является.
Это математическая нотация, повсеместно используемая в лямбда-исчислении. Языков программирования с именно таким синтаксисом я не знаю (возможно, какая-нибудь Agda и "прожуёт" эту формулу).
Ага, а потом Бурбакам приходится за эти псевдонимы отдуваться сотнями страниц аксиоматических определений
Возможность введения псевдонимов является частью мета-языка математики, она не определяется аксиомами на уровне математической теории.
Даже Бурбаки вынужденно использовали псевдонимы, ведь в противном случае даже определение единицы у них бы заняло 2 409 875 496 393 137 300 000 000 000 000 000 000 000 000 000 000 000 000 знаков (сам я не проверял, информация из Википедии).
Вообще в математике "=" - это не присваивание, а оператор сравнения. Если я правильно помню. Математика оперирует логическими выражениями вида "если значения y и x + 1 совпадают, то совпадут и значения y-1 и х"
Так что его употребление в математике вполне оправданно. В частности выражение y = λx.x+1 можно читать как: "Если неизвестное лямбда выражение y совпадает с λx.x+1, то ... (дальнейшие рассуждения)".
В чём проблема?
Ой, а можно я отвечу?
В 1930-х чувак придумывал кодировщикам спецификацию записи математических функций для первых ЦВМ. На Liste - то есть листе обычной белой бумаги (не путать с Lisпом), функции пишут, вроде как:
f(x,y,z) = x+y+z
Вот он долго не думая и записал: "Повелеваю, функции записывать так: (место для имени функции) = λ (место для перечня аргументов функции) . (место для тела функции)" и нарёк сё "абстракция". А вызов функции с аргументами - привет(в,е,н,я) - он нарёк "аппликация". Почему, собственно, нет? Имеет право!
Шли годы. Данный вид записи функции оброс слухами и легендами. В его мифологизацию внесла свой вклад и поп-масс-культура, выпустив пару музыкальных клипов с Кристиной Агилерой и тройку мерчей маек, сигарет, пива, и шариковых ручек с надписью Чё к ним, частично проспонсированных Ватиканом (это их маркетологам пришла идея, что всё это луче будет продаваться, если объявить запись Чёрча "Языком программирования Бога, на котором тот наваял Всё").
Шли годы ещё. Программисты теперь пишут функции по образцу имя(аргументы){тело} , а смутные обрывки о форме записи функций Чёрчем доступны в виде Тайных Знаний Гур и Лам. Преимущественно со скрепных территорий.
PS Ну, это тоже своего рода моё эссе о Лямбда-Исчислении.
єто не знак равенства. Єто знак связывания.
Платоновские идеи гораздо лучше ложатся на ООП, чем на функциональщину. Идея круга - класс. Нарисованный на листе бумаги круг - объект этого класса. Любые круглые предметы - объекты, реализующие интерфейс "круглость". А любой процесс, происходящий в мире, гораздо проще разложить на шаги и выразить императивно, чем попытаться вывести некую универсальную формулу.
Опоздали. Вопрос кругов в жизни "Мультивселенных" уже раскрыт автором в философском эссе Эйлер, Чёрч и Мандельброт — этюд о красоте и математике.
Там круг на весь экран (и не просто круг, а sic! круг с точкой посередине), и подпись: Чортов Чёрчев Черный Квадрат Монада Пифагора.
В принципе, ЯП - это абстракция. И ООП - это абстракция. И функциональное программирование - это абстракция. Круг - это тоже абстракция, которая позволяет выразить число Пи. Функциональное программирование позволяет выразить концепцию обработки данных. Концепция обработки данных позволяет выразить математические формулы. Математические формулы позволяют выразить правила и свойства пространства и времени, которые позволяют выразить то, что автор называет идеей. Некие законы бытия, правила для частиц и волн. И то, не факт, что это элементарные составляющие вселенной. ООП - это абстракция над функциональным программированием, которая позволяет объединять сходные данные и функции, а также, переиспользовать их или переопределять. Но всë это - лишь средство выражения, имеющее определëнные ограничения. Так, например, видимый или осязаемвй круг имеет погрешность реализации числа Пи. Функциональные языки имеют погрешность в представлении/хранении/обработке данных, а также, в реализации вычислений функций. С этой точки зрения, математика более точна, нежели информатика. Но, если возвращаться к вопросу того, что идеи Платона проще выразить через ООП, то следует помнить, что идея круга - это не класс, а функция. Идея многоугольников и многогранников - это углы, площадь и объëм. ООП лишь позволяет объединить эти формулы под общей абстракцией. Но, опять же, это даëт погрешность. Например, круг в ООП - что это? Напечатанная напринтере фигура? Или шаблон для станка? Или правила отрисовки для видеодвижка? ООП уводит нас от идеи - формулы - в сторону практической реализации, поскольку класс не может существовать без контекста его имплементации.
Почти обожаю этого автора! Стиль нечто) Наверное, когда он готовит себе завтрак, то это выглядит как-то так:
"Так, положим в тарелочку творога, немного докторской колбасы, пальмового масла... так - тёртый имбирь, столовую ложку соевого соуса, майонез, цедра лимона, кусочек сала... и, ох, да, чуть не забыл - заливаем все это квасом... ммм... предвкушаю вкусняшку...
И, пока я все это перемешиваю, я хотел бы поговорить с Вами подробно и по существу о Гаусовом исчислении и рангах компонент декартова разложения, чтобы было понятно как, в конце концов, в моей тарелке окажется замечательный жюлюен!"
Далее, напрягаться и писать какую-то обоснованную критику авторскому детищу смысла нет, ибо это как "об стену горох"! Это такой стиль изложения!
Но, все-таки, неплохо бы задуматься говоря о эпохи Античности на следующем, как говорится для общего образования:
Например, нет никакого "единства и борьбы противоположностей" (Гегель чуть опосля родился через где-то 15 веков) в понятиях Платона о материи и идеях, и фундаментально это не одно и тоже (идея и материя), а как раз фундаментально есть только идеи и всё!
Понятие "Бога" Античности нужно уточнять: безличное нечто существующее в замкнутом кругу перерождения в смысле циклинности и круговой замкнутости. Т.е. никакого Вам как пишет автор "создания" и "преобразования". В мире все создано и это множество постоянно и бессмысленно крутится по бесконечном кругу. Ничего не создаётся и не образуется! Нет идеи создания! Соответственно человек никакая не личность, а маленький атом в огромном космосе в надежде причаститься настоящей реальности "чистых идей" в философствовании.
Задуматься над термином создания! Ведь создание, это процесс появление того чего не было и одновременно почти полное отчуждение от него, ибо если созданное не автономно, то оно по сути и не созданно в полном смысле слова! И это один из серьёзных богословско-философских элементов проблематики акта божественного творения! И как пример разрешения этого - христианская идея богочеловечества и триадология.
Понятие человек в христианской этики, это не функция работающая с данными. Это трансцендентальная тайна. Это личность богоподобная.
Но, автору пофиг на эти нюансы, поэтому можно мешать тёплое с мягким ради красивого словца!
Мне нравится такое) Автор держит мозги читателя в тонусе. И задаёт интеллектуальное пространство для выяснения сути и деталей его скрытой на*бки! Спасибо искуситель абсурда!
По первому пункту позволил бы себе уточнить: идея единства и борьбы противоположностей хоть и не связана напрямую с Платоном, но к античности имеет самое непосредственное отношение, т.к. была высказана еще Гераклитом, а в диалектике Гегеля уже получила свое развитие. В том, что нужно быть осторожнее, делая попытки связать такие широкие области знания - соглашусь
Благодарю за уточнение! Вы правы!
Единственный важный момент: Гераклиту принадлежит "идея единства противоположностей" и мир находится "просто" в состоянии постоянного движения и изменения, а вот "идея единства и борьбы противоположностей" - это уже Гегель, и мир связан с развитием (становлением) и эволюцией идей и понятий, в процессе преодоления противоречий через диалектическое движение тезиса, антитезиса и синтеза! Т.е. как такового понятия "развития" (появление нового) в Античности отсутствует!
Т.о. на примере контекста автора - волна и корпускула у Гераклита - эти понятия просто существующие противоречия перетекающие одно в другое, а у Гегеля эти понятия "развиваются" в единстве и борьбе формируя новое понятие - "корпускулярно-волновой дуализм" и далее находя новый антитезис, например "единство материи", снова синтез - ну, например "квантовая физика" и т.д. т.е. в мире происходит процесс создания нового, конечноже не в идеях "эволюции Дарвина и современного понятия прогресс", а в Гегельянской трактовке как глобальное становление абсолютного духа в самоотчуждении!
Если язык Бога — это LISP
Но всем известно, что язык бога - это RUST
Если Лисп язык бога, то языком дьявола будут конечные автоматы, потому что они полностью противоположны функциональной парадигме - не состояния преобразуются функциями, а функции реализуются последовательностью состояний.
Мне кажется, связывать религию и программирование не стоит.
На протяжении всей статьи, особенно философской ее части, витает мысль о том, что все мы живём в симуляции. Но почему-то не постулируется явно.
Бог создал Lisp, а дьявол -- Common Lisp :)
В CL, при всей его лисповости, возможны такие грязные вещи, от которых стошнит и фортранщика. Но, именно потому что это Lisp, использование этих дьявольских кундштюков там возможно и даже полезно. То, от чего программа на другом языке превращается в гибрид макаронного монстра и атомной бомбы, в CL делает ее лишь быстрее.
Вообще, если мы уж коснулись вопросов божественного и дьявольского в языках программирования, то стоит упомянуть две книги -- SICP, как книгу "белой магии" программиста и "Common Lisp Recepies", как книгу черной магии. Обе про Lisp, что характерно.
Язык Ада же!
Если язык Бога — это LISP, то язык дьявола — это:
АДА?
Про возрения Лейбница,автор слыхивал?
Все смешалось в доме Облонских.
Смешались в кучу кони, люди, и залпы тысячи орудий слились в протяжный вой…
Это всё из разряда: "Весь мир - часовой механизм" или "Весь мир - древо Иггдрасиль". Каждый раз, когда слышу такое обобщение, хочется попросить предоставить доказательства. Напишите, пожалуйста, программу на LISP, чтобы она действительно описывала Вселенную. И не локально, а фундаментально, и чтобы и Меня, и Вас она тоже как-то описывала. Без предъявления подобной программы слова о том, что "наша Вселенная - это один гигантский бесплотный компьютер, который рекурсивно вычисляет все возможные программы, все возможные алгоритмы" в лучшем случае метафора. Это же БУКВАЛЬНО дискурс монистов из древней Греции. За почти 3 тысячи лет философия немного (прям совсем чуть-чуть) двинулась дальше. Я не понимаю, почему так сложно принять релятивную природу реальности? Зачем городить этот винегрет из всего и вся? Что в сущности вовсе и неплохо, но по-хорошему требует куда больше внимания к деталям, а не так что: %неймдропинг% -> LISP -> (вашу мать) Тора -> мир описывается функциональным программированием. PROFIT одним словом
В математике не обязательно построить, достаточно доказать возможность построения.
Учитывая что физики всё чаще стали говорить об информации (которая то быстрее света не может распространяться, то молекулы собирает, то ещё что-то), то можно уже говорить о формировании "всеобщей информационной теории" (сиречь - кибернетики). И соответственно, когда ( и если) такую теорию построят - то любой полный язык программирования можно использовать для вот такого информационного описания вселенной.
Просто некоторые предвосхищают. Ну или наоборот возвращаются к идеям середины 20го века.
Возможности построения БУКВАЛЬНО не было представлено. Набор метафор + восхищение функциональной парадигмой. Да, и насчет "достаточно возможности построения" тоже не все будут согласны, те же интуиционисты. Опять таки, если Всеобщая Информационная Теория, то пожалуйста. Никакой толковой выкладки по ней или по другой общей теории представлено не было.
Хорошая трава! Мне понравилось! 😂
Базированная статья. Натёр мой мозговой клитор до оргазма. Спасибо! В закладки!
Да понятно все )))
Программа это большое логическое выражение, выраженное как бинарное дерево
Бинарное дерево состоит из листьев и ветвлений - это S I K комбинаторы
Йота комбинатор это рекурсия (самоприменение)
Йота язык программа как число) это свертка бинарного дерева
Слово Божие — функциональное программирование как основа Вселенной