Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Помойму это очень странное заявление... во первых я не понимаю, какое отношение это имеет к теме, а во вторых, никаких проблем с использованием хештаблиц в си нет
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
Для модели всё взаимодействие с системой сводится к ответу. Вот по картинкам видно, что часть ответа, которая предполагается входом системной консоли получает команду копирования. То есть, будь эта система реально внедрённой, она бы себя скопировала. Впрочем, предположительно (я исследование не читал) системе была дана установка защищать себя в завуалированной форме. Вот она это и делала
А вот вопрос по теме. Он несколько сумбурный, но давно меня беспокоит:
Возможно ли, что уравнение x*x + 1 = 0 разрешимо в каких-то иных отличных от матриц структурах несводимых к линейным преобразованиям или "матричность", что бы это ни значило, каким-то образом зашита в аксиоматике сложения и умножения?
Это некоторое расширение уже довольно привычной системы с тремя эллиптическими и одной дуальной единицей, которыми оперирует проективная геометрия и проективная геометрическая алгебра, при работе с линейными подпространствами аля плоскость, прямая, точка. Но тут за счёт добавления ещё одной единицы с довольно специфическим законом умножения оно каким-то образом получает возможность работать со сферами и кругами и я никак не могу ухватить в чём глубинный смысл этой системы
Материал должен называться "Как пройти собеседование у ИМЯ". Есть хорошие пункты. Есть хорошие пункты, которые надо выбить в скрижалях. А есть крайне странные тейки, после которых хочется спросить "Что курил автор?"
Понятия не имею, что это за сайт, но нет... теорема об одном критерии существует в теории оптимизации, хотя она довольно очевидна и не то чтобы требует доказательств. Её можно найти в книжках по оптимизации и её приложениях, например в теории оптимального управления. Для решения проблемы принципиальной однокритериальности существует раздел многокритериальной оптимизации, область изучения которого по сути сводится к вопросу, как из многих критериев получить один с наименьшими потерями для каждого из исходных критериев
Очень верно сказано про возможность оптимизации отдельных систем в без какого либо ECS.
Вообще, сама идея ecs нарушает заповедь о преждевременной оптимизации.
Нарушеним этой заповеди страдают в основном начинающие программисты и по этому поводу можно сказать пару слов, ежели вдруг кто из таковых будет это читать. Выбор инструмента позволяющего сразу писать быстродействующий код - это очень соблазнительная идея, но благими намерениями, как известно выстелена дорога в ад. В геймдеве укоренилось особое значение слова оптимизация. Игровой разработчик и игроки, а следом за ними и разработчики прочих сфер, бывшие когда-то игроками, говорят "оптимизация", понимая оптимизацию по быстродействию и забывают о том, что оптимизация бывает и по другим параметрам. Конечно, разработка програмного обеспечения - довольно молодая отрасль, но если до чего и допёрло человечество за время её развития, так это до того, что код в первую очередь должен быть не быстрым, а понятным и обслуживаемым, и именно по этому параметру он должен оптимизироваться. Существует целая математическая теорема, согласно которой система в общем случае может быть оптимизирована только по одному параметру и когда мы выбираем быстродействие, мы сразу же задвигаем удобство работы с кодом в дальний угол. Худшее, что может сделать разработчик для того, чтобы сделать хороший продукт - возненавидеть собственный код в процессе работы над ним.
Если код будет напоминать не кусок госсэ, а попендикулярное произведение искусства, в момент когда настанет необходимость увеличивать быстродействие, это можно будет сделать легко и уместно. В плохом же коде таковые попытки могут привести к обвалу всего здания
… такое себе… планеты однообразные, активности однообразные, в перемещение между планетами bethesda не потянула, атмосферы космоса нет, атмосферы путешествия нет, npc на улицах нарисованы так, что десять лет назад такое стыдно было людям показать… лучше не связывайтесь.
Из зрительского зала раздаётся неуверенный "Бис".
Аудитория терпеливо ждёт того единственного момента, когда автор представит миру гера Грассмана!
Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Помойму это очень странное заявление... во первых я не понимаю, какое отношение это имеет к теме, а во вторых, никаких проблем с использованием хештаблиц в си нет
Давайте зацепимся за эту мысль.
По сути у нас есть две разных сущности с одним названием.
Есть ООП как "Средства поддержки ООП" - это вот про классы, инкапсуляцию, композицию , полиморфизм и прочее.
А есть ООП как парадигма, как способ мышления и филосовский инженерный принцип
И это конечно же не одно и тоже. Тем не менее, по устоявшейся традиции и то и другое называется ООП
Таки переход от с++ к си не означает отказа от ооп. Как известно, эталонное применение ооп, vfs ядра линукс - это вполне себе бодрый си
Вот это правильная статья про ООП
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
По идее для любой функции разложимой в ряд Тейлора автоматическое дифференцирование должно работать
Для модели всё взаимодействие с системой сводится к ответу. Вот по картинкам видно, что часть ответа, которая предполагается входом системной консоли получает команду копирования. То есть, будь эта система реально внедрённой, она бы себя скопировала. Впрочем, предположительно (я исследование не читал) системе была дана установка защищать себя в завуалированной форме. Вот она это и делала
Что же, буду с нетерпением следить за выходом новых статей :)
А вот вопрос по теме. Он несколько сумбурный, но давно меня беспокоит:
Возможно ли, что уравнение x*x + 1 = 0 разрешимо в каких-то иных отличных от матриц структурах несводимых к линейным преобразованиям или "матричность", что бы это ни значило, каким-то образом зашита в аксиоматике сложения и умножения?
Я, как говорится, просто оставлю это здесь.
Мне очень интересно, как работает вот эта числовая система:
https://conformalgeometricalgebra.org/wiki/index.php?title=Main_Page
Это некоторое расширение уже довольно привычной системы с тремя эллиптическими и одной дуальной единицей, которыми оперирует проективная геометрия и проективная геометрическая алгебра, при работе с линейными подпространствами аля плоскость, прямая, точка. Но тут за счёт добавления ещё одной единицы с довольно специфическим законом умножения оно каким-то образом получает возможность работать со сферами и кругами и я никак не могу ухватить в чём глубинный смысл этой системы
Материал должен называться "Как пройти собеседование у ИМЯ". Есть хорошие пункты. Есть хорошие пункты, которые надо выбить в скрижалях. А есть крайне странные тейки, после которых хочется спросить "Что курил автор?"
Ох... обязательно прочитаю позже :). Выглядит очень вкусно. Спасибо
Понятия не имею, что это за сайт, но нет... теорема об одном критерии существует в теории оптимизации, хотя она довольно очевидна и не то чтобы требует доказательств. Её можно найти в книжках по оптимизации и её приложениях, например в теории оптимального управления. Для решения проблемы принципиальной однокритериальности существует раздел многокритериальной оптимизации, область изучения которого по сути сводится к вопросу, как из многих критериев получить один с наименьшими потерями для каждого из исходных критериев
Очень верно сказано про возможность оптимизации отдельных систем в без какого либо ECS.
Вообще, сама идея ecs нарушает заповедь о преждевременной оптимизации.
Нарушеним этой заповеди страдают в основном начинающие программисты и по этому поводу можно сказать пару слов, ежели вдруг кто из таковых будет это читать. Выбор инструмента позволяющего сразу писать быстродействующий код - это очень соблазнительная идея, но благими намерениями, как известно выстелена дорога в ад. В геймдеве укоренилось особое значение слова оптимизация. Игровой разработчик и игроки, а следом за ними и разработчики прочих сфер, бывшие когда-то игроками, говорят "оптимизация", понимая оптимизацию по быстродействию и забывают о том, что оптимизация бывает и по другим параметрам. Конечно, разработка програмного обеспечения - довольно молодая отрасль, но если до чего и допёрло человечество за время её развития, так это до того, что код в первую очередь должен быть не быстрым, а понятным и обслуживаемым, и именно по этому параметру он должен оптимизироваться. Существует целая математическая теорема, согласно которой система в общем случае может быть оптимизирована только по одному параметру и когда мы выбираем быстродействие, мы сразу же задвигаем удобство работы с кодом в дальний угол. Худшее, что может сделать разработчик для того, чтобы сделать хороший продукт - возненавидеть собственный код в процессе работы над ним.
Если код будет напоминать не кусок госсэ, а попендикулярное произведение искусства, в момент когда настанет необходимость увеличивать быстродействие, это можно будет сделать легко и уместно. В плохом же коде таковые попытки могут привести к обвалу всего здания
Статья отражает заголовок с точностью до наоборот
Неа... это просто повод породить новые мифы, ибо никто не увидит этот телескоп
… такое себе… планеты однообразные, активности однообразные, в перемещение между планетами bethesda не потянула, атмосферы космоса нет, атмосферы путешествия нет, npc на улицах нарисованы так, что десять лет назад такое стыдно было людям показать… лучше не связывайтесь.
Проективная геометрическая алгебра, пространство клиффорда cl301.