Можете ли вы написать однозначную спецификацию на естественном языке, таком как английский?

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

Это известный результат или я что-то упустил?

Разве это не то, что адвокаты всегда делали, чтобы избежать двусмысленности?

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

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

Это также то, почему мы документируем наш код, потому что иногда это трудно читать для наших умов.

Нет смысла документировать код другим кодом.

Невозможно? Давайте сначала спросим, ​​желательно ли это. Если мы согласны с тем, что это невозможно, и есть еще много полезного программного обеспечения, тогда цель однозначной спецификации кажется академической.

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

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

Чем больше проблема, тем шире аудитория, тем сложнее ее сделать.

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

хорошо .. совершенно однозначная спецификация проблемы - сам фактический код :)

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

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

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

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

или:

result = (x + y) / b

Какой из них короче? Какой из них более читабелен? Что приносит больше понимания с этим?

То же самое относится и к спецификациям. Много раз, когда вы переходите к техническим деталям, написание одной строки кода может прояснить длинный абзац объяснения.

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

Но любой формальный язык, который достаточно выразителен, чтобы делать что-то интересное, не будет свободен от противоречий (неполнота Гёделя).

Спецификации неоднозначны и неточны, потому что люди неоднозначны и неточны. Найдите идеального человека и, возможно, тогда вы сможете получить идеальную спецификацию.

Английский, суахили, санскрит или вавилонянин не имеют значения.

Неопределенность на самом деле является сильной стороной в этом контексте.

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

Людям, которые читают проектные документы (особенно функциональные проекты), на самом деле не нужен этот уровень детализации - чтение исходного кода программы, будь то на C ++, Java или однозначном английском языке, намного выше среднего уровня непрограммиста. Вот тут-то и появляются естественные языки: они позволяют составителю спецификации скользить в любом направлении по шкале деталей, перемещая нерелевантные детали реализации в подтекст или оставляя их полностью неопределенными. Естественные языки полны устройств, которые передают значение относительно ясно, даже если вы не даете точного определения (что является частью того, что делает автоматизированные переводы такими сложными).

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

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

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

Задание документации для формального языка на еще одном формальном языке было бы своего рода проблемой "курицы и яйца".

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

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

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

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

• Функциональная спецификация предназначена для описания того, что должен делать проект или функция, часто с точки зрения клиента. В общем, не следует описывать, как это должно быть сделано. В зависимости от типа проекта, клиент может заботиться о том, как выглядит внешний API, но заботится ли клиент о том, наследует ли класс A от класса B или реализует интерфейс C? Он не должен. И ни одна не должна функциональной спецификации. Это уже вводит один уровень двусмысленности: технический дизайн.
• Спецификация проекта имеет задачу описать, как должны выполняться функциональные требования, с точки зрения архитектора или технического дизайнера функции или проекта. Он предназначен для устранения неоднозначностей на высоком уровне технического дизайна. Он будет содержать те детали, которые вам не нужны в функциональной спецификации, такие как архитектура решения, включая структуру классов, наследование, возможно, даже отдельные функции и методы, в зависимости от масштаба и масштаба проекта. Архитектор заботится о том, что вы называете своими временными переменными, или вы используете список или массив для внутреннего типа данных? Предполагая, что она доверяет своим разработчикам, она не должна, как и проектная спецификация. Это вводит второй уровень неопределенности: уровень реализации.

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

Однако это не означает, что во всем документе должна быть неоднозначность. На высоком уровне не должно быть никакой двусмысленности относительно интерфейса с клиентом. Если у функции есть открытый API, он должен быть строго определен. Если система требует, чтобы дата была передана для выполнения своей работы, должна ли эта дата быть в местном часовом поясе или в UTC? Какой формат нужен? Должен ли он быть с точностью до миллисекунды, или минута просто отлично?

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

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

Можно сделать естественный язык относительно однозначным, но только с большим трудом.

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

Это необходимо привести к изобретению легального. Как далеко вы готовы пойти?

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

Таким образом, спецификации не могут быть «идеальными». Однако это потому, что люди не совершенны. Например, однозначно, что HTTP должен использовать заголовок «Referer» - правильное написание на самом деле является «Referrer».

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

Кроме того, может быть полезно быть преднамеренно двусмысленным в отношении деталей, которые не были окончательно определены или могут потребовать обновления в будущем. Например, спецификация может указывать «хэш», а не конкретно указывать md5, sha1, crc32 и т. Д.

Я считаю, что правильный ответ отрицательный. Необходимо выделить следующие вопросы:

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

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

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

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

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

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

где операторы X, Y, Zсодержат только те элементы , упомянутые в предисловии спецификации и написаны соответствующим образом формального и согласованного подмножество естественного языка. Неопределенности будут касаться того, как реализовать спецификацию, но это будет ожидаемым.

нет

Однозначная спецификация вычислений - это компьютерная программа.