Pull to refresh
154
0
Никита Прокопов @tonsky

Пользователь

Send message
Не, я думал речь о том, чтобы на ассемблере именно писать. Если программу просто дизассемблировать, непонятно, откуда у нее возьмется выигрыш в производительности?
Если человек программист, то результатом его труда является код. И на этом фронте он должен сделать все, что может. Хороший код, как минимум, гарантирует гибкость и сопровождаемость. Ну, как от сапожника, вы же не ждете, что он вас жизни научит, а ждете, что он ботинок починит. Женитесь вы в этом ботинке или нет — гораздо более важный вопрос, конечно, но сапожник-то тут причем?
Предсказуемость результата есть признак профессионализма. Программа, действительно, может не выстрелить. Ее успех, действительно, не зависит от качества кода внутри. Но это не означает, что не надо уметь и писать, насколько умеешь, хороший код.
Штука еще в том, что JIT может менять набор инструкций в зависимости от конкретной ситуации, а код на ассемблере всегда статичный. Так что даже тут не все однозначно.
Вот очень интересный разбор от Фаулера The LMAX Architecture. На таких скоростях решает там, внимание, понимание работы современного железа.
Предлагаю также Даун Хаус, там главный герой между прочим программист.
А можете объяснить, каким образом Blade Runner про IT? Там же евгеника, людей выращивали?
Всё правильно про философию он говорит, это же один-в-один экранизация мифа о пещере Платона.
Ничего себе, один из самых айтишных представителей всего здесь перечисленного.
С паршивой овцы хоть шерсти клок :)
Нет, у него все правильно написано — дизайнер о юзабилити должен знать куда больше, чем программист. В реальности, как вы и говорите, это к сожалению не так.
Скорее кодер+тестер+сисадмин, то, что в веб-студиях называется «технолог».
Мой пока не заполнен, и я бы не назвал описанные знания бесполезными. То есть, если бы Ватсон рассказал Холмсу, как именно он может использовать эти знания в своей работе (о чем моя статья), так просто откреститься от них не получилось бы.
Это те самые эмпирические знания, накопленные программистской культурой, да. Но не все, необходимые для хорошего кода, и под ними нет системы, нельзя проследить, почему это работает, а это нет, можно только запомнить.
Да, это один из самых очевидных плюсов — делать работу проектировщика.

Зачем серверному программисту знать юзабилити? Чтобы потом бэкэнд сшился с фронтэндом без проблем. Бэкэнд определяет достаточно много потребительских качеств (скорость реакции системы, устройство бизнес-процессов, надежность), поэтому даже серверсайд программисту неплохо бы представлять, как то, что он делает, повлияет на использование системы конечными пользователями. Если он не знает точно, что и зачем он делает, успех продукта — только вопрос случая.
Еще раз, я, равно как и любой другой пользователь, готов понять и принять ограничения, накладываемые возможностями железа, программ, человеческого организма.

Я лишь указываю (в силу знания внутреннего устройства софта), что есть места, где часть ограничений можно снять, и это будет иметь практический смысл.

А вы все приводите примеры из серии «я смогу это сломать» и «я знаю, кому это не нужно». Но продукт определяется не этим.
Да я и не стираю. Хотя при чем тут .DS_Store — я же попросил всегда показывать одинаково…
Заниматься работой во время установки будет значительно дольше, чем установить и потом работать.


Я ж не полет обсчитываю, а в браузере сижу да код пописываю. Человек взаимодействует с компьютером небольшими всплесками активности, все остальное время компьютер может заниматься своими делами, и это прекрасно параллелится.
А что я могу предложить? Я-то считаю, что все описанное давным-давно можно было реализовать. Вы хотите меня опровергнуть?

Вот вам примеры: Фоновый рендеринг Final Cut Pro? Автоматическое обновление Хрома? Восстановление после крэша ИнДизайна?

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity