Если хелловорлд-сайт на Django тормозит, значит, или хостинг всё-таки хреновый, или надо искать ещё какую-то конкретную проблему, а не кивать на Django. Мне как-то хватает KVM на одно ядро и 1Гб на 5-6 не самых тяжёлых сайтов. Django, uwsgi за nginx, letsencrypt, PostgreSQL, redis, Celery, все дела.
Выяснять, что комфортнее и практичнее, клавиатура в связке с мышью или геймпад, не имеет смысла, так как это вопрос привычки и личного предпочтения.
Выходит, что вы начали статью с оценивающего утверждения (которое я лично понял как «все контроллеры одинаково комфортны и практичны»), а теперь пишете, что не задавались целью это выяснить. Если бы вы просто написали
Не будем выяснять сейчас, что комфортнее и практичнее: клавиатура в связке с мышью или геймпад.
Приведу аналогию.
Одни детишки играют с машинками, другие — с самолётиками.
Это плохая аналогия. Непонятно, как вы к ней пришли. В реальности, например, игрушки у детей одинаковые.
почему по-вашему сейчас так много кроссплейных игр?
Потому что на консолях появилась возможность подключения клав-мышей. Для тех, кто не собирается пользоваться этой возможностью, в кроссплеях будет возможность поставить галку, чтобы не матчиться с мышатниками. Сужу по обзорам игр от активижн, но, думаю, аналогичным образом будет всё устроено и у других.
Я считаю что консольщики ничуть не хуже ПК игроков.
Я ещё раз повторю: если бы это был вопрос вкуса и т. д., то пекарей и консольщиков не растаскивали бы в разные песочницы в мультиплеерах. Это не вопрос вкуса, увы. Бюджета, себестоимости, компактности, но не вкуса.
Ну, не знаю, мне отлично играется в Rage или Mad Max на мыше с клавой.
Если серьёзно, у геймпада, наверное, есть преимущества в рейсерах, в которых и акселерация, и направление могут управляться аналоговыми контролами. Но тогда уж давайте сравнивать геймпады с рулями.
А так − мышь однозначно лучший аналоговый контроллер, чем стик. Так же и клавиатура однозначно лучший бинарный контроллер, чем кнопки геймпада.
Я думаю, их просто эксплуатировали в режиме ЧС, и к моменту заболевания их иммунитет уже был разрушен переутомлением. Видели фотографии медсестёр с кровоподтёками от хирургических масок? Если так работать, то можно и от обычного ОРВИ коньки отбросить.
У вас не хватило сил прочитать буквально следующий абзац?
Вряд ли кто-то подумает, что коронавирус ещё и излечивает людей, но, в то что он убивает каждого четвёртого старика верят многие. Хотя это одинаковые по степени абсурдности выводы.
Так что да, автор манипулирует цифрами для примера, в чём сам сразу же и признаётся. Вам не кажется, что ваш сеанс разоблачения после этой цитаты уже излишен?
Я именно этому доводу из статьи и оппонирую. Если динамические языки не помогают, то почему на статических языках так часто реализуют динамические системы типов?
Вы отчасти правы, у меня действительно «подгорает», когда мои любимые инструменты задвигают в угол. Но ответа на свой вопрос я всё-таки не получил. Допустим, го-свичеры написали cty, потому что заскучали по Пайтону, но как тогда насчёт GObject? А имплементациям этим нет числа, не зря появилось правило Гринспуна.
Они сначала так и думали. Но в процессе оказалось, что именно динамическая, потому что ноды разнородные, и где какой тип данных объявлен, непонятно. И валидировать её централизованно не всегда возможно, так как обрабатывает её сторонний код.
Статья, перевод которой мы сейчас читаем, написана фактически как продолжение дискуссии о том, действительно ли парсинг JSON в статических языках является таким уж адом, каким его зачастую описывают, или ничего, можно терпеть.
Автор вот говорит, что можно терпеть, и даже описывает какие-то best practices. Но я чаще слышу противоположное мнение. А лучшие практики ИМХО − это такие практики, которым проще следовать, чем не следовать. Когда их знаешь, конечно.
Когда вам говорят, что вы чего-то не знаете или не понимаете, а вы приравниваете это к обвинению в глупости − это в вас говорит снобизм или чувство превосходства. Мы все можем не знать или не понимать чего-либо, независимо от уровня нашего интеллекта. Но, чтобы уметь учиться, нужно быть открытым к разным точкам зрения.
А если вы хотите обоснований, можете познакомиться с проектом, в котором я долгое время варился. Он имеет весьма навороченную систему динамической типизации, маскирующуюся под сериализатор данных. Эта система порождает множество проблем, начиная с мелких багов и кончая принципиальной сложностью её более-менее интероперабильной, кросплатформенной реализации. А между тем разработчикам достаточно было встроить какой-нибудь динамический язык (благо, на JVM реализовано много универсальных ЯП: Python, Ruby, JavaScript, Lisp, Tcl), чтобы забыть о реестрах типов, версионировании объектов (Duck Typing), интеропе (те же ЯП встраиваются и в C++, и в C#) и много о чём ещё. Заодно и облегчить подключение кастомного кода при распределённых вычислениях. А критичные части системы (сеть, обнаружение нод, алгоритмы дупликации и восстановления данных) оставить как есть.
И хуже всего то, что разработчики и архитекторы на этом проекте действительно сильные и опытные, без иронии. Но, видимо, уверены в превосходстве статической типизации, как и вы, поэтому других вариантов, кроме как пилить велосипед, не видят (или не увидели вовремя, а теперь уже поздно).
Иными словами, я не против статически типизированных языков. Но когда то, что вы пишете на статическом языке, начинает сильно напоминать интерпретатор динамического языка (или, как минимум, его часть), имеет смысл не переизобретать велосипед, а выбрать готовый.
Вряд ли это основная причина. Скорее, наоборот, вполне себе опытные разработчики на статически типизированных ЯП не понимают, что такое динамические системы типов и зачем они нужны (некоторые вообще отрицают существование динамических типов). И поэтому вынуждены каждый раз переизобретать их.
Тогда зачем стопицотый проект на C, C++ или Java в стопицотый раз имплементирует динамическую систему типов вместо того, чтобы использовать по назначению уже имеющиеся в наличии Lua или там Groovy? По мне так явный NIH-синдром.
тогда я бы не стал спорить.
Потому что на консолях появилась возможность подключения клав-мышей. Для тех, кто не собирается пользоваться этой возможностью, в кроссплеях будет возможность поставить галку, чтобы не матчиться с мышатниками. Сужу по обзорам игр от активижн, но, думаю, аналогичным образом будет всё устроено и у других.
Я пишу о контроллерах, а не игроках.
Если серьёзно, у геймпада, наверное, есть преимущества в рейсерах, в которых и акселерация, и направление могут управляться аналоговыми контролами. Но тогда уж давайте сравнивать геймпады с рулями.
А так − мышь однозначно лучший аналоговый контроллер, чем стик. Так же и клавиатура однозначно лучший бинарный контроллер, чем кнопки геймпада.
То-то пекашники разделывают консольщиков в любых сетевых играх, включая недавний пример. Вопрос привычки, ага.
Так что да, автор манипулирует цифрами для примера, в чём сам сразу же и признаётся. Вам не кажется, что ваш сеанс разоблачения после этой цитаты уже излишен?
Автор вот говорит, что можно терпеть, и даже описывает какие-то best practices. Но я чаще слышу противоположное мнение. А лучшие практики ИМХО − это такие практики, которым проще следовать, чем не следовать. Когда их знаешь, конечно.
А если вы хотите обоснований, можете познакомиться с проектом, в котором я долгое время варился. Он имеет весьма навороченную систему динамической типизации, маскирующуюся под сериализатор данных. Эта система порождает множество проблем, начиная с мелких багов и кончая принципиальной сложностью её более-менее интероперабильной, кросплатформенной реализации. А между тем разработчикам достаточно было встроить какой-нибудь динамический язык (благо, на JVM реализовано много универсальных ЯП: Python, Ruby, JavaScript, Lisp, Tcl), чтобы забыть о реестрах типов, версионировании объектов (Duck Typing), интеропе (те же ЯП встраиваются и в C++, и в C#) и много о чём ещё. Заодно и облегчить подключение кастомного кода при распределённых вычислениях. А критичные части системы (сеть, обнаружение нод, алгоритмы дупликации и восстановления данных) оставить как есть.
И хуже всего то, что разработчики и архитекторы на этом проекте действительно сильные и опытные, без иронии. Но, видимо, уверены в превосходстве статической типизации, как и вы, поэтому других вариантов, кроме как пилить велосипед, не видят (или не увидели вовремя, а теперь уже поздно).
Иными словами, я не против статически типизированных языков. Но когда то, что вы пишете на статическом языке, начинает сильно напоминать интерпретатор динамического языка (или, как минимум, его часть), имеет смысл не переизобретать велосипед, а выбрать готовый.