Здравствуйте, Кодёнок, Вы писали:

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

Во-первых, оно и в грамотно спроектированном софте не растет по экспоненте. Во-вторых, в микроэлектронике разработка несколько отличается от софта — там акцент на других сложностях. В-третьих, на активности по верификации там тратится почти столько же времени, как и на разработку. Помимо программирования, я два с половиной года руководил отделом разработки микроэлектроники, и могу раскрыть тему подробно, на примере вот этого проекта разработки достаточно сложного микроэлектронного блока, который велся в моей лаборатории.
http://rnd.cnews.ru/tech/electronics/news/line/index_science.shtml?2008/06/02/302983
Это, вероятно, наиболее успешный наш проект — 9 месяцев, 7 человек, строго на графике, сделано ровно то, что требовалось. В этом проекте, ironically, мы задействовали как раз _программистские_ практики организации разработи, что позволило нам сильно снизить затраты не в ущерб качеству. У микроэлектронщиков вообще организация разработки отстает от программистов лет на десять (если сравнивать их практики с лучшими практиками организации разработки ПО, а не с тем бардаком, который мы наблюдаем на практике на многих местах у нас).

Для начала, остановимся на разнице в микроэлектронике и программировании с точки зрения проектировщика/архитектора.
1. Их системы сильно проще программных систем по одному показателю. Там сильно меньше юз-кейсов, и они сами по себе существенно проще. Кроме того, в этих системах состояние хорошо локализовано (нет памяти — нет состояния), и не может меняться откуда попало. Оно по большей части локально. То есть, аппаратчики почти не имеют проблем программистов, связанных с мутабельным состоянием, которое неконтроллируемо меняется откуда попало, а это важно в плане природы самых геморройных ошибок.
2. Сложнее же они тем, что это hard-realtime системы. Представьте, что у вас на каждую функцию есть жесткое ограничение по времени, за которое она должна отработать при любых входных данных.
3. На задержки влияет геометрия и взаимное положение элементов — еще один фактор, в принципе отсутствующий в разработке ПО. Не то, чтобы это слишком сильно играло для встраиваемых систем на этапе проектирования, но это принимается во внимание, потому что может влиять на архитектуру.
4. Площадь — один из самых критичных факторов. Каждый лишний миллиметр площади кристалла — это бабки, прибавляемые к стоимости каждого кристалла. Это порядка 6 центов для техпроцесса 0,13. И такие безобидные вещи, как память — жрут площадь особенно быстро.
5. Вы можете получить ошибку на каждом этапе работы — в том числе, вы не застрахованы от ошибки САПР-ов.
6. Ошибок в кристалл должно попасть как можно меньше. Одна итерация с прототипом — это минимум 4 месяца (два из них фабрика делает прототип, если это быстрая фабрика), и в реальности будет больше. Ошибки, как вы видите, очень дороги.
7. В конечном кристалле ошибок для работы в заявленных режимах быть по возможности не должно. Перевыпуск фотошаблона — это от сотен тысяч баксов до порядка миллиона (или выше), если речь идет о современных тонких техпроцессах. Плюс, конечно, задержка времени с поставками.

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

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

Когда аппаратчики объединяют крупные блоки в систему, она пользуются для их связи "шинами" и "коммутационными средами" разной топологии. Среда передачи данных и алгоритм арбитража у них слабо не зависит от интерфейса блоков (для стандартных шин вообще не зависят), что позволяет хорошо развязать крупные блоки друг от друга, и тестрировать их независимо. Они четко разделяют "системный" дизайн, когда проектируется шинная иерархия и анализируются общесистемные потоки данных и юзкейсы (надо рассчитать параметры коммутационной среды, для этого так же применяются модели потоков данных), и разработку составных блоков системы. Это реально очень круто, в программировании сейчас становится модным подобный подход, часто в сочетании с SOA. Смотрите D-bus и AMQP.

Итак, говоря программистскими терминами, аппаратчики при построении систем вооружены подходом SOA, асинхронными сообщениями и Enterprise Bus Architecture, моделью dataflow, и функциональной чистотой. Ничего из перечисленного не является новым и революционным в программной инженерии. Поэтому, говорить о серебряных пулях — не стоит. Не тянет перечисленное на нее.

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

Теперь о процессе разработки. То, о чем я расскажу дальше, тем более не тянет на серебряную пулю.

Что поменяли в традиционных процессах мы, когда делали видеоконтроллер. У нас был жесткий бюджет, и я выкинул из проекта отдельных верификаторов. Кроме того, в проект на правах архитектора был включен программист, который знаком с видеообработкой, и умеет писать модели аппаратуры. Штука в том, что нам прототип ключевых аспектов архитектуры нужен был до того, как закончен архитектурный этап, и готова документация по ней. Поэтому, группу высокоуровневого моделирования не привлекали, а обошлись одним Сергеем Зефировым (thesz), включив его в состав команды как архитектора, и подчинив непосредственно руководителю проекта. Модели он писал на Хаскеле, в одиночку, без ТЗ, потому что сам был автором ТЗ и соавтором архитектуры. Таким образом, мы устранили тормозное звено в коммуникации "через бумагу", и ускорили "итерации" дизайна. Применяй мы на этом этапе SystemC как все — нихрена бы нас это не прокатило, для модели бы отдельная спецификация потребовалась.

Второе, что мы сделали — это была применена вполне программистская теория PSP/TSP для управления качеством. На первом этапе все возможные ошибки были отклассифицированы по типам и стадиям внесения, и далее была разработана стратегия тестирования, которая перечислял процедуры отлова ошибок на каждом этапе разработки, порядок и конкретные способы тестрирования блоков, и доказывал, что мы этими процедурами надежно накрываем все возможные типы ошибок на всех этапах. Задача, которую я ставил при разработке стратегии тестирования — максимальное использование автоматического тестирования на всех этапах, и применение поведенческих моделей для генерации тестовых векторов. В этой работепринимали участие как программисты, так и микроэлектронщики.

Тестовый план, разработанный также на раннем этапе, являлся следтсвием ТЗ, перечисляющего все юзкейсы, и стратегии тестирования, перечисляющей виды тестов. Он определял уже конкретный план работ по обеспечению качества, которые распределялись по разработчикам блоков, и программистам. В результате, мы обошлись ОДНИМ выделенным апарратчиком, который отвечал за стратегию тестирования и тестплан, и смогли обеспечить великолепное качество.

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

Еще одно новшество из мира программирования. В разработке не было выделенных архитекторов, не занятых кодированием. В проекте применялась любимая мной техника группового дизайна. Каждому инженеру была назначена зона ответственности, за дизайн которой он отвечает лично, ониперекрестно проверяли дизайн соседей, и совместно работали над общей архитектурой (по схеме научных семинаров — помните по ВУЗам?). Таким образом, когда они приступали к реализации, они прекрасно знали свои блоки, и разбирались в блоках соседей. Кроме того, им вовремя предоставили тестовое окружение и тулзы.

В результате, когда на переговорах по сдаче второго этапа работ (на котором, по условиям контракта, у нас должно быть собранная вместе модель устройства, но она не обязына проходить системные тесты), я в ответ на вопрос о работоспособности модели сообщил заказчику, что она уже показывает картинки в разрешении SECAM, у заказчика, который в микроэлектронном бизнесе не в первый год (Фомин, 1-й зам НТЦ Модуль), случился шок. В сугубо положительном смысле этого слова. Он не мог понять, как такое возможно. Мы объяснили, и показали картинки .

Итак, все завершилось хорошо, ребята молодцы, и сработали великолепно. Мы здесь-то во многом эффективно сработали потому, что смогли избежать "традиционного" для разработки аппаратуры сдвига акцента на документацию, сохранили маленький размер команды, и очень вдумчиво и к месту применили элементы PSP/TSP и agile-практик. Действуй мы "традиционно" — мы бы вылетили за бюджет и график к чертям и качество не смогли бы обеспечить. Но главное, конечно, в том, что у нас была отличная команда. Парни молодцы.

Однако, стал бы я применять подобный процесс для разработки софта, скажем, веб сервиса, где ошибки дешевы в исправлении? Нет. Никогда. Это overkill. Причина в том, что цена ошибки несопоставимо меньше в софте, и поэтому — не имеет смысл делать мероприятия по отлову ошибок на ранних этапах настолько дорогими, и не имеет смысла так из кожи вон лезть, чтобы обнаружить ошибки раньше. они должны быть соизмеримы цене ошибки. Хотя, в общем, нам удалось их сильно удешевить по сравнению с остальными.

Здравствуйте, Gaperton, Вы писали:

G>Так что не переживайте . Я очень хорошо проработал fault tolerance в цепочке управления. Настолько, что команда вполне может справляться с самыми разными ситуациями и без меня. Это, знаете-ли, ключевой навык и критерий успешности руководителя, ИМХО. Должен же руководитель обеспечить себе право уйти в отпуск, когда захочет, или заниматься херней по причине нерабочего настроения, в конце концов?

О fault tolerance. Я говорил так. Если кому-то покажется, что я говорю что-то неправильное, он ОБЯЗАН немедленно об этом сообщить, и отстаивать свою точку зрения, если я буду возражать. Если же по вашему мнению ваш начальник несет херню, ваша обязанность сообщить ему об этом немедленно в самых неприкрытых выражениях не стесняясь, ибо цена херни в устах начальника очень высока, и может привести к ужасным последствиям. Если эта херня выяснится сейчас, как можно раньше — нам всем будет хорошо. Если же она выяснится потом, и нам всем будет плохо, клянусь, я приравняю это к саботажу и это будет наихудший проступок в нашей команде.

В результате — все мне говорили, когда я херню несу . Видишь-у нас все защищено . Это наш корпоративный дух, дружище.

G>Самых настоящих исходников, на языке Verilog было, внимание...
G>...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.

G>Весь проект, вместе с тестамии окружением — 7000 строк на Verilog.

7965, разница в 16%. Это моя вина, я называл данные по памяти.

G>Поведенческая модель на Хаскеле — 1800 строк.

2194. Тоже одна шестая отличия, тоже меня память подвела.

G>Плюс, алгоритмическая модель на С алгоритма масштабирования изображения — 800 строк.

Да, здесь 800 строк. Здесь не подвела. Удивительно!

Собственно, моих, программистских строк кода и было — 2200 Хаскельных и 800 сишных. ~3000 строк. Что-то около 5-7 строк в час.

Инженеров было четверо, так что я всего в два раза превосходил по скорости инженеров.

Общая низкая скорость связана с тем, что надо было все это симулировать в специальных средах, что не очень быстро. И тяжесть отладки — обычного отладчика нет, надо умом понять причину ошибки и ее выявить. Ошибки, причем, встречались и в результатах моих программ тоже.

Кстати, мы для видеоконтроллера сделали два мультика на POVray, на 90 кадров, с размытием движения (чтобы возможные артефакты проверить).

G>Ну, плюс 300 строк кода на Перле — это преобзразователи логов сигналов в картинки tga и обратно.

И здесь я все правильно указал.

G>Для сравнения. Процессорное ядро Leon3 (SPARCv8) порядка 3 тыщи строк на VHDL.
G>Sun UltraSPARC T1 (SPARCv9, считается не ядро, а весь кристалл, кажется, с тестамии и окружением) — порядка 160 тыщ строк на Verilog, если мне память не изменяет. У них в дизайн-центре над этим процом 200 инженеров работали несколько лет

Это я подсчитывать не буду, поскольку T1 я у себя снес, а просто так скачать его не получается.

Здравствуйте, prVovik, Вы писали:

V>А какой был объем "исходников" у вашего видео-контроллера?

Самых настоящих исходников, на языке Verilog было, внимание...
...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.

Весь проект, вместе с тестамии окружением — 7000 строк на Verilog.

Поведенческая модель на Хаскеле — 1800 строк.

Плюс, алгоритмическая модель на С алгоритма масштабирования изображения — 800 строк.

Ну, плюс 300 строк кода на Перле — это преобзразователи логов сигналов в картинки tga и обратно.

Для сравнения. Процессорное ядро Leon3 (SPARCv8) порядка 3 тыщи строк на VHDL.
Sun UltraSPARC T1 (SPARCv9, считается не ядро, а весь кристалл, кажется, с тестамии и окружением) — порядка 160 тыщ строк на Verilog, если мне память не изменяет. У них в дизайн-центре над этим процом 200 инженеров работали несколько лет

Здравствуйте, mkizub, Вы писали:

M>Вы тут гордитесь сделаным чипом — но за счёт чего вы его сделали? За счёт удержания минимального размера комманды.

Каквсе просто, оказывается. Вперед, удержи минимальный размер команды, и повтори наш результат. Дело ведь в этом?

M>Если бы он чуть-чуть возрос — началась бы формальная работа, согласование работы нескольких человек работающих над
M>кодом, менеджеры комманд, менеджеры руководящие менеджерами и пошло-поехало.

Ой, какие ужасы. Но есть нюанс, почему ничего бы не пошло никуда и не поехало ни при каких обстоятельствах. "Еслибыми" моих ребят пугать не надо. Дело в том, что все "если бы" в данном проекте держал под контролем один менеджер. Я. А если бы я где-то ошибся, не справился, или заболел, и был бы выключен из процесса, меня бы поддержал Женя Янкевич, который хоть и тимлид, но он также отличный менеджер, которого я специально готовил, и который может если что меня заменить. И заменял. А если бы вдруг ошибся он, его бы поддержал, например, Сергей Зефиров (без моего внимания, кстати, это также не обошлось бы, поправил бы и я), который мог бы при нужде заменить Янкевича (и заменял, когда тот был в отпуске). Вообще, в нашей команде каждый инженер в менеджменте соображает больше, чем средний менеджер в индустрии. Счастлив это сообщить — во многом это так благодаря моим стараниям.

Так что не переживайте . Я очень хорошо проработал fault tolerance в цепочке управления. Настолько, что команда вполне может справляться с самыми разными ситуациями и без меня. Это, знаете-ли, ключевой навык и критерий успешности руководителя, ИМХО. Должен же руководитель обеспечить себе право уйти в отпуск, когда захочет, или заниматься херней по причине нерабочего настроения, в конце концов?

Здравствуйте, thesz, Вы писали:

T>Верифицированный код никто индусам не отдаст. А сели отдадут, то разница будет, как в США. Просто потому, что обьем труда будет такой же. Не передергивай, смешивая в сравнении труд по верификации американских программистов и труд по написанию

if (bFlag.toStr().length() == 5) ...

индийских. Это раз.

Я не передёргиваю. Я до тебя пытаюсь донести мысль, что код сделанный индусами — дешевле кода, сделанного американцами.
Верифицированный код нужен NASA, а обычному юзеру он не нужен. Он бы не отказался от безглючной программы, но тогда
она будет стоить в 1000 раз дороже — и за счёт квалификации программистов, и за счёт дополнительных расходов
на ревью, на верификацию и пр. Даже если сделают безглючную видну не за 100 баксов, а за 100 килобаксов — её
никто, кроме NASA и ещё пары контор не купит. Она просто не окупится и фирма прогорит. Да даже если она
будет стоит всего 1000 баксов — всё равно фирма прогорит. А по 1000 баксов у нас что продаётся? QNX?
Отличная, безглючная, и никому нахрен на десктопах не нужная. А если QNX довести размером до винды —
то и стоить она будет на два порядка больше.

T>$1000 за строку стоит код, прошедший все этапы анализа и готовый к загрузке в железку NASA. Читай, полностью верифицированный. Не передергивай. Это два.

Сам пишешь — хороший и верифицированый — это большая разница.

T>И третье и последнее — если все еще продолжают разрабатывать системы автоматической верификации программ, значит, они могут удешевить разработку и наверняка ее уже удешевляют.

Конечно удешевляют. Удешевляют написание верифицированного кода. А верифицированный код — это маргинальная ниша.
Его пишут для NASA, для армии... хотя и там не весь код супер-верифицированый — про авианосец сдохший от зависшей NT все читали.

T>"Не самый плохой" и "не содержащий ошибок" различаются в бесконечно большое количество раз.

"Не содержащий ошибок" — это вообще мистика. Софт может удовлетворять определённым constraint-ам.
Не падать от обращения по нулевому указателю. Не делать оптимизации, которые изменяют поведение программы.
А "не содержащий ошибок" — это невозможно, поскольку невозможно формально определить понятия "ошибка".
С точки зрения человека "правильно" — это когда происходит то, что он хотел, а "ошибочно" — то,
чего он не хотел.
Не ручаюсь за точность воспроизведения, но такую байку слышал — в МКС полетели какие-то гироскопы,
и управляющему компьютеру посыпался мусор. На что он решил перезагрузить код принимающий
данные от гироскопов. Для чего надо было выгрузить завязанные на этот код сервисы.
От чего то-ли этот-же компьютер, то-ли другой, решили, что МКС начал улетать от земли,
и вкючил двигатели на понижение орбиты. И совсем уже было приземлил МКС, да тут русский
аппаратный контроль вырубил нахрен все эти умные компьютеры.
Где тут ошибка, которую NASA-вский верификатор должен был отловить?
Все действовали согласно ситуации. А в верификатор не заложили условие, что при сдохших
гироскопах МКС не должна рыпаться. Заложили-бы — всё было бы в порядке. Верификатор
обнаружил отсутствие гарантии и не пропустил бы этот код. Но в него не заложили эту проверку.
Так были в софте ошибки или нет?

Ладно, закончу на этом. Я тебе уже писал, что в тебе есть наивная уверенность, что
всё можно (математически, наверное) описать и формализировать. Пока ты не поймёшь, что
это иллюзия — что-то тебе по этому поводу доказывать — бесполезно.

Кё>>http://www.rebelscience.org/Cosas/Reliability.htm

M>Чукча. "Что вижу — то пою".
M>Эмулятор среднего процессора пишется студентом за пару месяцев.
M>Ну, пусть не студентом и за пол-года — чтоб достичь такой-же степени безбаговости.
M>Теперь понятна степень сложности процессоров и софта?
M>Для программ тоже есть методики доказательства их корректности, правда не настолько сильно развитые, в силу их невостребованности.
M>А невостребованность проистекает из стоимости разработки таких программ. Она даже не на порядок, на два, на три порядка дороже.
M>Вы сейчас за винду сколько платите? 100 баксов. Платите 100 килобаксов, и будет вам щастье.

Час работы программиста в США стоит $125. В день программист работает 4 часа. За час он производит ~20 строк кода. Итого, $12,5 за строку кода.

Насколько мне известно, стоимость правильно, по всем стандартам NASA, пересмотренной строки кода возрастает до $1000. Это два порядка. Такая высокая цена получается, как раз, из-за использования code review и тщательного документирования кода.

Что еще? Верифицированный от разбора синтаксиса до кодогенерации компилятор с Си (написанный на Coq) занял (по-моему) полтора года работы коллектива из 4-х человек. Это, по-моему, даже не порядок разницы в стоимости для такого продукта.

Система доказательства программ (proof assistant) Coq совершенно бесплатна. Также, как Agda2, Maude и многие другие.

Рекомендую ознакомиться с состоянием дел, прежде, чем делать громкие заявления.

Здравствуйте, Кодёнок, Вы писали:

Кё>http://www.rebelscience.org/Cosas/Reliability.htm

Чукча. "Что вижу — то пою".
Эмулятор среднего процессора пишется студентом за пару месяцев.
Ну, пусть не студентом и за пол-года — чтоб достичь такой-же степени безбаговости.
Теперь понятна степень сложности процессоров и софта?
Для программ тоже есть методики доказательства их корректности, правда не настолько сильно развитые, в силу их невостребованности.
А невостребованность проистекает из стоимости разработки таких программ. Она даже не на порядок, на два, на три порядка дороже.
Вы сейчас за винду сколько платите? 100 баксов. Платите 100 килобаксов, и будет вам щастье.

Здравствуйте, Курилка, Вы писали:

К>Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"?
К>Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.

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

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.
Угу. Неужели ты думаешь, что если звуковуха начнет гадить в шину, то все остальные "отряхнутся и продолжат работать"?
Автор статьи также рассказывает о том, как мало багов он видел в процессорах.
Открытое издевательство:
1. Баги в процессорах находят на регулярной основе.
2. Стоимость разработки современного процессора — крайне высока. Если вкладывать по три-четыре миллиарда долларов в каждый софтный проект, то надежность софта резко улучшится.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

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

Кё>Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.

http://mskhug.ru/wiki/MskHUG1_1 — презентация.

Создание потактово-точной модели процессора — 2 месяца, один человек. "Потактово-точная" означает, что воспроизведены как внутренняя структура, так и машины состояний.

Грубо говоря, я описал "железо", только на Хаскеле.

Здравствуйте, thesz, Вы писали:

T>Час работы программиста в США стоит $125. В день программист работает 4 часа. За час он производит ~20 строк кода. Итого, $12,5 за строку кода.

Сейчас мало кто делает софт с США и западной Европе, подавляющее большинство кода делают в офшорах.

T>Насколько мне известно, стоимость правильно, по всем стандартам NASA, пересмотренной строки кода возрастает до $1000. Это два порядка. Такая высокая цена получается, как раз, из-за использования code review и тщательного документирования кода.

Необходимость в которых проистекает именно из сложности проектов и высокой цены ошибки для NASA (не нужны им взрывающиеся ракеты).
И это ещё не полная верификация, как я понимаю, это code review + документация.
Теперь добавляем к этой $1000 ещё верификацию, убираем из $12,5 цену западного программиста, и спокойно получаем разницу в 3 порядка.

T>Что еще? Верифицированный от разбора синтаксиса до кодогенерации компилятор с Си (написанный на Coq) занял (по-моему) полтора года работы коллектива из 4-х человек. Это, по-моему, даже не порядок разницы в стоимости для такого продукта.

Компилятор с Си — это ноль информации. Его сейчас может написать один человек за пол-года, и это будет не самый плохой компилятор —
аспиранты таким наверное развлекаются.
Мы же не знаем уровня оптимизации этого компилятора. Не говоря уже о том, что софт уровня C++ со средой разработки — это
минимум на порядок сложнее. А порядок сложности — это минимум 2 порядка увеличение затрат. Потому как не 4 человека, а 200,
плюс к ним менеджеров.
Вы тут гордитесь сделаным чипом — но за счёт чего вы его сделали? За счёт удержания минимального размера комманды.
Если бы он чуть-чуть возрос — началась бы формальная работа, согласование работы нескольких человек работающих над
кодом, менеджеры комманд, менеджеры руководящие менеджерами и пошло-поехало. И точно такая-же история прозошла бы
с этой коммандой писателей Си-шного компилятора.

А кому сейчас нужен Си-ный компилятор? Никому, практически. Нужен С++ минимум, плюс среда разработки (типа Eclipse/VisualStudio).
Никто же не кричит — у меня Си-шный компилер глючит. IDE навороченная глючит, операционка навороченная глючит,
оффис навороченный глючит, веб-броузер с десятком плагинов глючит.
Кстати, как у него было с производительностью? Вряд-ли быстро он компилил.
Как у него было с расширяемостью? Никак, это-ж компилятор для давно известного языка.
Сколько будет стоить добавить в этот компилятор новую фичу, которая потребует полного рефакторинга, скажем, подсистемы типов?

T>Система доказательства программ (proof assistant) Coq совершенно бесплатна. Также, как Agda2, Maude и многие другие.

Что не мешает накинуть два-три порядка на стоимость интересной программы, написанной с их использованием.

T>Рекомендую ознакомиться с состоянием дел, прежде, чем делать громкие заявления.

Сам дурак (c)

T>>Час работы программиста в США стоит $125. В день программист работает 4 часа. За час он производит ~20 строк кода. Итого, $12,5 за строку кода.

M>Сейчас мало кто делает софт с США и западной Европе, подавляющее большинство кода делают в офшорах.

T>>Насколько мне известно, стоимость правильно, по всем стандартам NASA, пересмотренной строки кода возрастает до $1000. Это два порядка. Такая высокая цена получается, как раз, из-за использования code review и тщательного документирования кода.

M>Необходимость в которых проистекает именно из сложности проектов и высокой цены ошибки для NASA (не нужны им взрывающиеся ракеты).
M>И это ещё не полная верификация, как я понимаю, это code review + документация.
M>Теперь добавляем к этой $1000 ещё верификацию, убираем из $12,5 цену западного программиста, и спокойно получаем разницу в 3 порядка.

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

if (bFlag.toStr().length() == 5) ...

индийских. Это раз.

$1000 за строку стоит код, прошедший все этапы анализа и готовый к загрузке в железку NASA. Читай, полностью верифицированный. Не передергивай. Это два.

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

T>>Что еще? Верифицированный от разбора синтаксиса до кодогенерации компилятор с Си (написанный на Coq) занял (по-моему) полтора года работы коллектива из 4-х человек. Это, по-моему, даже не порядок разницы в стоимости для такого продукта.
M>Компилятор с Си — это ноль информации. Его сейчас может написать один человек за пол-года, и это будет не самый плохой компилятор -
M>аспиранты таким наверное развлекаются.

"Не самый плохой" и "не содержащий ошибок" различаются в бесконечно большое количество раз.

M>Мы же не знаем уровня оптимизации этого компилятора. Не говоря уже о том, что софт уровня C++ со средой разработки — это
M>минимум на порядок сложнее. А порядок сложности — это минимум 2 порядка увеличение затрат. Потому как не 4 человека, а 200,
M>плюс к ним менеджеров.

CompCert он называется. Это первая версия, опытный образец. Дальше будет проще.

Он выполняет многие оптимизации, для которых могла быть быстро доказана их безопасность.

M>Вы тут гордитесь сделаным чипом — но за счёт чего вы его сделали? За счёт удержания минимального размера комманды.
M>Если бы он чуть-чуть возрос — началась бы формальная работа, согласование работы нескольких человек работающих над
M>кодом, менеджеры комманд, менеджеры руководящие менеджерами и пошло-поехало. И точно такая-же история прозошла бы
M>с этой коммандой писателей Си-шного компилятора.

Ну, да. Других путей не существует, конечно же.

M>А кому сейчас нужен Си-ный компилятор? Никому, практически. Нужен С++ минимум, плюс среда разработки (типа Eclipse/VisualStudio).

Сишный компилятор без ошибок нужен все тем же разработчикам NASA. Из цикла верификации программного обеспечения удаляется этап проверки отсутствия ошибок в компиляторе.

M>Никто же не кричит — у меня Си-шный компилер глючит. IDE навороченная глючит, операционка навороченная глючит,
M>оффис навороченный глючит, веб-броузер с десятком плагинов глючит.
M>Кстати, как у него было с производительностью? Вряд-ли быстро он компилил.

Почему ты так считаешь? Тоже взято из воздуха?

M>Как у него было с расширяемостью? Никак, это-ж компилятор для давно известного языка.
M>Сколько будет стоить добавить в этот компилятор новую фичу, которая потребует полного рефакторинга, скажем, подсистемы типов?

Coq достаточно гибкий язык, хотя я только начал его изучать. Например, типы классов Хаскеля в нем делаются на нем самом, и даже более гибко. Зависимые типы данных — это очень хорошо.

T>>Система доказательства программ (proof assistant) Coq совершенно бесплатна. Также, как Agda2, Maude и многие другие.
M>Что не мешает накинуть два-три порядка на стоимость интересной программы, написанной с их использованием.

Это каким же таким образом? Высосав из пальца?

T>>Рекомендую ознакомиться с состоянием дел, прежде, чем делать громкие заявления.
M>Сам дурак (c)

Рекомендую ознакомиться с состоянием дел, прежде чем называть других дураками.

M>Я о чём писал Сергею? Что чистый компилятор С — это по нынешним меркам примитив. Если вы делаете новый продукт на общую продажу -
M>вы должны делать как минимум С++.

Ты глупости писал Сергею.

Незачем писать компилятор C++ для области, где нужен C. (небольшие встраиваемые системы)

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

More importantly, notice the specific claim that Brooks is making. He asserts that the unreliability of a program comes from the difficulty of enumerating and/or understanding all the possible states of the program. This is an often repeated claim in the software engineering community but it is fallacious nonetheless. It overlooks the fact that it is equally difficult to enumerate all the possible states of a complex hardware system. This is especially true if one considers that most such systems consist of many integrated circuits that interact with one another in very complex ways. Yet, in spite of this difficulty, hardware systems are orders of magnitude more robust than software systems (see the COSA Reliability Principle for more on this subject).

http://www.rebelscience.org/Cosas/Reliability.htm

Здравствуйте, Кодёнок, Вы писали:

[cut]

Помнится в erlang-questions этого троля обсуждали немного по поводу The Seven Deadly Sins of Erlang

Здравствуйте, mkizub, Вы писали:

M>Эмулятор среднего процессора пишется студентом за пару месяцев.

Ты видимо не читал статью или не понял о чем речь.

Автомат, выполняющий инструкции процессора, не есть процессор.

Вот если бы он сэмулировал в виде объектов отдельные транзисторы, или отдельные логические устройства, и достиг той же степени надежности, что и в железе (звуковуха может глючить, но ничто остальное не затронет) — тогда да.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, mkizub, Вы писали:

M>>Эмулятор среднего процессора пишется студентом за пару месяцев.

Кё>Ты видимо не читал статью или не понял о чем речь.

Кё>Автомат, выполняющий инструкции процессора, не есть процессор.

Кё>Вот если бы он сэмулировал в виде объектов отдельные транзисторы, или отдельные логические устройства, и достиг той же степени надежности, что и в железе (звуковуха может глючить, но ничто остальное не затронет) — тогда да.

Для корректной работы процессора нам не нужно знать из каких транзисторов он состоит, фактически контрактом являются напряжения на ножках этого процессора (суть входы/выходы), которые есть по сути реализация эмулятора. И этот контракт жёстко зафиксирован и соблюдение его гарантируется (хотя помнится были и процессоры с багами).
А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.
И попробуй сравнить мощности моделей.

Здравствуйте, Курилка, Вы писали:

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

Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.

К>А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.

У general-purpose вещей контракта нет по определению. Его нет и у персонального компьютера. Но у любого компонента Windows — есть. И что получается? Сбойный драйвер ломает всю систему. Неожиданное исключение из недр используемой библиотеки аварийно завершает весь алгоритм. Кусочек плохого кода сразу низводит надежность алгоритма до его надежности, независимо от того, насколько он вообще нужен.

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

Здравствуйте, Кодёнок, Вы писали:

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

Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

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

Кё>Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.

О как, у нас и регистры вдруг пропали вдруг из процессора, да? И память тоже не используется? (хотя, безусловно, это внешний ресурс, если не говорить про кэш)

К>>А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.

Кё>У general-purpose вещей контракта нет по определению. Его нет и у персонального компьютера. Но у любого компонента Windows — есть. И что получается? Сбойный драйвер ломает всю систему. Неожиданное исключение из недр используемой библиотеки аварийно завершает весь алгоритм. Кусочек плохого кода сразу низводит надежность алгоритма до его надежности, независимо от того, насколько он вообще нужен.

Контракт "любого компонента" можно? Который бы не включал зависимости от других частей системы?

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

А если у тебя от записи в лог будет зависеть другие части системы? Точно также будут ломаться зависимые части.
Просто в рамках (современного) компьютера и ОС получить неявные зависимости гораздо проще, но с этим борются (как пример — software isolated processes), правда прогресс усложнения ПО по ходу дела идёт быстрей, чем прогресс у тех, кто борется.

Здравствуйте, mkizub, Вы писали:

M>Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?

Сломается все, что от них зависит, но ничто остальное. Если весь процессор зависит — то весь процессор, но никогда — сетевая карта. В алгоритме непредусмотренный сбой ломает все и насовсем.

Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.

Здравствуйте, Курилка, Вы писали:

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

К>А если у тебя от записи в лог будет зависеть другие части системы?

Для обоих плохо читающих, я выделил жирным. Никто не говорит о чудесах. Как можно обсуждать статью, если такие элементарные вещи не даются?

Еще раз, тезис статьи:

1. Непредусмотренный сбой в алгоритме ломает его весь. В современных системах есть способы поймать любой сбой (catch(...)), но они используются редко, считаются плохой практикой почти везде кроме нескольких исключительных мест (вроде message loop), и вы точно никогда не станете заполнять ими все свои программы, хотя бы потому, что все равно не знаете, что делать с любой ошибкой.

2. Непредусмотренный сбой в устройстве не дает возможности им пользоваться, но операции, которые от устройства не зависят, продолжаются как ни в чем не бывало. Устройство можно выключить или перезапустить, если такое предусмотрено.

Тезис ничем не отличается от подхода Singularity, которую вы, насколько я помню, горячо поддерживали. Интересно, что изменилось? Разница в том, что Singularity реализует это в рамках процессов системы, деление на которые производт сам программист, а этот парень мечтает все свести на уровень железа, вплоть до элементарных операций, чтобы даже сами такие процессы конструировались из других.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, mkizub, Вы писали:

M>>Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?

Кё>Сломается все, что от них зависит, но ничто остальное. Если весь процессор зависит — то весь процессор, но никогда — сетевая карта. В алгоритме непредусмотренный сбой ломает все и насовсем.

Кё>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.

Какие-то двойные стандарты получаются
Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"?
Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.

Здравствуйте, Кодёнок, Вы писали:

Кё>Еще раз, тезис статьи:

Кё>1. Непредусмотренный сбой в алгоритме ломает его весь. В современных системах есть способы поймать любой сбой (catch(...)), но они используются редко, считаются плохой практикой почти везде кроме нескольких исключительных мест (вроде message loop), и вы точно никогда не станете заполнять ими все свои программы, хотя бы потому, что все равно не знаете, что делать с любой ошибкой.

Кё>2. Непредусмотренный сбой в устройстве не дает возможности им пользоваться, но операции, которые от устройства не зависят, продолжаются как ни в чем не бывало. Устройство можно выключить или перезапустить, если такое предусмотрено.

Кё>Тезис ничем не отличается от подхода Singularity, которую вы, насколько я помню, горячо поддерживали. Интересно, что изменилось? Разница в том, что Singularity реализует это в рамках процессов системы, деление на которые производт сам программист, а этот парень мечтает все свести на уровень железа, вплоть до элементарных операций, чтобы даже сами такие процессы конструировались из других.

Вы (выделенное) — это я лично? Тогда плохо помнишь, апологеты сингулярити тут есть, но я к ним не отношусь.
Что значит "всё свести на уровень железа" как-то выше моего понимания.

Здравствуйте, Кодёнок, Вы писали:

Кё>В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.

Это так, только при условии что ни аппаратная ни программная часть (драйвер) сбой не заметила. Тогда "сломавшееся" молча устройство _возможно_ ничего не затронет. Если устройство коротнёт и сожжёт всех соседей — ваше утверждение неверно. Если устройство засбоит, и нарушит работу программной части — операционная система мгновенно завершит работу (BSOD, Kernel Panic, etc.).

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

К>>Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"?
К>>Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.

Кё>Это оно и есть. Только SIP или ерланговские процессы конструируются из маленьких алгоритмов, т.е. внутри себя потенциально все еще страдают от тех же проблем (хотя в таком масштабе они вполне могут быть незаметны).
Ужасно нравятся мне такие абстрактные разговоры.
Что за "те же проблемы" на примере эрланга?
Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)

Кё>А автору захотелось отбросить алгоритмы (и концепцию Тьюринг-машины) вообще, правда что-то не ясно, как именно

Мешок хорошего плана спасёт отца нерусской демократии
(хотя по ходу спасает уже во всю)

Здравствуйте, IID, Вы писали:

Кё>>В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.

IID>Это так, только при условии что ни аппаратная ни программная часть (драйвер) сбой не заметила. Тогда "сломавшееся" молча устройство _возможно_ ничего не затронет. Если устройство коротнёт и сожжёт всех соседей — ваше утверждение неверно. Если устройство засбоит, и нарушит работу программной части — операционная система мгновенно завершит работу (BSOD, Kernel Panic, etc.).

С этим никто не спорит.

Брукс заявил, что баговость и невозможность выпускать софт таким же [более-менее] надежным как железо, останется навсегда, потому что software is a special case. Автор говорит, что при условии отказа от концепции алгоритма, возможно то самое повышение качества, известное как Silver Bullet. Это тема топика, давайте о ней поговорим?

Здравствуйте, Кодёнок, Вы писали:

Кё>Брукс заявил, что баговость и невозможность выпускать софт таким же [более-менее] надежным как железо, останется навсегда, потому что software is a special case. Автор говорит, что при условии отказа от концепции алгоритма, возможно то самое повышение качества, известное как Silver Bullet. Это тема топика, давайте о ней поговорим?

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

Здравствуйте, Курилка, Вы писали:

К>Что за "те же проблемы" на примере эрланга?
К>Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)

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

Здравствуйте, Sinclair, Вы писали:

Кё>>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.
S>Угу. Неужели ты думаешь, что если звуковуха начнет гадить в шину, то все остальные "отряхнутся и продолжат работать"?

Не думаю, но речь не о достижении абсолютной идеальной надежности, а о её повышении. Каково твое мнение, если разрабатывать софт так же, как разрабатывают железо, то

1. Ничего не изменится (потому что software is different?)
2. Качество/стоимость разработки повысится
3. Качество/стоимость понизится (потому что станет еще хуже?)

Вот что меня интересует.

S>Автор статьи также рассказывает о том, как мало багов он видел в процессорах.
S>Открытое издевательство:
S>1. Баги в процессорах находят на регулярной основе.
S>2. Стоимость разработки современного процессора — крайне высока. Если вкладывать по три-четыре миллиарда долларов в каждый софтный проект, то надежность софта резко улучшится.

А других устройств? Еще раз — процессор это частный случай. А звуковуха или модем?

Здравствуйте, Курилка, Вы писали:

К>Ну да, если отказаться от софта, то проблем с софтом не будет, эт и ежу понятно.

Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?

К>BTW это ничего, что логику процессоров описывают алгоритмами? Так же как вся математика этими алгоритмами пропитана, её тоже выкинем? И физику, коль она математикой пользуется

Так может это потому, что он специально для выполнения алгоритмов и создается? Когда же уже вы оставите этот процессор, и возьмете другое устройство?

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

К>>Что за "те же проблемы" на примере эрланга?
К>>Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)

Кё>Автор заявил, что невозможность достигнуть уровня качества других инженерных областей присуща только алгоритмам и их разработке, а если разрабатывать другим способом, например, разработка устройств из обменивающихся сигналами стандартных элементов, то это станет возможно. А т.к. ерланговские процессы конструируются из алгоритмов, то... в общем понятно. Это в теории, если хочется на практике и строго об эрланге, то лучше в комментарии к тому блогу пойти.

Т.е. он заявил, а ты ему поверил на слово?
Хороший подход.
А по поводу этого 'rebelscience' и эрланга я уже писал.
BTW на эрланге разработка системы идёт из обменивающихся сигналами процессов (отчасти стандартных)

Здравствуйте, Курилка, Вы писали:

К>Т.е. он заявил, а ты ему поверил на слово?

Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

К>>Ну да, если отказаться от софта, то проблем с софтом не будет, эт и ежу понятно.

Кё>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?

В чём аналогичны? В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.

К>>BTW это ничего, что логику процессоров описывают алгоритмами? Так же как вся математика этими алгоритмами пропитана, её тоже выкинем? И физику, коль она математикой пользуется

Кё>Так может это потому, что он специально для выполнения алгоритмов и создается? Когда же уже вы оставите этот процессор, и возьмете другое устройство?

Да возьми любую плату (звуковую, сетевую, тюнер), на ней хоть микросхема стопудов есть, её код наверняка на Verilog'е/VHDL каком-нибудь писали. Кстати последние три буквы VHDL — hardware description language.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

К>>Т.е. он заявил, а ты ему поверил на слово?

Кё>Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.

Я пытаюсь (в данной ветке) понять твою точку зрения, или (не прошу воспринять за наезд) ты только в качестве ретранслятора готов выступать?

Здравствуйте, Кодёнок, Вы писали:

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

Кё>А других устройств? Еще раз — процессор это частный случай. А звуковуха или модем?
Я уже написал свое мнение по поводу звуковухи и модема. Автор, судя по всему, либо плохо знаком с электроникой, либо намеренно пренебрегает важными деталями.
В частности, проблемами паразитного взаимодействия и того, что не все сигналы достигают точек назначения.

Далее, программирование, о котором говорит автор, реализовано в Екселе. Уже. Можно вживую посмотреть, насколько улучшения в диспетчеризации отдельных "событий" повышают надежность программ. Да, действительно, сам ексель не ляжет от ошибки в формуле. В общем случае даже можно оценить масштаб катастрофы, построив транзитивное замыкание зависимых ячеек. Ну и какое отношение это имеет к надежности? Появляется другой класс ошибок, которые крайне трудно отлавливать.
А главное — что мы вкладываем в понятие "надежности"? Если программа расчета зарплаты упала, то она упала. А если сбой в формуле экселя, то кто-то получит мало денег.

Здравствуйте, Курилка, Вы писали:

Кё>>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?
К>В чём аналогичны?

В своей природе...

К>В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.

А как её оценить? В чем измерять?

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

Кё>>>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?
К>>В чём аналогичны?

Кё>В своей природе...

Очень чёткий и конструктивный ответ

К>>В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.

Кё>А как её оценить? В чем измерять?

Как вариант — возьми за оценку — мощность множества входов/выходов (фактически это и есть взаимосвязи компонентов), причём в случае винды учти неявные входы.

Здравствуйте, Курилка, Вы писали:

Кё>>Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.

К>Я пытаюсь (в данной ветке) понять твою точку зрения, или (не прошу воспринять за наезд) ты только в качестве ретранслятора готов выступать?

Моя текущая точка зрения (которая скоро наверняка будет другой): я не вижу препятствий, чтобы то, о чем говорит автор, могло получиться.

Здравствуйте, Sinclair, Вы писали:

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

Стоимость имелась ввиду количество усилий, конечно же. Неужели разработка модема настолько сложнее, чем у тулсы на 10000 строк, что первый релиз модема работает до сих пор, а во второй находят баги в коде, написанном 5 лет назад?

S>В частности, проблемами паразитного взаимодействия и того, что не все сигналы достигают точек назначения.

А это существенно? Если паразитного взаимодействия не будет, и сигналы будут доставляться гарантированно, железо станет глючить как софт?

S>А главное — что мы вкладываем в понятие "надежности"? Если программа расчета зарплаты упала, то она упала. А если сбой в формуле экселя, то кто-то получит мало денег.

Не так. Если бы формула «упала», то в некоторых ячейках было бы «internal error», или вроде того, вместо падения всего экселя. А от другого класса ошибок, приводящих к неверным результатам, не застрахован ни тот, ни другой подход.

Этот спор уже проходили в обсуждении Singularity, между прочим. Я думал, неубежденных не осталось.

Здравствуйте, Кодёнок, Вы писали:

Разобрался, в чем дело.

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

Отличие же софта в его виртуальной «бесконечности», когда объекты и связи между ними могут рождаться во время выполнения, и самое главное, зависеть от внешних сигналов, которые непредсказуемы. Во время компиляции нельзя предугадать все комбинации новых связей (NP-полная задача), а проводить верификацию во время выполнения на каждом новом сигнале есть те же самые ошибки времени выполнения (ибо если верификация не прошла, что делать, кроме как умертвить процесс?).

Таким образом, на ограниченном числе частных случаев действительно можно применить те же методы и получать то же качество, но к 99% софта это не имеет отношения.

Неудивительно, что у этого парня нет никакой даже самой примитивной черновой модели того, что он пишет. Потому что на первой же реальной задаче метод перестанет работать.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Кодёнок, Вы писали:

Кё>Разобрался, в чем дело.

Кё>Железо проектируется из фиксированного числа элементов. Это как если писать софт только на сингтонах, без возможности создавать новые объекты. Такие конфигурации можно верифицировать на любые исходы за конечное (и легко рассчитываемое) время.

Кё>Отличие же софта в его виртуальной «бесконечности», когда объекты и связи между ними могут рождаться во время выполнения, и самое главное, зависеть от внешних сигналов, которые непредсказуемы. Во время компиляции нельзя предугадать все комбинации новых связей (NP-полная задача), а проводить верификацию во время выполнения на каждом новом сигнале есть те же самые ошибки времени выполнения (ибо если верификация не прошла, что делать, кроме как умертвить процесс?).

Кё>Таким образом, на ограниченном числе частных случаев действительно можно применить те же методы и получать то же качество, но к 99% софта это не имеет отношения.

Кё>Неудивительно, что у этого парня нет никакой даже самой примитивной черновой модели того, что он пишет. Потому что на первой же реальной задаче метод перестанет работать.

Есть ощущение, что всё это близко к Total Functional Programming

Автор: Курилка
Дата: 18.01.08

, которое по идее защищено от бесконечности и прочих _|_
Правда на данный момент оно существует практически только в рамках идеи (за исключением не очень сложных случаев).
Гипотетически подход применим к реальным задачам, только вот усилия, которые придётся затратить, немаленькие.

Здравствуйте, Кодёнок, Вы писали:

Вероятно, ореол мистики вокруг микроэлектроники развеется окончательно, если я скажу вам, что в терминах транзисторов цифровые микросхемы давно никто не проектирует. Наши браться микроэлектронщики давным давно применяют для описания микросхем полноценные языки программирования. Один из них VHDL, другой Verilog. Они отличаются от наших языков тем, что ориентированны на описание высокопараллельных процессов, и напрямую поддерживают знакомые аппаратчикам идеомы, такие, как "провода", и "конечные автоматы". Никто уже не работает в терминах транзисторов (кроме аналоговых дихайнеров и топологов), никто даже не работает в терминах вентилей вроде 2и-не. Более того, например, сумматоров давно уже никто не делает сам, достаточно написать просто + и САПР сам сгенерирует сумматор по схеме ускоренного переноса.

VHDL — вполне человеческий язык программирования, имеет свои корни из Ады.

Verilog — по уровню ниже чем наш С. Он не позволяет определять своих типов данных — вы оперируете на уровне отдельных проводов и групп проводов (то есть, булевскиепеременные и массивы таких переменных). Именно этот убогий язык, который вызовет у любого программиста рвотный рефлекс, как ни странно, наиболее распространен в коммерческих компаниях, да и вообще. Например, Intel и Sun применяют для описания процов менно его. Его развитие, которое еще на что-то приличное похоже — это SystemVerilog. В Intel начали переходить на него только недавно.

В обоих языках есть "синтезируемое подмножество", которое может быть засинтезировано в описание микросхемы. Циклы, например, вы употреблять не можете в коде, который должен быть синтезируемым. То есть, в данной области, казалось бы, макросредства и всякий полиморфизм времени компиляции должны рулить со страшной силой. Однако, например, на популярном Verilog нельзя сделать практически ничего полиморфно-генерящегося, все что там есть — это убогая конструкция generate.

Короче говоря, и у этих людей, значит, мы предлагаем учится серебрянным пулям? Да они даже языков себе нормальных придумать не могут . Я бы, кстати, с удовольствием попридумывал для них макроязычок.

Здравствуйте, Gaperton, Вы писали:

А какой был объем "исходников" у вашего видео-контроллера?

Здравствуйте, Gaperton, Вы писали:

V>>А какой был объем "исходников" у вашего видео-контроллера?

G>Самых настоящих исходников, на языке Verilog было, внимание...
G>...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.

Стоили аналогичные блоки на рынке интеллектуальной собственности год назад порядка 100К-500К USD. HDTV-блоки дорогие, ближе к верхней границе, и их было мало. Теперь, что эти три тыщи строк кода умеют, и как результат соотносится с конкурентами. Берем для сравнения, как ближайший по функциональности, видеоконтроллер высокой четкости от немецкой компании SciWorks. Который нихрена не дешевый.

1) У нас накладывается меньше видео-слоев, чем у них — всего три, один для видео, и один для меню (у них 6). На сложность это почти никак не влияет, слоев добавить небольшая проблема. Трех слоев в большинестве приложений, которые мы рассматривали, хватит, плюс лишние слои жрут площадь, и увеличивают количество режимов для верификации. Последнее — это время разработки, которого у нас не было.
2) У нас у контроллера всего один интерфейс AXI Master. У них — весь тракт от шины AXI дублируется 6 раз для каждого слоя по разу. Халявят ребята — упрощают отдельные DMA-машины для выборки видеоданных по слоям, и всю работу по смешиванию возлагают на арбитра шины AXI. У нас — внутри стоит умная DMA-машина, которая дает выборку по памяти оптимальным образом через единственный интерфейс. Это, при прочих равных экономит нам площадь. Хотя, если честно, это было требование заказчика, я думаю, мы бы тоже схалявили при возможности .
3) У нас меньше цветовых режимовдля слоя меню, чем у них. Технически поддержать эти режимы — ерунда, не проблема, но они увеличивают объем сценариев тестирования, и мы из боязни вылететь за график поддержали только разумный минимум (1 байт 2r2g2b2a, 2 байта 5:5:5:1 и 4:4:4:4, 4 байта на точку честного RGBA, никаких палитр, экзотики, и трех байтов). Тем более, зоопарк режимов цвета для меню нафиг никому не нужен.
4) У нас существенно, радикально качественнее и лучше сделано масштабирование видео-изображения. Начать с того, что оно выполняется с плавным шагом. Вы сможете сделать плавный zoom в своем плеере, если там будет применяться наш контроллер. Второе — коэффициенты по X и Y могут меняться независимо — по одной координате он может сжимать, а по другой — растягивать. То есть, вы сможете откорректировать aspect ratio картинки. В третьих, у нас применяются существенно более качественные фильтры, чем у них, при этом — они занимают немного площади. Выбору алгоритмов фильтрации, их прототипированию, и проверке на реальных картинках, было посвящего очень много временина ранних этапах. Наши тупые фильтры дают картинку лучше и четче, чем сложные полифазные фильтры.
5) У нас нет второго блока, который уменьшает картинку (для функции picture in picture). Однако, этот блок внутрь контроллера не вставишь (развертку генерирует независимо от основного), он все равно вешается сбоку от видеоконтроллера на отдельном DMA-мастере, рядом на шину, и никак от контроллера не зависит — добавить его в систему потом будет легко. Во вторых, у нас контроллер для бюджетных устройств, и там такой блок не нужен. Нет блока — нет занимаемой им площади, которая — деньги .
6) То же самое касается разнообразных bitblitting и 2D accelerator. Их нет и у SciWorx — за ненадобностью, и они также все равно должны висеть снаружи контроллера, и тупо писать во внешнюю видеопамять.

Резюмируя — у нас очень простой и симпатичный контроллер, он занимает меньше площади, чем ближайший конкурент, имеет чуть меньше цветовых режимов (ну кому сейчас нафиг нужны режимы с 8-битной палитрой? А палитра, между прочим — это внутренняя память, которая жрет площадь кристалла, даже если вы ей не пользуетесь), не поддерживает picture in picture (сбоку прикручивается, и у них на самом деле тоже сбоку), имеет только необходимый минимум слоев, зато имеет весьма хороший (заметно лучше, чем уконкурента) для бюджетного устройства блок масштабирования. Для видеокамер, DVD-плееров (которым picture in picture не вперся) и бюджетных ТВ-приставок — самое то.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Курилка, Вы писали:

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

Кё>Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.

Щаз. В эмуляторе _системы команд_ — тебе реально ничего учитывать не надо. А вот в модели современного _проца_ очень даже есть зависимости между командами. Если у тебя внутри конвейр, тебе уже надо их учитывать, не говоря уже о ситуации, если у тебя суперскаляр или неупорядоченная запись. Такие модели довольно точно повторяют внутреннюю структуру проца, если они потактово-аккуратны.

Впрочем, как рядом говорит thesz, они и правда очень легко пишутся — структурно и алгоритмически аппаратура в сотни раз уступает в сложности программным системам. Но только если делать это на Хаскеле, а не на Верилоге, а Хаскельную модель ты в микросхему не засунешь. Что само по себе уже наглядно показывает истинную разницу между программированием и разработкой микроэлектроники.

Здравствуйте, Gaperton, Вы писали:

M>>Вы тут гордитесь сделаным чипом — но за счёт чего вы его сделали? За счёт удержания минимального размера комманды.

G>Каквсе просто, оказывается. Вперед, удержи минимальный размер команды, и повтори наш результат.

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

G>Дело ведь в этом?

Не только. Ещё и в том, на что ты намекаешь.

G>Ой, какие ужасы. Но есть нюанс, почему ничего бы не пошло никуда и не поехало ни при каких обстоятельствах. "Еслибыми" моих ребят пугать не надо.

Они твои? Ты им мамка, что-ли?

G>Дело в том, что все "если бы" в данном проекте держал под контролем один менеджер. Я. А если бы я где-то ошибся, не справился, или заболел, и был бы выключен из процесса, меня бы поддержал Женя Янкевич, который хоть и тимлид, но он также отличный менеджер, которого я специально готовил, и который может если что меня заменить. И заменял. А если бы вдруг ошибся он, его бы поддержал, например, Сергей Зефиров (без моего внимания, кстати, это также не обошлось бы, поправил бы и я), который мог бы при нужде заменить Янкевича (и заменял, когда тот был в отпуске). Вообще, в нашей команде каждый инженер в менеджменте соображает больше, чем средний менеджер в индустрии. Счастлив это сообщить — во многом это так благодаря моим стараниям.

Обида душила его, справедливая обида за наезд на "наше мы".

G>Так что не переживайте . Я очень хорошо проработал fault tolerance в цепочке управления. Настолько, что команда вполне может справляться с самыми разными ситуациями и без меня. Это, знаете-ли, ключевой навык и критерий успешности руководителя, ИМХО. Должен же руководитель обеспечить себе право уйти в отпуск, когда захочет, или заниматься херней по причине нерабочего настроения, в конце концов?

Я вообще настолько о другом говорил, что не могу даже предположить на что ты отвечаешь.

Здравствуйте, mkizub, Вы писали:

M>Я вообще настолько о другом говорил, что не могу даже предположить на что ты отвечаешь.

Я всегда цитирую то, на что отвечаю, так что думаю, ты кривишь душой. Смешно просто немного. Рассказываешь тут, рассказываешь, и вдруг узнаешь — что оказывается "за счет удержания минимального размера команды чип сделали, а если бы он чуть-чуть возрос, то ахтунг". Ладно, объясню подробнее. Ты опять путаешься в причинах и следствиях, и обращаешь внимание на второстепенные детали. Ты про сути трактуешь размер команды как фактор риска, величину случайную. Это фундаментальная ошибка.
1) Дело не в размере команды, он должен быть не "маленьким", а адекватным задаче и условиям, не больше и не меньше. Для данного проекта он должен был быть таким, каким был. Не больше, и не меньше.
2) Во-вторых, никакой "формальной работы" не произошло бы, даже если бы он был не "чуть-чуть" больше, а сильно больше. Размер команды со сдвигом акцента на формальности никак не связан сам по себе. На это влияет в основном не размер, а дурацкая организация работ.

M>"и точно такая же история произошла бы и с командой этого компилятора".
Маленькая команда безусловно имеет преимущество перед большой в виде меньших издержек на коммуникации. Хотя есть разные ходы, чтобы держать этот оверхэд под контролем, но все равно хорошо, когда не лишней проблемы, с которой надо бороться. Однако, ты не имеешь прямого контролянадразмеромкоманды. Ты не можешь сократить или увеличить размер команды просто потому, что тебе так хочется. Именно применение хороших технологий, организации работ и программных, как Coq (как у них) или Хаскель (как у нас, и, по слухам, в ARM), позволяет делать ту же работу меньшим количеством людей в то же время, позволяя проектам выигрывать на коммуникациях, и быть успешнее.

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

Здравствуйте, Gaperton, Вы писали:

G>Я всегда цитирую то, на что отвечаю, так что думаю, ты кривишь душой. Смешно просто немного. Рассказываешь тут, рассказываешь, и вдруг узнаешь — что оказывается "за счет удержания минимального размера команды чип сделали, а если бы он чуть-чуть возрос, то ахтунг". Ладно, объясню подробнее. Ты опять путаешься в причинах и следствиях, и обращаешь внимание на второстепенные детали. Ты про сути трактуешь размер команды как фактор риска, величину случайную. Это фундаментальная ошибка.

Я трактую размер комманды как величину зависимую от сложности проекта, а не случайную.
А вот проект, который в котором тебе надо будет участвовать — это уже дело случая.

G>1) Дело не в размере команды, он должен быть не "маленьким", а адекватным задаче и условиям, не больше и не меньше. Для данного проекта он должен был быть таким, каким был. Не больше, и не меньше.

Именно.

G>2) Во-вторых, никакой "формальной работы" не произошло бы, даже если бы он был не "чуть-чуть" больше, а сильно больше. Размер команды со сдвигом акцента на формальности никак не связан сам по себе. На это влияет в основном не размер, а дурацкая организация работ.

Вот с этим у тебя проблемы. Дело именно в том, что формализация работы неизбежно становится необходимой при определённом количестве
людей вовлечённых в работу, а количество людей зависит от сложности проекта.

G>Маленькая команда безусловно имеет преимущество перед большой в виде меньших издержек на коммуникации. Хотя есть разные ходы, чтобы держать этот оверхэд под контролем, но все равно хорошо, когда не лишней проблемы, с которой надо бороться. Однако, ты не имеешь прямого контролянадразмеромкоманды. Ты не можешь сократить или увеличить размер команды просто потому, что тебе так хочется. Именно применение хороших технологий, организации работ и программных, как Coq (как у них) или Хаскель (как у нас, и, по слухам, в ARM), позволяет делать ту же работу меньшим количеством людей в то же время, позволяя проектам выигрывать на коммуникациях, и быть успешнее.

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

Я о чём писал Сергею? Что чистый компилятор С — это по нынешним меркам примитив. Если вы делаете новый продукт на общую продажу —
вы должны делать как минимум С++. А это сразу на порядок усложняет код. Никакие оптимизации технологии написания программ
(организации работы) не позволят вам просто линейно увеличить количество программистов и издержки. 40 человек не напишут
хороший компилятор С++. Их надо будет разбить по группам, размером в те-же 4-7 человек, каждая группа будет отвечать
за свой участок работы. У каждой группы будет менеджер, который будет отвечать за этот участок в целом и синхронизировать
работу своей группы. Будут менеджеры которые будут синхронизировать между собой результаты работы этих групп.
А ещё будет какой-нибудь sales, который общаясь с заказчиками будет регулярно вмешиваться и рассказывать,
что заказчикам позарез понадобилась новая фича — вот её добавить и будет ещё один контракт. И будет большой
начальник, который в программировании уже вообще не будет разбираться, поскольку он будет бизнесмен,
экономист, банкир и прочая. Ах да, ещё ж будут акционеры (те-же банки в которых кредит взяли), и они будут
давить со своей стороны, так как им дивиденды нужны, а не хороший код.

Не рассказывайте мне сказок про решаемость всех проблем хорошей организацией труда.
Я работал и в небольших коммандах, и в фирмах размером в 100 человек. Это небо и земля.
И дело не в плохих руководителях. Дело в том, что работа выходит из под контроля кого-бы то нибыло.
Ни начальник, ни акционеры, ни проджект-менеджеры, ни тим-лиды, ни программисты — никто никакого
контроля не имеет. Фирму просто несёт куда вынесет, при том, что все стараются как лучше.
И в больших фирмах подрабатывал, в Самсунге. Это вообще броуновское движение в чистом виде.
Не потому, что там дураки, а потому, что кибернетику читать надо.

G>Почему-то этот аспект большинство начисто игнорируют при оценке эффективности технологий, сравнивая количественную разницу в скорости, эффективности, etc. А вот мы его вовсю эксплуатируем. Разница на самом деле качественная, а не количественная, и именно она позволяет применять другие ходы для организации роабот. Вот за счет этих качества мы и "чип сделали", а не потому что у нас совершенно случайно оказалось в проекте людей немного.

Про количество переходящее в качество ты уже забыл, как про страшный коммунистический сон?

T>>И третье и последнее — если все еще продолжают разрабатывать системы автоматической верификации программ, значит, они могут удешевить разработку и наверняка ее уже удешевляют.
M>Конечно удешевляют. Удешевляют написание верифицированного кода. А верифицированный код — это маргинальная ниша.

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

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

И ими пользуется все большее количество людей.

И второе замечание: микроэлектроника — маргинальная ниша, ага.

M>Ладно, закончу на этом. Я тебе уже писал, что в тебе есть наивная уверенность, что
M>всё можно (математически, наверное) описать и формализировать. Пока ты не поймёшь, что
M>это иллюзия — что-то тебе по этому поводу доказывать — бесполезно.

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

Так же считает громадное количество умных людей. Да, практически, весь научный и деловой мир.

Это разительно отличается "наивной уверенности, что все можно (математически, наверное) описать и формализовать".

Я в этом не уверен, просто если я берусь за дело, то стараюсь подходить именно так.

Надеюсь, прояснил.

Здравствуйте, thesz, Вы писали:

T>>>И третье и последнее — если все еще продолжают разрабатывать системы автоматической верификации программ, значит, они могут удешевить разработку и наверняка ее уже удешевляют.
M>>Конечно удешевляют. Удешевляют написание верифицированного кода. А верифицированный код — это маргинальная ниша.

T>Опровергнуть заявление про "маргинальную нишу" слишком легко, чтобы я смог удержаться.

T>Системы типов представляют собой частные простые случаи систем верификации программ. Чем дальше в лес, тем больше системы типов проверяют.

T>И ими пользуется все большее количество людей.

T>И второе замечание: микроэлектроника — маргинальная ниша, ага.

Отчего не опроверг-то тогда? Верифицированный код пригодится во всех системах, где требуется высокая надежность и доступность. Речь, например, о:
1) Встраиваемом телекоммуникационном ПО. Раутеры, свитчи, софтсвитчи, АТС, и прочие. Верифицированные стеки протоколов рулят.
2) Медицинских встраиваемых приложениях, от которых зависит человеческая жизнь.
3) Практически вся авионика и космические применения.
4) Софт на кораблях и подводных лодках. Все траспортные приложения вообще, связанные сповышенной опасностью.
5) Системы управления в ядерной энергетике (это, по моему, надо вообще затребовать законодательно, и пипец — пусть как хотят рожают верифицированный код), и вообще промавтоматизация с высокой ценой ошибки.
6) Разумеется, верифицированные комиляторы. И микроэлектроника (хотя, это уже ближе к научной фантастике на текущий момент ИМХО).
7) Ну, и все военные системы, включая (но не исчерпываясь) системами, связанными с управлением вооружениями.

Мало? Ну конечно, я не сомневаюсь, что нашему mkzub этого мало, и он нацелен на самые-пресамые крупные, немаргинальные ниши. Например, написание софта для автоматизации сложных бизнес-процессов бензозаправок на VB.NET. Или, скажем, без дураков очень крупную нишу — сайты на PHP.

Здравствуйте, Gaperton, Вы писали:

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

Я действительно хочу понять те многочисленные остановки, случай, например, на Кольской АЭС, когда главный трубопровод, наиболее ответственный трубопровод, по сварному шву, вместо того, что бы нормальным образом осуществить сварку, сварщики заложили просто электрод и потом слегка его приварили сверху и, конечно, это могла быть страшная авария – разрыв большого трубопровода ВВЭРовского аппарата – это самая крупная авария с полной потерей теплоносителя, с расплавлением активной зоны и т д.

Хорошо, что персонал, как мне говорил потом директор Кольской АЭС ВОЛКОВ Александр Петрович, был так вышколен что бы быть внимательным и точным, потому, что свищь первый, который был замечен оператором, его то и в микроскоп не увидишь. Помещение шумное, каких-то звуковых сигналов то же можно было не услышать, – тем не менее оператор этот был на столько внимательным, что заметил аномалию на этом основном сварном шве.

Начались разбирательства. Выяснили, что это просто халтура была. Ответственный трубопровод халтурно заверен. Стали документацию смотреть. Там вроде подписи есть. При проверке документации оказалось, что не только подпись сварщика есть, что он качественно сварил шов, но подпись гамма-дефектоскописта, который проверил этот шов, – шов, которого не существовало в природе. И все это было сделано, конечно, во имя того, что бы увеличить производительность труда. Больше швов варить. И такая халтура, которая просто поразила, помню, наше воображение.

Валерий Алексеевич Легасов, Об аварии на Чернобыльской АЭС

Я это к тому, что если заставят рожать верифицируемый код -- его будут рожать, и будет он считаться верифицированным. До первой аварии.

Тут будет работать человеческий фактор -- если есть закон, которому тяжело удовлетворить, то проще будет его обойти. А посему, целью будет не получение действительно верифицированного кода, а получение подписи под актом приемки "верифицированного" кода.

Здравствуйте, Gaperton, Вы писали:

G>2) Медицинских встраиваемых приложениях, от которых зависит человеческая жизнь.

Вот интересно, была ли способна верификация ПО предотвратить проблемы с Therac-25?