Principio KISS applicato alla progettazione del linguaggio di programmazione?

Quando penso al minimialismo, penso a Lisp e Vai . Con Lisp, tutto quello che hai sono funzioni ed elenchi, che è più semplice che puoi ottenere (beh, c'è un po 'di più, ma qualunque cosa sia). Tuttavia, penso che il caso Go sia più interessante.

Vai era progettato per essere semplice (è una lettura decente). Il termine che usano è "feature orthogonality", il che significa che qualsiasi funzione dovrebbe essere aggiunta solo se fornisce qualcosa di veramente unico. Questo sembra derivare dagli autori ( Russ Cox e Rob Pike venire in mente) coinvolgimento con Plan9 , che è stata una rivisitazione di UNIX con semplicità in mente. (Se ti interessa il design minimale, la carta di Rob Pike su un sistema di finestre semplici è una buona lettura. )

Ecco alcuni semplici esempi della sintassi:

Un solo costrutto di loop

Un ciclo può apparire come uno dei seguenti:

Ciclo infinito

for {
}

While loop

for <conditional> {
}

Tradizionale per ciclo

for i := 0; i < 10; i++ {
}

Ciclo Foreach

// works for maps or arrays
for k, v := range arr {
}

Interruttore multiuso

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

Ritorno multiplo

return val1, val2, ...

• Rimuove la necessità di lancio (passa l'errore come ultimo valore di ritorno)
• Rimuove la necessità di utilizzare i parametri
• Rimuove la necessità di tuple

Interfacce

type X interface {
    DoSomething()
    String() string
}

• Risolve problemi simili come generici
• Consente l'astrazione

Embedding

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

• Risolve lo stesso problema dell'ereditarietà
• Elimina la necessità di classi

Canali

Può essere usato per implementare i semafori

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

Utilizzato per il trasferimento di messaggi tra thread

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

Può essere utilizzato per gestire eventi asincroni

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

Conclusione

Non ho intenzione di entrare in ogni parte della sintassi, ma spero che tu possa vedere cosa può fare il minimalismo. La lingua è intrigante non perché aggiunge un sacco di nuove funzionalità, ma perché utilizza le migliori funzionalità di altre lingue senza aggiungere altro.

Di solito c'è un modo "migliore" per risolvere un problema. Ad esempio, sulla mailing list, molti utenti si lamentano di non avere generici. Dopo la discussione, si rendono conto che tutto ciò che vogliono fare può essere fatto con le interfacce. Leggi su vai efficace per esempi sulla sintassi idiomatica.

Il vantaggio dei linguaggi KISS è che è possibile scrivere codice idiomatico, perché lo stile del codice è limitato dalla lingua. Ad esempio, in Go, non puoi scrivere qualcosa come questo:

if <condition>
    statement;

Devi usare parentesi graffe:

if <condition> {
    statement;
}

Ci sono molti altri esempi di questo nella sintassi, che rende più semplice la lettura del codice di altri popoli.

Vantaggi del linguaggio KISS rispetto alle lingue con funzionalità:

• più facile da capire il codice degli altri
• più facile per l'intero linguaggio (il C ++ è noto per essere difficile da capire)
• concentrarsi sull'algoritmo, non sulla sintassi

Penso che Zen of Python indicherà perché Python è un linguaggio semplice molto meglio di Posso:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Modifica in risposta a @Giorgio

Come indica la tua domanda,

"Do you know of any programming languages that have been designed specifically with this principle in mind, i.e. to 'allow an average programmer under average working conditions to write and maintain as much code as possible with the least cognitive effort'"

Python è, per me, quello che mi viene immediatamente in mente. Il design di Python è in risposta diretta alla metodologia di Perl, il famoso "C'è più di un modo per farlo". Mentre è grandioso, permettendo ai programmatori di scrivere codice molto facilmente, non aiuta con la manutenzione. Avendo prima gestito un programma scritto in Perl (scritto molto male, lo ammetto), apprezzo Python forzando sia le buone pratiche di codifica che il linguaggio conciso in gola.

Python inoltre non ti obbliga a seguire una particolare metodologia durante la scrittura dei programmi. Posso scegliere di seguire uno stretto stile di programmazione orientato agli oggetti, o posso scrivere un semplice script da eseguire in sequenza. Non dover inizializzare una classe, quindi chiamare il metodo main() come si è costretti a fare in Java è molto bello. (Inoltre, la stampa su stdout in Python è meravigliosa, ma è un punto piuttosto nullo).

Infine, la metodologia "Batterie incluse" di includere una vasta libreria standard con la lingua è meravigliosa. Invece di cercare alcuni pacchetti esterni per i pacchetti, la maggior parte di ciò di cui ho bisogno è già inclusa nella lingua. È anche bello avere quel repository esterno, ma non dover scavare attraverso di esso per fare un'operazione di base è davvero utile.

Probabilmente, Tcl è stato sviluppato seguendo queste linee. L'intera lingua può essere descritta solo in 12 regole su una singola pagina man . È straordinariamente semplice e coerente.

Il creatore di Tcl ha affermato quanto segue come obiettivi originali:

• La lingua deve essere estensibile: deve essere molto facile per ciascuno applicazione per aggiungere le proprie funzionalità alle funzionalità di base del lingua e dovrebbero apparire le caratteristiche specifiche dell'applicazione naturale, come se fossero stati progettati nella lingua dal iniziare.
• Il linguaggio deve essere molto semplice e generico, in modo che possa funzionare facilmente con molte applicazioni diverse e così non lo fa limitare le funzionalità che possono essere fornite dalle applicazioni.
• Dal momento che la maggior parte delle funzionalità interessanti verrà dal applicazione, lo scopo principale della lingua è integrare o "Incolla" le estensioni. Quindi la lingua deve essere buona strutture per l'integrazione.

Da " Cronologia di Tcl " - link

Se una lingua è fissa nel suo design a causa di KISS, non può crescere. Un linguaggio che non può crescere morirà.

Nel seguente video Guy Steele spiega abilmente che un linguaggio di programmazione deve poter crescere e perché. Se applichi KISS, allora come può un langauge crescere perché una volta rilasciato, il set di strumenti è fisso e non è mai permesso di cambiare.

Guy Steele's keynote at the 1998 ACM OOPSLA conference on "Growing a Language" discusses the importance of and issues associated with designing a programming language that can be grown by its users.

È un video lungo un'ora, ma vale la pena guardare. Se non sai chi è Guy Steele dovresti davvero parlare di design della lingua.

Scelgo questo video come risposta perché ritengo che applicare KISS alla progettazione linguistica in generale sia sbagliato, e sperare che vedere un discorso di una nota persona del design linguistico possa aiutare ad ampliare la tua comprensione del futuro della progettazione linguistica.

Da quando sei venuto qui per imparare il design della lingua e ti ho dato una ragione per non usare KISS è giusto che io mostri qualcosa che trovo di aiuto nella progettazione del linguaggio. Dimensioni cognitive delle notazioni

Modifica

Quando ho scritto la risposta di cui sopra è stato basato sul ragionamento di: se un motore può essere mantenuto solo con un set fisso di strumenti, allora la mia riformulazione di quel significato rispetto alla progettazione del linguaggio è che un linguaggio non può cambiare una volta rilasciato . I commenti indicano che non era quello che si intendeva. Quindi lasciatemi presentare questa risposta modificata che sarà più in linea con la comprensione rivista.

Se uno dà un'occhiata a Dimensioni cognitive delle notazioni allora si impara che ci sono molte dimensioni concorrenti associate alla progettazione della lingua oltre alla semplicità e se ti concentri troppo su uno, soffrirai negli altri. Con la domanda di sta concentrando molto sulla semplicità (KISS) e sostenuta da persone famose del design del linguaggio, ho inviato il speech di Guy Steele per dimostrare che cercare di mantenere un design semplicemente semplice inciderà su altre dimensioni. Ancora più importante, sto cercando di comunicare che è necessario guardare a molte dimensioni e valutare i pro ei contro di esse, non solo la semplicità.

Una chiave importante per mantenere la "semplicità" è riconoscere quando sarà necessaria la complessità e fare in modo che le parti del sistema possano gestirlo al meglio. Avere un unico tipo di riferimento all'oggetto che non fa distinzione tra valori immutabili, valori mutabili ed entità, rende Java "semplice", non elimina la necessità di distinguere tra valori ed entità; priva semplicemente i programmatori di strumenti per aiutarli a farlo.

Più in generale, se si sta tentando di far sì che un linguaggio di programmazione o una funzione di framework supportino più casi d'uso, si dovrebbe garantire che non ci saranno situazioni in cui comportamenti differenti sarebbero appropriati in diversi casi d'uso, ma il compilatore sarebbe incapace di distinguerli. Aggiungere più tipi a una lingua o a un framework può sembrare una complicazione, ma in molti casi può davvero semplificare le cose.

Consideriamo, ad esempio, il caos delle regole che circondano i tipi firmati e non firmati in C. La complessità di queste regole deriva dal fatto che alcuni codici usano tipi interi senza segno per rappresentare numeri, mentre altri codici li usano per rappresentare membri di un avvolgimento di anello algebrico (in particolare, l'insieme di interi congruenti mod 2ⁿ). Le regole di conversione del tipo si comportano in modi che a volte sono appropriati per un utilizzo e talvolta in modi appropriati per l'altro. Avere tipi di avvolgimento e non-wrapping separati raddoppierebbe il numero di tipi interi, ma potrebbe semplificare le regole ad essi associate:

• Qualsiasi tipo intero non ring di qualsiasi dimensione può essere assegnato a un anello di qualsiasi dimensione; un anello può essere assegnato solo a un anello di dimensioni uguali o minori .

• Le operazioni diverse dagli operatori relazionali che coinvolgono un numero intero non ring e un anello implicano la conversione implicita del numero intero nel tipo di suoneria.

• Gli anelli possono essere espressi espressi su numeri o su anelli più grandi; il valore di un anello senza segno è il più piccolo numero intero non negativo che, aggiunto allo zero dell'anello, produrrebbe il valore dell'anello. Il valore di un anello con segno è il numero di grandezza minore che, aggiunto allo zero dell'anello, produce il valore dell'anello, con il valore negativo che viene preferito in caso di parità.

• Ad eccezione di quanto sopra menzionato, gli anelli sono limitati alle operazioni con anelli della stessa dimensione o più piccoli.

• Le operazioni su interi non-ring di tipi diversi dovrebbero aggiornare i numeri a un tipo che può ospitare tutti i valori di entrambi gli operandi, o dovrebbero essere rifiutati dal compilatore se non esiste un tipo adatto

La definizione dei tipi di anello sembra raddoppiare il numero di tipi interi, ma semplificherebbe enormemente la scrittura del codice portatile. L'utilizzo degli stessi tipi senza segno per numeri e anelli riduce il numero di tipi, ma porta a regole complicate che rendono quasi impossibile scrivere codice portatile efficiente.

Ecco una grande citazione da Hardcore Visual Basic di Bruce McKinney , che a sua volta mette le parole in bocca ai progettisti di BASIC, Kemeny e Kurtz . Enfatizza il mio.

Every computer language has its own feel, its own atmosphere, its own spirit. You can’t really define this spirit, but you know what it is when you see it. I think of Basic as the antithesis of a statement attributed to Albert Einstein:

Make things as simple as possible—but no simpler.

     

Questa frase era stata scritta dai designer originali di Basic, John   Kemeny e Thomas Kurtz, sarebbe stato ulteriormente semplificato:

     

Make things simpler than possible.

     

Questa è la contraddizione con cui vivono i programmatori hardcore di Visual Basic.   Vogliamo che le cose siano semplici, eleganti e intuitive, ma non lo sono.   Vogliamo che i nostri programmi modellano la realtà, ma non lo fanno. Vogliamo il nostro   linguaggio per funzionare come pensiamo, non come i computer o il funzionamento   i sistemi vogliono che pensiamo, ma non siamo disposti a pagare il prezzo .

But can the KISS principle be applied also to programming language design? Do you know of any programming languages that have been designed specifically with this principle in mind, i.e. to "allow an average programmer under average working conditions to write and maintain as much code as possible with the least cognitive effort"?

È una buona cosa che hai chiarito cosa intendi per "semplice", perché nella mia mente un semplice linguaggio di programmazione è uno con sintassi minima e poche funzioni (Scheme, Forth, ML), che non traducono direttamente alla tua definizione . Penso che tu stia davvero pensando alla progettazione delle lingue con RAD (sviluppo rapido delle applicazioni) in mente, e ce ne sono molte. Vedi questo thread StackOverflow, ad esempio: link

Sono sorpreso che nessuno abbia mai menzionato C, anche se mette la semplicità al primo posto in molti modi importanti, spesso in modo così radicale che i programmatori non apprezzano la semplicità:

• Non c'è magia nascosta. Se scrivi a + b in C, hai la garanzia che verrà compilato al massimo da una singola istruzione assembler.

  Anche in linguaggi relativamente semplici come Java, una semplice istruzione come a + b può richiedere diversi microsecondi (se le variabili sono stringhe). Altre lingue aggiungono molto, molto di più a questo con l'estremo esempio di C ++ in cui a + b può essere sovraccaricato per far apparire elefanti rosa. Non così in C: se non è una chiamata di funzione, non ci vorranno più di pochi nanosecondi. Questa prevedibilità delle prestazioni è una delle caratteristiche principali di C, ed è certamente una forma di semplicità.

• I tipi di dati sono semplici come possono essere mentre descrivono ancora tutte le strutture di dati interessanti che potresti voler costruire in memoria: ci sono solo i tipi fondamentali che una CPU può gestire + aggregazione ( struct ) + ripetizione ( matrici) + riferimenti (puntatori).

  È vero che i vari linguaggi basati su Lisp sono molto più semplici di C in questo senso. Tuttavia, non tentano di consentire al programmatore di manipolare liberamente la memoria come fa C.

• Ortogonalità delle caratteristiche: puoi combinare liberamente le funzionalità e funzioneranno insieme come previsto. Molte lingue falliscono permettendo che certi costrutti appaiano solo in contesti definiti.

  Prendiamo ad esempio matrici di lunghezza variabile in C e C ++: C consente lunghezze di runtime ovunque mentre le richieste più liberali di espandere lo standard C ++ le consentono solo in determinati contesti come gli array automatici e anche lì solo nella prima dimensione. Ciò consente a C di gestire veri array multidimensionali con dimensioni note solo in fase di esecuzione, mentre i programmatori C ++ sono ridotti a scrivere data[k + (j + i*lineLength)*lineCount] più e più volte.

  Un altro esempio di questo è il puntatore: un puntatore di dati in C questo in realtà non è niente più o meno di una variabile che contiene un indirizzo di memoria di qualche altra variabile. Poiché il puntatore è esso stesso una variabile, il doppio puntatore è una cosa ben definita. Cioè dato che cosa sono int e int* , è chiaro che cosa deve essere int** . Confronta questo con riferimenti C ++ in cui non hai assolutamente idea di cosa int&& abbia il significato di int e int& !)

È vero che è proprio questa semplicità che ha guadagnato tanto odio in C: la semplicità del linguaggio consente ai programmatori più libertà di quanto sia buono per loro, portando a molti problemi con comportamenti indefiniti e puntatori mal gestiti. Soprattutto la semplicità dell'ortogonalità che consente a un programmatore di definire una variabile come int (*array[m])(struct foo* (*arg)[n]) è del tipo che tende a dare ai lettori mal di testa perché le cose veramente complesse possono essere espresse in una forma molto concisa da una combinazione liberale di alcune semplici caratteristiche . Questo è il tipo di semplicità con cui C eccelle e che gli dà la reputazione di essere un linguaggio difficile da usare.

Inoltre, la semplicità del linguaggio costringe il programmatore a scrivere molto più codice di altri linguaggi ricchi di funzionalità, fornendo un terreno più fertile per far prosperare gli insetti. Tuttavia, rimane il linguaggio di alto livello più semplice possibile se il tuo obiettivo principale è programmare un vero computer e non una macchina virtuale.

Java Wikipedia - sebbene non dichiarato esplicitamente in Wikipedia, la semplificazione è menzionata un certo numero di volte e un obiettivo di progettazione originale, in quanto l'unico linguaggio serio con OO (termine utilizzato in modo approssimativo) a quei tempi era il C ++, che come tutti sappiamo, è potente ma ha più di poche trappole per gli incauti.

La JVM era intesa come un modo per semplificare lo sviluppo multipiattaforma e "Write once Run anywhere" è diventato un mantra Java per alcuni anni - ancora una volta, l'intento era che il framework fosse semplice da implementare.

Credo che C # rientri in quella categoria di semplificazione della lingua.

Hm ... questa è davvero una domanda difficile da rispondere 'positivamente', perché quando penso alla semplicità nella programmazione del linguaggio di programmazione (e cosa è 'più facile' lavorare con), penso immediatamente a:

1. "Leggibilità" del codice: quanto bene il linguaggio incapsula oggetti, metodi, ecc.
2. La coerenza delle API e delle interfacce del linguaggio.

Ci sono un certo numero di linguaggi che fanno bene queste cose - ma quello che mi viene in mente è un linguaggio che non fa le cose bene 'come linguaggio di programmazione': PHP.

[Disclaimer: ho scritto PHP e PHP è ancora il mio "go to language" per progetti web semplici. Questa è una critica dell'amore ...]

In primo luogo, PHP fa bene all'ambiente in cui viene generalmente eseguito - i server web. È facile da configurare, facile da mantenere, ecc.

Dove fatico con PHP: quando si vuole fare qualcosa di "inusuale" - qualcosa che in genere non si fa su base regolare (nel caso in cui sto pensando che stava consumando un servizio web SOAP - non qualcosa Ho fatto molto con PHP), hai a che fare con due opzioni:

1) Varie estensioni open source per PHP. Il modello di oggetti PHP è abbastanza lento in cui la progettazione dell'interfaccia non è troppo coerente da libreria a libreria, da sviluppatore a sviluppatore. Di fronte a una serie di codici in cui qualcuno ha utilizzato una libreria di cui non hai mai sentito parlare, passi molto tempo a capire "cosa diavolo fa" perché la lingua consente la creazione di API / librerie allentate.

2) Le funzioni "built-in" - di cui ci sono molto . Ho attraversato alcuni buchi di coniglio per trovare un'altra libreria o implementare un po 'di funzionalità per in qualche modo in seguito inciampare su impossiblyfound_basefunction()

Secondo me, la semplicità è coerenza.

Ora, l'approccio KISS ai linguaggi di programmazione è una nozione divertente, almeno se si considera che i linguaggi di programmazione siano un livello di astrazione per il set di istruzioni di una CPU, ecc. Se non si definisce "KISS" più da vicino. Sto solo dicendo che un carro da buoi è KISS applicato a un'auto al massimo.

Ora un'altra interpretazione di KISS potrebbe essere qualcosa come "elegantemente fatto senza ornamenti inutili e non eccessivamente complicato". Soprattutto si potrebbe obiettare che non ci dovrebbero essere troppi casi specifici per cose simili, ecc. Di solito la matematica è abbastanza brava a far bollire le cose nella sua essenza, e - o chiedo - i matematici hanno passato un po 'di tempo a pensare anche alla programmazione e ai computer .

Per la programmazione esistono 2 modelli astratti piuttosto famosi:

• Uno è il turing machine che definisce una macchina e un semplice modello di istruzione in grado di calcolare tutto ciò che un computer potrebbe fare.
• L'altro è il Lambda-Calculus di Church et. al. è equivalente in potenza

La cosa divertente è che, sebbene il turing machine sia piuttosto semplice nel suo layout, non è un sistema facile da gestire e non credo che sia adatto per "smart KISS". Ma Lambda Calculus ha più a che fare con i linguaggi di programmazione che conosciamo - e con le caratteristiche pionieristiche di Lisp e Scheme del calcolo lambda si è fatto strada in molte lingue.

Lisp e Scheme sono REALMENTE semplici, almeno per quanto riguarda la sintassi. La sintassi è un grosso problema con i linguaggi di programmazione (che è probabilmente il motivo per cui sono reinventati in ogni momento). Nel caso del C ++ è quasi impossibile per il cervello umano prevedere come alcune linee di origine vengono interpretate dal compilatore.)

I Lisps stanno riducendo la complessità sintattica del tutto introducendo un modulo comune per i comandi:

(command param1 param2 ...)

Questa può essere una chiamata al metodo, come

(max 1 2 3 4)

così come un ramo if, loop ecc.

(if (< 1 2) 
    (write 4)
    (write 5))

(tutto il codice qui è pseudo-Lisp / Dialect agnostic)

Il modulo

(command param1 param2 ...)

può anche essere interpretato come una lista

(item1 item2 item3)

E questa è la base della semplicità e della bellezza di Lisps. Poiché gli elenchi annidati (come nell'esempio di istruzione if ) costituiscono alberi e possono essere facilmente compresi sia dalla macchina che dall'essere umano davanti alla macchina.

Un'altra caratteristica dei Lisps sono macro non entrerò nei dettagli sporchi qui, ma poiché non c'è differenza sintattica tra le normali chiamate di funzione e "Sintassi (egg for loops, dichiarazione delle variabili, ecc. ., tutto ciò che il parser deve gestire in altri linguaggi di programmazione) è possibile creare la propria sintassi. I macro sono in pratica Manipolazioni dell'albero che costituisce il programma.

Penso che Lisp abbia un BACIO di programmazione. Il fatto che sia possibile manipolare la sintassi utilizzando le macro ha portato a un fenomeno che il Lisp si è evoluto in modo abbastanza dinamico. Hai bisogno di una nuova funzionalità di linguaggio come - diciamo orientamento agli oggetti - basta scrivere un sistema OOP con macro!

Mentre C è stato esteso a rotatoria 2 volte con le funzionalità OOP (C ++, Obj. C) Lisp è stato esteso più volte, alla fine c'è stato un vincitore.

Questa è un'altra stranezza su Lisp, si evolve (vedi Clojure e Clojurescript per interessanti nuove Mutation of lisp).

Per le sue proprietà KISS, il Lisps è preferito come lingua di insegnamento da alcuni. Come Fogus delinea nel suo progetto di un linguaggio educativo ( link )

To start, I’m strong believer that when learning new, and at times complex topics it’s outright detrimental to overload students with frivolous syntax rules. Therefore, Enfield is designed with minimal syntax rules and what’s more minimal than a Lisp like syntax.