Поражение советской IT-отрасли в конкуренции с США обыкновенно объясняют сочетанием трех факторов. Во-первых, слабой технологической базой СССР и ставкой на копирование американских компьютеров, сделанной уже в 1970-е. Во-вторых, отсутствием частной собственности, конкуренции и предпринимательской инициативы. И, наконец, изоляцией перспективных технологий в военном секторе и минимальным количеством разработок двойного назначения, доступных советскому народному хозяйству. Питерс не пытается опровергнуть все эти аргументы, но сосредоточивается на альтернативном объяснении: по его мнению, ключевой вклад в провал красного интернета внесла советская бюрократия. Главный тезис его книги звучит так: в тех ситуациях, где агенты капиталистической экономики, будто бы обязанные конкурировать между собой, в действительности демонстрировали способность сотрудничать для решения комплексных и принципиально новых задач, там советские ведомства, задача которых формально заключалась в том, чтобы обеспечивать социалистическую кооперацию, напротив, усердно защищали собственные аппаратные позиции. В итоге неспособность номенклатуры договариваться затормозила проект Глушкова, а после ранней смерти академика в 1982 году у ОГАС вообще не осталось крупных лоббистов. Формально не отвергнутый окончательно проект был закрыт из-за неактуальности лишь к 1989 году. «Советский Союз не смог построить интернет не столько из-за нехватки технологий или отсутствия частной собственности, — пишет Питерс, — сколько из-за невозможности протолкнуть столь масштабный проект через все ведомства, интересам которых он противоречил».

Постоянное соревнование в злом остроумии, ерничестве, жестокой иронии есть несомненный признак интеллектуальной жизни русскоязычного общества. Это соревнование, вне зависимости от политической принадлежности соревнующегося унаследованное от Маркса, Ленина и других блестящих полемистов, в наше время наносит непоправимый вред доверию, а значит и совокупному интеллекту. И, похоже, никакая степень знакомства со священным текстами тут не помеха. Борьба с чем бы то ни было такими средствами ни к чему рационально хорошему не приведет.

Всё начинается с того что мудак-функциональщик читает какую-нибудь «умную» книгу типа Little Schemer. Ну обычно хуже того: поциент узнает про самый лучший в мире язык хаскель. И во всяких быдлосайтах и говноблогах типа хабры он черпает свои знания.
Он долго тужится, пытаясь вникуть в суть буковок и однажды он вроде что-то там понимает. И тут начинается срашное: эта пиздота лезет на форумы и выплескивает свой ментально-функциональный гной на ничего не подозревающих окружающих, обязательно делая это наиболее ублюдочным способом: на языке хаскель или лисп.

«Ах, вы знаете господа я давеча читал про комбинатор неподвижной точки. Ах, ах, божественно! Ах, какая прелесть лябмда-исчисление! Какой блеск, функции высшего порядка, рекурсия. Ах! Ах! Высший класс! Циклы? Ах, глупости! Императивщина. Фи, как скучно!»

Просто и понятно ответить на законный вопрос недоумевающих читателей «зачем это простому человеку» тупой функциональный пиздюк не может. Вместо этого он начинает с важным видом дристать многабукав о том как всё нетривиально, и тупым идиотам на том форуме куда он пришёл конечно не понять генитальных задумок. Но как говорил Лев Толстой: «Самый верный признак истины — простота и ясность. Ложь всегда сложна и многословна.»

Практического применения очередной абстрактной хуиты, функциональная мразь найти не может. Вместо того чтобы показать пользу от мозговыносящего уёбищного сгустка замыканий мудак начинает рассказывать басни о том как он научился считать факториалы и числа Фибоначчи, используя бесконечные ряды функций, которые генериуют и постоянно вызывают сами себя.
Однако попроси применить Y-комбинатор, чтобы решить какую-нибудь нешаблонную задачку: найти бесконечную же сумму всех натуральных чисел, как тут же следует неловкая тишина и пердеж в лужу.

I learned to program on a course that follows SICP, I spent all my college years learning how to program from first principles, building all the pieces from scratch. Building compilers, soft threads implementations, graph parsing algorithms... and I was happy with that way of programming!

Today I'm an iOS developer

http://ivan-gandhi.livejournal.com/3493927.html?thread=57238311#t57238311
Я общался со спутникостроителями, а также с любителями Ады (я не спрашивал где они работали, насколько я понимаю - военка).

Так вот если в двух словах, на спутниках ничего не верифицируют, но в правильных конторах у них есть стенды - софтверный эмулятор спутника и в особо правильных еще и хардверный эмулятор спутника (то есть буквально макет спутника, в котором есть часть исполнительных устройств и датчиков, и программа на нем отрабатывает какие-то этапы полета).

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

Да, еще в спутниках обычно встроен хардверный отладчик, в смысле по каналу телеметрии можно остановить бортовой компьютер, прочитать/записать регистры проца и ячейки памяти; периферию подергать, типа там предохранители попередергивать и прочие телодвижения сделать.

Проблему что пока компьютер висит может потеряться ориентация решают по разному, например у "Венер" была такая конструкция корпуса что его "автоматически" давлением солнечного света разворачивало так что низкоскоростной канал телеметрии мог работать даже без ориентации; "Вояджеры" летают с закруткой.

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

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

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

Вобщем какой там ООП - там процедурно всё.

У любителей Ады не верификация, а что-то похожее на TDD - у них методология почти всегда водопад, и когда сверху приезжает ТЗ, то заранее известно какой диапазон значений могут принимать входные параметры ну и некоторые переменные тоже, и они просто создают под каждый параметр тип с ограничением диапазона а потом тестируют чтобы при работе проги переменные не вылезли за диапазон, плюс эмуляторы.

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

На Маска выйти пока не довелось. Допускаю что у него несколько иначе, поскольку Маск автомобилист по образованию.

С самолетчиками общался, так у них автопилот совершенно тупая, но чувствительная машина, чуть кто на борту чихнет, он сразу отключается и больше рулить не пытается.

А эти которые "буран" делали, у них тоже был водопад, и они для типа верификации сделали язык графический, у которого программы являются чертежами, которые соответствуют требованиям госта на ЕСКД :))))