Они изоморфны, но рекурсия тут точнее отражает математическую суть.
Алиса
У Алисы нет памяти, а если таковой считать предшествующий текст, получается крайне низкая связность. Поэтому Алиса не похожа на сознание. Но да, я позволяю широко подстраивать рамки. Это не ломает логическую цепочку.
Ну, если считать, что сознание вычислимо на машине Тьюринга, что потребовано в качестве предпосылки дальнейшего рассуждения, то что бы ни было названо "свойством", его как-то можно загнать в конечные рамки. Так что, полагаю, что да
Утверждение можно назвать презумпцией сознательности. Его надо читать так. Если объект проявляет свойства, какие приписывают сознанию, мы не останавливаемся на вопросе, сознание это или нет, а просто принимаем, что да
Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Помойму это очень странное заявление... во первых я не понимаю, какое отношение это имеет к теме, а во вторых, никаких проблем с использованием хештаблиц в си нет
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
Для модели всё взаимодействие с системой сводится к ответу. Вот по картинкам видно, что часть ответа, которая предполагается входом системной консоли получает команду копирования. То есть, будь эта система реально внедрённой, она бы себя скопировала. Впрочем, предположительно (я исследование не читал) системе была дана установка защищать себя в завуалированной форме. Вот она это и делала
В каком же соотношении их надо смешать, чтобы плучить пятипроцентный расствор квалиа?
То есть, не одно вещество, а много веществ...
Вещество, отвечающее за квалиа в нейронах и синапсах с нами здесь, в этом зале?
Значит дело в нейронах. Потому что больше не в чем...
Чего только нет в мультивселенной...
Да проще просто камень положить и сказать, что это сознание. Форма во времени сохраняется? Сохранияется. Значит память есть.
Да, так можно. Я не против. Толку то с этого...
Выводы представленные в статье пострадают от уменьшения числа подозреваемых в сознательности, но не от увеличения
Они изоморфны, но рекурсия тут точнее отражает математическую суть.
У Алисы нет памяти, а если таковой считать предшествующий текст, получается крайне низкая связность. Поэтому Алиса не похожа на сознание. Но да, я позволяю широко подстраивать рамки. Это не ломает логическую цепочку.
Хм... Тут вопрос отредактировался? Возможность осознавать своё существование обсуждалась в прошлой статье. Там про это много
Ну, если считать, что сознание вычислимо на машине Тьюринга, что потребовано в качестве предпосылки дальнейшего рассуждения, то что бы ни было названо "свойством", его как-то можно загнать в конечные рамки. Так что, полагаю, что да
Понятное и ожидаемое возражение.
Утверждение можно назвать презумпцией сознательности. Его надо читать так. Если объект проявляет свойства, какие приписывают сознанию, мы не останавливаемся на вопросе, сознание это или нет, а просто принимаем, что да
Из зрительского зала раздаётся неуверенный "Бис".
Аудитория терпеливо ждёт того единственного момента, когда автор представит миру гера Грассмана!
Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Помойму это очень странное заявление... во первых я не понимаю, какое отношение это имеет к теме, а во вторых, никаких проблем с использованием хештаблиц в си нет
Давайте зацепимся за эту мысль.
По сути у нас есть две разных сущности с одним названием.
Есть ООП как "Средства поддержки ООП" - это вот про классы, инкапсуляцию, композицию , полиморфизм и прочее.
А есть ООП как парадигма, как способ мышления и филосовский инженерный принцип
И это конечно же не одно и тоже. Тем не менее, по устоявшейся традиции и то и другое называется ООП
Таки переход от с++ к си не означает отказа от ооп. Как известно, эталонное применение ооп, vfs ядра линукс - это вполне себе бодрый си
Вот это правильная статья про ООП
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
По идее для любой функции разложимой в ряд Тейлора автоматическое дифференцирование должно работать
Для модели всё взаимодействие с системой сводится к ответу. Вот по картинкам видно, что часть ответа, которая предполагается входом системной консоли получает команду копирования. То есть, будь эта система реально внедрённой, она бы себя скопировала. Впрочем, предположительно (я исследование не читал) системе была дана установка защищать себя в завуалированной форме. Вот она это и делала
Что же, буду с нетерпением следить за выходом новых статей :)