Классика IoT, там всё такое. Сама культура разработки такая.
Никто не задумывается об этом. В начале никто из исходного состава даже и не знает обо всех этих умных вещах. А потом уже все продается, работает, зачем городить огород там, где все и так хорошо?
Нас вполне может устроить какой-нибудь декларативный DSL. Бизнес-процессы зачастую типовые, а программисты часто занимаются лишь написанием интеграции.
Это не наш случай, ибо мы говорим про ИИ, способный заменить программиста, т.е. он должен быть способен решать задачу формализации в общем.
Множество людей достаточно развиты для использования естественного языка, но при этом в высоком искусстве не находят ничего очаровательного.
<sarcasm>
А искусствоведы — это вообще такие хитрые жуки, которые собирают деньги с наивных граждан за откровенную чепуху. Прям как философы какие-то.
</sarcasm>
Между "находить что-то очаровательным" и "быть способным это что-то создать" довольно большая разница. При этом характеристика "быть очаровательным", очевидно, не должна входить в любое приемлемое определение произведения искусства.
Во-первых, предыдущий комментарий предполагает наличие мифической сущности "настоящий ИИ". Как мы понимаем, это сильно меняет дело.
Во-вторых, "объективно измеримый практический результат" — это не про разработку софта. С точки зрения программиста результатом его работы является программный код. Для объективной оценки кода требуется его проверить на корректность, т.е. соответствие формальным требованиям. Процесс создания формальных требований сам по себе не формализуем. Таким образом нам требуется ИИ достаточно мощный, чтобы работать на семантическом (т.е. понятийном) уровне естественных языков. Это уже ставит его на уровень достаточный для понимания и оценки искусства.
Вопрос: почему такой ИИ не сможет создавать произведения искусства?
А чем артисты и художники принципиально отличаются? ИИ будут ровно так же синтезировать музыку/изображения/тексты. Более того, при достаточных вычислительных ресурсах, человек может попросить "а сделай мне Х с характеристиками A, Б и В", ИИ подумает немного и выдаст готовое произведение. Просто и удобно.
И не нужны будут ни программисты, ни инженеры, ни художники, ни артисты.
Нет, не кажется. Если проект делать очень долго, то это уже сильно добавляет сложности само по себе. У людей есть жизнь, которая имеет ограниченную продолжительность, и потребности, которые требуют материальных ресурсов для их удовлетворения. И выгорание — реальность жизни, если человек готов потратить полгода на проект, значит нужен проект на полгода. Либо нужен другой человек через полгода.
Грубо говоря, есть большая разница в организационной сложности. Большим, продолжительным проектом значительно труднее управлять, планирование становится кошмаром, бюджеты сложно оценивать, а из-за постоянных изменений (которые неизбежно будут) все заранее намеченные вчера планы завтра могут кардинально измениться. Более того, сложившаяся практика управления может быть просто не подходящей для доведения проекта до конца. В конечном счете, именно управление процессами может спасти или утопить проект при том самом выгорании.
Во-вторых, есть большая разница в сложности создания цельного и увлекательного игрового процесса. Множество различных механик порождает огоромное количество сочетаний, добавление новых влечет изменения в старых, которые порождают новые изменения и т.д. Это такой порочный круг, причем большее число механик делают круг только больше. И это только на стадии их создания. Потом, после их реализации, приходит понимание о необходимости изменений, по разным причинам, от простых "это не интересно" или "это сильно сложно" до классической "это отрицательно влияет на игровой баланс". В итоге может получиться, что вроде и возможностей очень много, но чего-то цельного не получается. Иногда идеи просто не работают.
В-третьих, техническая сложность нелинейна от размера. Чем больше кодовая база, тем сложнее вносить дополнения или изменения. А так как стабилизация требований будет происходить очень поздно в цикле разработки, это повлечет огромное количество этих самых изменений. Что очень часто негативно сказывается на качестве.
В конечном счете "невероятно сложно" значит очень простое "очень мало кто на это способен". И неспособность потратить на что-то неограниченное количество времени — одна из причин. Точно так же почти кто угодно может (в теории) переплыть Ла-Манш, но сколько людей реально это могут?
Советуют в основном из-за того простого факта, что нуля сделать игру сложно. А большую игру невероятно сложно. Ведь многие новички приходят с идеями в стиле "я хочу сделать игру как третий ведьмак, но с добавлением вот этих замечательных идей (тут идет перечисление на три листа)".
Почти любая деятельность начинается с небольших проектов, где люди оттачивают базовые навыки, которые нужны постоянно. При этом разработка игр сложна тем, что требует множество различных навыков. И один из самых сложных — умение управлять проектами, даже большие успешные студии, делающие AAA проекты, постоянно испытывают сложности с этим. Сделав небольшой работающий проект будет уже понятно, что программисты умеют работать с движком и реализовывать игровую логику, геймдизайнеры имеют представление о том, как делать и балансировать игровые механики, сценаристы умеют придумывать сюжет и делать интересных персонажей, и т.д.
Более того, на поздних стадиях начинаются задачи, которые на начальных этапах вообще никак не появляются. Поиск издателя, работа с сообществом, даже банальный вопрос того, как об этой игре будут узнавать будущие игроки. И будет очень грустно, если крупный проект, который довели невероятными усилиями до приемлемого состояния, развалится на этой стадии. У начинающих студий чаще всего нет людей, которые это уже умеют. Просто потому что эти все вопросы решили люди, которые выпустили уже игру. И нужно либо в экстренном режиме получать новые знания, либо искать новых людей, которые это умеют.
Поэтому небольшой проект даст хотя бы некоторое представление о том, способны ли эти люди в принципе реализовать что-то. Очень просто может оказаться, что на каком-то этапе часть потеряет интерес, часть поссорится со всеми, часть окажется просто плохи в том, за что они взялись, а часть поймет, что разработка игр им на самом деле не интересно, а они хотят от жизни что-то совсем другое.
Коммерческое инди имеет довольно узкий коридор целесообразности проектов (я не говорю про тех, кто это делает по фану, получая основные средства из других источников). Типичная инди студия не обладает огромным бюджетом для разработки в течении долгого времени большой коммандой. Игру нужно сделать в краткие сроки ограниченным количеством людей, либо будет грустно и голодно. Даже если задумывать большой проект, нужно из него выделить небольшую часть, которую можно быстро сделать и выпустить, начав получать средства на дальнейшее развитие. Поэтому многие остаются на уровне некрупных проектов. Они нашли свою нишу, где они делают хорошие, продаваемые проекты, которые приносят стабильный доход.
Плохо ли это? Зависит от ситуации конкретного человека или студии. Готовы ли они на большой риск? Есть ли у него семья? Скажем, студия может начать с кучки 20-летних студентов, готовых работать за еду идею. Но время идет, у кого-то появилась семья, кто-то взял ипотеку, кто-то не может работать в авральном режиме за копейки, кто-то просто хочет более высокий уровень жизни. Крупный проект может иметь цикл разработки в несколько лет. И если начать с него, то высока вероятность, что к этому моменту он будет просто не готов, а люди не будут готовы продолжать работать за идею.
Поэтому многие статьи сразу говорят "не пытайтесь откусить сразу столько, сколько вы не сможете прожевать".
Такое бывает, но редко. Чаще всего из-за сильной географической разнесенности. ДЦ выгоднее размесить неподалеку от источников энергии и каналов связи, это обычно приводит к их размещению неподалеку от городов. Теплицы же (и подобные с/х конструкции) обычно требуют больших площадей, что обычно приводит к их размещению на некотором удалении от городов. Так что они редко бывают в зоне, где это будет выгодно. При этом важно учитывать, что теплицы устроены так, что полезное отопление от ДЦ возможно только в сильно ограниченном диапозоне условий (теплица — классический аккумулятор тепла). И подобная ситуация не только с теплицами, большая часть потребителей тепла либо далеко, либо затраты на создание и поддержку инфраструктуры слишком велики.
Кто-то, наверное, и проверял. Вдруг это не один человек, а комитет из троих марксистов, своими ответами (и книгами) заражающий неокрепшие умы разработчиков коммунистическими идеями.
В странах, где правят проклятые капиталисты, так и есть: врачи получают сравнимо (а то и много больше) программистов. Просто потому что рыночный спрос на здоровье выше. Ничего специально делать не пришлось.
Капиталисты правят почти везде, а вот врачи много получают только в хорошо развитых странах (условный Запад). Благодаря глобализации программисты могут предлагать свой труд на глобальном рынке, что позволяет получать много по сравнению с остальным населением своей страны, а вот с врачами такой фокус уже не работает. Если страна с невысоким уровнем жизни запретит гражданам страны работать на зарубежных заказчиков, то уровень доходов программистов резко упадёт.
Нужно больше треша и угара. Предлагаю быстренько переписать статью в сценарий для фильма категории Б.
Берем историю про, например, молодого создателя (далее ГГ, главный герой) очередной биткоин-фермы. Сам он из маленького городка в Айове.
В один прекрасный день к нему пришли поговорить вежливые люди в дорогих костюмах, после определенного убеждения он понимает, что работая совместно с ними он может достичь намного большего. Недолго думая, он соглашается. Получив от них секретные коды, его ферма начинает работать супер-эффективно, принося огромные прибыли.
ГГ переезжает в Калифорнию, покупает огромный дом неподалеку от океана, начинает встречаться с молодой красоткой, на которой вскоре женится. Жизнь, можно сказать, удалась.
Но его терзают сомнения в выборе, он подозревает, что не всё так просто. В своих поисках, он выходит на бывшего сотрудника ЦРУ. Они общаются через посредника — дочь этого агента (далее ПГ, подруга героя). ГГ выясняет, что на самом деле за биткоином стоят русские, а вежливые люди — агенты Москвы. После очередного разговора, когда ГГ собирается уходить, ПГ говорит ему, чтобы он был осторожен.
Дальше его похищают, жена оказывается агентом, приставленным с целью слежки. Но с помощью ПГ он спасается. Затем ГГ тренируется, готовится к борьбе, в итоге получает +10 к брутальности. После несколько перестрелок, погонь и прочих эффектных моментов, ГГ с ПГ убивают всех врагов, а так же уничтожают ферму со всеми биткоинами. В один из напряженных моментов ГГ и ПГ должны понять, что любят друг друга.
Фильм заканчивается тем, как ГГ с ПГ уезжают в закат.
Нет, но у const принципиально иное поведение. Они не хранят значение, но компилятор подставляет его во все места, где они используются. Поэтому пока что возможны только константы примитивных типов.
const int c = 3;
...
var x = c; // компилятор подставит 3 на место c
...
object p { get; } = new object();
...
var y = p; // произойдет обращение к свойству
У вас ошибка в предположениях, имелись в виду отдельные логические части не системы, но процесса обработки. Одного, но большого. Который вполне себе разделяется на более маленькие части. Хотя они сильно связанные, но их публичными делать не надо. Переиспользоваться 99% из них внешними тоже не будут, ибо они имеют смысл только в контексте данного процесса. И из-за переменчивой структуры реальности смысла вводить жесткий интерфейс между ними нет.
Но даже если рассматривать более большие части, в чем принципиальное преимущество DTO перед именованными кортежами из двух-трех значений?
Их можно наследовать? На мой взгляд, если вам нужно наследовать DTO, то всё свернуло куда-то не туда. Наследование вообще нужно применять минимально и стараться избегать наследования данных. А так как DTO из себя представляют чистые данные, которые кто-то запихнул в оболочку объекта (из-за отсутсвия более подходящих средств для их удержания), то наследовать их не надо.
Их можно документировать? Да, возможно, но какой в этом смысл? Если у вас DTO из двух-трех членов требует документации, то возникают вопросы "а что эти данные вообще делают вместе" и "а не пора ли это отрефакторить"
Вот есть довольно длинная обработка данных, где мы что-то читаем, куда-то пишем, делаем запросы, при разных условиях делаем разные действия в разной последовательности.
После разделения на отдельные логические части нам требуется способ обменяться данными. Есть два варианта — предложенные кортежи и куча DTO.
Чем огромная куча DTO лучше? Она волшебным образом делает код "поддерживаемым, расширяемым и тестируемым"? Нет, просто появится кучка новых классов, которые используются в одном месте.
В философии. Если приложение имеет область отображения, разделенную между компонентами, то HTML и CSS изначально создавались с идеей бесконечно растущего вниз текста.
Тут, например, растут уши у тысячи и одного костыля для того, чтобы web-приложение вело себя подобно десктопному/мобильному.
Более того, из-за этого HTML и CSS имеют очень слабую поддержку постраничного отображения информации (для печати, к примеру).
Не имею такой привычки. Зато сарказм иногда через край капает, прошу прощения, если невзначай обидел. В намерения не входило. :)
Вы прям мастерски через край сарказмируете, что…… хотя нет, сарказмом тут и не пахнет, ведь этот прием построен на игре между прямым и подразумеваемым смыслами. Тут скорее самодовольная глумливость и покровительственная хамоватость.
А чем неуместно? Или у процессоров и ракет-носителей подобных проблем нет?
Классика IoT, там всё такое. Сама культура разработки такая.
Никто не задумывается об этом. В начале никто из исходного состава даже и не знает обо всех этих умных вещах. А потом уже все продается, работает, зачем городить огород там, где все и так хорошо?
Это не наш случай, ибо мы говорим про ИИ, способный заменить программиста, т.е. он должен быть способен решать задачу формализации в общем.
<sarcasm>
А искусствоведы — это вообще такие хитрые жуки, которые собирают деньги с наивных граждан за откровенную чепуху. Прям как философы какие-то.
</sarcasm>
Между "находить что-то очаровательным" и "быть способным это что-то создать" довольно большая разница. При этом характеристика "быть очаровательным", очевидно, не должна входить в любое приемлемое определение произведения искусства.
Во-первых, предыдущий комментарий предполагает наличие мифической сущности "настоящий ИИ". Как мы понимаем, это сильно меняет дело.
Во-вторых, "объективно измеримый практический результат" — это не про разработку софта. С точки зрения программиста результатом его работы является программный код. Для объективной оценки кода требуется его проверить на корректность, т.е. соответствие формальным требованиям. Процесс создания формальных требований сам по себе не формализуем. Таким образом нам требуется ИИ достаточно мощный, чтобы работать на семантическом (т.е. понятийном) уровне естественных языков. Это уже ставит его на уровень достаточный для понимания и оценки искусства.
Вопрос: почему такой ИИ не сможет создавать произведения искусства?
А чем артисты и художники принципиально отличаются? ИИ будут ровно так же синтезировать музыку/изображения/тексты. Более того, при достаточных вычислительных ресурсах, человек может попросить "а сделай мне Х с характеристиками A, Б и В", ИИ подумает немного и выдаст готовое произведение. Просто и удобно.
И не нужны будут ни программисты, ни инженеры, ни художники, ни артисты.
Насколько я понимаю, Blender Eevee не использует трассировку лучей для рендеринга. Если я не прав, можете показать, где почитать про их рендер?
То есть клиентский код должен знать почему именно объект невалиден? Зачем тогда нужен валидатор?
Нет, не кажется. Если проект делать очень долго, то это уже сильно добавляет сложности само по себе. У людей есть жизнь, которая имеет ограниченную продолжительность, и потребности, которые требуют материальных ресурсов для их удовлетворения. И выгорание — реальность жизни, если человек готов потратить полгода на проект, значит нужен проект на полгода. Либо нужен другой человек через полгода.
Грубо говоря, есть большая разница в организационной сложности. Большим, продолжительным проектом значительно труднее управлять, планирование становится кошмаром, бюджеты сложно оценивать, а из-за постоянных изменений (которые неизбежно будут) все заранее намеченные вчера планы завтра могут кардинально измениться. Более того, сложившаяся практика управления может быть просто не подходящей для доведения проекта до конца. В конечном счете, именно управление процессами может спасти или утопить проект при том самом выгорании.
Во-вторых, есть большая разница в сложности создания цельного и увлекательного игрового процесса. Множество различных механик порождает огоромное количество сочетаний, добавление новых влечет изменения в старых, которые порождают новые изменения и т.д. Это такой порочный круг, причем большее число механик делают круг только больше. И это только на стадии их создания. Потом, после их реализации, приходит понимание о необходимости изменений, по разным причинам, от простых "это не интересно" или "это сильно сложно" до классической "это отрицательно влияет на игровой баланс". В итоге может получиться, что вроде и возможностей очень много, но чего-то цельного не получается. Иногда идеи просто не работают.
В-третьих, техническая сложность нелинейна от размера. Чем больше кодовая база, тем сложнее вносить дополнения или изменения. А так как стабилизация требований будет происходить очень поздно в цикле разработки, это повлечет огромное количество этих самых изменений. Что очень часто негативно сказывается на качестве.
В конечном счете "невероятно сложно" значит очень простое "очень мало кто на это способен". И неспособность потратить на что-то неограниченное количество времени — одна из причин. Точно так же почти кто угодно может (в теории) переплыть Ла-Манш, но сколько людей реально это могут?
Советуют в основном из-за того простого факта, что нуля сделать игру сложно. А большую игру невероятно сложно. Ведь многие новички приходят с идеями в стиле "я хочу сделать игру как третий ведьмак, но с добавлением вот этих замечательных идей (тут идет перечисление на три листа)".
Почти любая деятельность начинается с небольших проектов, где люди оттачивают базовые навыки, которые нужны постоянно. При этом разработка игр сложна тем, что требует множество различных навыков. И один из самых сложных — умение управлять проектами, даже большие успешные студии, делающие AAA проекты, постоянно испытывают сложности с этим. Сделав небольшой работающий проект будет уже понятно, что программисты умеют работать с движком и реализовывать игровую логику, геймдизайнеры имеют представление о том, как делать и балансировать игровые механики, сценаристы умеют придумывать сюжет и делать интересных персонажей, и т.д.
Более того, на поздних стадиях начинаются задачи, которые на начальных этапах вообще никак не появляются. Поиск издателя, работа с сообществом, даже банальный вопрос того, как об этой игре будут узнавать будущие игроки. И будет очень грустно, если крупный проект, который довели невероятными усилиями до приемлемого состояния, развалится на этой стадии. У начинающих студий чаще всего нет людей, которые это уже умеют. Просто потому что эти все вопросы решили люди, которые выпустили уже игру. И нужно либо в экстренном режиме получать новые знания, либо искать новых людей, которые это умеют.
Поэтому небольшой проект даст хотя бы некоторое представление о том, способны ли эти люди в принципе реализовать что-то. Очень просто может оказаться, что на каком-то этапе часть потеряет интерес, часть поссорится со всеми, часть окажется просто плохи в том, за что они взялись, а часть поймет, что разработка игр им на самом деле не интересно, а они хотят от жизни что-то совсем другое.
Коммерческое инди имеет довольно узкий коридор целесообразности проектов (я не говорю про тех, кто это делает по фану, получая основные средства из других источников). Типичная инди студия не обладает огромным бюджетом для разработки в течении долгого времени большой коммандой. Игру нужно сделать в краткие сроки ограниченным количеством людей, либо будет грустно и голодно. Даже если задумывать большой проект, нужно из него выделить небольшую часть, которую можно быстро сделать и выпустить, начав получать средства на дальнейшее развитие. Поэтому многие остаются на уровне некрупных проектов. Они нашли свою нишу, где они делают хорошие, продаваемые проекты, которые приносят стабильный доход.
Плохо ли это? Зависит от ситуации конкретного человека или студии. Готовы ли они на большой риск? Есть ли у него семья? Скажем, студия может начать с кучки 20-летних студентов, готовых работать за
едуидею. Но время идет, у кого-то появилась семья, кто-то взял ипотеку, кто-то не может работать в авральном режиме за копейки, кто-то просто хочет более высокий уровень жизни. Крупный проект может иметь цикл разработки в несколько лет. И если начать с него, то высока вероятность, что к этому моменту он будет просто не готов, а люди не будут готовы продолжать работать за идею.Поэтому многие статьи сразу говорят "не пытайтесь откусить сразу столько, сколько вы не сможете прожевать".
Такое бывает, но редко. Чаще всего из-за сильной географической разнесенности. ДЦ выгоднее размесить неподалеку от источников энергии и каналов связи, это обычно приводит к их размещению неподалеку от городов. Теплицы же (и подобные с/х конструкции) обычно требуют больших площадей, что обычно приводит к их размещению на некотором удалении от городов. Так что они редко бывают в зоне, где это будет выгодно. При этом важно учитывать, что теплицы устроены так, что полезное отопление от ДЦ возможно только в сильно ограниченном диапозоне условий (теплица — классический аккумулятор тепла). И подобная ситуация не только с теплицами, большая часть потребителей тепла либо далеко, либо затраты на создание и поддержку инфраструктуры слишком велики.
Кто-то, наверное, и проверял. Вдруг это не один человек, а комитет из троих марксистов, своими ответами (и книгами) заражающий неокрепшие умы разработчиков коммунистическими идеями.
Капиталисты правят почти везде, а вот врачи много получают только в хорошо развитых странах (условный Запад). Благодаря глобализации программисты могут предлагать свой труд на глобальном рынке, что позволяет получать много по сравнению с остальным населением своей страны, а вот с врачами такой фокус уже не работает. Если страна с невысоким уровнем жизни запретит гражданам страны работать на зарубежных заказчиков, то уровень доходов программистов резко упадёт.
Нужно больше треша и угара. Предлагаю быстренько переписать статью в сценарий для фильма категории Б.
Берем историю про, например, молодого создателя (далее ГГ, главный герой) очередной биткоин-фермы. Сам он из маленького городка в Айове.
В один прекрасный день к нему пришли поговорить вежливые люди в дорогих костюмах, после определенного убеждения он понимает, что работая совместно с ними он может достичь намного большего. Недолго думая, он соглашается. Получив от них секретные коды, его ферма начинает работать супер-эффективно, принося огромные прибыли.
ГГ переезжает в Калифорнию, покупает огромный дом неподалеку от океана, начинает встречаться с молодой красоткой, на которой вскоре женится. Жизнь, можно сказать, удалась.
Но его терзают сомнения в выборе, он подозревает, что не всё так просто. В своих поисках, он выходит на бывшего сотрудника ЦРУ. Они общаются через посредника — дочь этого агента (далее ПГ, подруга героя). ГГ выясняет, что на самом деле за биткоином стоят русские, а вежливые люди — агенты Москвы. После очередного разговора, когда ГГ собирается уходить, ПГ говорит ему, чтобы он был осторожен.
Дальше его похищают, жена оказывается агентом, приставленным с целью слежки. Но с помощью ПГ он спасается. Затем ГГ тренируется, готовится к борьбе, в итоге получает +10 к брутальности. После несколько перестрелок, погонь и прочих эффектных моментов, ГГ с ПГ убивают всех врагов, а так же уничтожают ферму со всеми биткоинами. В один из напряженных моментов ГГ и ПГ должны понять, что любят друг друга.
Фильм заканчивается тем, как ГГ с ПГ уезжают в закат.
Пустить через локальный прокси с SSL?
Нет, но у const принципиально иное поведение. Они не хранят значение, но компилятор подставляет его во все места, где они используются. Поэтому пока что возможны только константы примитивных типов.
У вас ошибка в предположениях, имелись в виду отдельные логические части не системы, но процесса обработки. Одного, но большого. Который вполне себе разделяется на более маленькие части. Хотя они сильно связанные, но их публичными делать не надо. Переиспользоваться 99% из них внешними тоже не будут, ибо они имеют смысл только в контексте данного процесса. И из-за переменчивой структуры реальности смысла вводить жесткий интерфейс между ними нет.
Но даже если рассматривать более большие части, в чем принципиальное преимущество DTO перед именованными кортежами из двух-трех значений?
Их можно наследовать? На мой взгляд, если вам нужно наследовать DTO, то всё свернуло куда-то не туда. Наследование вообще нужно применять минимально и стараться избегать наследования данных. А так как DTO из себя представляют чистые данные, которые кто-то запихнул в оболочку объекта (из-за отсутсвия более подходящих средств для их удержания), то наследовать их не надо.
Их можно документировать? Да, возможно, но какой в этом смысл? Если у вас DTO из двух-трех членов требует документации, то возникают вопросы "а что эти данные вообще делают вместе" и "а не пора ли это отрефакторить"
const в C# используется для констант времени компиляции, здесь же после установки свойства при создании объекта оно больше не будет меняться
Вот есть довольно длинная обработка данных, где мы что-то читаем, куда-то пишем, делаем запросы, при разных условиях делаем разные действия в разной последовательности.
После разделения на отдельные логические части нам требуется способ обменяться данными. Есть два варианта — предложенные кортежи и куча DTO.
Чем огромная куча DTO лучше? Она волшебным образом делает код "поддерживаемым, расширяемым и тестируемым"? Нет, просто появится кучка новых классов, которые используются в одном месте.
В философии. Если приложение имеет область отображения, разделенную между компонентами, то HTML и CSS изначально создавались с идеей бесконечно растущего вниз текста.
Тут, например, растут уши у тысячи и одного костыля для того, чтобы web-приложение вело себя подобно десктопному/мобильному.
Более того, из-за этого HTML и CSS имеют очень слабую поддержку постраничного отображения информации (для печати, к примеру).
Вы прям мастерски через край сарказмируете, что…… хотя нет, сарказмом тут и не пахнет, ведь этот прием построен на игре между прямым и подразумеваемым смыслами. Тут скорее самодовольная глумливость и покровительственная хамоватость.