Perché la verbosità è negativa per un linguaggio di programmazione? [chiuso]

Ho visto molte persone in giro lamentarsi della verbosità nei linguaggi di programmazione. Trovo che, entro certi limiti, più un linguaggio di programmazione sia dettagliato, migliore è capire. Penso che la verbosità rafforzi anche la scrittura di testi più chiari APIper quel particolare linguaggio.

L'unico svantaggio che mi viene in mente è che ti fa scrivere di più, ma intendo, la maggior parte delle persone usa IDE che fanno tutto il lavoro per te.

Quindi, quali sono i possibili svantaggi di un linguaggio di programmazione dettagliato?

L'obiettivo è una rapida comprensione

"Verbose" significa "usa troppe parole". La domanda è: "troppi".

Un buon codice dovrebbe essere facile da capire a colpo d'occhio. Questo è più semplice se la maggior parte dei caratteri serve direttamente allo scopo del codice .

Segnale vs rumore

Se una lingua è dettagliata, gran parte del tuo codice è rumore. Confronta "Hello World" di Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... con Ruby:

print "Hello World!"

Il rumore spreca energia mentale.

Cryptic vs Clear

D'altra parte, l' eccessiva terseness in una lingua costa anche energia mentale. Confronta questi due esempi da Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Colpisce la quantità di codice che puoi vedere e analizzare in una sola occhiata

x++ piuttosto che set(x,Integeradd(get(x),1))

ps. Non si tratta solo di leggere il codice. Ai giorni delle schermate 40x25, le lingue di tipo APL, o Perl, erano utili su Cobol o Fortran per la quantità di codice che si poteva leggere / pagina. Ma ora si tratta più della tua cache interna - se un'istruzione ha un singolo operatore è più facile per il mio cervello invecchiato analizzare uno con 3 simboli e 4 chiamate di funzione.

Se la verbosità della lingua toglie la leggibilità del codice, allora è cattiva.

Alcune lingue hanno una sintassi così dettagliata che la comprensione del significato del codice richiede più tempo (sto pensando a VB.NET rispetto a C #):

If something Then
End If

if(something)
{}

Si riduce davvero a ciò che un programmatore ha familiarità e confidenza.

Dai un'occhiata ad AppleScript , uno dei linguaggi più prolissi a cui posso pensare che potrebbe essere considerato attuale , prova a scrivere qualcosa di trivalente in esso e torna indietro e prova a sostenere che la verbosità è un buon tratto in una lingua.

Cercare di ricordare tutta la semantica di dove vanno le parole chiave e cosa sono non è banale se non lo fai tutti i giorni.

Guarda tutto il rumore delle parole chiave in questo banale esempio:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

concesso lo stesso bashcon gli strumenti Unix tradizionali sarebbe conciso ma criptico per la maggior parte degli utenti OSX, quindi c'è un equilibrio che deve essere raggiunto.

Penso che devi girare la domanda sulla sua testa e chiedere: perché alcune persone pensano che il codice terse sia buono?

La mia risposta sarebbe che ci sono due ragioni fondamentali:

Ragioni per cui Terse può essere migliore

Questi includono essere più leggibili, allo stesso modo in cui una frase breve può essere più comprensibile di una frase fiorita e dettagliata. Spesso i linguaggi di programmazione che cercano di emulare la grammatica della lingua inglese finiscono per essere orribilmente prolissi, che richiedono enormi distese di codice per eseguire le azioni più semplici. Spesso scoprirai che più una lingua emula una lingua scritta, più è difficile convincerla a eseguire operazioni logicamente complesse.

Ragioni per cui Terse può essere peggio

Alcune lingue (e sto pensando al Perl) usano una serie di strani simboli, che sembrano essere stati scelti quasi arbitrariamente, come parte della loro sintassi. Per chiunque non abbia familiarità con questi geroglifici, la lingua diventa impenetrabile. Diventa anche facile commettere errori di battitura che non sono facilmente visibili. Le espressioni regolari forse incarnano questo tipo di terseness.

Inoltre, ad alcune persone piace mettersi in mostra scrivendo codici concisi perché, francamente, pensano che li faccia sembrare intelligenti. Lo vedi a volte su StackOverflow, dove le persone spesso inviano risposte estremamente compatte a spese della leggibilità. Questo è un tipo di "impressione dei tuoi colleghi" con quanto conosci la filosofia, ma i bravi programmatori si rendono conto che il " golf del codice " non è il modo di creare software gestibile.

@frowing, suggerirei che un modo per esaminare il problema della verbosità è rendersi conto che la programmazione è sempre un mix di due stili piuttosto diversi di ricerca ed espressione di una soluzione.

Il primo e più dettagliato stile è la programmazione orientata al linguaggio (linguistica). Questo stile combina parole simili a un sostantivo e parole simili a un verbo all'interno di strutture simili a una frase, ed è inteso per essere letto e compreso in modo molto simile a un paragrafo ben scritto. La programmazione linguistica è lo stile più universale di programmazione poiché il linguaggio stesso è universale. Per lo stesso motivo, il supporto di programmi a lungo termine necessita sempre di una potente componente linguistica, poiché la prima cosa che un nuovo programmatore cercherà è la comprensione concettuale di ciò che viene fatto. Come regola generale, più ti allontani dal contesto in cui hai creato un programma, più importante sarà uno stile linguistico di programmazione per garantire che i tuoi presupposti e concetti non vengano fraintesi dalla persona successiva che cerca di capire il tuo codice .

Il secondo e più conciso stile è la programmazione matematica (orientata alla matematica). Questo stile di ragionamento si basa anche sul linguaggio, poiché ad esempio le variabili sono analoghe ai sostantivi e gli operatori ai verbi. Tuttavia, il ragionamento matematico sfrutta la straordinaria e altamente parallela capacità dei nostri cervelli di effettuare complesse trasformazioni spaziali su oggetti che si trovano all'interno della nostra linea di visione. Rappresentando nomi e verbi come simboli compatti e distintivi che possono essere disposti in oggetti immaginari ben strutturati - equazioni - possiamo quindi usare le nostre capacità visive altamente parallele per eseguire rotazioni, sostituzioni, movimenti, inversioni e altre trasformazioni su questi immaginari oggetti. Il risultato è un'enorme amplificazione del numero di casi che possiamo gestire contemporaneamente, poiché ogni simbolo può rappresentare intere classi di oggetti strettamente correlati.

Nota che per applicare efficacemente l'elaborazione visiva, devi mantenere il tuo oggetto immaginario il più simile possibile per dimensioni e caratteristiche a un oggetto reale. Se il campo visivo necessario diventa troppo ampio, o i simboli non possono essere usati come segni mobili su un oggetto, o se devi “leggere lettere” e convertirle in parole, la capacità di eseguire trasformazioni complesse in modo affidabile cadrà rapidamente anche per un ottimo matematico.

Ecco perché le persone immerse profondamente nello stile matematico della programmazione possono diventare seriamente infelici se un'equazione viene diffusa ed espressa in quello che chiamerebbero uno stile linguistico "verboso". Non è perché l'equazione è stata modificata in modo significativo, è perché diffonderla in questo modo può rendere quasi impossibile applicare uno stile visivo di comprensione ad essa. Allo stesso tempo, è probabile che un nuovo programmatore che non abbia familiarità con i simboli brevi preferisca una versione più dettagliata che fornisca più informazioni linguistiche per comprendere inizialmente cosa fa il codice.

Quindi cosa consiglierei?

Usa entrambi gli stili, ma presta molta attenzione al motivo per cui stai usando ogni stile.

Ad esempio, tutto ciò che ha la possibilità di interfacciarsi con il mondo esterno dovrebbe essere intensamente dettagliato ad un certo livello, anche se solo sotto forma di commenti incorporati mescolati con il codice, e dovrebbe includere anche controlli automatizzati per un corretto utilizzo. Notazioni criptiche e soprattutto definite in modo incompleto non hanno affari in tali interfacce, dal momento che sono quasi garantite per essere fraintese ad un certo punto. La perdita del Mars Climate Obiter del 1999 a causa di un fallimento nel riconoscere se le unità di interfaccia software fossero espresse in libbre o Newton è un esempio particolarmente evidente dei pericoli di affidarsi troppo casualmente a numeri grezzi su interfacce software o hardware.

Al contrario, qualsiasi forma di programmazione profondamente algoritmica e matematica è una buona programmazione succinta che supporta lo stile matematico del ragionamento. Se qualcuno di nuovo deve mantenere tale codice, di solito sarebbe meglio per loro imparare le notazioni matematiche invece di provare a trasformare il codice in forme più dettagliate. Ovviamente ci dovrebbe essere sempre la documentazione facilmente disponibile per spiegare le parti matematiche del codice disponibile per tali sviluppatori, ma questo è un problema separato.

Tra questi due estremi ci sono molti casi in cui il programmatore ha una notevole discrezione. Suggerirei di esaminare come il codice verrà mantenuto a lungo termine e di cercare di soddisfare le esigenze delle persone che più probabilmente mantengono il codice a lungo termine.

Un certo numero di persone ha accennato a qualcosa che penso dovrebbe essere dichiarato esplicitamente.

La verbosità tende a favorire la comprensione a livello microscopico - in genere porta a un'affermazione individuale di facile lettura e comprensione. La verbosità tende anche a ridurre il grado di familiarità con la lingua necessaria per capirla (almeno in parte). I linguaggi più dettagliati (ad esempio, COBOL) possono essere almeno in qualche modo leggibili anche da non programmatori completi.

La concisione tende al contrario: aiuta a comprendere a livello macroscopico, specialmente dai programmatori con la più intima familiarità con quel particolare linguaggio. Allo stesso tempo, la mancanza di familiarità con quel linguaggio specifico può impedire persino una comprensione rudimentale, anche da parte di programmatori che sono altrimenti abbastanza esperti.

Pertanto, la leggibilità varia ampiamente a seconda del pubblico di destinazione. Da un lato, considera un progetto ampio e complesso che viene scritto e gestito da persone che lavorano quasi esclusivamente su quel progetto, la maggior parte delle quali ha un notevole background di programmazione e formazione (ad esempio, molti dottorandi). Ciò tenderà a favorire un linguaggio più conciso.

Più o meno all'estremo opposto, prendi in considerazione un progetto che è considerevolmente più semplice (anche se forse ancora abbastanza grande) gestito principalmente da persone specializzate nel business associato al software, piuttosto che nel software stesso. Ciò favorirà quasi sicuramente un linguaggio molto più dettagliato.

Piuttosto che andare a un libro tecnico, torno a Elements of Style * di Strunk and White. Il concetto alla base è "Sii preciso" e "Non dire più del necessario". Tutto il resto è commento.

Applicato alla programmazione, si tratta di essere molto precisi, ma di non avere lanugine non necessarie. La lanugine in più può essere sintassi, ma potrebbe anche essere più parole del necessario per trasmettere significato. (Ovviamente non troppo pochi per consentire l'ambiguità)

• Cito la versione originale poiché è la più concisa. :-)

Alla fine della giornata, tutto ciò che è "diverso" farà urlare le persone. Sono a mio agio con la sintassi in stile C e quindi ok con altri linguaggi che condividono una sintassi simile (C ++, Java, C #). Quindi tendo a favorire questo stile particolare.

Le lingue tendono a trovare un equilibrio tra abbastanza descrittivo e non dettagliato.

Perl è un esempio di dove puoi scrivere un codice molto conciso. Per chi non lo sapesse, il codice scritto da un ninja Perl è a dir poco magico.

COBOL è un esempio di troppo prolisso.

Ho letto da qualche parte una volta che gran parte del dibattito prolisso viene da nuovi programmatori contro vecchi. L'analogia usata era che quando impariamo qualcosa di nuovo, ci raccontiamo una "storia" per superarla (pensate a quando avete imparato l'algebra in HS). Man mano che acquisiamo esperienza, andiamo oltre la necessità di una storia che spieghi i singoli componenti e ne comprendiamo una quantità maggiore. Il nostro codice diventa più denso e più conciso, con commenti che spiegano solo gli elementi necessari, invece di ripetere ciò che dice il codice.

Ho trovato che questo è vero tra me e un collega. Scrive codice con molti commenti che spiegano quali sono le righe di codice e un sacco di spazio bianco. Se lo sto leggendo, trovo che per questo motivo posso inserire solo poche righe di codice su una schermata. Ciò rende la comprensione di ogni singola linea molto più semplice, ma il trekking rende l'intera funzione molto più difficile.

Tendo a scrivere codice senza spazi o commenti extra. Questo rende il tutto molto più semplice, ma devi essere semplicemente in grado di "ottenere" le "parole" del singolo codice. Se provassi a leggere questa risposta con ogni parola sulla sua stessa riga, con un sacco di spazi bianchi / commenti / verbosità extra, sarebbe molto più facile capire ogni singola parola, ma molto più difficile da capire il tutto.

Einstein ha capito bene: "Rendi le cose il più semplici possibile, ma non più semplici".

Questo vale anche per il codice. Se puoi semplificare il codice rimuovendo elementi ripetitivi e inutilmente prolissi, questa è una buona cosa.

Inoltre, alcuni casi studio suggeriscono che la produttività del programmatore misurata in righe di codice è più o meno una costante. Lo stesso vale per il numero di bug per LOC. Quindi passare a una lingua che ti consente di fare di più per riga di codice può essere considerato un miglioramento della produttività, se tutte le altre cose rimangono uguali.

Detto questo, c'è una tendenza in questo settore a progettare eccessivamente e complicare quelle che dovrebbero essere cose semplici. Cose semplici come riempire i dettagli di contatto in un database relazionale. Ho visto alcune soluzioni ridicolmente complicate e fuorviate ( tosse MDA) per quel particolare problema. Lingue come Scala e Ruby sono buoni esempi di potenti strumenti che nelle mani di determinati individui danno origine a codici incomprensibili, eccessivamente complicati e scarsamente mantenibili. Solo perché puoi usare più livelli di indiretta con pochi colpi di chiave non significa che devi battere ogni chiodo in vista con quel particolare martello.

Se usato correttamente, ottieni un codice pulito che è sia breve che facile da capire. Se usato male, è meglio limitare la persona in questione all'utilizzo di Visual Basic o di un linguaggio altrettanto limitato per prevenire ulteriori danni.

La vera abilità sta nel fare cose complesse in modo semplice, non nel fare cose semplici in modo complicato.

Qualcosa che nessun altro ha colpito è la quantità di codice che puoi inserire in una schermata. Aiuta per diversi motivi:

• Meno scorrimento avanti e indietro quando si sta lavorando (o leggendo) più funzioni in un file.
• Meno scorrimento orizzontale (interrompere la lettura, fare clic e trascinare la barra di scorrimento, interrompere la lettura, fare clic e trascinare la barra di scorrimento ...).
• Scansione più rapida, poiché la sintassi è meno inutile nel modo di trovare ciò che desideri.

Perché più codice significa più tempi di sviluppo e più bug.

Se scrivi 100 righe di codice anziché 300 righe di codice. Ciò significa quasi 1/3 dei tempi di sviluppo necessari e 1/3 dei potenziali bug che potresti incontrare.

Nella maggior parte dei casi è necessario bilanciare l'efficienza e la concisione, poiché scrivere meno codici significa che la macchina deve fare più cose e diminuirà l'efficienza.

Di solito, le persone preferiscono le lingue leggibili / verbose rispetto a quelle criptiche / chiare. Tuttavia, penso che la maggior parte delle persone abbia assimilato la "verbosità" con il "disordine", che non sono la stessa cosa.

Per esempio: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

è un'affermazione molto concisa. Contiene tutto quello che vuoi sapere. Tuttavia, a causa della sua morbidezza, è difficile da capire. D'altra parte, una versione leggermente più dettagliata dello stesso programma sarebbe abbastanza semplice da capire perché è più leggibile. Ovviamente questa non è una proprietà del linguaggio di per sé, ma alcune lingue tendono a una maggiore verbosità mentre altre tendono a una maggiore concisione nel loro modo di programmare.

All'altro estremo della verbosità, è http://en.wikipedia.org/wiki/Literate_programming , che considero un concetto piuttosto interessante.

Un altro aspetto è la "verbosità indesiderata", chiamata anche "disordine". Cose che devi aggiungere per motivi tecnici, mancanza di zucchero sintattico, API gonfiate e così via.

Penso che una sintassi chiara e intuitiva sia molto importante. Deve anche essere abbastanza dettagliato per facilitare una lettura facile. Dichiarazioni troppo brevi piene di troppa logica spesso possono portare a più tempo per la decifrazione rispetto alle loro controparti leggermente più lunghe. D'altra parte, l'inutile codice gonfio pieno di righe di caldaia per fare qualcosa di assolutamente semplice è ugualmente fastidioso.

La verbosità è una tendenza ad usare grandi quantità di testo e Terseness l'uso di pochissimo testo ...

La verbosità è cattiva perché:

1. introduce maggiori opportunità di errore tipografico
2. rende più difficile leggere il codice sullo schermo o sulla carta e / o inserire sulla scheda perforata
   1. questo aumenta i tempi di debug
   2. questo rende più difficile la comprensione del codice per l'aggiornamento / la manutenzione
   3. questo può portare alla duplicazione involontaria del codice
3. aumenta in qualche modo la probabilità di errore di sintassi
4. diminuisce la flessibilità di codifica, in quanto la maggior parte delle lingue verbose sono altamente strutturate e non hanno più modi di dire la stessa cosa.
5. aumenta i tempi di codifica e compilazione
6. può richiedere più spazio di archiviazione.

Un certo livello di verbosità è essenziale per la chiarezza, tuttavia ...

un livello minimo di verbosità è buono perché:

1. è più facile per gli umani leggere e associare un valore semantico a un codice puramente simbolico
2. Nella denominazione delle variabili e delle funzioni, semplifica il debug, il port e il mantenimento del codice
3. nelle operazioni linguistiche di livello base e parole chiave di lingue complesse, porta a un minor numero di operazioni / assegnazioni di parole chiave errate.

Alcuni meravigliosi esempi di comandi troppo concisi per molte persone includono i vecchi standbys BASIC di val(x$), str$(x)e chr$(x)... restituiscono un numero dalla sua rappresentazione di stringa, restituiscono una stringa per un numero e restituiscono un singolo carattere con valore ASCII x come stringa.

O il puntatore C / C ++ e dagli operatori di riferimento &e *rispetto alla byrefparola chiave BASIC . In C / C ++, posso avere una variabile X e passare un puntatore a quella variabile, ma devo ricordare quale è il puntatore e quale è "usa il puntatore come variabile a cui punta"; in base, passo semplicemente il riferimento con una parola chiave byref nella chiamata di funzione, che è più chiara, ma meno flessibile:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

In questo codice, i contenuti di x vengono modificati a causa del flag byref. Alcuni sapori consentono il byref a chiamata, altri nella definizione, alcuni in entrambi.

La verbosità è importante per i programmatori occasionali per poter usare il simbolismo più facilmente; BASIC o Python sono più leggibili dall'uomo e più dettagliati di C / C ++ e quindi molto più utili per programmatori occasionali; la terseness di C / C ++ lo rende molto migliore per i programmatori più esperti, che hanno bisogno di vedere più codice e codice più complesso in una schermata, ma hanno dovuto imparare le varie convenzioni della struttura simbolica. In fondo c'è APL, che è quasi completamente illeggibile per l'uomo.

Un problema intimamente correlato è la chiarezza: il codice conciso è spesso poco chiaro e un codice eccessivamente dettagliato (come in AppleScript) può essere altrettanto poco chiaro. La familiarità con un determinato linguaggio aumenta la chiarezza del codice terse all'interno di quel linguaggio - un principiante grezzo, che affronta il codice C ++ è probabilmente in grado di analizzare solo le formule, e anche molto codice BASIC o Python funzionale è troppo conciso per la comprensione, ma applecript può essere perplesso, generalmente, senza ricorrere ai dizionari linguistici. Il meno chiaro che ho incontrato senza offuscamento intenzionale è Inform 7 ...

Ai vecchi tempi

Un'altra considerazione importante in passato, ma che non è più così importante per il programmatore hobby, è il funzionamento e lo spazio di archiviazione. (È ancora vitale nella fascia alta.) Tenendo presente che molte lingue sono state interpretate, in particolare i sapori BASIC, e molte altre sono state compilate in fase di esecuzione, lo spazio del codice era importante, soprattutto quando i dischi contenevano solo 128 KiB e le schede perforate individuali solo 80B.

Esistevano diverse soluzioni: la tokenizzazione era estremamente comune in BASIC; le parole chiave della singola lingua sono state ridotte a una parola di 1 o 2 byte nella parte superiore 128 o nello spazio dei caratteri di controllo. La tokenizzazione porta anche alla compilazione di bytecode (come in Inform e Z-Machine).

La compilazione e il collegamento di più file oggetto sono stati utilizzati anche per aggirare le limitazioni di spazio. Una sezione di codice Pascal da 100 KiB potrebbe essere compilata in soli 5 KiB; collegando più file compilati, è possibile creare applicazioni di grandi dimensioni senza avere accesso a unità di grande formato (ricordando che 10 MiB era sorprendentemente grande e acquistare una nuova auto costosa).

Linguaggi più concisi, tuttavia, ottennero più codice in un determinato blocco sia di disco che di ram, e quindi compilarono blocchi più grandi alla volta. Tenendo a mente: i "minicomputer" dei primi anni '70 potrebbero avere solo 64 KiB di ram (il Honeywell 800 aveva un'installazione base di 4 banchi ciascuno di 2048 parole di 8B ciascuno). APL e linguaggi simbolici simili si sono avvicinati a 1 B per istruzione più i suoi operandi, rispetto al 3B-10B molto più grande per istruzione più operandi. (È stato un incubo digitare su schede perforate, soprattutto perché i simboli erano essenzialmente un carattere sulla palla di tipo, e molti lanci di carte non avevano i simboli sui tasti ...)

Inoltre, tieni presente che le carte non possono essere cancellate ... e molti programmi sono stati inseriti nelle carte. Sebbene non sia individualmente costoso, più il codice potrebbe essere compresso sulla scheda, meno necessario e più grandi potrebbero essere i programmi o meno costosi. Questo è uno dei motivi per cui BASIC ha una concatenazione di più istruzioni per riga nella maggior parte dei gusti: è stato introdotto per risparmiare sulle schede perforate. (O almeno così dice il mio testo di programmazione Vax Basic.) Mentre non ho programmato per un lettore di schede, ho eseguito la perforazione della scheda per un Honeywell 800 in FORTRAN, BASIC, APL e un paio di altri linguaggi altamente simbolici.

Come in tante altre cose, la risposta dipende dalla definizione concreta di "verbosità". Se la definizione è tale che la verbosità implica ridondanza, direi che è sempre negativo. Si noti che con una tale definizione il programma ciao mondo spesso citato Java non si qualificherebbe come "dettagliato", perché non contiene nulla che sia ridondante.

I programmatori tendono ad apprezzare i linguaggi con potere espressivo in quanto consentono loro di codificare le cose semplici, che spesso devono essere fatte frequentemente, in piccoli pezzi di codice. I linguaggi dettagliati tendono a significare che molte, molte righe di codice devono essere usate per fare sempre la stessa cosa. Tuttavia, può esserci una sorta di prezzo da pagare con linguaggi espressivi in ​​quanto potrebbero non essere così veloci da eseguire come i linguaggi di alto livello più semplici. Se posso fare un esempio nel contrasto tra C e C ++. Il C ++ dà più potere espressivo agli scrittori di codice: possono incapsulare l'idea di oggetti del mondo reale nelle classi. I programmatori C possono ottenere le stesse cose ma hanno il potere espressivo del costrutto di classe per aiutarli - così spesso devono scrivere codice più lungo, più complicato (per capire). Ma quel codice potrebbe essere eseguito più velocemente (sebbene ciò dipenda fortemente dalla qualità del compilatore e così via) perché non usa il "late binding" di C ++ (cioè il refactoring del tempo di esecuzione) per eseguire il codice. C esegue semplicemente il codice compilato e collegato, C ++ deve prendere una decisione (in determinate circostanze) in fase di esecuzione su quali parti di codice eseguire.

Credo che ci sia una risposta alla domanda radicata in una questione più fondamentale e teorica della leggibilità e questa risposta è correlata alla teoria dell'informazione algoritmica fondata da Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Detto in poche parole, "il contenuto informativo di una stringa equivale alla lunghezza della rappresentazione autonoma più corta possibile di quella stringa", Ciò implica che il programma più breve (vale a dire in termini di lunghezza lessicografica) che risolva da vicino un dato problema corrisponde alla complessità intrinseca del problema a cui fornisce una soluzione e, quindi, dipende più dalla natura del problema e meno dalla rappresentazione del problema.