> Чтобы обосновать квадратные колёса, их сначала надо сделать.
> Пустобрёхи в интернете предпочитают мозрительные рассуждения, но мир так не работает.Хорошо ты физиков-теоретиков и любителей сперва в среде моделирования спроектировать до того как металл портить. Но если Хокингу можно умозрительно осознать излучение черных дыр, я как-нибудь позволю себе анализ движения квадратного колеса ДО его выпиливания лобзиком, сорь.
> Умозрительные рассуждения хороши, когда под ними лежит обширный опыт. Но когда
> начинаешь делать квадратные колёса, чтобы пощупать на прочность то, что принято
> считать очевидным, набегают всякие, и начинают доказывать, что "тысячи лет делали
> круглые и не тужили, ты что думаешь, что самый умный, что ли"?
Есть такое явление. Поэтому оконвательным критерием - как это работает, пожалуй.
> Дело в том, что психика склонна не замечать стимулов, которые действуют постоянно.
Есть такой баг. Но есть и иной баг - когда в руках молоток, все вокруг кажется гвоздями. Возможно что это чрезмерная компенсация одного другим.
> человек говорит, что его всё устраивает и у него нет проблем,
> то это скорее говорит о том, что он хорошо адаптировался к
> своим проблемам и перестал их замечать, чем о том, что проблем у него нет.
Это вполне возможно. И звучит разумно. С другой стороны, у разных индивидов разные стили мышления и предпочтения. Возможно мой mindset больше подходит к сям чем твой. Мне вот например не требуются крутые абстракции, я хочу чтобы все было просто и прозрачно по возможности. Крутые абстракции и лишние сущности этому крайне не способствуют в управляющем софте.
И вообще, я видел примеры как чрезмерно увлекшиеся правильностью и абстракциями типы сливали проект, все приходило к тому что в их наворотах не разбирается ни 1 человек на планете. В этом плане у си жирный плюс: он на самом деле достаточно простой и не способствует наворачиванию слишком высокопарных абстракций.
> Это и в речи часто видно: начинаешь объяснять линуксоиду/вендовозу, что что-то там
> в его линуксе/венде неудобно и представляет проблему, а он отвечает, что "это не
> проблема", и решается она так-то и так-то. Может это просто из-за неудачного
> слова "проблема", может быть стоит пользоваться словом "трудность".
А может быть человек знает хорошее эффективное решение, которое ты не предусмотрел? Или ему так проще. Я например из винды не соберу конфигурации которые из линуха наворачиваю. Глобально это может быть иногда субоптимально. Локально - с линухом я по крайней мере решу задачу а не обломаюсь целиком.
> Хотя, они ведь начнут убеждать, что "это совсем не трудно", "трудно для безруких" и тп.
А знаешь, жизнь так устроена что немного де-идеализированное, приблизительное, чуток субоптимальное но рабочее решение - везде и всюду. Жизнь эмпирически нащупала эти подходы. Они работают. А перфекционизм в real-world проектах до добра не доводит.
> Это хорошо делать в законченном устройстве.
Фифти-фифти. Это наполовину дебажная фича. Баги бывают разные. Некоторые очевидны сразу. А некоторые случаются раз в неделю. Или год. Когда звезды в правильном расположении. И вот такая фича позволяет странное краевое условие поймать. Системы где так сделано я встречал и в законченном устройстве это "should never happen" если уж по хорошему. Но раз в год и палка стреляет.
> В нём по-крайней мере можно определить понятия "осмысленное состояние" и "режим".
Если это task-specific железка, эти понятия надо бы определить еще на фазе постановки требований, ну и дальше - проектирования и архитектуры системы. Чтобы осмысленно делать все остальное так как это уместно для этой задачи. Наоборот работает плохо.
> В устройстве же, которое создаётся ради исследования, с этим будут проблемы.
А это смотря что исследовать. Даже пардон в generic девбордах те кто их делает все-таки приходят к некоторому набору требований и пониманию того что и почему они хотят получить. Это дает им понимание как это лучше сделать и почему так.
> Я думаю, что надо просто повесить отдельный светодиод, и в тот вечный цикл воткнуть
> моргание этим светодиодом, предварительно прочистив табличку прерываний. Будет,
> по-крайней мере, индикация паники.
Возможно. И это просто в реализации. Но это для каких-то совсем абстрактных экспериментов, просто потому что "просто индикация паники" не позволяет понять что, где и почему произошло (и как с этим бороться).
> Может. Именно поэтому разработчиками до сих пор работают люди, а не программы.
Интересный тезис. А можно какое-то обоснование? Любопытно откуда именно это следует именно тут. Логическая цепочка не реконструируется...
> Если бы всё было просто, то с разработкой вполне справилась бы
> программа. Но это не значит, что надо забить на то, что говорят computer scientist'ы.
Как показал пример Таненбаума и Торвальдса, забить на высокопарные рассуждизмы может быть не самой плохой идеей на свете.
>> Я думаю что основной перк программиста - сделать задуманное. А автоматизировать есть смысл то что дает хороший выигрыш при минимуме усилий. А если выигрыш от автоматизации меньше чем затраты на нее, это завал теста на разумность существа.
> Сделать задуманное -- это профессиональное свойство, которое отличает хорошего программиста
> от плохого. А неуёмное стремление автоматизировать -- это то основополагающее свойство,
> которое делает из человека программиста.
Хороший программист, и особенно апгрейты вида PM/архитект/etc отличаются тем что когда они что-то делают - есть рациональное обоснование почему. Зуд все и вся автоматизировать сам по себе рациональным не является и может привести к страданию фигней когда невероятные усилия убиваются ради копеечного выигрыша. Это ни к чему хорошему не приводит. Если бы человек немного де-идеализировал ситуацию, смог бы сделать лучше, больше и возможно даже интереснее для самого себя, просто он об этом никогда не узнает, погрязнув в идеализме.
