Не, я думал речь о том, чтобы на ассемблере именно писать. Если программу просто дизассемблировать, непонятно, откуда у нее возьмется выигрыш в производительности?
Если человек программист, то результатом его труда является код. И на этом фронте он должен сделать все, что может. Хороший код, как минимум, гарантирует гибкость и сопровождаемость. Ну, как от сапожника, вы же не ждете, что он вас жизни научит, а ждете, что он ботинок починит. Женитесь вы в этом ботинке или нет — гораздо более важный вопрос, конечно, но сапожник-то тут причем?
Предсказуемость результата есть признак профессионализма. Программа, действительно, может не выстрелить. Ее успех, действительно, не зависит от качества кода внутри. Но это не означает, что не надо уметь и писать, насколько умеешь, хороший код.
Штука еще в том, что JIT может менять набор инструкций в зависимости от конкретной ситуации, а код на ассемблере всегда статичный. Так что даже тут не все однозначно.
Нет, у него все правильно написано — дизайнер о юзабилити должен знать куда больше, чем программист. В реальности, как вы и говорите, это к сожалению не так.
Мой пока не заполнен, и я бы не назвал описанные знания бесполезными. То есть, если бы Ватсон рассказал Холмсу, как именно он может использовать эти знания в своей работе (о чем моя статья), так просто откреститься от них не получилось бы.
Это те самые эмпирические знания, накопленные программистской культурой, да. Но не все, необходимые для хорошего кода, и под ними нет системы, нельзя проследить, почему это работает, а это нет, можно только запомнить.
Да, это один из самых очевидных плюсов — делать работу проектировщика.
Зачем серверному программисту знать юзабилити? Чтобы потом бэкэнд сшился с фронтэндом без проблем. Бэкэнд определяет достаточно много потребительских качеств (скорость реакции системы, устройство бизнес-процессов, надежность), поэтому даже серверсайд программисту неплохо бы представлять, как то, что он делает, повлияет на использование системы конечными пользователями. Если он не знает точно, что и зачем он делает, успех продукта — только вопрос случая.
Еще раз, я, равно как и любой другой пользователь, готов понять и принять ограничения, накладываемые возможностями железа, программ, человеческого организма.
Я лишь указываю (в силу знания внутреннего устройства софта), что есть места, где часть ограничений можно снять, и это будет иметь практический смысл.
А вы все приводите примеры из серии «я смогу это сломать» и «я знаю, кому это не нужно». Но продукт определяется не этим.
Заниматься работой во время установки будет значительно дольше, чем установить и потом работать.
Я ж не полет обсчитываю, а в браузере сижу да код пописываю. Человек взаимодействует с компьютером небольшими всплесками активности, все остальное время компьютер может заниматься своими делами, и это прекрасно параллелится.
Зачем серверному программисту знать юзабилити? Чтобы потом бэкэнд сшился с фронтэндом без проблем. Бэкэнд определяет достаточно много потребительских качеств (скорость реакции системы, устройство бизнес-процессов, надежность), поэтому даже серверсайд программисту неплохо бы представлять, как то, что он делает, повлияет на использование системы конечными пользователями. Если он не знает точно, что и зачем он делает, успех продукта — только вопрос случая.
Я лишь указываю (в силу знания внутреннего устройства софта), что есть места, где часть ограничений можно снять, и это будет иметь практический смысл.
А вы все приводите примеры из серии «я смогу это сломать» и «я знаю, кому это не нужно». Но продукт определяется не этим.
Я ж не полет обсчитываю, а в браузере сижу да код пописываю. Человек взаимодействует с компьютером небольшими всплесками активности, все остальное время компьютер может заниматься своими делами, и это прекрасно параллелится.
Вот вам примеры: Фоновый рендеринг Final Cut Pro? Автоматическое обновление Хрома? Восстановление после крэша ИнДизайна?