Здравствуйте, LaptevVV, Вы писали:
LVV>Разработчики железа не пишут на JS, Python, C++ прочей ненадежной лабуде. LVV>Чтобы писать надежные программы, умолчания должны быть ЗАПРЕЩЕНЫ от слова совсем. LVV>За неявные преобразования — РАССТРЕЛ.
Но только VHDL больше похож на PL/1, чем на Go...
LVV>А разработчик Go вообще закончил виртовскую школу. Хоть и работает в гугле.
МР>Т.е. пока вероятные потери от ненадежного ПО не будут превышать затрат на обеспечения его надежности — никто не этой самой надежностью заниматься и не будет.
Тут еще играет роль, что абсолютно подавляющему большинству софта надежность и не нужна.
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
O>При этом часто встречается в компаниях разделение программистов на тех кто пишет софт ( добавляет фичи, фиксит баги ) и тех кто его поддерживает ( фиксит критичные баги в срочном порядке ). O>Причем некоторые крупные компании ( где ошибки в ПО сильно критичны ) берут инженеров других компаний, которые фиксят критичные баги которые возникают в процессе работы.
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Всё до безумия просто. Вот есть у нас, допустим, программист-бракодел Вася.
1. Вася пишет свою игру и хочет продать её за "дофига денег" в размере $2000. В процессе написания кода монетизации Вася сделает ошибку, при которой у него пользователям не будет показываться реклама. Это будет критическая ошибка для бизнеса, но пользователи ничего особо не заметят. Вася не будет получать доход от рекламы, пока не поправит ошибку, что будет стоить ему $100, но мир даже не заметит этот баг.
2. Вася поправил ошибку, теперь реклама показывается на весь экран и не убирается. Пользователи, увидев такую фигню, массово свалили. Игровой бизнес Васи разрушен, он "потерял" $2000, но миру всё ещё пофиг.
3. Потеряв надежду найти себя в бизнесе, но приобретя опыт, Вася устроился на работу в крупную игровую контору. Там его поставили писать игровой чат и, через некоторое время, Вася "положил" этот чат на целые сутки. Рейд-группа, бившая крупного босса, осталась без нормального взаимодействия, завалила бой, пошла на игровой форум и крупно "нагадила в сообщения". Продажи игры упали, примерный ущерб владельцы бизнеса оценили в $4000. Васе сказали, какой он нехороший человек. Мир погудел пару дней о "криворуких программистах" и забыл эту тему.
4. Васю, тем временем, перевели на правки сетевого протокола игры, где он через некоторое время также отличился. В течение выходных игра работала криво, что привело к массовому оттоку пользователей. Примерный ущерб составил порядка $100000. Руководство начало что-то подозревать, и решило уволить Васю "от греха подальше".
5. Через некоторое время Вася по знакомству устроился на работу в банк. Там тоже всё шло не очень гладко — из-за его ошибки упал модуль процессинга всех оплат и банк 1 час работал "вхолостую". Ущерб от отказа оставил несколько миллионов баксов. Васю опять уволили, популярное намекнув, что программирование — не его.
6. Перечитав в больнице много умных книжек Вскоре, неунывающий Вася нашёл новую работу. Он устроился разработчиком систем Искусственного Интеллекта в секретный проект по автоматизации систем управления ядерными реакторами... Через некоторое время прибывшая на Земню инопланетная экспедиция с прискорбием констатировала отсутствие на планете жизни.
Так вот. На любом из этих этапов к Васе можно было приставить мегакрутого программиста, который ревьювал бы его код и не допустил бы ни одной их этих ошибок. Вот только затраты на этого мегаспеца за период ревью Васиного кода составили бы, допустим, $5000 в каждом случае. А есть ещё менее бракоделистые программисты, код которых ревьювался бы вхолостую, за те же деньги.
Но конкретно для данного примера, думаю, понятно, что в первом и втором случае найм мегаспеца не оправдался бы ни при каких обстоятельствах. В третьем — тоже крайне спорно. С одной стороны, оценённый ущерб явно оправдывает разгильдяйство руководства, а с другой, могло и посильнее выстрелить, если бы чат отвалился в момент какого-нибудь массового эвента. А вот начиная с 4-го этапа уже да, без ревьювера кода обойтись уже тяжело. Критичный для крупного бизнеса функционал надо защищать от кривых ручек. Особенно если быстро внести правки невозможно.
Для железа, кстати, любая критическая ошибка, обнаруженная на этапе активных продаж — это многомиллионный ущерб, так как исправить распроданные платы физически уже невозможно. Отсюда и куча защит и перепроверок. И то, баги периодически находят.
А вот, например, сайт можно, во-первых, быстро обновить (т.е. цена ошибки будет существенно ниже), а во-вторых, если это не связанный с оплатой, или иными критичными для бизнеса процессами функционал, его падениевыльется в ущерб, но этот ущерб не факт, что будет сопоставим с затратами на команду мегаспецов-ревьюверов.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
LVV>Чтобы писать надежные программы, умолчания должны быть ЗАПРЕЩЕНЫ от слова совсем.
Чтобы писать надежные программы в том же стиле как и хардваре надо просто все тестировать как в хардваре.
На одного писателя верилога три верификатора, которые пишут тесты. Все поддерживаемые use-case до начала написания кода.
А потом еще столько же софтваре инженеров которые пищут фирмвары для этого напичаного багами изделиями так, чтобы конечный пользователь ничего этого не увиделю
BFE>А как начнёшь работать на низком уровне с какой-нибудь железкой, ну там, с Wi-Fi модулем, например, и стоит отклониться от обычного сценария, то пиши "пропало". Обычный сценарий, это например, один модуль на USB. А подключаешь второй — и всё, после soft перезагрузки модули не отвечают. Или что-нибудь другое в этом же роде.
Потому что как и с софтом — выкатить следующую версию важнее чем вылизывать. Конкуренты не дремлют.
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Это ты тысячестраничные errata не читал, видимо
Явно ты от ИТ далек, то паутиной любой граф представить хочешь, то вдруг железо у тебя без ошибок
Всё интересно, однако не совсем корректно:
Уже на третьем этапе, в игровой конторе, QA спецы выявят проблему игрового чата, ну а менеджеры "натянут" Васю по полной.
После чего — он либо перестроится (на верное профессиональное русло), либо просто начнётся его путь дауншифтинга...
Здравствуйте, AlexGin, Вы писали:
AG> AG>Всё интересно, однако не совсем корректно: AG>Уже на третьем этапе, в игровой конторе, QA спецы выявят проблему игрового чата, ну а менеджеры "натянут" Васю по полной.
Мне кажется, вы переоцениваете работу QA. Они, всё-таки, тоже работают в условиях ограниченного времени и возможностей. И там тоже бывают свои «Васи».
А ещё бывают жёсткие обязательства по срокам, когда либо продукт выходит «как есть», либо летит псу под хвост маркетинговая компания на много миллионов долларов. И игровая индустрия, как раз, примеров выхода «сырых» продуктов знает немало.
Так что третий и четвёртый примеры, при всей их выдуманности, основаны на реальных событиях.
Пятый случай — это история, которую успевший поработать в банках коллега рассказывал как реальную. Нет, он был не тем самым «Васей», но тем, кому пришлось участвовать в экстренной починке.
А что касается последней байки, то она является компиляцией шутки, которую я периодически говорил студентам в ВУЗе, мол, «если пойдёте работать программистами на Балаковскую АЭС, предупредите, чтобы я успел свалить из области», и вполне себе не шуточной истории, описаной под номером три по вот этой ссылке: https://topwar.ru/106491-chetyre-sluchaya-kogda-mir-nahodilsya-na-grani-yadernoy-voyny-mezhdu-ssha-i-sssr.html
Остальные истории там, кстати, тоже хороши, и в том числе про «сверхнадёжное» железо. Не смешно, зато про жизнь.
Так что «Вася», конечно, образ собирательный, но байки вполне себе реальные прототипы имеют.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
Зато его исправить легче. А раз легче, то зачем тратить деньги на тестирование, когда пользователи сами всё протестируют?
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
LVV>Элементарно, Ватсон. LVV>Разработчики железа
LVV>А видим мы Оберон
Не видим
LVV>, RUST и
Что раст? Раст еще молодой и в железе его пока что не видно даже в микроскоп.
LVV>Go.
Ну-ну. И много железяк ты видел напрограммированного на Go железа?
Ну-ну. LVV>Но даже ты, скажешь, что Оберон — это отстой... LVV>А вот разработчики RUST через десятки лет после создания Оберона пришли фактически к тому же.
Ахахахах. Что ты несешь вообще. Как разработчики Раста могли прийти к Оберону, если в Обероне примерно ноль возможностей, предоставляемых Растом?
Здравствуйте, LaptevVV, Вы писали:
LVV>А видим мы Оберон, RUST и Go. LVV>Но даже ты, скажешь, что Оберон — это отстой... LVV>А вот разработчики RUST через десятки лет после создания Оберона пришли фактически к тому же. LVV>А разработчик Go вообще закончил виртовскую школу. Хоть и работает в гугле.
То-то на Go простейшее сложение чисел происходит с игнорированием переполнения. Ну подумаешь — не тот результат выражения, который задумал хомячок, ну, полетела ракета не вверх, а вниз.
Виртовская школа, говорите?
N>То-то на Go простейшее сложение чисел происходит с игнорированием переполнения. Ну подумаешь — не тот результат выражения, который задумал хомячок, ну, полетела ракета не вверх, а вниз. N>Виртовская школа, говорите?
Тлетворное влияние мэйнстрима...
На интеле целые жеж без прерывания складываются
Зато нелокальный переход по исключению убрали...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
N>>То-то на Go простейшее сложение чисел происходит с игнорированием переполнения. Ну подумаешь — не тот результат выражения, который задумал хомячок, ну, полетела ракета не вверх, а вниз. N>>Виртовская школа, говорите? LVV>Тлетворное влияние мэйнстрима... LVV>На интеле целые жеж без прерывания складываются LVV>Зато нелокальный переход по исключению убрали...
Вот я как раз этого "зато" и ожидал (хоть и не хотел).
Если у вас выражение типа c = a+b*c-d, и происходит переполнение, то как его рапортовать?
Исключение? Вы ж говорите, что это тьфу, бяка.
Флаг контекста исполнения (как горутина)? Так никто ж не делает, облом-с, видите ли.
Переписывать в виде c, err = put_sub(tmp2, d)? Никто писать на таком не будет.
То же в скрытом виде через монады и аналоги для нескольких аргументов? Как можно, это же Go, тут всё должно быть явно написано
LVV>Зато нелокальный переход по исключению убрали...
Смеюсь, как вы вместе с фанатиками повторяете это, когда в языке есть panic и recover. Можно вводить исключения с нелокальными переходами, главное — не называть их так и не давать полную проработанную функциональность
Привет страусам
Здравствуйте, okon, Вы писали:
O>И ПО должно быть в итоге намного надежнее железа.
ПО давно стало "вещью в себе", которое уже существует немного отдельно от людей. По признание некоторых людей ПО, особенно операционные системы — это самое сложное творение человеческой мысли из всех существующих (не помню, где об этом читал). Уже стало невозможным для одного человека понять, как функционирует ПО, да и компьютер тоже. Такая селяви. Да, на счет железа тоже все не так просто.
Здравствуйте, netch80, Вы писали:
N>То-то на Go простейшее сложение чисел происходит с игнорированием переполнения. Ну подумаешь — не тот результат выражения, который задумал хомячок, ну, полетела ракета не вверх, а вниз.
"Операции с целыми числами" — это такой эвфемизм, который используется, чтобы не пугать граждан с образованием, эквиавалентным средней школе. Имеется ввиду, конечно, алгебраическое кольцо целых чисел по модулю 2^N. И нет там никакого переполнения, на кольце-то
N>Виртовская школа, говорите?
Go — это такой C 2.0. Удобный, но со своими подводными камнями. Местами весьма неочевидными. Старая школа, Ричи, Керниган, Пайк...
Я как его увидел, слова Plan 9 и Alef сразу в голову пришли
