Да, очень сложно понять, что хотел сказать автор.
Как я понял, голографический принцип воспринимается буквально, вплоть до "каждый минимальный участок голограммы содержит информацию обо всём объекте".
Голографический принцип он вообще не про проецирование 3д на 2д и не про участки голограммы. Он вообще не про голограмму, как и, например, Большой Взрыв не про взрыв.
Просто слово "голограмма" более-менее понятное.
Голографический принцип он про эквивалентность физик в объёме и на поверхности и всё это вследствие некоторых свойств чёрных дыр. Не в том смысле, что физики одинаковые, а в том, что физика внутри определяется физикой на поверхности.
ps: А про ротор и левитацию вообще ничего не понял.
Я скорее про то, что оно пишется и ощущается как нечистый императивный код. То, что оно задешугарится в безопасные бинды — это как раз желаемое поведение, иначе мы бы нарушили гарантии.
Может оно так и выглядит, но устроено совсем по другому, несёт другие гарантии и вообще, это ДРУГОЕ. Просто ФП это другое программирование, это не императивное с ограничениями, а другое.
Если пытаться на него смотреть с императивной колокольни, то всё будет казаться кривым, недоделанным и ограниченным. Лучше, мне кажется, понять, что лежит в его соно
Я не большой специалист в котлин и c#, интересно посмотреть, что они делают с переменными на стеке. В принципе, scheme тоже этого не требует, я больших сюрпризов здесь не ожидаю.
Мой основной поинт в том, что modifySTRef не модифицирует переменную в замыкании.
Если мы поместим result = i в замыкание и позовём это замыкание три раза, то получим result=resulti*3.
Если мы позовём modifySTRef три раза, то всё зависит от нашей композиции. Обычая do нотация тоже построит цепочку вызовов, а другая монада легко может свести всё к одному вычислению. Вопрос в управляемой композиции.
Поэтому монады в целом и do-нотация в частности это не про нечистый код в хаскеле, это про композицию.
В общем случае нет. Ну или много будет плясок и мы придумаем монады и замыкания.
Вот как есть result *= i нельзя присвоить переменной и звать по необходимости.
Та же ява требует переменные effectivelly final для засовывания в замыкание.
А после того, как мы вооружимся ФП и таки сделаем правильное замыкание в императивном языке нужно будет придумать правила их композиции. Стрелки, монады, вот это всё.
Да нет же. Хоть оно и выглядит как утка, но не крякает, как утка. Хотя бы потому, что хаскельный кусок кода я могу "взять с собой" по программе, а императивный нет.
В том смысле, что modifySTRef result (*x) это обычное применение функции, которое в нотации do выглядит, как утка. Но его не обязательно так применять.
Ввиду отсутствия потока выполнения, хаскельный чётко определяет вход-выход функции и зависимости. У императивного подхода такой "свободы" нет — для того, чтобы понять результат print(i++, ++i++) в императивном языке нужно заглянуть в спецификацию и молится, чтобы там не было написано undefined behaviour, а в функциональном в код монады, а там никакого undefined.
ps: Конечно, прямого i++ в функциональных нет, это просто яркий пример кода модифицирующего переменную. При желании пример заменяется на modifySTRef.
Так тут же монада. Тут нет локальной переменной. Всё это классически разворачивается передачу следующего значения в следующую функцию. Монада (монады) предлагают правила разворачивания.
И да, хаскель конечно разрешает "нечистый код" с помощью unsafe.
Всё это от того, что в ФП отсутствует понятие потока выполнения, а есть только правила преобразования которые undecidable. Поэтому надо в ФП прийти "снаружи" и навести порядок железной рукой. Что и делают все эти наши компиляторы.
ФП это не набор соглашений, требований и ограничений. ФП не накладывает никаких требований на неизменяемость, чистоту и прочее.
ФП это набор согласованных правил.
Просто это правила отличаются от императивных (а не от ООП). ООП это вообще игра на другом поле. ФП можно сравнивать с императивной парадигмой, но не с ООП.
Что касается приведённого примера, то в ней, например, result *= i; является операцией, которая в ФП отсутствует.
Можно как угодно себя уговаривать, что это программа в стиле ФП, но она такой не станет. Нельзя в середине уравнения сократить на 0 и получить верный результат. Даже если он очень похож на верный.
Оффлайн режим это же просто огонь. Яндекс.Электрички на стартовом экране показывают маленькое расписание, но если открыть направление, то лезут в сеть. И ты такой на эскалаторе готов проклять весь этот ненужный и не к месту онлайн.
Всё это дико напоминает алгоритм поиска решения в Прологе с бэктрекингом. Единственное добавление это выбор начального узла, что делается в Прологе вручную несложно.
Ничего. Сам падал на еда. Больно и неприятно. Иголки остались в разных частях тела. Местные сказали ничего не делать, иголки минеральные и через полгода рассосались. Сейчас никаких следов и шрамов нет.
Есть совершенно прекрасная книжка «Руководство астронавта по жизни на Земле», которую написал канадский астронавт Кристофер Хэдфилд. Он летал и на американских кораблях и на российском Союзе.
Этой гипотезе посвящена книга «Новый ум императора» Пенроуза.
Книга очень интересная даже безотносительно этой гипотезы, т.к. затрагивает множество вопросов — вычислимость, детерминизм, кванотвые эффекты и т.д.
Да, очень сложно понять, что хотел сказать автор.
Как я понял, голографический принцип воспринимается буквально, вплоть до "каждый минимальный участок голограммы содержит информацию обо всём объекте".
Голографический принцип он вообще не про проецирование 3д на 2д и не про участки голограммы. Он вообще не про голограмму, как и, например, Большой Взрыв не про взрыв.
Просто слово "голограмма" более-менее понятное.
Голографический принцип он про эквивалентность физик в объёме и на поверхности и всё это вследствие некоторых свойств чёрных дыр. Не в том смысле, что физики одинаковые, а в том, что физика внутри определяется физикой на поверхности.
ps: А про ротор и левитацию вообще ничего не понял.
Ага, ну вот примерно я об этом и говорю.
Примерно такой же алгоритм в схеме ведёт себя более предсказуемо (ну, или привычно, смотря кто читает код :)
выведет 01234
Может оно так и выглядит, но устроено совсем по другому, несёт другие гарантии и вообще, это ДРУГОЕ. Просто ФП это другое программирование, это не императивное с ограничениями, а другое.
Если пытаться на него смотреть с императивной колокольни, то всё будет казаться кривым, недоделанным и ограниченным. Лучше, мне кажется, понять, что лежит в его соно
Я не большой специалист в котлин и c#, интересно посмотреть, что они делают с переменными на стеке. В принципе, scheme тоже этого не требует, я больших сюрпризов здесь не ожидаю.
Мой основной поинт в том, что modifySTRef не модифицирует переменную в замыкании.
Если мы поместим result = i в замыкание и позовём это замыкание три раза, то получим result=resulti*3.
Если мы позовём modifySTRef три раза, то всё зависит от нашей композиции. Обычая do нотация тоже построит цепочку вызовов, а другая монада легко может свести всё к одному вычислению. Вопрос в управляемой композиции.
Поэтому монады в целом и do-нотация в частности это не про нечистый код в хаскеле, это про композицию.
В общем случае нет. Ну или много будет плясок и мы придумаем монады и замыкания.
Вот как есть result *= i нельзя присвоить переменной и звать по необходимости.
Та же ява требует переменные effectivelly final для засовывания в замыкание.
А после того, как мы вооружимся ФП и таки сделаем правильное замыкание в императивном языке нужно будет придумать правила их композиции. Стрелки, монады, вот это всё.
Присвоить переменной это действие и вызывать по необходимости.
Да нет же. Хоть оно и выглядит как утка, но не крякает, как утка. Хотя бы потому, что хаскельный кусок кода я могу "взять с собой" по программе, а императивный нет.
В том смысле, что modifySTRef result (*x) это обычное применение функции, которое в нотации do выглядит, как утка. Но его не обязательно так применять.
Ввиду отсутствия потока выполнения, хаскельный чётко определяет вход-выход функции и зависимости. У императивного подхода такой "свободы" нет — для того, чтобы понять результат print(i++, ++i++) в императивном языке нужно заглянуть в спецификацию и молится, чтобы там не было написано undefined behaviour, а в функциональном в код монады, а там никакого undefined.
ps: Конечно, прямого i++ в функциональных нет, это просто яркий пример кода модифицирующего переменную. При желании пример заменяется на modifySTRef.
Так тут же монада. Тут нет локальной переменной. Всё это классически разворачивается передачу следующего значения в следующую функцию. Монада (монады) предлагают правила разворачивания.
И да, хаскель конечно разрешает "нечистый код" с помощью unsafe.
Всё это от того, что в ФП отсутствует понятие потока выполнения, а есть только правила преобразования которые undecidable. Поэтому надо в ФП прийти "снаружи" и навести порядок железной рукой. Что и делают все эти наши компиляторы.
ФП это не набор соглашений, требований и ограничений. ФП не накладывает никаких требований на неизменяемость, чистоту и прочее.
ФП это набор согласованных правил.
Просто это правила отличаются от императивных (а не от ООП). ООП это вообще игра на другом поле. ФП можно сравнивать с императивной парадигмой, но не с ООП.
Что касается приведённого примера, то в ней, например,
result *= i;является операцией, которая в ФП отсутствует.Можно как угодно себя уговаривать, что это программа в стиле ФП, но она такой не станет. Нельзя в середине уравнения сократить на 0 и получить верный результат. Даже если он очень похож на верный.
var i32 x=0;
или
i32 x=0;
Книга очень интересная даже безотносительно этой гипотезы, т.к. затрагивает множество вопросов — вычислимость, детерминизм, кванотвые эффекты и т.д.