Why software sucks?

всё сосёт (с)

>Why software sucks?

кстати вроде книга была такая, ее уже перевели на русский?

http://www.linux.org.ru/view-message.jsp?msgid=315095

> большинство программ имеют довольно несовершенную структуру кода и как правило содержат приличное количество ошибок.

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

ИМХО, дело в том, что аппаратуру тестируют в десятки раз тщательнее, чем ПО. В случае с аппаратурой выпуск "патча" после "релиза" означает перенастройку оборудования по производству микросхем, это миллионы долларов. В случае с софтом "патч" после "релиза" особых затрат не несет. Менеджеры думают: зачем мы будем вбухивать кучу денег и человекочасов на тестирование, оттягивать выход продукта на рынок, когда можно чинить ошибки по мере их выявления в продакшене? Протестим чтоб оно хоть как-то работало, да и продадим поскорее - профит.

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

А в результате мы имеем то, что имеем - глюкодром. НЕНАВИЖУ.

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

перевели, у меня где-то дома лежит вяло читаемая:)

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

Свежий пример по работе.

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

К этой системе нужен Web-интерфейс для доступа пары сотен пользователей. Типичная трехзвенка: ядро - сервер приложений - клиенты.

Интерфейсный слой разрабатывают очень "умные" мальчики с горящими отсверком величия Билл Гейтса глазами. Все делается с использованием решений Microsoft, быстрое построение, надежность .NET, ASP.NET, XML. Книжки по C#, VB, - вот что можно увидеть у них в комнате где сидят программисты. Поговорить с ними - горы кажется свернут.

Результат: четвертый год, не преувеличиваю, они настраивают и надаживают свою красивенькую с приятными цветами систему. Все как бы работает, но очень любит с грохотом падать при уже 10-15 пользователях. Падает именно промежуточный слой. Сановский сервак работает как часы. Иногда валится и от одного юзера, если он введет какие-нибудь не совсем ожиданные данные. Не с целью завалить систему, а чисто по работе.

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

как она зовется в русском варианте?

>Ядро работает на сановском серваке.

>.NET, ASP.NET

венду уже портировали на спарк или я чего-то не понял?

Ключевое слово: "клиенты".

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

ааа, все, понял

Ошибки в железе ничуть не менее редки, чем в софте. У софта гораздо больше возможных внешних условий, от того и сложность, и ошибки. А если брать технику вообще, так посмотри сколько ту же Булаву отлаживают, до сих пор лететь не может нормально.

>Булаву отлаживают, до сих пор лететь не может нормально.

Не факт, что это не обусловлено софтовыми глюками.

>Не факт, что это не обусловлено софтовыми глюками.

последний раз вроде пиропатрон был бракованный

http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html

Прочитал. И?

http://www.sqlite.org/testing.html Вот после этого можно надеяться, что ошибок будет примерно как в железках :)

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

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

имеют-имеют. Если брать СУБД, у MySQL-я test suite существенно больше sqlite'овской будет. у Postgres'а она не такая большая но они вроде еще какие-то тесты гоняют.

> Производство аппартных средств - это прежде всего понятия продукт & законченность.

законченность c какой версией прошивки ассоциируется?

> законченность c какой версией прошивки ассоциируется?

Где появляются прошивки - появляется программист и халтура,
Это обратная сторона гибкости. Ничего нового.

> Если брать СУБД

А кроме СУБД? Огласите хотя бы десяток проектов с full branch coverage.

> http://www.sqlite.org/testing.html Вот после этого можно надеяться, что ошибок будет примерно как в железках :)

+ пицот

кстати в наборе тех тестах очень мало sqlite-специфичного и очень полезно всем остальным прогам.

> А кроме СУБД? Огласите хотя бы десяток проектов с full branch coverage.

этот ваш full branch coverage

1. слишком дорог - пусть есть 32 бранча, что, 2^32 варианта прогонять?

2. не является гарантией от багов.

поэтому его и нет.

Это ответ на:

>В случае с софтом "патч" после "релиза" особых затрат не несет. Менеджеры думают: зачем мы будем вбухивать кучу денег и человекочасов на тестирование, оттягивать выход продукта на рынок, когда можно чинить ошибки по мере их выявления в продакшене?

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

> слишком дорог

> поэтому его и нет

А в sqlite есть. И в аппаратуре есть очень часто. Например, в интеловских процессорах. Да, дорого и сложно - вот терпим глюки.

> не является гарантией от багов

Гарантией не является. Шансы на нормальную работу повышает многократно.

> пусть есть 32 бранча, что, 2^32 варианта прогонять?

Неа. Для каждого бранча нужно 2 теста: когда условие под бранчем true и когда условие под бранчем false.

> Есть же сообщество, которое будет искать ошибки и писать патчи.

И никогда не будет нормального тестирования, и всегда будут ошибки..

> В опенсорсе иначе нельзя, я думаю.

На данном этапе развития, думаю, нельзя.

>> пусть есть 32 бранча, что, 2^32 варианта прогонять?

> Для каждого бранча нужно 2 теста: когда условие под бранчем true и когда условие под бранчем false.

То есть 64 теста надо

>То есть 64 теста надо

Это при изоляции каждого бранча. На практике есть "глобальные" переменные состояния, поэтому максимум 2^32 тестов.

Да и изоляция есть в функциональных языках, так что для хаскеля в безмонадных функциях как раз и будет максимум 64 теста. Налицо профит!

все ошибки делятся на 3 вида

1. неверное представление об объекте при написании кода, управляющего этим объектом. может быть вызвано некачественным проектированием либо забывчивостью программиста в момент написания.

2. опечатки

3. ошибки при проектировании

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

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

>1. неверное представление об объекте при написании кода, управляющего этим объектом. может быть вызвано некачественным проектированием либо забывчивостью программиста в момент написания.

В объектно-ориентированных языках нету средства предугадать состояние объекта и соответственно валидные с ним действия. Есть всякие design-by-contract и прочие костыли. На уровне языка поддержки нету. ООП это тупиковая ветвь развития языков. ИМХО.

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

> почему аппаратные решения, с которыми мне приходилось сталкиваться столь надежны и быстры

Потому, что они экстремально, сверхъестественно, неописуемо, невероятно, исключительно... Тупы и ограничены в возможностях. Много ли ошибок в программах "Hello, World!"? А если речь заходит о более сложных материях, все становится очень неоднозначно. Слабо спаять "аппаратный" браузер, который будет работать без какой-либо софтовой начинки? Даже китайские тетрисы имеют прошивку.

> ИМХО, дело в том, что аппаратуру тестируют в десятки раз тщательнее

Де-факто, аппаратура в десятки и сотни раз проще чем программа. Типичный процессор имеет две-три сотни команд, у каждой из которых не более трех аргументов. Естественно, для ЭТОГО можно построить полный набор тестов. И то - помним про F0,0F,C7,C8?

> Типичный процессор имеет две-три сотни команд, у каждой из которых не более трех аргументов.

Десятки и сотни мегабайт исходного когда на Verilog/VHDL.

> Де-факто, аппаратура в десятки и сотни раз проще чем программа.

> Естественно, для ЭТОГО можно построить полный набор тестов.

Полагаю, вы помните, сколько тысяч страниц в руководстве по ia32? Попробуйте, постройте полный набор тестов для FP арифметики (напоминаю - интелу, после ошибки в pentuim, для начала пришлось разработать тестопригодную _спецификацию_ на fp арифметику - очень просто, да?). Постройте полный набор тестов для out-of-order конвеера с грудой разнотипных исполнительных устройств и спекулятивным исполнением. Постройте полный набор тестов для асинхронной подсистемы памяти, с разделяемым l2 кэшем, аппаратными префетчами, буфферизацией очередей. Постройте набор тестов, который гарантирует, что все пречисленное, будучи соеденино воедино, нормально работает.

Вам это кажется простым по одной простой причине - вы этого никогда не видели вблизи.

http://www.vedomosti.ru/newsline/index.shtml?2009/09/04/831835

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

Плюсую. Когда по архитектуре эвм в универе проходили Pentium 4, мне казалось что это какое-то безумие - устройство невероятной сложности. Вспонмить только всякте reorder buffer, петли replay, и куча-куча всего, хотя это всего лишь Pentium 4. О всяких менйнфреймовских процах я молчу. И все это работает, отлично работает. И модели новые выпускают часто.

Сам я делал самые-самые простые вещт, например устройство подавления дребезга контактов, так его можно мышкой нарисовать в State CAD. И наглядно все, и работало все с первого раза.

Видимо, дело в сложности. Аппаратная байда с миллиардом деталей тоже будет глючить. БАК, например.

> Видимо, дело в сложности. Аппаратная байда с миллиардом деталей тоже будет глючить.

Ерунда , по этой логике RAM CPU вообще не должен работать

> БАК, например.
Плохой пример.
Это разовый аппаратно-программный комплекс.
Как пример: реализация xorg на чипе - большой тираж и вечная совместимость по драйверам (мечтательно)
Да , будет долго и дорого подобное отлаживаться - это ведь не релизик
текущий N+1 дистра.
Но, это не реально ...

RAM CPU состоит из абсолютно одинаковых фрагментов, каждый из которых тестировать не надо. Правда, БАК тоже. С БАКом пример неудачный, ага.

>Правда, БАК тоже

одинаковые части БАК изготовляют по планарной технологии?

> Десятки и сотни мегабайт исходного когда на Verilog/VHDL.

Ты знаком с термином "черный ящик"?

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

Сложность его внутреннего устройства никого не е^Wволнует. А "десятки и сотни мегабайт кода Verilog/VHDL" это всего лишь издержки способа реализации. Если что - сходите в download qemu, посмотрите размер файла. Да, не забудьте - там ведь практически вся платформа и вагон эмулируемого железа в этих исходниках, не только процессор.

Так что аргумент про верилог мимо кассы. Никого не волнует, что молоток из титанового сплава с балансировкой и алмазными стразами - ибо это МОЛОТОК. Чья задача е..уть потяжелее и травм не причинять.

> Сложность его внутреннего устройства никого не е^Wволнует.

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

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

Ты путаешь теплое с мягким. Quemu сделан из машинных инструкций, и существует внутри готового компьютера. Процессор сделан из кремния, и существует в физическом мире, со всеми вытекающими из этого ограничениями и трудностями. То, что ты привел столь некорректное сравнение, позволяет сделать заключение о твоей личности. А именно, есть две альтернативы:
1. Ты идиот, и в самом деле счел свое сравнение сколь-нибудь содержательным.
2. Ты сильно озабочен своим чсв, и потому пытаешься отстоять свою точку зрения, осознанно неся ахинею.
В обоих случаях нет большого смысла пытаться что-либо тебе втолковать. Согласен?

> Ты знаком с термином "черный ящик"?

Ага, давай еще проблему бытия обсудим.

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

Вот и ответ на тему топика. Кому хочется сделать безглючную нетленку, получить свои копейки и искать новую работу? Это как часы Электроника 54, которые я ношу уже 25 лет. Где теперь те, кто их собирал? А те, кто впаривал 25 лет назад глючные ораклы и виндосы, так до сих пор за бешеные бабки их и впаривают

>Когда по архитектуре эвм в универе проходили Pentium 4, мне казалось что это какое-то безумие - устройство невероятной сложности. Вспонмить только всякте reorder buffer, петли replay, и куча-куча всего, хотя это всего лишь Pentium 4. О всяких менйнфреймовских процах я молчу. И все это работает, отлично работает.

Отож. А мне тут дефективные инженеры впаривали, что жестяная бочка с соплом, называемая Булава, гораздо сложнее в устройстве и изготовлении

Ну, вот тебе раз! Все возвращается к обсуждению "булавы против core i7".

Олсо, lenta.ru/news/2009/08/31/letter/

Кстати о http://www.vedomosti.ru/newsline/index.shtml?2009/09/04/831835, булаву ни на Java, ни на C#, ни на python, ни на хацкеле не запрограммировать.