Puoi scrivere una specifica non ambigua in un linguaggio naturale come l'inglese?

Non è questo che hanno sempre fatto gli avvocati per evitare ambiguità?

Il risultato è che scrivono nei modi più innaturali, provare a leggere i loro giornali è più difficile che mai, e nonostante questo ci sono sempre incongruenze e ambiguità.

Hai ragione, non puoi scrivere una specifica del software che sia completamente priva di ambiguità, ma non riuscirai a farlo anche implementando una lingua specificata formale.

Questo è anche il motivo per cui documentiamo il nostro codice, perché a volte è difficile da leggere per le nostre menti.

Nessun punto nel documentare il codice con un altro codice.

Impossibile? Chiediamo se è desiderabile prima. Se siamo d'accordo che è impossibile, e ci sono ancora molti software utili là fuori, allora l'obiettivo di una specifica non ambigua sembra accademico.

Direi che è impossibile dimostrare che tutto è perfetto e non ambiguo, sia per le specifiche che per il software.

Penso che dipenda dalla dimensione del problema. Se il problema è abbastanza piccolo, di natura matematica e forse alcuni altri criteri che mi mancano, direi che è possibile scrivere una specifica che sia fattibile.

Più grande è il problema, più ampio è il pubblico, più difficile sarà.

Ma l'avionica e altri problemi complessi suggeriscono che è possibile scrivere specifiche "abbastanza buone" in inglese per risolvere grandi problemi.

beh .. una specifica del problema inequivocabile è il codice stesso:)

Questo è un problema noto e per i sistemi mission critical speciali è obbligatorio scrivere specifiche non ambigue in un linguaggio formale (di programmazione) e poi trasformarlo in un codice che provatamente fa ciò che dice la specifica . Questo è un campo molto ristretto, il 99,999% degli sviluppatori non deve mai svolgere attività come questa, ma una volta ho parlato con un ragazzo che lo ha fatto per un sistema di controllo del traffico / ferrovia.

Sono un seguace del W3C e tendo a scrivere articoli basati sulle loro specifiche. La mia esperienza mi dice che leggere qualsiasi specifica senza codici di esempio scritti, è semplicemente un mal di testa.

Sono completamente d'accordo e penso che la ragione principale sia questa: gli sviluppatori tendono a leggere e capire meglio il codice. Immagina di ottenere una carta matematica senza alcuna formula.

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

o

result = (x + y) / b

Quale è più breve? Quale è più leggibile? Che porta più comprensione con esso?

Lo stesso vale per le specifiche. Molte volte, quando si arriva alle parti tecniche, scrivere una riga di codice può chiarire un lungo paragrafo di spiegazione.

Supponiamo che esista un linguaggio formale che permetta di scrivere specifiche univoche. Quindi propongo che ci dovrebbe essere una mappatura biiettiva per un sottoinsieme di inglese. Pertanto, dovrebbe essere possibile scrivere specifiche univoche se ci si attiene a questo sottoinsieme.

Ma qualsiasi linguaggio formale che sia abbastanza espressivo da fare qualcosa di interessante non sarà privo di incongruenze (Gödel incompletezza).

Le specifiche sono ambigue e imprecise perché le persone sono ambigue e imprecise. Trova una persona perfetta e forse poi puoi ottenere una specifica perfetta.

L'inglese, lo swahili, il sanscrito o il babilonese non fanno differenza.

L'ambiguità è in realtà un punto di forza in questo contesto.

Per spiegare perché, supponiamo per un momento che sia possibile usare la lingua inglese in un modo completamente non ambiguo, in modo che qualsiasi problema risolvibile a livello di programmazione possa essere espresso in modo completo e non ambiguo. Se usiamo questa variante dell'inglese, e la nostra descrizione descrive effettivamente il programma da scrivere in modo completo e inequivocabile, allora ne consegue logicamente che deve essere possibile eseguire una traduzione automatica nel linguaggio di programmazione di destinazione - in altre parole, la variante di L'inglese che abbiamo concepito è in realtà un linguaggio di programmazione stesso.

Le persone che leggono i documenti di progettazione (in particolare i progetti funzionali) in realtà non vogliono questo livello di dettaglio - la lettura della sorgente di un programma, sia in C ++, Java o Inglese non ambiguo, è molto più della testa media dei non programmatori. È qui che entrano le lingue naturali: consentono allo scrittore di una specifica di scorrere in entrambi i modi sulla scala di dettaglio, spostando dettagli di implementazione irrilevanti in sottotesto, o lasciandoli completamente non specificati. I linguaggi naturali sono pieni di dispositivi per trasmettere il significato in modo relativamente chiaro anche se non stai fornendo una definizione esatta (che è parte di ciò che rende le traduzioni automatizzate così difficili).

Quindi l'obiettivo di solito non è una specifica completa, corretta e non ambigua; l'obiettivo è scrivere una specifica che illustri chiaramente, agli esseri umani, ciò che stai per costruire.

Ogni volta che hai bisogno di correggere e non ambiguo, e comunque le cose stanno diventando tecniche, lo pseudocodice è spesso più prezioso dei linguaggi naturali o rigidi formali - può ancora tralasciare dettagli irrilevanti (chiamando funzioni / processi non specificati), ma il la struttura non è ambigua.

Non ti manca nulla, tranne che la documentazione è scritta per essere letta dagli umani. Ci si aspetta qualche ambiguità, e persino gradita, perché il testo terso è difficile da leggere (= non per gli umani).

Specificare la documentazione per un linguaggio formale in un altro linguaggio formale sarebbe una sorta di problema di gallina e uova.

Se hai davvero bisogno di specifiche formali, allora ci sono modi formali per controllare i modelli . È un'area di ricerca attiva e molto interessante, ma gli "utenti" finali qui sono macchine, non umani.

(Alcuni dei miei punti sono già stati accennati da altre risposte, ma sento che sto fornendo una prospettiva abbastanza diversa da far sì che valga la pena di dare una risposta piuttosto che un commento.)

Prima di affrontare la questione se una specifica può essere veramente e completamente non ambigua, dobbiamo affrontare la questione se dovrebbe essere inequivocabile, almeno al livello che stai chiedendo.

Consentitemi di approcciarlo dal punto di vista di un program manager che lavora su un progetto di dimensioni medio-piccole o una funzionalità come parte di un progetto più ampio. Di solito ci sono due diversi tipi di specifiche che verranno scritte per un progetto del genere: una specifica Funzionale (o PM) e una specifica Design (o Dev):

• Le specifiche funzionali hanno il compito di descrivere cosa dovrebbe fare il proiettile o la funzione, spesso dal punto di vista del cliente. In generale, non dovrebbe descrivere come dovrebbe essere fatto. A seconda del tipo di progetto, al cliente può interessare l'aspetto dell'API esterna, ma il cliente si preoccupa se la classe A eredita dalla classe B o dall'interfaccia C delle implementazioni? Non dovrebbe. E nemmeno la specifica funzionale. Questo già introduce un livello di ambiguità: quello del design tecnico.
• Le specifiche di progettazione hanno il compito di descrivere in che modo devono essere soddisfatti i requisiti funzionali, dal punto di vista dell'architetto o del progettista tecnico della funzione o del progetto. Ha lo scopo di risolvere le ambiguità di alto livello del design tecnico. Questo conterrà quei dettagli che non si desideravano nelle specifiche funzionali, come l'architettura della soluzione, inclusa la struttura della classe, l'ereditarietà, forse anche singole funzioni e metodi, a seconda dell'ambito e della scala del progetto. L'architetto si preoccupa di ciò che chiamate le tue variabili temporanee o se usi un elenco o un array per un tipo di dati interno? Supponendo che si fida dei suoi sviluppatori, lei non dovrebbe, e nemmeno le specifiche di progettazione. Questo introduce un secondo livello di ambiguità: quello di implementazione.

In generale, questi dettagli a livello di implementazione non vengono acquisiti in un documento formale, ma piuttosto documentati, di per sé , nel codice stesso, inclusi i commenti. Questo livello di ambiguità consente a un buon sviluppatore di utilizzare le proprie capacità e di prendere decisioni tecniche orientate al dettaglio che sono il segno distintivo di un buon sviluppatore individuale. Per questo motivo, non esiterò a dire che l'ambiguità in una specifica è, in effetti, una buona cosa: permette agli sviluppatori di fare il proprio lavoro e li eleva al di sopra delle semplici "code-scimmie".

Questo non vuol dire, tuttavia, che ci dovrebbe essere ambiguità attraverso l'intero documento. Al livello elevato, non dovrebbe esserci alcuna ambiguità sull'interfaccia con il cliente. Se la funzione ha un'API pubblica, deve essere rigorosamente definita. Se il sistema richiede una data per essere passato a fare il suo lavoro, questa data dovrebbe essere nel fuso orario locale o UTC? Che formato è necessario? Ha bisogno di essere preciso al millisecondo, o il minuto va bene?

Tornando alla domanda di se il linguaggio naturale può essere usato per creare specifiche non ambigue, è vero che non è molto bravo a catturare questo livello di chiarezza. L'ho visto fare in alcune circostanze limitate, ma quelle sono probabilmente eccezioni uniche che non possiamo applicare universalmente. Molto spesso, l'ambiguità viene risolta con l'aiuto di gergo tecnico, diagrammi o persino pseudocodice. Una volta che inizi ad arruolare l'aiuto di tali strumenti, il linguaggio naturale cessa di essere l'unico descrittore. Poiché questi strumenti possono rendere molto più chiara anche una specifica completamente funzionalmente non ambigua, mi permetto di dire che una simile impresa non dovrebbe si può anche tentare.

Detto questo, poiché il linguaggio naturale è generalmente integrato da questi strumenti per renderlo funzionalmente non ambiguo, è la mia opinione professionale che no, il linguaggio naturale da solo non è sufficiente per creare specifiche univoche in tutti i casi .

Si può rendere il linguaggio naturale relativamente non ambiguo, ma solo con grande difficoltà.

La professione legale ha un disperato bisogno di linguaggio per essere il più ambiguo possibile. Mentre molto su come viene applicata una legge può essere aperto all'interpretazione, ciò che le parole significano non dovrebbe.

Questa necessità ha portato all'invenzione di legalese. Quanto sei disposto ad andare?

Ci sono un certo numero di specifiche del gruppo aperto, ISO, IETF e ITU che sono sufficientemente inequivocabili da consentire alle aziende altamente competitive di interoperare con successo. Ci sono un certo numero di specifiche che sono alla base di contratti o leggi in cui sono in gioco milioni di dollari.

Quindi le specifiche potrebbero non essere "perfette". Comunque è perché gli umani non sono perfetti. Ad esempio, non è ambiguo che HTTP debba utilizzare un'intestazione "Referer" - l'ortografia corretta è in effetti "Referrer".

La lingua inglese è in grado di essere non ambigua, ma gli esseri umani sono in grado di commettere errori, compresa l'ambiguità.

Inoltre può essere utile essere volutamente ambigui per i dettagli che non sono stati finalizzati o potrebbero dover essere aggiornati in futuro. Ad esempio una specifica può specificare un "hash" piuttosto che specificando specificatamente md5, sha1, crc32 ecc.

Credo che la risposta corretta sia negativa. È necessario distinguere le seguenti domande:

1. È possibile scrivere una specifica del software in un linguaggio naturale che non contenga ambiguità?
2. È possibile scrivere software in un linguaggio naturale che non contenga ambiguità?

La differenza tra la prima e la seconda domanda riguarda il livello di dettaglio coinvolto, la quantità di interpretazione richiesta e le regole imposte sulla costruzione di frasi nel linguaggio naturale ai fini della scrittura del software o delle specifiche del software.

La risposta alla seconda domanda è affermativa. Dato un sottogruppo opportunamente vincolato di un linguaggio naturale con regole concordate per la costruzione e il significato delle frasi, il codice può essere scritto in frasi grammaticali in inglese. Ad esempio, la seguente lingua consente in modo univoco di scrivere le istruzioni di assegnazione:

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.

Cioè, possiamo tradurre sistematicamente il codice scritto in linguaggi di programmazione formale in linguaggi naturali descrivendo ogni procedura. D'altra parte, un specifica del software richiede spesso l'interpretazione. Quindi, se una specifica del software può essere data in modo inequivocabile dipende dal livello di dettaglio coinvolto nelle specifiche. Tuttavia, dato un dominio selezionato su cui si estende la specifica, con particolari operazioni su questo dominio selezionato, è possibile eseguire un processo di traduzione simile. Ad esempio:

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.

dove le dichiarazioni X , Y , Z contengono solo quegli elementi menzionati nella prefazione della specifica e sono scritti in un sottoinsieme adeguatamente formale e concordato di un linguaggio naturale. Le ambiguità riguarderanno quindi come implementare le specifiche, ma ciò è previsto.

No

Una specifica non ambigua di un calcolo è un programma per computer.