Ethereal писал(а):
Но ведь есть же и третья цель, для которой стандарт-то нужен. Написание учебников, книг и статей требует чтобы читающий понимал сказанное однозначно. И право ссылаться в них на собственную реализацию еще надо заслужить. Вот тут-то и нужен стандарт. Чтобы все могли разговаривать на одном языке.
Чего-чего?
Если не получается сделать рабочий и востребованный продукт, надо переключиться на написание книг и статей, чтобы пропихнуть там? Чтобы в ответ на вопросы можно было сыпануть десяток ссылок на себя же. Это что за вера в силу печатного слова?
Ethereal писал(а):
Баранов и Ноздрунов разговаривали на языке Forth-83, даже когда ссылались на особенности разных реализаций, все равно говорили на нем.
У Баранова Форт описан с нуля. Его книги достаточно самой по себе, чтобы не только писать на Форте, но и написать Форт. А что там использовано, уже и неважно.
Ethereal писал(а):
В конце концов тема топика о свойствах перспективного стандарта. Нужно или ее придерживаться или вообще не говорить.
Любопытные правила в чьем-то бложике. Хорошо, что на этом форуме правила другие. На вопрос о подключении индикатора к вечному двигателю вполне можно убеждать человека, что вечный двигатель невозможен. А не ограничиваться обсуждением сигналов индикатора и логических уровней.
Ethereal писал(а):
Так нужно не только самого себя слушать. Вот это вот, что я написал ? В топике "Elizabeth Rather о стандарте ANS" :
Ага, интересная логика. На одном предложении выстроить умозаключения? С учетом того, что у меня материалов на порядок больше, и даже процитированное предложение неоднозначно. Я уж не говорю о подспудном стремлении верить всему, написанному по-английски. Даже с учетом американского стиля "winner takes it all", что на практике выливается в то, что американец даже перед лицом явных аргументов будет повторять, что он лидер рынка и его продукт самый-самый лучший.
А теперь начинаем убирать телегу, стоящую впереди лошади. ГОСТ 19.201-78
1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.Что характерно, никаких разрядностей или переносимостей. И вообще первые три пункта чисто организационные, требующие разъяснить, что за программа и для чего она нужна. Вот например
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.Это то, что я постоянно спрашиваю - зачем нужен этот конкретный Форт? Где он будет использоваться? Это embedded, графические приложения, вычисления/моделирования, базы данных или что-то еще? В зависимости от декларируемой области применения раскручиваются остальные характеристики системы.
2.2. В разделе «Основания для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.Вот тут сразу "до свидания, ANS". Американский национальный стандарт на территории Российской Федерации не действует, и даже не входит в перечень стандартов, на которые можно ссылаться. Например, ISO, IEEE, МЭК и т.д.
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.И опять же сначала речь идет о выполняемых функциях, а не о реализации. А вот "требования к информационным структурам на входе и выходе и методам решения" - это аж пункт 2.4.5. Это даже не телега, а ее прицеп. И как реализовать 64-битные числа, это под-подраздел вот этого раздела.
А чтобы совсем интересно стало, берем ГОСТ Р ИСО/МЭК 12207-2010 "Процессы жизненного цикла программных средств". И оттуда следует, что формирование ТЗ - это один из этапов (и далеко не первый) в жизненном цикле программы. Там вообще масса интересного. Легко подумать, что это все чистая теория, не нужная на практике ("мы просто пишем код!"). Однако та самая практика показывает, что усилия одного человека, пусть даже подкрепленные всем его адреналином, в исчезающе малом круге задач способны привести к положительному эффекту. Просто потому что параллельно образуется другой такой же адреналинщик, который приложит усилия в другую сторону. А потом они начнут до хрипоты спорить, важнее переносимость или производительность. Если уж речь идет о работе на перспективу и группой людей (а также и для группы), то и к организации работы необходимо подойти к требуемым вниманием. Надо сказать, что организационные вопросы часто оказываются проработаны без участия программиста, или же решаются им интуитивно, но характерно это в первую очередь для мейнстрима. Это при программировании на Си не нужно каждый раз решать в деталях все вопросы ТЗ, потому что оно уже сформировано, и ожидания заказчика в целом именно на характеристики Си и ложатся. К примеру, заказчик уже видел программы на Visual Studio, и невозможного не требуют. А раз так, то даже исполнение всех пунктов формирования ТЗ все равно привело бы к выводу "можно писать на Visual Studio, этот инструмент соответствует задаче". А раз уж кому-то хочется писать на элитном языке, то и уровень задач будет элитным
И не в плане "суперхитрый алгоритм и ассемблерные вставки", а в плане создания четкого и непротиворечивого описания, что, куда и зачем разрабатывается. Чтобы и лозунгами не выглядело, и в малозначимые программерские детали не закапывалось.