Sai scrivere una specifica inequivocabile in una lingua naturale come l'inglese?

Mi sembra che non sia possibile scrivere una specifica software in inglese completamente priva di ambiguità, semplicemente a causa della natura informale del linguaggio naturale - e quindi che una specifica veramente inequivocabile deve includere il codice scritto in una lingua specificata formalmente.

È un risultato noto o mi sto perdendo qualcosa?

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

Il risultato è che scrivono nei modi più innaturali, cercare di leggere i loro articoli è più difficile che mai, e nonostante ciò ci sono sempre incoerenze e ambiguità.

Hai ragione, non puoi scrivere una specifica software completamente priva di ambiguità, ma non riuscirai nemmeno a farlo implementando un linguaggio specificato formale.

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

Inutile 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, l'obiettivo di una specifica non ambigua sembra accademico.

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

Penso che dipenda dalle dimensioni 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 è farlo.

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

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

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

Sono un seguace del W3C e tendo a scrivere articoli in base alle 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 il motivo principale sia che gli sviluppatori tendono a leggere e comprendere meglio il codice. Immagina di ottenere un documento matematico 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ù corto? Quale è più leggibile? Che porta maggiore 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 consenta di scrivere specifiche non ambigue. Quindi propongo che ci dovrebbe essere una mappatura biiettiva su un sottoinsieme di inglese. Pertanto, dovrebbe essere possibile scrivere specifiche non ambigue se si aderisce a questo sottoinsieme.

Ma qualsiasi linguaggio formale sufficientemente espressivo per fare qualcosa di interessante non sarà privo di incoerenze (incompletezza di Gödel).

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

Inglese, swahili, sanscrito o babilonese non fanno differenza.

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

Per spiegare il perché, supponiamo per un momento che sia possibile utilizzare la lingua inglese in modo completamente inequivocabile, in modo che qualsiasi problema che possa essere risolto a livello di programmazione possa essere espresso in modo completo e inequivocabile. Se utilizziamo questa variante dell'inglese e la nostra descrizione descrive effettivamente il programma da scrivere in modo completo e inequivocabile, 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 documenti di progettazione (in particolare progettazioni funzionali) in realtà non vogliono questo livello di dettaglio: leggere la fonte di un programma, sia in C ++, Java o inglese non ambiguo, è molto al di sopra della media dei non programmatori. È qui che entrano in gioco i linguaggi naturali: consentono allo scrittore di una specifica di scorrere in entrambi i modi sulla scala dei dettagli, spostando i dettagli di implementazione irrilevanti nel sottotesto o lasciandoli completamente non specificati. I linguaggi naturali sono pieni di dispositivi per trasmettere significato in modo relativamente chiaro anche se non si fornisce una definizione esatta (che fa parte di ciò che rende così difficili le traduzioni automatizzate).

Quindi l'obiettivo di solito non è una specifica completa, corretta e inequivocabile; l'obiettivo è quello di scrivere una specifica che illustri chiaramente, agli umani, cosa stai per costruire.

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

Non ti manca nulla, tranne che la documentazione è scritta per essere letta dagli umani. È prevista una certa ambiguità, e persino benvenuta, perché il testo conciso è difficile da leggere (= non per gli umani).

Specificare la documentazione per un linguaggio formale in un altro linguaggio formale sarebbe una sorta di problema con galline 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 citati da altre risposte, ma sento che sto fornendo una prospettiva abbastanza diversa da rendere questo valore una risposta piuttosto che un commento.)

Prima di affrontare il problema di stabilire se una specifica può essere veramente e inequivocabilmente inequivocabile, dobbiamo affrontare la questione se debba essere inequivocabile, almeno al livello di cui ci si sta chiedendo.

Consentitemi di affrontarlo dal punto di vista di un manager di programma che lavora su un progetto di dimensioni medio-piccole o di una funzione come parte di un progetto più ampio. Di solito ci sono due diversi tipi di specifiche che verranno scritte per un tale progetto: una specifica funzionale (o PM) e una specifica progettuale (o Dev):

• La specifica funzionale ha il compito di descrivere cosa dovrebbe fare il progetto o la caratteristica, spesso dal punto di vista del cliente. Non dovrebbe, in generale, descrivere come dovrebbe essere fatto. A seconda del tipo di progetto, al cliente può interessare l'aspetto dell'API rivolta verso l'esterno, ma al cliente importa se la classe A eredita dalla classe B o implementa l'interfaccia C? Non dovrebbe. E nemmeno le specifiche funzionali. Questo introduce già un livello di ambiguità: quello del design tecnico.
• La specifica di progettazione ha il compito di descrivere come devono essere soddisfatti i requisiti funzionali, dal punto di vista dell'architetto o del progettista tecnico della caratteristica o del progetto. Ha lo scopo di risolvere le ambiguità di alto livello della progettazione tecnica. Questo conterrà quei dettagli che non volevi nelle specifiche funzionali, come l'architettura della soluzione, tra cui la struttura della classe, l'ereditarietà, forse anche le singole funzioni e metodi, a seconda dell'ambito e della scala del progetto. L'architetto si preoccupa di ciò che chiami le tue variabili temporanee o se usi un elenco o un array per un tipo di dati interno? Supponendo che si fidi dei suoi sviluppatori, non dovrebbe, e nemmeno le specifiche di progettazione. Ciò introduce un secondo livello di ambiguità: quello dell'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 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: consente agli sviluppatori di fare il loro lavoro e li eleva al di sopra delle semplici "scimmie di codice".

Questo non vuol dire, tuttavia, che dovrebbe esserci ambiguità nell'intero documento. A livello elevato, non dovrebbe esserci alcuna ambiguità sull'interfaccia con il cliente. Se la funzionalità ha un'API rivolta al pubblico, deve essere definita in modo rigoroso. Se il sistema richiede che sia passata una data per fare il suo lavoro, questa data dovrebbe essere nel fuso orario locale o UTC? Quale formato è necessario? Deve essere preciso al millisecondo o il minuto va bene?

Tornando alla domanda se il linguaggio naturale possa essere usato per creare specifiche non ambigue, è vero che non è molto bravo a catturare questo livello di chiarezza. L'ho visto fare in determinate 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 pseudocodici. Una volta che inizi a chiedere 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 inequivocabile dal punto di vista funzionale, mi permetto di dire che una tale impresa non dovrebbe nemmeno essere tentata.

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

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

La professione legale ha un disperato bisogno che la lingua sia il più inequivocabile 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 del legalese. Fino a che punto sei disposto ad andare?

Esistono diverse specifiche da parte del gruppo aperto, ISO, IETF e ITU che sono sufficientemente inequivocabili per consentire alle aziende altamente competitive di interagire con successo. Ci sono una serie 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". Tuttavia questo è perché gli umani non sono perfetti. Ad esempio, non è chiaro che HTTP debba usare un'intestazione "Referer" - l'ortografia corretta è in realtà "Referrer".

La lingua inglese è in grado di essere inequivocabile, ma gli umani sono in grado di commettere errori, inclusa l'ambiguità.

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

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

1. È possibile scrivere una specifica 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, la quantità di interpretazione richiesta e le regole imposte per la costruzione di frasi in linguaggio naturale allo scopo di scrivere il software o le specifiche del software.

La risposta alla seconda domanda è affermativa. Dato un sottoinsieme adeguatamente limitato di un linguaggio naturale con regole concordate per la costruzione e il significato della frase, il codice può essere scritto in frasi grammaticali inglesi. Ad esempio, la seguente lingua consente in modo inequivocabile di scrivere dichiarazioni 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 formali in linguaggi naturali descrivendo ciascuna procedura. D'altra parte, una specifica software spesso richiede interpretazione. Pertanto, se una specifica software può essere fornita in modo inequivocabile dipende dal livello di dettaglio coinvolto nella specifica. 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. Per 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, Zcontengono solo gli elementi menzionati nella prefazione della specifica e sono scritti in una opportunamente formale e concordato sottoinsieme di un linguaggio naturale. Le ambiguità riguarderanno quindi come implementare le specifiche, ma ci si aspetta.

No

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