Настойчиво советую?.. Это вы тут бегаете за мной по разным веткам и инфантильно хамите (а теперь уже и запрашивая код-ревью - про который чуть подробнее напишу, когда будет время, но лестного там будет мало).
Вы утверждаете, что можете найти декомпозицию любой задачи на элементарные операции по 5 строчек кода - ок, ждем вашего решения.
У вас галлюцинации (или хуже), я такого никогда не утверждал и не собирался утверждать. К слову, ещё я не утверждал, что вы утверждали, что любая система должна быть написана одной большой простынёй. Но должен спросить: вы готовы утверждать последнее? И ещё - вы понимаете разницу между реализацией системы и реализацией алгоритма? Архитектурные паттерны полезны в реализации систем. Как молоток полезен в забивании гвоздей. И из того, что молотком нельзя разрезать помидор, не следует, что молоток это вредный или бесполезный инструмент.
Бывает так, что эти длинные линейные портянки - вся или почти вся бизнес-логика (типовой пример)? Или есть архитектура, где эти портянки изолированы в "вычислительном ядре", а остальной код занимается всеми другими типовыми задачами - всевозможными вводами-выводами, реализацией всяких API, интерфейса CLI, графических интерфейсов, сбором данных, построением статистики и чего там ещё бывает в типовых системах?
Могу на очередной лад повторить - инструменты следует применять без фанатизма и по назначению. Конечно, если насильно каждую строчку загонять в функцию, и вдогонку давать этой функции вводящее в заблуждение название, то от этого будет только плохое. Но весь этот холивар тут реально выглядит уже так: "Молоток ударил по пальцу! Молоток (и инструменты вообще) это чистое зло, а те, кто всё это придумал - кретины, предавшие человечество!!11"... :)
Откуда столько агрессии-то? Мартин с Фаулером в детстве конфеты отбирали после школы? Банда четырёх потом отнимала мелочь в тёмном переулке и давала подзатыльники? Как так вышло, что слова и сокращения типа "паттерны" и "SOLID" стали для вас эмоциональными триггерами? Или вы реально замеряли IQ Мартину и он оказался ниже вашего? И даже это не повод говорить об этом публично, но раз уж начали - приведите хоть какие-то доказательства. Пока в ваших сообщениях есть толика трезвости (декомпозицию, как и всё, нужно использовать без фанатизма) и море негативных эмоций с возведением в абсолют.
Предположим, что есть 50 строк кода, которые выполняют 5 семантически изолированных операций. Пусть код этих операций может быть аккуратно вынесен в функции так, что чтение сверху вниз создаёт корректное высокоуровневое понимание того, что делает весь код.
В варианте без такой декомпозиции для получения такого понимания необходимо будет прочесть весь код. Затем, т.к. границы семантической изоляции такого кода не очевидны (пока не запомнишь), его более-менее весь придётся читать каждый раз, когда будет необходимо внести изменение в ту или иную семантически изолированную область.
В варианте с такой декомпозицией можно почитать сверху вниз историю, которую рассказывают названия вызываемых функций вместе с вовлечёнными переменными и аргументами и получить высокоуровневую картину происходящего. Заодно можно зайти внутрь функций посмотреть, есть ли сторонние эффекты (которых, в идеале, быть не должно). Весь код читать нет необходимости даже первый раз. Далее, по мере необходимости читается код тех функций, семантика которых требует изменений. При грамотном именовании часто уже просто по названию понятно, где нужны изменения. Ну и отладку никто не отменял - и трассировка вызовов куда быстрее приведёт к необходимому коду, если он изолирован в функции (без декомпозиции она приведёт к изначальной функции в 50 строк, которые нужно будет почитать более-менее все снова).
Всё это может быть не очень очевидно и чувствительно при, скажем 50-100 строках кода - особенно, если он написан аккуратно и с вниманием к названиям сущностей. Но чем он становится длиннее, тем накладные расходы на перечитывание становятся больше, с ускорением.
Возьмем типовый пример с решением уравнения с несколькими десятками переменных и параметров.
Типовый? Вот прямо вся бизнес-логика состоит из решения вот таких уравнений? Ну, значит вам прямо сильно повезло (или нет) - в моём опыте подобные примеры это особые моменты в кодовой базе, к которым и относятся по особому.
Вы утверждаете, что каждую строчку или несколько строчек решения надо вынести в отдельную функцию с десятками параметров?
Вы читаете мысли? Где я такое утверждал?
Это феерический бред, что очевидно любому, кто хоть раз код писал.
А вы кроме решения уравнений что-то писали? Вообще, приведите конкретный пример, с кодом-портянкой, решающим вот этакое уравнение - посмотрим, можно ли рефакторить или лучше не надо. А пока это сферический конь, не более.
Этого я не утверждал, но было такое впечатление. Значит ошибочное, ещё раз приношу свои извинения. А чего тогда на "коучей" взъелись? У всяких Фаулеров и дядей Бобов, насколько помню, есть предупреждения, что всё хорошо в меру и без фанатизма.
Увы, мы не можем определить, фантазии это у вас или реальность.
И не надо.
Раз проектов своих вы не показываете, видимо, фантазии - вы на это так витиевато намекали?
Я наёмник, мои проекты принадлежат моим нанимателям - конечно, я не буду их показывать посторонним людям. Впрочем конкретно мой код не имеет простыней. Зато всякие легаси, которые тоже надо поддерживать - там много чего можно найти. И десятки тысяч строк в одной функции (или вообще без функции), и тьму глобальных переменных, и сайд эффекты между процессами и т.д. и т.п. Если вы витиевато намекнули, что ничего подобного никогда не видели, то радуйтесь и спите спокойно. :)
Вопрос в определении атомарности. Так-то я согласен, но легко может оказаться, что у трёх разных людей четыре разных понимания атомарности. Один из сотрудников на прошлой работе писал функции в 200+ строк кода, потому что "эта функция выполняет ровно одну задачу - которую выполняет вот весь этот код". Нет, эти функции не были реализациями каких-то сложных алгоритмов, они были сложными как раз для чтения, из-за месива - которое можно было бы крайне легко упростить, дав высокоуровневые отглагольные названия.
Вы там дальше по своим текстам разносите всяких "коучей" типа Фаулера. Дядя Боб у вас, наверное, тоже нехороший человек. Отсюда и напрашивается впечатление, что ваша "атомарность" это просто оправдание своих простыней.
Но если впечатление ложное - прошу прощения, ошибся.
Таких IDE в 2025 не существует.
С удобной навигацией? Это просто смешно.
Но приоткрою вам завесу страшной тайны: если у вас разительно отличается производительность с IDE и без нее, значит вы решаете задачи, в которых не нужно думать.
При чём тут производительность? Вы говорили о каких-то проблемах с переключением контекста. А я о том, что в нормальном современном IDE можно легко переключаться туда и обратно, ставить закладки, делить экран и т.д. и т.п. Если название функции хорошо обозначает суть задачи, которую решает её код (в противном случае её надо переименовывать), то этого достаточно, пока не появляется необходимость править этот самый код. Если постоянно приходится смотреть детали реализации, возвращаясь к вызывающему коду, то с функцией что-то не то - сторонние эффекты, например. Потребность постоянного прыгания туда-сюда это, скорее всего, признак плохого названия или ответственности, которая не вмещается в название. Такое, по-хорошему, надо исправлять.
задачи, с которыми сталкиваюсь я — требуют провести в редакторе максимум 10% времени, остальное — думать и рисовать на бумажке.
Простите, я давно вырос из возраста и ситуации, когда меряются... достижениями. :)
Но в любой ситуации — прыжок по коду (хоть хоткеем, хоть усилием воли) — это потеря контекста, потому что контекст внезапно больше не перед глазами. С этим бессмысленно спорить.
Только в другом сообщении вы себе же противоречите:
Я способен удержать в голове контекст и редко пользуюсь даже сплитом окна в редакторе. Триста мониторов расслабляют и отучают загружать контекст в оперативную память мозга, что приводит к громадному проседанию КПД, когда больше времени тратится на стрельбу глазами туда-сюда вместо обдумывания проблемы.
Так способны удержать контекст, или теряете его? Кстати, а держать контекст перед глазами - это не расслабляет и не отучает "загружать контекст в оперативную память мозга" и дальше по тексту? Почему бы не запомнить весь код проекта наизусть? :)
У кого фантазии, у кого регулярная боевая реальность...
А вот проблема о смене контекста при прыгании туда-обратно - это надуманная проблема. Либо человек не освоил свою среду разработки, как следует, либо под язык, на котором он работает, нет IDE, удобно реализующих навигацию по коду - ну хотя бы переход к декларации и определению символа и обратно.
Соглашусь, что сложный алгоритм - если он более-менее влезает на экран-два - возможно, лучше не делить, если по его коду нет высокоуровневых семантических смен контекста, которые можно изолировать под семантически ясным ярлыком типа названия функции/метода.
Но если такие смены контекста есть, то они есть и без прыжков туда-обратно, и их можно спокойно изолировать за нормальными именами, а детали смотреть по мере надобности. Если делать это без фанатизма, давая адекватные названия и не упарываться, пряча очевидные и наглядные вещи за функциями, то это обычно упрощает код для читающего. А вот парадигма, по которой должна быть одна гигантская простыня на тысячи (или десятки тысяч) строк, а все, кому трудно разобраться - неквалифицированные идиоты, это... Ну если не чистое зло, то точно не добро. :)
На работе уже года два использую ChatGPT - 3-я версия была более-менее бесполезной, но начиная с 4-й пошла реальная экономия времени. Навскидку - быстрый мозговой штурм вместо отвлекания кого-то для роли "резиновой утки", генерация CLI команд и кусков кода. Понятно, что всё надо вычитывать и проверять, но смысл читать определённо есть.
Так вот почему в некоторых легаси-проектах я наблюдаю функции по несколько тысяч строк... А порой просто простыню тысяч на 20 вообще без функций. Оказывается, это чтобы мне разобраться было проще. /s
Кроме научной литературы и словарей смысла читать хоть что-то другое вообще нет.
Если под смыслом действия понимать его целесообразность желаемому результату, то чтение чего угодно не из обозначенного вами множества может быть по-всякому осмысленным. Например, смысл такого чтения может быть отдых.
Хехе, я именно так прочитал заголовок и зашёл посмотреть, чего он такое творит, ещё и незаметно. Дочитал до английского текста про лес, тут же стал засыпать (ну хотя бы sci-fi horror, что ли, типа сцены в вертолёте из The Thing 2011) и пошёл читать комментарии. :)
Я же нашёл способ создать на его базе осознанный ИИ
Ага. Мне просто интересно - сколько лет вы занимаетесь проблематикой сознания? В частности, что вы понимаете под сознанием? Чем конкретно осознанная система отличается от неосознанной?
Если что, я уже знаю ответ, когда в некоторой неевклидовой геометрии квадрат равен кругу. Поэтому я специально озвучил условия конкретно. В общем, суть в том, что невозможна экземплификация объекта, свойства которого противоречат друг другу. Это элементарная логика. Те, кто считает, что может преодолеть этот "барьер" невозможности - просто недостаточно знакомы с тем, как работает логика.
Объективно-дофига-чего-давать можно и без сознания. Я использую ChatGPT o1 на работе каждый день, и он мне экономит массу времени. Это не значит, что у него есть сознание.
Реальное сознание нам известно из собственного субъективного опыта - у кого оно реально есть, конечно. Другого нам не известно. Проблема строгого доказательства наличия сознания не у себя упирается в проблему доказательства наличия не у себя любого квалитативного опыта вообще. Слыхали про проблему инвертированного цвета?
Свойство квалитативного опыта (через который мы знаем о собственном сознании) - принадлежать субъекту. Достоверно знать опыт другого субъекта - как он есть у этого субъекта - значит быть этим другим субъектом во всей его полноте. Что подразумевает незнание, что это опыт другого субъекта. Любой вариант частичного опыта другого субъекта сталкивается с проблемой идентификации - любой испытываемый мной опыт это в первую очередь мой опыт. Нет возможности "вылезти из себя" и "посмотреть", совпадает ли этот частичный опыт с реальным опытом другого субъекта - потому что такое тоже будет в первую очередь моим опытом.
Вообще, рекомендую ознакомиться хотя бы с этим материалом. Лучшие умы тысячи лет бьются над проблемой сознания по сей день. Даже если вы уникальный гений всех времён и народов, вряд ли вам кто-то поверит, если вы не будете аргументировать свою позицию чем-то существенно серьёзнее жизнерадостного оптимизма. :)
Как человек ставит границы своего восприятия - так и живёт.
Можно подумать, вы по желанию умеете в левитацию и дышать в вакууме. :) Думать, что всё возможно - это магическое мышление. Не все кодируемые свойства экземплифицируемы. Тот же круглый квадрат. Возьмите исправные обычные предметы, скажем, конца 20-го века: письменный стол с ровной столешницей, ровный лист бумаги формата А4, карандаш, циркуль, транспортир, линейку - и никогда, ни при каком оптимизме и достижениях науки у вас не получится с помощью этих инструментов начертить на ровно лежащем на столе листе бумаги геометрическую фигуру, одновременно соответствующую кругу и квадрату из евклидовой геометрии.
Конечно, если считать что-то принципиально невозможным, любое доказательство обратного аксиоматически будет отвергаться ещё до этапа знакомства с ним.
Настойчиво советую?.. Это вы тут бегаете за мной по разным веткам и инфантильно хамите (а теперь уже и запрашивая код-ревью - про который чуть подробнее напишу, когда будет время, но лестного там будет мало).
У вас галлюцинации (или хуже), я такого никогда не утверждал и не собирался утверждать. К слову, ещё я не утверждал, что вы утверждали, что любая система должна быть написана одной большой простынёй. Но должен спросить: вы готовы утверждать последнее? И ещё - вы понимаете разницу между реализацией системы и реализацией алгоритма? Архитектурные паттерны полезны в реализации систем. Как молоток полезен в забивании гвоздей. И из того, что молотком нельзя разрезать помидор, не следует, что молоток это вредный или бесполезный инструмент.
Бывает так, что эти длинные линейные портянки - вся или почти вся бизнес-логика (типовой пример)? Или есть архитектура, где эти портянки изолированы в "вычислительном ядре", а остальной код занимается всеми другими типовыми задачами - всевозможными вводами-выводами, реализацией всяких API, интерфейса CLI, графических интерфейсов, сбором данных, построением статистики и чего там ещё бывает в типовых системах?
Могу на очередной лад повторить - инструменты следует применять без фанатизма и по назначению. Конечно, если насильно каждую строчку загонять в функцию, и вдогонку давать этой функции вводящее в заблуждение название, то от этого будет только плохое. Но весь этот холивар тут реально выглядит уже так: "Молоток ударил по пальцу! Молоток (и инструменты вообще) это чистое зло, а те, кто всё это придумал - кретины, предавшие человечество!!11"... :)
Откуда столько агрессии-то? Мартин с Фаулером в детстве конфеты отбирали после школы? Банда четырёх потом отнимала мелочь в тёмном переулке и давала подзатыльники? Как так вышло, что слова и сокращения типа "паттерны" и "SOLID" стали для вас эмоциональными триггерами? Или вы реально замеряли IQ Мартину и он оказался ниже вашего? И даже это не повод говорить об этом публично, но раз уж начали - приведите хоть какие-то доказательства. Пока в ваших сообщениях есть толика трезвости (декомпозицию, как и всё, нужно использовать без фанатизма) и море негативных эмоций с возведением в абсолют.
Предположим, что есть 50 строк кода, которые выполняют 5 семантически изолированных операций. Пусть код этих операций может быть аккуратно вынесен в функции так, что чтение сверху вниз создаёт корректное высокоуровневое понимание того, что делает весь код.
В варианте без такой декомпозиции для получения такого понимания необходимо будет прочесть весь код. Затем, т.к. границы семантической изоляции такого кода не очевидны (пока не запомнишь), его более-менее весь придётся читать каждый раз, когда будет необходимо внести изменение в ту или иную семантически изолированную область.
В варианте с такой декомпозицией можно почитать сверху вниз историю, которую рассказывают названия вызываемых функций вместе с вовлечёнными переменными и аргументами и получить высокоуровневую картину происходящего. Заодно можно зайти внутрь функций посмотреть, есть ли сторонние эффекты (которых, в идеале, быть не должно). Весь код читать нет необходимости даже первый раз. Далее, по мере необходимости читается код тех функций, семантика которых требует изменений. При грамотном именовании часто уже просто по названию понятно, где нужны изменения. Ну и отладку никто не отменял - и трассировка вызовов куда быстрее приведёт к необходимому коду, если он изолирован в функции (без декомпозиции она приведёт к изначальной функции в 50 строк, которые нужно будет почитать более-менее все снова).
Всё это может быть не очень очевидно и чувствительно при, скажем 50-100 строках кода - особенно, если он написан аккуратно и с вниманием к названиям сущностей. Но чем он становится длиннее, тем накладные расходы на перечитывание становятся больше, с ускорением.
Типовый? Вот прямо вся бизнес-логика состоит из решения вот таких уравнений? Ну, значит вам прямо сильно повезло (или нет) - в моём опыте подобные примеры это особые моменты в кодовой базе, к которым и относятся по особому.
Вы читаете мысли? Где я такое утверждал?
А вы кроме решения уравнений что-то писали? Вообще, приведите конкретный пример, с кодом-портянкой, решающим вот этакое уравнение - посмотрим, можно ли рефакторить или лучше не надо. А пока это сферический конь, не более.
Этого я не утверждал, но было такое впечатление. Значит ошибочное, ещё раз приношу свои извинения. А чего тогда на "коучей" взъелись? У всяких Фаулеров и дядей Бобов, насколько помню, есть предупреждения, что всё хорошо в меру и без фанатизма.
И не надо.
Я наёмник, мои проекты принадлежат моим нанимателям - конечно, я не буду их показывать посторонним людям. Впрочем конкретно мой код не имеет простыней. Зато всякие легаси, которые тоже надо поддерживать - там много чего можно найти. И десятки тысяч строк в одной функции (или вообще без функции), и тьму глобальных переменных, и сайд эффекты между процессами и т.д. и т.п. Если вы витиевато намекнули, что ничего подобного никогда не видели, то радуйтесь и спите спокойно. :)
Вопрос в определении атомарности. Так-то я согласен, но легко может оказаться, что у трёх разных людей четыре разных понимания атомарности. Один из сотрудников на прошлой работе писал функции в 200+ строк кода, потому что "эта функция выполняет ровно одну задачу - которую выполняет вот весь этот код". Нет, эти функции не были реализациями каких-то сложных алгоритмов, они были сложными как раз для чтения, из-за месива - которое можно было бы крайне легко упростить, дав высокоуровневые отглагольные названия.
Вы там дальше по своим текстам разносите всяких "коучей" типа Фаулера. Дядя Боб у вас, наверное, тоже нехороший человек. Отсюда и напрашивается впечатление, что ваша "атомарность" это просто оправдание своих простыней.
Но если впечатление ложное - прошу прощения, ошибся.
С удобной навигацией? Это просто смешно.
При чём тут производительность? Вы говорили о каких-то проблемах с переключением контекста. А я о том, что в нормальном современном IDE можно легко переключаться туда и обратно, ставить закладки, делить экран и т.д. и т.п. Если название функции хорошо обозначает суть задачи, которую решает её код (в противном случае её надо переименовывать), то этого достаточно, пока не появляется необходимость править этот самый код. Если постоянно приходится смотреть детали реализации, возвращаясь к вызывающему коду, то с функцией что-то не то - сторонние эффекты, например. Потребность постоянного прыгания туда-сюда это, скорее всего, признак плохого названия или ответственности, которая не вмещается в название. Такое, по-хорошему, надо исправлять.
Простите, я давно вырос из возраста и ситуации, когда меряются... достижениями. :)
Только в другом сообщении вы себе же противоречите:
Так способны удержать контекст, или теряете его? Кстати, а держать контекст перед глазами - это не расслабляет и не отучает "загружать контекст в оперативную память мозга" и дальше по тексту? Почему бы не запомнить весь код проекта наизусть? :)
У кого фантазии, у кого регулярная боевая реальность...
А вот проблема о смене контекста при прыгании туда-обратно - это надуманная проблема. Либо человек не освоил свою среду разработки, как следует, либо под язык, на котором он работает, нет IDE, удобно реализующих навигацию по коду - ну хотя бы переход к декларации и определению символа и обратно.
Соглашусь, что сложный алгоритм - если он более-менее влезает на экран-два - возможно, лучше не делить, если по его коду нет высокоуровневых семантических смен контекста, которые можно изолировать под семантически ясным ярлыком типа названия функции/метода.
Но если такие смены контекста есть, то они есть и без прыжков туда-обратно, и их можно спокойно изолировать за нормальными именами, а детали смотреть по мере надобности. Если делать это без фанатизма, давая адекватные названия и не упарываться, пряча очевидные и наглядные вещи за функциями, то это обычно упрощает код для читающего. А вот парадигма, по которой должна быть одна гигантская простыня на тысячи (или десятки тысяч) строк, а все, кому трудно разобраться - неквалифицированные идиоты, это... Ну если не чистое зло, то точно не добро. :)
На работе уже года два использую ChatGPT - 3-я версия была более-менее бесполезной, но начиная с 4-й пошла реальная экономия времени. Навскидку - быстрый мозговой штурм вместо отвлекания кого-то для роли "резиновой утки", генерация CLI команд и кусков кода. Понятно, что всё надо вычитывать и проверять, но смысл читать определённо есть.
Так вот почему в некоторых легаси-проектах я наблюдаю функции по несколько тысяч строк... А порой просто простыню тысяч на 20 вообще без функций. Оказывается, это чтобы мне разобраться было проще. /s
Если под смыслом действия понимать его целесообразность желаемому результату, то чтение чего угодно не из обозначенного вами множества может быть по-всякому осмысленным. Например, смысл такого чтения может быть отдых.
Хехе, я именно так прочитал заголовок и зашёл посмотреть, чего он такое творит, ещё и незаметно. Дочитал до английского текста про лес, тут же стал засыпать (ну хотя бы sci-fi horror, что ли, типа сцены в вертолёте из The Thing 2011) и пошёл читать комментарии. :)
Желание получить Х порождает (при отсутствии сопротивления) намерение сделать У, чтобы получить Х.
Недоказано.
Перевод: "я не понимаю природу невозможности и почему математика эффективна в науках, а логика в математике".
Кстати, вечный двигатель вы уже сделали? Жду статью об этом. А также статью с чертежом евклидового круглого квадрата.
Ага. Мне просто интересно - сколько лет вы занимаетесь проблематикой сознания? В частности, что вы понимаете под сознанием? Чем конкретно осознанная система отличается от неосознанной?
Если что, я уже знаю ответ, когда в некоторой неевклидовой геометрии квадрат равен кругу. Поэтому я специально озвучил условия конкретно. В общем, суть в том, что невозможна экземплификация объекта, свойства которого противоречат друг другу. Это элементарная логика. Те, кто считает, что может преодолеть этот "барьер" невозможности - просто недостаточно знакомы с тем, как работает логика.
Объективно-дофига-чего-давать можно и без сознания. Я использую ChatGPT o1 на работе каждый день, и он мне экономит массу времени. Это не значит, что у него есть сознание.
Реальное сознание нам известно из собственного субъективного опыта - у кого оно реально есть, конечно. Другого нам не известно. Проблема строгого доказательства наличия сознания не у себя упирается в проблему доказательства наличия не у себя любого квалитативного опыта вообще. Слыхали про проблему инвертированного цвета?
Свойство квалитативного опыта (через который мы знаем о собственном сознании) - принадлежать субъекту. Достоверно знать опыт другого субъекта - как он есть у этого субъекта - значит быть этим другим субъектом во всей его полноте. Что подразумевает незнание, что это опыт другого субъекта. Любой вариант частичного опыта другого субъекта сталкивается с проблемой идентификации - любой испытываемый мной опыт это в первую очередь мой опыт. Нет возможности "вылезти из себя" и "посмотреть", совпадает ли этот частичный опыт с реальным опытом другого субъекта - потому что такое тоже будет в первую очередь моим опытом.
Вообще, рекомендую ознакомиться хотя бы с этим материалом. Лучшие умы тысячи лет бьются над проблемой сознания по сей день. Даже если вы уникальный гений всех времён и народов, вряд ли вам кто-то поверит, если вы не будете аргументировать свою позицию чем-то существенно серьёзнее жизнерадостного оптимизма. :)
Можно подумать, вы по желанию умеете в левитацию и дышать в вакууме. :) Думать, что всё возможно - это магическое мышление. Не все кодируемые свойства экземплифицируемы. Тот же круглый квадрат. Возьмите исправные обычные предметы, скажем, конца 20-го века: письменный стол с ровной столешницей, ровный лист бумаги формата А4, карандаш, циркуль, транспортир, линейку - и никогда, ни при каком оптимизме и достижениях науки у вас не получится с помощью этих инструментов начертить на ровно лежащем на столе листе бумаги геометрическую фигуру, одновременно соответствующую кругу и квадрату из евклидовой геометрии.
Так вы не привели никакого доказательства.