Только они позволяют убедиться, что мы работаем над пониманием правильных вещей.
Я тут как раз этими формальными доказательствами занимаюсь, и, короче, формулировки теорем уже приходилось несколько раз уточнять, а то иначе выяснялось, что они неверны.
Я не против автоматизированных доказательств и согласен с тем, что они полезны. Я против идеи о том, что даже если мы создадим программу, которая будет автоматически доказывать теоремы, это принесет столь существенную пользу. Ну получим мы например ответ, что Гипотеза Римана верна. Но если доказательство будет содержать тысячи или миллионы строк и в его невозможно будет понять, то что это нам даст?
Если переполнение не приводит к UB, то сложение с переполнением тоже ассоциативно.
Простите, это как? Если у вас (a + b) + c != a + (b + c), то ассоциативность нарушена.
Я с вами абсолютно согласен. Около года назад сам заинтересовался историей математики и решил разобраться с Теоремой Абеля-Руффини. До этого математикой особо не интересовался, а мои познания ограничивались школьной арифметикой, алгеброй и базовыми вещами из матанализа и линейной алгебры. Но к тому времени я уже программировал более 6 лет и программирование изучал самостоятельно. Честно сказать, в процессе изучения абстрактной алгебры у меня сложилось устойчивое убеждение, что подавляющее большинство преподавателей и лекторов сами плохо понимают то, о чем говорят, а при просьбах прояснения определенных моментов, начинают прятаться за формулировками или просто кидаются фразами - "читайте учебник X, там все написано". Если человек просто не в состоянии объяснить тему не прибегая к формализму из учебника, то это может являться высоким показателем того, что он не понимает о чем говорит.
По поводу статьи, то я склоняюсь к мнению определенных математиков, которые считают, что в чистой математике главным является не доказательство, а понимание. И доказательство, это лишь средство, а не цель. И чем больше мы имеем разных доказательств одного и того-же факта/теоремы, тем лучше и шире наше понимание. А автоматизированные формальные доказательства во многом походят на ответ 42.
Как мне кажется, то математические доказательства имеют не столь большое применение для доказательства корректности прикладных программ, так как даже на базовых примерах можно увидеть, что например в математике сложение целых чисел всегда ассоциативно, а в реальных программах нет, из-за наличия переполнения.
Как должно быть я не знаю, но может быть по разному.
Мир откажется от налички, но лично для вас каждый магазин должен будет держать кассу и размен?
Если большинство выбрало определенные правила взаимодействия в обществе, на меньшинство никто не будет смотреть.
Я думаю, что тут большой вопрос о том действительно ли большинство выбрало, а не ему навязали, а потом обратного пути уже нет, так как все на этом завязано.
Вообще тема выбор большинства, часто страдает от двойных стандартов - когда нужно говорится, что "большинство выбрало" и по-другому нельзя, а когда не нужно, то большинство - бараны и ничего не понимают, а просвещенная элита им расскажет как нужно.
К сожалению все не так просто и с этими другими приходится постоянно коммуницировать. А главная проблема в том, что в последние 2 года вообще стало модным в любой непонятной ситуации быстро примерять на других "фольгированные шапочки".
Я до сих пор не могу понять, насколько это все является просто пиар ходом и попыткой отвести внимание от скандалов, а насколько реально поехавшей кукухой Марка и ему подобных, возомнивших себя богами и решившими, что знают, какое будущее нам всем нужно. Как он там говорит - "This is the future we want". Меня бы это мало беспокоило, но нынешняя тенденция сводится к попытке загнать всех в какой-то виртуальный мир, а когда ты говоришь, что у тебя нет профайла в соцсетях, то на тебя уже начинают смотреть с подозрением, как на повернутого луддита. Все внедрения технологий начинаются с фраз - "не хочешь, не используй", а заканчиваются тем, что ты вынужден их использовать, даже если не хочешь.
Но в этой статье я хотел посеять зерно сомнения в том, а столько ли пользы приносит эта система, сколько она вносит негатива?
Как мне кажется, для большинства нормальных руководителей очевидно, что введения всяких явных KPI только ухудшает ситуацию. Это же подобие Принципа Гудхарта. Люди не такие тупые, как о них думают разные "эффективные менеджеры" :)
Логика у человека простая: языки, на первый взгляд, довольно близкие и почти обратно-совместимые, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.
Мне кажется, что такая логика может встречаться только у совсем уж новичков и я сомневаюсь, что хоть кто-то из более-менее опытных программистов на C может так думать или не знать про кардинальные различия между данными языками. Из перечисленного вами списка, многое может не использоваться намеренно, а не потому, что об этом не знают.
Вот я честно несколько раз пытался читать статью, но так и не смог понять, какую мысль хотел донести автор. Получилась какая-то смесь из эволюционной биологии, светского гуманизма, коммунизма (в понимании автора) и перехода к трансгуманизму. Автор пытается рассказывать о естественном процессе снижения насилия и эволюции морали, гуманизма, как будто опыта ХХ века не было. Вспомните, что еще совсем недавно, просвещенные европейцы, уничтожали друг друга в двух мировых войнах, а люди одной нации, считавшей себя самой культурной и просвещенной поставили уничтожение миллионов на поток. Я думаю, что если бы большинству людей в самом начале 20-го века сказали, что их ждет впереди, они бы посчитали это бредом сумасшедшего. И с чего вы взяли, что завтра все это не может повториться в еще более ужасных формах, а все рассказы о триумфе гуманизма, это не глупая иллюзия?
В целом статья хорошая и я согласен практически со всем изложенным.
Но к сожалению, данные советы мало помогут тому, кто не имеет подобного опыта. Чтобы делать обобщения нужно для начала иметь "то", что обобщать, и это главное, что есть у автора. А для человека, который не прошел подобного пути, эти 20 пунктов будут просто набором красивых фраз, так как не имеют под собой основы.
Вообщем, как и в геометрии, здесь "царских" путей нет.
Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101».
Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.
Увидев заголовок и данное описание, я решил, что тут будет доступно рассказано про внутреннее устройство Kubernetes, но доступность материала превзошла все мои ожидания. Я узнал, что оказывается: планировщик - планирует, контроллер - контролирует, а прокси - проксирует и балансирует.
Но процесс познания далек от завершения — ещё необходимо освоить множество важных понятий.
Это обнадеживает.
P.S. Я понимаю, что это перевод и к переводчику у меня никаких претензий нет.
"Я изобрету теперь целую социальную систему, и - ты не поверишь - как это легко! Стоит только уединиться куда-нибудь подальше в угол или хоть попасть в крокодила, закрыть глаза, и тотчас же изобретешь целый рай для всего человечества." (c)
Многих авторов опенсорс проектов вполне можно понять, если встать на их место. Когда человек действительно занимается проектом, обдумывает его развитие и у него сформировано определенное видение развития, а конкретнее - как, и что данный софт должен делать, и самое главное, чего он не должен делать. И когда ему приходится постоянно отбиваться от всяких "контрибьютеров", которые вообще не разобравшись с проектом лезут со своими PR "новой модной фичи", и которым нужно каждый раз объяснять, почему их "улучшение" не будет принято, то после определенного момента, этих авторов это все задалбывает и они без объяснений начинают закрывать подобные PR. А дальше идут обиды, что автор токсичный мудак и вообще не достоин находится в нашем комьюнити (вспоминается автор Actix). Я сам наблюдал такую трансформацию несколько раз.
Меня тоже знакомые и родственники часто спрашивали "Посоветуй на какие курсы пойти". Я сам на курсы не ходил и учился по разным видео курсам на youtube. До этого правда у меня была техническая специальность (слесарь КИПиА) и я почти 5 лет катался по области и ставил системы автоматики на ГРС, а к электронике у меня с детства интерес. И я согласен с тем, что для работы программистом у тебя должно быть в первую очередь желание и интерес к специальности, а не материальная составляющая.
Но, в большинстве курсов "Стань разработчиком Х за 3 месяца с зарплатой в 2000$" меня напрягает именно морально-этическая сторона вопроса. То есть, люди их создающие и продвигающие, хорошо понимают, что это практически невозможно и на лицо откровенное мошенничество и введение людей в заблуждение. Чем они кардинально отличаются от всяких лохотронов или казино, мне не понятно. Можно пойти дальше и сделать объявление "Выучи PHP и заработай 100 миллиардов" (у Цукерберга же получилось).
Да, я могу согласиться с этим описанием, но тут, как мне кажется, мы уже пытаемся смоделировать "то как мы думаем, о том как мы думаем". То есть, мы не знаем как на самом деле мозг представляет объекты и концепции, и как на самом деле происходит наше мышление, а введение понятия "концепции" и абстракции, тут уже играет роль нашего объяснения нашего же процесса мышления. Я не против такого подхода, но я не уверен, что он дает преимущества.
Да, это интересные вопросы и мне эта тема близка, так как сам много думал о том, как правильно переносить и моделировать объекты и концепции реального мира. Выскажу буквально последнюю мысль, по поводу представленной проблемы - у вас при описании объекта комнаты, помимо описания ее выходов, требовалось указание того, куда эти выходы ведут. Если мы посмотрим на это с "точки зрения" реальных объектов, то комната не должна "знать", какая комната находится на противоположной стороне "выхода/прохода", она "знает" только о своих "выходах". Из-за этого возникает рекурсивная зависимость при инициализации объектов. По моему мнению, здесь как раз и заключается ранее указанная мною проблема - что мы пытаемся моделировать не физические объекты, а наши представления о физических объектах. Я не думаю, что мы можем одномоментно держать в голове полную модель даже для такой маленькой задачи, а каждый раз рассматриваем лишь ее часть (отделые комнаты/выходы). Из-за этого и могут случаться такие вещи.
Ладно, заканчиваю тут свои трактаты, а то я слишком много пишу.
В дополнение - на мой взгляд, здесь проблема именно в реализации вашей модели. То есть необходимости в введении абстракции в виде класса _RoomConcept на самом деле никакой нет. Если бы вы, как и хотели, в начале создали все экземпляры комнат, а потом связали их, то все бы получилось и без лишней прослойки абстракции.
Поправьте меня, если я что-то упускаю, но в вашем примере, вы пришли к рекурсивной зависимости потому, что пытались запрограммировать иерархическую структуру, хотя на словах (и в мыслях) представляли плоскую.
То есть в соответствии с данным кодом, получается что bedroom, который в Exit("S"), это не тот bedroom, который вы пытаетесь инициализировать. Как будто bedroom содержит сам себя, а не ссылку на себя. Что и приводит к противоречию.
Я не говорил о том, что какое-то из решений не приведет к проблемам. В данном случае, я хотел обратить внимание на описанную автором проблему возможности соответствия реальным физическим объектам. Мне кажется, что наша модель физического объекта сильно зависит от восприятия. И это уже начинает переходить в "философскую" плоскость.
Вот например - у нас есть физическая комната с двумя дверьми на противоположных сторонах. Мы берем и строим по середине комнаты перегородку. Теперь вопрос - у нас стало две комнаты или одна комната с перегородкой? То есть физически это одно и тоже, но когда мы собираемся моделировать это в виде объектов, то в зависимости от точки зрения, у нас получатся разные модели и код. То есть по моему мнению, никакого однозначного соответствия между физическими объектами и программными объектами быть не может. Но возможно я что-то упускаю.
Я не против автоматизированных доказательств и согласен с тем, что они полезны. Я против идеи о том, что даже если мы создадим программу, которая будет автоматически доказывать теоремы, это принесет столь существенную пользу. Ну получим мы например ответ, что Гипотеза Римана верна. Но если доказательство будет содержать тысячи или миллионы строк и в его невозможно будет понять, то что это нам даст?
Простите, это как? Если у вас (a + b) + c != a + (b + c), то ассоциативность нарушена.
Я с вами абсолютно согласен. Около года назад сам заинтересовался историей математики и решил разобраться с Теоремой Абеля-Руффини. До этого математикой особо не интересовался, а мои познания ограничивались школьной арифметикой, алгеброй и базовыми вещами из матанализа и линейной алгебры. Но к тому времени я уже программировал более 6 лет и программирование изучал самостоятельно. Честно сказать, в процессе изучения абстрактной алгебры у меня сложилось устойчивое убеждение, что подавляющее большинство преподавателей и лекторов сами плохо понимают то, о чем говорят, а при просьбах прояснения определенных моментов, начинают прятаться за формулировками или просто кидаются фразами - "читайте учебник X, там все написано". Если человек просто не в состоянии объяснить тему не прибегая к формализму из учебника, то это может являться высоким показателем того, что он не понимает о чем говорит.
По поводу статьи, то я склоняюсь к мнению определенных математиков, которые считают, что в чистой математике главным является не доказательство, а понимание. И доказательство, это лишь средство, а не цель. И чем больше мы имеем разных доказательств одного и того-же факта/теоремы, тем лучше и шире наше понимание. А автоматизированные формальные доказательства во многом походят на ответ 42.
Как мне кажется, то математические доказательства имеют не столь большое применение для доказательства корректности прикладных программ, так как даже на базовых примерах можно увидеть, что например в математике сложение целых чисел всегда ассоциативно, а в реальных программах нет, из-за наличия переполнения.
Можно еще одно для полноты эксперимента - Кен Томпсон, возраст 78. Правда сомневаюсь, что HR оценят.
Как должно быть я не знаю, но может быть по разному.
Я думаю, что тут большой вопрос о том действительно ли большинство выбрало, а не ему навязали, а потом обратного пути уже нет, так как все на этом завязано.
Вообще тема выбор большинства, часто страдает от двойных стандартов - когда нужно говорится, что "большинство выбрало" и по-другому нельзя, а когда не нужно, то большинство - бараны и ничего не понимают, а просвещенная элита им расскажет как нужно.
К сожалению все не так просто и с этими другими приходится постоянно коммуницировать. А главная проблема в том, что в последние 2 года вообще стало модным в любой непонятной ситуации быстро примерять на других "фольгированные шапочки".
Я до сих пор не могу понять, насколько это все является просто пиар ходом и попыткой отвести внимание от скандалов, а насколько реально поехавшей кукухой Марка и ему подобных, возомнивших себя богами и решившими, что знают, какое будущее нам всем нужно. Как он там говорит - "This is the future we want". Меня бы это мало беспокоило, но нынешняя тенденция сводится к попытке загнать всех в какой-то виртуальный мир, а когда ты говоришь, что у тебя нет профайла в соцсетях, то на тебя уже начинают смотреть с подозрением, как на повернутого луддита. Все внедрения технологий начинаются с фраз - "не хочешь, не используй", а заканчиваются тем, что ты вынужден их использовать, даже если не хочешь.
Как мне кажется, для большинства нормальных руководителей очевидно, что введения всяких явных KPI только ухудшает ситуацию. Это же подобие Принципа Гудхарта. Люди не такие тупые, как о них думают разные "эффективные менеджеры" :)
Мне кажется, что такая логика может встречаться только у совсем уж новичков и я сомневаюсь, что хоть кто-то из более-менее опытных программистов на C может так думать или не знать про кардинальные различия между данными языками. Из перечисленного вами списка, многое может не использоваться намеренно, а не потому, что об этом не знают.
В общем очень спорные утверждения.
Вот я честно несколько раз пытался читать статью, но так и не смог понять, какую мысль хотел донести автор. Получилась какая-то смесь из эволюционной биологии, светского гуманизма, коммунизма (в понимании автора) и перехода к трансгуманизму. Автор пытается рассказывать о естественном процессе снижения насилия и эволюции морали, гуманизма, как будто опыта ХХ века не было. Вспомните, что еще совсем недавно, просвещенные европейцы, уничтожали друг друга в двух мировых войнах, а люди одной нации, считавшей себя самой культурной и просвещенной поставили уничтожение миллионов на поток. Я думаю, что если бы большинству людей в самом начале 20-го века сказали, что их ждет впереди, они бы посчитали это бредом сумасшедшего. И с чего вы взяли, что завтра все это не может повториться в еще более ужасных формах, а все рассказы о триумфе гуманизма, это не глупая иллюзия?
В целом статья хорошая и я согласен практически со всем изложенным.
Но к сожалению, данные советы мало помогут тому, кто не имеет подобного опыта. Чтобы делать обобщения нужно для начала иметь "то", что обобщать, и это главное, что есть у автора. А для человека, который не прошел подобного пути, эти 20 пунктов будут просто набором красивых фраз, так как не имеют под собой основы.
Вообщем, как и в геометрии, здесь "царских" путей нет.
Увидев заголовок и данное описание, я решил, что тут будет доступно рассказано про внутреннее устройство Kubernetes, но доступность материала превзошла все мои ожидания. Я узнал, что оказывается: планировщик - планирует, контроллер - контролирует, а прокси - проксирует и балансирует.
Это обнадеживает.
P.S. Я понимаю, что это перевод и к переводчику у меня никаких претензий нет.
Перестать прикрываться благими намерениями.
"Я изобрету теперь целую социальную систему, и - ты не поверишь - как это легко! Стоит только уединиться куда-нибудь подальше в угол или хоть попасть в крокодила, закрыть глаза, и тотчас же изобретешь целый рай для всего человечества." (c)
Многих авторов опенсорс проектов вполне можно понять, если встать на их место. Когда человек действительно занимается проектом, обдумывает его развитие и у него сформировано определенное видение развития, а конкретнее - как, и что данный софт должен делать, и самое главное, чего он не должен делать. И когда ему приходится постоянно отбиваться от всяких "контрибьютеров", которые вообще не разобравшись с проектом лезут со своими PR "новой модной фичи", и которым нужно каждый раз объяснять, почему их "улучшение" не будет принято, то после определенного момента, этих авторов это все задалбывает и они без объяснений начинают закрывать подобные PR. А дальше идут обиды, что автор токсичный мудак и вообще не достоин находится в нашем комьюнити (вспоминается автор Actix). Я сам наблюдал такую трансформацию несколько раз.
Меня тоже знакомые и родственники часто спрашивали "Посоветуй на какие курсы пойти". Я сам на курсы не ходил и учился по разным видео курсам на youtube. До этого правда у меня была техническая специальность (слесарь КИПиА) и я почти 5 лет катался по области и ставил системы автоматики на ГРС, а к электронике у меня с детства интерес. И я согласен с тем, что для работы программистом у тебя должно быть в первую очередь желание и интерес к специальности, а не материальная составляющая.
Но, в большинстве курсов "Стань разработчиком Х за 3 месяца с зарплатой в 2000$" меня напрягает именно морально-этическая сторона вопроса. То есть, люди их создающие и продвигающие, хорошо понимают, что это практически невозможно и на лицо откровенное мошенничество и введение людей в заблуждение. Чем они кардинально отличаются от всяких лохотронов или казино, мне не понятно. Можно пойти дальше и сделать объявление "Выучи PHP и заработай 100 миллиардов" (у Цукерберга же получилось).
Да, я могу согласиться с этим описанием, но тут, как мне кажется, мы уже пытаемся смоделировать "то как мы думаем, о том как мы думаем". То есть, мы не знаем как на самом деле мозг представляет объекты и концепции, и как на самом деле происходит наше мышление, а введение понятия "концепции" и абстракции, тут уже играет роль нашего объяснения нашего же процесса мышления. Я не против такого подхода, но я не уверен, что он дает преимущества.
Да, это интересные вопросы и мне эта тема близка, так как сам много думал о том, как правильно переносить и моделировать объекты и концепции реального мира. Выскажу буквально последнюю мысль, по поводу представленной проблемы - у вас при описании объекта комнаты, помимо описания ее выходов, требовалось указание того, куда эти выходы ведут. Если мы посмотрим на это с "точки зрения" реальных объектов, то комната не должна "знать", какая комната находится на противоположной стороне "выхода/прохода", она "знает" только о своих "выходах". Из-за этого возникает рекурсивная зависимость при инициализации объектов. По моему мнению, здесь как раз и заключается ранее указанная мною проблема - что мы пытаемся моделировать не физические объекты, а наши представления о физических объектах. Я не думаю, что мы можем одномоментно держать в голове полную модель даже для такой маленькой задачи, а каждый раз рассматриваем лишь ее часть (отделые комнаты/выходы). Из-за этого и могут случаться такие вещи.
Ладно, заканчиваю тут свои трактаты, а то я слишком много пишу.
Спасибо за поднятые вопросы.
В дополнение - на мой взгляд, здесь проблема именно в реализации вашей модели. То есть необходимости в введении абстракции в виде класса _RoomConcept на самом деле никакой нет. Если бы вы, как и хотели, в начале создали все экземпляры комнат, а потом связали их, то все бы получилось и без лишней прослойки абстракции.
Поправьте меня, если я что-то упускаю, но в вашем примере, вы пришли к рекурсивной зависимости потому, что пытались запрограммировать иерархическую структуру, хотя на словах (и в мыслях) представляли плоскую.
То есть в соответствии с данным кодом, получается что bedroom, который в Exit("S"), это не тот bedroom, который вы пытаетесь инициализировать. Как будто bedroom содержит сам себя, а не ссылку на себя. Что и приводит к противоречию.
Я не говорил о том, что какое-то из решений не приведет к проблемам. В данном случае, я хотел обратить внимание на описанную автором проблему возможности соответствия реальным физическим объектам. Мне кажется, что наша модель физического объекта сильно зависит от восприятия. И это уже начинает переходить в "философскую" плоскость.
Вот например - у нас есть физическая комната с двумя дверьми на противоположных сторонах. Мы берем и строим по середине комнаты перегородку. Теперь вопрос - у нас стало две комнаты или одна комната с перегородкой? То есть физически это одно и тоже, но когда мы собираемся моделировать это в виде объектов, то в зависимости от точки зрения, у нас получатся разные модели и код. То есть по моему мнению, никакого однозначного соответствия между физическими объектами и программными объектами быть не может. Но возможно я что-то упускаю.