Машины фон Неймана и лямбды
Предпосылка Брайана в его аргументации на вопрос "Являются ли побочные эффекты хорошей вещью?" Интересно:
компьютеры - это машины фон Неймана, которые хорошо работают с эффектами (вместо того, чтобы хорошо работать с лямбдами)
Меня смущает сопоставление подходов. Я не могу видеть их черно-белыми. Что такое доказательство стоимости:
компьютеры - это машины фон Неймана, которые хорошо работают с эффектами [1]
Последняя часть смущает меня:
вместо того, чтобы быть разработанным, чтобы хорошо работать с лямбдами [2]
Используются ли лямбды как символы для функционального программирования? Или это эвфенизмы для функционального программирования? Каково реальное сообщение?
В каком смысле части предпосылки [1] и [2] верны? Какие скрытые посылки в ответе? Может ли кто-нибудь обосновать первоначальную предпосылку? Как на самом деле работают машины фон Неймана и лямбды?
2 ответа
Я не совсем уверен, что вы спрашиваете, но когда я читаю это, вы спрашиваете, что он имеет в виду под лямбдами?
Он имеет в виду лямбда-исчисление, которые составляют большую часть теоретической основы для функционального программирования. Это абстрактная запись для (среди прочего) описания и рассуждений о функциях высшего порядка.
Машина фон Неймана - это то, что у нас есть. Программы выполняются инструкциями, управляющими и обращающимися к магазину (нашей оперативной памяти). То есть все косвенно делается через побочные эффекты. Данные считываются из некоторой области в ОЗУ, немного обрабатываются и записываются обратно в некоторую (возможно, другую) область в ОЗУ. Без побочных эффектов центральный процессор будет ограничен манипулированием данными о мусоре, которые оказались в его регистрах, когда он был включен.
Лямбда-исчисление не имеет понятия о побочных эффектах, поэтому машина, основанная на этом принципе, не будет иметь различия между "тем, что ЦП может получить доступ" (наши регистры, по существу), и "тем, к чему можно получить косвенный доступ" (наша ОЗУ). Все в такой машине будет основано на функциональных принципах, на функциях, принимающих один или несколько аргументов, и возвращающих новое значение, никогда не изменяющих существующих. (И нет, я не уверен, как это будет работать в оборудовании...:))
Это отвечает на ваш вопрос?
Вот более глубокий смысл того, что я имел в виду, хотя будет интересно посмотреть, согласны ли другие или что они скажут.
Посмотрите, как сегодня работают компьютеры. У вас есть оборудование, которое имеет целочисленные регистры и регистры с плавающей запятой, а также огромный массив оперативной памяти и инструкции, которые в основном имеют форму, основанную на чтении значения этого регистра / ячейки памяти, и вставьте это новое значение в этот регистр. / клетка. (Обновление ячеек памяти имеет всевозможные преимущества, когда речь идет о строках кэша, моделях когерентности, памяти и т. Д.). Целые числа 32- или 64-разрядные, и почти все языки программирования отображают эти типы данных, которые точно соответствуют аппаратному обеспечению. Почти каждая среда выполнения работает с небольшим стеком вызовов, где размещенные в стеке объекты дешевы, и более дорогой "кучей", где другие объекты могут создаваться и уничтожаться, когда требуются времена, не основанные на стеке.
Теперь рассмотрим большинство современных функциональных языков программирования. Неизменность является нормой; Вы редко будете "тыкать" в память новыми значениями. (Это означает, что вы создаете больше новых объектов, что означает, что вы выделяете больше.) Лямбды и продолжения являются нормой; у вас реже есть время жизни объекта, соответствующее стеку. (Действительно, некоторые среды выполнения FP не используют стек; в реализации CPS понятие стека и счетчик программы неуместны.) Рекурсия - это циклическая конструкция, поэтому вам, по крайней мере, нужны 'хвостовые' вызовы, чтобы не потреблять стек в любом случае. Практически все нужно выделить "кучу", и, конечно, вам нужен сборщик мусора. Алгебраические типы данных предоставляют помеченные данные; теоретически для этих тегов потребуются только дополнительные 2 или 3 бита данных, но для соответствия времени выполнения им часто требуется дополнительное слово памяти или больше.... Я в некотором роде извилистый, но то, что вы чаще всего делаете на языке FP, как правило, точно соответствует вещам, которые масштабируются хуже всего или являются самыми дорогими в типичной архитектуре компьютерного оборудования и базовом языковом времени выполнения.
Так не должно быть. Можно представить себе мир, в котором среда выполнения избегает стека и ускоряет работу с кучей / выделением ресурсов (и не является узким местом для многопоточных приложений). Можно представить мир, в котором взаимодействующие целочисленные типы имеют 29 или 60 битов, а среда выполнения / аппаратное обеспечение используют дополнительные оставшиеся биты слова, например, для GC, тегов алгебраического типа или чего-то еще. (Я думаю, что некоторые реализации / среды выполнения FP выполняют некоторые из этих трюков.) И т. Д. И т. Д. Дело в том, что если взять современный функциональный язык как данность, а затем спроектировать среду выполнения / оборудование вокруг него, он будет выглядеть совсем по-другому. от типичного оборудования / времени выполнения сегодня.
(Я не думаю, что я сообщил об этом ужасно, и я не очень точен в отношении многих деталей, которые я точно не знаю, но, надеюсь, вы поняли суть моей диссертации здесь.)