Ну, если рассуждать в ключе, что иррациональных чисел не существует, то и доказывать ничего не нужно дополнительно: нумеруем рациональные и всё. Что, как я понял, и было сделано. Вот только иррациональные числа существуют сами по себе, и это доказано строго математически. А то, что мы можем «пощупать» только их приближения — это не проблема иррациональных чисел и уж никак не опровержение их существования.
А что является результатом работы алгоритма, который не завершится никогда? Рассуждая на пальцах: либо «ничего» (или другой определённый конкретный ответ), и тогда все иррациональные числа имеют «одинаковый номер» — нет однозначности, либо «не определено», и тогда мы не можем сравнить номера, как следствие, не можем проверить однозначность соответствия.
Или, например, так: вот для двух разных «конечных рациональных» чисел при грамотно построенной нумерации (например, по квадрату) всегда будет два конечных номера, которые можно сравнить и убедиться, что номера разные. А как сравнить между собой два бесконечных номера?
Ну гнать-то вроде не за что, айтишник просто неравнодушен и своё мнение доносит, но работу при этом делает со всеми хотелками. А работа тут такая, что без обсуждений с заказчиком нельзя. В частности, и сам заказчик может до конца не знать, что он реально хочет.
Но с остальным соглашусь. Тебе платят за цифры — даёшь цифры. Как с этими цифрами обращаться и что с ними делать — это пускай у других людей голова болит, тебе за это не платят.
Цифры – это просто инструмент, как молоток или дрель.
Вот даже исходя из этой аналогии: производитель моего молотка мне не будет доказывать, что молоток мне не нужен, т.к. я его купил и положил пылиться на полку. Его дело — сделать молоток. А на полку я его положу, буду им гвозди забивать или в носу им ковырять — его это вообще не должно волновать.
Это всё до первого бага или первого изменения требований. Тогда-то и придётся залезть в реализацию объекта и схватиться за голову.
Если программист (1)выдаёт идеально работающий продукт, который (2)не нужно будет дорабатывать, тогда конечно не так важно, как оно написано. Первое происходит обычно никогда, а второе — обычно когда продукт никому не нужен.
Ну, это, конечно, да. Согласен с тем, что это боль. Но вот лично у меня эта боль не основная. С огромным методом хотя бы понятно что делать — анализировать и разбивать. Т.е. есть конкретный файл, в нём конкретный ком грязи, конкретно его чистишь в несколько заходов — и понимание приходит, что оно делает, и мелкие баги сразу под пристальным взглядом всплывают и фиксятся. Если время есть, то это даже какого-то рода медитативное дело. Даже настроение улучшается: вроде как какой-то дурак намусорил, а ты всё прибрал и почистил, молодец. (Даже если намусоривший дурак — это я полгода назад, лол)
Моя основная боль начинается от ООПшного комка грязи, разбросанного по разным файлам, между которыми нужно скакать, пытаясь угадать зависимости. Когда непонятно даже, куда в принципе стоит смотреть. А усиливается боль от пучка зависимостей между огромными модулями (пускай даже не слишком плохими внутри), с которыми уже вообще фиг знает, что можно сделать, и любая правка подобна магии. А ещё больнее, когда все остальные модули — не твоя зона ответственности, и ничего менять в них по регламенту тебе не положено. Ещё хлеще, если часть этих модулей вообще проприетарное ПО с закрытым кодом, и ничего там нельзя изменить в принципе.
Работал с программистом, который очень любил «не писать лишнего». В его коде как раз были методы-простыни на тысячи строк. Спорил с ним на ревью по поводу выделения в отдельный метод, его рассуждения были примерно такие:
— Этот метод будет вызываться один раз, значит в коде будут плюс две-четыре лишние строки на сигнатуру функции, скобки, разделяющую пустую строку и т.п., зачем мне лишние строки?
Ну и, несмотря на то, что я считаю это ужасным подходом с точки зрения качества кода, стоит признать, что формально-то он прав, кода действительно становится больше. Поэтому я удивился, когда увидел в статье
Код заслуживает быть вынесенным в отдельную функцию не только тогда, когда его планируется переиспользовать, но и в целях улучшения читаемости.
Так что я не понял посыл. С чем предлагается бороться: с количеством или низким качеством? Или под словом «код» здесь понимается только содержание методов?
Нужно просто не использовать прямые ответы на секретные вопросы. И они должны быть сопоставимы по сложности с паролями, т.к. общая защищённость равна защищённости самого слабого звена. Помню, ещё в 2009-2012 злоумышленники массово угоняли мыла на мейлру, перебирая стандартные ответы. У них даже целые списки были в публичном доступе, вроде:
Популярные клички: Барсик, Васька, Мурка, Мухтар, Барбос;
Популярные любимые блюда: мороженое, мороженное, шашлык;
и т.д.
Музыку из первой группы любят «сложные» люди, которые склонны к рефлексии.
Вторую группу предпочитают «напористые и бунтующие» натуры[...] они более спортивны и не любят казаться умнее всех.
В третьей группе — оптимисты и экстраверты, более добросовестные и склонные соглашаться с другими
Музыку из четвертой группы предпочитают энергичные и ритмичные люди [...] отличаются отсутствием консерватизма, более высоким уровнем дохода и IQ.
1. А реально ли нужно запретить проезд? Может его разрешить и не заморачиваться?
2. Или может запретить въезд вообще всем? Тогда хорошо подойдёт стена.
3. Перевести все автомобили на автопилот с картой и условиями въезда.
4. Поставить знак-экран (условный кирпич) и камеру, нарушителей автоматически штрафовать по номеру.
5. Металлические шипы.
6. Ров с водой и крокодилами и автоматический опускающийся мост на цепях.
7. Хорошая парковка вне огороженной территории.
8. Просто знак запрета проезда, но если человек, которому показали этот знак, не едет, разворачивается и уезжает, то на выезде ему в автомате рядом выдаётся бесплатная газировка (попытка перевести с кнута на пряник).
9. Знак запрета проезда, муляж автоматического огнемёта и два поджаренных корпуса авто рядом.
Я всё-таки достиг результата, поэтому могу смело изменить название этой презентации с «Как я сбивал назойливый дрон соседского ребёнка» на «Как я сбил назойливый дрон соседского ребёнка».
Печаль. Всю статью ждал подробное описания того, как автор будет сбивать непосредственно дрон ребёнка.
И тут обнаруживается кое-что интересное. «Идентично» — то есть, тождественно, взаимозаменяемо при любых обстоятельствах. И даже при UB?
Неопределённое поведение — оно не определено. Значит и идентичность этого поведения какому-то другому поведению при нём тоже не определена.
Это как сравнивать два поля одного nullable типа (в БД для конкретики аналогии): если они определены, то их можно сравнить (проверить на равенство). Но если хотя бы одно из них null, то это значит, что мы вообще не можем их сравнивать, результат их сравнения тоже не определён. А само null — это не состояние данных, а неопределённость этого состояния. И думать о нём нужно именно на этом абстрактном уровне. Но программисту (говорю, основываясь на личных ощущениях) очень хочется воспринимать null как очередное состояние, потому что на уровне реализации это и есть состояние, а программист чаще мыслит реализацией.
Меня такой код восхищает, потому что он наверняка супер оптимален и с первого взгляда совершенно непонятно, как работает. От подобных алгоритмов я получаю особое удовольствие.
А я ровно наоборот. Не скажу, что в данном случае это плохо, всё-таки, как я понял, библиотечная реализация, которая, вообще говоря, критична к производительности. Но хотелось бы комментарий «как» и «почему так», хотя бы название алгоритма/приёма, если это какая-то классика. Вот опечатается коллега на один символ в реализации, а мне придёт бага — и как мне понять, есть ли здесь ошибка, где конкретно и как проявляется?
А что если функций не 4? Может, есть пятое слагаемое, навскидку, любовь созерцать воду. И через эту водосозерцательную функцию мы будем говорить о том, нравятся нам или не нравятся люди (которые на большую часть состоят из воды), какие занятия нам нравятся (близостью с водой либо похожестью на поведение воды) и т.д.?
Или что если ум и душа это одно и то же? Или что если никакой логики не существует в принципе? Что если есть люди, у которых нет каких-то из перечисленных четырёх функций? Что если у человека все четыре функции вторые или четвёртые? Что если «пробивной инструмент» человека в обычной жизни логика, а при опасности физика? Что если психотип приобретённый, а не врождённый? Что если он не постоянный, а меняется в течение жизни или даже по десять раз в течение дня? Что если не психотип определяет поведение человека, а сформировавшийся человек определяет свой психотип?
А ещё очень «здорово», что этой теорией можно объяснить что угодно. Есть, например, спортсмен. Он хорош, потому что его пробивной инструмент — физика. Ну или он хорош, потому что его тонкий инструмент — физика. Ну или физика его третья функция, поэтому он комплексует и вкачивает её на максимум. А есть человек, у которого со спортом плохо. Почему? Потому что его физика — первая функция, он плох в ней, но не осознаёт, поэтому ничего не делает для её улучшения. Или третья, поэтому он стесняется своего тела и не ходит в зал. Или четвёртая — и ему пофиг на спорт.
Проблема поставлена хорошо, да и решение предложено неплохое. Но ИМХО использование перечислений — шаг вперёд, а завязка их на булевы значения (и тем более каст к ним) — шаг назад. При определении перечислений нужно забыть, что переменные, из-за которых они возникают, были из множества {false, true}. Т.е. вместо
enum class WithValidation : bool { False, True };
enum class WithNewEngine : bool { False, True };
я бы написал как-то так:
enum class ValidationMode : bool { NoValidation, Validation };
enum class EngineVersion : bool { Old, New };
Тогда и мыслей о касте к булеву значению не возникает: мы будем проверять строгое соответствие переменной одному из её возможных значений.
Кстати, по опыту, часто функции (bool,…, bool) не обрабатывают весь спектр 2 в степени n индивидуально, она просто болеет «добавлением ещё флажка». Т.е., например, если у нас есть функция
То при первом аргументе false второй вообще не важен: какая разница, доступный контрол или нет, если мы его даже не будем отрисовывать по факту. Из-за этого напрашивается сделать что-то такое:
О том же подумал, когда статью читал. Всё надо либо проверять, либо заранее «договариваться» о том, чего быть «не должно», потому что это уже было обязательно проверено выше.
А что является результатом работы алгоритма, который не завершится никогда? Рассуждая на пальцах: либо «ничего» (или другой определённый конкретный ответ), и тогда все иррациональные числа имеют «одинаковый номер» — нет однозначности, либо «не определено», и тогда мы не можем сравнить номера, как следствие, не можем проверить однозначность соответствия.
Или, например, так: вот для двух разных «конечных рациональных» чисел при грамотно построенной нумерации (например, по квадрату) всегда будет два конечных номера, которые можно сравнить и убедиться, что номера разные. А как сравнить между собой два бесконечных номера?
Но с остальным соглашусь. Тебе платят за цифры — даёшь цифры. Как с этими цифрами обращаться и что с ними делать — это пускай у других людей голова болит, тебе за это не платят.
Вот даже исходя из этой аналогии: производитель моего молотка мне не будет доказывать, что молоток мне не нужен, т.к. я его купил и положил пылиться на полку. Его дело — сделать молоток. А на полку я его положу, буду им гвозди забивать или в носу им ковырять — его это вообще не должно волновать.
Если программист (1)выдаёт идеально работающий продукт, который (2)не нужно будет дорабатывать, тогда конечно не так важно, как оно написано. Первое происходит обычно никогда, а второе — обычно когда продукт никому не нужен.
Моя основная боль начинается от ООПшного комка грязи, разбросанного по разным файлам, между которыми нужно скакать, пытаясь угадать зависимости. Когда непонятно даже, куда в принципе стоит смотреть. А усиливается боль от пучка зависимостей между огромными модулями (пускай даже не слишком плохими внутри), с которыми уже вообще фиг знает, что можно сделать, и любая правка подобна магии. А ещё больнее, когда все остальные модули — не твоя зона ответственности, и ничего менять в них по регламенту тебе не положено. Ещё хлеще, если часть этих модулей вообще проприетарное ПО с закрытым кодом, и ничего там нельзя изменить в принципе.
— Этот метод будет вызываться один раз, значит в коде будут плюс две-четыре лишние строки на сигнатуру функции, скобки, разделяющую пустую строку и т.п., зачем мне лишние строки?
Ну и, несмотря на то, что я считаю это ужасным подходом с точки зрения качества кода, стоит признать, что формально-то он прав, кода действительно становится больше. Поэтому я удивился, когда увидел в статье
Так что я не понял посыл. С чем предлагается бороться: с количеством или низким качеством? Или под словом «код» здесь понимается только содержание методов?
Популярные клички: Барсик, Васька, Мурка, Мухтар, Барбос;
Популярные любимые блюда: мороженое, мороженное, шашлык;
и т.д.
Звучит как гороскоп.
2. Или может запретить въезд вообще всем? Тогда хорошо подойдёт стена.
3. Перевести все автомобили на автопилот с картой и условиями въезда.
4. Поставить знак-экран (условный кирпич) и камеру, нарушителей автоматически штрафовать по номеру.
5. Металлические шипы.
6. Ров с водой и крокодилами и автоматический опускающийся мост на цепях.
7. Хорошая парковка вне огороженной территории.
8. Просто знак запрета проезда, но если человек, которому показали этот знак, не едет, разворачивается и уезжает, то на выезде ему в автомате рядом выдаётся бесплатная газировка (попытка перевести с кнута на пряник).
9. Знак запрета проезда, муляж автоматического огнемёта и два поджаренных корпуса авто рядом.
Ну или он просто высказал своё субъективное мнение, которое подхватили, потому что он
Печаль. Всю статью ждал подробное описания того, как автор будет сбивать непосредственно дрон ребёнка.
Неопределённое поведение — оно не определено. Значит и идентичность этого поведения какому-то другому поведению при нём тоже не определена.
Это как сравнивать два поля одного nullable типа (в БД для конкретики аналогии): если они определены, то их можно сравнить (проверить на равенство). Но если хотя бы одно из них null, то это значит, что мы вообще не можем их сравнивать, результат их сравнения тоже не определён. А само null — это не состояние данных, а неопределённость этого состояния. И думать о нём нужно именно на этом абстрактном уровне. Но программисту (говорю, основываясь на личных ощущениях) очень хочется воспринимать null как очередное состояние, потому что на уровне реализации это и есть состояние, а программист чаще мыслит реализацией.
А я ровно наоборот. Не скажу, что в данном случае это плохо, всё-таки, как я понял, библиотечная реализация, которая, вообще говоря, критична к производительности. Но хотелось бы комментарий «как» и «почему так», хотя бы название алгоритма/приёма, если это какая-то классика. Вот опечатается коллега на один символ в реализации, а мне придёт бага — и как мне понять, есть ли здесь ошибка, где конкретно и как проявляется?
А что если функций не 4? Может, есть пятое слагаемое, навскидку, любовь созерцать воду. И через эту водосозерцательную функцию мы будем говорить о том, нравятся нам или не нравятся люди (которые на большую часть состоят из воды), какие занятия нам нравятся (близостью с водой либо похожестью на поведение воды) и т.д.?
Или что если ум и душа это одно и то же? Или что если никакой логики не существует в принципе? Что если есть люди, у которых нет каких-то из перечисленных четырёх функций? Что если у человека все четыре функции вторые или четвёртые? Что если «пробивной инструмент» человека в обычной жизни логика, а при опасности физика? Что если психотип приобретённый, а не врождённый? Что если он не постоянный, а меняется в течение жизни или даже по десять раз в течение дня? Что если не психотип определяет поведение человека, а сформировавшийся человек определяет свой психотип?
А ещё очень «здорово», что этой теорией можно объяснить что угодно. Есть, например, спортсмен. Он хорош, потому что его пробивной инструмент — физика. Ну или он хорош, потому что его тонкий инструмент — физика. Ну или физика его третья функция, поэтому он комплексует и вкачивает её на максимум. А есть человек, у которого со спортом плохо. Почему? Потому что его физика — первая функция, он плох в ней, но не осознаёт, поэтому ничего не делает для её улучшения. Или третья, поэтому он стесняется своего тела и не ходит в зал. Или четвёртая — и ему пофиг на спорт.
я бы написал как-то так:
Тогда и мыслей о касте к булеву значению не возникает: мы будем проверять строгое соответствие переменной одному из её возможных значений.
Кстати, по опыту, часто функции (bool,…, bool) не обрабатывают весь спектр 2 в степени n индивидуально, она просто болеет «добавлением ещё флажка». Т.е., например, если у нас есть функция
То при первом аргументе false второй вообще не важен: какая разница, доступный контрол или нет, если мы его даже не будем отрисовывать по факту. Из-за этого напрашивается сделать что-то такое:
Это почти ложь.