>> Чтобы обосновать квадратные колёса, их сначала надо сделать.
>> Пустобрёхи в интернете предпочитают мозрительные рассуждения, но мир так не работает.
> Хорошо ты физиков-теоретиков и любителей сперва в среде моделирования спроектировать до
> того как металл портить. Но если Хокингу можно умозрительно осознать излучение
> черных дыр, я как-нибудь позволю себе анализ движения квадратного колеса ДО
> его выпиливания лобзиком, сорь.Физики-теоретики были бы совершенно бесполезными ребятами, если бы не эмпирики, которые построили LHC или отправляют аппараты на марс, чтобы померять магнитное поле, и показать, что существующие теоретические модели магнитного поля -- полнейшия туфта, только после этого физики-теоретики начали чесаться, и пришли к выводу, что они зря заложили в свои модели сферичность Марса. http://www.planetary.org/blogs/emily-lakdawalla/2008/1710.html
> И вообще, я видел примеры как чрезмерно увлекшиеся правильностью и абстракциями типы
> сливали проект, все приходило к тому что в их наворотах не
> разбирается ни 1 человек на планете. В этом плане у си
> жирный плюс: он на самом деле достаточно простой и не способствует
> наворачиванию слишком высокопарных абстракций.
А я видел, как те, кто просто брал и лепил как придётся, приходили к ситуации, когда они были не в состоянии двигать проект дальше. Я читал интересные рассказы о том, как проект пришёл к состоянию, в котором любое изменение, исправляющее баг, порождало пяток новых багов.
Я как-то читал статейку, в которой человек разбирал два условных подхода к написанию кода в стартапе -- хакерский и академический. Первый давал быстрый старт, ценой последующего прогрессирующего замедления, второй -- медленный старт, но затем выход на стабильную скорость разработки. А собственно вывод в том, что в стартапе подходы надо объединять, и начиная писать код, писать его так, чтобы затем его можно было бы итеративно переписать. А для этого, надо быть "хакером", и при этом быть докой в "академическом" подходе.
> Как показал пример Таненбаума и Торвальдса, забить на высокопарные рассуждизмы может быть
> не самой плохой идеей на свете.
Пример Торвальдса показывает ещё и то, что прежде чем браться за разработку ядра, надо магистратуру по специальности computer science закончить.
>> Хотя, они ведь начнут убеждать, что "это совсем не трудно", "трудно для безруких" и тп.
> А знаешь, жизнь так устроена что немного де-идеализированное, приблизительное, чуток субоптимальное
> но рабочее решение - везде и всюду. Жизнь эмпирически нащупала эти
> подходы. Они работают.
Я не верю в эти идеи. Нащупывает не жизнь, а человек, и чтобы нащупать он должен активно искать. Пассивое "все так делают" -- для слабаков. Если я сомневаюсь, в том что все делают хорошо, я пойду и попробую сделать лучше. Если мне удастся, то не сомневавшиеся будут выглядеть идиотами. Если мне не удастся, они тоже будут выглядеть идиотами, потому что я, в отличие от них, смогу объяснить, почему делать надо именно так, как они делают, а не иначе, причём не прибегая к аргументам вида "все так делают".
> А перфекционизм в real-world проектах до добра не доводит.
Грань между перфекционизмом и real-world -- это не что-то такое фундаментально определённое законами Вселенной. Это условность, которая определяется скиллами 95% программистов. Иногда эта условность пересматривается -- когда человечество накапливает критическую массу идей, когда это дополняется критической массой изменений в технологиях, внезапно случается "БУМ", и 95% оказываются старпёрами, потому что внезапно оказалось, что системно программировать надо на C, а они только в асме подсекают, а молодые быстрее них учатся.
Именно поэтому не стоит сидеть на жoпе ровно и ждать, когда "БУМ" случится. Надо упреждать. Впрочем, применительно к embedded, мне с профессиональной стороны совершенно не страшно отстать от трендов, так что я тут скорее выступаю в роли того, кто помогает человечеству накапливать критическую массу идей.
>> Может. Именно поэтому разработчиками до сих пор работают люди, а не программы.
> Интересный тезис. А можно какое-то обоснование? Любопытно откуда именно это следует именно
> тут. Логическая цепочка не реконструируется...
Если бы процесс разработки можно было бы свести к базе правил "если-то", то дальше было бы делом техники написать алгоритм, который опираясь на эту базу будет проводить процесс разработки. У нас нет таких алгоритмов, значит процесс разработки невозможно свести к базе правил "если-то". Вот и всё обоснование.
>> Если бы всё было просто, то с разработкой вполне справилась бы
>> программа. Но это не значит, что надо забить на то, что говорят computer scientist'ы.
> Хороший программист, и особенно апгрейты вида PM/архитект/etc отличаются тем что когда
> они что-то делают - есть рациональное обоснование почему. Зуд все и
> вся автоматизировать сам по себе рациональным не является и может привести
> к страданию фигней когда невероятные усилия убиваются ради копеечного выигрыша. Это
> ни к чему хорошему не приводит. Если бы человек немного де-идеализировал
> ситуацию, смог бы сделать лучше, больше и возможно даже интереснее для
> самого себя, просто он об этом никогда не узнает, погрязнув в
> идеализме.
Да, хороший программист должен научиться контролировать зуд всё и вся автоматизировать. Но он не станет программистом, без этого зуда. Без него, он может стать кодером, то есть тем кто сидит за клавиатурой и набирает код. Это тоже разновидность программиста, и такой программист может много чего создать, но он никогда не создаст ядра linux.
Вот как ты думаешь, каким образом можно стать таким PM'ом которого ты описываешь? Как можно научиться априри отличать усилия, которые дадут копеечный выигрыш, от усилий которые в конечном окупятся? Я вижу два подхода. Первый -- консервативный: "мы всегда делали так". Второй -- это обширный опыт, поверх которого выработана интуиция.
Но если ты, будешь следовать любому из этих подходов до того, как стал PM'ом, то ты не станешь PM'ом. При первом подходе твоё "мы всегда так делали" устареет до того, как тебя сделают PM'ом по выслуге лет. При втором подходе -- если ему следовать не имея интуиции, -- интуиция ниоткуда не возьмётся. Для интуиции нужен опыт, причём как успешный, так и неуспешный.
ps. просто ссылка в тему эмбеддед rust'а: http://blog.japaric.io/brave-new-io/
Очень вовремя ссылка появилась. Надо попробовать такое же для аврки сделать, посмотреть что получится.
Вот одно обломно, что компилятор нельзя заставить проверять максимальное время выполнения функции и выкидывать ошибки, если это время может превосходить заданное в заголовке функции значение.
