У людей полно своих забот. Некоторые вещи хочется делегировать. Безопасность хочется делегировать тем, кто в этом разбирается (разработчики систем, которыми ты пользуешься, правоохранительные органы, чьи зарплаты это твои налоги).
Я тут в цивку последнюю играл. И там один из оппонентов (ИИ) осудил меня за то, что я убил шпиона, которого он ко мне подослал. Политика беспощадна даже в играх ))
Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
А как же "попробовать"? Что, если надо проверить гипотезу на практике? Что, если в результате исследования оказжется, что это вообще невозможно сделать? Например, используемый инструмент работает не так, как ожидалось, а свой писать слишком долго?
Я неоднократно сокращал время на разработку тем, что реализовывал всякие полезности. И эти полезности я мог описать уже после реализации. Просто у меня было предчувствие, что все должно получиться. :)
В противном случае, разработка пошла бы по очевидному, но при этом длинному пути.
Ну конечно, если я подниму сервис на своем домашнем компе и меня решат ДДОСить, то я окажусь в вакууме. Но вы недооцениваете каналы и оборудование крупных игроков.
Это понятно. Мы ведь знаем, что мы хотим получить. У нас есть представление о том, что такое процессор. У нас нет только технологий, позволяющих его произвести. Более того, путь получения этих технологий очень непростой, придется буквально пройтись по пути интелов и амд, то есть по всем поколениям процессоров.
Ну вот у процессоров сильно решает стоимость производства, а не материалов. То есть сам процесс производства дорогой. Оборудование, вот это вот все.
Предположим, я произвожу 100 процессоров в день и мне это стоит 100уе. Что если я придумаю, как удешевить процесс производства и 100 процессоров мне уже будет стоить 50уе? Тогда ведь я смогу делать 50 процессоров, продавать их по цене того дорогого производства и у меня не будет уже так остро стоять проблема куда их сбыть.
Меня тоже эта работа порадовала. Просто здесь заявлен "рукописный шрифт", поэтому я и предложил некоторые изменения, которые сделают его еще более рукописным :)
Может, это приведет к удешевлению производства. Я не знаю, возможно ли это в случае с процессорами, но есть пример из иной отрасли. Когда мне нужен один особенный совок, дешевле напечатать его на 3Д принтере, чем создавать для него литейную форму и топать на зовод по производству совков.
То есть, если удастся изменить процесс производства чипов тиаким образом, чтобы он не требовал для окупаемости создавать 5 миллиардов экземпляров, то вот эта проблема с рынками пропадет.
Ели говорить про разработчиков, то у них есть ещё один способ избежать когнитивной перегрузки: тренировать свою способность выдерживать когнитивную нагрузку
Я думаю, что это невозможно. В явном виде. Вот что сказано в статье.
При чтении кода мы держим в голове значения переменных, логику управления и последовательности вызовов функций. Человеческий мозг способен удерживать в рабочей памяти около четырех сложных разнородных элементов.
Получается что то вроде регистров, в которые что либо помещается/считывается. Понятно, что на одних регистрах не выехать и нужно задействовать внешние ресурсы по вычислению из condition1 && condition2 некий isValid, который, затем отправится в регистр, а condition1 и condition2 забудутся. Но это приведение нужно выполнить. И таких приведений в коде может быть множество. Кроме того, вместо condition1 и condition2 тут может быть намного больше условий, а значит они не поместятся в регистры, а значит придется делать несколько промежуточных действий. Так же, этот isValid - вполне ясная для нашего "процессора" команда, тогда как condition1 и тд нам неизвестны и требуют погружения в предметку в тех местах, которые просто не нужны для выполнения текущей задачи.
И да, мозг постоянно тренируется и новые связи помогают выполнять все эти промежуточные вычисления быстрее - по прямому пути.
То есть с одной стороны вы правы, говоря, что мы можем тренироваться, с другой стороны это никак не отменяет слов автора о том, что для выполнения поставленной задачи это лишняя нагрузка.
И нет, промежуточные return это не то же самое что goto. Место куда нас ведет goto надо искать и исследовать, тогда как return всегда ведет нас на фрейм выше и дополнительное исследование тут не требуется. Мы ведь знаем, что вернет нам функция, по каким правилам она работает. И если в самой функции мы проблему не увидели (а это можно понять намного быстрее, в идеале, одним коротким взглядом на нее боковым зрением, если она понятно написана), значит проблема либо выше либо ниже. То есть либо ошибка в вызывающем коде, либо в одной из абстракций, на которую мы полагаемся внутри своей функции.
эти ранние return можно не заметить вовремя
Есть такое. Но эти же ранние return могут быть и внтури ифов. И там их заметить намного сложнее. А они там могут быть, потому что язык это позволяет. В scala, например, возвращается значение последнего выражения. Там не используется return. вместо этого блоки там тоже возвращают значение. val myVar = if (condition) val1 else val2. То есть условный оператор есть тернарное выражение. И это позволяет не сталкиваться с проблемами return. но там где они есть, приходится разрабатывать подходы, как их использовать наименее просто для восприятия. И наименее просто, когда они находятся на одном уровне вложенности. Более того, полезная нагрузка (логика) находится навиду, когда находится перед глазами без вложенности. То есть в идеале, мы сначла проходим все предусловия, а затем выполняем логику, которая сама по себе от этих предусловий не зависит. Таким образом мы визуально отделяем предусловия от логики, а не просто создаем дополнительные строки кода.
Автор, все круто. А попробуй сделать нолик без диагональной линии. Эта линия как будто не вписывается в концепт рукописного шрифта (понимаю, что кто то ее рисует ручкой, но это редкость).
Ну или сделать эту линию "неряшливой". Чтобы она либо не доставала до краев либо выходила за границы.
Еще можно попробовать "фиксированный" шрифт сделать с разбросом. То есть чтобы точка бралась не там где она есть, а в небольшом радиусе вокруг. Тогда в числе 22 двойки будут выглядеть по разному, но сохранится почерк.
Если я произвожу дома пулеметы но закон этого не запрещает, то меня не посадят за то, что кто то убил другого моим пулеметом. Более того, если я произвел пулемет вчера, а запрет ввели сегодня, это не сделает меня преступником.
Для того чтобы пришить к делу, надо чтобы было дело. Причем с похожим контекстом.
Причем тут Трамп? У нас не США. Но справедливости ради, если не смог изначиловать - слабый. Кому нужен слабый президент? ))
Это так не работает. Нельзя судить за преступление, совершенное до вступление закона в силу. Хотя, это может быть поводом для расследования.
Так может не в доходе дело?
У людей полно своих забот. Некоторые вещи хочется делегировать. Безопасность хочется делегировать тем, кто в этом разбирается (разработчики систем, которыми ты пользуешься, правоохранительные органы, чьи зарплаты это твои налоги).
Так и в требованиях ни слова про ютьюб же. Все всё понимают, но...
Ну да. Только я не выбирал это действие. Меня игра поставила перед фактом... вероятно, этот шпион оказывал вооруженное сопротивление.
А демонстрировать после спринта что? Набор классов на бэке? Или это сарказм? :)
Я тут в цивку последнюю играл. И там один из оппонентов (ИИ) осудил меня за то, что я убил шпиона, которого он ко мне подослал. Политика беспощадна даже в играх ))
А как же "попробовать"? Что, если надо проверить гипотезу на практике? Что, если в результате исследования оказжется, что это вообще невозможно сделать? Например, используемый инструмент работает не так, как ожидалось, а свой писать слишком долго?
Я неоднократно сокращал время на разработку тем, что реализовывал всякие полезности. И эти полезности я мог описать уже после реализации. Просто у меня было предчувствие, что все должно получиться. :)
В противном случае, разработка пошла бы по очевидному, но при этом длинному пути.
Ну конечно, если я подниму сервис на своем домашнем компе и меня решат ДДОСить, то я окажусь в вакууме. Но вы недооцениваете каналы и оборудование крупных игроков.
Это понятно. Мы ведь знаем, что мы хотим получить. У нас есть представление о том, что такое процессор. У нас нет только технологий, позволяющих его произвести. Более того, путь получения этих технологий очень непростой, придется буквально пройтись по пути интелов и амд, то есть по всем поколениям процессоров.
Это если не найти принципиально иной путь.
Ну вот у процессоров сильно решает стоимость производства, а не материалов. То есть сам процесс производства дорогой. Оборудование, вот это вот все.
Предположим, я произвожу 100 процессоров в день и мне это стоит 100уе. Что если я придумаю, как удешевить процесс производства и 100 процессоров мне уже будет стоить 50уе? Тогда ведь я смогу делать 50 процессоров, продавать их по цене того дорогого производства и у меня не будет уже так остро стоять проблема куда их сбыть.
Меня тоже эта работа порадовала. Просто здесь заявлен "рукописный шрифт", поэтому я и предложил некоторые изменения, которые сделают его еще более рукописным :)
в часах нет никакой латинской D же. И даже буквы О нет. Там 0 есть 0
А что на счет урощения производства?
Может, это приведет к удешевлению производства. Я не знаю, возможно ли это в случае с процессорами, но есть пример из иной отрасли.
Когда мне нужен один особенный совок, дешевле напечатать его на 3Д принтере, чем создавать для него литейную форму и топать на зовод по производству совков.
То есть, если удастся изменить процесс производства чипов тиаким образом, чтобы он не требовал для окупаемости создавать 5 миллиардов экземпляров, то вот эта проблема с рынками пропадет.
Я думаю, что это невозможно. В явном виде. Вот что сказано в статье.
Получается что то вроде регистров, в которые что либо помещается/считывается. Понятно, что на одних регистрах не выехать и нужно задействовать внешние ресурсы по вычислению из condition1 && condition2 некий isValid, который, затем отправится в регистр, а condition1 и condition2 забудутся. Но это приведение нужно выполнить. И таких приведений в коде может быть множество. Кроме того, вместо condition1 и condition2 тут может быть намного больше условий, а значит они не поместятся в регистры, а значит придется делать несколько промежуточных действий. Так же, этот isValid - вполне ясная для нашего "процессора" команда, тогда как condition1 и тд нам неизвестны и требуют погружения в предметку в тех местах, которые просто не нужны для выполнения текущей задачи.
И да, мозг постоянно тренируется и новые связи помогают выполнять все эти промежуточные вычисления быстрее - по прямому пути.
То есть с одной стороны вы правы, говоря, что мы можем тренироваться, с другой стороны это никак не отменяет слов автора о том, что для выполнения поставленной задачи это лишняя нагрузка.
И нет, промежуточные return это не то же самое что goto. Место куда нас ведет goto надо искать и исследовать, тогда как return всегда ведет нас на фрейм выше и дополнительное исследование тут не требуется. Мы ведь знаем, что вернет нам функция, по каким правилам она работает. И если в самой функции мы проблему не увидели (а это можно понять намного быстрее, в идеале, одним коротким взглядом на нее боковым зрением, если она понятно написана), значит проблема либо выше либо ниже. То есть либо ошибка в вызывающем коде, либо в одной из абстракций, на которую мы полагаемся внутри своей функции.
Есть такое. Но эти же ранние return могут быть и внтури ифов. И там их заметить намного сложнее. А они там могут быть, потому что язык это позволяет. В scala, например, возвращается значение последнего выражения. Там не используется return. вместо этого блоки там тоже возвращают значение. val myVar = if (condition) val1 else val2. То есть условный оператор есть тернарное выражение. И это позволяет не сталкиваться с проблемами return. но там где они есть, приходится разрабатывать подходы, как их использовать наименее просто для восприятия. И наименее просто, когда они находятся на одном уровне вложенности. Более того, полезная нагрузка (логика) находится навиду, когда находится перед глазами без вложенности. То есть в идеале, мы сначла проходим все предусловия, а затем выполняем логику, которая сама по себе от этих предусловий не зависит. Таким образом мы визуально отделяем предусловия от логики, а не просто создаем дополнительные строки кода.
Автор, все круто. А попробуй сделать нолик без диагональной линии. Эта линия как будто не вписывается в концепт рукописного шрифта (понимаю, что кто то ее рисует ручкой, но это редкость).
Ну или сделать эту линию "неряшливой". Чтобы она либо не доставала до краев либо выходила за границы.
Еще можно попробовать "фиксированный" шрифт сделать с разбросом. То есть чтобы точка бралась не там где она есть, а в небольшом радиусе вокруг. Тогда в числе 22 двойки будут выглядеть по разному, но сохранится почерк.
А можно подробнее про использование данного костыля? Какие были противоправные (на ваш взгляд) случаи его использования?
Производство пулемета никак не подходит под "длящееся преступление"
Если я произвожу дома пулеметы но закон этого не запрещает, то меня не посадят за то, что кто то убил другого моим пулеметом. Более того, если я произвел пулемет вчера, а запрет ввели сегодня, это не сделает меня преступником.