Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства.
Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы.
Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку.
И ПО должно быть в итоге намного надежнее железа.
При этом часто встречается в компаниях разделение программистов на тех кто пишет софт ( добавляет фичи, фиксит баги ) и тех кто его поддерживает ( фиксит критичные баги в срочном порядке ).
Причем некоторые крупные компании ( где ошибки в ПО сильно критичны ) берут инженеров других компаний, которые фиксят критичные баги которые возникают в процессе работы.
Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор.
Как правило все ошибки идут уже на уровне драйверов и софта.
Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, okon, Вы писали:
O>>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? GIV>Нет, совсем нет, ни одного.
Ну познается в сравнении, по сравнению с софтом — никогда.
На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался.
При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Ну познается в сравнении, по сравнению с софтом — никогда. O>На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался. O>При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
Количество программ с которыми ты имел дело как бы на несколько порядков больше.
ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Элементарно, Ватсон.
Разработчики железа не пишут на JS, Python, C++ прочей ненадежной лабуде.
Чтобы писать надежные программы, умолчания должны быть ЗАПРЕЩЕНЫ от слова совсем.
За неявные преобразования — РАССТРЕЛ.
За неявные переходы при обработке исключений — бессрочная каторга в Сибири...
И что мы видим в результате?
А видим мы Оберон, RUST и Go.
Но даже ты, скажешь, что Оберон — это отстой...
А вот разработчики RUST через десятки лет после создания Оберона пришли фактически к тому же.
А разработчик Go вообще закончил виртовскую школу. Хоть и работает в гугле.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, okon, Вы писали:
O>>Ну познается в сравнении, по сравнению с софтом — никогда. O>>На своей истории я много раз сталкивался с критичными ошибками в софте — код программы переставал неожиданно работать, при этом сам код программы не повреждался. O>>При этом с железом такого не наблюдается ( если конечно оно физически не вышло из строя = изменение кода программы ).
GIV>Количество программ с которыми ты имел дело как бы на несколько порядков больше.
Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
От сменных модулей — каждый модуль еще состоит из частей в итоге 20-30 наберется.
При этом я еще пользуюсь кучей железок — телефоны и пр.
GIV>ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Зависит от того из-за чего глючит, если от поломки например у тебя там контакт поврежден механически ( = изменение логики работы ) то не считается.
И в чем глюк заключается — если этот глюк блокирует тебе работу, то да.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
Уверен на 100%, что одних драйверов ты используешь больше 20-30. Потом загляни в диспетчер задач/top, чтобы посмотреть, сколько сервисов крутится у тебя (да, ты их тоже используешь, но неявно). А потом уже считай программы.
Общий ответ: потому, что люди, принимающие решения, не хотят платить за надёжность софта. Это касается как производителей, так и покупателей.
В целом надёжность софта значит гораздо меньше, т.к. обычно есть возможность обновить этот самый софт. С железом это сделать практически невозможно. Стоит отметить, что когда игры и программы распространялись на дисках, надёжность софта была повыше, т.к. у среднего покупателя не было возможности обновиться по интернету.
К примеру Microsoft раньше использовала огромный парк тестовых машин самых разных конфигураций, на которых прогонялись все билды Windows. Когда это убрали, качество упало. Зато сэкономили деньги.
Нет формального определения качества. Нет даже возможности сравнить качество двух конкурирующих продуктов кроме как личными впечатлениями. Поэтому качество, как правило, не служит ориентиром при выборе программы. Ориентируются на дизайн, ориентируются на формальный список фич. Например микрософт решит, что пора подтянуть качество Windows и следующие 5 лет будет выпускать только багфиксы без единой новой фичи. Увеличит это продажи? Нет, уменьшит.
А языки и прочее это всё вторично.
Ну и такая культура пренебрежения качеством проникает во все уголки. Не удивлюсь, если автопилот в юбере пишут те же люди, что писали фронтэнд на JavaScript, с соответствующим подходом.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, okon, Вы писали:
O>>Не уверен, в моем списке программ наверное штук 20-30. При этом в конкретном компьютере железок того же порядка.
N>Уверен на 100%, что одних драйверов ты используешь больше 20-30. Потом загляни в диспетчер задач/top, чтобы посмотреть, сколько сервисов крутится у тебя (да, ты их тоже используешь, но неявно). А потом уже считай программы.
Еще обычно драйвер сопоставляется железке.
В таком случае можно посчитать количество деталей на плате, там тоже не один процессор, а другие ”сервисы“.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Еще обычно драйвер сопоставляется железке. O>В таком случае можно посчитать количество деталей на плате, там тоже не один процессор, а другие ”сервисы“.
Конечно можно. И ты обнаружишь, что всё ломается и многое очень плохо спроектировано, особенно в ноутбуках или смартфонах. Ради интереса поговори за бокалом пива с мастером из сервис центра, он тебе расскажет про надёжность железа всё, что знает.
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
В условиях рыночной экономики — зачем производителю вообще надо писать надежное ПО?
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
Именно потому, что вместо глючной железки разработать новую — долго. А вместо глючной программы разработать новую версию и впарить покупателям — быстро.
И да, убедить пользователя поставить новую версию программы — проще, чем убедить физически поменять железку.
Здравствуйте, okon, Вы писали:
O>И ПО должно быть в итоге намного надежнее железа. O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Вообще говоря, надежность софта достаточно большая. Вот попробуй положить ютуб, гугл, контакт, банковский софт и т.д. Хрен у тебя получится. Какие то мелкие баги да, могут проскальзывать. Но на то они и мелкие что с ними можно жить. Быстро выпустить фичу важнее чем пофиксить мелкие некритичные баги.
Здравствуйте, okon, Вы писали:
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
То, что вы о них не знаете, не значит, что их нет.
Вот тут, например, список извесных ошибок семейства микроконтролёров SAM D5x/E5x Family.
Примеры ошибок:
2. Silicon Errata Issues
...
2.14 Non-Volatile Memory Controller (NVMCTRL)
2.14.1 NVM Read Corruption
NVM reads could be corrupted when mixing NVM reads with Page Buffer writes.
Workaround
Disable cache lines before writing to the Page Buffer when executing from NVM or reading data from NVM while
writing to the Page Buffer. Cache lines are disabled by writing a one to CTRLA.CACHEDIS0 and
CTRLA.CACHEDIS1.
или
2.1 Analog-to-Digital Converter (ADC)
2.1.1 ADC SYNCBUSY.SWTRIG
The ADC SYNCBUSY.SWTRIG gets stuck to '1' after wake-up from Standby Sleep mode.
Workaround
Ignore the ADC SYNCBUSY.SWTRIG status when waking up from Sleep mode.
Как вам такой Workaround?
И таких ошибок семь десятков примерно. Это известных. И только в одном широкоиспользуемом микроконтролёре.
А как начнёшь работать на низком уровне с какой-нибудь железкой, ну там, с Wi-Fi модулем, например, и стоит отклониться от обычного сценария, то пиши "пропало". Обычный сценарий, это например, один модуль на USB. А подключаешь второй — и всё, после soft перезагрузки модули не отвечают. Или что-нибудь другое в этом же роде.
Здравствуйте, vsb, Вы писали:
vsb>Общий ответ: потому, что люди, принимающие решения, не хотят платить за надёжность софта. Это касается как производителей, так и покупателей.
Дополню вас небольшим примером, который как-то приводил мой коллега (как раз в обсуждении вопроса качества ПО). Этот он сам нашел в какой-то статье или книге.
Со слов коллеги где-то до начала 90-х производители медицинского оборудования (имеется в виду серьезного и потенциально опасного — таких, как рентгеновские аппараты) не сильно заморачивались вопросами качества управляющего ПО и процессы разработки там были в целом такими же как везде.
Но где-то в конце 80-х, начале 90-х прошла целая волна серьезных инцидентов с мед. оборудованием, и как следствие — огромные иски от потерпевших и штрафы от контролирующих органов.
По их результатам производители оборудования прикинули, что возможные потери от исков из-за ошибок в ПО многократно перекрывают вложения в организацию процесса тестирования и выпуска надежного ПО.
Были сделаны соответствующие изменения и как результат проблемы не ушли совсем, но их количество резко упало.
Т.е. пока вероятные потери от ненадежного ПО не будут превышать затрат на обеспечения его надежности — никто не этой самой надежностью заниматься и не будет.
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
С точностью до наоборот.
Вопрос "на засыпку": в каком коде чаще всего обнаруживаются баги? Да в том, который только что написали или поменяли! (Есть статья на эту тему как минимум от Гугла. Возможно, Фейсбук тоже смотрел такую статистику и где-то рассказывал.)
Таким образом, лёгкость внесения изменений в софт по сравнению с железом провоцирует _увеличение_ количества багов, а не их уменьшение. Чисто статистически.
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор. O>Как правило все ошибки идут уже на уровне драйверов и софта.
На эту тему уже высказались намного более компетентные коллеги. Я только вспомню FDIV bug, Spectre и Meltdown.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Это у них throughput ~1 процессор в год, а latency ~20 лет. Со всеми вытекающими.
Т.е. объём _анализа_, _моделирования_, _верификации_ и тестирования по сути несопоставим. Ровне все те элементы, которые ведут к снижению количества ошибок и как правило "пропускаются" при разработке ПО.
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства. O>Можно легко внести изменение и протестировать, в отлчии от той же электрической схемы. O>Т.е. ПО можно за одно и тоже время проверить и улучшить во много раз больше чем железку. O>И ПО должно быть в итоге намного надежнее железа.
Можно просто открыть errata на эти железки, и представить, сколько геморроя была у писателей драйверов и ОС, пока они эти "особенности" обходили, сразу передумаешь сравнивать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, okon, Вы писали:
O>Почему нет критичных багов в релизных процессорах, материнских платах, компьютерах ? И в компаниях обычно нет инженера Интел который сидит и поддерживает их процессор.
Есть.
O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
Никак не добиваются. И часто к их ошибкам приходится делать workaround в драйвере. И если workaround оказывается недостаточно хорош, то некоторые несознательные пользователи считают, что это ошибка в драйвере.
Здравствуйте, GarryIV, Вы писали:
GIV>ЗЫЖ У меня модуль wi-fi в ноуте глючит, это считается?
Почему ты думаешь, что это не софтверная проблема?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, 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 сразу в голову пришли
Здравствуйте, LaptevVV, Вы писали:
LVV>Тлетворное влияние мэйнстрима... LVV>На интеле целые жеж без прерывания складываются
Да нет там никаких целых, есть алгебраические кольца (операции по модулю 2^N). И все там корректно делается, нет на этих кольцах никаких переполнений.
LVV>Зато нелокальный переход по исключению убрали...
Здравствуйте, vsb, Вы писали:
vsb>В целом надёжность софта значит гораздо меньше, т.к. обычно есть возможность обновить этот самый софт. С железом это сделать практически невозможно. Стоит отметить, что когда игры и программы распространялись на дисках, надёжность софта была повыше, т.к. у среднего покупателя не было возможности обновиться по интернету.
Так они были куда как проще, когда распостранялись на дисках.
vsb>К примеру Microsoft раньше использовала огромный парк тестовых машин самых разных конфигураций, на которых прогонялись все билды Windows. Когда это убрали, качество упало. Зато сэкономили деньги.
Windows 1.0 глючило неимоверно. Несмотря на парк тестовых машин (если он, конечно, был).
Здравствуйте, Александр Кузнецов, Вы писали:
АК>6. Перечитав в больнице много умных книжек Вскоре, неунывающий Вася нашёл новую работу. Он устроился разработчиком систем Искусственного Интеллекта в секретный проект по автоматизации систем управления ядерными реакторами... Через некоторое время прибывшая на Земню инопланетная экспедиция с прискорбием констатировала отсутствие на планете жизни.
К ядерному реактору обычно приделывают для подстраховки что-нибудь олдскульное, теплое и ламповое, способное отследить момент, когда Васино поделие пытается отправить содержимое реактора в открытый космос, аккуратно отрстранить это поделие от управление реактором и заглушить реактор.
Здравствуйте, Pzz, Вы писали:
N>>То-то на Go простейшее сложение чисел происходит с игнорированием переполнения. Ну подумаешь — не тот результат выражения, который задумал хомячок, ну, полетела ракета не вверх, а вниз. Pzz>"Операции с целыми числами" — это такой эвфемизм, который используется, чтобы не пугать граждан с образованием, эквиавалентным средней школе. Имеется ввиду, конечно, алгебраическое кольцо целых чисел по модулю 2^N. И нет там никакого переполнения, на кольце-то
Только вот проблема — программисту как раз нужны не произвольные операции на кольце, а контролируемые на 𝐙
И в разумных местах ему идут навстречу (C# checked контекст, Rust спец. методы и т.п.)
N>>Виртовская школа, говорите? Pzz>Go — это такой C 2.0. Удобный, но со своими подводными камнями. Местами весьма неочевидными. Старая школа, Ричи, Керниган, Пайк...
Pzz>Я как его увидел, слова Plan 9 и Alef сразу в голову пришли
Да можно всякие Limbo вспоминать хоть 20 раз в день, но это не поможет перестать наступать на типовые грабли всех видов.
Здравствуйте, netch80, Вы писали:
N>Только вот проблема — программисту как раз нужны не произвольные операции на кольце, а контролируемые на 𝐙 N>И в разумных местах ему идут навстречу (C# checked контекст, Rust спец. методы и т.п.)
В общем, все как всегда. Граждане ученые создали не такую машину, какая требуется народному хозяйству, а бригадирам машинистов не сообщили.
Думаю не последнее место занимает избыточность количества кода. В хардваре каждый транзистор на счету (ну, я по кр мере в это верю). Меньше элементов — надежнее система.
Есть хоть одна контора, которая бы практиковала KPI — W/N, где W — условый вес решенных программистом проблем, N — условный вес кода, на который при этом вырос проект? Хрен там. Бывает вообще зарплата прямо зависит от количества написанного кода. А теперь представьте если хардварщикам будут платить по количеству запроектированных в схеме элементов?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, dsorokin, Вы писали:
D>По признание некоторых людей ПО, особенно операционные системы — это самое сложное творение человеческой мысли из всех существующих (не помню, где об этом читал)
Здравствуйте, okon, Вы писали:
O>Казалось бы процесс производства софта гораздо более короткий чем при проектировании железа или какого-либо устройства.
... O>Как разработчики железа при той же периодичности крупных релизов ~раз в 1 год добиваются надежной работы, хотя их цикл внесения изменений намного дольше.
8 марте, в перерывах между работами на дачном участке, беседовал с зятем на предмет, зачем внедряют в РФ проектную систему западного образца, когда перед этим прекрасно работала советская.
Он — типа менеджера в одной компании, которая занимается испытанием западных лекарств на россиянах. Такое в РФ теперь конкурентное преимущество обнажилось, после перестройки, хранить отходы других и испытывать чужие лекарства на себе (на населении, конечно).
Выяснили для себя, что такая система, очень похожая на то, что творится в разработке софта (РП, ПМ, АМ, линейные руками водители и прочая требуха) практически не применяется там, где имеют дело с вещами материальными — т.е. с двигателями, кораблями, вообще машинами. Но зачем внедряют эту дрянь в софтовых и прочих конторах, спрашиваю. И тут пришли к выводу что дело в кардинальной разнице между плановой и рыночной экономиками и социумами.
Что было при плановой ( это я помню) в разработке софта и железа к нему (или наоборот) на примере системы спутникового мониторинга окружающей среды в интересах народного хозяйства (не военного, это важно для нашего случая)? Сверху спускалось задание крупными блоками. По мере опускания к исполнителям его дробили, наполняли подробностями. Железо всегда было базой. И внизу одни делали железо, другие его запускали и контролировали (это делали именно военные, они заведовали всем летающим над страной и планетой, по традиции), третьи проектировали и писали софт, интегрированных с системами приёма данных. Писали обработку данных. И были заинтересованы, чтобы софт был стабильным и надёжным. И содержал средства отработки новых версий (не частых) железа. За это и платили деньги. Платил за всё не частник (это очень важно), а государство, т.е. вполне себе общественная организация, в советских условиях это реальностью, хотя уже и загибаемой (в 80-х) к эрэфийскому битию. И этой системе было важна именно надёжность и устойчивость. Так было записано в основах советской экономики и политики.
Рассказывать о тех деталях долго, скажу лишь, что современные системы, разрабатываемые частными РФ-конторками, в подмётки не годятся тем по масштабам и системности подхода (чётно слизанного с западных образцов, к тому-же).
А из беседы с зятем понят то, что этот знаменитый agile есть именно отражение частно-рыночного подхода к разработке софта, когда результат зачастую далёк от планируемого изначально, зато даёт больше (на 0.5 %) прибыли главному инвестору. Правда, инфляция при этом случилась уже в 5-15 %, ну да дело то житейское, это при СССР инфляции не было в принципе (кроме перехода к перестройке, по понятным причинам). Естественно, когда кони меняются на переправе или даже при заплыве, а софт дрейфует при любом колебании "рынка", то ничего реально хорошего с т.з. устойчивости произвести невозможно. Более того, устойчивое и надёжное — противоречит самой идее рыночного производства, где во главе всего — личная прибыль на всех этапах. И если личным интересам (читай прибыли) соответствует производство плохого софта, то софт обязательно должен стать плохим и ненадёжным. Зато его можно переделывать, улучшать и продавать по новой, особенно государственному заказчики.
И вот парадокс, нынче государственный заказчик (имея частную оболочку чиновника) ТОЖЕ заинтересован как можно в больших объёмах работы и длительности сроков исполнения. У него тоже ЧАСТНЫЙ теперь интерес. Парадокс — разрешился!
Короче, при рынке производить надёжный софт — невыгодно! И это — приговор! И в будущем (при капитализме, конечно, ведь есть и другие варианты, правда, они связаны с посягательствами на все подряд конституции), софт должен становиться всё хуже и нестабильнее. Т.к. именно это и ведёт к повышению личной прибыли одних за счёт ухудшения жизни других. А это и есть единственный путь получения прибыли из общего источника благосостояния — реальной работы многих для наживы немногих.
А железо — оно тоже стало ненадёжным, т.к. выгоднее продавать больше, часто сменяемого железа, чем надёжного и работоспособного в течении десятилетий! Скажем. мой холодильник работает с 1992 года, почти 30 лет! Заменяло только биметаллический переключатель датчика остывания -нагрева. Ремонтник на прощание сказал — берегите холодильник, таких теперь не делают.
Микроволновка LG проработала 20 лет, пора менять. Читаю отзывы — техника не живёт такая дольше 5 лет в среднем.
Про автомашины молчу, т.к. не пользую. Но слышал. что принято в массах менять машины раз в несколько лет, иначе кирдык. Хотя есть знакомые, пользующие опять-же старые (это важно!) машины уже десятилетиями.
АК>Всё до безумия просто. Вот есть у нас, допустим, программист-бракодел Вася.
АК>...1. Вася пишет ...
Так в чём же суть ответа? Так и не понял? В чём дело то? В чём ответ? Что такого основополагающего в том, что Вы описали? Всё описанное — дрянь, личный бизнес, попытки срубить денег. Ничего иного и быть не могло, включая падение банковских сервисов.
Почему софт перестали делать надёжным-то? Потому что не требуется его делать надёжным? С этим ещё можно было бы согласиться. Но из вашего текста это не следует явно. Прошу пояснить.
Еще давняя мысль на эту тему вспомнилась. В софте в отличии от хардвара со стороны сложно понять реализация каких вещей будет надежным решением, а каких (или каким путем) — надежно сделать практически невозможно.
К примеру, никто не делает трансфер пассажиров между авиарейсами прямо на лету. Ведь было бы удобно и сэкономило бы кучу бабла. Но даже кухарке очевидно, что как не пили такую технологию, но периодически люди в процессе такой пересадки будут падать с неба А в софте менеджмент апрувит любой костыль, ограничителем могут быть только сами девелоперы, но их склоняют к инкостыляции самими разными непотребными способами (эджайл и вот это вот все).
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Еще давняя мысль на эту тему вспомнилась. В софте в отличии от хардвара со стороны сложно понять реализация каких вещей будет надежным решением, а каких (или каким путем) — надежно сделать практически невозможно.
ORLY? Если бы было так, не было бы тупиковых аппаратных архитектур, на которые выброшены миллиарды, кривейших решений в плане дизайна всякой железной логики, протоколов общения и т.п., а также Meltdown, Spectre и тысяч тому подобных.
И то, сколько потратилось индустрией на освоение следующих шагов типа этих 10нм, 7нм, а сколько обещалось — показывает, что не всё так просто, мягко говоря.
O>К примеру, никто не делает трансфер пассажиров между авиарейсами прямо на лету. Ведь было бы удобно и сэкономило бы кучу бабла. Но даже кухарке очевидно, что как не пили такую технологию, но периодически люди в процессе такой пересадки будут падать с неба
Если это будет челноками-шлюпками — не будут. Но надо отработать проблемы турбулентности.
Если отбросить всевозможные социологические аспекты, методологии, то полагаю ответ прост — требования к софту сильно выросли, а вариативность условий в которых он работает и КАК его использует — практически безгранична.
Если вы возьмете ЭБУ автомобиля начала 2000-х, который суть программа то там и ошибок почти нет. А если возьмете блок комфорта современного авто (не важно кого, 50% +/- одинаковы), то проблем там, как правило много.
Железо, современное железо, хоть и может поразить кол-вом транзисторов и имеют талмуды-спецификации, но в отличии от софта — оно спаяно именно таким образом и никаким другим. В софте же все не так.
Если же опять спустится с небес на землю, то с банальными железками, опять же, например, в автомобилях — почти в любой модели есть родовые болезни. То задние двери сами себе проводку перебивают (привет, астра), то регулятор давления в рампе... заменялся заводом, у кого-то теплообменник ссыться постоянно, потому что инженеры бараны, у кого-то привод ГРМ расположен не спереди как у всех, а с заднице (на коробке, привет, туарег, VR6). Почти в любом каталоге одни запчасти заменяются новыми, в том числе и по причине просчетов.
PS: У бнв там вробще перманентные проблемы с указателями поворотов.
А в софте менеджмент апрувит любой костыль, ограничителем могут быть только сами девелоперы, но их склоняют к инкостыляции самими разными непотребными способами (эджайл и вот это вот все).
