Холодильник на лоджии - это же очень неудобно! Не понимаю, как можно заморачиваться с умным домом, не решив базовых проблем планировки. Вроде на кухне достаточно места.
В этой статье мы разъясним довольно тонкий семантический вопрос, который часто остаётся за кадром при изучении программирования на императивных языках.
Однажды Базарбаев пришёл в гости к Мыркымбаеву. Мыркымбаев угостил Базарбаева чаем с баурсаками, а сам вышел из комнаты. Через какое-то время Базарбаев пошёл в соседнюю комнату и увидел, что в ней сидит Мыркымбаев и ест целую тарелку дымящегося мяса. Базарбаев тогда сказал: — Как тебе не стыдно, ведь я гость, и ты должен был меня угостить мясом. На что Мыркымбаев ему ответил: — Ты стыдишь меня? Посуди сам: я угостил тебя чаем с баурсаками, и ты был доволен. Ты был доволен до тех пор, пока не вышел из комнаты и не увидел, что я ем мясо. Разве не ты сам виноват в том, что вышел из комнаты? И разве же я виноват в том, что не оправдал твоих ожиданий? Так кто же виноват в твоём недовольстве? Разве не ты сам? На что Базарбаев сказал: — Ты мозги не еби, мясо давай.
И всё это использует объекты ядра операционки - mutex.
SemaphoreSlim тоже использует мьютексы, когда не может обойтись атомарками (interlocked). Вообще, худые семафоры - это попытка сэкономить на использовании мьютексов за счёт атомарных операций. Очень удачная, надо сказать.
Интересно, а что мешает на текущей орбите просто затормозить МКС кораблём-толкателем? Получаем резкое и контролируемое снижение орбитальной скорости, затем совершенно предсказуемое падение горизонтально вниз.
Ох, как же задолбали хоронить десктоп! Он живее всех живых, у него свои ниши, где веб по удобству даже близко не стоял. При прочих равных, десктоп быстрее разрабатывается и быстрее работает.
За вебом сценарий, когда надо массовый продукт, а пользоваться им будут эпизодично.
Можно спорить о том, как правильно читать "william", "whatsup" и прочее. Это инвариантные случаи. Но в слове "view" нет второй "в" и никогда не было. Никто же не читает "ренаулт", "куеуе", "бузинесс".
Когда AI научится писать код лучше программиста, наступит удивительное время. AI сможет себя переписать, доработать и оптимизировать. А потом, став лучше, повторит.
Это называется "Технологическая сингулярность".
И странно бояться замещения программиста AI, когда оно пойдёт в комплекте с сингулярностью. Изменений будет столько, что мало никому не покажется. От скайнета до рая на земле, всё станет возможно.
Делать сходу двоичный поиск, без требований - это признак незрелости программиста. Premature optimization.
Оптимизация делается ТОЛЬКО по результатам замеров и профилирования. Иначе алгоритмы усложняются и код становится нечитаемым. А читаемость кода для львиной части кода гораздо важнее скорости.
ВНЕЗАПНО может оказаться, что in-memory join работает на порядки быстрее, чем тот же джоин в базе. Особенно, если этот случай учтён при проектировании.
А вы в данном случае не понимаете разницу между статически типизированными языками и динамически типизированными.
Да, конечно, и там и там "вылетит птичка". Только в динамически типизированном языке вы эту "птичку" получите в рантайме. А в статически типизированном - на этапе компиляции. И на этапе компиляции вам не нужно отлавливать условия возникновения ошибки и изучать стек в попытке узнать, откуда это взялось. Компилятор просто не даст вам сделать такую ошибку.
И не надо называть исключения копеечной проблемой. Это может быть прод на миллионы запросов в час. Это может быть две недели попыток воспроизведения бага. Не надо недооценивать ошибки.
Статическая типизация - это один из инструментов управления сложностью проекта. Точно так же, как и ORM. Та технология, что позволяет сгрузить риск ошибки на неё. В ущерб кривой вхождения, да.
Если для вас внедрение в пайплайн компилятора или ORM делает проекты запутаннее, то у вас недостаточно сложные проекты. Или же вы не умеете ими пользоваться. Или у вас редкий случай, когда это просто невыгодно.
Все свои большие проекты я делал с ORM. Кроме последнего, где ORM не нужен. Вот просто у проекта другая идеология. Но вот придумать условия, где было бы оправданно использовать язык с динамической типизацией для действительно большого проекта я не могу.
Что за "ручки" такие? Вы тащите в статью какой-то ваш внутренний сленг?
По статье:
Нормализация. Делать нормализацию только потому, что "так учили" - сомнительно. Бывает приходится сознательно денормализовывать данные.
Отдельные схемы для разных модулей. Крайне сомнительно. Особенно, если данные используются далеко не одним модулем.
Холодильник на лоджии - это же очень неудобно! Не понимаю, как можно заморачиваться с умным домом, не решив базовых проблем планировки. Вроде на кухне достаточно места.
<данные удалены>
А где сформулированный вопрос?
Анекдот
Однажды Базарбаев пришёл в гости к Мыркымбаеву. Мыркымбаев угостил Базарбаева чаем с баурсаками, а сам вышел из комнаты. Через какое-то время Базарбаев пошёл в соседнюю комнату и увидел, что в ней сидит Мыркымбаев и ест целую тарелку дымящегося мяса. Базарбаев тогда сказал: — Как тебе не стыдно, ведь я гость, и ты должен был меня угостить мясом. На что Мыркымбаев ему ответил: — Ты стыдишь меня? Посуди сам: я угостил тебя чаем с баурсаками, и ты был доволен. Ты был доволен до тех пор, пока не вышел из комнаты и не увидел, что я ем мясо. Разве не ты сам виноват в том, что вышел из комнаты? И разве же я виноват в том, что не оправдал твоих ожиданий? Так кто же виноват в твоём недовольстве? Разве не ты сам? На что Базарбаев сказал: — Ты мозги не еби, мясо давай.
Эскобар про меньшее из зол
Semaphore использует Monitor.WaitHandle.
Lock использует Monitor.WaitHandle.
AutoResetEvent использует Monitor.WaitHandle.
И всё это использует объекты ядра операционки - mutex.
SemaphoreSlim тоже использует мьютексы, когда не может обойтись атомарками (interlocked). Вообще, худые семафоры - это попытка сэкономить на использовании мьютексов за счёт атомарных операций. Очень удачная, надо сказать.
Статья - безграмотная чушь.
Интересно, а что мешает на текущей орбите просто затормозить МКС кораблём-толкателем? Получаем резкое и контролируемое снижение орбитальной скорости, затем совершенно предсказуемое падение горизонтально вниз.
Или слишком много энергии надо?
Я где-то говорил, что не вижу разницы? Я где-то говорил, что времена те же самые остались?
xkcd_extrapolation.jpg
Может это говорит больше о текучке в вакансиях на веб, чем о востребованности десктопа?
Ох, как же задолбали хоронить десктоп! Он живее всех живых, у него свои ниши, где веб по удобству даже близко не стоял. При прочих равных, десктоп быстрее разрабатывается и быстрее работает.
За вебом сценарий, когда надо массовый продукт, а пользоваться им будут эпизодично.
Можно спорить о том, как правильно читать "william", "whatsup" и прочее. Это инвариантные случаи. Но в слове "view" нет второй "в" и никогда не было. Никто же не читает "ренаулт", "куеуе", "бузинесс".
Кринге, блин.
вьюер - англицизм, вьювер - рунглицизм
Когда AI научится писать код лучше программиста, наступит удивительное время. AI сможет себя переписать, доработать и оптимизировать. А потом, став лучше, повторит.
Это называется "Технологическая сингулярность".
И странно бояться замещения программиста AI, когда оно пойдёт в комплекте с сингулярностью. Изменений будет столько, что мало никому не покажется. От скайнета до рая на земле, всё станет возможно.
Долго можно ждать. Чат на языковой модели не может в принципе писать стихи просто потому что не знает, как произносятся слова.
int result = a.LastOrDefault(n => n < x);if (result == 0) result = -1;return resultКажется, я уложился в 30 строчек.
Делать сходу двоичный поиск, без требований - это признак незрелости программиста. Premature optimization.
Оптимизация делается ТОЛЬКО по результатам замеров и профилирования. Иначе алгоритмы усложняются и код становится нечитаемым. А читаемость кода для львиной части кода гораздо важнее скорости.
Очень наивная статья без анализа причинно-следственных связей. Мне кажется, что лучше будет смотреться на пикабу, чем на хабре.
ВНЕЗАПНО может оказаться, что in-memory join работает на порядки быстрее, чем тот же джоин в базе. Особенно, если этот случай учтён при проектировании.
Для начала больше не использовать аргумент "не можешь знать, что под капотом происходит".
А вы в данном случае не понимаете разницу между статически типизированными языками и динамически типизированными.
Да, конечно, и там и там "вылетит птичка". Только в динамически типизированном языке вы эту "птичку" получите в рантайме. А в статически типизированном - на этапе компиляции. И на этапе компиляции вам не нужно отлавливать условия возникновения ошибки и изучать стек в попытке узнать, откуда это взялось. Компилятор просто не даст вам сделать такую ошибку.
И не надо называть исключения копеечной проблемой. Это может быть прод на миллионы запросов в час. Это может быть две недели попыток воспроизведения бага. Не надо недооценивать ошибки.
Статическая типизация - это один из инструментов управления сложностью проекта. Точно так же, как и ORM. Та технология, что позволяет сгрузить риск ошибки на неё. В ущерб кривой вхождения, да.
Если для вас внедрение в пайплайн компилятора или ORM делает проекты запутаннее, то у вас недостаточно сложные проекты. Или же вы не умеете ими пользоваться. Или у вас редкий случай, когда это просто невыгодно.
Все свои большие проекты я делал с ORM. Кроме последнего, где ORM не нужен. Вот просто у проекта другая идеология. Но вот придумать условия, где было бы оправданно использовать язык с динамической типизацией для действительно большого проекта я не могу.